Google si impegna a promuovere l'equità razziale per le comunità nere. Vedi come.
Questa pagina è stata tradotta dall'API Cloud Translation.
Switch to English

Autorizzazioni di runtime

In Android 6.0 e versioni successive, il modello delle 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 e i gestori di dispositivi possono preinstallare app con autorizzazioni anticipate 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 sono richieste autorizzazioni (come 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 vettori possono preinstallare le app, ma non possono ottenere autorizzazioni anticipate 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 dispongono delle autorizzazioni di runtime di riconoscimento attività (AR). La finestra di dialogo delle autorizzazioni di runtime richiede agli utenti di consentire, consentire durante l'utilizzo o negare sempre le autorizzazioni. Su 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 di un utente e forniscono loro un contesto e una visibilità aggiuntivi sui tipi di autorizzazioni richieste dalle applicazioni 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 offre 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 ad alto rischio (come READ_CALENDAR ) che concedono alle applicazioni richiedenti l'accesso 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 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 dell'utente. Per i dettagli sulle autorizzazioni, consultare la documentazione dell'elemento <permission> .

Restrizioni rigide e leggere in Android 10

Oltre ad essere pericoloso, un'autorizzazione può essere limitata o limitata. In entrambi i casi, anche l'autorizzazione limitata deve essere autorizzata. Le restrizioni rigide non autorizzate si comportano in modo diverso rispetto alle restrizioni 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 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 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 criterio di piattaforma. Esempi di tipi di autorizzazioni con restrizioni rigide includono le autorizzazioni SMS e Registro chiamate.

La whitelisting avviene durante l'installazione e quando

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

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 installazione. 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 Android Compatibility Test Suite (CTS).
  • Le app devono richiedere agli utenti di concedere le autorizzazioni dell'applicazione in fase di esecuzione. Per i dettagli, consultare 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_CALL potrebbe disporre dell'accesso alle autorizzazioni del 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. Cioè, il flusso dell'interfaccia utente durante l'installazione dell'app non deve discostarsi dall'implementazione AOSP di PermissionController, gli utenti possono revocare le autorizzazioni pericolose delle app preinstallate e così via.
  • Le applicazioni senza testa 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 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 Android da 9 a 10, tutte le autorizzazioni con restrizioni rigide vengono autorizzate. Per i dettagli sull'implementazione delle autorizzazioni di suddivisione in primo piano / in background, vedi Modifica della privacy di Android 10 , a partire da Richiedi 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 per funzionare con il nuovo modello. Puoi anche definire eccezioni per le app che sono i gestori / provider predefiniti per le funzionalità principali, definire autorizzazioni personalizzate e personalizzare il tema utilizzato nell'app PermissionController .

Aggiornamento delle applicazioni

Le applicazioni sull'immagine di sistema e le applicazioni preinstallate non dispongono di autorizzazioni predefinite automaticamente. Ti invitiamo a collaborare con sviluppatori di app preinstallati (OEM, operatore e terze parti) per apportare le modifiche necessarie alle app seguendo 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 per 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 sono 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 senza testa possono richiedere autorizzazioni se installate o se sono state preinstallate senza l'uso di un'attività.
  • In Android 6.0 e versioni successive, le applicazioni senza testa devono utilizzare uno dei seguenti metodi per richiedere le autorizzazioni:
    • Aggiungi un'attività per richiedere autorizzazioni. (Questo è il metodo preferito.)
    • Condividi un UID con un'altra applicazione che disponga delle autorizzazioni necessarie. Utilizzare questo metodo solo quando è necessaria la piattaforma per gestire più APK come 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 si desidera, è possibile personalizzare il tema dell'interfaccia utente 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 relative alla visualizzazione dell'interfaccia utente delle autorizzazioni.

Per includere stringhe per altre lingue, aggiungere le stringhe ad AOSP.

Creare eccezioni

È possibile pre-concedere autorizzazioni alle applicazioni che sono gestori o provider predefiniti per la funzionalità del SO principale 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 OEM / Carrier ai gruppi di autorizzazioni esistenti, proprio come 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 di altre autorizzazioni pericolose (richieste durante il runtime dell'app e revocabili dagli utenti). In particolare:

  • È possibile aggiungere nuove autorizzazioni a un gruppo corrente, ma non è possibile 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 assegnare a un altro gruppo).
  • È possibile aggiungere nuovi gruppi di autorizzazioni nelle applicazioni installate sul dispositivo, ma non è possibile aggiungere nuovi gruppi di autorizzazioni nel manifest della piattaforma.

Autorizzazioni di test

Android include test di Compatibility Test Suite (CTS) che verificano che le singole autorizzazioni siano associate ai gruppi corretti. Il superamento di questi test è un requisito per la compatibilità con Android 6.0 e successive CTS.