Chi programma per Android impara a gestire le permission sin dai primi esempi di codice. Non appena ci si trova infatti a dover accedere alla Rete o a scrivere su una scheda SD esterna, se non si conosce questo concetto, vengono rilevate eccezioni di sicurezza che è difficile afferrare completamente.
L’idea di base è questa: un’app Android lavora in un ambiente protetto, una sandbox come si dice spesso nel gergo informatico e quando deve svolgere attività al di fuori di esso deve segnalarlo al sistema.
Per farlo vengono inserite nel file AndroidManifest.xml dei campi <uses-permission> che dichiarano il tipo di attività particolari che l’app deve svolgere.

<manifest xmlns:android="http://schemas.android.com/apk/res/android"
    package="it.devapp.permission" >
    <uses-permission android:name="android.permission.ACCESS_FINE_LOCATION" />
    ...
</manifest>

Una volta che l’utente installerà l’app gli verrà notificato l’elenco delle permission che essa contiene e queste dovranno essere accettate in blocco per proseguire.
Tutto ciò è valido fino ad Android 5.1 incluso, ma con Marshmallow si cambia.

Permission normali e pericolose

Prima di entrare nel vivo del discorso facciamo una precisazione. Android suddivide le permission in due categorie:

• Normali: intese come le permission che non mettono a rischio la privacy dell’utente. Includono la gettonatissima permission INTERNET ma anche tutte quelle che riguardano lo stato della rete, l’accesso a WI-FI e Bluetooth;
• Pericolose: queste invece potrebbero essere più lesive della riservatezza dell’utente e riguardano aspetti come la comunicazione telefonica nel complesso (Contatti, telefonia, SMS), localizzazione, hardware come camera e registrazione audio, sensori e storage esterno.

La distinzione è utile perchè a partire da Android 6 – le API 23 come diciamo noi sviluppatori – per le permission pericolose è necessario che l’utente esprima esplicito assenso. Tale autorizzazione, inoltre, potrà essere revocata in qualsiasi momento accedendo al pannello Impostazioni del dispositivo.

Quest’ultimo aspetto comporterà la necessità di prevedere il blocco delle funzionalità che necessitino di queste permission, senza causare l’arresto dell’applicativo. In pratica, un’app ben progettata dovrà prevedere un funzionamento completo ed uno o più funzionamenti parziali in mancanza della concessione di tutte le autorizzazioni.

Controllare una permission

Per poter lavorare con le nuove permission dovremo innanzitutto saper controllare se una permission è stata accordata all’app. La classe ContextCompat – resa disponibile nella libreria di supporto – prevede il metodo checkSelfPermission che accetta in input un riferimento al Context ed uno che indica la permission da verificare. Restituirà un intero che incontrerà, a seconda che il permesso sia stato accordato o meno,  il valore PERMISSION_GRANTED o PERMISSION_DENIED definiti nella classe PackageManager.

L’uso nel codice

Premessi i concetti fondamentali, possiamo vedere alcune righe di codice in cui cercheremo di gestire le permission nella maniera più attuale possibile. Immaginiamo che un’app per funzionare abbia bisogno di utilizzare la permission di localizzione.

Questa andrà per prima cosa dichiarata nel file AndroidManifest.xml come visto in precedenza e poi se ne dovrà controllare l’attivazione a runtime trattandosi di una permission dangerous.

Per fare ciò apporremo il seguente codice in un metodo eseguito all’attivazione dell’Activity, diciamo in onResume:

if (ContextCompat.checkSelfPermission(this,
                Manifest.permission.ACCESS_FINE_LOCATION)
        != PackageManager.PERMISSION_GRANTED) {

    if (ActivityCompat.shouldShowRequestPermissionRationale(this,
            Manifest.permission.ACCESS_FINE_LOCATION)) {

        /*
          mostriamo una finestra di dialogo che spiega perchè l'app 
          ha bisogno della permission e successivamente ne chiediamo 
          l'accettazione
         */
    } else {

        // viene proposto all'utente di accettare la permission
        ActivityCompat.requestPermissions(this,
                new String[]{Manifest.permission.ACCESS_FINE_LOCATION},
                REQUEST_ID);
    }
}

Tale codice verrà eseguito solo se ci troviamo in Android 6: in tutte le altre versioni la permission verrà considerata concessa.

Con il metodo requestPermissions verrà aperta la finestra di dialogo con cui l’utente accetta o meno le permission. La risposta sarà inoltrata al metodo onRequestPermissionsResult all’interno del quale riconosceremo la richiesta grazie al parametro REQUEST_ID usato:

@Override
public void onRequestPermissionsResult(int requestCode,
        String permissions[], int[] grantResults) {
    switch (requestCode) {
        case REQUEST_ID: {
            if (grantResults.length > 0
                && grantResults[0] == PackageManager.PERMISSION_GRANTED) {
           // permission accettata: possiamo attivare il codice

            } else {

               // permission negata: disattiviamo i servizi che ne hanno bisogno
            }
        }

    }
}

Il codice da usare non è complesso ma è necessario comprendere bene quali sono le permission sottoposte a tale disciplina e dove collocare l’invocazione dei servizi in una tale struttura di blocchi if.

Comunque sia, affronteremo tale nuova norma volentieri visto che rappresenta un passo importante nella difesa della privacy dell’utente.

Alla prossima!