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

个推技术

于 2022-09-05 11:08:16 发布

阅读量1.8k

点赞数 1

分类专栏：实时数仓数据仓库治数训练营文章标签： android java android studio

本文链接：https://blog.csdn.net/Androilly/article/details/126700840

版权

治数训练营同时被 3 个专栏收录

10 篇文章 0 订阅

订阅专栏

实时数仓

3 篇文章 0 订阅

订阅专栏

数据仓库

2 篇文章 0 订阅

订阅专栏

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

感兴趣的开发者可以登录官网下载源码测试学习：https://developer.android.google.cn/about/versions/13

个推服务开发者多年，一直密切关注和跟进行业发展趋势。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"的限制，代码如下：

<manifest ...>
    <uses-permission android:name="android.permission.NEARBY_WIFI_DEVICES"       
                     android:usesPermissionFlags="neverForLocation"/>
  
    <uses-permission android:name="android.permission.ACCESS_FINE_LOCATION"
                     android:maxSdkVersion="32" />
</manifest>复制

三、更细分的媒体权限

除了通知权限和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权限，代码如下：

<manifest ...>
    <uses-permission android:name="android.permission.READ_MEDIA_IMAGES" />
    <uses-permission android:name="android.permission.READ_MEDIA_AUDIO" />
    <uses-permission android:name="android.permission.READ_MEDIA_VIDEO" />
  
    <uses-permission android:name="android.permission.WRITE_EXTERNAL_STORAGE"
                       android:maxSdkVersion="32" />
</manifest>复制

四、精确的闹钟权限

为了节省系统资源，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.复制