Permission Group dans Android — ce que c'est, groupes d'autorisations et principe de fonctionnement

Qu'est-ce que Permission Group dans Android

Permission Group est un mécanisme système Android qui regroupe plusieurs autorisations dangereuses en un groupe selon leur objectif fonctionnel. Chaque groupe a un identifiant de chaîne, par exemple android.permission-group.CAMERA ou android.permission-group.LOCATION. Toutes les autorisations d'un même groupe sont logiquement liées et fournissent un accès à des fonctions connexes de l'appareil.

Les groupes d'autorisations sont apparus dans Android 6.0 Marshmallow avec le modèle d'autorisations d'exécution. Leur objectif principal est de simplifier l'interaction avec l'utilisateur : au lieu d'une série de dialogues pour chaque autorisation individuelle, le système affiche un dialogue par groupe. Si l'utilisateur accorde une autorisation d'un groupe, les autres sont considérées comme automatiquement approuvées. Selon Android UX Research (2015), cela a réduit le nombre de refus au premier lancement de 20 pour cent.

Il est important de comprendre que le développeur ne peut pas créer ses propres Permission Groups. Les groupes sont prédéfinis au niveau du système d'exploitation et décrits dans les fichiers permissions.xml sur chaque appareil. L'application déclare uniquement uses-permission, et le système associe automatiquement l'autorisation à son groupe en fonction du protectionLevel et de la catégorisation dans AOSP.

Comment le système détermine le groupe

L'association d'une autorisation à un groupe se fait via l'attribut permissionGroup dans la définition de l'autorisation système. Par exemple, CAMERA est déclaré avec permissionGroup="android.permission-group.CAMERA", ACCESS_FINE_LOCATION avec permissionGroup="android.permission-group.LOCATION". Ce mappage est codé en dur dans le code d'Android Open Source Project et est identique sur tous les appareils certifiés.

Comment fonctionnent les Permission Group

Le mécanisme des groupes fonctionne sur le principe d'« un dialogue par groupe ». Lorsqu'une application demande pour la première fois une autorisation dangereuse, le système vérifie son Permission Group. Si aucune autorisation de ce groupe n'a encore été accordée — un dialogue s'affiche. Après consentement, le système marque l'ensemble du groupe comme accordé, et les demandes ultérieures d'autres autorisations du même groupe sont satisfaites sans interface utilisateur.

L'algorithme simplifié ressemble à ceci :

• L'application appelle requestPermissions pour ACCESS_FINE_LOCATION
• Le système détermine le groupe — android.permission-group.LOCATION
• Vérifie si le groupe LOCATION a déjà été accordé
• Si non — affiche un dialogue avec le nom du groupe et la liste des autorisations incluses
• Après Allow — tout le groupe LOCATION est considéré comme accordé
• ACCESS_COARSE_LOCATION est désormais disponible sans demande supplémentaire

Ce mécanisme s'applique uniquement aux autorisations dangereuses. Les autorisations normales n'ont pas de groupes et ne participent pas à cette logique. Les autorisations privilégiées et signées ne sont pas non plus regroupées — elles ont un système de contrôle d'accès séparé.

Limitations de la logique de groupe

Les groupes ne fonctionnent pas « en sens inverse » : révoquer une autorisation d'un groupe via les paramètres révoque uniquement cette autorisation sans affecter les autres. De plus, si un utilisateur refuse le dialogue d'un groupe, cela ne bloque pas les autres groupes — chaque nouvelle autorisation d'un groupe différent affichera son propre dialogue. Permission Group affecte uniquement l'UX de la demande, pas le modèle de sécurité.

Liste des Permission Group dans Android

Android définit les Permission Group système suivants pour les autorisations dangereuses. Chaque groupe inclut une ou plusieurs autorisations unies par un objectif fonctionnel commun.

Changements dans les nouvelles versions

Sur Android 13 (API 33), un nouveau groupe NEARBY_DEVICES est apparu, combinant BLUETOOTH_SCAN, BLUETOOTH_CONNECT et BLUETOOTH_ADVERTISE. De plus, le groupe STORAGE a été partiellement remplacé par les autorisations média READ_MEDIA_IMAGES, READ_MEDIA_VIDEO et READ_MEDIA_AUDIO, qui ne font pas partie de STORAGE mais sont des autorisations dangereuses indépendantes sans regroupement.

Groupes d'autorisations personnalisés

Les développeurs peuvent déclarer leurs propres autorisations avec des Permission Groups personnalisés via l'attribut permissionGroup dans le manifeste. Cependant, cela fonctionne uniquement pour les autorisations personnalisées de la même application et n'affecte pas les dialogues d'interface système. Dans la pratique, les Permission Groups personnalisés sont rarement utilisés — pour l'interaction entre applications dans la même pile.

Permission Group et UX

L'impact de Permission Group sur l'expérience utilisateur est significatif. Grâce au regroupement, l'utilisateur ne voit pas 8 dialogues séparés pour différentes autorisations, mais quelques dialogues de groupe. Cela réduit la charge cognitive et diminue la probabilité que l'utilisateur refuse une autorisation critique sans comprendre son objectif.

Les recherches UX montrent que les dialogues de groupe sont perçus par les utilisateurs comme plus transparents. Lorsqu'une application demande « l'autorisation d'accéder à la caméra », l'utilisateur comprend le contexte. Si chaque autorisation était demandée séparément — CAMERA, CAMERA2, FLASHLIGHT — cela créerait une impression de redondance. Permission Group abstrait cette granularité.

La meilleure pratique est de demander les autorisations d'un seul groupe à la fois. Si une application a besoin à la fois de la caméra et de la géolocalisation, ne les demandez pas dans un seul appel requestPermissions. Demandez d'abord un groupe après avoir expliqué pourquoi il est nécessaire, puis le second. Cela donne à l'utilisateur le contrôle et une compréhension séquentielle de chaque fonctionnalité.

Permission Group vs ProtectionLevel

Permission Group et ProtectionLevel sont deux dimensions différentes du système d'autorisations Android. ProtectionLevel détermine comment une autorisation est accordée (normal, dangerous, signature, privileged), tandis que Permission Group est une catégorie pour l'affichage dans l'interface utilisateur. Ils sont indépendants, mais dans la pratique, la combinaison dangerous + permission group est la plus courante.

Les autorisations du même ProtectionLevel peuvent appartenir à différents groupes. Par exemple, ACCESS_FINE_LOCATION et CAMERA ont tous deux protectionLevel dangerous mais appartiennent à des groupes différents — LOCATION et CAMERA. Et inversement, les autorisations de même nom appartiennent toujours au même groupe : ACCESS_FINE_LOCATION et ACCESS_COARSE_LOCATION sont toutes deux dans LOCATION.

Les niveaux de protection supérieurs — signature et privileged — n'utilisent pas les Permission Groups pour l'interface utilisateur. Leur octroi est contrôlé au niveau système : signature est accordée aux applications signées avec le même certificat que le système, et privileged aux applications dans l'image système. Les groupes pour ces autorisations existent mais n'affectent pas les dialogues UX car ces dialogues n'apparaissent tout simplement pas.

Vérifier Permission Group dans le code

Le développeur peut déterminer par programmation le Permission Group de toute autorisation via PackageManager. La méthode getPermissionInfo retourne PermissionInfo avec un champ group contenant l'identifiant de chaîne du groupe. C'est utile pour la journalisation, l'analyse et les écrans d'autorisations d'interface personnalisés.

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

Utilisation dans DI et architecture

La connaissance des Permission Groups aide à construire l'architecture des demandes. Vous pouvez créer une abstraction appelée PermissionGroupProvider qui retourne la liste des autorisations pour un groupe spécifique. Cela simplifie les tests : dans les tests unitaires, le fournisseur retourne des données simulées sans appeler PackageManager. Dans les tests d'instrumentation, il retourne des groupes réels du système.

PermissionGroupProvider dans DI

L'intégration de PermissionGroupProvider via Dagger Hilt ou Koin permet une gestion centralisée du mappage autorisation-groupe. Dans le fournisseur, vous pouvez mettre en cache le résultat de PackageManager.queryPermissionsByGroup pour éviter des appels système répétés à chaque demande. C'est particulièrement important pour les écrans de paramètres où la liste complète des autorisations et leur statut sont affichés.

Journalisation et analyse

Lors de la collecte d'analyses sur les refus, il est utile de journaliser non seulement le nom de l'autorisation mais aussi son Permission Group. Cela permet d'identifier quels domaines fonctionnels causent le plus grand nombre de refus. Par exemple, le groupe LOCATION a traditionnellement le taux de refus le plus élevé — environ 40 pour cent, selon les statistiques de Google Play Console.

L'analyse par groupes aide à prendre des décisions produit : si le groupe CONTACTS a un taux de refus élevé, il peut être nécessaire de reconsidérer le moment de la demande ou d'ajouter un dialogue de justification. L'approche basée sur les groupes pour l'analyse fournit une image plus complète que l'analyse des autorisations individuelles, car le nombre de refus dans un groupe entier reflète l'attitude globale des utilisateurs envers un domaine fonctionnel.