android mのruntime-permissionに潜む罠
TRANSCRIPT
新パーミッションモデルの特徴
Android の抱える課題の一つ、「許可したパーミッションを後から変更できない」という状況の解消 ( ただし、一部のパーミッション )
インストール時ではなく、利用時に許可を求める
チェックや許可要求、結果受け取りは作ってやる必要有り→公式やサンプル参照
許可を与えても後から変更が可能
新パーミッションモデルの特徴
連絡帳の読取
利用時
「連絡帳の読取」が必要な機能を使うときに、
パーミッションをチェックして個別に許可する
設定画面からも変更可能で与えていた許可を取り消したり、要求がなくても許可を与えることが出来る
新パーミッションモデルの特徴
連絡帳の読取
利用時
「連絡帳の読取」が必要な機能を使うときに、
パーミッションをチェックして個別に許可する
設定画面からも変更可能で与えていた許可を取り消したり、要求がなくても許可を与えることが出来る
許可がないまま機能を使おうとすると、「 Permission Denied 」として強制終了する( パーミッション無いから当たり前 )
グループ単位での設定変更 パーミッションの設定変更は、 AndroidManifest で
宣言されているグループ内のパーミッション全てに対して一律に行われる
設定画面からの変更でも、 requestPermissions によるアプリからの要求でも同じ。要求は引数にパーミッションを一つ指定すれば、グループ全体に影響が及ぶ
<use-permission android:name=“android.permission. READ_CONTACTS”><use-permission android:name=“android.permission. WRITE_CONTACTS”>AndroidManifest での宣言
<pkg name="com.sample.sample"> <item name="android.permission. READ_CONTACTS" granted="true" flags="0" /> <item name="android.permission. WRITE_CONTACTS" granted="true" flags="0" /></pkg>
パーミッションの許可状況/data/system/user/{userId}/runtime-permissions.xml
requestPermissions(new String[]{Manifest.permission.READ_CONTACTS}, REQUEST_READ_CONTACTS);アプリ内でのパーミッション要求
許可済パーミッションとユーザー認識のずれ (1/3)
パーミッション グループ パーミッション
android.permission-group.CONTACTS
android.permission.READ_CONTACTS
android.permission.WRITE_CONTACTS
android.permission.READ_PROFILE
android.permission.WRITE_PROFILE
コミュニケーション系アプリで以下の機能を想定A) 既存ユーザを探すために、連絡帳の情報を利用要: android.permission.READ_CONTACTSB) サービス上のユーザを連絡帳に追加要: android.permission.WRITE_CONTACTS
いずれも android.permission-group.CONTACTS に所属
③ パーミッショングループへの許可要求「連絡帳の情報を使ってユーザーを探すには、「連絡帳へのアクセス」を許可する必要があります。」
許可済パーミッションとユーザー認識のずれ (2/3)
ユーザは機能 A だけ許可したつもりでも、機能 B も許可される
① 機能 A 利用の要求
④ パーミッショングループへの許可
⑤ パーミッショングループへの許可の付与
② パーミッションチェック (READ_CONTACTS)
ユーザ アプリ・端末
⑥ 機能 A の利用ここで READ_CONTACTS だけでなく、
WRITE_CONTACTS にも許可が与えられる
③ パーミッショングループへの許可要求「連絡帳の情報を使ってユーザーを探すには、「連絡帳へのアクセス」を許可する必要があります。」
許可済パーミッションとユーザー認識のずれ (2/3)
ユーザは機能 A だけ許可したつもりでも、機能 B も許可される
① 機能 A 利用の要求
④ パーミッショングループへの許可
⑤ パーミッショングループへの許可の付与
② パーミッションチェック (READ_CONTACTS)
ユーザ アプリ・端末
⑥ 機能 A の利用⑦ 機能 B 利用の要
求⑧ パーミッションチェック(WRITE_CONTACTS)⑨ 機能 B の利用
ここで READ_CONTACTS だけでなく、 WRITE_CONTACTS にも許可が与えられる
許可済パーミッションとユーザー認識のずれ (3/3)
「要求された箇所の機能を使うためにパーミッションが必要」という説明だけではなく、「パーミッション( グループ ) を許可することによる、アプリ全体への影響」の説明も必要かも
公式のベストプラクティスのように、チュートリアルを設ける手もあるが、全てをその中ではカバーできない。
グループ全体で要求ダイアログが表示されない (1/2)
requestPermissions でパーミッション要求を行った際に、「今後は確認しない」にチェックして「許可しない」を選ぶと、次回以降ダイアログが表示されなくなる。
「今後は確認しない」とした箇所だけではなく、同一パーミッショングループ全体が同じ設定になる。
各パーミッションの状態を、「 flags 」で管理しており、この値もグループ単位で設定するため ( 「今後は確認しない」は flags=2)
<pkg name="com.sample.sample"> <item name=" android.permission. READ_CONTACTS" granted=“false" flags=“2" /> <item name=" android.permission. WRITE_CONTACTS" granted=“false" flags=“2" /></pkg>
パーミッションの許可状況/data/system/user/{userId}/runtime-permissions.xml
グループ全体で要求ダイアログが表示されない (2/2)
この回避 ( 正確には軽減策 ) のためには、表示しないとしたときのメッセージの作成や、復活させるための手順を示したヘルプを設ける
初めて利用する機能ですでに制限されてしまっている場合には手順を表示、複数回反応がないのにボタンを押したらヘルプ表示などのサポートも必要
このバランスは今後ちょうどよいところを見つけていくしかない
まとめ Android のパーミッションモデルは Android M で新しいモデ
ルにとなりユーザーが決定権を持つようになった
グループ単位での設定となったことによって、うまく説明しないとユーザーに誤解が生じかねない
問題は仕組み上、根本的に解決する方法がない。説明や補助的な機能を作り、誤解を生じないようにするしかない。分量のバランスはユーザーからのレスポンスをよく見てやる必要がある。
パーミッショングループのまとまりが iOS のプライバシー設定と似ているものは、そのときの対応も参考に。