Prima della versione M, il modello di permessi Android è stato una decisione "tutto o niente" per gli utenti al momento dell'installazione. Ciò significava che se un utente desiderava utilizzare un'app, prima doveva accettare tutte le autorizzazioni incluse nell'applicazione o scegliere di non installarlo affatto. Ciò ha portato molti sviluppatori a perdere le installazioni delle app, una disconnessione di fiducia tra utenti e sviluppatori e altri problemi di privacy.
Con il nuovo modello di autorizzazioni, gli utenti saranno in grado di approvare le autorizzazioni in fase di esecuzione in quanto sono necessarie e possono negare tali autorizzazioni in qualsiasi momento. In questo articolo, imparerai come questo cambiamento nella gestione delle autorizzazioni ti influenzerà come sviluppatore e in che modo i tuoi utenti sperimenteranno le tue applicazioni.
Va notato che questo articolo è stato scritto prima del rilascio ufficiale di Android M, quindi alcune informazioni potrebbero cambiare con la versione ufficiale.
Mentre Android M richiede ancora le autorizzazioni per essere dichiarato in AndroidManifest.xml, gli utenti dovranno ora approvare o negare l'utilizzo di tale autorizzazione in fase di runtime. Un cambiamento importante nella nuova versione di Android è questo android.permission.INTERNET
e android.permission.WRITE_EXTERNAL_STORAGE
sono stati declassati da un rating di pericoloso a normale. Ciò significa che non è necessario chiedere all'utente prima dell'uso.
Quando si richiede l'approvazione dell'autorizzazione, all'utente verrà richiesto in base al gruppo del permesso, invece di chiedere di approvare ogni singola autorizzazione all'interno di un gruppo. Ciò significa che se l'applicazione deve inviare e ricevere messaggi SMS, all'utente verrà richiesto solo di approvare il gruppo di autorizzazioni SMS. Di seguito è riportato un elenco dei gruppi di autorizzazioni attualmente supportati in Android M Developer Preview 2, come mostrato dalle impostazioni di sistema.
Va anche notato che Android presenta un robusto Intento
sistema, che consente agli sviluppatori di richiedere dati da altre applicazioni. Anziché richiedere l'autorizzazione della fotocamera e sviluppare un'applicazione che utilizzi le API della fotocamera da zero, puoi richiedere all'utente di scattare una foto utilizzando un'applicazione per fotocamere già affidabile per ottenere un'immagine nella tua app. Le autorizzazioni relative alla videocamera verranno gestite dall'app della fotocamera.
Quando è necessario utilizzare una funzione che richiede un'autorizzazione, si verificherà un flusso generale di eventi. Devi prima vedere se tale autorizzazione è già stata approvata dal tuo utente.
Se l'utente non ha approvato l'autorizzazione, è possibile presentarli con una finestra di dialogo di richiesta di autorizzazione. La prima volta che lo presenti all'utente, dovrà negare o approvare l'autorizzazione.
Tuttavia, se in precedenza hanno negato l'autorizzazione e sono stati nuovamente invitati, avranno la possibilità di annullare la richiesta di tale autorizzazione ancora una volta.
È possibile verificare se è stata precedentemente concessa un'autorizzazione chiamando checkSelfPermission
prima di utilizzare una funzione che richiederà tale autorizzazione. Questo metodo restituisce un int
valore basato sul fatto che il permesso è concesso o meno.
Se è uguale a PackageManager.PERMISSION_GRANTED
, allora puoi continuare come previsto. Tuttavia, se tale autorizzazione non è stata concessa in precedenza, è possibile richiederla con requestPermissions
, passando una serie di stringhe di autorizzazione e un'abitudine int
codice di richiesta per tenere traccia del flusso logico della tua app.
int hasLocationPermission = checkSelfPermission (Manifest.permission.ACCESS_FINE_LOCATION); int hasSMSPermission = checkSelfPermission (Manifest.permission.SEND_SMS); Elencoautorizzazioni = nuovo ArrayList (); if (hasLocationPermission! = PackageManager.PERMISSION_GRANTED) permissions.add (Manifest.permission.ACCESS_FINE_LOCATION); if (hasSMSPermission! = PackageManager.PERMISSION_GRANTED) permissions.add (Manifest.permission.SEND_SMS); if (! permissions.isEmpty ()) requestPermissions (permissions.toArray (new String [permissions.size ()]), REQUEST_CODE_SOME_FEATURES_PERMISSIONS);
Una volta requestPermissions
viene chiamato, all'utente viene presentata una finestra di dialogo di richiesta per ciascun gruppo di autorizzazioni per il quale l'applicazione richiede l'autorizzazione. È consigliabile richiedere solo le autorizzazioni necessarie, piuttosto che in blocco quando l'utente avvia la tua applicazione per la prima volta.
Quando il tuo utente ha finito con le finestre di dialogo, onRequestPermissionsResult
si chiama e si può accedere al tuo Attività
. Qui è dove si avvia la funzione o si gestisce la situazione in cui l'utente ha negato una o più autorizzazioni.
Di seguito viene mostrato un esempio di come verificare se un'autorizzazione è stata concessa o negata. Se l'utente ha negato qualsiasi autorizzazione richiesta per la tua funzione, dovresti disabilitare questa funzione e far sapere all'utente perché non funziona nella tua applicazione.
@Override public void onRequestPermissionsResult (int requestCode, String [] permissions, int [] grantResults) switch (requestCode) case REQUEST_CODE_SOME_FEATURES_PERMISSIONS: for (int i = 0; i < permissions.length; i++ ) if( grantResults[i] == PackageManager.PERMISSION_GRANTED ) Log.d( "Permissions", "Permission Granted: " + permissions[i] ); else if( grantResults[i] == PackageManager.PERMISSION_DENIED ) Log.d( "Permissions", "Permission Denied: " + permissions[i] ); break; default: super.onRequestPermissionsResult(requestCode, permissions, grantResults);
Mentre le app che sono state create con targeting per Android M sono necessarie per implementare i nuovi dialoghi e metodi di autorizzazione, le app create per le versioni precedenti di Android continueranno a presentare agli utenti un elenco di autorizzazioni al momento dell'installazione. Sebbene le autorizzazioni siano accettate prima che gli utenti possano utilizzare la tua app, possono comunque essere revocate in qualsiasi momento.
Poiché l'infrastruttura per la gestione delle autorizzazioni revocate non sarà disponibile in applicazioni con targeting inferiore a Android M, verranno restituite tutte le funzionalità che avrebbero richiesto le autorizzazioni nullo
, 0
, o un valore vuoto quando le autorizzazioni non sono concesse. Ciò può portare a comportamenti imprevisti nelle app, quindi è consigliabile che gli sviluppatori si preparino ad aggiornare le loro app per supportare il nuovo modello di autorizzazione di Android M il prima possibile.
In questo articolo, hai imparato a conoscere il nuovo modello di autorizzazione di Android M e come supportare le autorizzazioni aggiornate nelle tue applicazioni. Abbiamo anche spiegato come le app risponderanno alla nuova versione di Android quando sono state costruite per le versioni precedenti. Utilizzando queste informazioni, dovresti essere in grado di preparare le tue applicazioni per il rilascio ufficiale del prossimo aggiornamento ad Android.