原文 : http://source.android.com/tech/security/index.html
Androidプラットフォームを構成する主要なブロックは下記です。
- Device Hardware
- Android OS
- Androidアプリケーションランタイム
Androidのアプリケーションには2つの主要な提供場所があります。
- プリインストールアプリ
- ユーザーインストールアプリ
Googleの提供している主要なサービスは以下です。
- Google Play
- Android Updates
- Application Services
これらのサービスはAndroid Open Source Projectには含まれません。また、この文書の対象範囲外です。 しかしながら、これらはほとんどのAndroidデバイスのセキュリティに関連し、「Google Services for Android: Security Overview」というタイトルのセキュリティ文書が存在します。
開発の初期段階から、主要なAndroid開発チームは、Androidプラットフォームとクラウドサービスによるサポートの周囲に構築されるアプリケーションとデバイスのエコシステムの活性化に堅牢なセキュリティモデルが必要であることを認識していました。 うんたらかんたら（後で書く）。
Androidセキュリティプログラムのキーとなるコンポーネントは次のものを含みます。
- デザインレビュー: Androidセキュリティの手続きは、リッチで設定可能なセキュリティモデルとデザインの生成による開発ライフサイクルを、早期に開始します。システムアーキテクチャに統合された適切なセキュリティコントロールと共に、主要なプラットフォームの機能はエンジニアリングとセキュリティリソースによってレビューされます。
- 侵入テストとコードレビュー: プラットフォームの開発中は、Androidが作成したものとオープンソースコンポーネントは、活発なセキュリティレビューの対象となります。これらのレビューはAndroidセキュリティチーム、Googleの情報セキュリティエンジニアリングチーム、そして第三者のセキュリティコンサルタントによって実施されます。これらのレビューの目標はプラットフォームがオープンソースになる充分前に、弱点と脆弱性の可能性を特定することと、リリース時に外部のセキュリティの専門家によって行われる分析の種類をシミュレートすることです。
- オープンソースとコミュニティレビュー: Android Open Source Projectは利害関係者による広範なセキュリティレビューを可能にします。Androidも、Linuxカーネルのように重要な外部のセキュリティレビューを経たオープンソースの技術を使用しています。Google Playは、ユーザーとユーザーへ直接特定のアプリケーションに関する情報を提供する企業のための討論の場を提供します。
- 問題への対応: これらの注意事項の全てを満たしたとしても、セキュリティ上の問題が出荷後に発生する可能性があり、それがAndroidプロジェクトが包括的なセキュリティ対応手順を作成した理由です。Androidセキュリティチームは、Android独自のものも一般的なものも含めた、潜在的な脆弱性の議論を行うためのセキュリティコミュニティを定常的に監視しています。正当な問題が発見された際は、Androidチームは、全てのAndroidユーザーへの潜在的なリスクを最小化するために、脆弱性の迅速な低減を可能にする対応手続きをもっています。これらのクラウドに補助された対応はAndroidプラットフォームのアップデート（over-the-air update）や、Google Playからのアプリケーションの削除、そして使用されているデバイスからのアプリケーションの削除を含めることができます。
Androidは以下のような従来のOSのセキュリティコントロールの転用によって、最も安全で使い易いモバイルプラットフォームのためのオペレーティングシステムになることを目指しています。
- ユーザデータ保護
- ネットワークを含んだシステムリソースの保護
- 隔離されたアプリケーションの提供
上記の目的を達成するために、Androidはキーとなるセキュリティのための機能を提供します。
- Linuxカーネルを含んだOSレベルの堅牢なセキュリティ
- 全てのアプリケーションに対して必須となるサンドボックス環境
- 安全なプロセス間通信
- アプリケーション署名
- アプリケーションが定義でき、ユーザー許可制であるパーミッション
このセクションでは、上記のAndroidプラットフォームにおけるセキュリティ上の機能について説明します。 Figure1 はAndroidソフトウェアスタックの様々なレベルでのセキュリティコンポーネントと関連するものの概要をまとめた図です。 各コンポーネントは下位のコンポーネントが適切な安全対策が施されている前提になっています。 ルート権限で動作するAndroid OSの少量のコードを除いて、Linuxカーネル上で動く全てのコードがアプリケーションサンドボックスによって制限されます。
Figure 1: Android software stack.
オペレーティングシステムレベルでは、AndroidプラットフォームはLinuxカーネルのセキュリティおよび、異なるプロセスとして実行されるアプリケーション間での安全なコミュニケーションを可能にするための、安全なプロセス間通信（IPC）の機構を提供します。 これらのOSレベルのセキュリティ機能によって、ネイティブコードであってもアプリケーションサンドボックスによって制約を受けることが確認できます。 そのネイティブコードが含まれているアプリケーションの動作の結果であれ、アプリケーション脆弱性の悪用の結果であれ、システムは他のアプリケーション、Androidシステムまたはデバイス自身を、害のある悪意を持ったアプリケーションから保護します。
Androidプラットフォームの土台はLinuxカーネルです。Linuxカーネル自身は何年も広く使用されており、安全に敏感な数百万の環境で使われています。 うんたらかんたら（後で書く）
モバイルコンピューティング環境のための基盤として、Linuxカーネルはいくつかのキーとなるセキュリティ機能をAndroidに提供します。
- ユーザーベースのパーミッションモデル
- プロセスの隔離
- 安全なIPCのための拡張可能なメカニズム
- 不要なものや潜在的に安全で無いカーネルの一部を取り除く能力
マルチユーザーオペレーティングシステムとして、Linuxカーネルとしての根本的なセキュリティ対策方針は、ユーザーリソースを他のユーザーから隔離することです。 Linuxのセキュリティ哲学はユーザーリソースを他のユーザーから保護することです。
- ユーザーAがユーザーBのファイルを読み取ることを禁止する
- ユーザーAがユーザーBのメモリを使い果たさないようにする
- ユーザーAがユーザーBのCPUリソースを使い果たさないようにする
- ユーザーAがユーザーBのデバイス（例えば電話、GPS、Bluetooth）を使い果たさないようにする
Androidプラットフォームでは、アプリケーションリソースの識別と隔離のためにLinuxユーザーベースの保護を活用しています。 Androidシステムは各Androidアプリケーションに一意のユーザーIDを割り当て、個別のプロセスとして、割り当てられたユーザーとしてアプリケーションを実行します。 この手法は、複数のアプリケーションが同じユーザー権限で動作するような、その他の（従来のLinuxの構成を含んだ）オペレーティングシステムとは異なるものです。
うんたらかんたら（後で書く）
システムパーティションはAndroidの核となる部分および、オペレーティングシステムのライブラリ、アプリケーションランタイム、アプリケーションフレームワーク、そしてアプリケーションを含んでいます。 このパーティションは読み取り専用として設定されます。 ユーザーがデバイスをセーフモードで起動した場合は、コアとなるAndroidアプリケーションたちだけが有効です。 これにより、サードパーティのソフトウェアを除外した環境でデバイスを起動することができます。
UNIXスタイルの環境では、ファイルシステムパーミッションによって、あるユーザーが他のユーザーのファイルに対して変更または読み取りができないことを確保します。 Androidにおいては、各アプリケーションが個別のユーザーとして動作します。 開発者が明示的にファイルを他のアプリケーションに対して公開する場合を除いて、あるアプリケーションが作成したファイルは、他のアプリケーションによって読み取られたり変更されたりすることはありません。
Android 3.0以降ではファイルシステム全体の暗号化機能が提供されており、カーネル内部でdmcryptのAES128(CBC)とESSIV:SHA256を使用した実装による暗号化を、全てのユーザーデータに対して行えます。 暗号化の鍵はユーザーパスワードを元にした鍵を使用したAES128によって保護され、ユーザーデバイスパスワード無しに、保存されたデータへの許可されていないアクセスを予防します。 システマチックなパスワード推測攻撃（例えば"rainbow tables"や総当たり）に対抗するために、パスワードはランダムなsaltと合成され、ファイルシステムが復号される前に標準のPBKDF2アルゴリズムを使用したSHA1で繰り返しハッシュ化されます。 辞書式のパスワード推測攻撃に対抗するために、Androidはオペレーティングシステムによって強制できる、デバイス管理者によって設定可能なパスワードの複雑さについてのルールを提供します。 ファイルシステムの暗号化ユーザーパスワードの使用が必要で、パターンベースのスクリーンロックはサポートされていません。
より詳細なファイルシステムの暗号化の実装についてはこちらを参照してください : http://source.android.com/tech/encryption/android_crypto_implementation.html
Androidは、デバイスへのアクセスを提供する前に、ユーザーの入力したパスワードを検証するように設定ができます。 許可されていないデバイスの使用を予防することに加えて、このパスワードが全ファイルシステムの暗号化のための暗号化キーを保護します。
パスワードとパスワードの複雑さのルールの両方またはどちからの使用は、デバイス管理者によって必須になるよう設定できます。
Android 2.2以降では「Android Device Administration API」を提供し、システムレベルでのデバイス管理機能を提供します。 例えば、組み込みのAndroid EメールアプリケーションはExchangeサポートの改善のためにこのAPIを使用します。 Eメールアプリケーションを通じて、Exchangeの管理者たちはパスワードポリシー（アルファベットと数字を含んだパスワードまたは数値のPINコード）をデバイスを横断的に強制できます。 管理者たちは紛失または盗まれた携帯電話に対して、遠隔からのワイプ（工場出荷状態への復元）もできます。
Androidシステムに含まれるアプリケーションでの使用に加えて、これらのAPIはデバイス管理ソリューションのサードバーティ提供者も利用できます。
このAPIの詳細はこちらを参照してください : https://developer.android.com/guide/topics/admin/device-admin.html
Androidは、一般的なセキュリティ問題を悪用するのを難しくする多くの機能を含んでいます。
Android 1.5+
- スタックバッファーオーバーランを予防するためのProPolice（-fstack-protector）
- 正数オーバーフローを減少させるためのsafe_iop
- double freeの脆弱性とチャンク連結攻撃を予防するためのOpenBSDのdlmallocへの拡張。チャンク連結攻撃はヒープの破壊を悪用するための一般的な手法です。
- メモリ割り当て時の正数オーバーフローを予防するためのOpenBSDのcalloc
Android 2.3+
- 書式化文字列に関する脆弱性の保護（-Wformat-security -Werror=format-security）
- スタックとヒープ上のコード実行を予防するためのハードウェアベースのNo eXecute（NX）
- NULLポインタ参照による権限昇格を軽減するためのLinuxのmmap_min_addr（Android 4.1ではさらに強化）
Android 4.0+
- メモリ内のキーの配置をランダム化するための、アドレス空間配置のランダム化(Address Space Layout Randomization : ASLR)
Android 4.1+
- Position Independent Excecutable(PIE)サポート
- 読み取り専用の再配置 / 即時結合 (-Wl,-z,relro -Wl,-z,now)
- dmesg_restrictの有効化 (カーネルアドレスの漏洩を避ける)
- kptr_restrictの有効化 (カーネルアドレスの漏洩を避ける)
初期設定では、Android上ではカーネルとコアアプリケーションの小さなサブセットだけが、ルート権限で動作します。 Androidは、ルート権限をもったユーザーまたはアプリケーションが、オペレーティングシステム、カーネルそして他のアプリケーションを修正するのを予防しません。 通常は、ルートは全てのアプリケーションとアプリケーションのデータへの完全なアクセスを所持しています。 Androidデバイス上の権限を、アプリケーションへのルート権限を許可するように変更するユーザーは、悪意のあるアプリケーションや潜在的なアプリケーションの欠陥へのセキュリティ上の露出を増加させます。
Androidプラットフォームで作業を行う開発者にとって、Androidデバイスを変更するための機能は重要です。 多くのAndroidデバイス上では、ユーザーが代替となるオペレーティングシステムをインストールするために、ブートローダーのロック解除を行う機能を持っています。 これらの代替となるオペレーティングシステムは、アプリケーションとシステムコンポーネントのデバッグか、またはAndroidのAPIとして提供されていない機能へアクセすることを目的として、所有者がルート権限でのアクセスを得ることを許可するかもしれません。
デバイスによっては、デバイスとUSBケーブルでの物理的な制御によって、人の手でユーザーへルート権限を提供する新しいオペレーティングシステムをインストールすることができます。 妥協から既存のユーザーデータを保護するために、ブートローダーのロック解除機構は、ロック解除の手順の一つとして、全ての既存のユーザーデータをブートローダーが消去することを要求します。 カーネルのバグやセキュリティホールを悪用して得たルート権限でのアクセスは、アクセス保護を迂回することができます。
デバイス上に格納された鍵を使用して暗号化されたデータは、ルート権限をもったユーザーからは保護されません。 アプリケーションは、サーバー上やユーザーパスワードのようなデバイスの外側に格納された鍵による暗号化を使用する、データ保護レイヤーを追加できます。 この方法は、キーが存在しない間の一時的な保護を提供できますが、どこかの時点で鍵はアプリケーションに提供されなければならず、そうであればルート権限をもったユーザーにアクセスすることが可能になります。
うんたらかんたら（後で書く）
Androidはモバイルデバイスのためのオープンソースプラットフォームとアプリケーション環境を提供します。 オペレーティングシステムのコアはLinuxカーネルを元にしており、Androidアプリケーションはほとんどの場合、プログラミング言語Javaで書かれDalvik仮想マシン上で動作します。 しかしながら、アプリケーションをネイティブコードで書くこともできます。 アプリケーションは「.apk」という拡張子をもった単一のファイルからインストールされます。
Androidアプリケーションを構成する主要なブロック:
- AndroidManifest.xml : アプリケーション中の全てのトップレベルコンポーネント(具体的には、Activities, Services, Broadcast Receivers, そして後述のContent Providers)をどう処理するのかをシステムに通知する制御ファイルです。またどの権限が必要かの指定もします。
- Activities : 通常は単一のユーザーに特化したタスクのコードです。通常ユーザーへ表示するUIを含みますが、それは必須ではなく、いくつかのActivityは表示されないUIです。一般的に、アプリケーションのActivityの一つが、アプリケーションのエントリーポイントです。
- Services : バックグラウンドで動作するコードの本体です。独自のプロセスで、または別のアプリケーションのプロセスのコンテキストで動作できます。他のコンポーネントはServiceに"bind"しリモートプロシージャコールを経由してメソッドを呼び出します。サービスの例はmedia player: ユーザーがメディア選択のUIを終了しても、ユーザーはおそらく音楽が再生され続けることを想定します。サービスはUIが完了した時でも音楽の再生を続けます。
- Broadcast Receiver : Intentとして知られるIPCメカニズムがオペレーティングシステムまたは他のアプリケーションによって発行される時、インスタンス化されるオブジェクトです。例えば、アプリケーションはバッテリの出力低下メッセージのためのレシーバーを登録し、情報に基づいて動作を変更できます。
初期設定では、Androidアプリケーションはシステムリソースの限られた範囲へのアクセスだけができます。システム管理のAndroidアプリケーションはリソースにアクセスします、もし間違ったかまたは悪意をもって使用されたら、ユーザーエクスペリエンスや、ネットワークまたはデバイス上のデータに悪影響を与える可能性があります。
うんたらかんたら（後で書く）
これらの保護APIは下記を含みます:
- Camera functions
- Location data (GPS)
- Bluetooth functions
- Telephony functions
- SMS/MMS functions
- Network/data connections
うんたらかんたら（後で書く）
システムの初期設定のパーミッションはhttps://developer.android.com/reference/android/Manifest.permission.htmlに記述されています。 アプリケーションは他のアプリケーションが使用するための独自のパーミッションを宣言できます。 それらのパーミッションは前述の場所には記載されません。
パーミッションを定義する時のprotectionLevel属性は、アプリケーションが必要とするパーミッションをユーザーに通知する方法か、またはパーミッションの保持を許可されているのが誰かをシステムに指示します。
アプリケーション固有のパーミッションの作成と使用の詳細はこちらを参照してください : https://developer.android.com/guide/topics/security/security.html
SMSブロードキャストインテントを送信するようないくつかのデバイスの機能は、サードパーティアプリケーションでは使用できませんが、OEMによってプリインストールされたアプリケーションによって使用されるかもしれません。これらのパーミッションは"signatureOrSystem"権限を使用します。
Androidはユーザーのサードパーティアプリケーションとの相互作用において、権限が明確になるように努力し、それらのアプリケーションが持つ機能をユーザーへ通知します。 全てのアプリケーションのインストール前に、アプリケーションが要求している個別のパーミッションに関する簡潔なメッセージを表示します。 インストール後は、ユーザーにパーミッションの確認を再度表示することはありません。
うんたらかんたら（後で書く）
| Permissions at Application Install -- Google Maps | Permissions of an Installed Application -- gMail |
|---|---|
 |
 |
プロセスは従来のUNIXタイプのメカニズムの全てを使用したコミュニケーションが可能です。例えば、ファイルシステムに含まれるローカルソケット、またはシグナルです。しかしながら、Linuxパーミッションはまだ適用されます。
Android新しいIPCメカニズムも提供します:
- Binder : プロセスに閉じてもプロセスを跨いでも呼び出しを実行された時に高パフォーマンスになるようにデザインされた、軽量な機能ベースのリモートプロシージャコールメカニズムです。"Binder"はカスタムLinuxドライバーを使用するように実装されています。詳細はこちら : https://developer.android.com/reference/android/os/Binder.html
- Services : "Binder"を使用して直接アクセス可能なインターフェイスを提供できます。
- Intents : 何かをするための"意図"を表すシンプルなメッセージオブジェクトです。例えば、貴方のアプリケーションがWebページを表示したくなったら、Intentインスタンスを作成し、それをシステムに渡すことによって、URLを表示するための"意図"を表します。システムはいくつかのインテントの扱い方と、それを動作させる方法を知っているその他のコードの一部(この場合はブラウザ)をシステム中に配置します。Intentは、システム全体へ興味深いイベント(通知のような)をブロードキャストするために使用することもできます。詳細はこちら : https://developer.android.com/reference/android/content/Intent.html
- ContentProviders : デバイス上のデータへのアクセスを提供するデータの格納庫です。古典的な例では、ContentProviderはユーザーの連絡帳へアクセスするために使用されます。アプリケーションは他のアプリケーションがContentProviderを介して公開するデータへアクセスができ、独自のデータを公開するために独自のContentProviderを定義することもできます。詳細はこちら : https://developer.android.com/reference/android/content/ContentProvider.htm
ネットワークソケットまたは誰もが書き込めるファイルのような、その他のメカニズムを使用してIPCを実装することは可能ですが、これらはAndroidのIPCフレームワークとして推奨されています。ユーザーのデータをセキュアにし、かつセキュリティ脆弱性を導入するのを避ける最良の手法を使用することがAndroidの開発者たちには推奨されます。
コストに注意するべきAPIはユーザーまたはネットワークへのコストを発生させる可能性がある機能です。 Androidプラットフォームでは、コストに注意するべきAPIは、OSによって制御される保護されたAPIのリストに含まれています。 ユーザーは、コストに注意するべきAPIの使用を要求するサードパーティーのアプリケーションに明示的に権限を与える必要があります。
これらのAPIが含まれます:
- Telephony
- SMS/MMS
- Network/Data
- In-App Billing
- NFC Access
サードパーティアプリケーションからのSIMカードへの低レベルなアクセスは無効化されています。SIMカードメモリー上の個人情報（電話帳）へのアクセスを含む、SIMカードとの全ての通信をOSが扱います。 アプリケーションはATコマンドにもアクセスもできないようになっており、これらはRadio Interface Layer(RIL)によって占有管理されています。 RILはATコマンドのための高レベルAPIは提供していません。
Androidでは、ユーザーデータへのアクセスを提供するAPIは保護されたAPIのセットの中に含まれています。 通常の使用においては、Androidデバイスはユーザーによってインストールされたサードパーティアプリケーション内のユーザーデータを蓄積します。 その情報を共有するように作られたアプリケーションでは、サードパーティアプリケーションからデータを保護するためにAndroid OSのパーミッションチェックを使用できます。
Figure 3: Access to sensitive user data is only available through protected APIs
個人情報または電話帳やカレンダーのような個人を識別可能な情報を格納するシステムコンテンツプロバイダは、特定の権限を持つように作成されています。 その粒度はアプリケーションに提供できる情報の種類についてユーザーに明確に提示します。 インストールの間、サードパーティアプリケーションはこれらのリソースへアクセスするための権限を要求するかもしれません。 もし権限が与えられた場合、アプリケーションをインストールすることができ、インストール後はいつでも要求されたデータへアクセスできます。
初期状態では、個人情報を収集するどんなアプリケーションも、特定のアプリケーションにだけ制限されたデータを持ちます。 もしアプリケーションがIPCを介してデータを使用できるようにするのであれば、アクセスを許可するアプリケーションは、オペレーティングシステムによって強制されたIPCメカニズムにパーミッションを適用することができます。
Androidデバイスはカメラや、マイクロフォンまたはGPSのような、周囲の環境と相互に作用することをアプリケーションに許可する敏感なデータ入力デバイスをたくさん提供します。 サードパーティアプリケーションがこれらのデバイスにアクセスするためには、まずはじめにAndroid OSのパーミッションを使用して、ユーザーによって明示的に提供されたアクセスでなければなりません。 インストールの際に、ユーザーが要求しているセンサーのパーミッションを、インストーラーは名前で表示します。
もしアプリケーションがユーザーの位置を知りたい場合は、ユーザーの位置情報へアクセスするためのパーミッションが必須となります。 インストールの際に、アプリケーションがユーザーの位置情報にアクセスできるなら、インストーラーはユーザーに確認のためのプロンプトを出します ユーザーが全てのアプリケーションが位置情報へのアクセスすることを望まないのであれば、"設定"アプリケーションを起動して、"現在地情報 & セキュリティ"を開き、"無線ネットワークを使用"と"GPS機能を使用"のチェックを外すことができます(Gingerbread以前の場合)。 これによって、ユーザーのデバイス上の全てのアプリケーションに対して位置情報ベースのサービスを無効化します。
Androidは本質的に敏感で無いデータへのアクセスを制限するように努力していますが、ユーザーやユーザーの嗜好、デバイスを使用する習慣に関する特性を間接的に公開してしまうかもしれません。
初期設定では、アプリケーションがオペレーティングシステムのログ、ブラウザの履歴、電話番号、またはハードウェア／ネットワークの個体識別情報にアクセスすることはできません。 アプリケーションがインストール時にこの情報へのアクセスを要求した場合、インストーラーはアプリケーションが情報にアクセスできるかユーザーに問い合わせを行うプロンプトを表示します。 もしユーザーがアクセスを許可しなければ、そのアプリケーションがインストールされることはありません。
コード署名を行うことで、複雑なインターフェイスとパーミッションの作成をせずに、アプリケーションの作者の特定およびそのアプリケーションを更新することを開発者に許可します。 全てのAndroidプラットフォーム上で動作するアプリケーションは、開発者による署名が必須です。 署名されること無しにインストールされようとするアプリケーションは、Google PlayまたはAndroidデバイス上のパッケージインストーラーによって拒絶されます。
うんたらかんたら（後で書く）
Androidプラットフォームは、コンテンツに紐付いたライセンス上の制約に従って権利保護がなされたコンテンツを管理するアプリケーションに対して、拡張可能なDRMフレームワークを提供します。 DRMフレームワークは多くのDRMスキームをサポートします; デバイスのサポートするDRMスキームは、デバイスの製造者に任されています。
AndroidのDRMフレームワークは2つの構造的な階層によって実装されています(下図を参照してください)。
- DRM Framework APIは、Androidアプリケーションフレームワークを介してアプリケーションに公開されており、標準的なアプリケーションではDalvik VMを通して実行されます。
- ネイティブコードのDRM Managerは、DRMフレームワークを実装し、著作権管理と複数のDRMスキームのための復号を操作するためのDRM Plug-ins（エージェント）のためのインターフェイスを公開します。
Figure 4: Architecture of Digital Rights Management on Android platform
Androidは、セキュリティと様々な目的に関連した機能の両方のためのシステムアップデートを提供します。
ほとんどのAndroidデバイスでは、更新を行うための2つの方法が存在しています。ひとつはover-the-air(OTA)で、もう一つはside-loadedという方法です。 OTAアップデートは所定の期間が過ぎたものに配信するか、または一度に全てのデバイスに配信させることができ、OEMとキャリアの両者またはどちらかが、更新を配信する方法を決定します。 side-loadedアップデートはzipファイルとしてユーザーのローカルデスクトップマシンや、携帯電話に直接ダウンロードすることができ、セントラルロケーション（訳注：おそらく更新を集中的に配布する任意のURLやWebサイトのこと）から提供されます。 一度更新がコピーされるか、デバイス上のSDカードにダウンロードされると、Androidは更新を認識し、更新の整合性と信頼性を検証し、デバイスを自動的に更新します。
危険な脆弱性が内部で発見されるか、GoogleまたはAndroid Open Source Projectに責任を持って報告された場合、Androidセキュリティチームは以下の手続きを開始します。
- Androidチームは、問題に対するNDAに署名した企業に通知を行い、解決策を議論し始めます。
- コードの担当者が修正を開始します。
- Androidチームは、Androidに関連したセキュリティ上の問題を修正します。
- パッチができたら、NDA締結企業に修正を提供します。
- Androidチームは、Android Open Source Projectでパッチを公開します。
- OEMまたはキャリアは顧客にアップデートを配信します。
セキュリティ上の問題の修正が提供される前に、ユーザを危険にさらしてしまわないことを保証するためにNDAが必要です。 多くのOHA(訳注:おそらくOpen Handset Allianceの略)のメンバーはブートローダーやWiFiドライバー、無線のようなAndroidのデバイス上でコードを動かしています。 一度これらのOHAメンバーのコード中のセキュリティ上の問題がAndroidセキュリティチームに通知されると、当面の問題と同様の問題に対する修正を早期に発見すべく、OHAメンバーたちと相談します。しかしながら、欠陥のあるコードを書いたOHAメンバーが、問題の修正に対する最終的な責任を持ちます。
危険な脆弱性が誰も責任を待たない形で公開されている(例えば、警告も無しに公開されたフォーラムに投稿されているかもしれない)場合、GoogleとAndroid Open Source Projectの両方またはどちらかが、可能な限り早くパッチを作成します。 パッチがテストされ、適用する準備ができると、一般（とパートナー）に提供されます。
Google I/O 2011の場で、巨大なOHAパートナーの多くが初出荷後から18ヶ月間はデバイスへの更新を提供することを約束しました。 これは、Androidの最新機能だけでなくセキュリティアップデートもユーザーに提供します。
全ての開発者、Androidユーザー、またはセキュリティ研究者は、潜在的なセキュリティ上の問題について、security@android.com 宛てにEメールを送信することで、Androidセキュリティチームに通知することができます。 もし希望があれば、AndroidセキュリティチームのPGPキーを使用した暗号化を行って連絡を行うことができます : https://developer.android.com/security_at_android_dot_com.txt
Android Open Source Projectに関する情報 : https://source.android.com
Androidアプリケーション開発者のための情報 : https://developer.android.com
Androidセキュリティチームの連絡先 : security@android.com
Android Open Sourceと開発者のためのサイト全体を通したセキュリティ情報 : https://developer.android.com/guide/topics/security/security.html
開発者のためのセキュリティに関するFAQ : https://developer.android.com/resources/faq/security.html
Androidのセキュリティに関する議論のためのコミュニティリソース : https://groups.google.com/forum/?fromgroups#!forum/android-security-discuss