Android 12 保姆级适配指南

·  阅读 4859
Android 12 保姆级适配指南

背景

邮件内容.png

近期,Google Play向所有的应用开发者发送了一封邮件,邮件中明确了应用将目标API级别更新为Android 12的最后期限。

这表示,Android 12的适配工作不得不提上日程了。

本着将改动最小化的原则,建议在开始适配之前,可以将此次需要适配的一系列行为变更,按照对自身项目的影响程度,先进行优先级划分,并依据此优先级去分批、逐步完成适配工作。

该如何进行划分呢?可能具体到每个人的项目情况都有所不同,这里提供一下笔者项目的适配任务优先级划分标准,供其他开发者参考:

P0:功能异常

指明确影响到了App功能的正常使用,甚至导致App无法正常启动或者崩溃率直线上升的行为变更。

P1:体验下降

指虽不影响功能正常使用,但可能导致获取数据的准确度下降,或者需要增加操作步骤进而影响用户体验的行为变更。

P2:可选优化

指对App本身没有什么实质影响,但做好适配后可以增强App健壮性或用户体验的行为变更。

接下来,我们就以上面划分好的优先级标准,来开始对Android 12的适配工作。

影响所有App的行为变更

P0:功能异常

应用启动画面

造成影响

简单讲,就是从Android 12开始,所有的App在每次启动时(特指冷启动与温启动),系统都会为我们加上一个默认的启动画面,如下所示:

应用启动画面.gif

该启动画面主要由以下4个元素组成,分别为:

启动画面构成元素.png

(1) 应用图标:可以是静态或动画形式。默认情况下,使用Launcher图标。

(2) 图标背景:可选,在图标与窗口背景之间需要更高的对比度时很有用。

(3) 前景遮罩:可选,前景的 ⅓ 将被遮盖。

(4) 窗口背景:不透明的单色,默认是所设置主题的windowBackground。

虽然这个启动画面允许我们一定程度的自定义,但总体都无法跳脱出以上4个元素,且无法去除。如果不做任何处理,加上我们原有的闪屏页和广告页,视觉上会有多个启动画面

适配方案

方案1(懒人专用):设置除窗口背景之外的元素都为透明

处理后的效果就是,在启动时会先显示由所设置主题的windowBackground指定的纯色背景,即与大多数开发者之前为了解决启动黑屏/白屏问题所采用的方法一致。

应用启动画面-纯色背景.gif

方案2(常规做法):改用SplashScreen API定制系统启动画面

缺点就是可定制程度低,可能无法满足产品的需求;

如果总体的效果可以接受,那么接下来要处理的就是对原有闪屏页的取舍,以及与原有广告页的画面衔接了。

但如开头所言,我们的目标是将改动最小化,那么,原有闪屏页该干嘛还是让它干嘛,初始化也好,路由也罢,逻辑不变,要求只是不再显示而已。

具体做法如下:

  1. 添加 SplashScreen compat 库

添加SplashScreen库.png

  1. 在闪屏页调用 SplashScreen#setKeepOnScreenCondition{ true } 使得默认的启动画面持续覆盖原有的闪屏页,直到广告页开始显现时,才调用SplashScreen#setKeepOnScreenCondition{ false } 让页面重新显示,以此实现平稳过渡

SplashScreen#setKeepOnScreenCondition.png

应用启动画面-持续覆盖原有的闪屏页.gif

麦克风和摄像头切换开关

造成影响

简单讲,就是从Android 12开始,用户可以通过状态栏下拉菜单中两个新增的切换开关选项,一键启用/停用摄像头和麦克风使用权限。

麦克风和摄像头切换开关.png

请注意,这里的「使用权限」针对的是设备上的所有App,是全局的,不要和Android 6.0的「运行时权限」混淆。

而两者在具体表现上也有所不同,在实际操作中:

  • 当关闭摄像头使用权限后,画面录制将继续进行,但只会收到空白画面

  • 当关闭麦克风使用权限后,声音录制将继续进行,但只会收到无声视频

适配方案

尽管官网上提供了检查设备是否支持麦克风和摄像头切换开关的API,也就是检查状态栏下拉菜单是否有这两个开关选项,然而这对于我们实际的适配工作几乎没有什么卵用:

检查设备是否支持麦克风和摄像头切换开关的API.png

SensorPrivacyManager类倒是有提供检查指定切换开关是否开启的API,但由于是系统权限,因此即使是通过反射形式也无法调用:

检查指定切换开关是否开启的API.png

所幸的是,如果用户主动关闭了摄像头或麦克风的使用权限,那么当下次App再需要启动摄像头或麦克风时,系统就会提醒用户,相关硬件的使用权限已关闭,并申请重新开启:

麦克风切换开关-重新开启.gif

因此,对于此行为变更的适配,我们要做的,就是验证在用户主动关闭了摄像头或麦克风使用权限后,App的相关功能是否受影响,至于监听/提示/重新开启的工作则交给系统帮我们完成即可。

影响目标API级别为Android 12的App的行为变更

P0:功能异常

更安全的组件导出

造成影响

简单讲,就是以Android 12为目标平台的App,如果其包含的四大组件中使用到了Intent过滤器(intent-filter),则必须显式声明 android:exported 属性,否则App将无法在Android 12及更高系统版本的设备上安装

无法在Android 12及更高系统版本的设备上安装.png

适配方案

这里要区分两种情况:

  • 如果是自身项目使用到了,则按要求显式声明即可;

  • 如果是依赖的第三方库使用到了,那就比较麻烦了。且不说等待第三方库更新的过程很被动,如果该库还已停止维护了,那就芭比Q了。

但众所周知,Android Studio Project在打包时是会合并多个Module的AndroidManifest.xml文件的,基于这种情况,我们就可以通过编写Gradle脚本,在打包过程中检索合并后的AndroidManifest.xml文件中,所有使用到了Intent过滤器但没有声明exported属性的组件,动态地为其加上exported属性。

具体的Gradle脚本已经有人写过了,这里就不再贴出了:

events.jianshu.io/p/1913b48f2…

待处理 intent 可变

造成影响

简单讲,就是以Android 12为目标平台的App,在构建PendingIntent时,需要指定Flag为FLAG_IMMUTABLE(建议)或FLAG_MUTABLE二者之一,否则App将崩溃并出现以下警告。

待处理 intent 可变性崩溃警告.png

适配方案

指定Flag为FLAG_IMMUTABLE(建议)或FLAG_MUTABLE二者之一.png

但同样可能出现第三方库的代码未正确指定Flag的问题,目前除了等待第三方库更新之外似乎也没有更好的措施。

前台服务启动限制

造成影响

简单讲,就是以Android 12为目标平台的App,如果尝试在后台运行时启动前台服务(startForegroundService),则会引发ForegroundServiceStartNotAllowedException异常(某些场景除外):

ForegroundServiceStartNotAllowedException异常.png

适配方案

分两步走:

  • 检查App是否有在后台启动前台服务的行为

    可在Terminal终端执行以下adb命令,该命令会监控你的App是否有在后台启动前台服务的行为,一旦有此行为,就会在通知栏推送一条提醒,定位到触发此行为的代码处:

    adb shell device_config put activity_manager \ default_fgs_starts_restriction_notification_enabled true

检查您的应用程序是否执行后台启动.gif

  • 考虑改用WorkManager的加急工作来执行后台任务

精确的闹钟权限

造成影响

简单讲,就是以Android 12为目标平台的App,如果使用到了AlarmManager来设置定时任务,并且设置的是精准的闹钟(使用了setAlarmClock()、setExact()、setExactAndAllowWhileIdle()这几种方法),则需要确保SCHEDULE_EXACT_ALARM权限声明且打开,否则App将崩溃并出现以下警告:

SCHEDULE_EXACT_ALARM权限声明未打开.png

适配方案

分三步走:

  • 在AndroidManifest.xml清单文件中声明 SCHEDULE_EXACT_ALARM 权限
  • 判断是否具有设置精确闹钟的权限

判断是否具有设置精确闹钟的权限.png

  • 打开闹钟和提醒权限授权页面,进行授权

打开闹钟和提醒权限授权页面.png

进行授权.png

通知 trampoline 限制

造成影响

简单讲,就是我们之前在配置通知(Notification)的点按行为时,可能会通过PendingIntent来启动一个Service或BrocastReceiver。而以Android 12为目标平台的App,如果尝试在Service或BrocastReceiver中内调用 startActivity(),系统会阻止该Activity启动,并在 Logcat 中显示以下消息:

尝试在Service或BrocastReceiver中内调用 startActivity().png

适配方案

分两步走:

  • 排查哪个Service或BrocastReceiver有此行为

    可在Terminal终端执行以下adb命令,该命令会在你点按通知后,识别哪个Service或BrocastReceiver调用了startActivity(),并输出相关信息到Logcat,可以通过关键字“NotifInteractionLog”进行过滤:

    adb shell dumpsys activity service \ com.android.systemui/.dump.SystemUIAuxiliaryDumpService

通过关键字“NotifInteractionLog”进行过滤.png

  • 考虑在配置通知(Notification)的点按行为时选择直接启动Activity

P1:体验下降

大致位置

造成影响

做过定位功能的Android开发者都知道,Android提供了两种不同精确度的位置权限,分别是:

  • ACCESS_COARSE_LOCATION(大致位置)

    提供设备位置的估算值,将范围限定在大约 1.6 公里(1 英里)内

  • ACCESS_FINE_LOCATION(确切位置)

    通常将范围限定在大约 50 米(160 英尺)内,有时精确到几米(10 英尺)范围以内

而在以Android 12为目标平台的App上,当App尝试请求ACCESS_FINE_LOCATION权限时,系统权限对话框会提供两个选项,即允许App获取确切位置,还是仅允许获取大致位置。

允许App获取确切位置,还是仅允许获取大致位置.png

也即是说,给了用户拒绝提供确切位置的权力,一旦用户拒绝,这种情况下App就只能获取到大致位置了。

适配方案

虽然用户可能拒绝提供确切位置,但我们依旧可以再次请求升级到确切位置:

再次请求升级到确切位置.png

当然,在再次请求前提供一个适当的解释说明是一个比较好的做法,App本身也要做好只能获取到大致位置时的业务降级处理。

应用休眠

造成影响

简单讲,就是以Android 12为目标平台的App,如果用户有长达几个月的时间没有打开过你的App,那么你之前申请的所有运行时权限都会被重置为未授权状态,即使再次打开也无法恢复,需要重新申请。

适配方案

基本上,只要你的App之前已经做好运行时权限的的判断和申请,那对你的App就几乎没什么影响。如果还是想稳妥的测试一下,可以用Terminal终端执行adb命令,手动触发应用休眠:

developer.android.com/topic/perfo…

应用休眠运行时权限重置.gif

自定义通知

造成影响

简单讲,就是如果之前App中的通知(Notification)中使用到了自定义内容视图,并且该视图是填满整个通知区域的。那么当App以Android 12为目标平台后,视图将不再能填充整个区域,而是会被缩小到某个固定范围:

缩小到某个固定范围.png

另外,所有通知现在都变成了可展开的,如果你之前设置自定义内容视图时使用的是 setCustomContentView方法,那你现在则还需要另外再使用setBigCustomContentView方法来设置展开状态的样式,以确保通知在收起状态和展开状态的样式能统一。

适配方案

确认被缩减显示范围后的自定义内容视图样式是否能接受,若不能接受,则根据实际需要调整即可。

演示Demo

这边提供了一个Demo,可以帮助我们通过实际操作,快速理解以上行为变更的具体表现,并且由于是轻量级的Demo,所以也方便我们进行改动,快速验证适配方案的效果:

github.com/madchan/Sup…

Demo.png

「椎锋陷陈」微信技术号现已开通,为了获得第一手的技术文章推送,欢迎搜索关注!

扫码_搜索联合传播样式-白色版.png

分类:
Android
标签:
分类:
Android
标签:
收藏成功!
已添加到「」, 点击更改