Wear OS で権限をリクエストする

Wear OS での権限のリクエストはモバイルアプリでの権限のリクエストと似ていますが、追加のユースケースがいくつかあります。このドキュメントは、Android の権限の仕組みについて理解していることを前提としています。不明な点がある場合は、Android での権限の仕組みをご確認ください。

モバイルアプリの場合と同様に、ユーザーは特定の機能を利用するための権限を Wear アプリに付与する必要があります。Wear アプリでは、権限をリクエストせずに有意義な機能を提供してください。

権限のシナリオ

Wear OS で危険な権限をリクエストするシナリオとして、次のようないくつかの場合があります。

  • Wear アプリが、ウェアラブル デバイスで動作するアプリ用の権限をリクエストする場合。

  • Wear アプリが、スマートフォンで動作するアプリ用の権限をリクエストする場合。

  • スマートフォン アプリが、ウェアラブル デバイスで動作するアプリ用の権限をリクエストする場合。

  • スマートフォン アプリが、ウェアラブル デバイスが接続されている間のみ使用できる複数の権限をリクエストする場合。

実際のアプリでこのようなすべてのシナリオを確認するには、GitHub の ExcersizeSampleCompose サンプルをご覧ください。

この後のセクションでは、上記の各シナリオについて説明します。権限のリクエストについて詳しくは、権限リクエストのパターンをご覧ください。

Wear アプリがウェアラブルの権限をリクエストする場合

Wear アプリがウェアラブル デバイスで動作するアプリ用の権限をリクエストする場合は、その権限の付与をユーザーに求めるダイアログがシステムによって表示されます。アプリでは、特定のオペレーションを行うためにその権限が必要な理由がユーザーにとって明白である場合にのみ、権限をリクエストします。

優れたユーザー エクスペリエンスを実現するため、権限の原則を確認してください。また、必ず shouldShowRequestPermissionRationale() をチェックし、必要に応じて補足情報を提供してください。

アプリまたはウォッチフェイスで一度に複数の権限を要求する場合、権限リクエストは 1 つずつ表示されます。

複数の権限画面が 1 つずつ表示されます。
図 1. 権限画面が順番に表示されます。

Wear アプリがスマートフォンの権限をリクエストする場合

Wear アプリがスマートフォンの権限をリクエストする場合（ウェアラブル アプリがモバイル版で写真などのプライベート データにアクセスしようとする場合など）、Wear アプリは、ユーザーにスマートフォンで権限を付与してもらう必要があります。その際、スマートフォン アプリでアクティビティを使用してユーザーに補足情報を提供できます。アクティビティには 2 つのボタン（権限を付与するボタンと拒否するボタン）を含めます。

Wear アプリがユーザーにスマートフォンで権限を付与してもらいます。
図 2. ユーザーにスマートフォンで権限を付与してもらいます。

スマートフォン アプリがウェアラブルの権限をリクエストする場合

ユーザーがスマートフォン アプリを操作していて、アプリがウェアラブルの権限を必要とする場合（スマートフォンが接続解除された場合に備えて音楽をプリロードする場合など）、スマートフォン アプリは、ユーザーにウェアラブル デバイスで権限を付与してもらう必要があります。アプリのウェアラブル版は、requestPermissions() メソッドを使用してシステム権限ダイアログをトリガーします。

スマートフォン アプリがユーザーにウェアラブルで権限を付与してもらいます。
図 3. ユーザーにウェアラブルで権限を付与してもらいます。

スマートフォン アプリが一度に複数の権限をリクエストする場合

図 4. コンパニオン デバイス プロファイルを使用して、1 つのリクエストで複数の権限をリクエストする権限ダイアログ。

Android 12（API レベル 31）以降に搭載されたパートナー アプリは、スマートウォッチに接続する際にコンパニオン デバイス プロファイルを使用できます。プロファイルを使用すると、デバイスタイプ固有の権限セットの付与を 1 つのステップにまとめて、登録プロセスを簡素化できます。

まとめた権限は、デバイスが接続されるとコンパニオン アプリに付与され、デバイスが関連付けられている間に限り有効です。アプリを削除するか関連付けを削除すると、権限が削除されます。詳しくは、AssociationRequest.Builder.setDeviceProfile() をご覧ください。

権限リクエストのパターン

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

  • 状況に応じてリクエスト: その権限が特定の機能に必要であることは明白だが、アプリ自体の動作には必要ない場合。

  • 状況に応じて説明: その権限をリクエストする理由が明白でなく、その権限がアプリ自体の動作には必要ない場合。

これらのパターンについては、この後のセクションで説明します。

状況に応じてリクエスト

特定のオペレーションを行うためにその権限が必要な理由がユーザーにとって明白である場合に、権限をリクエストします。ユーザーが使用したい機能と権限の関連性を理解すれば、権限を付与する可能性が高くなります。

たとえば、アプリで周辺の注目スポットを表示する場合は、ユーザーの位置情報が必要です。周辺のスポットの検索と位置情報の権限の必要性には明白な関連性があるため、ユーザーが周辺のスポットを検索するためにタップすると、アプリはすぐに位置情報の権限をリクエストできます。関連性が明白であるため、アプリで補足説明の画面を表示する必要はありません。

権限の必要性が明白な場合、アプリは権限をリクエストします。
図 5. 状況に応じて権限をリクエストします。

状況に応じて説明

図 6 は、状況に応じて説明する例を示しています。アプリは権限がなくてもタイマーを開始できますが、インラインの説明キューで、アクティビティの一部（位置情報の検出）がロックされていることを示します。ユーザーがキューをタップすると、権限リクエスト画面が表示され、ユーザーは位置情報検出機能のロックを解除できます。

shouldShowRequestPermissionRationale() メソッドを使用すると、アプリで詳細情報を提供するかどうかを指定できます。詳しくは、アプリの権限をリクエストするをご覧ください。または、GitHub のスピーカー サンプルアプリが情報の表示をどのように処理するかを調べることもできます。

権限が必要になったときに、権限が必要な理由を説明します。
図 6. 状況に応じて説明します。

拒否された場合の処理

リクエストした権限がユーザーに拒否された場合、目的のアクティビティにとってその権限が不可欠でなければ、アクティビティの続行を妨げないでください。権限が拒否されたことでアクティビティの一部が無効になる場合は、実用的な視覚的フィードバックを提供します。

図 7 では、ユーザーが機能を使用する権限を付与しなかったためにその機能がロックされたことを鍵アイコンによって示しています。

ユーザーが権限を拒否した場合、対象の機能と並んで鍵アイコンが表示されます。
図 7. 権限が拒否されたために機能がロックされたことを示す鍵アイコン。

以前に拒否された権限のダイアログをウェアラブルに再度表示する場合は、「拒否、次回から表示しない」オプションが追加されます。ユーザーがこのオプションを選択すると、その後はウェアラブルの設定アプリからでなければその権限を付与できなくなります。

権限のリクエストを停止するオプションがシステムによって表示されます。
図 8. ユーザーは、以前に 2 回拒否した権限のリクエストに設定からアクセスできます。

権限の拒否を処理する方法をご確認ください。

サービスの権限

requestPermissions() メソッドを呼び出せるのはアクティビティのみです。そのため、ユーザーがサービスを使用して（たとえばウォッチフェイス経由で）アプリを操作する場合、サービスが権限をリクエストするにはアクティビティを開く必要があります。このアクティビティで、権限が必要な理由について補足説明を提供します。

一般的に、ウォッチフェイスの権限はリクエストしません。代わりにウォッチフェイスの追加機能を実装し、ウォッチフェイスの追加機能を通じて、表示するデータをユーザーが選択できるようにします。

設定

ユーザーはいつでも設定から Wear アプリの権限を変更できます。ユーザーが権限を必要とする操作を行おうとしたときは、まず checkSelfPermission() メソッドを呼び出して、アプリにその操作を行うための権限が付与されているかどうかをチェックします。

このチェックは、ユーザーが以前に権限を付与していても実施してください。後になって権限を取り消した可能性があるからです。

ユーザーは設定アプリから権限を変更できます。
図 9. ユーザーは設定アプリを使用して権限を変更できます。