Permission Group in Android — wat is het, machtigingsgroepen en werkingsprincipe

Wat is Permission Group in Android

Permission Group — is een systeemmechanisme van Android dat meerdere gevaarlijke machtigingen in één groep combineert op basis van hun functionele doel. Elke groep heeft een string-identificatie, bijvoorbeeld android.permission-group.CAMERA of android.permission-group.LOCATION. Alle machtigingen binnen één groep zijn logisch verbonden en bieden toegang tot verwante functies van het apparaat.

Machtigingsgroepen verschenen in Android 6.0 Marshmallow samen met het runtime-verzoekmodel. Hun hoofddoel is het vereenvoudigen van de interactie met de gebruiker: in plaats van een reeks dialoogvensters voor elke afzonderlijke machtiging toont het systeem één dialoog per groep. Als de gebruiker één machtiging uit een groep heeft verleend, worden de overige als automatisch goedgekeurd beschouwd. Volgens Android UX Research (2015) verminderde dit het aantal weigeringen bij de eerste start met 20 procent.

Het is belangrijk om te begrijpen dat de ontwikkelaar geen eigen Permission Groups kan maken. Groepen zijn vooraf gedefinieerd op het niveau van het besturingssysteem en beschreven in permissions.xml-bestanden op elk apparaat. De app specificeert alleen uses-permission, en het systeem koppelt de machtiging automatisch aan de groep op basis van protectionLevel en categorisatie in AOSP.

Hoe het systeem de groep bepaalt

De koppeling van een machtiging aan een groep gebeurt via het attribuut permissionGroup in de systeemdefinitie van de machtiging. Bijvoorbeeld, CAMERA is gedeclareerd met permissionGroup="android.permission-group.CAMERA", ACCESS_FINE_LOCATION — met permissionGroup="android.permission-group.LOCATION". Deze mapping is vast ingesteld in de code van Android Open Source Project en is hetzelfde op alle gecertificeerde apparaten.

Hoe werken Permission Groups

Het groepsmechanisme werkt volgens het principe „één dialoog per groep”. Wanneer een app voor het eerst een gevaarlijke machtiging aanvraagt, controleert het systeem de Permission Group. Als nog geen machtiging uit deze groep is verleend — wordt een dialoogvenster getoond. Na toestemming markeert het systeem de hele groep als verleend, en volgende aanvragen van andere machtigingen uit dezelfde groep worden zonder gebruikersinterface ingewilligd.

Het algoritme ziet er vereenvoudigd als volgt uit:

• De app roept requestPermissions aan voor ACCESS_FINE_LOCATION
• Het systeem bepaalt de groep — android.permission-group.LOCATION
• Het controleert of de groep LOCATION eerder is verleend
• Zo niet — toont een dialoog met de groepsnaam en lijst van inbegrepen machtigingen
• Na Allow — wordt de hele groep LOCATION als verleend beschouwd
• ACCESS_COARSE_LOCATION is nu beschikbaar zonder extra aanvraag

Dit mechanisme is alleen van toepassing op gevaarlijke machtigingen. Normale machtigingen hebben geen groepen en nemen niet deel aan deze logica. Geprivilegieerde en ondertekende machtigingen worden ook niet gegroepeerd — ze hebben een apart toegangsbeheersysteem.

Beperkingen van de groepslogica

Groepen werken niet in omgekeerde richting: het intrekken van één machtiging uit een groep via de instellingen trekt alleen die ene in, zonder de andere te beïnvloeden. Ook als de gebruiker het dialoogvenster voor een groep heeft afgewezen, blokkeert dit andere groepen niet — elke nieuwe machtiging uit een andere groep toont zijn eigen dialoog. Permission Group beïnvloedt alleen de UX van de aanvraag, niet het beveiligingsmodel.

Lijst van Permission Groups in Android

Android definieert de volgende systeem-Permission Groups voor gevaarlijke machtigingen. Elke groep omvat één of meer machtigingen verenigd door een gemeenschappelijk functioneel doel.

Wijzigingen in nieuwe versies

Op Android 13 (API 33) is een nieuwe groep NEARBY_DEVICES verschenen, die BLUETOOTH_SCAN, BLUETOOTH_CONNECT en BLUETOOTH_ADVERTISE combineert. Ook is de groep STORAGE gedeeltelijk vervangen door de mediamachtigingen READ_MEDIA_IMAGES, READ_MEDIA_VIDEO en READ_MEDIA_AUDIO, die geen deel uitmaken van STORAGE, maar onafhankelijke gevaarlijke machtigingen zonder groepering zijn.

Groepen voor aangepaste machtigingen

Ontwikkelaars kunnen eigen machtigingen met aangepaste Permission Groups declareren via het attribuut permissionGroup in het manifest. Dit werkt echter alleen voor aangepaste machtigingen van dezelfde app en beïnvloedt de systeem-UI-dialogen niet. In de praktijk worden aangepaste Permission Groups zelden gebruikt — voor interactie tussen eigen apps in één stack.

Permission Group en UX

De invloed van Permission Group op de gebruikerservaring is aanzienlijk. Dankzij groepering ziet de gebruiker niet 8 aparte dialoogvensters voor verschillende machtigingen, maar een aantal groepsdialogen. Dit vermindert de cognitieve belasting en verlaagt de kans dat de gebruiker een kritieke machtiging afwijst zonder het doel ervan te begrijpen.

UX-onderzoek toont aan dat groepsdialogen door gebruikers als transparanter worden ervaren. Wanneer een app „toegang tot de camera” aanvraagt, begrijpt de gebruiker de context. Als elke machtiging afzonderlijk zou worden aangevraagd — CAMERA, CAMERA2, FLASHLIGHT — zou dit een indruk van overbodigheid creëren. Permission Group abstraheert deze detaillering.

De beste praktijk is om machtigingen slechts uit één groep tegelijk aan te vragen. Als de app zowel camera als geolocatie nodig heeft, vraag ze dan niet aan met één requestPermissions-aanroep. Vraag eerst de ene groep na uitleg, daarna de tweede. Dit geeft de gebruiker controle en een stapsgewijs begrip van elke functie.

Permission Group vs ProtectionLevel

Permission Group en ProtectionLevel — dit zijn twee verschillende dimensies van het Android-machtigingensysteem. ProtectionLevel bepaalt hoe de machtiging wordt verleend (normal, dangerous, signature, privileged), en Permission Group is een categorie voor UI-weergave. Ze zijn onafhankelijk, maar in de praktijk komt de combinatie dangerous + permission group het vaakst voor.

Machtigingen van hetzelfde ProtectionLevel kunnen tot verschillende groepen behoren. Bijvoorbeeld, ACCESS_FINE_LOCATION en CAMERA hebben beide protectionLevel dangerous, maar behoren tot verschillende groepen — LOCATION en CAMERA. En omgekeerd, machtigingen met dezelfde naam behoren altijd tot dezelfde groep: ACCESS_FINE_LOCATION en ACCESS_COARSE_LOCATION zitten beide in LOCATION.

Hogere beschermingsniveaus — signature en privileged — gebruiken geen Permission Group voor UI. Hun toekenning wordt op systeemniveau gecontroleerd: signature wordt verleend aan apps die met hetzelfde certificaat als het systeem zijn ondertekend, en privileged aan apps in het systeemimage. Groepen voor dergelijke machtigingen bestaan wel, maar beïnvloeden de UX-dialogen niet, omdat deze dialogen simpelweg niet bestaan.

Permission Group controleren in code

De ontwikkelaar kan programmatisch de Permission Group van elke machtiging bepalen via PackageManager. De methode getPermissionInfo retourneert PermissionInfo met het veld group dat de string-identificatie van de groep bevat. Dit is nuttig voor logging, analytics en aangepaste UI-schermen voor machtigingen.

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

Gebruik in DI en architectuur

Kennis van Permission Group helpt bij het bouwen van een aanvraagarchitectuur. Men kan een abstractie PermissionGroupProvider maken die de lijst van machtigingen voor een specifieke groep retourneert. Dit vereenvoudigt testen: in unittesten retourneert de provider fictieve gegevens zonder PackageManager aan te roepen. In instrumentele testen — echte groepen uit het systeem.

PermissionGroupProvider in DI

Integratie van PermissionGroupProvider via Dagger Hilt of Koin maakt gecentraliseerd beheer van de mapping van machtigingen en groepen mogelijk. In de provider kan het resultaat van PackageManager.queryPermissionsByGroup worden gecached om herhaalde systeemaanroepen bij elke aanvraag te voorkomen. Dit is vooral belangrijk voor instellingen-schermen waar de volledige lijst van machtigingen en hun status wordt weergegeven.

Logging en analytics

Bij het verzamelen van analytics over weigeringen is het nuttig om niet alleen de naam van de machtiging te loggen, maar ook de Permission Group ervan. Dit helpt bij het identificeren van functionele gebieden die de meeste weigeringen veroorzaken. Bijvoorbeeld, de groep LOCATION heeft traditioneel het hoogste percentage weigeringen — ongeveer 40 procent, volgens Google Play Console-statistieken.

Analytics per groep helpt bij het nemen van productbeslissingen: als de groep CONTACTS een hoog weigeringspercentage heeft, is het wellicht de moeite waard om het moment van aanvragen te heroverwegen of een toelichtingsdialoog toe te voegen. Een groepsgewijze benadering van analytics geeft een vollediger beeld dan analyse van afzonderlijke machtigingen, omdat het aantal weigeringen voor de hele groep de algemene houding van gebruikers ten opzichte van het functionele gebied weerspiegelt.