Android Target 31 升级全攻略 —— 记首个超级 App 的坎坷升级之路

6773次阅读  |  发布于2年以前

简述

Android Target 版本作为应用和系统版本间的“协议”与“桥梁”，在厂商预装合作、应用商店曝光、开放能力方面都是一个重要衡量标准，近年来谷歌和手机厂商对于 Target 升级的推动速度和力度明显加大。Target 版本越高，对系统和用户的安全性相应越好，但其对应用的改动、约束和不明确的坑也随之增多，尤其是对使用系统API范围广、业务复杂、稳定性要求高的超级应用挑战很大。

高德地图此次一鼓作气从 Target 28 升级到 最新的 Target31，成为业界首个升级到最新版本的头部应用，满足了应用市场、厂商预装合规的要求，为后续市场先发、预装合作等赢得了时间窗口。第一个“吃螃蟹”，踩了不少坑，因此我们总结了升级过程中遇到的问题、原理、解决方案及操作方式，希望能帮大家在升级 Target 中事半功倍。

1.1 释义：何为 Target 版本

Target 版本，用白话意思是「告知系统我已满足指定系统版本的合规要求，并愿意受约束」。具体指:

1.2 挑战：变化快、成本高的原因

为什么近期 Target 升级推动快、成本高呢？从行业发展和技术的角度来看：

从行业发展看趋势：

从技术看问题：

作为高速发展的超级 App，高德需要做到既保持内部“持续的业务增长”，又能消化外部“要求高、变化快、难度大”。经过大家的不懈努力，最终圆满完成了 Target 28 → 31 的升级。

1.3 收益

  1. 为满足应用市场、厂商预装合规要求，政府、厂商、电信终端产业协会公约 打好提前量，为后续市场先发、预装合作赢得的时间窗口，避免卡脖子；
  2. 在专项过程中沉淀了升级、合规相关经验，设计并落地系统隔离层，降低后续改动对业务的影响，提升后续对新系统、华米 OV ROM、鸿蒙等的应对效率；
  3. 通过源码分析+自研脚本，成功识别 13 个谷歌未提及的改动，减少了 119 个潜在崩溃、不可用风险。

隐私权限

2.1 外置存储、分区存储与限制【29,30】

1 背景

为了更好保护用户数据并限制设备冗余文件增加，若应用升级到 Target 29，在默认情况下被赋予了对外部存储设备的分区访问权限（即分区存储），应用只能看到本应用专有的沙箱目录以及特定类型的媒体（通过MediaStore）。

2 现状（SDK=28为目标平台的应用）

当用户授予“存储”权限，允许读写外置非沙盒目录的内容，并在卸载重装后不会被清除；此外，一些用户相册、敏感信息，在授予权限后也可以读取到。

3 Target 升级后不同访问方式表现

前提：

目录：

坑点&避坑建议（已在小米、ov等主流机型验证）：

4 总结&适配建议

2.2 蓝牙权限及不同策略【29,30,31】

1 涉及权限的蓝牙API

大致可以分为下面三类：

2 蓝牙权限在不同版本的要求

对于新增的这三个权限的弹窗表现，我们也实际测试了一下，现象如下：

不同版本中蓝牙API与权限的对应关系，最终总结起来如下：

3 适配方案

以下是Target SDK从28升级到31需要做的适配：

  1. 为不同Android版本申明不同的权限
 <!-- Request legacy Bluetooth permissions on older devices. -->
    <uses-permission android:name="android.permission.BLUETOOTH"
                     android:maxSdkVersion="30" />
    <uses-permission android:name="android.permission.BLUETOOTH_ADMIN"
                     android:maxSdkVersion="30" />
    <uses-permission android:name="android.permission.ACCESS_COARSE_LOCATION" />
    <uses-permission android:name="android.permission.BLUETOOTH_SCAN" />
    <uses-permission android:name="android.permission.BLUETOOTH_ADVERTISE" />
    <uses-permission android:name="android.permission.BLUETOOTH_CONNECT" />

2 . 动态申请运行时权限

3 . 使用API前做权限校验

使用涉及权限的蓝牙API前，需做权限校验。确定已具备相应权限，再继续调用；否则应停止调用，否则可能导致应用直接崩溃。

2.3 大致位置【31】

（厂商称“模糊定位”，以下做统一）

1 背景

升级到Target 31后，在Android 12系统的定位权限设置页和授权弹窗中，明确区分了精确定位和模糊定位，并允许用户选择仅使用模糊定位，即当开启“模糊定位”时，其“精准定位”权限被关闭。此前，小米/Vivo的部分Android 11机型已经采用了这种方式为用户提供更灵活的定位选择，Android target 31升级算是借鉴了相同的思路。可以理解为，在原先仅小米/Vivo 支持“模糊定位”（关闭精确定位）的基础上，Target 升级后，将其扩展到了 Oppo/华为/三星等其他厂商的所有 Android 12 系统。

2 不同厂商/版本策略

图 定位权限设置页 & 定位授权弹窗

以下是Target 31升级前后关于模糊定位的对比情况：

可以看到，如果应用仅使用模糊定位，那么不会受到任何影响。但对于高度依赖精确定位的应用，则需要进行相应的适配，确保获得精确定位权限。

3 适配方案

  1. 判断应用是否具备精确定位权限

2 . 引导用户开启精确定位 ：可以在弹出授权弹窗前，或者去到应用权限设置页面前，向用户展示引导性的弹窗或文案，提示其开启精确定位。

2.4 在后台访问位置信息的权限【29,30】

1 背景

为了让用户更好地控制应用对位置信息的访问权限，从Android10开始加强了后台定位权限申请的管控。在介绍变更之前需先了解后台定位的场景，除非符合以下条件之一，否则应用将被视为在后台访问位置信息：

2 升级后的变化

注意：通过requestPermission去动态申请ACCESS_BACKGROUND_LOCATION 权限，系统将忽略该请求不会弹窗。如果您同时请求在前台访问位置信息的权限和在后台访问位置信息的权限， 系统会忽略该请求，且不会向您的应用授予其中的任一权限。

3 适配建议

2.5 精准的闹钟权限【31】

1 背景

为了鼓励应用节省系统资源，Android 12 要求为以 Android 12 为目标平台且设置精确的闹钟的应用配置“闹钟和提醒”特殊应用访问权限。如需获取这种特殊应用访问权限，请在清单中请求 SCHEDULE_EXACT_ALARM 权限。精确的闹钟只能用于面向用户的功能，且用户和系统均可撤消“闹钟和提醒”特殊应用访问权限，因此需要时加权限判断，否则会抛出Exception。

2 适配建议

需要精确的闹钟的得申请SCHEDULE_EXACT_ALARM权限，且使用时做权限判断。

2.6 一些电话 API、蓝牙 API 和 WLAN API 需要精确位置权限【29】

1 背景

如果应用以 Android 10 或更高版本为目标平台， 则它必须具有 ACCESS_FINE_LOCATION 权限才能使用 Telephony、WLAN、WLAN 感知和蓝牙（蓝牙上面章节已介绍）API中的一些方法。涉及影响的类主要有：

1）电话：TelephonyManager、TelephonyScanManager、TelephonyScanManager.NetworkScanCallback、PhoneStateListener

2）WLAN：WifiManager、WifiAwareManager、WifiP2pManager、WifiRttManager

2 适配建议

涉及通过无线进行“定位”的API需授予ACCESS_FINE_LOCATION权限后方可调用。

安全合规

3.1 软件包可见性【30】

1 背景

Android 11 更改了应用查询用户已在设备上安装的其他应用以及与之交互的方式。使用 元素，应用可以定义一组自身可访问的其他软件包。通过告知系统应向您的应用显示哪些其他软件包，此元素有助于鼓励最小权限原则。此外，此元素还可帮助 Google Play 等应用商店评估应用为用户提供的隐私权和安全性。

2 现状&影响

通过识别发现主要受影响的系统API包括但不限于：queryIntentActivities、getPackageInfo、getInstalledApplications、getInstalledPackages 等。我们以 getInstalledPackages 和 getInstalledApplications 的API为例：

  1. 您自己的应用，即自身应用
  2. 实现 Android 核心功能的某些系统软件包，如媒体提供程序。
  3. 通过 startActivityForResult（注意 startActivity 无效）打开自身应用时的应用（仅当次有效）
  4. 安装了您应用的应用（如当时安装自身应用时的应用市场）
  5. 通过 bindService/startService/Provider 打开自身应用时的应用（仅当次有效）
  6. 自己在 Manifest 中声明的包名/签名/IntentFilter/ProviderAuthorities 清单（见“建议”）

3 建议

  1. 如果有需要查询或者交互的非当前App应用组件，需要在 AndroidManifest 中添加 queries 元素。以下有几种建议，大家可根据自己的实际使用场景来选择，最好遵守最小使用原则。可考虑添加包名、Provider 声明的 android:authorities、通用的 Intent-Filter 等来实现；
  2. 【不建议】在 Manifest 中添加 QUERY_ALL_PACKAGES 做兜底，避免崩溃，但应考虑 Google Play 及海外市场的限制。

4 补充

关于软件包可见性，除了Google的要求外，国内各大厂商正在要求App添加厂商自定义权限：com.android.permission.GET_INSTALLED_APPS，该权限需要用户授权，也就是说未来某App想要获取应用软件列表信息是需要用户授权通过才可以正常获取。

3.2 对已配置的 WLAN 网络限制【29】

1 背景

为了保护用户隐私，只有系统应用和设备政策控制器 (DPC) 支持手动配置 WiFi 网络列表（包括增删改/连接 WiFi 等）。如果应用升级 Target 到 29 且应用不是系统应用或 DPC，则有些方法不会返回有用数据，具体表现见下节。

2 升级后的变化

Target升级到29+后获取/操作WIFI列表的行为如下：

需更换新 API（addNetworkSuggestions），当添加新 WiFi 时系统会弹窗等待用户确认（如下图），用户可拒绝添加；其它行为和升级前一致。

3 适配建议

3.3 更安全的组件导出【31】

1 背景

如果您的应用以 Android 12 或更高版本为目标平台，且包含使用 intent 过滤器的 activity、服务或广播接收器，您必须为这些应用组件显式声明 android:exported 属性。

警告：如果 activity、服务或广播接收器使用 intent 过滤器，并且未显式声明 android:exported 的值，您的应用将无法在搭载 Android 12 或更高版本的设备上进行安装。

2 影响

需要check一下activity、服务或广播中包含intent过滤器的场景。

3 思考&建议

官方考虑对于强制声明android:exported 属性，主要是考虑到安全性，自然也建议我们将exported 属性非必需true的都改成false，理想的角度，推荐大家逐一check一下所有的场景。

当然如果大家想更快捷的去解决，推荐在编译期间，解析AndroidManifest，对于没有主动设置exported属性的统一设置，这样也可以一并解决 SDK 相关问题。

这里有个细节需要注意一下，当Activity包含intent 过滤器时，如果没有设置exported属性，系统在运行的时候会将exported解析成true使用，这在系统的源码中也是有体现的；这样我们就需要考虑历史业务场景中：可能会存在没有给exported设置属性，却将exported设为true来使用。

3.4 前台服务启动限制【31】

1 背景

以 Android 12 或更高版本为目标平台的应用无法在后台运行时启动前台服务，少数特殊情况（https://developer.android.com/guide/components/foreground-services#background-start-restriction-exemptions）除外。如果应用尝试在后台运行时启动前台服务，则会引发异常。

2 影响

使用到启动前台服务（API如下）的业务场景，需要check是否有从后台启动的情况，如果有看是否满足特殊情况。主要涉及：startForegroundService 和 startForeground 方法。

3 建议：

尽量避免，甚至杜绝（随着系统不断升级，对于从后台启动前台服务越来越严）从后台启动前台服务。建议从静态分析角度查找所有涉及前台调用的 API，梳理和 Check。

3.5 前台服务访问摄像头、麦克风需声明【30】

1 背景：

  1. 在前台服务中访问摄像头或麦克风，则必须添加前台服务类型 camera 和 microphone；
  2. 如果应用在后台运行时启动了某项前台服务， 则该前台服务无法访问麦克风或摄像头，如果想访问位置，需要有后台访问位置信息的权限。

2 影响

前台服务中使用摄像头、麦克风或位置。

3 建议

  1. 如果在前台服务中需要使用camera和microphone，需要在AndroidManifest.xml声明对应类型。如下：<service ... android:foregroundServiceType="camera|microphone" />
  2. 不建议应用在后台时启动前台服务，因为如果Target升级到31的时候，除非特殊情况，否则无法从后台启动前台服务。

3.6 待处理 intent 可变性【31】

1 背景

如果您的应用以 Android 12 为目标平台，则需对 Pending Intent 强制设置“可变性”（即 FLAG_IMMUTABLE/FLAG_MUTABLE），这项额外的要求可提高应用的安全性。

2 影响

使用到PendingIntent的业务场景。

3 建议

根据需要为PendingIntent填写 PendingIntent.FLAG_MUTABLE 或 PendingIntent.FLAG_IMMUTABLE 标志；此外，最好提供一个适配的聚合类，其他类都直接调用适配类的方法，这样可以减少适配成本。

3.7 更新后的非 SDK 限制【29,30,31】

1 背景

从 Android 9（API 级别 28）开始，Android 平台对应用能使用的非 SDK 接口实施了限制。只要应用引用非 SDK 接口或尝试使用反射或 JNI 来获取其句柄，这些限制就适用。这些限制旨在帮助提升用户体验和开发者体验，为用户降低应用发生崩溃的风险，同时为开发者降低紧急发布的风险。

2 影响

使用google官方提供的工具（https://developer.android.com/guide/app-compatibility/restrictions-non-sdk-interfaces#list-names）和Android 12 非 SDK 接口及其对应的名单，就可以对需要的APP扫描出结果，根据结果可知道影响范围。

3 建议

理想情况下，我们应该只使用SDK(whitelist)；但是一些App为了获得一些能力，使用了非sdk接口。因此：

写在结束前

以上是我们在 Target 升级中的思考和解法，由于篇幅所限，上述仅介绍了一些隐私安全相关的“关键要点”，具体的技术实现细节，大家若有兴趣，欢迎随时在评论区留言讨论。

Target 升级的关键之处，除了外部（厂商、政府政策）的推动，公司内部对于拥抱隐私合规，对用户负责的积极态度外，还有多方团队的合作，自上而下的重视，以及自内而外的决心，三者缺一不可。Target 升级绝非“一锤子买卖”，它需要长期、持之以恒的耕耘，才能不断结出果实。希望我们的经历，能为大家带来启发，少走弯路，轻装上阵。

Copyright© 2013-2020

All Rights Reserved 京ICP备2023019179号-8