背景
近期，Google Play向所有的应用开发者发送了一封邮件，邮件中明确了应用将目标API级别更新为Android 12的最后期限。
这表示，Android 12的适配工作不得不提上日程了。
本着将改动最小化的原则，建议在开始适配之前，可以将此次需要适配的一系列行为变更，按照对自身项目的影响程度，先进行优先级划分，并依据此优先级去分批、逐步完成适配工作。
该如何进行划分呢？可能具体到每个人的项目情况都有所不同，这里提供一下笔者项目的适配任务优先级划分标准，供其他开发者参考：
P0：功能异常
指明确影响到了App功能的正常使用，甚至导致App无法正常启动或者崩溃率直线上升的行为变更。
P1：体验下降
指虽不影响功能正常使用，但可能导致获取数据的准确度下降，或者需要增加操作步骤进而影响用户体验的行为变更。
P2：可选优化
指对App本身没有什么实质影响，但做好适配后可以增强App健壮性或用户体验的行为变更。
接下来，我们就以上面划分好的优先级标准，来开始对Android 12的适配工作。
影响所有App的行为变更
P0：功能异常
应用启动画面
造成影响
简单讲，就是从Android 12开始，所有的App在每次启动时（特指冷启动与温启动），系统都会为我们加上一个默认的启动画面，如下所示：
该启动画面主要由以下4个元素组成，分别为：
(1) 应用图标：可以是静态或动画形式。默认情况下，使用Launcher图标。
(2) 图标背景：可选，在图标与窗口背景之间需要更高的对比度时很有用。
(3) 前景遮罩：可选，前景的 ⅓ 将被遮盖。
(4) 窗口背景：不透明的单色，默认是所设置主题的windowBackground。
虽然这个启动画面允许我们一定程度的自定义，但总体都无法跳脱出以上4个元素，且无法去除。如果不做任何处理，加上我们原有的闪屏页和广告页，视觉上会有多个启动画面。
适配方案
方案1(懒人专用)：设置除窗口背景之外的元素都为透明
处理后的效果就是，在启动时会先显示由所设置主题的windowBackground指定的纯色背景，即与大多数开发者之前为了解决启动黑屏/白屏问题所采用的方法一致。
方案2(常规做法)：改用SplashScreen API定制系统启动画面
缺点就是可定制程度低，可能无法满足产品的需求；
如果总体的效果可以接受，那么接下来要处理的就是对原有闪屏页的取舍，以及与原有广告页的画面衔接了。
但如开头所言，我们的目标是将改动最小化，那么，原有闪屏页该干嘛还是让它干嘛，初始化也好，路由也罢，逻辑不变，要求只是不再显示而已。
具体做法如下：
- 添加 SplashScreen compat 库
- 在闪屏页调用 SplashScreen#setKeepOnScreenCondition{ true } 使得默认的启动画面持续覆盖原有的闪屏页，直到广告页开始显现时，才调用SplashScreen#setKeepOnScreenCondition{ false } 让页面重新显示，以此实现平稳过渡
麦克风和摄像头切换开关
造成影响
简单讲，就是从Android 12开始，用户可以通过状态栏下拉菜单中两个新增的切换开关选项，一键启用/停用摄像头和麦克风使用权限。
请注意，这里的「使用权限」针对的是设备上的所有App，是全局的，不要和Android 6.0的「运行时权限」混淆。
而两者在具体表现上也有所不同，在实际操作中：
-
当关闭摄像头使用权限后，画面录制将继续进行，但只会收到空白画面；
-
当关闭麦克风使用权限后，声音录制将继续进行，但只会收到无声视频。
适配方案
尽管官网上提供了检查设备是否支持麦克风和摄像头切换开关的API，也就是检查状态栏下拉菜单是否有这两个开关选项，然而这对于我们实际的适配工作几乎没有什么卵用：
SensorPrivacyManager类倒是有提供检查指定切换开关是否开启的API，但由于是系统权限，因此即使是通过反射形式也无法调用：
所幸的是，如果用户主动关闭了摄像头或麦克风的使用权限，那么当下次App再需要启动摄像头或麦克风时，系统就会提醒用户，相关硬件的使用权限已关闭，并申请重新开启：
因此，对于此行为变更的适配，我们要做的，就是验证在用户主动关闭了摄像头或麦克风使用权限后，App的相关功能是否受影响，至于监听/提示/重新开启的工作则交给系统帮我们完成即可。
影响目标API级别为Android 12的App的行为变更
P0：功能异常
更安全的组件导出
造成影响
简单讲，就是以Android 12为目标平台的App，如果其包含的四大组件中使用到了Intent过滤器（intent-filter），则必须显式声明 android:exported 属性，否则App将无法在Android 12及更高系统版本的设备上安装：
适配方案
这里要区分两种情况：
-
如果是自身项目使用到了，则按要求显式声明即可；
-
如果是依赖的第三方库使用到了，那就比较麻烦了。且不说等待第三方库更新的过程很被动，如果该库还已停止维护了，那就芭比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将崩溃并出现以下警告。
适配方案
但同样可能出现第三方库的代码未正确指定Flag的问题，目前除了等待第三方库更新之外似乎也没有更好的措施。
前台服务启动限制
造成影响
简单讲，就是以Android 12为目标平台的App，如果尝试在后台运行时启动前台服务(startForegroundService)，则会引发ForegroundServiceStartNotAllowedException异常（某些场景除外）：
适配方案
分两步走：
-
检查App是否有在后台启动前台服务的行为
可在Terminal终端执行以下adb命令，该命令会监控你的App是否有在后台启动前台服务的行为，一旦有此行为，就会在通知栏推送一条提醒，定位到触发此行为的代码处：
adb shell device_config put activity_manager \ default_fgs_starts_restriction_notification_enabled true
- 考虑改用WorkManager的加急工作来执行后台任务
精确的闹钟权限
造成影响
简单讲，就是以Android 12为目标平台的App，如果使用到了AlarmManager来设置定时任务，并且设置的是精准的闹钟(使用了setAlarmClock()、setExact()、setExactAndAllowWhileIdle()这几种方法)，则需要确保SCHEDULE_EXACT_ALARM权限声明且打开，否则App将崩溃并出现以下警告：
适配方案
分三步走：
- 在AndroidManifest.xml清单文件中声明 SCHEDULE_EXACT_ALARM 权限
- 判断是否具有设置精确闹钟的权限
- 打开闹钟和提醒权限授权页面，进行授权
通知 trampoline 限制
造成影响
简单讲，就是我们之前在配置通知(Notification)的点按行为时，可能会通过PendingIntent来启动一个Service或BrocastReceiver。而以Android 12为目标平台的App，如果尝试在Service或BrocastReceiver中内调用 startActivity()，系统会阻止该Activity启动，并在 Logcat 中显示以下消息：
适配方案
分两步走：
-
排查哪个Service或BrocastReceiver有此行为
可在Terminal终端执行以下adb命令，该命令会在你点按通知后，识别哪个Service或BrocastReceiver调用了startActivity()，并输出相关信息到Logcat，可以通过关键字“NotifInteractionLog”进行过滤：
adb shell dumpsys activity service \ com.android.systemui/.dump.SystemUIAuxiliaryDumpService
- 考虑在配置通知(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就只能获取到大致位置了。
适配方案
虽然用户可能拒绝提供确切位置，但我们依旧可以再次请求升级到确切位置：
当然，在再次请求前提供一个适当的解释说明是一个比较好的做法，App本身也要做好只能获取到大致位置时的业务降级处理。
应用休眠
造成影响
简单讲，就是以Android 12为目标平台的App，如果用户有长达几个月的时间没有打开过你的App，那么你之前申请的所有运行时权限都会被重置为未授权状态，即使再次打开也无法恢复，需要重新申请。
适配方案
基本上，只要你的App之前已经做好运行时权限的的判断和申请，那对你的App就几乎没什么影响。如果还是想稳妥的测试一下，可以用Terminal终端执行adb命令，手动触发应用休眠：
developer.android.com/topic/perfo…
自定义通知
造成影响
简单讲，就是如果之前App中的通知(Notification)中使用到了自定义内容视图，并且该视图是填满整个通知区域的。那么当App以Android 12为目标平台后，视图将不再能填充整个区域，而是会被缩小到某个固定范围：
另外，所有通知现在都变成了可展开的，如果你之前设置自定义内容视图时使用的是 setCustomContentView方法，那你现在则还需要另外再使用setBigCustomContentView方法来设置展开状态的样式，以确保通知在收起状态和展开状态的样式能统一。
适配方案
确认被缩减显示范围后的自定义内容视图样式是否能接受，若不能接受，则根据实际需要调整即可。
演示Demo
这边提供了一个Demo，可以帮助我们通过实际操作，快速理解以上行为变更的具体表现，并且由于是轻量级的Demo，所以也方便我们进行改动，快速验证适配方案的效果：
「椎锋陷陈」微信技术号现已开通，为了获得第一手的技术文章推送，欢迎搜索关注！