Autorizzazioni di runtime

In Android 6.0 e versioni successive, il modello di autorizzazioni dell'applicazione 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 (vedere 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 installano o aggiornano l'app. I produttori di dispositivi e gli operatori possono preinstallare le app con autorizzazioni concesse 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 le 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 dell'applicazione a gruppi di autorizzazioni specifici. Gli OEM / i corrieri possono preinstallare le app, ma non possono mantenere le autorizzazioni a meno che non passino attraverso il processo di eccezione. (Vedere Creazione di eccezioni .)

    ( Android 10 ) Gli utenti vedono una maggiore trasparenza e hanno il controllo su quali app dispongono delle 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 un contesto e una visibilità aggiuntivi sui tipi di autorizzazioni che le applicazioni stanno cercando o a cui 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 concessione o al rifiuto.

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 richieste di accedere ai dati degli utenti privati ​​o il controllo su un dispositivo, che può 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 modifica 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 dell'utente. Per i dettagli sulle autorizzazioni, vedere la documentazione dell'elemento <permission> .

Restrizioni rigide e flessibili in Android 10

Oltre a essere pericoloso, un permesso può essere limitato o limitato in modo flessibile. In entrambi i casi, anche l'autorizzazione limitata deve essere inserita nella whitelist. Le restrizioni rigide non autorizzate si comportano in modo diverso dalle restrizioni flessibili non autorizzate:

  • ( Restrizioni rigide ) Alle app non possono essere concesse autorizzazioni non autorizzate.
  • ( Limitazioni soft ) Le app senza whitelist si comportano in base all'autorizzazione specifica che richiedono. Il comportamento è descritto nella documentazione pubblica per l'autorizzazione richiesta.

Durante l'installazione di un'app, il programma di installazione (come Google Play Store) potrebbe scegliere di non autorizzare le autorizzazioni limitate per l'app. Le autorizzazioni sono limitate dalla piattaforma e possono essere concesse solo se un'app soddisfa criteri speciali per i criteri della piattaforma. Esempi di tipi di autorizzazione con limitazioni rigide includono le autorizzazioni per gli SMS e il registro delle chiamate.

Il whitelisting avviene durante l'installazione e quando

  • un'app è già installata durante un aggiornamento da Android 9 a 10.
  • un'autorizzazione è stata concessa o un'app è preinstallata.
  • è necessaria un'autorizzazione per un ruolo già definito per autorizzare l'autorizzazione.
  • il programma di installazione (come Google Play Store) contrassegna l'autorizzazione come white list.

Gli utenti non possono inserire manualmente le autorizzazioni nella whitelist.

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. Questo viene applicato 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 . Possono essere concesse eccezioni limitate alle applicazioni e ai 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_CALL potrebbe disporre dell'autorizzazione di accesso al telefono.) Per i dettagli, vedere Creazione di eccezioni .
  • Le app precaricate con autorizzazioni pericolose devono essere indirizzate al 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 revocare tali autorizzazioni in qualsiasi momento.

In un aggiornamento di Android da 9 a 10, tutte le autorizzazioni con limitazioni rigide vengono inserite nella whitelist. Per i dettagli sull'implementazione delle autorizzazioni di suddivisione in primo piano / in background, vedere 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

Le applicazioni nell'immagine di sistema e le applicazioni preinstallate non sono autorizzazioni concesse automaticamente. 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 . 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 superiore e mantenere il modello di autorizzazione AOSP per Android 6.0 e versioni successive. Ad esempio, il flusso dell'interfaccia utente durante l'installazione di un'app non deve deviare dall'implementazione AOSP di PermissionController . Gli utenti possono persino revocare le pericolose autorizzazioni delle app preinstallate.

In Android 6.0 e 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 direttamente le autorizzazioni.

  • 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. Usa questo metodo solo quando hai bisogno della piattaforma per gestire più APK come una singola applicazione.

L'obiettivo è evitare di confondere gli utenti con richieste di autorizzazione che appaiono fuori contesto.

Personalizzazione dell'interfaccia utente di PackageInstaller

Se lo desideri, 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 è possibile personalizzare il posizionamento, la posizione e le regole di quando viene visualizzata l'interfaccia utente delle autorizzazioni.

Per includere stringhe per lingue aggiuntive, invia le stringhe ad AOSP.

Creazione di eccezioni

È possibile pre-concedere le autorizzazioni alle applicazioni che sono gestori o provider predefiniti per le funzionalità del sistema operativo di base 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 autorizzazioni personalizzate

È possibile definire autorizzazioni e gruppi personalizzati come normali o pericolosi e aggiungere autorizzazioni specifiche dell'OEM / operatore ai gruppi di autorizzazioni esistenti, proprio come si poteva in Android 5.xe 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 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 sul dispositivo, ma non puoi aggiungere nuovi gruppi di autorizzazioni nel manifesto 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 di CTS.