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 si mosse applicazioni Android che richiedono i permessi pericolosi (vedi permessi interessati ) da un momento dell'installazione modello di permesso di un modello di permessi di esecuzione:

  • Autorizzazioni al momento dell'installazione

    (Android 5.1 e inferiori) Gli utenti concedono permessi pericolose per un app quando si installa o aggiornare l'applicazione. I produttori di dispositivi e gli operatori possono preinstallare app con autorizzazioni preconcesse senza informare l'utente.

  • Autorizzazioni di runtime

    (Android 6,0-9) Gli utenti concedono le autorizzazioni pericolosi per un'applicazione quando l'applicazione è in esecuzione. Quando vengono richieste le autorizzazioni (ad esempio quando l'app viene avviata 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/i gestori possono preinstallare le app, ma non possono concedere preventivamente le autorizzazioni a meno che non eseguano il processo di eccezione. (Vedere Creazione di eccezioni .)

    (Android 10) Gli utenti vedere una maggiore trasparenza e avere il controllo su quali applicazioni hanno il riconoscimento di attività (AR) i permessi di esecuzione. Agli utenti viene richiesto dai permessi di runtime dialogo a uno sempre permettere, consentono durante l'uso, o negare le autorizzazioni. Su un aggiornamento del sistema operativo ad Android 10, autorizzazioni concesse alle applicazioni vengono mantenuti, ma gli utenti possono andare in Impostazioni e cambiarli.

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 che 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 sulla concessione o il rifiuto.

Autorizzazioni interessate

Android 6.0 e versioni successive richiedono autorizzazioni pericolose per utilizzare un modello di autorizzazioni di runtime. Autorizzazioni pericolosi sono permessi alto rischio (come READ_CALENDAR ) che garantiscono che richiede l'accesso alle applicazioni di dati degli utenti privati, o controllo su un dispositivo, che può influenzare negativamente l'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 cambia il comportamento dei permessi normali . Queste sono tutte autorizzazioni non pericolose, comprese le autorizzazioni normali, di sistema e di firma. Autorizzazioni normali sono autorizzazioni a basso rischio (come SET_WALLPAPER ) che concedono richiedente applicazioni accesso a sezionato a livello di applicazione dispone con minimo rischio 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 <permessi> elemento documentazione.

Restrizioni hard e soft in Android 10

Oltre a essere pericoloso, un'autorizzazione può essere con restrizioni rigide o limitate. In entrambi i casi, anche l'autorizzazione limitata deve essere inserita nella whitelist. Le restrizioni hardware non autorizzate si comportano in modo diverso rispetto alle restrizioni software non autorizzate:

  • (Restrizioni Hard) Apps non possono essere concesse le autorizzazioni che non sono nella whitelist.
  • (Restrizioni Soft) Apps senza whitelist si comportano secondo l'permessi speciali richieste. 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 autorizzare 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 autorizzazioni con limitazioni rigide includono le autorizzazioni SMS e Registro chiamate.

La whitelist si verifica durante l'installazione e quando

  • un'app è già installata durante un aggiornamento da 9 a 10 di Android.
  • un'autorizzazione è preconcesso 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 nella whitelist.

Gli utenti non possono autorizzare manualmente le autorizzazioni.

Requisiti

Il modello di autorizzazione di runtime si applica a tutte le applicazioni, incluse 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 con Android 6.0 e versioni successive. Questo 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 . Eccezioni limitate possono essere concesse ad applicazioni e gestori predefiniti che forniscono funzionalità di base del dispositivo fondamentali per il funzionamento previsto del dispositivo. (Per esempio, app dialer di default del dispositivo per la gestione ACTION_CALL può avere accesso il permesso del telefono.) Per 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. In altre parole, 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, consultare le applicazioni senza testa .

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 da 9 a 10, tutte le autorizzazioni con limitazioni rigide vengono inserite nella whitelist. Per i dettagli sulla realizzazione delle divisione delle autorizzazioni primo piano / sfondo, vedi Android 10 cambiamento della privacy , a cominciare da Richiesta della posizione in background .

Integrazione

Quando si integra il modello delle autorizzazioni di runtime dell'applicazione per Android 6.0 e versioni successive, è necessario aggiornare le applicazioni preinstallate affinché funzionino con il nuovo modello. È inoltre possibile definire delle eccezioni per le applicazioni che sono i gestori predefiniti / fornitori per funzionalità di base, definire autorizzazioni personalizzate e personalizzare il tema utilizzato nel PermissionController app.

Aggiornamento delle applicazioni

Le applicazioni nell'immagine di sistema e le applicazioni preinstallate non sono autorizzazioni preconcesse automaticamente. Vi incoraggiamo a lavorare con gli sviluppatori di app preinstallati (OEM, carrier, e di terze parti) per apportare le modifiche necessarie app che utilizzano 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. Per esempio, il flusso di interfaccia utente durante l'installazione di app non deve discostarsi dalla realizzazione AOSP di PermissionController . Gli utenti possono persino revocare i permessi pericolosi delle app preinstallate.

In Android da 6.0 a 9, alcune autorizzazioni vengono concesse durante il flusso di installazione. Tuttavia, a partire dal 10, il flusso di installazione (eseguita dal Package Installer app) è una funzione separata dalle autorizzazioni concedere (in Permission Controller app).

Applicazioni senza testa

Solo le attività possono richiedere autorizzazioni. I servizi non possono richiedere le autorizzazioni direttamente.

  • In Android 5.1 e versioni precedenti, le applicazioni headless possono richiedere autorizzazioni quando sono installate o se sono state 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. 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 Permessi UI aggiornando i temi dei dispositivi di default ( 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, contribuiscono le stringhe AOSP.

Creare eccezioni

È possibile pre-concessione delle autorizzazioni per le applicazioni che sono gestori predefiniti o fornitori di funzionalità di base del sistema operativo utilizzando il DefaultPermissionGrantPolicy.java classe PackageManager. Esempi:

ACTION_CALL (Dialer) Default
Phone, Contacts, SMS, Microphone
SMS_DELIVER_ACTION (SMS/MMS) Default
Phone, Contacts, SMS

Definizione di permessi personalizzati

È possibile definire autorizzazioni personalizzate e gruppi come normale o pericolosi e aggiungere le autorizzazioni OEM / Carrier-specifici per gruppi di autorizzazioni esistenti, proprio come si potrebbe in Android 5.xe versioni precedenti.

In Android 6.0 e versioni successive, se aggiungi una nuova autorizzazione pericolosa, 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 sul dispositivo, ma non puoi aggiungere nuovi gruppi di autorizzazioni nel manifest della piattaforma.

Permessi di test

Android include test 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.