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

Какво е Permission Group в Android

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. Ако никой разрешение от тази група все още не е предоставено — се показва диалог. След съгласие, системата маркира цялата група като предоставена и последващите заявки за други разрешения от същата група се удовлетворяват без потребителски интерфейс.

Алгоритъмът опростено изглежда така:

• Приложението вика 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 срещу 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 позволява централизирано управление на картирането на разрешенията и групите. В provider-а резултатът от PackageManager.queryPermissionsByGroup може да бъде кеширан, за да се избегнат повторни системни повикания при всяка заявка. Това е особено важно за екраните на настройките, където се показва пълен списък на разрешенията и тяхното състояние.

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

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

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