À partir du 27 mars 2025, nous vous recommandons d'utiliser android-latest-release au lieu de aosp-main pour créer et contribuer à AOSP. Pour en savoir plus, consultez la section Modifications apportées à AOSP.
Autorisation de notification pour les notifications nécessitant une confirmation
Restez organisé à l'aide des collections
Enregistrez et classez les contenus selon vos préférences.
Les notifications dans Android 13 utilisent un modèle d'activation, ce qui diffère des versions précédentes d'Android, qui utilisent un modèle de désactivation. Sous Android 13, toutes les applications doivent demander aux utilisateurs l'autorisation avant d'envoyer des invites de notification. Ce modèle permet de réduire les interruptions liées aux notifications, de limiter la surcharge d'informations et d'aider les utilisateurs à contrôler les notifications qui s'affichent en fonction de ce qui est important pour eux. Pour prendre en charge le modèle d'activation, les OEM doivent implémenter des modifications dans les systèmes de notification et d'autorisation d'exécution.
Cette page décrit ce que les OEM doivent implémenter pour prendre en charge ce changement et comment valider l'implémentation.
Implémenter les modifications apportées aux notifications nécessitant une confirmation
À partir d'Android 13, les applications doivent déclarer leur intention d'envoyer des notifications en demandant l'autorisation d'exécution android.permission.POST_NOTIFICATION au système avant de pouvoir envoyer des notifications.
Sous Android 13 ou version ultérieure, le paramètre qui détermine si une application peut envoyer des notifications à l'utilisateur est stocké dans le système d'autorisations.
Avant Android 13, ce paramètre était stocké dans le système de notification. Par conséquent, les OEM doivent migrer les données de notification existantes indiquant si une application est autorisée à envoyer des notifications, du système de notification vers le système d'autorisation d'exécution. Les OEM doivent également gérer les API existantes dans le système de notification qui présentent ces données aux développeurs d'applications.
Les modifications apportées aux systèmes de notification et d'autorisation sont basées sur le modèle d'activation du comportement des notifications utilisateur et sont décrites dans la section Consignes d'implémentation.
Comportement des notifications utilisateur dans un modèle nécessitant une confirmation
Le tableau suivant illustre le comportement des notifications pour différentes versions d'applications sur un appareil équipé d'Android 13:
| Appareil sous Android 13 |
Applications ciblant Android 13 ou version ultérieure |
Applications ciblant des versions antérieures à Android 13 |
| Nouvelle installation
|
Les notifications sont bloquées jusqu'à ce que l'application vous invite à les activer.
Les applications contrôlent le moment où elles doivent demander une autorisation.
|
Les notifications sont bloquées jusqu'à ce que l'OS les autorise.
L'autorisation est demandée lors du premier lancement de l'application.
|
| Application existante (mise à niveau)
|
Les notifications sont autorisées jusqu'à ce que l'application en demande.
L'autorisation temporaire est accordée jusqu'à ce que l'application demande l'autorisation lors de la première exécution éligible.
|
Les notifications sont autorisées jusqu'à ce que l'OS vous invite à les désactiver.
L'autorisation temporaire est accordée jusqu'à la première exécution de l'application.
|
Consignes d'implémentation
Pour une implémentation de référence, consultez les sections service de notification, service d'autorisation et service de règles. Pour implémenter des exceptions pour les gestionnaires d'autorisations par défaut, consultez la section Autorisations d'exécution.
Lors de l'implémentation, suivez les consignes suivantes sur le comportement des notifications utilisateur pour les applications ciblant les SDK Android 13 ou versions antérieures:
- Les applications fraîchement installées sur un appareil Android 13 ne doivent pas envoyer de notification sans que l'utilisateur n'approuve une invite d'autorisation.
- Si l'application cible les versions Android 13 et ultérieures, les notifications doivent être bloquées jusqu'à ce que l'application le demande, car elle contrôle quand et si elle doit demander l'autorisation de l'utilisateur.
- Si l'application cible des versions antérieures à Android 13, les notifications doivent être bloquées jusqu'à ce que l'OS les demande. L'OS doit afficher l'invite d'autorisation lors du premier lancement de l'application.
Toute application qui existait sur l'appareil avant la mise à niveau vers Android 13 ou toute application qui a été restaurée via la sauvegarde et la restauration doit être autorisée à envoyer des notifications jusqu'à la première fois que l'utilisateur lance une activité à partir de cette application.
Pour les applications qui ciblent le SDK des versions Android 13 et ultérieures, si l'utilisateur n'a pas encore personnalisé les paramètres de notification de cette application au niveau de l'application ou de NotificationChannel, révoquez l'autorisation temporaire. Les applications doivent ensuite demander l'autorisation à l'utilisateur avant de pouvoir continuer à envoyer des notifications.
Si une application mise à niveau ciblant Android 13 ne dispose pas actuellement de l'autorisation de notification via l'autorisation de mise à niveau temporaire et que l'utilisateur l'a lancée au moins une fois, l'application doit afficher une invite d'autorisation de notification avant d'être autorisée à exécuter d'autres services de premier plan.
Pour les applications dont le SDK cible est une version antérieure à Android 13, interceptez le premier lancement d'activité après que l'application a créé au moins un NotificationChannel pour afficher une invite d'autorisation demandant à l'utilisateur s'il souhaite recevoir des notifications de l'application.
Si un utilisateur a précédemment personnalisé les paramètres de notification au niveau de l'application ou de NotificationChannel pour une application sur l'appareil en cours de mise à niveau ou dans une sauvegarde restaurée sur l'appareil, le paramètre au niveau de l'application doit être migré vers le système d'autorisation avec l'indicateur FLAG_PERMISSION_USER_SET. Aucune autre invite d'autorisation de notification ne doit être présentée à l'utilisateur, sauf si l'application le demande spécifiquement.
La sauvegarde et la restauration doivent être rétrocompatibles et évolutives entre un appareil Android 13 et un appareil équipé d'une version antérieure de l'OS. Les données de sauvegarde générées à partir d'un appareil Android 13 doivent être restaurées sur une version antérieure de l'OS, et les données de sauvegarde d'une version antérieure de l'OS doivent être restaurées sur un appareil Android 13.
Les notifications multimédias associées à la lecture multimédia en cours doivent être exemptées de l'autorisation de notification.
Valider les modifications apportées aux systèmes de notification et d'autorisation
Pour valider l'implémentation, exécutez les tests suivants:
Le contenu et les exemples de code de cette page sont soumis aux licences décrites dans la Licence de contenu. Java et OpenJDK sont des marques ou des marques déposées d'Oracle et/ou de ses sociétés affiliées.
Dernière mise à jour le 2025/07/27 (UTC).
[[["Facile à comprendre","easyToUnderstand","thumb-up"],["J'ai pu résoudre mon problème","solvedMyProblem","thumb-up"],["Autre","otherUp","thumb-up"]],[["Il n'y a pas l'information dont j'ai besoin","missingTheInformationINeed","thumb-down"],["Trop compliqué/Trop d'étapes","tooComplicatedTooManySteps","thumb-down"],["Obsolète","outOfDate","thumb-down"],["Problème de traduction","translationIssue","thumb-down"],["Mauvais exemple/Erreur de code","samplesCodeIssue","thumb-down"],["Autre","otherDown","thumb-down"]],["Dernière mise à jour le 2025/07/27 (UTC)."],[],[],null,["# Notification permission for opt-in notifications\n\nNotifications in Android 13 use an opt-in model, which\nis a change from previous Android versions, which use an opt-out model. In\nAndroid 13, all apps must ask users for permission before\nsending notification prompts. This model helps reduce notification\ninterruptions, minimizes information overload, and helps users control what\nnotifications appear based on what's important to them. To support the\nopt-in model, OEMs must implement changes in the notification and runtime\npermission systems.\n\nThis page describes what OEMs must implement to support this change and how\nto validate the implementation.\n\nImplement changes for opt-in notifications\n------------------------------------------\n\nStarting with Android 13, apps must declare their\nintent to send notifications by requesting the\n[`android.permission.POST_NOTIFICATION`](https://developer.android.com/about/versions/13/changes/notification-permission)\nruntime permission from the system before they can send notifications.\n\nIn Android 13 and higher, the setting that determines\nif an app can send notifications to the user is stored in the permission system.\nPrior to Android 13, this setting was stored in the\nnotification system. Hence, OEMs must migrate the existing notification data\nabout whether an app is allowed to send notifications, from the notification\nsystem into the runtime permission system. OEMs must also maintain existing APIs\nin the notification system that surface that data to app developers.\n\nChanges to the notification and permission systems are based on the\n[opt-in model of user notification behavior](#behavior-optin) and are\ndescribed in the [Guidelines for implementation](#guidelines-impl) section.\n\n### Behavior of user notifications in an opt-in model\n\nThe following table illustrates the notification behavior for various app\nversions on a device running Android 13:\n\n| Device on Android 13 | Apps targeting Android 13 or higher | Apps targeting versions lower than Android 13 |\n|------------------------|--------------------------------------------------------------------------------------------------------------------------------------|---------------------------------------------------------------------------------------------------------------------|\n| New install | Notifications are blocked until prompted by the app. Apps control when to ask for permission. | Notifications are blocked until prompted by the OS. Permission is asked on the first run of the app. |\n| Existing app (upgrade) | Notifications are allowed until prompted by the app. Temporary permission is granted until the app asks on the first qualifying run. | Notifications are allowed until prompted by the OS. Temporary permission is granted until the first run of the app. |\n\n### Guidelines for implementation\n\nFor reference implementation, refer to\n[notification service](https://cs.android.com/android/platform/superproject/+/android-latest-release:frameworks/base/services/core/java/com/android/server/notification/),\n[permission service](https://cs.android.com/android/platform/superproject/+/android-latest-release:frameworks/base/services/core/java/com/android/server/pm/permission/) and\n[policy service](https://cs.android.com/android/platform/superproject/+/android-latest-release:frameworks/base/services/core/java/com/android/server/policy). To implement exceptions\nfor default permission handlers see\n[Runtime Permissions](/docs/core/permissions/runtime_perms#integration).\n\nDuring implementation, use the following guidelines on user notification\nbehavior for apps targeting Android 13 or lower SDKs:\n\n- Freshly installed apps on an Android 13 device must not send a notification without the user approving a permission prompt.\n - If the app targets versions Android 13 and higher, notifications must be blocked until prompted by the app as the app controls when and if to ask for user permission.\n - If the app targets versions lower than Android 13, notifications must be blocked until prompted by the OS. The OS must show the permission prompt on the first run of the app.\n- Any app that existed on the device prior to an upgrade to\n Android 13, or any app that was restored through backup\n and restore, must be allowed to send notifications until the first time the user\n launches an activity from that app.\n\n - For apps that target SDK of versions Android 13\n and higher, if the user hasn't previously customized notification settings for\n this app at the app or `NotificationChannel` level, revoke the temporary\n permission grant. Apps must then ask the user for permission before being\n allowed to continue to send notifications.\n\n If an upgraded app targeting Android 13 doesn't\n currently have the notification permission through the temporary upgrade\n grant, and the user has launched it at least once, the app must show a\n notification permission prompt before it's allowed to run any further foreground\n services.\n - For apps that have a target SDK of versions lower than\n Android 13,\n [intercept](https://cs.android.com/android/platform/superproject/+/android-latest-release:frameworks/base/services/core/java/com/android/server/wm/ActivityInterceptorCallback.java)\n the first activity launch after the app has created at least one `NotificationChannel`\n to show a permission prompt asking if the user wants to receive notifications\n from the app.\n\n If a user previously customized notification settings at the\n app or `NotificationChannel` level for an app on the upgrading device or in a\n backup being restored to the device, the app level setting must be migrated into\n the permission system with the `FLAG_PERMISSION_USER_SET` flag. No further\n notification permission prompt must be shown to the user unless the app\n specifically asks it to be.\n- Backup and restore must be backward and forward compatible between an\n Android 13 device and a device from an earlier OS\n version. Backup data generated from an Android 13\n device must restore onto an earlier OS version, and backup data from an earlier\n OS version must restore onto an Android 13 device.\n\n- Media notifications associated with ongoing media playback must be exempt\n from the notification permission.\n\nValidate changes to the notification and permission systems\n-----------------------------------------------------------\n\nTo validate the implementation, run the following tests:\n\n- Unit tests as specified in [`PreferencesHelperTest`](https://cs.android.com/android/platform/superproject/+/android-latest-release:frameworks/base/services/tests/uiservicestests/src/com/android/server/notification/PreferencesHelperTest.java),\n [`NotificationManagerServiceTest`](https://cs.android.com/android/platform/superproject/+/android-latest-release:frameworks/base/services/tests/uiservicestests/src/com/android/server/notification/NotificationManagerServiceTest.java).\n\n- Any manual test that tests upgrades and backup and restore.\n\n- Any CTS Permission and Notification system test that sends notifications.\n Some of these tests are located in [cts/tests/tests/permission/](https://cs.android.com/android/platform/superproject/+/android-latest-release:packages/modules/Permission/tests/cts/permission/src/android/permission/cts/),\n [NotificationManagerTest.java](https://cs.android.com/android/platform/superproject/+/android-latest-release:cts/tests/tests/notification/src/android/app/notification/current/cts/NotificationManagerTest.java?q=NotificationManagerTest.java),\n and [cts/tests/tests/notificationlegacy/](https://cs.android.com/android/platform/superproject/+/android-latest-release:cts/tests/tests/notificationlegacy/)."]]
