关于android:Android-Target-31-升级全攻略-记阿里首个超级-App-的坎坷升级之路

作者：杨夕凯、张炅轩

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

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

Target 版本，用文言意思是「告知零碎我已满足指定零碎版本的合规要求，并违心受约束」。具体指:

从束缚上，和个别的强制束缚（例如用户降级到 Android 12 就必须满足某个条件）不同，Target 版本为咱们提供了一种“柔和、缓冲适配”的路径，容许用户在降级 Android 12 时，先长期不受新零碎束缚（Target 为老版本），而是等本人“准备就绪后”在降级 Target 版本以满足束缚，更具灵活性；
从强度上，Target 版本越高，受到的束缚越多，且约束力越强，这里的版本为“零碎 API 版本号”，和 Android 版本一一对应，如 28 对应的是 Android 9，29 为 Android 10，以此类推。

为什么近期 Target 降级推动快、老本高呢？从行业倒退和技术的角度来看：

从 行业倒退 看趋势：

厂商跟进快： 近年来对于 Target 降级的要求体现了“趋紧”和“趋严”，通过此伎俩，可从零碎层面束缚各 App 满足隐衷合规、对立用户体验等要求；其中：

a、针对预装利用，作为 CTS（Compatibility Test Suite，谷歌的兼容性测试套件）集成的必要一环，若不能及时响应 Target 降级诉求，则很有可能导致预装下架，进而对厂商单干、利用带量等造成重大影响；

b、针对市场利用，通过 TAF《挪动应用软件高 API 等级预置与散发自律公约》等公约，从教训看会在 1- 2 年内将条件扩大到利用商店，即使不波及预装利用，则仍要防患未然

隐衷力度强：无论政府监管部门，还是厂商、Google，其满足“隐衷合规”的要求越加频繁，已经“粗放”的 App 权限已成过来，从长远看，此种限度对用户是有显著收益的，但对于利用开发者而言，须要及时响应、明确趋势，充沛了解和执行；
碎片设施多：谷歌和各厂商 /ROM 对于隐衷、API 调整等的了解不同，其不同版本、不同设施的施行成果有较大差别，且“碎片化”愈演愈烈。如“大抵地位”、“启动图”等，各厂商会依据本人的需要来做二次开发，导致在谷歌原生的适配办法，到其它 ROM 中则存在问题

从技术看问题：

变动频繁：以 Android 12 为例，Release 公布后至多有 5 次文档变动（包含启动图、含糊定位、文件存储等），并下发过 Release Patch 至厂商，厂商再依据本人的需要、节奏来看是否“施行”Patch，导致适配老本成倍增加；加之各 ROM 的碎片化，过程中须要继续调整对焦
资料不全：过后业内无较好的剖析文档，支流 App 也未适配到 31，很多须要本人摸索，如新增权限判断、外置存储应用、启动图等，官网要么未提及，要么只说大略，须要本人剖析源码 + 一直的实际能力明确。
适配艰难：每一个权限调整，其波及 API 泛滥、用户影响高，且适配量很大，以咱们为例，相比过来 Target 21 → 26 的 20+ 零碎 API，本次波及 300+ 零碎 API，上千处调用，涵盖多个技术栈，革新老本高、影响范围广，为咱们的适配带来了不小挑战

作为高速倒退的超级 App，高德须要做到既放弃外部“继续的业务增长”，又能消化内部“要求高、变动快、难度大”。通过大家的不懈努力，最终圆满完成了 Target 28 → 31 的降级。

为满足利用市场、厂商预装合规要求，政府、厂商、电信终端产业协会公约打好提前量，为后续市场先发、预装单干博得的工夫窗口，防止卡脖子；
在专项过程中积淀了降级、合规相干教训，设计并落地零碎隔离层，升高后续改变对业务的影响，晋升后续对新零碎、华米 OV ROM、鸿蒙等的应答效率；
通过源码剖析 + 自研脚本，胜利辨认 13 个谷歌未提及的改变，缩小了 119 个潜在解体、不可用危险。

为了更好爱护用户数据并限度设施冗余文件减少，若利用降级到 Target 29，在默认状况下被赋予了对外部存储设备的分区拜访权限（即分区存储），利用只能看到本利用专有的沙箱目录以及特定类型的媒体（通过 MediaStore）。

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

前提：

设置 requestLegacyExternalStorage=true 和 PreserveLegacyExternalStorage=true
APK targetSDK 降级到 31
新装 / 卸载后重装 APK

共享目录：存储其余利用可拜访文件，蕴含媒体文件、文档文件以及其余文件，对应设施 DCIM、Pictures、Alarms, Music, Notifications,Podcasts, Ringtones、Movies、Download 等目录;
沙箱内目录：
- /sdcard/Android/data/{packagename}
- /data/data/{packagename}
- /sdcard/Android/media/{packagename}
其余目录：零碎或其余利用在外置 SD 卡创立的目录；

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

坑点：在 Android 11+、Target 为 30+ 且用户新装 / 卸载重装时，即使没有存储权限，写入超过 sdcard 两级子目录（比方：/sdcard/xxx/yyy）零碎返回“可读写”仍为 true，不合乎预期；直到对文件内容做读写时，零碎才抛出写入异样，导致失败。
避坑倡议：因为繁多依附零碎返回后果已不可信，因而对系统返回后果做双重校验。如：Android 11 及以上且“可读写”返回 true 后，写入临时文件，若写入失败则仍放入沙箱。

笼罩装置不会主动开启分区存储，原有存储拜访权限不受影响；
利用可通过 requestLegacyExternalStorage 和 PreserveLegacyExternalStorage 两个属性禁掉分区存储机制来实现数据迁徙，但这两个属性只对降级无效，在 android 11 后的机器新装 / 重装会强制开启分区存储机制；
分区存储开启后无需申请存储权限即可失常拜访沙箱内目录；
分区存储开启后非沙箱内目录拜访会受限，具体表现见上表格；
分区存储开启后依然须要申请存储权限，否则访问共享目录会受限。

大抵能够分为上面三类：

Target ≤ 28 时： 具备 BLUETOOTH 和 BLUETOOT_ADMIN 权限就能应用连贯类 API 和播送类 API，扫描类 API 须要具备大抵定位权限（ACCESS_COARSE_LOCATION）
Target 为 29 和 30 时：连贯类 API 和播送类 API 权限无变动，扫描类 API 须要另外具备精确定位权限(ACCESS_FINE_LOCATION)。
Target ≥ 31 时： 新增了细分的蓝牙权限来代替 BLUETOOTH 和 BLUETOOTH_ADIMIN，为利用提供更灵便的权限申请形式。具体包含：
- BLUETOOTH_SCAN：容许扫描和发现设施，扫描类 API 须要同时具备该权限和精确定位权限(ACCESS_FINE_LOCATION)。
- BLUETOOTH_CONNECT：容许连贯和拜访已配对的设施，连贯类 API 须要具备该权限。
- BLUETOOTH_ADVERTISE：容许向左近的蓝牙设施进行播送，播送类 API 须要具备该权限。

对于新增的这三个权限的弹窗体现，咱们也理论测试了一下，景象如下：

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

在不同的 Android 版本中，蓝牙 API 的应用形式并未发生变化，所以只须要对权限进行相应的适配，防止因未受权而导致的解体即可；
如果同时应用了蓝牙的扫描、连贯和播送类 API，对应的权限都须要进行申请。思考到蓝牙的这三类操作往往是严密相连的，比方扫描发现后，就会进行连贯，如果一次性申请扫描、连贯和播送所需的所有蓝牙权限能更好的满足应用场景，同时也能防止反复弹出权限弹窗，使交互更加简洁。因而咱们最终采取了组合申请的形式；
组合申请蓝牙权限时，在 Vivo IQOO 5 上的零碎权限弹窗如图：

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

为不同 Android 版本申明不同的权限

为了持续兼容 SDK 29-30，须要保留在 Manifest 中申明的 BLUETOOTH 和 BLUETOOTH_ADMIN 权限，同时还应申明 maxSdkVersion 为 30，ACCESS_COARSE_LOCATION 也须要保留，如：

  <!-- 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" />

新增 BLUETOOTH_SCAN，BLUETOOTH_CONNECT 和 BLUETOOTH_ADVERTISE 权限的申明。如

    <uses-permission android:name="android.permission.BLUETOOTH_SCAN" />
    <uses-permission android:name="android.permission.BLUETOOTH_ADVERTISE" />
    <uses-permission android:name="android.permission.BLUETOOTH_CONNECT" />

新增 ACCESS_FINE_LOCATION 权限申明（如果确定利用不会推导用户地位，可跳过此申明和上面的动静申请。但需在 BLUETOOTH_SCAN 权限申明时，增加 android:usesPermissionFlags=”neverForLocation” 申明）

2、动静申请运行时权限

SDK 29-30，须要动静申请取得 ACCESS_FINE_LOCATION
SDK ≥ 31，先动静申请取得 ACCESS_COARSE_LOCATION+ACCESS_FINE_LOCATION（含糊定位引入的新要求，详见下文)，而后再组合 BLUETOOTH_SCAN、BLUETOOTH_CONNECT 和 BLUETOOTH_ADVERTISE 一起申请取得蓝牙权限。如果在未取得 ACCESS_FINE_LOCATION 的状况下，间接申请蓝牙权限，可能导致申请被疏忽的异样后果。

3、应用 API 前做权限校验

应用波及权限的蓝牙 API 前，需做权限校验。确定已具备相应权限，再持续调用；否则应进行调用，否则可能导致利用间接解体。

SDK 29-30，判断是否具备 ACCESS_FINE_LOCATION 权限即可
SDK ≥ 31，因为采纳了组合申请形式，咱们能够直接判断是否同时具备 ACCESS_FINE_LOCATION 和 BLUETOOTH_SCAN 即可

（厂商称“含糊定位”，以下做对立）

降级到 Target 31 后，在 Android 12 零碎的定位权限设置页和受权弹窗中，明确辨别了精确定位和含糊定位，并容许用户抉择仅应用含糊定位，即当开启“含糊定位”时，其“精准定位”权限被敞开。此前，小米 /Vivo 的局部 Android 11 机型曾经采纳了这种形式为用户提供更灵便的定位抉择，Android target 31 降级算是借鉴了雷同的思路。能够了解为，在原先仅小米 /Vivo 反对“含糊定位”（敞开精确定位）的根底上，Target 降级后，将其扩大到了 Oppo/ 华为 / 三星等其余厂商的所有 Android 12 零碎。

图定位权限设置页

图定位受权弹窗

以下是 Target 31 降级前后对于含糊定位的比照状况：

能够看到，如果利用仅应用含糊定位，那么不会受到任何影响。但对于高度依赖精确定位的利用，则须要进行相应的适配，确保取得精确定位权限。

判断利用是否具备精确定位权限

Target ≤ 30 且反对含糊定位的机型（小米 /Vivo），需应用厂商提供的 API 进行判断，具体可参见各厂商适配相干文档（官网或外部公布文档）
Target ≥ 31 的机型，可间接应用零碎 API，即 Context.checkSelfPermission()判断是否具备 ACCESS_FINE_LOCATION 即可。

2、疏导用户开启精确定位： 能够在弹出受权弹窗前，或者去到利用权限设置页背后，向用户展现引导性的弹窗或文案，提醒其开启精确定位。

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

属于该利用的 Activity 可见；
该利用运行的某个前台设施已申明前台服务类型为 location。

Target = 29 时： 开始引入了 ACCESS_BACKGROUND_LOCATION 权限，利用需在 AndroidManifest 申明 ACCESS_BACKGROUND_LOCATION 权限，而后动静申请该权限且用户抉择“始终容许”能力获取到后盾定位能力；

Target ≥ 30 时：利用需在 AndroidManifest 申明 ACCESS_BACKGROUND_LOCATION 权限，而后用户在零碎设置页面上抉择“始终容许”后能力获取到后盾定位能力。

留神：通过 requestPermission 去动静申请 ACCESS_BACKGROUND_LOCATION 权限，零碎将疏忽该申请不会弹窗。如果您同时申请在前台拜访地位信息的权限和在后盾拜访地位信息的权限，零碎会疏忽该申请，且不会向您的利用授予其中的任一权限。

因为不同 target 后盾定位权限获取形式不统一，如果须要后盾拜访地位权限，倡议从产品侧疏导用户去零碎设置增加
不要同时申请前台和后盾拜访地位权限，否则无奈显示受权弹窗

为了激励利用节俭系统资源，Android 12 要求为以 Android 12 为指标平台且设置准确的闹钟的利用配置“闹钟和揭示”非凡利用拜访权限。如需获取这种非凡利用拜访权限，请在清单中申请 SCHEDULE_EXACT_ALARM 权限。准确的闹钟只能用于面向用户的性能，且用户和零碎均可吊销“闹钟和揭示”非凡利用拜访权限，因而须要时加权限判断，否则会抛出 Exception。

须要准确的闹钟的得申请 SCHEDULE_EXACT_ALARM 权限，且应用时做权限判断。

如果利用以 Android 10 或更高版本为指标平台，则它必须具备 ACCESS_FINE_LOCATION 权限能力应用 Telephony、WLAN、WLAN 感知和蓝牙（蓝牙下面章节已介绍）API 中的一些办法。波及影响的类次要有：

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

2）WLAN：WifiManager、WifiAwareManager、WifiP2pManager、WifiRttManager

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

Android 11 更改了利用查问用户已在设施上装置的其余利用以及与之交互的形式。应用 <queries> 元素，利用能够定义一组本身可拜访的其余软件包。通过告知零碎应向您的利用显示哪些其余软件包，此元素有助于激励最小权限准则。此外，此元素还可帮忙 Google Play 等利用商店评估利用为用户提供的隐私权和安全性。

通过辨认发现次要受影响的零碎 API 包含但不限于：queryIntentActivities、getPackageInfo、getInstalledApplications、getInstalledPackages 等。咱们以 getInstalledPackages 和 getInstalledApplications 的 API 为例：

在 Target 降级前，可间接通过 getInstalledPackages 和 getInstalledApplications 来获取装置的利用
当 Target 降级后，如果未命中白名单的，将无奈获取包名。这里提到的白名单次要包含：
1. 您本人的利用，即本身利用
2. 实现 Android 外围性能的某些零碎软件包，如媒体提供程序。
3. 通过 startActivityForResult（留神 startActivity 有效）关上本身利用时的利用（仅当次无效）
4. 装置了您利用的利用（如过后装置本身利用时的利用市场）
5. 通过 bindService/startService/Provider 关上本身利用时的利用（仅当次无效）
6. 本人在 Manifest 中申明的包名 / 签名 /IntentFilter/ProviderAuthorities 清单（见“倡议”）
另外，通过申明 QUERY_ALL_PACKAGES 权限可长期疏忽上述限度，但 Google Play 已要求在 22 年 4 月，除平安、浏览器、文件等必要利用（无导航利用）外，其余应下线此权限，否则会面临下架危险，因而仅可作为兜底计划。

如果有须要查问或者交互的非以后 App 利用组件，须要在 AndroidManifest 中增加 queries 元素。以下有几种倡议，大家可依据本人的理论应用场景来抉择，最好恪守最小应用准则。可思考增加包名、Provider 申明的 android:authorities、通用的 Intent-Filter 等来实现；
【不倡议】在 Manifest 中增加 QUERY_ALL_PACKAGES 做兜底，防止解体，但应思考 Google Play 及海内市场的限度。

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

为了爱护用户隐衷，只有零碎利用和设施政策控制器 (DPC) 反对手动配置 WiFi 网络列表（包含增删改 / 连贯 WiFi 等）。如果利用降级 Target 到 29 且利用不是零碎利用或 DPC，则有些办法不会返回有用数据，具体表现见下节。

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

获取 WiFi 列表；
扫描 WiFi 列表（startScan），在授予“精确定位”（FINE_LOCATION）权限后可失常获取，该行为跟降级前统一；
若用户仅授予“含糊定位”（COARSE_LOCATION），则无奈获取，返回空；
用户已保留的网络（getConfiguredNetworks）则始终无奈获取，返回空；
增加 WiFi（保留网络）。

需更换新 API（addNetworkSuggestions），当增加新 WiFi 时零碎会弹窗期待用户确认（如下图），用户可回绝增加；其它行为和降级前统一。

移除 / 批改保留的 WiFi：需更换为新 API removeNetworkSuggestions；
被动连贯 WiFi：已禁止（enableNetwork），只能交由零碎策略解决或者用户去零碎设置连贯。

获取 WiFi 列表：适配当用户只授予“含糊定位”返回 Null 时的状况；去掉对已保留网络（getConfiguredNetworks）接口的依赖；
增加 / 移除 / 批改保留的 WiFi：更换新 API。思考到有零碎弹窗，如需要的话可疏导用户实现。

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

正告：如果 activity、服务或播送接收器应用 intent 过滤器，并且未显式申明 android:exported 的值，您的利用将无奈在搭载 Android 12 或更高版本的设施上进行装置。

须要 check 一下 activity、服务或播送中蕴含 intent 过滤器的场景。

官网思考对于强制申明 android:exported 属性，次要是思考到安全性，天然也倡议咱们将 exported 属性非必须 true 的都改成 false，现实的角度，举荐大家逐个 check 一下所有的场景。

当然如果大家想更快捷的去解决，举荐在编译期间，解析 AndroidManifest，对于没有被动设置 exported 属性的对立设置，这样也能够一并解决 SDK 相干问题。

这里有个细节须要留神一下，当 Activity 蕴含 intent 过滤器时，如果没有设置 exported 属性，零碎在运行的时候会将 exported 解析成 true 应用，这在零碎的源码中也是有体现的；这样咱们就须要思考历史业务场景中：可能会存在没有给 exported 设置属性，却将 exported 设为 true 来应用。

以 Android 12 或更高版本为指标平台的利用无奈在后盾运行时启动前台服务，多数非凡状况除外。如果利用尝试在后盾运行时启动前台服务，则会引发异样。

应用到启动前台服务（API 如下）的业务场景，须要 check 是否有从后盾启动的状况，如果有看是否满足非凡状况。次要波及：startForegroundService 和 startForeground 办法。

尽量避免，甚至杜绝（随着零碎一直降级，对于从后盾启动前台服务越来越严）从后盾启动前台服务。倡议从动态剖析角度查找所有波及前台调用的 API，梳理和 Check。

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

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

如果在前台服务中须要应用 camera 和 microphone，须要在 AndroidManifest.xml 申明对应类型。如下：<service … android:foregroundServiceType=”camera|microphone” />
不倡议利用在后盾时启动前台服务，因为如果 Target 降级到 31 的时候，除非非凡状况，否则无奈从后盾启动前台服务。

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

应用到 PendingIntent 的业务场景。

依据须要为 PendingIntent 填写 PendingIntent.FLAG_MUTABLE 或 PendingIntent.FLAG_IMMUTABLE 标记；此外，最好提供一个适配的聚合类，其余类都间接调用适配类的办法，这样能够缩小适配老本。

从 Android 9（API 级别 28）开始，Android 平台对利用能应用的非 SDK 接口施行了限度。只有利用援用非 SDK 接口或尝试应用反射或 JNI 来获取其句柄，这些限度就实用。这些限度旨在帮忙晋升用户体验和开发者体验，为用户升高利用产生解体的危险，同时为开发者升高紧急公布的危险。

辨别 SDK 接口和非 SDK 接口： 一般而言，公共 SDK 接口是在 Android 框架软件包索引中记录的那些接口。非 SDK 接口的解决是 API 形象进去的实现细节，因而这些接口可能会在不另行通知的状况下随时产生更改。为了防止产生解体和意外行为，利用应仅应用 SDK 中通过正式记录的类。这也意味着当您的利用通过反射等机制与类互动时，不应拜访 SDK 中未列出的办法或字段；
非 SDK API 名单： 随着每个 Android 版本的公布，会有更多非 SDK 接口受到限制。为最大水平地升高非 SDK 应用限度对开发工作流的影响，将非 SDK 接口分成了几个名单，这些名单界定了非 SDK 接口应用限度的严格水平（取决于利用的指标 API 级别）。

应用 google 官网提供的工具和 Android 12 非 SDK 接口及其对应的名单，就能够对须要的 APP 扫描出后果，依据后果可晓得影响范畴。

现实状况下，咱们应该只应用 SDK(whitelist)；然而一些 App 为了取得一些能力，应用了非 sdk 接口。因而：

对于 greylist，咱们暂且能够应用；
对于 greylist-max-x，咱们须要依据工程中 target 版本来看是否能够暂且应用，greylist-max- p 等价于 max-target-p；
对于 blacklist，则无奈应用。另外所有的非 sdk 接口肯定要加 try catch 爱护。

以上是咱们在 Target 降级中的思考和解法，因为篇幅所限，上述仅介绍了一些隐衷平安相干的“要害要点”，具体的技术实现细节，大家若有趣味，欢送随时在评论区留言探讨。

Target 降级的要害之处，除了内部（厂商、政府政策）的推动，公司外部对于拥抱隐衷合规，对用户负责的积极态度外，还有多方团队的单干，自上而下的器重，以及自内而外的信心，三者缺一不可。Target 降级绝非“一锤子买卖”，它须要长期、坚持不懈的耕耘，能力一直结出果实。心愿咱们的经验，能为大家带来启发，少走弯路，轻装上阵。

关注【阿里巴巴挪动技术】，阿里前沿挪动干货 & 实际给你思考！

简述

1.1 释义：何为 Target 版本

1.2 挑战：变动快、老本高的起因

1.3 收益

隐衷权限

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

背景

现状（SDK=28 为指标平台的利用）

Target 降级后不同拜访形式体现

总结 & 适配倡议

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

波及权限的蓝牙 API

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

适配计划

2.3 大抵地位【31】

背景

不同厂商 / 版本策略

适配计划

2.4 在后盾拜访地位信息的权限【29,30】

背景

降级后的变动

适配倡议

2.5 精准的闹钟权限【31】

背景

适配倡议

2.6 一些电话 API、蓝牙 API 和 WLAN API 须要准确地位权限【29】

背景

适配倡议

平安合规

3.1 软件包可见性【30】

背景

现状 & 影响

倡议

补充

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

背景

降级后的变动

适配倡议

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

背景

影响

思考 & 倡议

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

背景

影响

倡议：

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

背景：

影响

倡议

3.6 待处理 intent 可变性【31】

背景

影响

倡议

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

背景

影响

倡议

写在完结前