隐私策略更新 | Android 11 应用兼容性适配

做者 / Fred Chung

Android 11 的最终版本已正式发布！该版本延续了以前发行版本里不断改进的隐私策略，为用户提供更加完善的控制机制和透明度，并帮助应用更好地处理自身的数据。

其中不少优化将当前安全策略的最佳实践应用于最近的 Android 发行版本中（它们并不只仅针对 Android 11）。在本文中，咱们将如下面四个最佳实践做为切入点，助力您的应用设计与时俱进，并计划开始进行兼容性测试。

1. 处理内容 URI 分享
2. 递增式权限申请
3. 在前台访问敏感数据
4. 使用可重置的标识符

为其它应用提供合适的 URI 权限

随着 Android 11 中 软件包可见性 的策略更新，目标 API 级别为 30 的应用对设备上已安装的其它软件包默认仅拥有受限的可见性。这样的设计旨在为应用“查看”设备上的其它已安装软件包时，提供更好的“问责”制度。

为了简化迁移，对于常见的应用场景，咱们提供了 实现指南。一般，应用须要具有对其它已安装软件包的可见性（经过 PackageManager API 验证）才能够和其它软件包进行交互。该特性一般应用于诸如：启动服务，或者访问属于其它应用的 Content Provider。

您访问 Content Provider 的模式可能不是经过发送显式 intent 到某个特定的应用，而是经过发送隐式 intent。这样的话，您没法预判接收端应用（最终处理这个 intent 的应用）的目标 API 等级，而这个等级决定了接收端应用是否会受到 Android 11 中引入的应用包可见性限制的影响。

为了保证接收端应用可以"查看"您的软件包，从而可以访问任何共享的 URI，您须要在 intent 中添加 FLAG_GRANT_READ_URI_PERMISSION 和/或者 FLAG_GRANT_WRITE_URI_PERMISSION。请注意，写入权限并不包含读取访问权限。当被 intent 触发之后，接收端应用会被授予对相关 URI 的临时访问权限。

val shareIntent = Intent(Intent.ACTION_VIEW).apply {
    flags = Intent.FLAG_GRANT_READ_URI_PERMISSION
    data = //须要向其它应用共享的 Content Uri
}

随着应用的目标 SDK 版本的更新（即便更新到 Android 11 以前的版本），请您特别关注涉及到与其它应用分享 Content Provider 访问权限的用例，并确保授予适当的 URI 权限。不管哪一个应用是这 content provider 的拥有者，这个策略都管用。

一般，咱们要将数据访问程度限制为当前任务所需的水平，若是您遵循了这个最佳实践，您的 Content Provider 访问权限应该是按照个别 URI 模式 设定的。只要作到这点，您的 Content Provider 就已经能够兼容 Android 11 了！

递增式申请权限

Android 用户研究报告 显示，在请求获取用户的受权时，那些符合用户指望值的请求更有可能被获准。所以，当您应用中的某个功能须要这些权限时，最佳实践是在上下文中 请求权限。

用户授予权限的缘由排行。来源：Android 用户研究报告

△ 大多数用户会为了使用某个特定的功能而选择赞成受权

这项策略对于敏感权限尤为适用，如位置访问权限。从 Android 10 开始，平台引入了细粒度的位置模型，区分了前台和后台位置访问。大多数位置场景仅须要前台访问，好比当用户在操做 Activity 的时候。

事实上，Google Play 已经出台了相关政策限制没必要要的后台位置访问。要检查您的应用可能在哪些地方从后台访问位置，请参阅：后台访问位置信息文档。若是您的应用须要后台位置权限，好比地理围栏应用，请确保后台位置对您的功能设计是不可或缺的。

对于适用的应用，须要先申请前台位置权限，而后在稍晚些再申请后台位置权限。这种方法为用户提供了控制权限授予级别的选择。此外，您还能够有策略地显示一个权限申请的说明，或者设计一个合理的交互界面，为用户提供更多信息，以说明用户授予位置权限以后所得到的的功能提高。

Android 11 要求面向 API 级别为 30 的应用使用递增式位置权限请求。任何同时申请前台位置权限（不管是粗略位置仍是精确位置）和后台位置权限的请求都会被忽略而且返回以下错误信息。

E/GrantPermissionsActivity: Apps targeting 30 must have foreground permission before requesting background and must request background on its own.

请注意在 requestPermissions() API 请求的任何其它非位置权限也会同时被忽略。

由于 requestPermissions API 接受一个由所需权限组成的数组做为参数，您现有的代码可能已有了同时申请多个权限的状况（以下所示），所以这里咱们鼓励你们检查和审核一下本身的代码，若是代码修改影响到用户交互，则须要按需进行相应设计。

若是启用了 ActivityCompat 或者框架 API：

requestPermissions(
        arrayOf(
            // 不要同时申请前台位置权限和后台位置权限
            // 由于全部同时申请的权限都会被忽略
            // 而是经过增量式请求位置权限
            android.Manifest.permission.ACCESS_COARSE_LOCATION,         
            android.Manifest.permission.ACCESS_BACKGROUND_LOCATION,

            ...)

        )

一样地，若是启用了 Jetpack Activity 库：

// 使用 Activity 库
val requestPermissionsLauncher =
                registerForActivityResult(ActivityResultContracts.RequestMultiplePermissions()) {
                    map: MutableMap<String, Boolean> ->
                        ...
                }
...

requestPermissionsLauncher.launch(
        arrayOf(
            // 不要同时申请前台位置权限和后台位置权限
            // 由于全部同时申请的权限都会被忽略
            // 而是经过增量式请求位置权限
            android.Manifest.permission.ACCESS_COARSE_LOCATION,         
            android.Manifest.permission.ACCESS_BACKGROUND_LOCATION,

            ...)
    )

合理访问位置、麦克风和相机

Android 的系统设计支持公开透明地访问敏感数据，好比麦克风、相机和位置。例如，应用在前台的时候，也就是用户能看到应用界面的时候，才可使用麦克风和相机。这样能够提升公开透明性，因此用户能够在知情的状况下启用相关特性。

若是您的应用包含访问敏感数据的前台服务，请确认应用场景中包含直接的用户交互，使用户能够控制所执行的任务。例如，在一个视频会议应用中，您可使用一个前台服务来支持活跃的会议进程，其中会涉及到访问麦克风和相机。其中应该包含一个对于用户可见的用于启动和中止会议进程的操做，也就是该前台服务。

此外，您的应用必须正确设置 foregroundServiceType 属性来代表位置、麦克风或者相机的用途。这样能够为应用增长系统可见性，同时在 Android 11 中也是必须配置的属性。更多信息请访问：Android 11 中的前台服务。

您可能须要在 AndroidManifest 中声明多种数据类型的用途。

android:foregroundServiceType = "microphone location camera"

 
若是您的功能是基于 WorkManager 的 长时间运行的 worker 来实现的，那么它其实是运行在叫作 SystemForegroundService 的前台服务上。您应该在应用的 AndroidManifest 中包含适合的前台服务类型，它会同 Jetpack 库的 AAR AndroidManifest 文件 合并。  

在应用的 AndroidManifest 中添加下面的声明，而且在其中定义所需的前台服务类型。

<service
    android:name="androidx.work.impl.foreground.SystemForegroundService"
    android:foregroundServiceType="location|microphone"//这里选择和您的应用相关的服务类型
    tools:node="merge" />

当您须要将 worker 之前台服务运行时，您须要将合适的前台服务类型传入 ForegroundInfo 对象。传入的服务类型必须和上面在 AndroidManifest 中添加的声明一致或者是其子集。

setForeground(
    ForegroundInfo(NOTIF_ID,
           notification.build(),
           // 前台服务类型
        ServiceInfo.FOREGROUND_SERVICE_TYPE_LOCATION or ...)
)

弃用不可重置标识符

Android 系统使用了一些不可重置的硬件标识符，好比 IMEI 以支持各类操做系统功能。出于隐私方面的考虑，这些相对“强大”的持久性和惟一性的标识符不适合用于大部分应用场景。

从 Android 10 开始，系统对不可重置的设备标识符 实施了限制。好比，只有带有 READ_PRIVILEGED_PHONE_STATE 权限的系统应用才能够经过 getSimSerialNumber()) 方法访问 SIM 卡的硬件标识符。在 Android 11 中，操做系统对 getIccId()) 方法也增长了相似的限制来进一步 限制访问权限，如今该方法仅返回空字符串。

对于须要使用 SIM 卡信息做为惟一性标识的应用，须要在 Android 11 里进行“空字符串”的兼容性检查。一个替代方案是使用 getSubscriptionId()) 方法，它会针对设备上指定的 SIM 卡信息返回一个以数字 1 开头的惟一索引值，也就是说，若是同一张 SIM 卡被从新安装到设备上的话，它会保持以前的订阅标识符，除非设备恢复出厂设置。更多请参阅：惟一标识符最佳作法。

平台和 Google Play 服务为应用提供了一些其它的 标识符，提供各类惟一性、可重置性和有做用域限制的标识符，适用于各类不一样的应用场景。更多请参阅：惟一标识符最佳作法。

以上内容可以帮助你们更快更新适配最新的 API ，并设计出对隐私更友好的应用。更多资源请参阅：

• Android 11 中的改进
• 隐私设置最佳实践