それで、私たちは今モバイルに行きました: Android Developerコースのセットが始まりました。 別の小さなマイルストーンとまったく新しい方向性。 私たちの教師であるSemyon Piluntsは、この点に関する許可についての彼の考えをいくつか共有しています。
アプリケーションがAndroid 6.0(APIレベル23)以上で実行され、特別な権限が必要な場合、それらを使用するにはさらに作業が必要です。 Marshmallow以降、ユーザーはアプリケーションの実行中にアプリケーションの許可を提供します。アプリケーションのインストール時ではなく(Marshmallowより前のバージョンでは、マニフェストファイルで使用する許可を単に宣言できます)。 新しい概念は、実行時許可と呼ばれています。 このアプローチにより、アプリケーションのインストールまたは更新時にユーザーがアクセス許可を付与する必要がないため、アプリケーションのインストールプロセスが簡素化されます。 また、ユーザーはアプリケーションの機能をより詳細に制御できます。 たとえば、ユーザーは撮影アプリケーションでカメラにアクセスすることはできますが、デバイスの場所にはアクセスできません。 ユーザーは、アプリケーション設定画面にアクセスして、いつでも権限を取り消すことができます。 それらの背後にある考え方は、多くのアプリケーションが多くの不必要な許可を使用するため、使用する許可をユーザーに通知することです。

場合によっては、アプリケーションがこの許可またはその許可を必要とする理由をユーザーに理解させるのに役立ちます。 上記の例では、ユーザーが写真アプリケーションを起動した場合、ユーザーはおそらくアプリケーションがカメラの使用許可を要求することに驚かないでしょうが、ユーザーはアプリケーションがユーザーの位置または連絡先にアクセスする理由を理解できないかもしれません。 許可を要求する前に、ユーザーに説明を提供することを検討する必要があります。 ユーザーに説明をあふれさせたくないことに注意してください。 あまりにも多くの説明を提供すると、ユーザーはアプリケーションを失望させて削除する場合があります。
それでは、その方法を理解しましょう。
システム権限は、 通常と危険の 2つのカテゴリに分けられます。
- 通常の許可は、ユーザーのプライバシーに直接影響しません。 アプリケーションのマニフェストに通常の解像度が表示されている場合、システムは自動的に許可を提供します。
- 危険な許可により、アプリケーションはユーザーの機密データにアクセスできます。 危険な許可を指定する場合、ユーザーはアプリケーションに明示的に承認する必要があります。
Androidのすべてのバージョンで、アプリケーションは、アプリケーションマニフェストで必要な通常のアクセス許可と危険なアクセス許可の両方を宣言する必要があります。 ただし、この宣言の効果は、システムのバージョンとアプリケーションのターゲットSDKレベルによって異なります。
- デバイスがAndroid 5.1以下を実行している場合、またはアプリケーションのターゲットSDKが22以下の場合:マニフェストで危険な許可を指定した場合、ユーザーはアプリケーションのインストール時に許可を提供する必要があります。 権限を提供しない場合、システムはアプリケーションをまったくインストールしません。
- デバイスがAndroid 6.0以降を実行しており、アプリケーションのターゲットSDKが23以上の場合:アプリケーションはマニフェストにアクセス許可を表示し、アプリケーションの実行中に必要なすべての危険なアクセス許可を要求する必要があります。 ユーザーは各許可を許可または拒否でき、許可要求を拒否した場合でも、アプリケーションは限られた機能で引き続き動作できます。
アプリケーションに危険な許可が必要な場合、その許可を必要とする操作を実行するたびに、その許可があるかどうかを確認する必要があります。 ユーザーはいつでも許可を取り消すことができるため、アプリケーションが昨日カメラを使用した場合でも、今日この許可をまだ持っているとは想定できません。
権限があるかどうかを確認するには、
ContextCompat.checkSelfPermission ()
メソッドを呼び出します。 たとえば、次のスニペットは、アクションにカレンダーへの書き込み権限があるかどうかを確認する方法を示しています。
*コードフラグメント> *
アプリケーションに許可がある場合、メソッドは
PackageManager.PERMISSION_GRANTED
返し、アプリケーションは操作を続行できます。 アプリケーションに許可がない場合、メソッドはPERMISSION_DENIEDを返し、アプリケーションはユーザーに許可を明示的に要求する必要があります。
アプリケーションに必要な許可がまだない場合、アプリケーションは
requestPermissions ()
メソッドの1つを呼び出して適切な許可を要求する必要があります。 アプリケーションは、必要な許可と、この許可要求を識別するために指定する整数要求コードを渡します。 リクエストコードとは何ですか? リクエストに対するユーザーの反応を処理するとき、同じアクションで複数のアクセス許可を複数回要求できるため、これらのリクエストを選択する必要があります。これはリクエストコードで行います。 では、リクエストに対するユーザーの応答をどのように処理しますか? アプリケーションが許可を要求すると、システムはユーザーにダイアログボックスを提供します。 ユーザーが応答すると、システムはアプリケーションの
onRequestPermissionsResult ()
メソッドを呼び出し、ユーザーの応答をそれに渡します。 アプリケーションは、このメソッドをオーバーライドして、許可が付与されているかどうかを確認する必要があります。 コールバックには、
requestPermissions ()
渡したのと同じリクエストコードが渡されます。 システムがユーザーに許可を求めると、ユーザーはシステムにこの許可を再度要求しないように指示できます。 この場合、アプリケーションが
requestPermissions ()
を使用してこの許可を再度要求すると、システムはすぐに要求を拒否します。 システムは
onRequestPermissionsResult ()
コールバックメソッドを呼び出し、ユーザーがリクエストを明示的に拒否したかのようにPERMISSION_DENIEDを渡します。 これは、
requestPermissions ()
を呼び出すときに、ユーザーとの直接的なやり取りがあったと想定できないことを意味します。
終わり
いつものように、私たちはあなたのフィードバックや質問をここまたは公開レッスンで待っています。そこでは、Android StudioおよびAndroid Virtual Device(AVD)Manager開発環境とその機能の紹介を紹介します。