権限の概要

権限の目的は、Android ユーザーのプライバシーを保護することです。Android アプリは、ユーザーの機密データ（連絡先や SMS）と特定のシステム機能（カメラやインターネット）にアクセスする権限をリクエストする必要があります。機能に応じて、システムは権限を自動的に付与するか、またはユーザーにリクエストの承認を求めます。

Android セキュリティアーキテクチャの設計においては、他のアプリ、オペレーティングシステム、またはユーザーに悪影響を及ぼしかねないオペレーションの実行権限を、いかなるアプリにもデフォルトで付与しないよう徹底されています。そうしたオペレーションとしては、ユーザーの個人情報（連絡先やメールアドレス）の読み取りまたは書き込み、他のアプリのファイルの読み取りまたは書き込み、ネットワークへのアクセス、デバイスのスリープモードへの移行の抑止などがあります。

このページでは、Android の権限の仕組みの概要を示します。具体的には、ユーザーに対する権限の提示、インストール時の権限リクエストと実行時の権限リクエストの違い、権限が適用される仕組み、権限の種類と権限グループなどについて説明します。アプリの権限を使用するための入門ガイドのみを参照したい場合は、アプリの権限をリクエストするをご覧ください。

権限の承認

アプリでは、<uses-permission> タグをアプリマニフェストに含めることにより、必要な権限を公開する必要があります。たとえば、SMS メッセージを送信する必要があるアプリの場合、マニフェストに次の行があります。

<manifest xmlns:android="http://schemas.android.com/apk/res/android"
          package="com.example.snazzyapp">

    <uses-permission android:name="android.permission.SEND_SMS"/>

    <application ...>
        ...
    </application>
</manifest>

アプリのマニフェストに記載された権限が標準の権限（つまり、ユーザーのプライバシーまたはデバイスのオペレーションにとってほとんど危険がない権限）である場合、システムはその権限を自動的にアプリに付与します。

上記の SEND_SMS 権限のような危険な権限（つまり、ユーザーのプライバシーまたはデバイスの通常のオペレーションに影響を及ぼす可能性がある権限）がアプリのマニフェストに記載されている場合、ユーザーがそれらの権限を付与するには、明示的に同意する必要があります。

標準の権限と危険な権限の詳細については、保護レベルをご覧ください。

危険な権限をリクエストするプロンプト

ユーザーの同意が必要なのは、危険な権限のみです。Android がユーザーに危険な権限の付与をリクエストする方法は、ユーザーのデバイスで実行されている Android のバージョンと、アプリがターゲットとするシステムのバージョンによって異なります。

実行時のリクエスト（Android 6.0 以上）

デバイスで Android 6.0（API レベル 23）以上を実行しており、かつ、アプリの targetSdkVersion が 23 以上である場合、ユーザーはインストール時にアプリの権限について通知されません。アプリは、危険な権限の付与を実行時にユーザーにリクエストする必要があります。アプリが権限をリクエストすると、アプリがアクセスしようとしている権限グループを示すシステムダイアログ（図 1 の左を参照）がユーザーに表示されます。ダイアログには、[許可しない] ボタンと [許可] ボタンがあります。

ユーザーが権限リクエストを拒否した場合、アプリが次に権限をリクエストしたとき、ダイアログにチェックボックスが表示されます。チェックボックスをオンにすると、それ以降ユーザーは権限の付与をリクエストされなくなります（図 1 の右を参照）。

図 1. 初回の権限ダイアログ（左）と、以降のリクエストをオフにできる 2 回目の権限ダイアログ（右）

ユーザーが [次回から表示しない] チェックボックスをオンにして [許可しない] をタップすると、それ以降アプリが同じ権限をリクエストしようとしても、システムはユーザーにプロンプトを表示しません。

アプリがリクエストした権限をユーザーがアプリに付与したとしても、アプリが常に権限を保持できるとは限りません。ユーザーは、システム設定で権限を個別に有効または無効にすることもできるからです。アプリ側では、実行時エラー（SecurityException）を防ぐため、実行時に必ず権限をチェックして、権限が無効になっている場合はリクエストする必要があります。

実行時の権限リクエストの処理方法の詳細については、アプリの権限をリクエストするをご覧ください。

インストール時のリクエスト（Android 5.1.1 以下）

デバイスで Android 5.1.1（API レベル 22）以下を実行している場合、または Android の任意のバージョンを実行していてアプリの targetSdkVersion が 22 以下である場合、ユーザーはインストール時にすべての危険な権限をアプリに付与するかどうかを自動的に尋ねられます（図 2 を参照）。

図 2. インストール時の権限ダイアログ

ユーザーが [同意する] をクリックすると、アプリがリクエストするすべての権限が付与されます。ユーザーが権限リクエストを拒否すると、システムはアプリのインストールをキャンセルします。

アプリのアップデートで追加の権限が必要になる場合、ユーザーはアプリをアップデートする前に、追加の新しい権限を承認するかどうかを尋ねられます。

権限をリクエストする際に推奨されるユーザーエクスペリエンスパターンの概要については、アプリの権限に関するおすすめの設定をご覧ください。

ユーザーが付与する権限をチェックする方法とリクエストする方法については、アプリの権限をリクエストするをご覧ください。

ユーザーの機密情報へのアクセスをリクエストするプロンプト

アプリによっては、通話履歴や SMS メッセージに関するユーザーの機密情報にアクセスする必要があります。通話履歴や SMS メッセージに固有の権限をリクエストするアプリを Play ストアに公開する場合は、実行時の権限をリクエストする前に、アプリを中核的システム機能のデフォルトハンドラとして設定することをユーザーに求める必要があります。

デフォルトハンドラの詳細（デフォルトハンドラのプロンプトをユーザーに表示する方法など）については、デフォルトハンドラでのみ使用される権限のガイドをご覧ください。

オプションのハードウェア機能の権限

一部のハードウェア機能（Bluetooth やカメラ）にアクセスするには、アプリの権限が必要です。ただし、実際には、こうしたハードウェア機能をすべての Android デバイスが備えているわけではありません。したがって、アプリが CAMERA 権限をリクエストする場合、マニフェストに <uses-feature> タグも挿入して、この機能が実際に必要かどうかを宣言することが重要です。次に例を示します。

<uses-feature android:name="android.hardware.camera" android:required="false" />

この機能に対して android:required="false" を宣言すると、その機能を持たないデバイスにアプリをインストールすることが Google Play によって許可されます。次に、PackageManager.hasSystemFeature() を呼び出して、実行時にデバイスがその機能を備えているかどうかをチェックし、備えていなければその機能を無効にする必要があります。

<uses-feature> タグを指定しなかった場合、Google Play は該当する権限をアプリがリクエストしていることを確認すると、アプリがこの機能を必要としていると見なします。したがって、<uses-feature> タグで android:required="true" を宣言した場合と同様に、Google Play はその機能を持たないデバイスからアプリを除外します。

詳細については、Google Play と機能ベースのフィルタリングをご覧ください。

1 回だけのアクセス許可

Android 11（API レベル 30）以降では、アプリが位置情報、マイク、またはカメラに関連する権限をリクエストするたびに、ユユーザー向けの権限ダイアログに [今回のみ] というオプションが表示されます。ユーザーがダイアログでこのオプションを選択した場合、アプリには一時的な「1 回だけのアクセス許可」が付与されます。

アプリの動作とユーザーの操作に応じて、一定期間アプリは該当するデータにアクセスできます。

アプリのアクティビティが表示されている間、アプリはデータにアクセスできます。
ユーザーがアプリをバックグラウンドに移行した場合、アプリは短時間だけ引き続きデータにアクセスできます。
アクティビティが表示されている間にフォアグラウンドサービスを起動した場合、ユーザーがアプリをバックグラウンドに移動しても、そのフォアグラウンドサービスが停止するまで、アプリは引き続きそのデータにアクセスできます。
ユーザーがシステム設定などで 1 回だけのアクセス許可を取り消した場合、アプリはフォアグラウンドサービスを開始したかどうかにかかわらず、データにアクセスできなくなります。他の権限と同様に、ユーザーがアプリの 1 回だけのアクセス許可を取り消すと、アプリのプロセスは終了します。

ユーザーが次にアプリを開いて、アプリ内の機能が位置情報、マイク、またはカメラへのアクセスをリクエストすると、ユーザーに再度権限の付与が求められます。

権限の適用

権限の目的はシステム機能を要求することだけではありません。アプリが提供するサービスは、カスタム権限を適用して、サービスを使用できる主体を制限できます。カスタム権限の宣言の詳細については、カスタムアプリ権限を定義するをご覧ください。

アクティビティ権限の適用

android:permission 属性を使用してマニフェストの <activity> タグに適用される権限により、その Activity を開始できる主体が制限されます。権限は、Context.startActivity() と Activity.startActivityForResult() でチェックされます。呼び出し元に必要な権限がない場合は、呼び出しで SecurityException がスローされます。

サービス権限の適用

android:permission 属性を使用してマニフェストの <service> タグに適用される権限により、関連する Service を開始またはバインドできる主体が制限されます。権限は、Context.startService()、Context.stopService()、Context.bindService() でチェックされます。呼び出し元に必要な権限がない場合は、呼び出しで SecurityException がスローされます。

ブロードキャスト権限の適用

android:permission 属性を使用して <receiver> タグに適用される権限により、関連する BroadcastReceiver にブロードキャストを送信できる主体が制限されます。権限は、Context.sendBroadcast() が返された後、送信されたブロードキャストを指定されたレシーバにシステムが配信しようとしたときにチェックされます。したがって、権限エラーが発生しても呼び出し元に例外はスローされません。単に Intent が配信されないだけです。

同様に、Context.registerReceiver() に権限を与えることにより、プログラムで登録されたレシーバにブロードキャストを送信できる主体を制限できます。逆に、Context.sendBroadcast() を呼び出す際に権限を与えて、ブロードキャストを受信できるブロードキャストレシーバを制限することもできます。

ブロードキャストの受信側と送信側の両方で権限が必要とされる場合があります。その場合、関連するターゲットにインテントが配信されるためには、両方の権限チェックに合格する必要があります。詳細については、権限の設定によるブロードキャストの制限をご覧ください。

コンテンツプロバイダ権限の適用

android:permission 属性を使用して <provider> タグに適用される権限により、ContentProvider 内のデータにアクセスできる主体が制限されます（コンテンツプロバイダでは、後述の URI 権限と呼ばれる追加の重要なセキュリティ機能を使用できます）。他のコンポーネントと異なり、2 つの権限属性を個別に設定できます。android:readPermission はプロバイダから読み取りを行う主体を制限し、android:writePermission は書き込みを行う主体を制限します。プロバイダが読み取りと書き込みの両方の権限で保護されている場合、書き込み権限だけを持っていても、プロバイダの情報を読み取ることはできません。

権限がチェックされるのは、最初にプロバイダを取得するとき（いずれかの権限を持っていないと SecurityException がスローされます）と、プロバイダでオペレーションを実行するときです。ContentResolver.query() を使用するには読み取り権限が必要です。ContentResolver.insert()、ContentResolver.update()、ContentResolver.delete() を使用するには書き込み権限が必要です。いずれの場合も、必要な権限を持っていなければ、呼び出しで SecurityException がスローされます。

URI 権限

これまでに説明した標準的な権限システムは、コンテンツプロバイダで使用するには不十分であることがままあります。コンテンツプロバイダは読み取りおよび書き込み権限で自身を保護する必要がありますが、一方、コンテンツプロバイダの直接クライアントは、特定の URI を他のアプリに渡して、それらのアプリが URI を処理できるようにしなくてはなりません。

その典型的な例は、メールアプリの添付ファイルです。メールはユーザーの機密データであるため、メールへのアクセスは権限で保護する必要があります。しかし、画像添付ファイルの URI がイメージビューアに渡されても、イメージビューアにはすべてのメールにアクセスする権限を保持する理由がないため、添付ファイルを開く権限がありません。

この問題の解決策は、URI ごとの権限です。アクティビティを開始するときまたは結果をアクティビティに返すときに、呼び出し元は Intent.FLAG_GRANT_READ_URI_PERMISSION と Intent.FLAG_GRANT_WRITE_URI_PERMISSION の両方またはいずれかを設定できます。これにより、インテントに対応するコンテンツプロバイダ内のデータにアクセスする権限の有無にかかわらず、インテント内の特定のデータの URI にアクセスする権限が受信側アクティビティに付与されます。

この仕組みによって、ユーザー操作（添付ファイルの開封や連絡先リストからの選択など）に対し臨機応変にきめ細かい権限を付与できる一般的な機能スタイルモデルが利用可能になります。この仕組みは、アプリが要求する権限を、アプリの動作に直接関連するものだけに制限するうえで非常に重要です。

アプリ内で他のアプリが実行を請け負う最も安全な実装を構築するには、この方法できめ細かい権限を使用し、android:grantUriPermissions 属性または <grant-uri-permissions> タグでアプリが権限をサポートすることを宣言する必要があります。

詳細については、Context.grantUriPermission()、Context.revokeUriPermission()、Context.checkUriPermission() メソッドを参照してください。

その他の権限の適用

サービスを呼び出すとき、任意のきめ細かい権限を適用できます。これは Context.checkCallingPermission() メソッドで行います。目的の権限文字列を指定して呼び出しを行うと、実行された呼び出しプロセスに権限が付与されたかどうかを示す整数値が返されます。この方法は、別のプロセスからの呼び出しを実行する場合にのみ使用できることに注意してください。このような呼び出しは、一般的にはサービスから発行された IDL インターフェースを介して行いますが、別のプロセスに固有の他の方法で行うこともあります。

有用な権限のチェック方法は他にもいくつかあります。別のプロセスのプロセス ID（PID）がある場合は、Context.checkPermission() メソッドを使用して、その PID に対する権限を確認できます。別のアプリのパッケージ名がある場合は、PackageManager.checkPermission() メソッドを使用して、そのパッケージに特定の権限が付与されているかどうかを確認できます。

使用していないアプリの権限を自動リセットする

Android 11（API レベル 30）以上をターゲットとするアプリが数か月間使用されていない場合、システムはユーザーデータを保護するために、ユーザーがアプリに付与した機密情報に関する実行時の権限を自動的にリセットします。このアクションは、ユーザーがシステム設定で権限を表示してアプリのアクセスレベルを [拒否] に変更するのと同じ効果があります。

アプリが実行時に権限をリクエストするためのおすすめの方法に従っている場合、アプリに変更を加える必要はありません。

自動リセットを無効にするようにユーザーにリクエストする

必要に応じて、システムがアプリの権限をリセットしないように設定することをユーザーに依頼します。これは、以下のユースケースのように、ユーザーがアプリを操作しなくても主にバックグラウンドで動作することが前提となっている場合に役立ちます。

図 3. 特定のアプリについてユーザーが権限の自動リセットを無効化

家族の安全を確保する
データを同期する
スマートデバイスと通信する
コンパニオンデバイスとペア設定する

アプリ内のシステム設定のページにユーザーを誘導するには、Intent.ACTION_AUTO_REVOKE_PERMISSIONS インテントアクションを含むインテントを呼び出します。ユーザーはこの画面で次の手順に沿って、システムがアプリの権限をリセットしないように設定できます。

[権限] をタップすると、[アプリの権限] 設定画面が読み込まれます。
図 3 に示されているように、[アプリが使用されていない場合に権限を削除] をオフにします。

自動リセットが無効になっているかどうかを確認する

アプリで自動リセット機能が無効になっているか確認するには、isAutoRevokeWhitelisted() を呼び出します。この方法で true が返された場合、アプリの権限は自動リセットされません。

自動リセット機能をテストする

システムがアプリの権限をリセットすることを確認するには、次のようにします。

システムがアプリの権限をリセットするまでのデフォルトの時間を保持します。それにより、テスト後の復元が可能になります。
```
threshold=$(adb shell device_config get permissions \
  auto_revoke_unused_threshold_millis2)
```
システムが権限をリセットするまでの時間を短縮します。次の例では、アプリの操作を中断して 1 秒後にアプリの権限がリセットされるように変更されています。
```
adb shell device_config put permissions \
  auto_revoke_unused_threshold_millis2 1000
```
次のスニペットに示すように、自動リセットプロセスを手動で呼び出します。テストデバイスを短時間（約 45 秒間）オンにしてから、このコマンドを実行します。
```
adb shell cmd jobscheduler run -u 0 -f \
  com.google.android.permissioncontroller 2
```
アプリが自動リセットイベントを処理できることを確認します。
システムがアプリの権限を自動リセットするまでのデフォルトの時間を元に戻します。
```
adb shell device_config put permissions \
  auto_revoke_unused_threshold_millis2 $threshold
```

新しい権限を自動的に付与する

時間の経過に伴って、プラットフォームに新たな制限が追加されることがあります。たとえば、アプリが特定の API を使用するために、以前は不要だった権限をリクエストすることが必要になる場合などです。既存のアプリはそうした API に自由にアクセスできると想定しているので、Android は、新しいプラットフォームバージョンでアプリが失敗することを避けるために、アプリのマニフェストに新しい権限のリクエストを適用する（それによってアプリが権限を継承できるようにする）ことがあります。Android は、targetSdkVersion 属性に指定された値に基づいて、アプリに権限が必要かどうかを判断します。権限が追加されたバージョンよりもこの値が小さければ、Android は権限を追加します。

たとえば、共有ストレージ領域へのアクセスを制限するため、最初に API レベル 19 で READ_EXTERNAL_STORAGE 権限が適用されたとします。アプリの targetSdkVersion が 18 以下であれば、Android の新しいバージョンで、この権限がアプリに追加されます。

注意: アプリに自動的に権限が追加された場合、実際にはアプリにその権限が不要だったとしても、Google Play のアプリ情報には追加された権限が表示されます。このような状況を避けて不要なデフォルトの権限を削除するには、targetSdkVersion を常に最新の（最大の）値に更新します。各リリースで追加された権限は、Build.VERSION_CODES のドキュメントで確認できます。

保護レベル

権限はいくつかの保護レベルに分類されます。保護レベルは、実行時の権限リクエストが必要かどうかに影響します。

サードパーティのアプリに影響する保護レベルは、標準、署名、危険の 3 つです。特定の権限の保護レベルを確認するには、権限 API リファレンスのページをご覧ください。

標準の権限

標準の権限に該当するのは、アプリがアプリのサンドボックス外のデータやリソースにアクセスする必要があるが、ユーザーのプライバシーまたは他のアプリのオペレーションに影響する危険がほとんどないケースです。たとえば、タイムゾーンを設定する権限は、標準の権限です。

アプリがマニフェストで標準の権限が必要であると宣言している場合、システムはインストール時にその権限を自動的にアプリに付与します。ユーザーは標準の権限を付与するかどうかを尋ねられることはなく、標準の権限を取り消すこともできません。

署名権限

このタイプの権限については、権限の使用を要求するアプリが権限を定義しているアプリと同じ証明書で署名されている場合に限り、システムはインストール時に権限をアプリに付与します。

危険な権限

危険な権限に該当するのは、アプリがユーザーの個人情報を含むデータやリソースを要求するケースや、ユーザーが保存したデータや他のアプリのオペレーションに影響を及ぼす可能性があるケースです。たとえば、ユーザーの連絡先を読み取る機能には、危険な権限が必要です。危険な権限が必要であるとアプリが宣言した場合、ユーザーは明示的にアプリに権限を付与することを求められます。ユーザーが権限を承認しない限り、アプリはその権限に依存する機能を提供できません。

アプリが危険な権限を使用するには、実行時に権限の付与をユーザーにリクエストする必要があります。ユーザーにプロンプトを表示する方法の詳細については、危険な権限をリクエストするプロンプトをご覧ください。

特別な権限

標準の権限とも危険な権限とも異なる効果を持つ権限がいくつかあります。SYSTEM_ALERT_WINDOW と WRITE_SETTINGS は特に取扱いに注意を要するため、ほとんどのアプリでは使用を避けるべきです。

ほとんどの場合、アプリはマニフェスト内で SYSTEM_ALERT_WINDOW 権限を宣言し、かつ、ユーザーの承認をリクエストするインテントを送信する必要があります。システムはインテントに対応するために、ユーザーに対して詳細な管理画面を表示します。

Android 11（API レベル 30）以降、ACTION_MANAGE_OVERLAY_PERMISSION インテントアクションを呼び出すアプリではパッケージを指定できません。このインテントアクションを含むインテントをアプリが呼び出したとき、ユーザーはまず権限を付与するアプリまたは権限を取り消すアプリを選択することを求められます。この動作は、権限を付与する際の意識を高めることで、ユーザーの保護を強化することを目的としています。

これらの権限をリクエストする方法の詳細については、SYSTEM_ALERT_WINDOW および WRITE_SETTINGS のリファレンスの説明をご覧ください。

Android システムが提供するすべての権限は、Manifest.permission で確認できます。

権限グループ

権限は、デバイスの機能に応じて、いくつかのグループに分類されています。このシステムの下で、権限リクエストはグループレベルで処理されます。1 つの権限グループがアプリマニフェスト内の複数の権限の宣言に対応します。たとえば、SMS グループには READ_SMS 宣言と RECEIVE_SMS 宣言の両方が含まれています。権限をこのようにグループ化することにより、ユーザーは、複雑で専門的な権限リクエストに煩わされずに、十分な情報に基づいて適切な判断を下すことができます。

Android システムのすべての危険な権限は、なんらかの権限グループに属しています。権限は、保護レベルと無関係に同じ権限グループに属する場合があります。ただし、ある権限が属するグループがユーザーエクスペリエンスに影響するのは、その権限が危険な権限である場合だけです。

デバイスで Android 6.0（API レベル 23）を実行していて、アプリの targetSdkVersion が 23 以上である場合、アプリが危険な権限をリクエストしたときのシステムの動作は次のとおりです。

現在、該当する権限グループ内の権限がいずれもアプリにない場合は、アプリがアクセスしようとしている権限グループを示す権限リクエストダイアログがユーザーに表示されます。そのグループ内の具体的な権限はダイアログに表示されません。たとえば、アプリが READ_CONTACTS 権限をリクエストした場合、ダイアログには、アプリがデバイスの連絡先にアクセスする必要があることだけが示されます。ユーザーが承認した場合は、リクエストされた権限だけがアプリに付与されます。
同じ権限グループ内の別の危険な権限がすでにアプリに付与されている場合は、ユーザーへのプロンプトなしで、リクエストされた権限が直ちにアプリに付与されます。たとえば、以前 READ_CONTACTS 権限をリクエストして付与されたアプリが WRITE_CONTACTS をリクエストした場合、ユーザーに権限リクエストダイアログは表示されず、直ちにその権限がアプリに付与されます。

注意: Android SDK の将来のバージョンで、特定の権限が別のグループに移動される可能性があります。そのため、現行の権限グループの編成に基づいてアプリのロジックを作成することは避けてください。

たとえば、Android 8.1（API レベル 27）では、READ_CONTACTS は WRITE_CONTACTS と同じ権限グループに属しています。アプリが READ_CONTACTS 権限をリクエストした後で WRITE_CONTACTS 権限をリクエストした場合、システムが WRITE_CONTACTS 権限を自動的に付与すると想定しないようにしてください。

デバイスで Android 5.1（API レベル 22）以下を実行しているか、アプリの targetSdkVersion が 22 以下である場合、ユーザーはインストール時に権限を付与するかどうかを尋ねられます。この場合も、システムは、個別の権限ではなく、どの権限グループがアプリに必要かをユーザーに知らせます。たとえば、アプリが READ_CONTACTS をリクエストした場合、連絡先グループがインストールダイアログに示されます。ユーザーが承認すると、READ_CONTACTS 権限だけがアプリに付与されます。

注: ユーザーが同じ権限グループ内の別の権限をすでに付与している場合も、アプリはすべての必要な権限を明示的にリクエストする必要があります。また、権限グループの編成は、将来の Android リリースで変更される可能性があります。アプリのコードでは、同じグループに属する特定の権限のセットに依存するロジックを使用しないようにしてください。

アプリの権限を表示する

システムで現在定義されているすべての権限を表示するには、設定アプリまたはシェルコマンド adb shell pm list permissions を使用します。設定アプリにアクセスするには、[設定] > [アプリ] に移動します。アプリを選択して下にスクロールすると、アプリが使用する権限を確認できます。デベロッパーの場合は、adb の '-s' オプションを使用して、ユーザーが目にするのと同様の形式で権限を表示できます。

$ adb shell pm list permissions -s
All Permissions:

Network communication: view Wi-Fi state, create Bluetooth connections, full
internet access, view network state

Your location: access extra location provider commands, fine (GPS) location,
mock location sources for testing, coarse (network-based) location

Services that cost you money: send SMS messages, directly call phone numbers

...

また、adb の -g オプションを使用すると、エミュレータまたはテストデバイスにアプリをインストールする際に、すべての権限を自動的に付与できます。

$ adb shell install -g MyApp.apk

参考情報

アプリの権限をリクエストする: アプリの権限をリクエストするための入門ガイド。
機能要件を伴う権限: 一部の権限をリクエストしたとき、対応するハードウェアまたはソフトウェアの機能を持つデバイスにアプリが暗黙的に制限される仕組みに関する情報。
<uses-permission>: アプリに必要な権限を宣言するマニフェストタグの API リファレンス。
デバイスの互換性: さまざまなタイプのデバイスでの Android の動作、デバイスごとにアプリを最適化する方法、各種デバイスでアプリの利用を制限する方法に関する情報。
Android セキュリティの概要: Android プラットフォームのセキュリティモデルに関する詳細な説明。
"Mother, May I?" Asking for Permissions: Android Dev Summit 2015 のこの動画は、権限をリクエストする際のおすすめの方法について説明しています。
Android M Permissions: Google I/O 2015 のこの動画は、Android 6.0 で権限モデルに加えられた変更について説明しています。

アプリの権限をリクエストする