AndroidManifest Permissions: concetti chiave, dichiarazione e tipi di permessi

Cosa sono AndroidManifest Permissions?

AndroidManifest Permissions è il meccanismo di sicurezza di Android che controlla l’accesso delle applicazioni a dati protetti e funzioni di sistema. Ogni applicazione deve dichiarare i permessi necessari nel file AndroidManifest.xml utilizzando l’elemento . Senza dichiarazione, la chiamata all’API corrispondente genererà un errore di sicurezza SecurityException.

Il modello di permessi di Android ha attraversato diverse fasi evolutive. Prima di Android 6.0 (API 23), tutti i permessi venivano concessi all’installazione — l’utente vedeva l’elenco completo e accettava o rifiutava l’installazione dell’applicazione. A partire da Android 6.0, i permessi di livello dangerous vengono richiesti in fase di esecuzione (Runtime Permissions), dando all’utente un controllo più flessibile.

I permessi sono suddivisi in quattro livelli di protezione: normal (concessi automaticamente all’installazione), dangerous (richiedono richiesta in fase di esecuzione), signature (disponibili solo per applicazioni firmate con lo stesso certificato) e special (richiedono attivazione separata nelle impostazioni). Ogni livello ha il proprio meccanismo di concessione e revoca.

Secondo Google I/O 2024, Android 15 prevede di introdurre permessi più granulari — l’utente potrà concedere l’accesso solo a file specifici nella libreria multimediale, non all’intera raccolta. Ciò prosegue la tendenza di Android a minimizzare la quantità di dati forniti per impostazione predefinita.

Differenza dal modello di permessi iOS

A differenza di iOS, dove tutti i permessi vengono richiesti in fase di esecuzione, Android divide i permessi in tipi di installazione (install-time) ed esecuzione (runtime). Il livello normal viene concesso automaticamente all’installazione senza notifica all’utente. Il livello dangerous richiede un dialogo esplicito, come in iOS.

Un’altra differenza: in Android, i permessi sono raggruppati in gruppi di permessi. Se l’utente acconsente all’accesso alla fotocamera, l’applicazione ottiene automaticamente l’accesso al microfono — si trovano nello stesso gruppo MICROPHONE. In iOS, ogni permesso viene richiesto indipendentemente dai gruppi.

Evoluzione dei permessi per versioni Android

Quali tipi di permessi esistono

Android definisce quattro livelli di protezione per i permessi, ciascuno con le proprie regole di concessione. Esaminiamo ogni livello in dettaglio.

Permessi Normal (install-time)

I permessi normal vengono concessi automaticamente all’installazione dell’applicazione senza notifica o richiesta all’utente. Coprono funzioni a basso rischio che non minacciano la privacy dell’utente: INTERNET, ACCESS_NETWORK_STATE, VIBRATE, BLUETOOTH. L’utente non vede alcun dialogo di consenso — il permesso si considera concesso al momento dell’installazione.

Lo sviluppatore non deve gestire richieste nel codice per i permessi normal — è sufficiente dichiararli nel manifesto. Tuttavia, su Android 12+, durante l’installazione da Google Play, l’utente vede una scheda “Permessi” che elenca tutti i permessi normal, aumentando la trasparenza. Secondo Statista (2024), oltre il 90% delle applicazioni su Google Play utilizza INTERNET come permesso normal più comune.

Permessi Dangerous (runtime)

I permessi dangerous coprono l’accesso a dati e funzioni che possono compromettere la privacy: fotocamera, microfono, geolocalizzazione, contatti, SMS, telefono, calendario, sensori corporei. Questi permessi richiedono un meccanismo in due fasi: dichiarazione nel manifesto + richiesta in fase di esecuzione tramite ActivityCompat.requestPermissions().

L’utente può negare un permesso dangerous, e l’applicazione deve gestire correttamente questo scenario. Su Android 11+, se l’utente nega due volte, le richieste successive non mostrano il dialogo di sistema — il sistema restituisce automaticamente DENIED. In questo caso, l’applicazione deve indirizzare l’utente alle impostazioni.

Permessi Signature e Special

Il livello signature — il permesso viene concesso automaticamente se l’applicazione è firmata con lo stesso certificato del sistema o di un’altra applicazione che ha definito il permesso. Utilizzato per applicazioni di sistema e aziendali. Esempio: BIND_ACCESSIBILITY_SERVICE — disponibile solo per applicazioni di sistema.

Il livello special (SYSTEM_ALERT_WINDOW, WRITE_SETTINGS, REQUEST_INSTALL_PACKAGES, MANAGE_EXTERNAL_STORAGE) — richiede un’azione esplicita dell’utente tramite le impostazioni di sistema. L’applicazione può aprire la pagina delle impostazioni con Intent(Settings.ACTION_MANAGE_OVERLAY_PERMISSION). Google Play limita l’uso dei permessi special e richiede una giustificazione nel modulo di pubblicazione.

Runtime Permission: lavorare con i permessi dangerous

Da Android 6.0, tutti i permessi dangerous richiedono una richiesta in fase di esecuzione. Esaminiamo il ciclo completo di lavoro con i runtime permissions in Kotlin.

Verifica e richiesta del permesso

Prima di chiamare un’API che richiede un permesso dangerous, verifica sempre lo stato corrente tramite ContextCompat.checkSelfPermission(). Se lo stato è PERMISSION_GRANTED, puoi chiamare l’API. Se è PERMISSION_DENIED, devi richiedere il permesso tramite ActivityResultContract RequestPermission (AndroidX) o il deprecato requestPermissions().

Si raccomanda di utilizzare ActivityResultContracts.RequestMultiplePermissions per richiedere più permessi contemporaneamente. Google raccomanda di raggruppare permessi correlati (ad esempio, fotocamera + microfono per la registrazione video) in un unico dialogo, in modo che l’utente veda il contesto completo della richiesta.

import android.Manifest
import android.content.pm.PackageManager
import androidx.activity.result.contract.ActivityResultContracts
import androidx.core.content.ContextCompat

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

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

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

Gestione del rifiuto “Non chiedere più”

Se l’utente rifiuta due volte, Android porta la richiesta allo stato “Never ask again”. In questo caso, shouldShowRequestPermissionRationale() restituisce false e il dialogo di sistema non verrà mostrato. L’applicazione deve indirizzare l’utente alle impostazioni di sistema tramite Intent(Settings.ACTION_APPLICATION_DETAILS_SETTINGS).

Importante: non mostrare un dialogo che offre di aprire le impostazioni subito dopo il primo rifiuto — viene percepito come comportamento aggressivo. Usa shouldShowRequestPermissionRationale() per determinare se è necessario mostrare una spiegazione. Le Linee guida Material Design raccomandano di mostrare una schermata che spiega il valore dell’accesso, non solo un pulsante “Apri impostazioni”.

private fun openAppSettings() {
    Intent(
        Settings.ACTION_APPLICATION_DETAILS_SETTINGS,
        Uri.fromParts("package", packageName, null)
    ).also { intent ->
        startActivity(intent)
    }
}

private fun showPermissionSettings() {
    AlertDialog.Builder(this)
        .setTitle("Accesso alla fotocamera")
        .setMessage("Consenti l’accesso alla fotocamera nelle Impostazioni, "
            + "per scattare foto del profilo")
        .setPositiveButton("Apri impostazioni") { _, _ ->
            openAppSettings()
        }
        .setNegativeButton("Annulla", null)
        .show()
}

Dichiarazione dei permessi in AndroidManifest.xml

Il file AndroidManifest.xml contiene l’elemento per ogni permesso utilizzato dall’applicazione. I permessi vengono dichiarati a livello di prima dell’elemento .

Sintassi di dichiarazione

Ogni permesso viene dichiarato con un elemento separato utilizzando l’attributo android:name che specifica il nome completo del permesso. Per i permessi introdotti in versioni specifiche di Android, usa l’attributo maxSdkVersion per limitare la dichiarazione solo alle versioni necessarie — questo migliora la compatibilità.

Ad esempio, il permesso WRITE_EXTERNAL_STORAGE non è necessario su Android 10+ (Scoped Storage), quindi specifica maxSdkVersion="28" (Android 9). Ciò previene domande inutili da parte degli utenti sulle versioni più recenti. Android Studio avvisa sui maxSdkVersion raccomandati tramite Lint.

<!-- AndroidManifest.xml -->
<?xml version="1.0" encoding="utf-8"?>
<manifest xmlns:android="http://schemas.android.com/apk/res/android">

    <!-- Normal permissions (install-time) -->
    <uses-permission
        android:name="android.permission.INTERNET" />
    <uses-permission
        android:name="android.permission.ACCESS_NETWORK_STATE" />

    <!-- Dangerous permissions (runtime) -->
    <uses-permission
        android:name="android.permission.CAMERA" />
    <uses-permission
        android:name="android.permission.ACCESS_FINE_LOCATION" />

    <!-- Legacy storage permission limited to API 28 and below -->
    <uses-permission
        android:name="android.permission.WRITE_EXTERNAL_STORAGE"
        android:maxSdkVersion="28" />

    <uses-feature
        android:name="android.hardware.camera"
        android:required="false" />

    <application>
        <!-- ... -->
    </application>
</manifest>

Utilizzo di per il filtraggio

L’elemento indica che l’applicazione richiede hardware specifico (fotocamera, GPS, NFC). L’attributo android:required="false" consente di installare l’applicazione su dispositivi senza quell’hardware — la disponibilità viene verificata nel codice. Se required="true", Google Play filtra l’applicazione, rendendola non disponibile per dispositivi non adatti.

Si raccomanda di impostare required="false" per tutte le funzionalità hardware e verificare la disponibilità a livello di codice tramite PackageManager.hasSystemFeature(). Ciò amplia il pubblico della tua applicazione. L’unica eccezione è se la funzionalità è critica per il funzionamento dell’applicazione (un’app di taxi senza GPS non ha senso).

Buone pratiche ed errori

La corretta gestione dei permessi è un aspetto fondamentale della qualità di un’applicazione Android. Esaminiamo le principali raccomandazioni e gli errori tipici.

Minimizzare i permessi richiesti

Richiedi solo i permessi realmente necessari per il funzionamento dell’applicazione. Ogni permesso extra riduce il tasso di conversione delle installazioni e aumenta il numero di rifiuti. La Google Play Console mostra quanti utenti hanno rifiutato l’installazione a causa dell’insieme di permessi. Secondo AppBrain (2024), le applicazioni con 10+ permessi dangerous hanno il 35% in meno di installazioni.

Rivedi regolarmente il tuo elenco di permessi. Rimuovi quelli non utilizzati, specialmente quando migri a versioni più recenti di Android dove alcuni permessi diventano opzionali. Ad esempio, con il selettore foto (ActivityResultContracts.PickVisualMedia) su Android 13+, l’accesso alla libreria multimediale può essere ottenuto senza il permesso dangerous READ_MEDIA_IMAGES.

Mostrare una spiegazione prima della richiesta

Prima di richiedere un permesso dangerous, mostra all’utente una schermata che spiega perché questo permesso è necessario e quale valore offre. Material Design raccomanda di utilizzare un foglio inferiore o un dialogo con un’icona, testo breve e un pulsante “Continua”. La spiegazione aumenta il consenso del 20–30% rispetto a una richiesta diretta.

Verifica shouldShowRequestPermissionRationale() prima di chiamare launch(). Se true, mostra la spiegazione. Se false, il permesso è già stato concesso o l’utente lo ha negato permanentemente (never ask again). In quest’ultimo caso, mostra un pulsante “Apri impostazioni” invece di ripetere la richiesta.

Testare tutti gli scenari di permessi

Testa tutti gli scenari possibili: concessione del permesso, rifiuto, rifiuto permanente, revoca del permesso nelle impostazioni, reimpostazione dei permessi (Android 11+ auto-reset). Ogni scenario deve essere gestito senza crash o perdita di dati. La Guida ai test Android raccomanda di utilizzare la libreria TestPermission per automatizzare i test.

Presta particolare attenzione allo scenario in cui l’utente revoca un permesso mentre l’applicazione è in esecuzione (app minimizzata → Impostazioni → revoca). Al ritorno nell’applicazione, verifica tutti i permessi in onResume(). Non affidarti alla memorizzazione nella cache dello stato dei permessi — l’utente può modificarli in qualsiasi momento.

Errori tipici

• Richiedere un permesso senza prima verificare checkSelfPermission — attiva un dialogo inutile
• Ignorare shouldShowRequestPermissionRationale — peggiora l’esperienza utente dopo il primo rifiuto
• Richiedere un permesso senza contesto (solo “Consentire l’accesso?”) — riduce il consenso
• Usare WRITE_EXTERNAL_STORAGE su Android 10+ senza maxSdkVersion — richiesta inutile
• Mancata verifica dei permessi in onResume — perdere la revoca dei permessi nelle impostazioni