このページは Cloud Translation API によって翻訳されました。

通知に関する実行時の権限

Android 13（API レベル 33）以降では、アプリから除外対象外（フォアグラウンドサービス（FGS）を含む）通知を送信するための実行時の権限（POST_NOTIFICATIONS）がサポートされています。この変更は、ユーザーが重要な通知に集中するのに役立ちます。

この機能による制御の強化と柔軟性の向上を活用するため、できるだけ早く Android 13 以降をターゲットに設定することを強くおすすめします。引き続き 12L（API レベル 32）以下をターゲットとする場合、アプリの機能のコンテキストに応じて権限をリクエストするための柔軟性が失われます。

権限を宣言する

アプリから新しい通知権限をリクエストするには、アプリを更新して Android 13 をターゲットに設定し、以下のセクションで説明しているように、他の実行時の権限をリクエストする場合と同様のプロセスを実施します。

アプリのマニフェストファイルで宣言する必要がある権限を、次のコードスニペットに示します。

<manifest ...>
    <uses-permission android:name="android.permission.POST_NOTIFICATIONS"/>
    <application ...>
        ...
    </application>
</manifest>

アプリの機能は権限ダイアログでのユーザーの選択によって異なる

権限ダイアログでは、ユーザーは次のアクションを実行できます。

[許可] を選択する
[許可しない] を選択する
どちらのボタンも押さずにダイアログをスワイプして閉じる

以下のセクションでは、ユーザーが選択したアクションに基づくアプリの動作について説明します。

ユーザーが [許可] を選択した場合

ユーザーが [許可] を選択した場合、アプリは次のことを実行できます。

通知を送信する。すべての通知チャンネルが許可されます。
フォアグラウンドサービスに関する通知を送信する。この通知は通知ドロワーに表示されます。

ユーザーが [許可しない] を選択した場合

ユーザーが [許可しない] を選択した場合は、除外対象である場合を除き、アプリは通知を送信できません。少数の特定のロールを除いて、すべての通知チャンネルがブロックされます。これは、ユーザーがシステム設定でアプリの通知をすべて手動でオフにした場合の動作と似ています。

注意: アプリが 12L 以下をターゲットとしている場合は、ユーザーが [許可しない] を一度でもタップすると、次のいずれかの条件が発生するまでは権限のプロンプトが表示されなくなります。

ユーザーがアプリをアンインストールして再インストールした
Android 13 以上をターゲットとするようにアプリをアップデートした

ユーザーがダイアログをスワイプして閉じた場合

ユーザーがダイアログをスワイプして閉じた場合（つまり、[許可] と [許可しない] のどちらも選択しなかった場合）、通知権限の状態は変わりません。

新しくインストールされたアプリへの影響

Android 13 以降を搭載したデバイスにユーザーがアプリをインストールした場合、アプリの通知はデフォルトでオフになります。アプリは、新しい権限をリクエストしてユーザーがその権限をアプリに付与するまで、通知の送信を控える必要があります。

権限ダイアログが表示されるタイミングは、アプリのターゲット SDK バージョンによって異なります。

Android 13 以上をターゲットとするアプリは、権限ダイアログが表示されるタイミングを完全に制御できます。この機会を利用して、アプリがこの権限を必要とする理由をユーザーに説明し、権限を付与するようすすめます。
アプリが 12L（API レベル 32）以下をターゲットとする場合、権限ダイアログは、通知チャンネルの作成後にアプリが最初にアクティビティを開始したとき、または、アプリがアクティビティを開始して最初の通知チャンネルを作成したときに表示されます。通常、これはアプリの起動時です。

既存のアプリのアップデートへの影響

通知権限の許可に伴う中断を最小限に抑えるため、ユーザーがデバイスを Android 13 以降にアップグレードした時点で、自動的にすべての対象アプリに通知権限が事前付与されます。つまり、これらのアプリは引き続きユーザーに通知を送信できますが、ユーザーには実行時の権限のプロンプトが表示されません。

権限が事前付与される条件

アプリが自動的な事前権限付与の対象となるには、アプリに既存の通知チャンネルがあり、12L 以下を搭載したデバイスでユーザーがアプリの通知を明示的に無効にしていないことが必要です。

12L 以下を搭載したデバイスでユーザーがアプリの通知を無効にした場合、デバイスが Android 13 以上にアップグレードされても、ユーザーの拒否は引き続き有効です。

除外

このセクションでは、通知権限の動作の変更から除外される通知とアプリを示します。Android 13（API レベル 33）以降では、ユーザーが通知権限を拒否しても、フォアグラウンドサービスに関連する通知がタスクマネージャーに表示されます。ただし、この通知は通知ドロワーには表示されません。

メディアセッション

メディアセッションに関する通知は、この動作変更から除外されます。

通話を自己管理するように構成されたアプリ

通話を自己管理するようにアプリが構成されている場合は、Notification.CallStyle スタイルの通知をアプリが送信するために POST_NOTIFICATIONS 権限は必要ありません。

アプリで次のことが行われた場合、システムはアプリが通話を自己管理するように構成されているとみなします。

MANAGE_OWN_CALLS 権限を宣言する。
ConnectionService インターフェースを実装する。
registerPhoneAccount() を呼び出して、デバイスの通信プロバイダに登録する。

アプリをテストする

Android 13 以降を搭載したデバイスでは、通知権限をデバイス上のアプリに最初に使用したときの影響を評価できます。以下の Android Debug Bridge（ADB）コマンドのセットを使用すると、テストデバイスをリセットすることなく、ユーザー選択やデバイスアップグレードの一般的なシーケンスをシミュレーションできます。

Android 13 以降を搭載したデバイスに、アプリが新しくインストールされた場合:

adb shell pm revoke PACKAGE_NAME android.permission.POST_NOTIFICATIONS
adb shell pm clear-permission-flags PACKAGE_NAME \
  android.permission.POST_NOTIFICATIONS user-set
adb shell pm clear-permission-flags PACKAGE_NAME \
  android.permission.POST_NOTIFICATIONS user-fixed

12L 以下を搭載しているデバイスにアプリをインストールする際に、ユーザーが通知を有効のままにし、その後にデバイスを Android 13 以降にアップグレードした場合:

adb shell pm grant PACKAGE_NAME android.permission.POST_NOTIFICATIONS
adb shell pm set-permission-flags PACKAGE_NAME \
  android.permission.POST_NOTIFICATIONS user-set
adb shell pm clear-permission-flags PACKAGE_NAME \
  android.permission.POST_NOTIFICATIONS user-fixed

12L 以下を搭載しているデバイスにアプリをインストールする際に、ユーザーが手動で通知を無効にし、その後にデバイスを Android 13 以降にアップグレードした場合:

adb shell pm revoke PACKAGE_NAME android.permission.POST_NOTIFICATIONS
adb shell pm set-permission-flags PACKAGE_NAME \
  android.permission.POST_NOTIFICATIONS user-set
adb shell pm clear-permission-flags PACKAGE_NAME \
  android.permission.POST_NOTIFICATIONS user-fixed

おすすめの方法

このセクションでは、新しい通知権限をアプリで最も効果的に使用するためのいくつかの方法について説明します。

アプリのターゲット SDK バージョンを更新する

権限ダイアログが表示されるタイミングをより柔軟に制御するには、アプリを更新して Android 13 以降をターゲットに設定します。

通知権限プロンプトを表示するまで通知の送信を控える

ユーザーに権限の付与をリクエストする前に、アプリに関する十分な説明をユーザーに提供します。

新規ユーザーは、多くの場合、アプリを操作しながら個々の通知リクエストのメリットを直接確かめようとします。アプリでは、ユーザーアクションから権限プロンプトをトリガーすることができます。通知権限プロンプトをいつ表示すればよいかについて、いくつかの例を次に示します。

ユーザーが「警報ベル」ボタンをタップしたとき。
ユーザーが誰かのソーシャルメディアアカウントをフォローすることを選択したとき。
ユーザーが料理の宅配を注文したとき。

図 1 は、通知権限をリクエストする際の推奨されるワークフローを示しています。shouldShowRequestPermissionRationale() が true を返さない限り、アプリに中央の画面（タイトルが「Get notified!」の画面）を表示する必要はありません。

代わりに、ユーザーがアプリに慣れてからリクエストが表示されるように設定できます。たとえば、ユーザーがアプリを 3 回か 4 回起動した後に初めて表示することもできます。

ユーザーがログインすると、旅行に関する最新情報の通知を受け取るようすすめられます。ユーザーが [I'm in] ボタンを押すと、アプリは新しい権限をリクエストし、それによってシステムダイアログが表示されます。 — **図 1.** 通知権限をリクエストする際のユーザー主導のワークフロー。中央の画面は、`shouldShowRequestPermissionRationale()` が `true` を返す場合にのみ必要です。

コンテキストに応じて権限をリクエストする

アプリ内で通知権限をリクエストする場合は、適切なコンテキストでリクエストし、通知の用途とユーザーがオプトインした方がよい理由を明確に示します。たとえば、メールアプリには、新着メールごとに通知を送信するオプションや、そのユーザーが唯一の受信者であるメールについてのみ通知を送信するオプションが含まれていることがあります。

この機会を利用して通知の意図を明確に示すと、ユーザーがアプリに通知権限を付与する可能性が高まります。

アプリから通知を送信できるかどうかを確認する

アプリから通知を送信する前に、ユーザーがアプリの通知を有効にしているかどうかを確認します。そのためには、areNotificationsEnabled() を呼び出します。

責任を持って権限を使用する

通知を送信する承認が得られたら、責任を持って権限を使用してください。ユーザーは、アプリが送信した 1 日あたりの通知の数を確認できます。また、いつでも権限を取り消すことができます。