Permission Group in Android — cosa sono, gruppi di permessi e principio di funzionamento

Cosa sono i Permission Group in Android

Permission Group è un meccanismo di sistema Android che raggruppa più permessi pericolosi in un gruppo in base al loro scopo funzionale. Ogni gruppo ha un identificatore di stringa, ad esempio android.permission-group.CAMERA o android.permission-group.LOCATION. Tutti i permessi all'interno di un gruppo sono logicamente correlati e forniscono accesso a funzioni correlate del dispositivo.

I gruppi di permessi sono apparsi in Android 6.0 Marshmallow insieme al modello di permessi runtime. Il loro scopo principale è semplificare l'interazione con l'utente: invece di una serie di finestre di dialogo per ogni permesso individuale, il sistema mostra una finestra di dialogo per gruppo. Se l'utente concede un permesso da un gruppo, gli altri sono considerati automaticamente approvati. Secondo Android UX Research (2015), ciò ha ridotto il numero di rifiuti al primo avvio del 20 per cento.

È importante capire che lo sviluppatore non può creare i propri Permission Group. I gruppi sono predefiniti a livello di sistema operativo e descritti nei file permissions.xml su ogni dispositivo. L'app dichiara solo uses-permission, e il sistema associa automaticamente il permesso al suo gruppo in base a protectionLevel e alla categorizzazione in AOSP.

Come il sistema determina il gruppo

L'associazione di un permesso a un gruppo avviene tramite l'attributo permissionGroup nella definizione del permesso di sistema. Ad esempio, CAMERA è dichiarato con permissionGroup="android.permission-group.CAMERA", ACCESS_FINE_LOCATION con permissionGroup="android.permission-group.LOCATION". Questo mapping è codificato nel codice Android Open Source Project ed è identico su tutti i dispositivi certificati.

Come funzionano i Permission Group

Il meccanismo dei gruppi funziona secondo il principio di “una finestra di dialogo per gruppo”. Quando un'app richiede per la prima volta un permesso pericoloso, il sistema verifica il suo Permission Group. Se nessun permesso di questo gruppo è stato ancora concesso — viene mostrata una finestra di dialogo. Dopo il consenso, il sistema contrassegna l'intero gruppo come concesso, e le richieste successive di altri permessi dello stesso gruppo vengono soddisfatte senza interfaccia utente.

L'algoritmo semplificato è il seguente:

• L'app chiama requestPermissions per ACCESS_FINE_LOCATION
• Il sistema determina il gruppo — android.permission-group.LOCATION
• Verifica se il gruppo LOCATION è stato concesso in precedenza
• Se no — mostra una finestra di dialogo con il nome del gruppo e l'elenco dei permessi inclusi
• Dopo Allow — l'intero gruppo LOCATION è considerato concesso
• ACCESS_COARSE_LOCATION è ora disponibile senza richiesta aggiuntiva

Questo meccanismo si applica solo ai permessi pericolosi. I permessi normali non hanno gruppi e non partecipano a questa logica. Anche i permessi privilegiati e firmati non vengono raggruppati — hanno un sistema di controllo degli accessi separato.

Limitazioni della logica di gruppo

I gruppi non funzionano “al contrario”: revocare un permesso da un gruppo tramite le impostazioni revoca solo quel permesso senza influenzare gli altri. Inoltre, se un utente rifiuta la finestra di dialogo per un gruppo, ciò non blocca altri gruppi — ogni nuovo permesso da un gruppo diverso mostrerà la propria finestra di dialogo. Permission Group influisce solo sull'UX della richiesta, non sul modello di sicurezza.

Elenco dei Permission Group in Android

Android definisce i seguenti Permission Group di sistema per i permessi pericolosi. Ogni gruppo include uno o più permessi uniti da uno scopo funzionale comune.

Modifiche nelle nuove versioni

Su Android 13 (API 33), è apparso un nuovo gruppo NEARBY_DEVICES che combina BLUETOOTH_SCAN, BLUETOOTH_CONNECT e BLUETOOTH_ADVERTISE. Inoltre, il gruppo STORAGE è stato parzialmente sostituito dai permessi multimediali READ_MEDIA_IMAGES, READ_MEDIA_VIDEO e READ_MEDIA_AUDIO, che non fanno parte di STORAGE ma sono permessi pericolosi indipendenti senza raggruppamento.

Gruppi di permessi personalizzati

Gli sviluppatori possono dichiarare i propri permessi con Permission Group personalizzati tramite l'attributo permissionGroup nel manifest. Tuttavia, questo funziona solo per i permessi personalizzati della stessa app e non influisce sulle finestre di dialogo dell'interfaccia di sistema. Nella pratica, i Permission Group personalizzati sono usati raramente — per l'interazione tra app nello stesso stack.

Permission Group e UX

L'impatto di Permission Group sull'esperienza utente è significativo. Grazie al raggruppamento, l'utente non vede 8 finestre di dialogo separate per diversi permessi, ma alcune finestre di dialogo di gruppo. Ciò riduce il carico cognitivo e diminuisce la probabilità che l'utente rifiuti un permesso criticamente importante senza comprenderne lo scopo.

La ricerca UX mostra che le finestre di dialogo di gruppo sono percepite dagli utenti come più trasparenti. Quando un'app richiede “permesso di accedere alla fotocamera”, l'utente comprende il contesto. Se ogni permesso fosse richiesto separatamente — CAMERA, CAMERA2, FLASHLIGHT — creerebbe un'impressione di ridondanza. Permission Group astrae questa granularità.

La miglior pratica è richiedere i permessi solo da un gruppo alla volta. Se un'app necessita sia della fotocamera che della posizione, non richiederli in un'unica chiamata requestPermissions. Prima richiedi un gruppo dopo aver spiegato perché è necessario, poi il secondo. Questo dà all'utente controllo e una comprensione sequenziale di ogni funzionalità.

Permission Group vs ProtectionLevel

Permission Group e ProtectionLevel sono due dimensioni diverse del sistema di permessi Android. ProtectionLevel determina come un permesso viene concesso (normal, dangerous, signature, privileged), mentre Permission Group è una categoria per la visualizzazione nell'interfaccia utente. Sono indipendenti, ma nella pratica la combinazione dangerous + permission group è la più comune.

Permessi dello stesso ProtectionLevel possono appartenere a gruppi diversi. Ad esempio, ACCESS_FINE_LOCATION e CAMERA hanno entrambi protectionLevel dangerous ma appartengono a gruppi diversi — LOCATION e CAMERA. E viceversa, permessi con lo stesso nome appartengono sempre allo stesso gruppo: ACCESS_FINE_LOCATION e ACCESS_COARSE_LOCATION sono entrambi in LOCATION.

Livelli di protezione superiori — signature e privileged — non usano Permission Group per l'interfaccia utente. La loro concessione è controllata a livello di sistema: signature è concesso alle app firmate con lo stesso certificato del sistema, e privileged alle app nell'immagine di sistema. I gruppi per tali permessi esistono ma non influenzano le finestre di dialogo UX perché queste finestre semplicemente non appaiono.

Verificare Permission Group nel codice

Lo sviluppatore può determinare programmaticamente il Permission Group di qualsiasi permesso tramite PackageManager. Il metodo getPermissionInfo restituisce PermissionInfo con un campo group contenente l'identificatore di stringa del gruppo. Questo è utile per logging, analisi e schermate di permessi dell'interfaccia personalizzate.

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

Utilizzo in DI e architettura

La conoscenza dei Permission Group aiuta a costruire l'architettura delle richieste. Puoi creare un'astrazione chiamata PermissionGroupProvider che restituisce l'elenco dei permessi per un gruppo specifico. Questo semplifica il testing: nei test unitari, il fornitore restituisce dati fittizi senza chiamare PackageManager. Nei test strumentali, restituisce gruppi reali dal sistema.

PermissionGroupProvider in DI

L'integrazione di PermissionGroupProvider tramite Dagger Hilt o Koin consente una gestione centralizzata del mapping permesso-gruppo. Nel fornitore, puoi memorizzare nella cache il risultato di PackageManager.queryPermissionsByGroup per evitare chiamate di sistema ripetute a ogni richiesta. Questo è particolarmente importante per le schermate delle impostazioni dove viene visualizzato l'elenco completo dei permessi e il loro stato.

Logging e analisi

Durante la raccolta di analisi sui rifiuti, è utile registrare non solo il nome del permesso ma anche il suo Permission Group. Questo aiuta a identificare quali aree funzionali causano il maggior numero di rifiuti. Ad esempio, il gruppo LOCATION ha tradizionalmente il tasso di rifiuto più alto — circa il 40 per cento, secondo le statistiche di Google Play Console.

L'analisi per gruppi aiuta a prendere decisioni di prodotto: se il gruppo CONTACTS ha un alto tasso di rifiuto, potrebbe essere necessario riconsiderare il momento della richiesta o aggiungere una finestra di dialogo di spiegazione. L'approccio basato sui gruppi per l'analisi fornisce un quadro più completo rispetto all'analisi dei singoli permessi, poiché il numero di rifiuti in un intero gruppo riflette l'atteggiamento generale degli utenti verso un'area funzionale.