Android中的Permission Group——它是什么、权限组和工作原理

Android中的Permission Group是什么

Permission Group — 是Android的系统机制，根据功能用途将多个危险权限组合到一个组中。每个组都有一个字符串标识符，例如android.permission-group.CAMERA或android.permission-group.LOCATION。一个组中的所有权限都逻辑相关，提供对设备相关功能的访问。

权限组随Android 6.0 Marshmallow一起出现，同时引入了运行时请求模型。它们的主要目标是简化与用户的交互：替代为每个单独权限弹出一系列对话框，系统为每个组显示一个对话框。如果用户已经授予了某个组中的一个权限，其他权限将被视为自动批准。根据Android UX Research (2015)，这将首次启动时的拒绝率降低了20%。

重要的是，开发者无法创建自己的Permission Group。组在操作系统层面预先定义，并在每个设备的permissions.xml文件中描述。应用程序只指定uses-permission，系统会根据protectionLevel和AOSP中的分类自动将权限与其组匹配。

系统如何确定组

权限与组的匹配通过权限系统定义中的permissionGroup属性完成。例如，CAMERA声明为permissionGroup="android.permission-group.CAMERA"，ACCESS_FINE_LOCATION声明为permissionGroup="android.permission-group.LOCATION"。这个映射在Android Open Source Project代码中确定，在所有认证设备上都相同。

Permission Group如何工作

组机制按“每组一个对话框”原则工作。当应用程序首次请求任何危险权限时，系统会检查其Permission Group。如果还没有授予该组中的任何权限，则会显示一个对话框。同意后，系统将整个组标记为已授予，并且后续对同一组中其他权限的请求将在没有用户界面的情况下被满足。

简化的算法如下：

• 应用程序为ACCESS_FINE_LOCATION调用requestPermissions
• 系统确定组——android.permission-group.LOCATION
• 检查LOCATION组是否已经被授予
• 如果没有——显示一个对话框，包含组名称和包含的权限列表
• 在Allow之后——整个LOCATION组被视为已授予
• ACCESS_COARSE_LOCATION现在可以无需额外请求访问

这个机制仅适用于危险权限。普通权限没有组，不参与这个逻辑。特权和签名权限也不会被分组——它们有单独的访问管理系统。

组逻辑的局限性

组不能反向工作：通过设置撤销组中的一个权限只会撤销该权限，不会影响其他权限。此外，如果用户拒绝了某个组的对话框，这不会阻止其他组——来自另一个组的每个新权限都会显示自己的对话框。Permission Group仅影响请求的UX，而不影响安全模型。

Android中的Permission Group列表

Android定义了以下用于危险权限的系统 Permission Group。每个组包含一个或多个由共同功能目标联合起来的权限。

新版本中的变化

在Android 13（API 33）中出现了一个新组NEARBY_DEVICES，它组合了BLUETOOTH_SCAN、BLUETOOTH_CONNECT和BLUETOOTH_ADVERTISE。此外，STORAGE组部分被媒体权限READ_MEDIA_IMAGES、READ_MEDIA_VIDEO和READ_MEDIA_AUDIO所取代，这些不是STORAGE的一部分，而是没有分组的独立危险权限。

自定义权限的组

开发者可以通过清单中的permissionGroup属性声明自己的权限，并使用自定义Permission Group。但这仅适用于同一应用程序的自定义权限，不会影响系统UI对话框。在实践中，自定义Permission Group很少使用——用于在同一栈中自己的应用程序之间进行交互。

Permission Group和UX

Permission Group的影响对用户体验很大。由于分组，用户看到的不是针对不同权限的8个单独对话框，而是几个组对话框。这减轻了认知负荷，并降低了用户在不理解其目的的情况下拒绝关键权限的可能性。

UX研究表明，用户觉得组对话框更透明。当应用程序请求“访问相机”时，用户理解上下文。如果每个权限都单独请求——CAMERA、CAMERA2、FLASHLIGHT——这会给人一种冗余的感觉。Permission Group抽象了这种细节。

最佳实践是每次只请求来自一个组的权限。如果应用程序同时需要相机和地理位置，不要通过一个requestPermissions调用来请求它们。先在解释后请求一个组，然后再请求第二个。这给予用户控制权，并逐步理解每个功能。

Permission Group与ProtectionLevel

Permission Group和ProtectionLevel——这是Android权限系统的两个不同维度。ProtectionLevel确定如何授予权限（normal、dangerous、signature、privileged），而Permission Group是用于UI显示的类别。它们独立，但在实践中，dangerous + permission group的组合最为常见。

相同ProtectionLevel的权限可以属于不同的组。例如，ACCESS_FINE_LOCATION和CAMERA都具有protectionLevel dangerous，但属于不同的组——LOCATION和CAMERA。反之亦然，同名的权限始终属于同一个组：ACCESS_FINE_LOCATION和ACCESS_COARSE_LOCATION都在LOCATION中。

更高级别的保护级别——signature和privileged——不使用Permission Group进行UI显示。它们的授予在系统层面控制：signature授予给与系统使用相同证书签名的应用程序，privileged授予给系统镜像中的应用程序。这类权限的组确实存在，但不会影响UX对话框，因为这些对话框根本不存在。

在代码中检查Permission Group

开发者可以通过PackageManager程序化地确定任何权限的Permission Group。getPermissionInfo方法返回一个PermissionInfo，其中的group字段包含组的字符串标识符。这对于日志记录、分析和自定义权限UI屏幕很有用。

fun getPermissionGroupName(
    permission: String
): String? {
    return try {
        val pm = packageManager
        val info = pm.getPermissionInfo(
            permission,
            PackageManager.GET_META_DATA
        )
        info.group
    } catch (e: NameNotFoundException) {
        null
    }
}

fun getPermissionsByGroup(
    group: String
): List<String> {
    val pm = packageManager
    val perms = pm.queryPermissionsByGroup(
        group,
        PackageManager.GET_META_DATA
    )
    return perms.map { it.name }
}

在DI和架构中的使用

了解Permission Group有助于構建请求架构。可以创建一个PermissionGroupProvider抽象，它返回特定组的权限列表。这简化了测试：在单元测试中，provider返回伪造数据而不调用PackageManager。在工具测试中，则返回来自系统的真实组。

DI中的PermissionGroupProvider

通过Dagger Hilt或Koin集成PermissionGroupProvider可以集中管理权限和组的映射。在provider中可以缓存PackageManager.queryPermissionsByGroup的结果，以避免每次请求时重复调用系统。这对于显示所有权限及其状态的设置屏幕尤其重要。

日志记录和分析

在收集关于拒绝的分析数据时，不仅记录权限名称，还记录其Permission Group也很有用。这有助于识别导致最多拒绝的功能域。例如，LOCATION组一向拥有最高的拒绝率——根据Google Play Console统计数据，约为40%。

按组分析有助于做出产品决策：如果CONTACTS组的拒绝率很高，可能需要重新考虑请求时机或添加解释对话框。基于组的分析方法比单独权限分析提供更完整的图景，因为整个组的拒绝数反映了用户对功能域的整体态度。