Dangerous Permission in Android: cosa sono, elenco dei permessi e richiesta runtime

Cosa sono le Dangerous Permission in Android

Dangerous Permission è una categoria di permessi di sistema Android che forniscono accesso ai dati sensibili dell'utente. A differenza dei permessi normali, i permessi pericolosi non vengono concessi automaticamente durante l'installazione — l'applicazione deve richiederli esplicitamente a runtime tramite il meccanismo introdotto in Android 6.0 Marshmallow (API 23).

La necessità di una richiesta esplicita è dovuta alla natura dei dati che questi permessi proteggono: posizione dell'utente, contatti personali, contenuto della fotocamera e del microfono, cronologia chiamate e SMS. Android considera questi dati come sensibili e richiede che l'utente conceda l'accesso consapevolmente. Secondo Android Privacy Sandbox (2024), gli utenti rifiutano in media circa il 30 percento delle richieste runtime.

Una caratteristica fondamentale di Dangerous Permission è la possibilità di revocarlo in qualsiasi momento. L'utente può andare in Impostazioni — Applicazioni — Permessi e disattivare qualsiasi permesso pericoloso. L'applicazione deve essere pronta al fatto che un permesso precedentemente concesso possa essere revocato in qualsiasi momento senza riavvio.

ProtectionLevel dangerous

Il livello di protezione dangerous è definito nelle definizioni dei permessi di sistema a livello di OS. Quando un'applicazione dichiara uses-permission con questo protectionLevel, il sistema contrassegna il permesso come richiedente una richiesta runtime. A differenza di normal, i permessi dangerous sono sempre visualizzati nell'interfaccia di gestione dei permessi del sistema e possono essere revocati.

Permission Group e Dangerous

Tutti i permessi pericolosi sono raggruppati in Permission Groups per categoria funzionale. Ad esempio, CAMERA e CAMERA2 sono nel gruppo CAMERA, ACCESS_FINE_LOCATION e ACCESS_COARSE_LOCATION sono nel gruppo LOCATION. Se un utente ha concesso un permesso da un gruppo, i permessi rimanenti dello stesso gruppo vengono concessi automaticamente senza un dialogo aggiuntivo.

Come funziona la richiesta runtime

La richiesta runtime è un meccanismo in cui l'applicazione chiama un'API di sistema per visualizzare un dialogo di richiesta permesso. L'utente vede una finestra modale con il nome del permesso e i pulsanti Consenti e Nega. Dopo la risposta, il sistema chiama il callback onRequestPermissionsResult con il risultato.

Il ciclo completo include tre passaggi: verifica dello stato tramite checkSelfPermission, chiamata di requestPermissions se il permesso non è concesso e gestione del risultato in onRequestPermissionsResult. La verifica dello stato è obbligatoria perché l'utente potrebbe aver revocato il permesso in qualsiasi momento tramite le impostazioni e chiamare una funzione senza verifica comporterà una SecurityException.

fun checkAndRequestCameraPermission() {
    when {
        ContextCompat.checkSelfPermission(
            this,
            Manifest.permission.CAMERA
        ) == PackageManager.PERMISSION_GRANTED -> {
            openCamera()
        }
        else -> {
            ActivityCompat.requestPermissions(
                this,
                arrayOf(Manifest.permission.CAMERA),
                REQUEST_CAMERA_CODE
            )
        }
    }
}

La gestione del risultato avviene in ActivityResultLauncher o onRequestPermissionsResult. L'approccio moderno raccomandato è l'utilizzo di ActivityResultContracts.RequestPermission, che fornisce un'API più pulita senza codici di richiesta espliciti. Questo contratto restituisce un Boolean — se il permesso è stato concesso o meno.

Buone pratiche di richiesta

Richiedete i permessi pericolosi rigorosamente nel contesto dell'utilizzo della funzionalità, non all'avvio dell'applicazione. Se l'utente ha premuto il pulsante della fotocamera — richiedete CAMERA. Se ha aperto una mappa — richiedete LOCATION. Le richieste contestuali ottengono il doppio delle concessioni rispetto alla richiesta di tutti i permessi al primo avvio. Si raccomanda inoltre di non richiedere più di un permesso alla volta in modo che l'utente capisca quale funzionalità necessita dell'accesso.

Elenco dei permessi pericolosi in Android

Android definisce diversi gruppi di permessi pericolosi, ciascuno contenente una o più costanti. L'elenco più completo è disponibile nella classe Manifest.permission. Di seguito sono riportati i gruppi principali e i permessi utilizzati nello sviluppo.

Nuovi permessi in Android 12+

A partire da Android 12, Google ha inasprito i requisiti per alcuni permessi. Ad esempio, BLUETOOTH_CONNECT e BLUETOOTH_SCAN sono diventati pericolosi e richiedono una richiesta runtime. Il permesso BODY_SENSORS_BACKGROUND è stato aggiunto per l'accesso in background ai sensori. Gli sviluppatori devono aggiornare targetSdkVersion e testare le richieste sulle versioni correnti del sistema operativo.

Permessi per Android 13+

Android 13 (API 33) ha introdotto nuovi permessi per le notifiche (POST_NOTIFICATIONS) e i file multimediali (READ_MEDIA_IMAGES, READ_MEDIA_VIDEO, READ_MEDIA_AUDIO), sostituendo il generale READ_EXTERNAL_STORAGE. Ora l'accesso a foto, video e audio viene richiesto separatamente tramite permessi specializzati senza un unico dialogo.

Dangerous vs Normal Permission

I permessi Dangerous e Normal differiscono fondamentalmente per modalità di concessione, possibilità di revoca e UX. Normal viene concesso automaticamente durante l'installazione, Dangerous richiede un dialogo runtime esplicito. Normal non può essere revocato tramite le impostazioni, Dangerous può essere disattivato in qualsiasi momento. Questa asimmetria crea diversi modelli di sviluppo.

Dal punto di vista del codice, i permessi pericolosi richiedono più lavoro: checkSelfPermission, requestPermissions, gestione del rifiuto. Per quelli normali, basta una riga in AndroidManifest.xml. Tuttavia, Dangerous Permission dà il controllo all'utente, aumentando la fiducia, specialmente per funzionalità sensibili come fotocamera o posizione.

La scelta tra le categorie non spetta allo sviluppatore — è determinata dal sistema. Lo sviluppatore dichiara solo uses-permission e il sistema determina la categoria in base a protectionLevel. Tuttavia, la strategia di richiesta dei permessi pericolosi influisce sull'esperienza utente: dialoghi frequenti o inappropriati abbassano la valutazione dell'applicazione.

Come richiedere i permessi in Kotlin

Il modo moderno per richiedere i permessi in Kotlin è utilizzare ActivityResultContracts.RequestMultiplePermissions o RequestPermission. Questi contratti fanno parte della libreria androidx.activity e forniscono un'API pulita basata su lambda, senza bisogno di sovrascrivere onRequestPermissionsResult.

class CameraActivity : AppCompatActivity() {
    private val requestPermissionLauncher =
        registerForActivityResult(
            ActivityResultContracts.RequestPermission()
        ) { isGranted: Boolean ->
            if (isGranted) {
                openCamera()
            } else {
                showPermissionDeniedMessage()
            }
        }

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

Richiedere più permessi contemporaneamente

Quando un'applicazione necessita di più permessi pericolosi contemporaneamente, utilizzate RequestMultiplePermissions. Il contratto restituisce Map<String, Boolean> dove la chiave è il nome del permesso e il valore è il risultato. Questo è utile al primo avvio quando è necessario richiedere CAMERA e RECORD_AUDIO per la registrazione video.

Gestione del primo rifiuto

Se l'utente rifiuta la richiesta, il metodo shouldShowRequestPermissionRationale restituisce true. Questo segnala di mostrare una spiegazione del perché il permesso è necessario. La buona pratica è mostrare un dialogo personalizzato con una spiegazione e un pulsante Riprova. Se l'utente rifiuta nuovamente la richiesta con la casella Never Ask Again selezionata, shouldShowRequestPermissionRationale restituirà false ed è necessario reindirizzare alle Impostazioni.

Gestione del rifiuto e Never Ask Again

Never Ask Again è un flag che l'utente può impostare quando rifiuta il dialogo runtime per la seconda volta. Dopodiché, il dialogo standard non viene più mostrato per quel permesso. L'unico modo per concedere l'accesso è reindirizzare l'utente alle impostazioni di sistema delle applicazioni.

Lo sviluppatore deve distinguere due scenari di rifiuto: primo, quando shouldShowRequestPermissionRationale restituisce true (l'utente ha rifiutato ma il dialogo può ancora essere mostrato), e secondo, quando il metodo restituisce false (Never Ask Again è attivo o il permesso è bloccato da policy). Nel secondo caso, è opportuno mostrare un pulsante Apri Impostazioni.

fun handlePermissionDenied(permission: String) {
    if (ActivityCompat.shouldShowRequestPermissionRationale(
            this, permission
    )) {
        showRationaleDialog(permission)
    } else {
        showSettingsRedirectDialog(permission)
    }
}

private fun showSettingsRedirectDialog(permission: String) {
    AlertDialog.Builder(this)
        .setTitle("Accesso negato")
        .setMessage(
            "Permesso bloccato. Apri Impostazioni."
        )
        .setPositiveButton("Impostazioni") { _, _ ->
            val intent = Intent(
                Settings.ACTION_APPLICATION_DETAILS_SETTINGS,
                Uri.fromParts(
                    "package", packageName, null
                )
            )
            startActivity(intent)
        }
        .show()
}

È importante non richiedere nuovamente il permesso se shouldShowRequestPermissionRationale ha restituito false. Una chiamata ripetuta a requestPermissions in questo caso non mostrerà alcun dialogo — il risultato arriverà immediatamente con DENIED senza spiegazione. L'utente incontrerà un comportamento poco chiaro, che influisce negativamente sull'esperienza d'uso dell'applicazione.