Permission Group v Androidu — co to je, skupiny oprávnění a princip fungování

Co je Permission Group v Androidu

Permission Group — je systémový mechanismus Androidu, který kombinuje několik nebezpečných oprávnění do jedné skupiny na základě jejich funkčního účelu. Každá skupina má řetězcový identifikátor, například android.permission-group.CAMERA nebo android.permission-group.LOCATION. Všechna oprávnění v rámci jedné skupiny jsou logicky propojena a poskytují přístup k příbuzným funkcím zařízení.

Skupiny oprávnění se objevily v Android 6.0 Marshmallow spolu s modelem žádostí za běhu. Jejich hlavním účelem je zjednodušit interakci s uživatelem: místo série dialogů pro každé jednotlivé oprávnění systém zobrazuje jeden dialog na skupinu. Pokud uživatel udělil jedno oprávnění ze skupiny, ostatní jsou považovány za automaticky schválené. Podle Android UX Research (2015) to snížilo počet odmítnutí při prvním spuštění o 20 procent.

Je důležité pochopit, že vývojář nemůže vytvářet vlastní Permission Group. Skupiny jsou předdefinovány na úrovni operačního systému a popsány v souborech permissions.xml na každém zařízení. Aplikace pouze specifikuje uses-permission a systém automaticky přiřadí oprávnění k jeho skupině na základě protectionLevel a kategorizace v AOSP.

Jak systém určuje skupinu

Přiřazení oprávnění ke skupině probíhá prostřednictvím atributu permissionGroup v systémové definici oprávnění. Například CAMERA je deklarováno s permissionGroup="android.permission-group.CAMERA", ACCESS_FINE_LOCATION — s permissionGroup="android.permission-group.LOCATION". Toto mapování je pevně stanoveno v kódu Android Open Source Project a je stejné na všech certifikovaných zařízeních.

Jak fungují Permission Group

Mechanismus skupin funguje na principu „jeden dialog na skupinu”. Když aplikace poprvé žádá o jakékoli nebezpečné oprávnění, systém zkontroluje jeho Permission Group. Pokud dosud nebylo uděleno žádné oprávnění z této skupiny — zobrazí se dialog. Po souhlasu systém označí celou skupinu jako udělenou a následné žádosti o jiná oprávnění ze stejné skupiny jsou splněny bez uživatelského rozhraní.

Algoritmus zjednodušeně vypadá následovně:

• Aplikace volá requestPermissions pro ACCESS_FINE_LOCATION
• Systém určí skupinu — android.permission-group.LOCATION
• Zkontroluje, zda byla skupina LOCATION již dřúveve udělena
• Pokud ne — zobrazí dialog s názvem skupiny a seznamem zahrnutých oprávnění
• Po Allow — celá skupina LOCATION je považována za udělenou
• ACCESS_COARSE_LOCATION je nyní k dispozici bez další žádosti

Tento mechanismus se vztahuje pouze na nebezpečná oprávnění. Normální oprávnění nemají skupiny a neúčastní se této logiky. Privilegovaná a podepsaná oprávnění se také neseskupují — mají samostatný systém řízení přístupu.

Omezení skupinové logiky

Skupiny nefungují opačným směrem: odvolání jednoho oprávnění ze skupiny prostřednictvím nastavení odvolá pouze toto oprávnění, aniž by ovlivnilo ostatní. Pokud uživatel odmítl dialog pro skupinu, neblokuje to ostatní skupiny — každé nové oprávnění z jiné skupiny zobrazí vlastní dialog. Permission Group ovlivňuje pouze UX žádosti, nikoli bezpečnostní model.

Seznam Permission Group v Androidu

Android definuje následující systémové Permission Groups pro nebezpečná oprávnění. Každá skupina zahrnuje jedno nebo více oprávnění spojených společným funkčním účelem.

Změny v nových verzích

V Android 13 (API 33) se objevila nová skupina NEARBY_DEVICES, kombinující BLUETOOTH_SCAN, BLUETOOTH_CONNECT a BLUETOOTH_ADVERTISE. Také skupina STORAGE byla částečně nahrazena mediálními oprávněními READ_MEDIA_IMAGES, READ_MEDIA_VIDEO a READ_MEDIA_AUDIO, která nejsou součástí STORAGE, ale jsou nezávislými nebezpečnými oprávněními bez seskupování.

Skupiny pro vlastní oprávnění

Vývojáři mohou deklarovat vlastní oprávnění s vlastními Permission Groups pomocí atributu permissionGroup v manifestu. To však funguje pouze pro vlastní oprávnění stejné aplikace a neovlivňuje systémové UI dialogy. V praxi se vlastní Permission Groups používají zřídka — pro interakci mezi vlastními aplikacemi v jednom zásobníku.

Permission Group a UX

Vliv Permission Group na uživatelský zážitek je významný. Díky seskupování uživatel nevidí 8 samostatných dialogů pro různá oprávnění, ale několik skupinových dialogů. To snižuje kognitivní zátěž a snižuje pravděpodobnost, že uživatel odmítne kritické oprávnění, aniž by pochopil jeho účel.

UX výzkumy ukazují, že skupinové dialogy jsou uživateli vnímány jako transparentnější. Když aplikace žádá o „přístup ke kameře”, uživatel chápe kontext. Pokud by každé oprávnění bylo žádáno samostatně — CAMERA, CAMERA2, FLASHLIGHT — vytvořilo by to dojem nadbytečnosti. Permission Group tuto podrobnost abstrahuje.

Nejlepší praxí je žádat o oprávnění pouze z jedné skupiny najednou. Pokud aplikace potřebuje kameru i geolokaci, nežádejte o ně jediným voláním requestPermissions. Nejprve požádejte o jednu skupinu po vysvětlení, poté o druhou. To dává uživateli kontrolu a postupné pochopení každé funkce.

Permission Group vs ProtectionLevel

Permission Group a ProtectionLevel — to jsou dva různé rozměry systému oprávnění Androidu. ProtectionLevel určuje, jak je oprávnění udělováno (normal, dangerous, signature, privileged), zatímco Permission Group je kategorie pro zobrazení v UI. Jsou nezávislé, ale v praxi je kombinace dangerous + permission group nejčastější.

Oprávnění stejného ProtectionLevel mohou patřit do různých skupin. Například ACCESS_FINE_LOCATION a CAMERA mají obě protectionLevel dangerous, ale patří do různých skupin — LOCATION a CAMERA. A naopak, oprávnění se stejným názvem vždy patří do stejné skupiny: ACCESS_FINE_LOCATION a ACCESS_COARSE_LOCATION jsou obě v LOCATION.

Vyšší úrovně ochrany — signature a privileged — nepoužívají Permission Group pro UI. Jejich udělování je řízeno na úrovni systému: signature je udělováno aplikacím podepsaným stejným certifikátem jako systém, a privileged aplikacím v systémovém obrazu. Skupiny pro taková oprávnění existují, ale neovlivňují UX dialogy, protože tyto dialogy jednoduše neexistují.

Kontrola Permission Group v kódu

Vývojář může programově určit Permission Group libovolného oprávnění prostřednictvím PackageManager. Metoda getPermissionInfo vrací PermissionInfo s polem group obsahujícím řetězcový identifikátor skupiny. To je užitečné pro logování, analytiku a vlastní UI obrazovky oprávnění.

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

Použití v DI a architektuře

Znalost Permission Group pomáhá při budování architektury žádostí. Lze vytvořit abstrakci PermissionGroupProvider, která vrací seznam oprávnění pro konkrétní skupinu. To zjednodušuje testování: v jednotkových testech provider vrací falešná data bez volání PackageManager. V instrumentálních testech — skutečné skupiny ze systému.

PermissionGroupProvider v DI

Integrace PermissionGroupProvider prostřednictvím Dagger Hilt nebo Koin umožňuje centralizované řízení mapování oprávnění a skupin. V provideru lze uložit do mezipaměti výsledek PackageManager.queryPermissionsByGroup, aby se předešlo opakovaným systémovým voláním při každé žádosti. To je důležité zejména pro obrazovky nastavení, kde se zobrazuje úplný seznam oprávnění a jejich stav.

Logování a analytika

Při sběru analytiky o odmítnutích je užitečné logovat nejen název oprávnění, ale také jeho Permission Group. To pomáhá identifikovat funkční oblasti, které způsobují nejvíce odmítnutí. Například skupina LOCATION má tradičně nejvyšší procento odmítnutí — kolem 40 procent, podle statistik Google Play Console.

Analytika podle skupin pomáhá při produktových rozhodnutích: pokud má skupina CONTACTS vysoké procento odmítnutí, možná stojí za to přehodnotit načasování žádosti nebo přidat vysvětlující dialog. Skupinový přístup k analytice poskytuje úplnější obrázek než analýza jednotlivých oprávnění, protože počet odmítnutí pro celou skupinu odráží obecný postoj uživatelů k funkční oblasti.