Android では、ユーザーに最新技術を提供することも重視されていますが、最優先されているのはユーザーのセキュリティとプライバシーです。
このページで説明しているベスト プラクティスの一部は、クイック リファレンスにも掲載されています。
権限に注意する
透明性を高め、アプリ体験をユーザーが管理できるようにすることで、ユーザーとの信頼関係を構築します。
機能に必要な最小限の権限をリクエストします。アプリに大きな変更を加えるときは必ずリクエスト対象の権限を見直し、その権限がアプリの機能で引き続き必要であることを確認します。
- Android の新しいバージョンでは、権限を必要とせずプライバシーに配慮した方法でデータにアクセス可能になる場合も多くあります。詳しくは、アプリで権限を宣言する必要性を検討するをご覧ください。
- アプリを Google Play で配信している場合、アプリの権限を拒否したユーザーの割合が Android Vitals に表示されます。このデータを使用して、必要な権限が拒否されがちな機能の設計を見直します。
推奨されるフローに沿って、アプリの機能に権限が必要な理由を説明します。権限のリクエストは、権限が必要であることをユーザーにはっきりと示すために、アプリの起動時ではなく、権限が必要なときに行います。
ユーザーまたはシステムが権限を複数回拒否する場合があります。Android はユーザーのその選択を尊重し、同じアプリからの権限リクエストを無視します。
ユーザーが権限を拒否するか取り消した場合は、グレースフル デグラデーションを行います。たとえば、ユーザーがマイクの権限を付与していない場合、アプリの音声入力機能を無効にできます。
アプリを更新するときは、アプリで不要になった実行時の権限に対してアプリのアクセス権を削除します。
危険な権限で保護されているデータにアクセスがあった場合、ユーザーとしては、危険な権限を必要とする SDK やライブラリのあるアプリがそのようなデータにアクセスしたと考えるのが自然です。SDK が必要とする権限とその理由を理解しておいてください。
- Android 11（API レベル 30）でアプリをテストする場合は、データアクセスの監査を使用して、自身のコードとサードパーティ ライブラリのコードで、プライベート データがアクセスされている場所を探します。
位置情報の使用を最小限に抑える
アプリが位置情報なしでもユースケースに対応できる場合は、位置情報の利用許可をリクエストしないでください。位置情報にアクセスする権限をアプリでリクエストする場合、ユーザーが情報に基づいて判断できるようにします。
- アプリで位置情報を収集する必要がある場合は、ユーザーに特定のメリットを提供するためにアプリでどのように位置情報を使用するかを説明します。
- アプリが Bluetooth または Wi-Fi 経由でユーザーのデバイスを近くのデバイスとペア設定する必要がある場合は、位置情報の利用許可を必要としないコンパニオン デバイス マネージャーを使用します。
- アプリが必要とする位置情報の粒度レベルを確認します。位置情報関連のほとんどのユースケースでは、おおよその位置情報へのアクセスで十分です。
- アプリがユーザーに表示されている間に位置情報にアクセスします。こうすることで、アプリが位置情報をリクエストする理由をユーザーがより正確に理解できます。
- ジオフェンスの実装など、アプリがバックグラウンドで位置情報を必要とする場合は、それがアプリのコア機能にとって不可欠なものであること、またユーザーにとってわかりやすい方法で行われることを確認します。詳しくは、バックグラウンドでの位置情報の使用に関する考慮事項についての説明をご覧ください。
- Android 10（API レベル 29）以降では、アプリの使用中もユーザーはアプリの位置情報へのアクセスを制限できます。位置情報への常時アクセス権限がない場合にグレースフル デグラデーションを行うようにアプリを設計します。
- ユーザーがアプリの UI から離れた後も、ユーザーが開始したタスクで位置情報へのアクセスを維持する必要がある場合は、アプリがバックグラウンドに移動する前にフォアグラウンド サービスを開始します。これは、Android のライフサイクル コールバック（
onPause()など）で行えます。 - フォアグラウンド サービスはバックグラウンドから開始しないでください。代わりに、アプリを通知から起動して、アプリの UI が表示されたときに位置情報コードを実行することを検討してください。
データを安全に処理する
注: センシティブ データの定義について詳しくは、Google Play デベロッパー ポリシー センターのユーザーデータの記事をご覧ください。
センシティブ データの処理方法における透明性と安全性を確保します。
- アプリがセンシティブ データを収集、使用、共有するタイミングと理由をユーザーに知らせます。
- 可能であれば、対象範囲別ストレージ モデルを使用します。詳しくは、アプリのユースケースに基づいて対象範囲別ストレージに移行する方法についての説明をご覧ください。
- 常に安全なネットワーク接続を使用します。アプリの保存データに対しては、Android に組み込まれている認証情報暗号化を使用します。転送中のデータについては、機密性に関係なく、すべてのデータ転送に SSL の後継となる TLS を使用します。
- センシティブ データを含むファイルは、内部ストレージ内のアプリ専用ディレクトリに配置します。
- Android 10（API レベル 29）では、アプリにのみ関連するファイルは、外部ストレージのアプリ固有のディレクトリに保存します。対象範囲別ストレージの詳細をご確認ください。
- センシティブ データを別のアプリに渡す必要がある場合は、明示的インテントを使用します。他のアプリのアクセスをさらに制限するには、1 回限りのデータアクセス権限を付与します。
- アプリがフォアグラウンドで実行されている場合でも、マイクやカメラからキャプチャしているリアルタイム通知を表示します。Android 9（API レベル 28）以降では、アプリがバックグラウンドで実行されている場合、マイクやカメラへのアクセスが許可されません。
- logcat メッセージやアプリのログファイルにセンシティブ データを含めないでください。ユーザーデータの処理方法の詳細をご確認ください。
Jetpack には、アプリのデータをより安全に保つためのライブラリが用意されています。詳しくは、Jetpack セキュリティ ライブラリと Jetpack 設定ライブラリの使用方法に関するガイドをご覧ください。
リセット可能な識別子を使用する
ユーザーのプライバシーを尊重し、リセット可能な識別子を使用します。詳しくは、一意の識別子に関するベスト プラクティスをご覧ください。
- これらの識別子は永続的であるため、IMEI またはデバイスのシリアル番号にはアクセスしないでください。Android 10（API レベル 29）以降をターゲットとするアプリでこれらの識別子にアクセスしようとすると、
SecurityExceptionが発生します。 - ユーザー プロファイル作成や広告のユースケースでは広告 ID のみを使用します。Google Play のアプリの場合、これは必須条件です。カスタマイズを行う場合、広告トラッキングに関するユーザー設定を常に考慮します。
- ほとんどの非広告のユースケースでは、非公開環境に保存されているグローバルに一意の ID（GUID）を使用します（GUID はアプリ別の ID です）。
- ユーザーがアカウントにログインしなくてもデベロッパー所有のアプリ間で状態を共有できるようにするには、Secure Settings Android ID（SSAID）を使用します。ログアウトしたユーザーの設定をアプリ間でトラッキングする方法の詳細をご確認ください。