自 2025 年 3 月 27 日起,我们建议您使用 android-latest-release
而非 aosp-main
构建 AOSP 并为其做出贡献。如需了解详情,请参阅 AOSP 的变更。
“选择启用”通知的通知权限
使用集合让一切井井有条
根据您的偏好保存内容并对其进行分类。
Android 13 中的通知采用“选择启用”模式,这与旧版 Android 不同,旧版 Android 采用的是“选择停用”模式。在 Android 13 中,所有应用必须先请求用户授予权限,然后才能发送通知提示。此模式有助于减少通知打扰,尽可能避免发生信息过多的情况,并帮助用户根据重要程度控制显示通知。为了支持“选择启用”模式,OEM 必须在通知和运行时权限系统中实现变更。
本页将介绍 OEM 必须进行哪些实现才能支持这项变更,以及如何验证该实现。
实现“选择启用”通知功能所需的变更
从 Android 13 开始,应用必须先向系统请求 android.permission.POST_NOTIFICATION
运行时权限,以声明发送通知的意图,然后才能发送通知。
在 Android 13 及更高版本中,决定应用能否向用户发送通知的设置存储在权限系统中。在 Android 13 之前,此设置存储在通知系统中。因此,OEM 必须将关于是否允许应用发送通知的现有通知数据从通知系统迁移到运行时权限系统。此外,OEM 还必须维护通知系统中的现有 API,以向应用开发者提供上述数据。
对通知系统和权限系统做出的变更基于用户通知行为的“选择启用”模式,实现指南部分对此进行了说明。
“选择启用”模式中用户通知的行为
下表说明了搭载 Android 13 的设备上的各种应用版本的通知行为:
搭载 Android 13 的设备 |
以 Android 13 或更高版本为目标平台的应用 |
以低于 Android 13 的版本为目标平台的应用 |
新安装
|
系统会屏蔽通知,直至应用发出提示。
应用控制何时请求权限。
|
系统会屏蔽通知,直至操作系统发出提示。
首次运行应用时,系统会请求权限。
|
现有应用(升级)
|
系统会屏蔽通知,直至应用发出提示。
系统将授予临时权限,直至应用在首次符合条件地运行时发出请求。
|
系统会屏蔽通知,直至操作系统发出提示。
系统会授予临时权限,直至应用首次运行。
|
实现指南
有关参考实现,请参阅通知服务、权限服务和政策服务。如需为默认权限处理程序实现异常,请参阅运行时权限。
在实现过程中,对于以 Android 13 或更低版本的 SDK 为目标平台的应用,请遵循以下关于用户通知行为的准则:
- Android 13 设备上新安装的应用不得在未经用户批准权限提示的情况下发送通知。
- 如果应用以 Android 13 及更高版本为目标平台,则系统必须屏蔽通知,直至应用发出提示,因为应用控制着何时请求以及是否请求用户授予权限。
- 如果应用以低于 Android 13 的版本为目标平台,则系统必须屏蔽通知,直至操作系统发出提示。操作系统必须在应用首次运行时显示权限提示。
对于在设备升级到 Android 13 之前存在的任何应用,或通过“备份和恢复”功能恢复的任何应用,系统都必须允许发送通知,直至用户首次通过该应用启动一个 activity。
对于以 Android 13 及更高版本的 SDK 为目标平台的应用,如果用户之前未在应用或 NotificationChannel
级别自定义此应用的通知设置,请撤消授予临时权限。然后,系统必须请求用户授予权限,才能继续发送通知。
如果以 Android 13 为目标平台的升级后的应用目前未获得通过升级临时权限授权提供的通知权限,并且用户已启动该应用至少一次,则该应用必须先显示通知权限提示,才能运行任何其他前台服务。
对于以低于 Android 13 的版本的 SDK 为目标平台的应用,在应用创建至少一个 NotificationChannel
后,拦截首次 activity 启动以显示权限提示,询问用户是否想要接收来自应用的通知。
如果某用户之前在应用或 NotificationChannel
级别为升级设备上或要恢复到设备的备份中的应用的自定义了通知设置,应用级别的相应设置必须迁移到具有 FLAG_PERMISSION_USER_SET
标志的权限系统。除非应用明确要求,否则不得向用户显示其他通知权限提示。
在搭载 Android 13 的设备和使用较低操作系统版本的设备之间,备份和恢复必须向前和向后兼容。从搭载 Android 13 的设备生成的备份数据必须恢复到搭载早期操作系统版本的设备上,反之亦然。
与正在进行的媒体播放相关联的媒体通知不得受到通知权限的限制。
验证对通知和权限系统做出的变更
如需验证实现,请运行以下测试:
本页面上的内容和代码示例受内容许可部分所述许可的限制。Java 和 OpenJDK 是 Oracle 和/或其关联公司的注册商标。
最后更新时间 (UTC):2025-03-05。
[null,null,["最后更新时间 (UTC):2025-03-05。"],[],[],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/)."]]