Autorisation d'exécution des notifications

Android 13 (niveau d'API 33) ou version ultérieure accepte une autorisation d'exécution pour l'envoi de notifications non exemptées (y compris les services de premier plan) depuis une application : POST_NOTIFICATIONS. Ce changement permet aux utilisateurs de se concentrer sur les notifications les plus importantes pour eux.

Nous vous recommandons vivement de cibler Android 13 ou version ultérieure dès que possible pour bénéficier du contrôle et de la flexibilité supplémentaires de cette fonctionnalité. Si vous continuez à cibler la version 12L (niveau d'API 32) ou une version antérieure, vous perdrez en flexibilité pour demander l'autorisation dans le contexte des fonctionnalités de votre application.

Remarque : Les applications n'ont pas besoin de demander l'autorisation POST_NOTIFICATIONS pour lancer un service de premier plan. Toutefois, les applications doivent inclure une notification lorsqu'elles démarrent un service de premier plan, comme elles le font sur les versions précédentes d'Android.

Déclarer l'autorisation

Pour demander la nouvelle autorisation de notification depuis votre application, mettez-la à jour pour cibler Android 13 et suivez une procédure semblable à celle permettant de demander d'autres autorisations d'exécution, comme indiqué dans les sections suivantes.

L'autorisation que vous devez déclarer dans le fichier manifeste de votre application apparaît dans l'extrait de code suivant :

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

Les capacités de l'application dépendent du choix utilisateur dans la boîte de dialogue des autorisations

Dans cette boîte de dialogue, les utilisateurs peuvent effectuer les actions suivantes :

• Sélectionnez Autoriser.
• Sélectionnez Ne pas autoriser.
• Balayez l'écran pour fermer la boîte de dialogue sans appuyer sur aucun bouton.

Les sections suivantes décrivent le comportement de votre application en fonction de l'action effectuée par l'utilisateur.

L'utilisateur sélectionne "Autoriser".

Si l'utilisateur sélectionne l'option Autoriser, votre application peut effectuer les opérations suivantes :

• Envoyer des notifications Tous les canaux de notification sont autorisés.
• Publier des notifications liées aux services de premier plan. Ces notifications s'affichent dans le panneau des notifications.

L'utilisateur sélectionne "Ne pas autoriser"

Si l'utilisateur sélectionne l'option Ne pas autoriser, votre application ne peut pas envoyer de notifications, sauf si elle bénéficie d'une exception. Tous les canaux de notification sont bloqués, à l'exception de quelques rôles spécifiques. Ce comportement est semblable à celui qui se produit lorsque l'utilisateur désactive manuellement toutes les notifications de votre application dans les paramètres système.

Attention : Si votre application cible 12L ou une version antérieure et que l'utilisateur appuie sur Ne pas autoriser, même une seule fois, il n'est plus invité à le faire jusqu'à ce qu'il désinstalle et réinstalle votre application, ou que vous mettiez à jour votre application pour cibler Android 13 ou une version ultérieure.

L'utilisateur balaie l'écran pour quitter la boîte de dialogue

Si l'utilisateur balaie la boîte de dialogue (c'est-à-dire qu'il ne sélectionne ni Autoriser, ni Ne pas autoriser), l'état de l'autorisation de notification ne change pas.

Effets sur les applications récemment installées

Si un utilisateur installe votre application sur un appareil exécutant Android 13 ou une version ultérieure, les notifications de votre application sont désactivées par défaut. Votre application doit attendre que vous demandiez la nouvelle autorisation et que l'utilisateur l'accorde à votre application avant d'envoyer des notifications.

Le moment où la boîte de dialogue des autorisations s'affiche dépend de la version du SDK cible de votre application :

• Si votre application cible Android 13 ou une version ultérieure, elle contrôle entièrement le moment où la boîte de dialogue d'autorisation s'affiche. Profitez-en pour expliquer aux utilisateurs pourquoi l'application a besoin de cette autorisation et les encourager à l'accorder.
• Si votre application cible la version 12L (niveau d'API 32) ou une version antérieure, le système affiche la boîte de dialogue d'autorisation la première fois que votre application démarre une activité après la création d'un canal de notification, ou lorsque votre application démarre une activité, puis crée son premier canal de notification. Cela se produit généralement au démarrage de l'application. Dans les applications à activité unique, comme la plupart des applications Compose, le système affiche la boîte de dialogue au démarrage de MainActivity.

Effets sur les mises à jour d'applications existantes

Pour limiter les perturbations liées à l'autorisation de notification, le système préaccorde automatiquement l'autorisation à toutes les applications éligibles lorsque l'utilisateur met à niveau son appareil vers Android 13 ou une version ultérieure. En d'autres termes, ces applications peuvent continuer à envoyer des notifications aux utilisateurs, et ceux-ci ne voient pas d'invite d'autorisation d'exécution.

Remarque : Prenons l'exemple d'une application éligible installée sur un appareil exécutant Android 12L ou une version antérieure que l'utilisateur n'utilise plus, et pour laquelle l'utilisateur a autorisé les notifications sur cet ancien appareil. L'utilisateur dispose désormais d'un nouvel appareil équipé d'Android 13 ou version ultérieure et restaure l'application à l'aide de la fonctionnalité de sauvegarde et de restauration.

Dans ce cas, le système considère votre application comme une "application existante" et lui accorde automatiquement l'autorisation pour qu'elle puisse continuer à envoyer des notifications.

Éligibilité à l'octroi préalable d'autorisations

Pour que votre application soit éligible à une pré-autorisation automatique, elle doit disposer d'un canal de notification existant et ses notifications ne doivent pas avoir été explicitement désactivées par l'utilisateur sur un appareil exécutant 12L ou une version antérieure.

Si l'utilisateur a désactivé les notifications pour votre application sur un appareil exécutant 12L ou une version antérieure, ce refus persiste lorsque l'appareil passe à Android 13 ou une version ultérieure.

Exceptions

Cette section contient l'ensemble des notifications et des applications qui ne sont pas concernées par le changement de comportement de l'autorisation de notification. Sur Android 13 (niveau d'API 33) ou version ultérieure, si l'utilisateur refuse l'autorisation de notification, il voit toujours les notifications liées aux services de premier plan dans le Gestionnaire des tâches, mais pas dans le volet des notifications.

Sessions multimédias

Les notifications liées aux sessions multimédias ne sont pas concernées par ce changement de comportement.

Applications configurées pour autogérer les appels téléphoniques

Si votre application se configure pour gérer elle-même les appels téléphoniques, vous n'avez pas besoin de l'autorisation POST_NOTIFICATIONS pour que votre application envoie des notifications utilisant le style de notification Notification.CallStyle.

Le système considère que votre application s'est configurée pour l'autogestion des appels téléphoniques si elle effectue chacune des opérations suivantes :

1. Déclare l'autorisation MANAGE_OWN_CALLS.
2. Implémente l'interface ConnectionService.
3. S'enregistre auprès de l'opérateur de télécommunications de l'appareil en appelant registerPhoneAccount().

Tester votre application

Vous pouvez évaluer l'impact de l'autorisation de notification sur votre application lors de sa première utilisation sur un appareil équipé d'Android 13 ou version ultérieure. Les ensembles de commandes Android Debug Bridge (ADB) suivants vous permettent de simuler les séquences les plus courantes de choix utilisateur et de mises à niveau d'appareils sans avoir à réinitialiser votre appareil de test :

• L'application est nouvellement installée sur un appareil équipé d'Android 13 ou version ultérieure :

  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
  

• L'utilisateur laisse les notifications activées lorsque l'application est installée sur un appareil exécutant 12L ou une version antérieure, puis l'appareil passe à Android 13 ou une version ultérieure :

  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
  

• L'utilisateur désactive manuellement les notifications lorsque l'application est installée sur un appareil exécutant 12L ou une version antérieure, puis l'appareil passe à Android 13 ou une version ultérieure :

  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
  

Bonnes pratiques

Cette section décrit plusieurs façons d'utiliser efficacement la nouvelle autorisation de notification dans votre application.

Mettre à jour la version du SDK cible de votre application

Pour que votre application puisse contrôler plus précisément le moment où la boîte de dialogue d'autorisation s'affiche, mettez-la à jour pour qu'elle cible Android 13 ou une version ultérieure.

Attendre avant d'afficher l'invite d'autorisation de notification

Avant de demander aux utilisateurs d'accorder des autorisations, laissez-les se familiariser avec votre application.

Les nouveaux utilisateurs peuvent vouloir explorer l'application et se rendre compte par eux-mêmes des avantages de chaque demande de notification. Vous pouvez déclencher une invite d'autorisation à partir d'une action de l'utilisateur. La liste suivante présente plusieurs exemples de moments opportuns pour afficher l'invite d'autorisation de notification :

• L'utilisateur appuie sur un bouton en forme de cloche d'alerte.
• L'utilisateur choisit de suivre le compte d'un autre utilisateur sur un réseau social.
• L'utilisateur passe une commande de livraison de repas.

La figure 1 illustre un workflow recommandé pour demander l'autorisation de notification. Sauf si shouldShowRequestPermissionRationale() renvoie true, votre application n'a pas besoin d'afficher l'écran du milieu, celui qui porte le titre "Recevoir des notifications". Dans Compose, vous pouvez trouver l'élément Activity actuel en accédant à LocalContext.current et en le castant en Activity.

Vous pouvez également configurer une demande pour qu'elle s'affiche après avoir donné aux utilisateurs la possibilité de se familiariser avec votre application. Par exemple, vous pouvez attendre que l'utilisateur lance votre application pour la troisième ou quatrième fois.

Figure 1. Workflow recommandé basé sur l'utilisateur pour demander l'autorisation de notification. L'écran du milieu n'est nécessaire que si shouldShowRequestPermissionRationale() renvoie true.

Demander l'autorisation

Pour demander l'autorisation dans votre UI Compose, utilisez l'API rememberLauncherForActivityResult() avec le contrat ActivityResultContracts.RequestPermission().

L'extrait de code suivant montre comment demander l'autorisation de notification en réponse à une interaction de l'utilisateur :

Kotlin

val context = LocalContext.current
val permissionLauncher = rememberLauncherForActivityResult(
    ActivityResultContracts.RequestPermission()
) { isGranted ->
    if (isGranted) {
        // Permission granted, you can now send notifications.
    } else {
        // Permission denied, handle accordingly.
    }
}

// ... in your UI ...
Button(onClick = {
    if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.TIRAMISU) {
        permissionLauncher.launch(Manifest.permission.POST_NOTIFICATIONS)
    }
}) {
    Text("Enable Notifications")
}

Demander l'autorisation en contexte

Lorsque vous demandez des autorisations de notification dans votre application, faites-le dans le contexte approprié, afin que l'utilisateur comprenne clairement à quoi servent les notifications et pourquoi il doit les accepter. Par exemple, une application de messagerie peut inclure des options permettant d'envoyer des notifications pour chaque nouvel e-mail ou uniquement pour les e-mails dont l'utilisateur est le seul destinataire.

Profitez de cette occasion pour expliquer clairement vos intentions. Les utilisateurs seront ainsi plus susceptibles d'accorder l'autorisation de notification à votre application.

Vérifier si votre application peut envoyer des notifications

Avant que votre application n'envoie une notification, vérifiez si l'utilisateur a activé les notifications pour votre application. Pour ce faire, appelez areNotificationsEnabled().

Utiliser l'autorisation de manière responsable

Une fois que vous avez reçu l'autorisation d'envoyer des notifications, n'oubliez pas de l'utiliser de manière responsable. Les utilisateurs peuvent voir le nombre de notifications quotidiennes envoyées par votre application et révoquer l'autorisation à tout moment.