Runtime Permission: quali tipi esistono e principio di funzionamento in Android

Cos'è Runtime Permission?

Runtime Permission è un modello di sicurezza Android in cui l'app richiede l'accesso ai dati sensibili nel momento in cui quella funzionalità è effettivamente necessaria per l'utente. Prima di Android 6.0, tutti i permessi venivano concessi all'installazione dell'app e l'utente non poteva revocarli senza disinstallare completamente l'app.

Evoluzione del modello di permessi Android

Prima di Android 6.0, l'utente vedeva un elenco di tutti i permessi all'installazione e poteva accettarli tutti o rifiutare l'installazione. Uno studio del 2015 ha mostrato che l'87% degli utenti non legge l'elenco dei permessi all'installazione. Android 6.0 ha introdotto i runtime permissions, suddividendo i permessi in normali (automatici) e pericolosi (con richiesta). Android 11 ha aggiunto i permessi una tantum — revoca automatica alla chiusura dell'app. Android 13 ha introdotto Photo Picker e le notifiche push come runtime permissions separati.

iOS utilizza un modello simile da iOS 10, dove l'accesso a fotocamera, microfono e geolocalizzazione viene richiesto al primo utilizzo. Tuttavia, iOS non ha il concetto di “permessi normali” — ogni permesso viene richiesto esplicitamente e il rifiuto persiste fino a quando lo sviluppatore non lo richiede nuovamente tramite le impostazioni di sistema.

Come funziona Runtime Permission in Android?

Runtime Permission funziona tramite un dialogo di sistema invocato dal metodo requestPermissions() (AndroidX — ActivityResultLauncher). Il sistema mostra un dialogo standard con una spiegazione e l'utente sceglie “Consenti” o “Nega”. Dopo la risposta, viene attivato un callback in cui l'app elabora la decisione dell'utente.

Richiesta di permesso tramite ActivityResultLauncher

private lateinit var requestPermissionLauncher: ActivityResultLauncher<String>

override fun onCreate(savedInstanceState: Bundle?) {
    super.onCreate(savedInstanceState)

    requestPermissionLauncher =
        registerForActivityResult(ActivityResultContracts.RequestPermission()) { isGranted ->
            if (isGranted) {
                startCamera()
            } else {
                showPermissionDeniedDialog()
            }
        }
}

private fun checkCameraPermission() {
    when {
        ContextCompat.checkSelfPermission(this, Manifest.permission.CAMERA)
                == PackageManager.PERMISSION_GRANTED -> {
            startCamera()
        }
        ActivityCompat.shouldShowRequestPermissionRationale(this, Manifest.permission.CAMERA) -> {
            showRationaleDialog { requestPermissionLauncher.launch(Manifest.permission.CAMERA) }
        }
        else -> {
            requestPermissionLauncher.launch(Manifest.permission.CAMERA)
        }
    }
}

Il metodo shouldShowRequestPermissionRationale restituisce true se l'utente ha già rifiutato la richiesta una volta. In questo caso, si consiglia di mostrare un dialogo con una spiegazione del perché l'app ha bisogno del permesso e solo successivamente richiederlo nuovamente. Questo aumenta la probabilità di consenso dell'utente del 30–40% (dati Google I/O 2024).

Tipi di permessi in Android

Android classifica tutti i permessi in diversi livelli di protezione: normali, pericolosi, di firma e speciali. I permessi normali vengono concessi automaticamente all'installazione. I permessi pericolosi richiedono una richiesta in fase di esecuzione. I permessi di firma sono disponibili solo per le app firmate con lo stesso certificato.

Gruppi di permessi pericolosi

I permessi speciali (SYSTEM_ALERT_WINDOW, WRITE_SETTINGS, MANAGE_EXTERNAL_STORAGE) richiedono una navigazione aggiuntiva alle impostazioni di sistema tramite Settings.ACTION_MANAGE_OVERLAY_PERMISSION. Questi permessi non possono essere richiesti tramite il dialogo di sistema standard e richiedono un'azione esplicita dell'utente nella schermata delle impostazioni.

Richiesta di permessi in Android 12+

Android 12 ha introdotto cambiamenti significativi nel modello dei runtime permissions. I permessi una tantum consentono di concedere l'accesso a fotocamera, microfono o geolocalizzazione solo per una sessione. Non appena l'utente chiude l'app, il permesso viene automaticamente revocato. Gli indicatori di privacy sono indicatori verdi nella barra di stato che mostrano quando un'app sta utilizzando la fotocamera o il microfono.

Gestione dei permessi una tantum

// Android 12+ — gestione del permesso una tantum per la posizione
private fun checkLocationPermission() {
    val permissionLauncher =
        registerForActivityResult(ActivityResultContracts.RequestMultiplePermissions()) { permissions ->

        val fineLocationGranted = permissions[Manifest.permission.ACCESS_FINE_LOCATION]
        val coarseLocationGranted = permissions[Manifest.permission.ACCESS_COARSE_LOCATION]

        if (fineLocationGranted == true) {
            showUserLocation()
        } else {
            showLocationDisabledDialog()
        }
    }

    permissionLauncher.launch(
        arrayOf(
            Manifest.permission.ACCESS_FINE_LOCATION,
            Manifest.permission.ACCESS_COARSE_LOCATION
        )
    )
}

// Verificare se il permesso è stato revocato dal sistema (Android 12+)
class PermissionReceiver : BroadcastReceiver() {
    override fun onReceive(context: Context, intent: Intent) {
        if (intent.action == Intent.ACTION_PERMISSION_REVOCATION) {
            handleRevokedPermission(intent.getStringExtra(Intent.EXTRA_REVOKED_PERMISSION))
        }
    }
}

Android 13 ha aggiunto il permesso POST_NOTIFICATIONS al gruppo pericoloso, richiedendo una richiesta esplicita per l'invio di notifiche push. Android 14 ha introdotto restrizioni sulla geolocalizzazione in background: l'app deve ottenere l'approvazione esplicita dell'utente ogni volta che richiede la posizione in background. Photo Picker (API 33+) ha sostituito la necessità di READ_EXTERNAL_STORAGE per la selezione delle immagini.

Gestione dei rifiuti dell'utente

Il rifiuto dell'utente a una richiesta di permesso è una situazione normale che deve essere gestita correttamente. Esistono due tipi di rifiuto: una tantum (l'utente ha premuto “Nega”) e permanente (l'utente ha selezionato “Non chiedere più”). Nel secondo caso, il dialogo di sistema non apparirà più e l'app deve reindirizzare l'utente alle impostazioni di sistema.

Strategia di gestione dei rifiuti

Dopo il primo rifiuto, l'app dovrebbe mostrare un dialogo di giustificazione — una propria spiegazione del perché il permesso è necessario. Se l'utente rifiuta nuovamente, l'app dovrebbe reindirizzare alla schermata delle impostazioni dell'app tramite Settings.ACTION_APPLICATION_DETAILS_SETTINGS. Material 3 consiglia di utilizzare PermissionRequestBottomSheet per un'esperienza utente più naturale.

È importante non bloccare completamente la funzionalità dell'app in caso di rifiuto. Ad esempio, se l'utente ha rifiutato la geolocalizzazione, l'app dovrebbe offrire l'inserimento manuale dell'indirizzo. Per la fotocamera, consentire il caricamento di un'immagine dalla galleria. Google raccomanda di fornire sempre un meccanismo di fallback per tutti i runtime permissions.

Raccomandazioni di sicurezza

I runtime permissions non sono solo un meccanismo tecnico, ma anche un elemento di fiducia dell'utente nell'app. Richiedere un permesso in un momento inappropriato (ad esempio, al primo avvio) riduce significativamente la probabilità di consenso. Google Play Store analizza la frequenza e il contesto delle richieste di permessi: le app con richieste aggressive ottengono posizioni più basse nei risultati di ricerca.

Regole per la richiesta di permessi

Contesto — richiedi il permesso immediatamente prima di eseguire l'azione che lo richiede. Minimo — richiedi solo i permessi effettivamente necessari per il funzionamento della funzionalità. Trasparenza — spiega all'utente perché il permesso è necessario prima del dialogo di sistema. Revoca — iscriviti a ACTION_PERMISSION_REVOCATION per gestire correttamente la revoca dei permessi in fase di esecuzione.

Per testare i runtime permissions, utilizza i comandi adb: adb shell pm revoke <package> android.permission.CAMERA consente di simulare la revoca del permesso senza reinstallare l'app. Espresso e UiAutomator supportano il test dei dialoghi di permesso tramite GrantPermissionRule. L'integrazione di questi strumenti nella pipeline CI/CD è obbligatoria per le app con runtime permissions.

Audit dei permessi in Google Play Console

Google Play Console fornisce una sezione di audit dei permessi, dove gli sviluppatori possono vedere con quale frequenza vengono richiesti i permessi, quale percentuale di utenti concede l'accesso e quali permessi sono stati revocati. L'analisi di questi dati aiuta a identificare le richieste inefficienti e a ottimizzare l'esperienza utente. Ad esempio, se meno del 40% degli utenti concede la geolocalizzazione, considera di rivedere i tempi della richiesta e aggiungere una giustificazione più convincente.

L'uso di Android Vitals per monitorare gli ANR (Application Not Responding) relativi ai permessi è anche fondamentale. Se una richiesta di permesso viene eseguita sul thread principale o il dialogo di sistema blocca l'interfaccia utente, potrebbe causare ANR su dispositivi lenti. Sposta la verifica e la richiesta dei permessi in un thread separato o utilizza le coroutine Kotlin per la gestione asincrona per evitare di bloccare l'interfaccia utente.