个推发布《Android13 适配指南》，解读 Android13 新特性

作者：个推

2022-11-25
浙江
本文字数：6098 字
阅读完需：约 20 分钟

8 月 16 日，谷歌宣布 Android13 新系统的源代码已经上传到 Android 开源项目（AOSP）中，Android13 正式发布。自从 2022 年 2 月 Android13 第一个预览版上线以来，历经 7 个月的测试和优化，正式版本的 Android13 终于来了！Android13 仍然聚焦个人隐私保护和安全，并提供了万物互联时代下大小屏适配、电池利用率优化等相关的技术开发能力。

个推服务开发者多年，一直密切关注和跟进行业发展趋势。Android13 正式版发布后，我们使用模拟器进行了研究和适配测试。本文将从权限变更、系统优化、功能更新等方面来谈谈 Android13 新特性，以帮助开发者快速上手完成 Android 新系统的适配。

权限变更

通知栏消息一直是 App 和用户沟通的有效渠道。在 Android13 之前，App 只需要使用 NotificationManager 即可向终端用户推送通知栏消息。Android13 则引入了新的运行时通知权限： POST_NOTIFICATIONS 。对此，App 开发者需要予以重点关注。

个推对该权限进行了测试，总结如下：

1. 首先看 TargetSdk<33 的情况。

如下图，当 App 使用通知栏功能时，系统将自动弹出授权弹窗：

用户点击“允许”，App 可正常给用户推送消息：

2. 再看 TargetSdk == 33 的情况。

开发者需要在 AndroidManifest.xml 中声明 POST_NOTIFICATIONS 权限，还需要在使用通知栏推送功能时在代码中申请运行时权限：

<?xml version="1.0" encoding="utf-8"?><manifest xmlns:android="http://schemas.android.com/apk/res/android" xmlns:tools= "http://schemas.android.com/tools" package= "com.gt.demo.mubai.push" > <uses-permission android:name= "android.permission.POST_NOTIFICATIONS" /></manifest> requestPermissions(new String[]{“android.permission.POST_NOTIFICATIONS”})

以上是用户点击“允许”App 推送的情况。当然，用户也有可能点击“不允许”。值得注意的是， 一旦被用户拒绝授权，下次系统将不会再出现权限申请的弹窗。

如果 App 仍然要推送重要消息（比如重大版本更新）给用户，则需要引导用户前往设置界面打开通知权限。代码如下：

private void jumpNotificationSetting () { final ApplicationInfo applicationInfo = getApplicationInfo(); try { Intent intent = new Intent(); intent.setFlags(Intent.FLAG_ACTIVITY_NEW_TASK); intent.setAction( "android.settings.APP_NOTIFICATION_SETTINGS" ); intent.putExtra( "app_package" , applicationInfo.packageName); intent.putExtra( "android.provider.extra.APP_PACKAGE" , applicationInfo.packageName); intent.putExtra( "app_uid" , applicationInfo.uid); startActivity(intent); } catch (Throwable t) { t.printStackTrace(); Intent intent = new Intent(); intent.setFlags(Intent.FLAG_ACTIVITY_NEW_TASK); intent.setAction( "android.settings.APPLICATION_DETAILS_SETTINGS" ); intent.setData(Uri.fromParts( "package" , applicationInfo.packageName, null )); startActivity(intent); }}

★ 温馨提示：

如果 App 要确认用户是否已启用通知，可以调用 NotificationManager.areNotificationsEnabled()进行判断。

另外，除了“允许”和“不允许”两种选择外，用户还可以 划走权限申请对话框（User swipes away from dialog） ，即用户未选择授权（也未选择不授权）。那么下次 App 进行通知栏消息推送时，系统将再次弹出用户授权弹窗。

Android13 的通知权限变更将使终端用户的体验得到极大改善。用户能够自主选择是否接受 App 推送的通知栏消息，减少被无效信息频繁打扰的情况。
个推以消息推送服务起家，也一直倡导绿色推送，强调在合适的时间、合适的地点、合适的场景把合适的内容推送给合适的人群，给终端用户更好的体验。

二、WiFi 权限变更

Android13 对 WiFi 权限的变更也是一大重点。在万物互联的当下，不同的智能家居/智能穿戴设备多是通过 WiFi 互通互联，因此这些类型的 App 开发者更要着重关注该部分内容。

在以往版本的 Android 系统下，如果 App 要使用 WiFi 相关功能，需要申请 ACCESS_FINE_LOCATION ，即位置权限，如下图：

图片来源于 Android13 官网

为了避免 App 过度索权，更好地保护终端用户隐私， Android13 将 WiFi 权限从位置权限中分离了出来 ，引入了新的运行时权限： NEARBY_WIFI_DEVICES 。

如果 App 仅需要使用 WiFi 相关的 API，并不需要使用 getScanResults()、startScan()等与位置相关的 API，那么建议 App 开发者切换到新的 NEARBY_WIFI_DEVICES 权限。

新的 WiFi 权限运行机制：

图片来源于 Android13 官网

权限使用和适配：

开发者需要注意的是，如果你的应用（targetSdk == 33） 已经声明不会根据 WiFi 信息推导设备的物理位置信息 ，那就不再需要声明 ACCESS_FINE_LOCATION 权限。

另外，如果应用 在 Android13 上只使用 WiFi API 而不使用位置信息 ，那开发者可以在 AndroidManifest.xml 中增加 NEARBY_WIFI_DEVICES 权限，并将 usesPermissionFlags 属性设为 neverForLocation，给 ACCESS_FINE_LOCATION 权限增加 maxSdkVersion="32"的限制，代码如下：

三、更细分的媒体权限

除了通知权限和 WiFi 权限的更新外，Android13 对本地数据访问权限也做了进一步细化。

Android13 将 READ_EXTERNAL_STORAGE 和 WRITE_EXTERNAL_STORAGE 权限细分为： READ_MEDIA_IMAGES 、 READ_MEDIA_VIDEO 和 READ_MEDIA_AUDIO ，如下图：

图片来源于 Android13 官网

个推使用 android.permission.READ.MEDIA_IMAGES，对新权限进行了测试：

我们发现，单独请求 READ_MEDIA_IMAGES、单独请求 READ_MEDIA_VIDEO 和同时请求 READ_MEDIA_IMAGES& READ_MEDIA_VIDEO，系统均将 只显示一个授权弹窗 。

另外， 如果 App（targetSdk == 33）已经申请了读的权限，那 App 同时也就有了写的权限 ，无需再额外声明 WRITE_EXTERNAL_STORAGE 权限，代码如下：

四、精确的闹钟权限

为了节省系统资源，Android12 引入了 SCHEDULE_EXACT_ALARM 权限进行“闹钟和提醒”功能的授权管理。Android13 则又引入了新的闹钟权限 USE_EXACT_ALARM 。

和 Android12 的 SCHEDULE_EXACT_ALARM 权限不同，如果 App 已经申请使用了 USE_EXACT_ALARM 新权限，那么用户是不能在设置页面里关闭授权的。

对于日程管理、时间管理等类型的 App 来讲，Android13 引入的 USE_EXACT_ALARM 权限能够带来一定便利。相比 Android12 的 SCHEDULE_EXACT_ALARM 权限，使用新权限的应用将不再需要频繁打扰用户进行授权，能够更高效地为用户提供闹钟、日程提醒等服务。

不过，为了防止新权限被滥用，GooglePlay 设置了严格的上架审核机制。开发者要注意，一旦使用了 USE_EXACT_ALARM 权限，App 在上架 GooglePlay 时将会被平台严格审查。 除非 App 属于闹钟、计时器、日历等类型的应用或者在已被列入到应用市场的白名单里，否则 GooglePlay 将不会允许使用该权限的应用上架。

随着我国对 App 用户个人权益保护力度的不断加大，相信后续国内的手机厂商和应用市场也将跟进建立相应的审查机制，增强对用户权益的保护。建议 App 开发者持续关注相关动态，及时做好适配工作。

五、后台的传感器权限

如今生物信息安全也是大众关注的焦点。为了更好地保护终端用户的个人生物信息，Android13 增加了新的后台传感器权限。

App 在后台运行时，如果需要获取心率、体温、血氧饱和度等传感器信息，将不仅需要向用户申请现有的 BODY_SENSORS 权限，还必须声明新的 BODY_SENSORS_BACKGROUND 权限。

综上可以看到，Android13 对个人隐私保护的重视和加强。除了权限变更方面，Android13 还进行了系统优化、组件更新，以进一步提升系统的安全性和友好性。

系统优化

一、更安全的系统组件

IntentFilter

在之前版本的 Android 系统中，开发者只需将 android:exported 设为 true 就可以跨应用显式启动 Activity 和 Service，即使 intent-filter 中的 action 或者 type 不匹配，也能够启动。

为避免上述漏洞，Android 13 增强了 intent-filter 的匹配过滤逻辑。 在接收方的 targetSdk == 33 的情况下，如果 intent-filter 匹配命中，无论发送方的 targetSdk 版本如何，intent 都将生效。

★ 温馨提示：

以下几种情况不需要遵循 intent-filter 的匹配过滤逻辑：

组件没有声明
同一个 App 里的 intent
系统或 Root 进程发出的 intent

BroadcastReceiver

以往的 Android 系统下，应用动态注册的 BroadcastReceiver 广播接收器会接收到任何应用发送的广播（除非该接收器使用了应用签名权限保护），这会使动态注册的广播接收器存在安全风险。

Android13 要求， 应用动态注册的广播接收器必须以显著的方式指出是否允许其他应用访问 ，即其他应用是否可以向其发送广播。否则，在动态注册时系统将抛出安全异常（SecurityException）。

目前该增强措施并非默认生效，开发者需启用 DYNAMIC_RECEIVER_EXPLICIT_EXPORT_REQUIRED 兼容性框架，并在动态注册广播时指定是否接受其他应用的广播：

context.registerReceiver( receiver , intentFilter , RECEIVER_EXPORTED ) context .registerReceiver( receiver , intentFilter , RECEIVER_NOT_EXPORTED )

★ 温馨提示：

系统广播不受 RECEIVER_NOT_EXPORTED 影响。

二、前台服务(FGS)任务管理器

Android13 还新增了前台服务（FGS）任务管理器功能。

如下图，用户可以在下拉的通知栏中直接关闭前台服务和应用程序：

此外，如果系统检测到应用长时间运行某项前台服务 （在 24 小时的时间段内至少运行 20 小时） ，便会向用户发送提醒通知，通知内容如下：

APP is running in the background for a long time. Tap to review.

值得注意的是，满足以下任一条件的情况下，系统均将不会显示该通知：

已经发送过前台服务相关的通知，也就是说，用户未关闭之前的提醒通知
前台服务的类型为 FOREGROUND_SERVICE_TYPE_MEDIA_PLAYBACK 或 FOREGROUND_SERVICE_TYPE_LOCATION

★ 温馨提示：

如果系统针对某应用已经显示过此通知，那至少在 30 天后系统才会再次显示该通知。另外，系统级应用、安全应用（比如具有 android.app.role.EMERGENCY 角色的应用）等运行的前台服务，将不会显示在 FGS 任务管理器中。

三、通知权限

Android9 引入了 应用待机存储分区功能 ，根据应用的使用时间和频率，将应用动态分配到五个不同优先级的存储分区，然后对不同存储分区的应用施加不同级别的应用资源限制。

如下， 存储分区按照优先级从高到低排序，优先级越低对该分区内的 App 限制越多 ：

活跃：应用目前正在使用中，或者最近刚刚使用过。
工作集：应用会定期使用。
常用：应用会经常使用，但不会每天使用。
极少使用：应用不经常使用。
受限：应用会消耗大量的系统资源，或表现出不良行为（Android11 引入）。

其中“受限”状态的应用，将受到以下限制：

无法启动前台服务。
现有的前台服务会从前台移除。
不会触发闹钟。
不会执行 Jobs。

在 Android9 应用待机存储分区功能的基础上，Android13 对电池资源策略进行了优化，以延长设备的电池续航时间，提升终端用户的体验。

首先，Android13 新增了以下规则， 符合相应规则的应用将进入到“受限”存储分区 （设备处于关闭状态的时间不会计入互动限制）：

用户已经 8 天没有与应用互动。
应用在 1 天内调用过多的广播或者绑定服务。
应用在 1 天内消耗了大量的电池电量，阈值取决于设备。

其次，Android13 还对“受限”存储分区的应用增加了限制措施：

应用将不收受到 BOOT_COMPLETED、LOCKED_BOOT_COMPLETED 广播

四、对 non-SDK 接口限制的更新

Android 13 对一些 non-SDK 接口进行了限制（并针对部分限制提供了替代方案）。开发者需要明确 App 在升级时是否使用了受限的 non-SDK 接口。

Android13 中受限的 non-SDK 接口参考：

Landroid/app/Activity;->setDisablePreviewScreenshots(Z)V # Use setRecentsScreenshotEnabled() instead. Landroid/os/PowerManager;->isLightDeviceIdleMode()Z # Use isDeviceLightIdleMode() instead. Landroid/os/Process;->setArgV0(Ljava/lang/String;)V # In general, do not try to change the process name. If you must change the process name (for instance, for debugging), you can use pthread_setname_np() instead, though be aware that doing this might confuse the system. Landroid/view/accessibility/AccessibilityInteractionClient;->clearCache(I)V # Use android.accessibilityservice.AccessibilityService#clearCache() instead.