In Android 6.0 e versioni successive, il modello di autorizzazioni delle applicazioni Android è progettato per rendere le autorizzazioni più comprensibili, utili e sicure per gli utenti. Il modello ha spostato le applicazioni Android che richiedono autorizzazioni pericolose (vedi Autorizzazioni interessate ) da un modello di autorizzazione in fase di installazione a un modello di autorizzazione di runtime :
- Autorizzazioni per il tempo di installazione
( Android 5.1 e versioni precedenti ) Gli utenti concedono autorizzazioni pericolose a un'app quando installano o aggiornano l'app. I produttori e gli operatori di dispositivi possono preinstallare app con autorizzazioni preassegnate senza avvisare l'utente.
- Autorizzazioni di runtime
( Android 6.0 – 9 ) Gli utenti concedono autorizzazioni pericolose a un'app quando l'app è in esecuzione. Quando vengono richieste autorizzazioni (ad esempio quando l'app viene avviata o quando l'utente accede a una funzione specifica) dipende dall'applicazione, ma l'utente concede/nega l'accesso all'applicazione a gruppi di autorizzazioni specifici. Gli OEM/i gestori possono preinstallare le app, ma non possono preassegnare le autorizzazioni a meno che non passino attraverso il processo di eccezione. (Vedi Creazione di eccezioni .)
( Android 10 ) Gli utenti vedono una maggiore trasparenza e hanno il controllo su quali app hanno autorizzazioni di runtime di riconoscimento attività (AR). La finestra di dialogo delle autorizzazioni di runtime richiede agli utenti di consentire sempre, consentire durante l'uso o negare le autorizzazioni. In un aggiornamento del sistema operativo ad Android 10, le autorizzazioni concesse alle app vengono mantenute, ma gli utenti possono accedere alle Impostazioni e modificarle.
Le autorizzazioni di runtime impediscono alle app di accedere ai dati privati senza il consenso dell'utente e forniscono loro contesto e visibilità aggiuntivi sui tipi di autorizzazioni che le applicazioni stanno cercando o sono state concesse. Il modello di runtime incoraggia gli sviluppatori ad aiutare gli utenti a capire perché le applicazioni richiedono le autorizzazioni richieste e fornisce una maggiore trasparenza in modo che gli utenti possano prendere decisioni migliori in merito alla loro concessione o negazione.
Autorizzazioni interessate
Android 6.0 e versioni successive richiedono autorizzazioni pericolose per utilizzare un modello di autorizzazioni di runtime. Le autorizzazioni pericolose sono autorizzazioni a rischio più elevato (come READ_CALENDAR ) che concedono alle applicazioni richiedenti l'accesso ai dati degli utenti privati o il controllo su un dispositivo, che possono avere un impatto negativo sull'utente. Per visualizzare un elenco di autorizzazioni pericolose, eseguire il comando:
adb shell pm list permissions -g -d
Android 6.0 e versioni successive non modificano il comportamento delle normali autorizzazioni . Queste sono tutte autorizzazioni non pericolose, comprese le autorizzazioni normali, di sistema e di firma. Le autorizzazioni normali sono autorizzazioni a basso rischio (come SET_WALLPAPER ) che concedono alle applicazioni richiedenti l'accesso a funzionalità isolate a livello di applicazione con un rischio minimo per altre applicazioni, il sistema o l'utente. Come in Android 5.1 e versioni precedenti, il sistema concede automaticamente le normali autorizzazioni a un'applicazione richiedente al momento dell'installazione e non richiede l'approvazione all'utente. Per i dettagli sulle autorizzazioni, vedere la documentazione dell'elemento <permission> .
Restrizioni hard e soft in Android 10
Oltre ad essere pericoloso, un permesso può essere limitato o limitato. In entrambi i casi, anche l'autorizzazione limitata deve essere inclusa nella lista consentita. Le restrizioni rigide non consentite si comportano in modo diverso rispetto alle restrizioni soft non consentite:
- ( Restrizioni rigide ) Non è possibile concedere autorizzazioni alle app che non sono consentite.
- ( Restrizioni soft ) Le app senza lista consentita si comportano in base all'autorizzazione specifica richiesta. Il comportamento è descritto nella documentazione pubblica per l'autorizzazione richiesta.
Durante l'installazione di un'app, il programma di installazione (come Google Play Store) può scegliere di non inserire nella lista consentita le autorizzazioni limitate per l'app. Le autorizzazioni sono limitate dalla piattaforma e sono concesse solo se un'app soddisfa criteri speciali per i criteri della piattaforma. Esempi di tipi di autorizzazione con restrizioni obbligatorie includono le autorizzazioni SMS e Registro chiamate.
La lista consentita avviene durante l'installazione e quando
- un'app è già installata durante un aggiornamento da Android 9 a 10.
- un'autorizzazione è preconcessa o un'app è preinstallata.
- è richiesta un'autorizzazione per un ruolo già definito per autorizzare l'autorizzazione.
- il programma di installazione (come Google Play Store) contrassegna l'autorizzazione come consentita.
Gli utenti non possono autorizzare manualmente le autorizzazioni.
Requisiti
Il modello di autorizzazione di runtime si applica a tutte le applicazioni, comprese le app preinstallate e le app consegnate al dispositivo come parte del processo di configurazione. I requisiti del software applicativo includono:
- Il modello di autorizzazione di runtime deve essere coerente su tutti i dispositivi con Android 6.0 e versioni successive. Ciò è imposto dai test di Android Compatibility Test Suite (CTS).
- Le app devono richiedere agli utenti di concedere le autorizzazioni dell'applicazione in fase di esecuzione. Per i dettagli, vedere Aggiornamento delle applicazioni . Eccezioni limitate possono essere concesse ad applicazioni e gestori predefiniti che forniscono funzionalità di base del dispositivo fondamentali per il funzionamento previsto del dispositivo. (Ad esempio, l'app Dialer predefinita del dispositivo per la gestione di
ACTION_CALLpotrebbe avere l'accesso all'autorizzazione Telefono.) Per i dettagli, vedere Creazione di eccezioni . - Le app precaricate con autorizzazioni pericolose devono avere come destinazione il livello API 23 e mantenere il modello di autorizzazione di runtime. Ovvero, il flusso dell'interfaccia utente durante l'installazione dell'app non deve deviare dall'implementazione AOSP di PermissionController, gli utenti possono revocare autorizzazioni pericolose delle app preinstallate e così via.
- Le applicazioni headless devono utilizzare un'attività per richiedere autorizzazioni o per condividere un UID con un'altra applicazione che dispone delle autorizzazioni necessarie. Per i dettagli, vedere Applicazioni senza testa .
Migrazione delle autorizzazioni
Le autorizzazioni concesse alle applicazioni 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 Android da 9 a 10, tutte le autorizzazioni con limitazioni restrittive vengono incluse nella lista consentita. Per i dettagli sull'implementazione delle autorizzazioni di suddivisione in primo piano/sfondo, consulta Modifica della privacy di Android 10 , a partire da Richiedi posizione in background .
Integrazione
Quando si integra il modello di autorizzazioni di runtime dell'applicazione per Android 6.0 e versioni successive, è necessario aggiornare le applicazioni preinstallate per funzionare con il nuovo modello. Puoi anche definire eccezioni per le app che sono gestori/fornitori predefiniti per le funzionalità principali, definire autorizzazioni personalizzate e personalizzare il tema usato nell'app PermissionController .
Aggiornamento delle applicazioni
Le applicazioni nell'immagine di sistema e le applicazioni preinstallate non sono autorizzazioni preassegnate automaticamente. Ti invitiamo a collaborare con gli sviluppatori di app preinstallate (OEM, operatore e terze parti) per apportare le modifiche necessarie alle app utilizzando le linee guida per gli sviluppatori . In particolare, è necessario assicurarsi che le applicazioni preinstallate vengano modificate per evitare arresti anomali e altri problemi quando gli utenti revocano le autorizzazioni.
Applicazioni precaricate
In Android 9 e versioni precedenti, le app precaricate che utilizzano autorizzazioni pericolose devono avere come target il livello API 23 o successivo 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 di PermissionController . Gli utenti possono persino revocare le autorizzazioni pericolose delle app preinstallate.
In Android da 6.0 a 9, alcune autorizzazioni vengono concesse durante il flusso di installazione. Tuttavia, a partire da 10, il flusso di installazione (eseguito dall'app Package Installer ) è una funzione separata dalla concessione delle autorizzazioni (nell'app Permission Controller ).
Applicazioni senza testa
Solo le attività possono richiedere autorizzazioni. I servizi non possono richiedere autorizzazioni direttamente.
- In Android 5.1 e versioni precedenti, le applicazioni headless possono richiedere autorizzazioni una volta installate o se erano preinstallate senza l'uso di un'attività.
- In Android 6.0 e versioni successive, le applicazioni 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 applicazione che dispone delle autorizzazioni necessarie. Utilizzare questo metodo solo quando è necessario che la piattaforma gestisca più APK come un'unica applicazione.
L'obiettivo è evitare di confondere gli utenti con richieste di autorizzazione che appaiono fuori contesto.
Personalizzazione dell'interfaccia utente di PackageInstaller
Se lo si desidera, è possibile personalizzare il tema dell'interfaccia utente delle autorizzazioni aggiornando i temi del dispositivo predefiniti ( Theme.DeviceDefault.Settings e Theme.DeviceDefault.Light.Dialog.NoActionBar ) utilizzati da PackageInstaller. Tuttavia, poiché la coerenza è fondamentale per gli sviluppatori di app, non è possibile personalizzare il posizionamento, la posizione e le regole di quando viene visualizzata l'interfaccia utente delle autorizzazioni.
Per includere stringhe per lingue aggiuntive, inserisci le stringhe in AOSP.
Creazione di eccezioni
È possibile concedere in anticipo le autorizzazioni alle applicazioni che sono gestori o provider predefiniti per le funzionalità principali 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
Definizione delle autorizzazioni personalizzate
Puoi definire autorizzazioni e gruppi personalizzati come normali o pericolosi e aggiungere autorizzazioni specifiche per OEM/corriere a gruppi di autorizzazioni esistenti, proprio come in Android 5.x e nelle versioni precedenti.
In Android 6.0 e versioni successive, se aggiungi una nuova autorizzazione pericolosa, questa deve essere gestita allo stesso modo delle altre autorizzazioni pericolose (richieste durante il runtime dell'app e revocabili dagli utenti). Nello specifico:
- È possibile aggiungere nuove autorizzazioni a un gruppo corrente, ma non è possibile modificare la mappatura AOSP di autorizzazioni pericolose e 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 applicazioni installate nel dispositivo, ma non puoi aggiungere nuovi gruppi di autorizzazioni nel manifesto della piattaforma.
Autorizzazioni di prova
Android include test di Compatibility Test Suite (CTS) che verificano che le singole autorizzazioni siano mappate ai gruppi corretti. Il superamento di questi test è un requisito per la compatibilità con Android 6.0 e versioni successive CTS.
Revoca dei permessi
In Android 13 e versioni successive, puoi revocare le autorizzazioni di runtime concesse utilizzando Context.revokeSelfPermissionsOnKill() . La revoca avviene in modo asincrono e viene attivata quando è sicuro farlo senza interrompere l'utente. Quando viene attivata la revoca, tutti i processi in esecuzione nell'UID chiamante verranno uccisi.
È importante comprendere che la revoca di una singola autorizzazione potrebbe non essere riflessa nell'interfaccia utente delle impostazioni, che tratta le autorizzazioni per gruppo. In genere, un gruppo di autorizzazioni verrà visualizzato come concesso purché sia concessa almeno una delle autorizzazioni in quel gruppo. Se per te è importante assicurarsi che gli utenti siano in grado di 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 verrà attivata finché il processo rimane in primo piano, ma può anche essere attivata immediatamente uccidendo manualmente tutti i processi in esecuzione nell'uid corrente, ad esempio utilizzando System.exit() . Tuttavia si consiglia di lasciare che sia il sistema a decidere quando attivarlo.
Dopo che una revoca dell'autorizzazione è effettiva, è possibile richiederla nuovamente e all'utente verrà chiesto di concedere o rifiutare la richiesta. Non è possibile richiedere un permesso che era stato precedentemente negato dall'utente. Sebbene tu sia incoraggiato a revocare le autorizzazioni che detieni attualmente ma non sono più necessarie, dovresti fare attenzione a non informare l'utente della revoca fino a quando non sarà effettiva.