Permission Group in Android — was es ist, Berechtigungsgruppen und Funktionsprinzip

Was ist Permission Group in Android

Permission Group ist ein Systemmechanismus von Android, der mehrere gefährliche Berechtigungen basierend auf ihrem funktionalen Zweck in einer Gruppe zusammenfasst. Jede Gruppe hat eine Zeichenfolgenkennung, zum Beispiel android.permission-group.CAMERA oder android.permission-group.LOCATION. Alle Berechtigungen innerhalb einer Gruppe sind logisch miteinander verbunden und gewähren Zugriff auf zusammenhängende Gerätefunktionen.

Berechtigungsgruppen erschienen in Android 6.0 Marshmallow zusammen mit dem Laufzeitberechtigungsmodell. Ihr Hauptzweck ist die Vereinfachung der Benutzerinteraktion: Anstatt einer Reihe von Dialogen für jede einzelne Berechtigung zeigt das System einen Dialog pro Gruppe. Wenn der Benutzer eine Berechtigung aus einer Gruppe erteilt, gelten die übrigen als automatisch genehmigt. Laut Android UX Research (2015) reduzierte dies die Anzahl der Ablehnungen beim ersten Start um 20 Prozent.

Es ist wichtig zu verstehen, dass Entwickler keine eigenen Permission Groups erstellen können. Gruppen sind auf Betriebssystemebene vordefiniert und in permissions.xml-Dateien auf jedem Gerät beschrieben. Die App deklariert lediglich uses-permission, und das System ordnet die Berechtigung automatisch ihrer Gruppe basierend auf protectionLevel und der Kategorisierung im AOSP zu.

Wie das System die Gruppe bestimmt

Die Zuordnung einer Berechtigung zu einer Gruppe erfolgt über das Attribut permissionGroup in der Systemberechtigungsdefinition. Zum Beispiel ist CAMERA mit permissionGroup="android.permission-group.CAMERA" deklariert, ACCESS_FINE_LOCATION mit permissionGroup="android.permission-group.LOCATION". Diese Zuordnung ist im Android Open Source Project Code fest codiert und auf allen zertifizierten Geräten identisch.

Wie Permission Groups funktionieren

Der Gruppenmechanismus funktioniert nach dem Prinzip „ein Dialog pro Gruppe“. Wenn eine App zum ersten Mal eine gefährliche Berechtigung anfordert, überprüft das System ihre Permission Group. Wenn noch keine Berechtigung aus dieser Gruppe erteilt wurde, wird ein Dialog angezeigt. Nach der Zustimmung markiert das System die gesamte Gruppe als gewährt, und nachfolgende Anfragen für andere Berechtigungen derselben Gruppe werden ohne UI erfüllt.

Der vereinfachte Algorithmus sieht so aus:

• Die App ruft requestPermissions für ACCESS_FINE_LOCATION auf
• Das System bestimmt die Gruppe — android.permission-group.LOCATION
• Prüft, ob die LOCATION-Gruppe bereits gewährt wurde
• Wenn nicht — zeigt einen Dialog mit dem Gruppennamen und der Liste der enthaltenen Berechtigungen an
• Nach Allow — gilt die gesamte LOCATION-Gruppe als gewährt
• ACCESS_COARSE_LOCATION ist nun ohne zusätzliche Anfrage verfügbar

Dieser Mechanismus gilt nur für gefährliche Berechtigungen. Normale Berechtigungen haben keine Gruppen und nehmen an dieser Logik nicht teil. Privilegierte und signierte Berechtigungen werden ebenfalls nicht gruppiert — sie haben ein separates Zugriffskontrollsystem.

Einschränkungen der Gruppenlogik

Gruppen funktionieren nicht „in umgekehrter Richtung“: Das Widerrufen einer Berechtigung aus einer Gruppe über die Einstellungen widerruft nur diese Berechtigung, ohne die anderen zu beeinträchtigen. Wenn ein Benutzer den Dialog für eine Gruppe ablehnt, blockiert dies keine anderen Gruppen — jede neue Berechtigung aus einer anderen Gruppe zeigt ihren eigenen Dialog. Permission Group beeinflusst nur die UX der Anfrage, nicht das Sicherheitsmodell.

Liste der Permission Groups in Android

Android definiert die folgenden System-Permission-Groups für gefährliche Berechtigungen. Jede Gruppe enthält eine oder mehrere Berechtigungen, die durch einen gemeinsamen funktionalen Zweck verbunden sind.

Änderungen in neuen Versionen

Unter Android 13 (API 33) erschien eine neue Gruppe NEARBY_DEVICES, die BLUETOOTH_SCAN, BLUETOOTH_CONNECT und BLUETOOTH_ADVERTISE kombiniert. Außerdem wurde die STORAGE-Gruppe teilweise durch Medienberechtigungen READ_MEDIA_IMAGES, READ_MEDIA_VIDEO und READ_MEDIA_AUDIO ersetzt, die nicht Teil von STORAGE sind, sondern eigenständige gefährliche Berechtigungen ohne Gruppierung.

Benutzerdefinierte Berechtigungsgruppen

Entwickler können eigene Berechtigungen mit benutzerdefinierten Permission Groups über das Attribut permissionGroup im Manifest deklarieren. Dies funktioniert jedoch nur für benutzerdefinierte Berechtigungen derselben App und beeinflusst keine System-UI-Dialoge. In der Praxis werden benutzerdefinierte Permission Groups selten verwendet — für die Interaktion zwischen Apps im selben Stack.

Permission Group und UX

Die Auswirkung von Permission Group auf die Benutzererfahrung ist erheblich. Dank der Gruppierung sieht der Benutzer nicht 8 separate Dialoge für verschiedene Berechtigungen, sondern einige Gruppendialoge. Dies reduziert die kognitive Belastung und verringert die Wahrscheinlichkeit, dass ein Benutzer eine kritisch wichtige Berechtigung ablehnt, ohne ihren Zweck zu verstehen.

UX-Forschung zeigt, dass Gruppendialoge von Benutzern als transparenter wahrgenommen werden. Wenn eine App „Berechtigung für den Kamerazugriff“ anfordert, versteht der Benutzer den Kontext. Wenn jede Berechtigung einzeln angefordert würde — CAMERA, CAMERA2, FLASHLIGHT — würde dies einen Eindruck von Redundanz erzeugen. Permission Group abstrahiert diese Detailtiefe.

Die beste Praxis ist, Berechtigungen immer nur aus einer Gruppe gleichzeitig anzufordern. Wenn eine App sowohl Kamera als auch Standort benötigt, fordern Sie sie nicht in einem einzigen requestPermissions-Aufruf an. Fordern Sie zuerst eine Gruppe an, nachdem Sie erklärt haben, warum sie benötigt wird, dann die zweite. Dies gibt dem Benutzer Kontrolle und ein sequenzielles Verständnis jeder Funktion.

Permission Group vs ProtectionLevel

Permission Group und ProtectionLevel sind zwei verschiedene Dimensionen des Android-Berechtigungssystems. ProtectionLevel bestimmt, wie eine Berechtigung gewährt wird (normal, dangerous, signature, privileged), während Permission Group eine Kategorie für die UI-Anzeige ist. Sie sind unabhängig, aber in der Praxis ist die Kombination dangerous + permission group am häufigsten.

Berechtigungen desselben ProtectionLevels können zu verschiedenen Gruppen gehören. Zum Beispiel haben ACCESS_FINE_LOCATION und CAMERA beide protectionLevel dangerous, gehören aber zu verschiedenen Gruppen — LOCATION und CAMERA. Umgekehrt gehören gleichnamige Berechtigungen immer zur selben Gruppe: ACCESS_FINE_LOCATION und ACCESS_COARSE_LOCATION sind beide in LOCATION.

Höhere Schutzstufen — signature und privileged — verwenden keine Permission Groups für die UI. Ihre Gewährung wird auf Systemebene gesteuert: signature wird Apps gewährt, die mit demselben Zertifikat wie das System signiert sind, und privileged Apps im Systemabbild. Gruppen für solche Berechtigungen existieren, beeinflussen aber keine UX-Dialoge, da diese Dialoge einfach nicht erscheinen.

Permission Group im Code prüfen

Entwickler können die Permission Group jeder Berechtigung programmatisch über PackageManager ermitteln. Die Methode getPermissionInfo gibt PermissionInfo mit einem group-Feld zurück, das die Zeichenfolgenkennung der Gruppe enthält. Dies ist nützlich für Protokollierung, Analyse und benutzerdefinierte Berechtigungs-UI-Bildschirme.

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

Verwendung in DI und Architektur

Kenntnis der Permission Groups hilft beim Aufbau der Anfragearchitektur. Sie können eine Abstraktion namens PermissionGroupProvider erstellen, die die Liste der Berechtigungen für eine bestimmte Gruppe zurückgibt. Dies vereinfacht das Testen: In Unit-Tests gibt der Anbieter Scheindaten zurück, ohne PackageManager aufzurufen. In Instrumentierungstests gibt er reale Gruppen aus dem System zurück.

PermissionGroupProvider in DI

Die Integration von PermissionGroupProvider über Dagger Hilt oder Koin ermöglicht eine zentrale Verwaltung der Berechtigungs-zu-Gruppe-Zuordnung. Im Anbieter können Sie das Ergebnis von PackageManager.queryPermissionsByGroup zwischenspeichern, um wiederholte Systemaufrufe bei jeder Anfrage zu vermeiden. Dies ist besonders wichtig für Einstellungsbildschirme, auf denen die vollständige Liste der Berechtigungen und ihr Status angezeigt werden.

Protokollierung und Analyse

Beim Sammeln von Analysen über Ablehnungen ist es nützlich, nicht nur den Berechtigungsnamen, sondern auch seine Permission Group zu protokollieren. Dies hilft zu identifizieren, welche Funktionsbereiche die meisten Ablehnungen verursachen. Zum Beispiel hat die LOCATION-Gruppe traditionell die höchste Ablehnungsrate — etwa 40 Prozent, laut Google Play Console-Statistiken.

Analysen nach Gruppen helfen bei Produktentscheidungen: Wenn die CONTACTS-Gruppe eine hohe Ablehnungsrate hat, sollten Sie möglicherweise den Zeitpunkt der Anfrage überdenken oder einen Begründungsdialog hinzufügen. Der gruppenbasierte Ansatz für Analysen liefert ein vollständigeres Bild als die Analyse einzelner Berechtigungen, da die Anzahl der Ablehnungen in einer gesamten Gruppe die allgemeine Einstellung der Benutzer zu einem Funktionsbereich widerspiegelt.