Permissionとその一覧

投稿日:  更新日:

Androidは携帯端末のOSで、スマートフォンに適しています。

スマート(Smart)とは「賢い・洗練された」といった意味を持つ形容詞です。

Androidはこの「スマート」をユーザ自身の手で育てることが出来ます。

どのように育てるのか!

それは世界中の開発者からリリースされているアプリをインストールして育てます。

より高機能なアプリ、より使い勝手の良いアプリを探してインストールすれば、あなたのスマートフォンはもっと「スマート」になるでしょう!

しかし、アプリは良心的なものばかりではありません。中には悪意を持ったアプリも存在します。

悪意を持ったアプリから、ユーザを守る仕組みの1つがPermissionです。

ここまではユーザ目線でした。

逆にアプリの開発者目線で言えば、Permissionはアプリの安全性をユーザにアピールする手段でもありあます。

今回は、このPermissionについてまとめます。

スポンサーリンク

Permissionとは

ユーザが人気のメモ帳アプリをGoogle Playからインストールしたとしましょう。

このメモ帳アプリが悪意のある開発者の登録したものであり、ユーザの通話履歴を開発者に送信する機能を持っていたとしたら、通話履歴が漏洩します。

これは重大なプライバシーの侵害です。

悪意のあるアプリケーション

そもそも、メモ帳アプリに「通話履歴を読み出す機能」や「ネットにアクセスする機能」は不要です。このアプリはメモ帳としての権限を逸脱してると言えます。

アプリの権限の逸脱

このような問題点を回避するために、アプリに対して必要最低限の機能のみを許可する仕組みがあります。

それがパーミッションシステムです。

パーミッションシステムにおいて、Permissionは「○○する機能」に紐づけられた権限のことです。

アプリがPermissionを取得していれば、アプリは「○○する機能」を実行する権限を持つことになり、「○○する機能」が利用できます。

同様な表現として…

ユーザがPermissionを許可していれば、アプリは「○○する機能」を実行する権限を持つことになり、「○○する機能」が利用できます。

そして、アプリにPermissionを許可するか(拒否するか)どうかは、ユーザが判断します。開発者の判断では無い点がポイントです。

これにより、逸脱した権限はユーザの手で排除できます。

Permissionの概要

ただし、完全にプライバシーの侵害を回避できるわけではありません。

先の例で言えば、悪意のある「メモ帳アプリ」が「IP電話アプリ」であれば、「通話履歴を読み出す機能」も「ネットにアクセスする機能」も必要になり、漏洩は防げません。

信頼に足りる開発者であるか、信頼に足りるアプリであるか、ユーザの判断が最も重要であることを忘れてはいけません。

スポンサーリンク

プロテクションレベル

Permissionは危険性の種類により分類したプロテクションレベルが設定されています。

以下はその基本タイプです。

レベル危険性取得タイミング許可⇔拒否の変更
dangerous高リスクな機能の実行アプリの機能の実行時
normal低リスクな機能の実行アプリのインストール時×
signatureアプリへ不正アクセスアプリのインストール時×
internalシステムへ不正アクセス※未確認※未確認
※許可⇔拒否の変更:インストール後の変更、Settings(設定)アプリで行う

基本タイプに加えて多くのフラグが存在しています。詳細はマニュアル(プロテクションレベル)を参照してください。

スポンサーリンク

Dangerous

高リスクな機能に分類されたPermissionです。カテゴリ毎にGroup分けされています。

以下のような種類があります。

GroupPermission許可する機能
ACTIVITY_RECOGNITIONACTIVITY_RECOGNITION身体活動の認識(活動量計で利用)
CALENDARREAD_CALENDAR予定表の読み出し
WRITE_CALENDAR予定表の書き込み
CAMERACAMERAカメラで写真・動画の撮影
CONTACTSREAD_CONTACTS連絡先の読み出し
WRITE_CONTACTS連絡先の書き込み
GET_ACCOUNTSアカウントプロフィールの取得
LOCATIONACCESS_FINE_LOCATION大まかな地理的位置情報の取得
※携帯基地局・Wi-Fiスポットデータに基づく
ACCESS_COARSE_LOCATION正確な地理的位置情報の取得
※GPSデータに基づく
ACCESS_BACKGROUND_LOCATIONバックグラウンドで位置情報の取得
MICROPHONERECORD_AUDIOマイクで音声の録音
NEARBY_DEVICES
※API32で追加
※詳細は未確認
BLUETOOTH_ADVERTISE
※API31で追加、詳細は未確認
他のBluetoothデバイスへ広告
BLUETOOTH_CONNECT
※API31で追加、詳細は未確認
他のBluetoothデバイスと通信
BLUETOOTH_SCAN
※API31で追加、詳細は未確認
他のBluetoothデバイスを捜査
PHONEREAD_PHONE_STATE電話の状態の読み出し
CALL_PHONE電話の発信
ANSWER_PHONE_CALLS電話の着信
READ_CALL_LOG通話履歴の読み出し
WRITE_CALL_LOG通話履歴の書き込み
ADD_VOICEMAILボイスメールの利用
USE_SIPSIPサービスの利用
PROCESS_OUTGOING_CALLS別の番号へ転送
SENSORSBODY_SENSORS人体センサーでヘルスデータの取得
SMSSEND_SMSSMSメッセージの送信
RECEIVE_SMSSMSメッセージの受信
READ_SMSSMSメッセージ履歴の読み出し
RECEIVE_WAP_PUSHWAPプッシュの受信
RECEIVE_MMSMMSメッセージの受信
STORAGEREAD_EXTERNAL_STORAGE外部ストレージの読み出し
WRITE_EXTERNAL_STORAGE外部ストレージへ書き込み
※Groups:android.permission-group.XXX
※Permission:android.permission.YYY
※SMS:Short Message Service、電話番号を使ったメッセージ交換
※MMS:Multimedia Message Service、キャリアメールアドレスを使ったメッセージ交換
※外部ストレージ:サンドボックス外、他のアプリからアクセス可能な領域
※SIP:IP電話の呼制御プロトコル

取得タイミングが「アプリの機能の実行時」であることから、別名「Runtime Permission」と呼ばれます。

アプリは機能を実行するタイミングで、ユーザに対してPermissionを申請します。申請が行われると、ダイアログが開かれてユーザに許可・拒否の判定を求めます。

【API23~29(例:API24)】

Permissionを申請
【API30~31(例:API31)】

Permissionを申請

Dangerous Permissionは許可・拒否の判定後も、Settings(設定)アプリにより判定の変更が可能です。※Settings⇒アプリ⇒アプリ情報⇒権限

【API23~29(例:API24)】

Permissionの判定を変更
【API30~31(例:API31)】

Permissionの判定を変更
スポンサーリンク

Normal

低リスクな機能に分類されたPermissionです。

以下のような種類があります。ただし、ここに挙げるのは一部です。

Permission許可する機能
ACCESS_NETWORK_STATEネットワーク情報へアクセス
ACCESS_WIFI_STATEWiFi情報へアクセス
BLUETOOTHペアリング済みBluetoothデバイスへ接続 ※API≦30で利用
BLUETOOTH_ADMINBluetoothデバイスの検出とペアリング ※API≦30で利用
CHANGE_NETWORK_STATEネットワーク接続状態の変更
CHANGE_WIFI_MULTICAST_STATEWi-Fiマルチキャスト状態へ変更
CHANGE_WIFI_STATEWi-Fi状態の変更
DISABLE_KEYGUARDキーガードの無効化
FOREGROUND_SERVICEフォアグラウンドサービスの起動
HIGH_SAMPLING_RATE_SENSORSサンプリングレート≧200Hzでセンサーの使用
INTERNETインターネットへアクセス
KILL_BACKGROUND_PROCESSESバックグラウンドプロセスの中断
MODIFY_AUDIO_SETTINGSオーディオ設定の変更
NFCNFCを介したI/O操作
NFC_PREFERRED_PAYMENT_INFONFC優先支払いサービス情報の受信
NFC_TRANSACTION_EVENTNFCトランザクションイベントの受信
READ_SYNC_SETTINGS同期アダプター設定の読み出し
WRITE_SYNC_SETTINGS同期アダプター設定の書き込み
READ_SYNC_STATS同期アダプターの状態の読み出し
RECEIVE_BOOT_COMPLETEDシステムブート完了時に発行されるブロードキャストの受信
REORDER_TASKSタスクの表示順(Z-order、Z軸の順序)の変更
SET_ALARMアラームの設定
SET_WALLPAPER壁紙の設定
TRANSMIT_IRIR送信機の使用(可能であれば)
USE_BIOMETRIC生体認証の使用
USE_FINGERPRINT指紋認証ハードウェアの使用
USE_FULL_SCREEN_INTENT全画面アクティビティの起動
VIBRATEバイブレータの使用
WAKE_LOCK端末の起動状態の維持(スリープ、画面OFFにならない)
※API≦30で利用:AndroidManifestのPermission宣言でandroid:maxSdkVersion="30"を付加

取得タイミングが「アプリのインストール時」であることから、別名「Install-time Permission」と呼ばれます。インストール後に許可・拒否の判定は変更できません。

Signature

アプリ間でアプリケーションコンポーネントを連携させたい場合に、「○○コンポーネントへアクセスする機能」に紐づいたPermissionを、開発者が新規に定義できます。

この時、プロテクションレベルがSignatureであると、同じ鍵で署名された証明書を持つアプリからのみアクセスが許可されます。それ以外のアプリからのアクセスは拒否されます。

取得タイミングが「アプリのインストール時」であることから、「Install-time Permission」に含まれます。インストール後に許可・拒否の判定は変更できません。

【アプリケーションコンポーネント】
アプリを構成する最上位のコンポーネント(部品、構成要素)です。

次の4つがあります。どれも、AndroidManifestファイルで利用の宣言が必要です。

  ・Activity
  ・Service
  ・Broadcast Reciever
  ・Content Provider

アプリを一つのコンポーネント(Activity)で構成することもあります。しかし、複数のコンポーネントを連携(呼び出したり、呼ばれたり)させて構成する場合がほとんどです。

連携は同一アプリ内のコンポーネントに限りません。他者アプリのコンポーネントに対しても可能です。

スポンサーリンク

Internal

システムによって内部的に管理されるPermissionです。※詳細は未確認

スポンサーリンク

関連記事:

Install-time(Normal)Permissionの取得方法についてまとめます。 Permissionの詳細は「Permissionとその一覧」を参照してください。 ...
Runtime(Dangerous)Permissionの取得方法についてまとめます。 現在、Runtime Permissoinの取得方法は2つあります。 ここで紹介するのはRuntime Permission(API≧23)が登場した当初から存在している方法です。 この方法は、リクエスト(Permissionの申請)の結果を共用のコールバックAppCompatActivity#onRequestPermissionsResult( )で受け取ります。複数のリクエスト行うと、複数の結果を一つのコールバックで受けることになり、コールバック内でRequestCodeによる分岐が必要になります。 つまり、「開発者がリクエストを管理」しなければなりません。 Permissionの詳細は「Permissionとその一覧」を参照してください。 ...
Runtime(Dangerous)Permissionの取得方法についてまとめます。 現在、Runtime Permissoinの取得方法は2つあります。 ここで紹介するのは、ActivityResultContracts(※)を使う方法です。 この方法は、リクエスト(Permissionの申請)と結果を受け取る専用のコールバックが1対1に対応しています。ですので、複数のリクエストを行っても、RequestCodeによる分岐処理は必要ありません。システムが結果を各コールバックへ割り振ってくれます。 つまり、「システムがリクエストを管理」してくれます。 ドキュメントで推奨されている方法です。 Permissionの詳細は「Permissionとその一覧」を参照してください。 ※ライブラリandroidx.activity:activity≧1.20が必要 ...
パーミッションシステムの仕様変更がAPI≧30で行われています。  (1)1回だけアクセス許可  (2)“今後表示しない”の非表示  (3)アプリの休止 ここでは、「(1)1回だけアクセス許可」について説明します。 ...
パーミッションシステムの仕様変更がAPI≧30で行われています。  (1)1回だけアクセス許可  (2)“今後表示しない”の非表示  (3)アプリの休止 ここでは、「(2)“今後表示しない”の非表示」について説明します。 ...
パーミッションシステムの仕様変更がAPI≧30で行われています。  (1)1回だけアクセス許可  (2)“今後表示しない”の非表示  (3)アプリの休止 ここでは、「(3)アプリの休止」について説明します。 ...
「アプリの休止(App hibernation)」は発動までの期間が長いので、端末上で実際にその動作を確認しようとすると、待機時間が長くなってしまい、効率が悪いです。 ですので、テストでは「アプリの休止」を手動で発動させます。 今回は、この手動で発動させる方法を説明します。 ...
数ヶ月にわたってアプリが操作されなかった時に、アプリは休止状態(アプリの休止)になり、自動的にRuntime Permissionがリセット(削除)されます。 この機能はデフォルトで有効(On)です。 しかし、このPermissionのリセットを、良しとしないアプリが存在するかも知れません。 そのようなアプリのために、管理ページからユーザによって機能を無効(Off)にできます。 また、プログラム中から管理ページへユーザを誘導できます。 この「管理ページへユーザを誘導する方法」を紹介します。デベロッパーブログにも紹介されています。 ...
スポンサーリンク