In Android 6.0 e versioni successive, il modello delle 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 autorizzazioni in fase di installazione a un modello di autorizzazioni in fase di esecuzione :
- Autorizzazioni al momento dell'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 preconcesse senza avvisare l'utente.
- Autorizzazioni di esecuzione
( Android 6.0 – 9 ) Gli utenti concedono autorizzazioni pericolose a un'app quando l'app è in esecuzione. Il momento in cui vengono richieste le autorizzazioni (ad esempio all'avvio dell'app o quando l'utente accede a una funzionalità specifica) dipende dall'applicazione, ma l'utente concede/nega l'accesso all'applicazione a gruppi di autorizzazioni specifici. Gli OEM/gli operatori possono preinstallare le app, ma non possono preconcedere le autorizzazioni a meno che non eseguano il processo di eccezione. (Vedi Creazione di eccezioni .)
( Android 10 ) Gli utenti vedono una maggiore trasparenza e hanno il controllo su quali app dispongono di autorizzazioni di runtime di riconoscimento delle attività (AR). Agli utenti viene richiesto dalla finestra di dialogo delle autorizzazioni di runtime 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 ulteriore contesto e visibilità sui tipi di autorizzazioni che le applicazioni stanno cercando o sono state concesse. Il modello runtime incoraggia gli sviluppatori ad aiutare gli utenti a capire perché le applicazioni richiedono le autorizzazioni richieste e fornisce maggiore trasparenza in modo che gli utenti possano prendere decisioni migliori sulla 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 ad alto rischio (come READ_CALENDAR ) che concedono alle applicazioni richiedenti l'accesso ai dati privati dell'utente o il controllo su 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 normali autorizzazioni . Queste sono tutte autorizzazioni non pericolose, incluse 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 all'applicazione richiedente al momento dell'installazione e non richiede l'approvazione dell'utente. Per dettagli sulle autorizzazioni, vedere la documentazione dell'elemento <permission> .
Restrizioni rigide e flessibili in Android 10
Oltre ad essere pericolosa, un'autorizzazione può essere limitata in modo rigido o limitato. In entrambi i casi, anche l'autorizzazione limitata deve essere inclusa nella lista consentita. Le restrizioni rigide non incluse nella lista consentita si comportano diversamente rispetto alle restrizioni flessibili non incluse nella lista consentita:
- ( Restrizioni rigide ) Non è possibile concedere autorizzazioni alle app che non sono incluse nella lista consentita.
- ( Restrizioni flessibili ) Le app senza inclusione nella lista consentita si comportano in base all'autorizzazione specifica richiesta. Il comportamento è descritto nella documentazione pubblica per l'autorizzazione richiesta.
Quando si installa un'app, il programma di installazione (come Google Play Store) può scegliere di non consentire le autorizzazioni limitate per l'app. Le autorizzazioni sono limitate dalla piattaforma e sono concesse solo se un'app soddisfa criteri speciali secondo i criteri della piattaforma. Esempi di tipi di autorizzazione 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 aggiornamento Android 9-10.
- è stata concessa un'autorizzazione o è stata preinstallata un'app.
- è necessaria un'autorizzazione per un ruolo già definito per consentire l'autorizzazione.
- il programma di installazione (come Google Play Store) contrassegna l'autorizzazione come inclusa 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 applicazioni, comprese le app preinstallate e le app fornite 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 che eseguono Android 6.0 e versioni successive. Ciò viene applicato dai test 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 . Possono essere concesse eccezioni limitate 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'autorizzazione di accesso al telefono.) Per i dettagli, vedere Creazione di eccezioni . - Le app precaricate con autorizzazioni pericolose devono avere come target il livello API 23 e mantenere il modello di autorizzazione di runtime. Ciò significa che il flusso dell'interfaccia utente durante l'installazione dell'app non deve discostarsi 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 condividere un UID con un'altra applicazione che dispone delle autorizzazioni necessarie. Per i dettagli, vedere Applicazioni headless .
Migrazione dei permessi
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 revocare tali autorizzazioni in qualsiasi momento.
In un aggiornamento Android 9-10, tutte le autorizzazioni con limitazioni rigide vengono inserite nella lista consentita. Per informazioni dettagliate 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 affinché funzionino 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 utilizzato nell'app PermissionController .
Aggiornamento delle applicazioni
Alle applicazioni nell'immagine di sistema e alle applicazioni preinstallate non vengono concesse automaticamente autorizzazioni. Ti invitiamo a collaborare con gli sviluppatori di app preinstallate (OEM, operatore telefonico e terze parti) per apportare le modifiche richieste alle app utilizzando le linee guida per gli sviluppatori . Nello specifico, è 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 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 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 dalla versione 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 quando installate o se erano preinstallate senza l'utilizzo 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. Utilizza 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 puoi personalizzare il posizionamento, la posizione e le regole di quando viene visualizzata l'interfaccia utente delle autorizzazioni.
Per includere stringhe per lingue aggiuntive, contribuire con le stringhe ad AOSP.
Creazione di eccezioni
Puoi preconcedere 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 di permessi personalizzati
Puoi definire autorizzazioni e gruppi personalizzati come normali o pericolosi e aggiungere autorizzazioni specifiche per OEM/operatore ai gruppi di autorizzazioni esistenti, proprio come potresti fare in Android 5.x e 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:
- Puoi aggiungere nuove autorizzazioni a un gruppo corrente, ma non puoi modificare la mappatura AOSP delle autorizzazioni pericolose e dei gruppi di autorizzazioni pericolose. (In altre parole, non è possibile rimuovere un'autorizzazione da un gruppo e assegnarla a un altro gruppo).
- Puoi aggiungere nuovi gruppi di autorizzazioni nelle applicazioni installate sul dispositivo, ma non puoi aggiungere nuovi gruppi di autorizzazioni nel manifest della piattaforma.
Test delle autorizzazioni
Android include test CTS (Compatibility Test Suite) 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 delle autorizzazioni
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 disturbare l'utente. Quando viene attivata la revoca, tutti i processi in esecuzione nell'UID chiamante verranno terminati.
È importante comprendere che la revoca di una singola autorizzazione potrebbe non riflettersi nell'interfaccia utente delle impostazioni, che tratta le autorizzazioni per gruppo. In genere, un gruppo di autorizzazioni verrà visualizzato come concesso purché venga concessa almeno una delle autorizzazioni in quel gruppo. Se per te è importante garantire che gli utenti siano in grado di confermare la revoca nelle impostazioni, assicurati di revocare ogni autorizzazione nel gruppo di autorizzazione. 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 corrispondenti autorizzazioni in background se nessuna delle corrispondenti autorizzazioni in primo piano è ancora concessa.
La revoca non verrà attivata finché il processo rimane in primo piano ma può anche essere attivata immediatamente terminando 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.
Una volta effettiva la revoca dell'autorizzazione, è possibile richiederla nuovamente e all'utente verrà richiesto di concedere o negare la richiesta. Non è possibile richiedere un permesso precedentemente negato dall'utente. Anche se sei incoraggiato a revocare le autorizzazioni di cui disponi attualmente ma che non sono più necessarie, dovresti fare attenzione a non informare l'utente della revoca fino a quando non sarà effettiva.