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". Це зіставлення жорстко задане в коді 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, яка повертає список дозволів для конкретної групи. Це спрощує тестування: в юніт-тестах провайдер повертає фіктивні дані без звернення до PackageManager. В інструментальних тестах — реальні групи із системи.

PermissionGroupProvider в DI

Інтеграція PermissionGroupProvider через Dagger Hilt або Koin дозволяє централізовано керувати маппінгом дозволів і груп. У провайдері можна закешувати результат PackageManager.queryPermissionsByGroup, щоб не робити повторні системні виклики при кожному запиті. Це особливо важливо для екранів налаштувань, де відображається весь список дозволів та їхній статус.

Логування та аналітика

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

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