Permissions Best Practices　翻訳

Permissions Best Practices　翻訳

A+ a-

Android Developer Siteのトレーニングページ、Working With System Permissionの最後のページの翻訳になります。

本ブログ内のトレーニング翻訳ページをまとめると以下となります。

Working with System Permissions　翻訳


Permissions Best Practices


パミッションの要求機能により、ユーザを失望させるのは簡単です。
ユーザが、アプリのイライラする点を見つけたり、ユーザ情報で何かやっているのではと心配している場合は、ユーザはアプリケーションを使わないようにしたり、また完全にアンインストールする事ができます。
次のベストプラクティスを使用すると、悪いユーザエキスペリエンスを回避する事ができます。

Consider Using an Intent


（パミッションの必要な）タスクをアプリケーションで実行する場合、多くの場合２つの方法のどちらかを選択する事ができます。
一つは、ユーザにパミッションの許可をもらい自分自身で実装する方法
もう一つは、インテントを用いて他のアプリケーションにその機能を実行される方法です。

例えば、アプリケーションでカメラで写真を撮る事ができるようにする必要があるとします。
あなたのアプリは、カメラに直接アクセスできるCAMERAパミッションを要求します。
あなたのアプリは、カメラＡＰＩを使用し、カメラをコントロールし、写真を撮ります。
このアプローチは、写真を撮るプロセス全てをコントロールする事ができ、カメラのＵＩを組み込む事ができます。

一方、このような完全なコントロールを必要としない場合、ACTION_IMAGE_CAPTUREインテントを用いて写真を要求する事ができます。
このインテントを投げた時、システムはカメラアプリ選択画面をユーザに表示します（デフォルトカメラアプリが設定されていない場合）
ユーザは選択したアプリで写真を撮影しアプリケーションはアプリケーションのonActivityResult()メソッドで写真を返します。

同じように、電話をかける必要がある場合、ユーザの連絡先にアクセスする場合も、インテントを作成するか、パミッションを要求して直接オブジェクトをアクセスする２種類の方法があります。各アプローチには長所と短所があります。

パミッションを使用する時


  • あなたが実現したいユーザエキスペリエンスを完全に実現できます。しかしながら、適切なＵＩを設計する必要があるので、広範囲の制御が必要になり複雑になります。（訳注：バグが入り込む可能性が高くなり、工数も増えます）
  • ランタイムパミッション、インストールパミッションのどちらかにせよ（ユーザのアンドロイドバージョンに依存）、ユーザは一度パミッションを許可する必要があります。その後アプリはユーザとの何らかの追加の操作を必要とせずに処理を進める事ができます。しかしながら、ユーザが許可を与えなかった場合（また、後から設定画面から許可の取り消しもできます）アプリケーションは、パミッションに関わる全ての機能を実行できなくなります。

インテントを使用する時


  • ＵＩ設計をする必要がありません。インテントを受け取るアプリがＵＩを提供します。しかしながらこれは、ユーザエキスペリエンスを制御できない事を意味します。ユーザはあなたが知らないアプリを操作します。（訳注：第三者のアプリのバグを自分のアプリのせいにされる可能性もあります）
  • ユーザがインテントを処理するデフォルトアプリを設定していない場合、システムはアプリを選択するダイアログを表示します。ユーザがデフォルトアプリを指定しない場合、操作を実行する毎に同じダイアログが表示され煩雑になります。

Only Ask for Permissions You Need


パミッションの許可を求めるたびに、ユーザはどうするのかの判断をしなければいけません。
あなたは、これらの許可を求める回数を最小限にする必要があります。
アンドロイド6.0 (API Level 23)以上の環境では、ユーザが権限を必要とする新しいアプリの機能を実行しようとすると、アプリがパミッションの許可を求めるため、ユーザは作業を中断しなければなりません。
アンドロイド6.0未満のバージョンの場合、ユーザはアプリをインストールする場合、アプリのパミッションを一つ一つ許可を与える必要があります。（訳注：一つ一つ目でチェックして、インストールする事で許可という事を書きたかったのだと思う）
パミッションのリストが長すぎる、また不適切と思われる場合ユーザはアプリケーションをインストールしない事を決定する事ができます。
これらの理由により、アプリケーションが必要とするパミッションは最小限にする必要があります。

インテントを代わりに利用する事で、パミッションの要求を避ける事ができるケースがかなりあります。
機能がアプリケーションのコアの機能ではない場合、インテントを使用する事で、他のアプリに仕事を引き渡す事を検討する必要があります。


Don't Overwhelm the User

アンドロイド6.0(API Level23)以上では、アプリケーション実行時に、アプリケーションに権限を付与する必要があります。
あなたが一度にたくさんのパミッションを要求した場合、ユーザは閉口し、アプリケーションを終了させることがあります。一度にすべてではなく、パミッションが必要な時に、必要なパミッションのみ取得要求をすべきです。

いくつかのケースでは、一つ以上のパミッションがアプリケーションに不可欠な場合があります。
その時は、アプリケーションが起動したらすぐに、それらのパミッションの許可を取る必要があります。
例えば、写真撮影のアプリを作る場合、カメラへのアクセスが必要となります。
ユーザがアプリケーションを最初に起動した得、カメラの使用許可を求められてもびっくりはしません。
しかし、同じアプリで、連絡先を参照して写真を共有する機能を持っている場合、起動時にREAD_CONTACTSパミッションの使用を起動時に求められて後気多分許可しないでしょう。代わりに、ユーザが、「共有」機能を実行するまで待ってパミッションの許可を求めるようにします。

アプリが、チュートリアルの機能を提供している場合、チュートリアルの後に本質的な権限を要求する事も理にかなっています。

Explain Why You Need Permissions


requestPermission()メソッドを実行した時にシステムにより表示されるパミッションダイアログは、「何の」パミッションがアプリに必要なのかを表示するのみです、「何故」必要なのかは表示しません。
ユーザが不可解に思う場合もあります。従ってrequestPermission()を呼び出す前に、何故アプリはこのパミッションが必要なのかを説明する事をお勧めします

例えば、写真撮影アプリは、ロケーションサービスが使用する事が可能でれば、写真にジオタグを付ける事ができます。
一般的なユーザは写真に位置情報を付ける事ができる事を理解していない可能性があり、写真撮影アプリが何故位置情報を知りたいのかわからず困惑するでしょう。
requestPermissions()を呼び出す前に、この機能についてユーザに説明するのは良いアイディアです。

ユーザに理解してもらうための良い方法の一つは、アプリケーションのチュートリアルに、これらの要求を盛り込む事です。
チュートリアルは、アプリのそれぞれの機能が実行されるときに表示します。そして、何故パミッションが必要かを説明します。
例えば、写真撮影アプリのチュートリアルでは、「連絡先ユーザへの写真を送る」機能では、アプリケーションがユーザの連絡先を見るためにパミッションが必要なのを説明し、理解してもらう事ができます。
これで、アプリは、requestPermissions()を呼び出し、ユーザにその権限へ許可を依頼できます。
もちろん、全てのユーザはチュートリアルに従うわけではありませんので、パミッションのチェックとリクエストは依然必要です。

Test for Both Permissions Models

アンドロイド6.0(API Level23)以降からは、アプリケーションのインストール時にパミッションを許可するのではなく、ユーザはアプリケーション実行時にパミッションを許可したり取り消したりできます。

その結果、アプリケーションを、今までよりも広い範囲でテストする必要があります。
アンドロイド6.0の以前は、アプリケーションが実行している時、あなたのアプリはマニュフェストに利用宣言したパミッションを全て取得している事を前提としている可能性があります。
新しいパミッションモデルでは、もはやその仮定は成り立ちません。

以下のヒントは、アンドロイド6.0(API Level23)以上のデバイスで実行している時のパミッションに関する問題を切り分けるのに役立ちます。

  • アプリの現在の権限と関連するコードパスを確認します。
  • パミッションで保護されたサービスとデータのユーザフローをテストします。
  • パミッションが付与、取り消された時の様々な組み合わせのテストをします。
  • 例えばカメラアプリが、CAMERA, READ_CONTACTS, ACCESS_FINE_LOCATIONをマニュフェストに記載している時、アプリが全てのパミッションの処理がうまくできているのを確認するために、それぞれのパミッションをon/offしてテストする必要があります。
  • コマンドラインからのアクセス許可を管理するために、adb ツールを使用します。
    • パミッションをグループ単位でリストアップします
      $ adb shell pm list permissions -d -g
    • パミッションの許可・不許可をします。
      $ adb shell pm [grant|revoke] <permission-name> ...
  • パミッションを使用しているサービスを分析します。

最後に

これで、トレーニングページに載っているパミッションの説明の翻訳は終了です。以前Developer Previewのページに記載してあった内容をコンパクトに纏めたといった感じで、細かい所までの網羅はありませんが、新しいパミッションモデルをざっくり知りたい時には有用だと思います。

しかし、現在リリースしているアプリをどうしていくのかだと思います。何も改編しない場合アンドロイド６．０上でも旧来のインストール時にパミッションを付与する状況で動作します。しかしユーザが設定画面で特定のパミッションを不許可にした場合ハングアップする可能性もあります。
取りあえず、パミッションを不許可にして動作を見る所から始められては如何でしょうか？

さて、RiskFinderですが、今回の大幅なパミッションモデルの変更に伴いバージョンアップ作業を行っております。今までも、アンドロイドＯＳがバージョンアップするたびにRiskFinderのバージョンアップを繰り返していましたが、パミッションという根本からの変更なので調査事項が大変多く、ちょっと大変な事になっております。

なるべく早くに最新版をお出ししたいと思っておりますので、よろしくお願いします。

がく

がく

リスクファインダーはAndroidアプリのセキュリティホールを見つけます！

Androidスマートフォンが急速に普及するとともにアプリの脆弱性報告も急増しています。
リスクファインダーは、Androidアプリの脆弱性診断WEBサービスです。
500項目以上のチェックでアプリの脆弱性や問題を検出し、セキュアなアプリ開発をサポートします。

  • ブラウザでファイルをアップロードするだけ
  • アプリの脆弱性を指摘するだけでなく対処方法も提示
  • 頻繁にバージョンアップするAndroidの最新情報に素早く対応

リスクファインダーの詳細はこちら