Android 6.0 以降では、Android アプリの権限モデルは、権限をユーザーにとって理解しやすく、便利で、安全なものにするように設計されています。このモデルは、危険な権限（影響を受ける権限をご覧ください）を必要とする Android アプリを、インストール時の権限モデルから実行時の権限モデルに移行しました。
- インストール時の権限
（Android 5.1 以前）ユーザーは、アプリをインストールまたはアップデートする際に危険な権限を付与します。デバイス メーカーと携帯通信会社は、ユーザーに通知せず、あらかじめ付与された権限でアプリをプリインストールできます。
- 実行時の権限
（Android 6.0～9）ユーザーは、アプリの実行中に危険な権限を付与します。権限がリクエストされるタイミング（アプリの起動時やユーザーが特定の機能にアクセスしたときなど）はアプリによって異なりますが、ユーザーは特定の権限グループに対するアプリのアクセスを許可または拒否します。OEM / 携帯通信会社はアプリをプリインストールできますが、例外処理を行わないと権限を付与できません（例外の作成をご覧ください）。
（Android 10）透明性が増し、操作の認識（AR）を実行時の権限として持つアプリを管理できるようになりました。実行時の権限ダイアログによって、ユーザーは権限を常に許可、使用中に許可、または拒否するように求められます。Android 10 への OS アップグレードでは、アプリに与えられた権限は保持されますが、ユーザーは [設定] でこれを変更できます。
実行時の権限は、アプリがユーザーの同意なしにプライベート データにアクセスすることを防ぎます。また、アプリが求めている、または付与されているタイプの権限に対する、追加のコンテキストと公開設定を提供します。実行時モデルは、アプリがリクエストした権限を必要とする理由をユーザーが理解できるようにデベロッパーを支援し、透明性を高めてユーザーが許可または拒否の判断を適切に行えるようにします。
影響を受ける権限
Android 6.0 以降では、危険な権限について実行時の権限モデルを使用する必要があります。危険な権限とは、リクエスト元のアプリがプライベート ユーザーデータにアクセスできるようにする、またはデバイスを管理できるようにする、リスクの高い権限（READ_CALENDAR など）のことです。これはユーザーに悪影響を及ぼすおそれがあります。危険な権限のリストを表示するには、次のコマンドを実行します。
adb shell pm list permissions -g -d
Android 6.0 以降では、標準の権限の動作は変更されません。これらはすべて、標準、システム、署名の権限を含む、危険ではない権限です。標準の権限とは、リスクの低い権限（SET_WALLPAPER など）のことです。他のアプリ、システム、またはユーザーに対するリスクを最小限に抑えながら、リクエスト元のアプリに、分離されたアプリレベルの機能へのアクセスを許可します。Android 5.1 以前のリリースと同様に、システムはインストール時に標準の権限をリクエスト元のアプリに自動的に付与します。ユーザーに承認を求めることはありません。権限の詳細については、<permission> 要素のドキュメントをご覧ください。
Android 10 のハード制限とソフト制限
危険な権限だけでなく、権限には、ハード制限またはソフト制限があります。いずれの場合も、制限付き権限は許可リストに登録されている必要があります。許可リストに登録されていないハード制限は、許可リストに登録されていないソフト制限とは動作が異なります。
- （ハード制限）許可リストに登録されていない権限をアプリに付与できません。
- （ソフト制限）許可リストに登録されていないアプリは、リクエストした特定の権限に基づいて動作します。この動作は、リクエストされた権限に関する公開ドキュメントに記載されています。
アプリをインストールする際、インストーラ（Google Play ストアなど）で、アプリの制限付き権限を許可リストに登録しないように選択できます。権限はプラットフォームによって制限され、アプリがプラットフォーム ポリシーごとの特別な条件を満たしている場合にのみ付与されます。ハード制限付きの権限タイプの例には、SMS と通話履歴の権限があります。
許可リストへの登録は、インストール中と、次の場合に行われます。
- Android 9 から 10 へのアップグレードの際、アプリがすでにインストールされている。
- 権限があらかじめ付与されているか、アプリがプリインストールされている。
- 権限を許可リストに登録するようにすでに定義されている役割に、権限が必要である。
- インストーラ（Google Play ストアなど）が権限を許可リスト登録対象としてマークしている。
ユーザーは、権限を手動で許可リストに登録することはできません。
要件
実行時の権限モデルは、プリインストール アプリとセットアップ プロセスの一環としてデバイスに配信されるアプリを含む、すべてのアプリに適用されます。アプリのソフトウェア要件は次のとおりです。
- 実行時の権限モデルは、Android 6.0 以降を搭載しているすべてのデバイスで一貫している必要があります。これは、Android 互換性テストスイート（CTS）のテストによって適用されます。
- アプリは、実行時にアプリの権限を付与するようにユーザーに求める必要があります。詳しくはアプリを更新するをご覧ください。デバイスの想定される動作に不可欠な基本機能を提供するデフォルトのアプリとハンドラには、制限付きで例外が認められることがあります（たとえば、
ACTION_CALLを処理するデバイスのデフォルトの電話アプリには、電話へのアクセス権限があります）。詳細については、例外の作成をご覧ください。 - 危険な権限を持つプリロードされたアプリは、API レベル 23 をターゲットとし、実行時の権限モデルを維持する必要があります。つまり、アプリのインストール時の UI フローは PermissionController の AOSP 実装から逸脱してはならず、ユーザーはプリインストールされているアプリの危険な権限を取り消すことができます。
- ヘッドレス アプリはアクティビティを使用して、権限をリクエストするか、必要な権限を持つ別のアプリと UID を共有する必要があります。詳しくはヘッドレス アプリをご覧ください。
権限の移行
Android 5.x でアプリに付与された権限は、Android 6.0 以降にアップデートしても引き続き付与されますが、ユーザーはいつでも権限を取り消すことができます。
Android 9 から 10 へのアップデートでは、ハード制限付きの権限がすべて許可リストに登録されます。フォアグラウンド / バックグラウンド分割権限の実装の詳細については、バックグラウンド位置情報へのアクセス権をリクエストするで始まる Android 10 のプライバシーに関する変更点をご覧ください。
統合
Android 6.0 以降のアプリの実行時の権限モデルを統合する場合は、新しいモデルで動作するように、プリインストールされているアプリをアップデートする必要があります。コア機能のデフォルトのハンドラ / プロバイダであるアプリの例外の定義、カスタム権限の定義、PermissionController アプリで使用されるテーマのカスタマイズもできます。
アプリを更新する
システム イメージ上のアプリとプリインストールされているアプリには、権限は自動的には付与されません。プリインストールされているアプリのデベロッパー（OEM、携帯通信会社、サードパーティ）と協力し、デベロッパー ガイドラインを使用して、アプリに必要な変更を行うことをおすすめします。特に、ユーザーが権限を取り消したときにクラッシュや他の問題が発生しないように、プリインストールされているアプリを変更する必要があります。
プリロード アプリ
Android 9 以前では、危険な権限を使用するプリロード アプリは API レベル 23 以降をターゲットとし、Android 6.0 以降の AOSP 権限モデルを維持する必要があります。たとえば、アプリのインストール時の UI フローは、PermissionController の AOSP 実装から逸脱してはなりません。ユーザーは、プリインストールされているアプリの危険な権限を取り消すこともできます。
Android 6.0～9 では、インストール フロー中にいくつかの権限が付与されます。ただし Android 10 以降では、インストール フロー（Package
Installer アプリで実施）は権限の付与（Permission Controller アプリ）とは別の機能です。
ヘッドレス アプリ
権限をリクエストできるのは、アクティビティのみです。サービスは権限を直接リクエストできません。
- Android 5.1 以前では、ヘッドレス アプリは、インストールされたとき、またはアクティビティを使用せずにプリインストールされている場合、権限をリクエストできます。
- Android 6.0 以降では、ヘッドレス アプリは次のいずれかの方法で権限をリクエストする必要があります。
- アクティビティを追加して権限をリクエストする（推奨）。
- 必要な権限を持つ別のアプリと UID を共有する。この方法は、プラットフォームで複数の APK を単一のアプリとして処理する必要がある場合にのみ使用します。
コンテキストと関係なく表示される権限リクエストでユーザーを混乱させないようにすることが目的です。
PackageInstaller UI をカスタマイズする
必要に応じて、PackageInstaller で使用されるデフォルトのデバイステーマ（Theme.DeviceDefault.Settings と Theme.DeviceDefault.Light.Dialog.NoActionBar）をアップデートすることで、権限 UI テーマをカスタマイズできます。ただし、アプリ デベロッパーにとっては一貫性が重要なため、Permissions UI の配置、位置、ルールはカスタマイズできません。
別の言語の文字列を含めるには、文字列を AOSP に提供します。
例外を作成する
コア OS 機能のデフォルトのハンドラまたはプロバイダであるアプリには、PackageManager の DefaultPermissionGrantPolicy.java クラスを使用して権限を事前に付与できます。例:
ACTION_CALL (Dialer) Default Phone, Contacts, SMS, Microphone
SMS_DELIVER_ACTION (SMS/MMS) Default Phone, Contacts, SMS
カスタムの権限を定義する
カスタム権限とグループを標準または危険として定義し、Android 5.x 以前のリリースと同様に、OEM / 携帯通信会社固有の権限を既存の権限グループに追加できます。
Android 6.0 以降では、危険な権限を新たに追加する場合、他の危険な権限と同様に処理する必要があります（アプリの実行時にリクエストされ、ユーザーによって取り消し可能）。具体的には次のとおりです。
- 現在のグループに新しい権限を追加できますが、危険な権限と危険な権限グループの AOSP マッピングを変更することはできません（つまり、グループから権限を削除して別のグループに割り当てることはできません）。
- デバイスにインストールされているアプリに新しい権限グループを追加できますが、プラットフォーム マニフェストに新しい権限グループを追加することはできません。
権限をテストする
Android には、個々の権限が適切なグループにマッピングされていることを検証する互換性テストスイート（CTS）テストが含まれています。Android 6.0 以降の CTS 互換性には、これらのテストに合格することが必須です。
権限を取り消す
Android 13 以降では、Context.revokeSelfPermissionsOnKill() を使用して独自に付与された実行時の権限を取り消すことができます。取り消しは非同期で行われ、ユーザーを中断することなく安全に実行できるときにトリガーされます。取り消しがトリガーされると、呼び出し元の UID で実行されているすべてのプロセスが強制終了されます。
重要なのは、単一の権限の取り消しは、グループごとに権限を処理する設定 UI には反映されない可能性があるということです。通常、権限グループは、そのグループ内の少なくとも 1 つの権限が付与されている限り、付与されていると表示されます。ユーザーが設定の取り消しを確実に確認できるようにする必要がある場合は、権限グループ内のすべての権限を取り消すことが重要です。特定のグループに属する権限を確認するには、PackageManager.getGroupOfPlatformPermission と PackageManager.getPlatformPermissionsForGroup を使用します。
システムがリクエストされた権限を取り消すときに、対応するフォアグラウンド権限がまだ付与されていない場合は、対応するバックグラウンド権限も取り消されます。
プロセスがフォアグラウンドに存在する限り取り消しはトリガーされませんが、たとえば、System.exit() を使用して現在の uid で実行されているすべてのプロセスを手動で強制終了した場合も、すぐにトリガーできます。ただし、トリガーするタイミングはシステムが決定できるようにすることをおすすめします。
権限の取り消しが有効になったら再度リクエストすることが可能で、ユーザーはリクエストを許可または拒否するよう求められます。以前にユーザーが拒否した権限をリクエストすることはできません。現在保持している権限が不要になった場合は取り消すことをおすすめしますが、取り消しが有効になるまでユーザーに取り消しを通知しないように注意してください。