Permission Group Androidban — mi ez, engedélycsoportok és működési elv

Hogyan működnek a Permission Group-ok

A csoportmechanizmus az „egy párbeszédablak csoportonként" elv szerint működik. Amikor az alkalmazás először kér bármilyen veszélyes engedélyt, a rendszer ellenőrzi annak Permission Group-ját. Ha még egyetlen engedélyt sem adtak meg ebből a csoportból — megjelenik egy párbeszédablak. A beleegyezés után a rendszer az egész csoportot megadottként jelöli meg, és a későbbi kérések ugyanabból a csoportból származó más engedélyekre felhasználói felület nélkül teljesülnek.

Az algoritmus egyszerűsítve így néz ki:

• Az alkalmazás meghívja a requestPermissions-t az ACCESS_FINE_LOCATION számára
• A rendszer meghatározza a csoportot — android.permission-group.LOCATION
• Ellenőrzi, hogy a LOCATION csoport korábban meg lett-e adva
• Ha nem — megjelenít egy párbeszédablakot a csoport nevével és a benne lévő engedélyek listájával
• Az Allow után — az egész LOCATION csoport megadottnak tekintendő
• Az ACCESS_COARSE_LOCATION mostantól elérhető további kérés nélkül

Ez a mechanizmus csak a veszélyes engedélyekre vonatkozik. A normál engedélyeknek nincs csoportjuk, és nem vesznek részt ebben a logikában. A privilegizált és aláírt engedélyek szintén nem csoportosíthatók — külön hozzáférés-kezelő rendszerrel rendelkeznek.

A csoportlogika korlátai

A csoportok nem működnek fordított irányban: egy engedély visszavonása egy csoportból a beállításokon keresztül csak azt vonja vissza, a többire nincs hatással. Továbbá, ha a felhasználó elutasította a párbeszédablakot egy csoport számára, ez nem blokkolja a másik csoportokat — minden új engedély egy másik csoportból megjeleníti a saját párbeszédablakát. Permission Group csak a kérés UX-ére van hatással, nem a biztonsági modellre.

Permission Group-ok listája Androidban

Az Android meghatározza a következő rendszer-Permission Group-okat a veszélyes engedélyek számára. Minden csoport egy vagy több engedélyt foglal magában, amelyeket közös funkcionális cél egyesít.

Változások az új verziókban

Az Android 13-ban (API 33) megjelent egy új csoport NEARBY_DEVICES, amely egyesíti a BLUETOOTH_SCAN, BLUETOOTH_CONNECT és BLUETOOTH_ADVERTISE engedélyeket. A STORAGE csoportot részben felváltották a READ_MEDIA_IMAGES, READ_MEDIA_VIDEO és READ_MEDIA_AUDIO médiaengedélyek, amelyek nem képezik részét a STORAGE-nak, hanem csoportosítás nélküli független veszélyes engedélyek.

Csoportok egyéni engedélyekhez

A fejlesztők saját engedélyeket deklarálhatnak egyéni Permission Group-okkal a permissionGroup attribútumon keresztül a manifesztumban. Ez azonban csak az alkalmazáson belüli egyéni engedélyekre működik, és nem befolyásolja a rendszer UI-párbeszédablakait. A gyakorlatban az egyéni Permission Group-okat ritkán használják — a saját alkalmazások közötti interakcióra egy veremben.

Permission Group és UX

A Permission Group hatása a felhasználói élményre jelentős. A csoportosításnak köszönhetően a felhasználó nem 8 külön párbeszédablakot lát a különböző engedélyekhez, hanem néhány csoportos párbeszédablakot. Ez csökkenti a kognitív terhelést és csökkenti annak valószínűségét, hogy a felhasználó elutasít egy kritikus engedélyt anélkül, hogy megértené a célját.

Az UX-kutatások azt mutatják, hogy a csoportos párbeszédablakokat a felhasználók átláthatóbbnak érzékelik. Amikor az alkalmazás „kamerahozzáférést" kér, a felhasználó érti a kontextust. Ha minden engedélyt külön kérnének — CAMERA, CAMERA2, FLASHLIGHT — ez redundancia érzetét keltené. Permission Group elvonatkoztatja ezt a részletezést.

A legjobb gyakorlat az, hogy egyszerre csak egy csoportból kérjünk engedélyeket. Ha az alkalmazásnak mind kamerára, mind helymeghatározásra szüksége van, ne kérje őket egyetlen requestPermissions hívással. Először kérje az egyik csoportot magyarázat után, majd a másodikat. Ez irányítást és az egyes funkciók fokozatos megértését biztosítja a felhasználó számára.

Permission Group vs ProtectionLevel

Permission Group és ProtectionLevel — ez az Android engedélyrendszerének két különböző dimenziója. A ProtectionLevel meghatározza, hogy az engedély hogyan kerül kiadásra (normal, dangerous, signature, privileged), a Permission Group pedig egy kategória a UI megjelenítéshez. Függetlenek egymástól, de a gyakorlatban a dangerous + permission group kombináció a leggyakoribb.

Az azonos ProtectionLevelű engedélyek különböző csoportokba tartozhatnak. Például az ACCESS_FINE_LOCATION és a CAMERA egyaránt protectionLevel dangerous besorolású, de különböző csoportokba — LOCATION és CAMERA — tartoznak. És fordítva, az azonos nevű engedélyek mindig ugyanabba a csoportba tartoznak: az ACCESS_FINE_LOCATION és az ACCESS_COARSE_LOCATION egyaránt a LOCATION-ban van.

Magasabb szintű védelmi szintek — signature és privileged — nem használnak Permission Group-ot a UI-hoz. Kiadásuk rendszerszinten történik: a signature-t azok az alkalmazások kapják, amelyeket ugyanaz a tanúsítvány írt alá, mint a rendszert, a privileged-t pedig a rendszerképben lévő alkalmazások. Az ilyen engedélyek csoportjai léteznek, de nem befolyásolják az UX-párbeszédablakokat, mert ezek a párbeszédablakok egyszerűen nem léteznek.

Permission Group ellenőrzése kódban

A fejlesztő programozottan meghatározhatja bármely engedély Permission Group-ját a PackageManager segítségével. A getPermissionInfo metódus egy PermissionInfo-t ad vissza a group mezővel, amely tartalmazza a csoport sztringazonosítóját. Ez hasznos naplózáshoz, analitikához és egyéni engedély UI-képernyőkhöz.

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

Használat DI-ben és architektúrában

A Permission Group ismerete segít a kérési architektúra felépítésében. Létrehozható egy PermissionGroupProvider absztrakció, amely egy adott csoporthoz tartozó engedélyek listáját adja vissza. Ez leegyszerűsíti a tesztelést: az egységtesztekben a provider hamis adatokat ad vissza a PackageManager meghívása nélkül. Az instrumentális tesztekben — valódi csoportokat a rendszerből.

PermissionGroupProvider DI-ben

A PermissionGroupProvider integrálása Dagger Hilt vagy Koin segítségével lehetővé teszi az engedélyek és csoportok leképezésének központosított kezelését. A provider-ben a PackageManager.queryPermissionsByGroup eredménye gyorsítótárba helyezhető, hogy elkerüljük az ismétlődő rendszerhívásokat minden kérésnél. Ez különösen fontos a beállítások képernyőn, ahol az összes engedély és azok állapota látható.

Naplózás és analitika

Az elutasításokkal kapcsolatos analitika gyűjtésekor hasznos nemcsak az engedély nevét, hanem a Permission Group-ját is naplózni. Ez segít azonosítani azokat a funkcionális területeket, amelyek a legtöbb elutasítást okozzák. Például a LOCATION csoport hagyományosan a legmagasabb elutasítási aránnyal rendelkezik — körülbelül 40 százalék, a Google Play Console statisztikái szerint.

A csoportonkénti analitika segít termékdöntések meghozatalában: ha a CONTACTS csoport magas elutasítási aránnyal rendelkezik, érdemes lehet újragondolni a kérés időpontját vagy magyarázó párbeszédablakot hozzáadni. A csoportalapú megközelítés az analitikában teljesebb képet ad, mint az egyes engedélyek elemzése, mert a teljes csoportra vonatkozó elutasítások száma tükrözi a felhasználók általános hozzáállását a funkcionális területhez.