Permission Group in Android — what it is, permission groups and how they work

What is Permission Group in Android

Permission Group is an Android system mechanism that groups several dangerous permissions into one group based on their functional purpose. Each group has a string identifier, for example android.permission-group.CAMERA or android.permission-group.LOCATION. All permissions within one group are logically related and provide access to related device functions.

Permission groups appeared in Android 6.0 Marshmallow along with the runtime permission model. Their main purpose is to simplify user interaction: instead of a series of dialogs for each individual permission, the system shows one dialog per group. If the user grants one permission from a group, the rest are considered automatically approved. According to Android UX Research (2015), this reduced the number of denials on first launch by 20 percent.

It is important to understand that developers cannot create their own Permission Groups. Groups are predefined at the operating system level and are described in permissions.xml files on each device. The app only declares uses-permission, and the system automatically maps the permission to its group based on protectionLevel and categorization in AOSP.

How the system determines the group

The mapping of a permission to a group occurs through the permissionGroup attribute in the system permission definition. For example, CAMERA is declared with permissionGroup="android.permission-group.CAMERA", ACCESS_FINE_LOCATION with permissionGroup="android.permission-group.LOCATION". This mapping is hardcoded in the Android Open Source Project code and is identical on all certified devices.

How Permission Groups Work

The group mechanism works on the principle of “one dialog per group.” When an app first requests any dangerous permission, the system checks its Permission Group. If no permission from this group has been granted yet, a dialog is shown. After consent, the system marks the entire group as granted, and subsequent requests for other permissions from the same group are satisfied without UI.

The algorithm simplified looks like this:

• The app calls requestPermissions for ACCESS_FINE_LOCATION
• The system determines the group — android.permission-group.LOCATION
• Checks whether the LOCATION group has been granted previously
• If not, shows a dialog with the group name and list of included permissions
• After Allow — the entire LOCATION group is considered granted
• ACCESS_COARSE_LOCATION is now available without an additional request

This mechanism applies only to dangerous permissions. Normal permissions do not have groups and do not participate in this logic. Privileged and signature permissions are also not grouped — they have a separate access control system.

Limitations of group logic

Groups do not work “in reverse”: revoking one permission from a group through settings revokes only that permission without affecting the others. Also, if a user declines the dialog for a group, it does not block other groups — each new permission from a different group will show its own dialog. Permission Group only affects the request UX, not the security model.

List of Permission Groups in Android

Android defines the following system Permission Groups for dangerous permissions. Each group includes one or more permissions united by a common functional purpose.

Changes in new versions

On Android 13 (API 33), a new group NEARBY_DEVICES appeared, combining BLUETOOTH_SCAN, BLUETOOTH_CONNECT, and BLUETOOTH_ADVERTISE. Also, the STORAGE group was partially replaced by media permissions READ_MEDIA_IMAGES, READ_MEDIA_VIDEO, and READ_MEDIA_AUDIO, which are not part of STORAGE but are standalone dangerous permissions without grouping.

Custom permission groups

Developers can declare their own permissions with custom Permission Groups via the permissionGroup attribute in the manifest. However, this only works for custom permissions of the same app and does not affect system UI dialogs. In practice, custom Permission Groups are rarely used — for interaction between apps in the same stack.

Permission Group and UX

The impact of Permission Group on user experience is significant. Thanks to grouping, the user sees not 8 separate dialogs for different permissions but a few group dialogs. This reduces cognitive load and decreases the likelihood that a user will deny a critically important permission without understanding its purpose.

UX research shows that group dialogs are perceived by users as more transparent. When an app requests “permission to access the camera,” the user understands the context. If each permission were requested separately — CAMERA, CAMERA2, FLASHLIGHT — it would create an impression of redundancy. Permission Group abstracts this granularity.

The best practice is to request permissions from only one group at a time. If an app needs both camera and location, do not request them in a single requestPermissions call. First request one group after explaining why it is needed, then the second. This gives the user control and a sequential understanding of each feature.

Permission Group vs ProtectionLevel

Permission Group and ProtectionLevel are two different dimensions of the Android permission system. ProtectionLevel determines how a permission is granted (normal, dangerous, signature, privileged), while Permission Group is a category for UI display. They are independent, but in practice the combination of dangerous + permission group is the most common.

Permissions of the same ProtectionLevel can belong to different groups. For example, ACCESS_FINE_LOCATION and CAMERA both have protectionLevel dangerous but belong to different groups — LOCATION and CAMERA. Conversely, similarly named permissions always belong to the same group: ACCESS_FINE_LOCATION and ACCESS_COARSE_LOCATION are both in LOCATION.

Higher-level protection levels — signature and privileged — do not use Permission Groups for UI. Their granting is controlled at the system level: signature is granted to apps signed with the same certificate as the system, and privileged to apps in the system image. Groups for such permissions exist but do not affect UX dialogs because these dialogs simply do not appear.

Checking Permission Group in Code

Developers can programmatically determine the Permission Group of any permission through PackageManager. The getPermissionInfo method returns PermissionInfo with a group field containing the string identifier of the group. This is useful for logging, analytics, and custom permission UI screens.

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 }
}

Usage in DI and architecture

Knowledge of Permission Groups helps build request architecture. You can create an abstraction called PermissionGroupProvider that returns the list of permissions for a specific group. This simplifies testing: in unit tests, the provider returns mock data without calling PackageManager. In instrumentation tests, it returns real groups from the system.

PermissionGroupProvider in DI

Integrating PermissionGroupProvider via Dagger Hilt or Koin allows centralized management of permission-to-group mapping. In the provider, you can cache the result of PackageManager.queryPermissionsByGroup to avoid repeated system calls on every request. This is especially important for settings screens where the full list of permissions and their status is displayed.

Logging and analytics

When collecting analytics about denials, it is useful to log not only the permission name but also its Permission Group. This helps identify which functional areas cause the highest number of denials. For example, the LOCATION group traditionally has the highest denial rate — about 40 percent, according to Google Play Console statistics.

Analytics by groups helps make product decisions: if the CONTACTS group has a high denial rate, you may want to reconsider the request timing or add a rationale dialog. The group-based approach to analytics provides a more complete picture than analyzing individual permissions, as the denial count across an entire group reflects the overall user attitude toward a functional area.