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 има висок проценат одбијања, можда је вредно преиспитати тренутак захтева или додати дијалог са образложењем. Групни приступ аналитици пружа потпунију слику него анализа појединачних дозвола, јер број одбијања за целу групу одражава општи однос корисника према функционалној области.