Save the date! Android Dev Summit is coming to Sunnyvale, CA on Oct 23-24, 2019.

Wear OS におけるパーミッションのリクエスト

Android 6.0(API レベル 23)で新しいパーミッション モデルが導入され、Wear OS by Google に固有ないくつかの変更が行われています。また、すべての Android ベースの端末に適用される変更も加えられています。

コンパニオン スマートフォン アプリがある場合でも、ユーザーは Wear アプリにパーミッションを付与する必要があります。Android 6.0(API レベル 23)以降の Wear アプリは、スマートフォン アプリで付与されたパーミッションを受け取ることはできません。たとえば、ユーザーがスマートフォン アプリにロケーション データを使用するパーミッションを付与しても、Wear アプリのユーザーは再度同じパーミッションを付与する必要があります。

注: このページでは、時計のアプリのコンパニオンとなるスマートフォン アプリが作成されている可能性も考慮されています。しかし、スマートフォン アプリの作成は必須ではなく、時計のアプリはスタンドアロン アプリでも構いません。

Android 6.0(API レベル 23)のパーミッション モデルでは、Wear アプリとスマートフォン アプリの両方で、アプリが必要とする可能性があるすべてのパーミッションをユーザーが前もって付与しなければならないという要件が削除され、アプリのインストールやアップグレードを効率的に行えるようになっています。パーミッションは、実際にアプリが必要とするときに初めてリクエストされます。

注:アプリで新しいパーミッション モデルを使うには、uses-sdk-elementcompileSdkVersion の両方に値 23 を指定する必要があります。

ドキュメントの以降の部分では、Wear OS アプリを開発する際の Android 6.0(API レベル 23)のパーミッション モデルの使い方について説明します。

パーミッション シナリオ

Wear OS では、大きく分けて以下の 4 つのシナリオで Dangerous パーミッションをリクエストすることが考えられます。

  • Wear アプリウェアラブル端末で実行されているアプリのパーミッションをリクエストする場合
  • Wear アプリハンドセットで実行されているアプリのパーミッションをリクエストする場合
  • スマートフォン アプリウェアラブル端末で実行されているアプリのパーミッションをリクエストする場合
  • ウェアラブル アプリがペアとなるスマートフォンによって提供される異なるパーミッション モデルを使う場合

このセクションの以降の部分では、それぞれのシナリオについて説明します。パーミッション リクエストの詳細については、パーミッション リクエストのパターンをご覧ください。

Wear アプリがウェアラブル端末で実行されているアプリのパーミッションをリクエストする

Wear アプリがウェアラブル端末で実行されているアプリのパーミッションをリクエストすると、そのパーミッションを求めるダイアログがユーザーに対して表示されます。アプリやサービスができるのは、アクティビティから requestPermissions() メソッドを呼び出すことだけです。ユーザーがウォッチフェイスなどのサービス経由でアプリとインタラクションしている場合、サービスはパーミッションをリクエストする前にアクティビティを開く必要があります。

アプリは、操作を実行するためにパーミッションが必要となる理由が明確にわかるタイミングで、コンテキスト内でパーミッションをリクエストします。アプリに特定のパーミッションが必要なことが明らかである場合は、アプリの起動時にリクエストしても構いません。そこまで明確でない場合は、パーミッションをリクエストする前に追加の説明を表示することもできます。

アプリやウォッチフェイスで一度に複数のパーミッションが必要になる場合は、パーミッションのリクエストが連続して表示されます。

複数のパーミッション画面が連続して表示されます。

図 1. 連続して表示されるパーミッション画面

注: Android 6.0(API レベル 23)以降では、Wear OS はカレンダー、連絡先、ロケーションのデータを Wear 端末に自動的に同期します。そのため、Wear がこれらのデータをリクエストすると、このシナリオが適用されます。

Wear アプリがスマートフォンのパーミッションをリクエストする

Wear アプリからスマートフォンのパーミッションをリクエストする場合、Wear アプリがユーザーをスマートフォンに送り、パーミッションを許可してもらう必要があります。その際に、スマートフォン アプリのアクティビティから、ユーザーに追加の説明を表示することができます。このアクティビティには、パーミッションを許可するボタンと拒否するボタンの 2 つを含める必要があります。

Wear アプリがユーザーをスマートフォンに送り、パーミッションを付与してもらいます。

図 2. ユーザーをスマートフォンに送り、パーミッションを付与してもらいます。

スマートフォン アプリがウェアラブルのパーミッションをリクエストする

ユーザーがスマートフォン アプリを操作しており、アプリにウェアラブルのパーミッションが必要になる場合、スマートフォン アプリがユーザーをウェアラブルに送り、パーミッションを許可してもらう必要があります。スマートフォン アプリは、ウェアラブルで requestPermissions() メソッドを使ってシステム パーミッション ダイアログを起動します。

スマートフォン アプリがユーザーをウェアラブルに送り、パーミッションを付与してもらいます。

図 3. ユーザーをウェアラブルに送り、パーミッションを付与する

ウェアラブルとスマートフォン アプリ間のパーミッション モデルの不一致

Android 6.0(API レベル 23)のモデルがスマートフォン アプリで使用され、ウェアラブル アプリでは使用されていない場合、Wear アプリはダウンロードされますが、インストールはされません。ユーザーが初めてアプリを起動すると、すべての保留中のパーミッションを許可することが要求されます。その後、アプリがインストールされます。ウォッチフェイスなどのアプリにランチャーが存在しない場合、アプリに必要なパーミッションを付与することを求めるストリーム通知が表示されます。

パーミッション リクエストのパターン

ユーザーにパーミッションをリクエストする際のパターンには、いくつかの種類があります。以下に、優先度の高い順に記載します。

  • コンテキスト内で要求: 特定の機能について明らかにパーミッションが必要だが、アプリの実行には必須でない場合
  • コンテキスト内で説明: パーミッションをリクエストする理由が明らかでなく、アプリの実行には必須でない場合
  • 事前に要求: パーミッションの必要性が明らかで、アプリの実行に必須である場合
  • 事前に説明: パーミッションの必要性が明らかでないが、アプリの実行に必須である場合

コンテキスト内で要求

アプリは、ある操作を実行するためにパーミッションが必要となる理由が明らかになるタイミングで、パーミッションをリクエストする必要があります。ユーザーがパーミッションと使いたい機能との関連性を理解すれば、パーミッションを付与する可能性が高くなります。

たとえば、アプリが近くの有名スポットを表示するために、ユーザーのロケーションを必要とする場合などです。近くのスポットの検索とロケーションのパーミッションの必要性には明らかな関連があるので、ユーザーがタップして近くのスポットを検索したとき、すぐにロケーションのパーミッションをリクエストできます。関連性が明らかなので、アプリが追加の説明画面を表示する必要はありません。

明らかにパーミッションが必要な場合に、アプリがパーミッションをリクエストします。

図 4. コンテキスト内で要求

コンテキスト内で説明

必要に応じて、パーミッションをリクエストする前に追加説明を行うこともできます。ここでも、アプリが特定の操作を完了するためにリクエストされたパーミッションにアクセスしなければならない理由が不明確な場合、その操作のコンテキスト内で追加説明を行う必要があります。

図 5 に、コンテキスト内での説明の例を示します。アプリはパーミッションがなくてもタイマーを開始できますが、インラインのキューで一部のアクティビティ(ロケーションの検出)がロックされていることを説明します。ユーザーがキューをタップすると、パーミッション リクエスト画面が表示され、ロケーション検出機能のロックを解除できるようになります。

shouldShowRequestPermissionRationale() メソッドを使うと、アプリで詳しい情報を表示するかどうかを決めることができます。さらに詳しくは、実行時のパーミッション リクエストをご覧ください。

パーミッションの必要性が生じた場合に、パーミッションが必要になる理由を説明します。

図 5. コンテキスト内で説明

事前に要求

アプリが動作するために明らかにパーミッションが必要である場合、ユーザーがアプリを起動した際にパーミッションを要求することができます。たとえば、地図アプリが期待されているアクティビティを実行するためには、明らかに端末のロケーションにアクセスする必要があります。このパーミッションのために説明を行う必要はありません。

アプリを実行するために明らかにパーミッションが必要である場合、起動時にパーミッションを要求することができます。

図 6. 事前に要求

事前に説明

場合によっては、アプリの基本機能にパーミッションが必要であるにもかかわらず、パーミッションの必要性が明らかでないこともあります。このような場合、ユーザーが初めてアプリを起動したとき、またはウォッチフェイスを設定したときに、アプリまたはウォッチフェイスでユーザーに説明を表示し、パーミッションを要求することもできます。

起動時にパーミッションをリクエストする場合、アプリでパーミッションが必要になる理由を説明することができます。

図 7. 事前に説明

拒否された場合の処理

ユーザーがリクエストされたパーミッションを拒否し、それが意図するアクティビティにとって重要でない場合は、アクティビティの継続を妨げてはいけません。パーミッションが拒否されたことによってアクティビティの一部が無効になった場合、目で見てわかるアクション可能なフィードバックを提供します。図 8 では、ユーザーがパーミッションを付与しなかったため、ロックアイコンを使って機能がロックされていることを示しています。

ユーザーがパーミッションを拒否すると、関連する機能の隣にロックアイコンが表示されます。

図 8. パーミッションの拒否によって機能がロックされていることを示すロックアイコン

以前に拒否されたウェアラブルのパーミッション ダイアログが再度表示された場合、[Deny, don't show again] オプションが含まれます。ユーザーがこのオプションを選ぶと、以降、そのパーミッションはウェアラブルの Settings アプリからしか許可できなくなります。

システムによって、パーミッションのリクエストを停止するオプションが表示されます。

図 9. 今後パーミッション リクエスト画面を表示しないことの確認

サービスのパーミッション

前述のように、requestPermissions() メソッドを呼び出せるのはアクティビティのみです。そのため、ユーザーがアプリ経由でウォッチフェイスなどのサービスとインタラクションする場合、サービスはバックグラウンド アクティビティを開いてからパーミッションをリクエストする必要があります。このアクティビティは、追加の説明を表示するものでも、システム ダイアログを表示するだけの見えないアクティビティでも構いません。

ウェアラブル アプリがウォッチフェイス以外のサービスを実行しており、パーミッションをリクエストすべきアプリが起動されていない場合は、ウェアラブルに説明の通知を送信することができます。この通知にアクティビティを開く操作を表示し、そこからシステム パーミッション ダイアログを呼び出すことができます。

注:これは、パーミッションのリクエストにストリーム通知を利用できる唯一の方法です。

ユーザーがサービス経由で間接的にアプリとインタラクションする場合、パーミッションを付与する必要が生じる場合があります。

図 10. パーミッションをリクエストするサービス

設定

スマートフォンと同じように、ユーザーはいつでも Settings から Wear アプリのパーミッションを変更することができます。そのため、パーミッションを必要とする操作をユーザーが試みた場合、アプリはまず checkSelfPermission() メソッドを呼び出して、現在アプリにその操作を行うパーミッションがあるかどうかを確認する必要があります。このチェックは、ユーザーが以前にパーミッションを付与していることが分かっていても行う必要があります。ユーザーがその後にパーミッションを取り消している可能性があるからです。

ユーザーは、Settings アプリからパーミッションを変更できます。

図 11. Settings アプリでの設定の変更