Permission Group в Android — что это такое, группы разрешений и принцип работы

Что такое Permission Group в Android

Permission Group — это системный механизм Android, объединяющий несколько опасных разрешений в одну группу на основе их функционального назначения. Каждая группа имеет строковый идентификатор, например android.permission-group.CAMERA или android.permission-group.LOCATION. Все разрешения внутри одной группы логически связаны и предоставляют доступ к смежным функциям устройства.

Группы разрешений появились в Android 6.0 Marshmallow вместе с runtime-моделью запросов. Их основная цель — упростить взаимодействие с пользователем: вместо серии диалогов для каждого отдельного разрешения система показывает один диалог на группу. Если пользователь предоставил одно разрешение из группы, остальные считаются автоматически одобренными. По данным 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". Этот mapping жёстко задан в коде Android Open Source Project и одинаков на всех сертифицированных устройствах.

Как работают Permission Group

Механизм групп работает по принципу «одного диалога на группу». Когда приложение впервые запрашивает любое опасное разрешение, система проверяет его Permission Group. Если ни одно разрешение из этой группы ещё не предоставлено — показывается диалог. После согласия система помечает всю группу как предоставленную, и последующие запросы других разрешений из той же группы удовлетворяются без UI.

Алгоритм упрощённо выглядит так:

• Приложение вызывает requestPermissions для ACCESS_FINE_LOCATION
• Система определяет группу — android.permission-group.LOCATION
• Проверяет, предоставлена ли группа LOCATION ранее
• Если нет — показывает диалог с названием группы и списком входящих разрешений
• После Allow — вся группа LOCATION считается предоставленной
• ACCESS_COARSE_LOCATION теперь доступен без дополнительного запроса

Этот механизм распространяется только на опасные разрешения. Нормальные разрешения не имеют групп и не участвуют в этой логике. Привилегированные и подписанные разрешения также не группируются — они имеют отдельную систему управления доступом.

Ограничения групповой логики

Группы не работают «в обратную сторону»: отзыв одного разрешения из группы через настройки отзывает только его, не затрагивая остальные. Также если пользователь отклонил диалог для группы, это не блокирует другие группы — каждое новое разрешение из другой группы покажет свой собственный диалог. Permission Group влияет только на UX запроса, не на модель безопасности.

Список Permission Group в Android

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, а являются самостоятельными опасными разрешениями без группировки.

Группы для кастомных разрешений

Разработчики могут объявлять собственные разрешения с кастомными Permission Group через атрибут permissionGroup в манифесте. Однако это работает только для кастомных разрешений того же приложения и не влияет на системные UI-диалоги. На практике кастомные Permission Group используются редко — для взаимодействия между своими приложениями в одном стеке.

Permission Group и UX

Влияние Permission Group на пользовательский опыт существенно. Благодаря группировке пользователь видит не 8 отдельных диалогов для разных разрешений, а несколько групповых диалогов. Это снижает когнитивную нагрузку и уменьшает вероятность, что пользователь отклонит критически важное разрешение, не поняв его назначения.

Исследования UX показывают, что групповые диалоги воспринимаются пользователями как более прозрачные. Когда приложение запрашивает «разрешение на доступ к камере», пользователь понимает контекст. Если бы каждое разрешение запрашивалось отдельно — CAMERA, CAMERA2, FLASHLIGHT — это создало бы впечатление избыточности. Permission Group абстрагирует эту детализацию.

Лучшая практика — запрашивать разрешения только из одной группы за раз. Если приложению нужны и камера, и геолокация, не стоит запрашивать их одним вызовом requestPermissions. Сначала запросите одну группу после объяснения, зачем она нужна, затем — вторую. Это даёт пользователю контроль и последовательное понимание каждой функции.

Permission Group vs 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 в коде

Разработчик может программно определить Permission Group любого разрешения через PackageManager. Метод 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. В инструментальных тестах — реальные группы из системы.

PermissionGroupProvider в DI

Интеграция PermissionGroupProvider через Dagger Hilt или Koin позволяет централизованно управлять маппингом разрешений и групп. В провайдере можно закэшировать результат PackageManager.queryPermissionsByGroup, чтобы не делать повторные системные вызовы при каждом запросе. Это особенно важно для экранов настроек, где отображается весь список разрешений и их статус.

Логирование и аналитика

При сборе аналитики об отказах полезно логировать не только имя разрешения, но и его Permission Group. Это позволяет выявить, какие функциональные области вызывают наибольшее количество отказов. Например, группа LOCATION традиционно имеет самый высокий процент отказов — около 40 процентов, согласно статистике Google Play Console.

Аналитика по группам помогает принимать продуктовые решения: если группа CONTACTS имеет высокий процент отказов, возможно, стоит пересмотреть момент запроса или добавить rationale-диалог. Групповой подход к аналитике даёт более полную картину, чем анализ отдельных разрешений, так как количество отказов по всей группе отражает общее отношение пользователей к функциональной области.