In Android 6.0 e versioni successive, il modello di autorizzazioni app di Android è progettato per rendere le autorizzazioni più comprensibili, utili e sicure per gli utenti. Il modello ha spostato le app Android che richiedono autorizzazioni pericolose (vedi Autorizzazioni interessate) da un modello di autorizzazione al momento dell'installazione a un modello di autorizzazione di runtime:
- Autorizzazioni al momento dell'installazione
(Android 5.1 e versioni precedenti) Gli utenti concedono autorizzazioni pericolose a un'app quando la installano o la aggiornano. I produttori di dispositivi e gli operatori possono preinstallare app con autorizzazioni preconcedute senza informare l'utente.
- Autorizzazioni di runtime
(Android 6.0-9) Gli utenti concedono autorizzazioni pericolose a un'app quando è in esecuzione. Il momento in cui vengono richieste le autorizzazioni (ad esempio quando l'app viene avviata o quando l'utente accede a una funzionalità specifica) dipende dall'app, ma l'utente concede/nega all'app l'accesso a gruppi di autorizzazioni specifici. Gli OEM/operatori possono preinstallare le app, ma non possono concedere autorizzazioni predefinite, a meno che non superino la procedura di eccezione. (Vedi Creare eccezioni.)
(Android 10) Gli utenti hanno una maggiore trasparenza e possono controllare le app che dispongono delle autorizzazioni di runtime per il riconoscimento attività (RA). Nella dialoga delle autorizzazioni di runtime viene chiesto agli utenti di consentire sempre, consentire solo durante l'uso o negare le autorizzazioni. Durante l'upgrade del sistema operativo ad Android 10, le autorizzazioni concesse alle app vengono conservate, ma gli utenti possono andare in Impostazioni e modificarle.
Le autorizzazioni di runtime impediscono alle app di accedere ai dati privati senza il consenso dell'utente e forniscono contesto e visibilità aggiuntivi sui tipi di autorizzazioni richieste o concesse alle app. Il modello di runtime incoraggia gli sviluppatori a aiutare gli utenti a capire perché le app richiedono le autorizzazioni richieste e offre maggiore trasparenza, in modo che gli utenti possano prendere decisioni migliori in merito alla concessione o al rifiuto delle autorizzazioni.
Autorizzazioni interessate
Android 6.0 e versioni successive richiedono autorizzazioni pericolose per utilizzare un modello di autorizzazioni di runtime.
Le autorizzazioni pericolose sono autorizzazioni ad alto rischio (ad esempio READ_CALENDAR) che consentono alle app che le richiedono di accedere ai dati privati dell'utente o di controllare un dispositivo, il che può avere un impatto negativo sull'utente. Per visualizzare un elenco di autorizzazioni pericolose, esegui il comando:
adb shell pm list permissions -g -d
Android 6.0 e versioni successive non modificano il comportamento delle autorizzazioni normali. Si tratta di autorizzazioni non pericolose, tra cui quelle normali, di sistema e di firma. Le autorizzazioni normali sono autorizzazioni a rischio più basso (comeSET_WALLPAPER) che consentono alle app che le richiedono di accedere a funzionalità isolate a livello di app con rischi minimi per altre app, il sistema o l'utente. Come nelle release di Android 5.1 e precedenti, il sistema concede automaticamente le autorizzazioni normali a un'app che le richiede al momento dell'installazione e non richiede l'approvazione dell'utente. Per informazioni dettagliate sulle autorizzazioni, consulta la documentazione relativa all'elemento <permission>.
Limitazioni rigide e flessibili in Android 10
Oltre ad essere pericolosa, un'autorizzazione può essere soggetta a limitazioni rigide o a limitazioni flessibili. In entrambi i casi, l'autorizzazione limitata deve essere inserita nella lista consentita. Le limitazioni rigide non consentite si comportano in modo diverso rispetto alle limitazioni non rigide non consentite:
- (Limitazioni rigide) Non è possibile concedere alle app autorizzazioni non incluse nella lista consentita.
- (Restrizioni soft) Le app non incluse nella lista consentita si comportano in base all'autorizzazione specifica che richiedono. Il comportamento è descritto nella documentazione pubblica relativa all'autorizzazione richiesta.
Durante l'installazione di un'app, il programma di installazione (ad esempio il Google Play Store) può selezionare di non inserire nella lista consentita le autorizzazioni con limitazioni per l'app. Le autorizzazioni sono limitate dalla piattaforma e possono essere concesse solo se un'app soddisfa criteri speciali in base alle norme della piattaforma. Esempi di tipi di autorizzazioni con limitazioni rigide includono le autorizzazioni SMS e Registro chiamate.
L'inserimento nella lista consentita avviene durante l'installazione e quando
- un'app è già installata durante un upgrade da Android 9 ad Android 10.
- un'autorizzazione è preassegnata o un'app è preinstallata.
- è necessaria un'autorizzazione per un ruolo già definito per inserire l'autorizzazione nella lista consentita.
- Il programma di installazione (ad esempio Google Play Store) contrassegna l'autorizzazione come inserita nella lista consentita.
Gli utenti non possono inserire manualmente le autorizzazioni nella lista consentita.
Requisiti
Il modello di autorizzazione di runtime si applica a tutte le app, incluse quelle preinstallate e quelle caricate sul dispositivo durante la procedura di configurazione. I requisiti del software per le app includono:
- Il modello di autorizzazione di runtime deve essere coerente su tutti i dispositivi con Android 6.0 e versioni successive. Questo viene applicato dai test della suite di test di compatibilità Android (CTS).
- Le app devono chiedere agli utenti di concedere le autorizzazioni di app in fase di esecuzione. Per maggiori dettagli, vedi Aggiornare
le app. Potrebbero essere concesse eccezioni limitate per app e gestori predefinite
che forniscono funzionalità di base del dispositivo fondamentali per il funzionamento previsto del dispositivo.
Ad esempio, l'app Telefono predefinita del dispositivo per la gestione di
ACTION_CALLpotrebbe avere accesso all'autorizzazione Telefono. Per maggiori dettagli, consulta Creare eccezioni. - Le app precaricate con autorizzazioni pericolose devono avere come target il livello API 23 e mantenere il modello di autorizzazione di runtime. In altre parole, il flusso dell'interfaccia utente durante l'installazione dell'app non deve discostarsi dall'implementazione di AOSP di PermissionController, gli utenti possono revocare le autorizzazioni pericolose delle app preinstallate e così via.
- Le app headless devono utilizzare un'attività per richiedere le autorizzazioni o per condividere un UID con un'altra app che dispone delle autorizzazioni necessarie. Per maggiori dettagli, vedi App headless.
Migrazione delle autorizzazioni
Le autorizzazioni concesse alle app su Android 5.x rimangono concesse dopo l'aggiornamento ad Android 6.0 o versioni successive, ma gli utenti possono revocarle in qualsiasi momento.
In un aggiornamento da Android 9 ad Android 10, tutte le autorizzazioni con limitazioni rigide vengono inserite nella lista consentita. Per informazioni dettagliate sull'implementazione delle autorizzazioni suddivise in primo piano/sfondo, consulta la pagina Modifica alla privacy di Android 10, a partire da Richiedi accesso alla posizione in background.
Integrazione
Quando integri il modello di autorizzazioni di runtime dell'app per Android 6.0 e versioni successive, devi aggiornare le app preinstallate in modo che funzionino con il nuovo modello. Puoi anche definire eccezioni per le app
che sono i gestori/fornitori predefiniti per le funzionalità di base, definire autorizzazioni personalizzate e
personalizzare il tema utilizzato nell'app PermissionController.
Aggiorna le app
Le app nell'immagine di sistema e le app preinstallate non hanno autorizzazioni predefinite. Ti invitiamo a collaborare con gli sviluppatori di app preinstallate (OEM, operatori e terze parti) per apportare le modifiche necessarie alle app utilizzando le linee guida per gli sviluppatori. In particolare, devi assicurarti che le app preinstallate vengano modificate per evitare arresti anomali e altri problemi quando gli utenti revocano le autorizzazioni.
App precaricate
In Android 9 e versioni precedenti, le app precaricate che utilizzano autorizzazioni pericolose devono avere come target il livello API 23 o versioni successive e mantenere il modello di autorizzazione AOSP di Android 6.0 e versioni successive. Ad esempio, il flusso dell'interfaccia utente durante l'installazione di un'app non deve discostarsi dall'implementazione AOSP diPermissionController. Gli utenti possono persino revocare le autorizzazioni pericolose delle app preinstallate.
In Android 6.0 e versioni successive, alcune autorizzazioni vengono concesse durante il flusso di installazione. Tuttavia, a partire da Android 10, il flusso di installazione (eseguito dall'app Package
Installer) è una funzione separata dalla concessione delle autorizzazioni (nell'app Permission Controller).
App headless
Solo le attività possono richiedere autorizzazioni. I servizi non possono richiedere autorizzazioni direttamente.
- In Android 5.1 e versioni precedenti, le app headless possono richiedere autorizzazioni al momento dell'installazione o se sono state preinstallate senza l'utilizzo di un'attività.
- In Android 6.0 e versioni successive, le app headless devono utilizzare uno dei seguenti metodi per richiedere le autorizzazioni:
- Aggiungi un'attività per richiedere le autorizzazioni. Questo è il metodo preferito.
- Condividi un UID con un'altra app che dispone delle autorizzazioni necessarie. Utilizza questo metodo solo se hai bisogno che la piattaforma gestisca più APK come singola app.
L'obiettivo è evitare di confondere gli utenti con richieste di autorizzazione che appaiono fuori contesto.
Personalizzare l'interfaccia utente di PackageInstaller
Se vuoi, puoi personalizzare il tema dell'interfaccia utente delle autorizzazioni aggiornando i temi predefiniti del dispositivo (Theme.DeviceDefault.Settings e Theme.DeviceDefault.Light.Dialog.NoActionBar) utilizzati da PackageInstaller. Tuttavia, poiché la coerenza è fondamentale per gli sviluppatori di app,
non puoi personalizzare il posizionamento, la posizione e le regole relative al momento in cui viene visualizzata l'UI delle autorizzazioni.
Per includere stringhe per altre lingue, contribuisci con le stringhe ad AOSP.
Creare eccezioni
Puoi concedere in anticipo le autorizzazioni alle app che sono gestori o fornitori predefiniti per le funzionalità di base del sistema operativo utilizzando la classe DefaultPermissionGrantPolicy.java in PackageManager. Esempi:
ACTION_CALL (Dialer) Default Phone, Contacts, SMS, Microphone
SMS_DELIVER_ACTION (SMS/MMS) Default Phone, Contacts, SMS
Definire le autorizzazioni personalizzate
Puoi definire autorizzazioni e gruppi personalizzati come normali o pericolose e aggiungere autorizzazioni specifiche per OEM/operatore ai gruppi di autorizzazioni esistenti, come potresti fare in Android 5.x e versioni precedenti.
In Android 6.0 e versioni successive, se aggiungi una nuova autorizzazione pericolosa, deve essere gestita come le altre autorizzazioni pericolose (richieste durante il runtime dell'app e revocabili dagli utenti). Nello specifico:
- Puoi aggiungere nuove autorizzazioni a un gruppo attuale, ma non puoi modificare la mappatura AOSP delle autorizzazioni pericolose e dei gruppi di autorizzazioni pericolose. In altre parole, non puoi rimuovere un'autorizzazione da un gruppo e assegnarla a un altro gruppo.
- Puoi aggiungere nuovi gruppi di autorizzazioni nelle app installate sul dispositivo, ma non nel file manifest della piattaforma.
Test delle autorizzazioni
Android include i test della Compatibility Test Suite (CTS) che verificano che le singole autorizzazioni siano mappate ai gruppi corretti. Superare questi test è un requisito per la compatibilità con CTS di Android 6.0 e versioni successive.
Revocare le autorizzazioni
In Android 13 e versioni successive, puoi revocare le autorizzazioni di runtime concesse utilizzandoContext.revokeSelfPermissionsOnKill().
La revoca avviene in modo asincrono e viene attivata quando è possibile farlo senza interrompere l'utente. Quando viene attivata la revoca, tutti i processi in esecuzione nell'UID chiamante vengono interrotti.
È importante capire che la revoca di una singola autorizzazione potrebbe non essere visualizzata nell'interfaccia utente delle impostazioni, che gestisce le autorizzazioni per gruppo. In genere, un gruppo di autorizzazioni viene visualizzato come concesso se almeno una delle autorizzazioni del gruppo è concessa. Se per te è importante che gli utenti possano confermare la revoca nelle impostazioni, assicurati di revocare ogni autorizzazione nel gruppo di autorizzazioni. Per sapere quali autorizzazioni appartengono a un determinato gruppo, puoi utilizzare PackageManager.getGroupOfPlatformPermission e PackageManager.getPlatformPermissionsForGroup.
Quando il sistema revoca le autorizzazioni richieste, revoca anche le autorizzazioni in background corrispondenti se nessuna delle autorizzazioni in primo piano corrispondenti è ancora concessa.
La revoca non viene attivata finché il processo rimane in primo piano, ma può essere attivata anche immediatamente uccidendo manualmente tutti i processi in esecuzione nell'uid corrente, ad esempio utilizzando System.exit().
Tuttavia, è consigliabile lasciare che sia il sistema a decidere quando attivarla.
Una volta che la revoca dell'autorizzazione è effettiva, puoi richiederla di nuovo e all'utente viene chiesto di concederla o negarla. Non è possibile richiedere un'autorizzazione precedentemente rifiutata dall'utente. Ti invitiamo a revocare le autorizzazioni attualmente in tuo possesso, ma che non sono più necessarie, ma devi fare attenzione a non informare l'utente della revoca finché non è in vigore.