Autorizzazioni runtime

In Android 6.0 e versioni successive, il modello di autorizzazioni delle app per Android è progettato per autorizzazioni più comprensibili, utili e sicure per gli utenti. Il modello ha spostato Android che richiedono autorizzazioni pericolose (vedi Autorizzazioni interessate) da un 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. Dispositivo produttori e operatori possono preinstallare app con autorizzazioni preconcesse senza informare il utente.

  • Autorizzazioni di runtime

    (Android 6.0-9) Gli utenti concedono autorizzazioni pericolose a un'app quando è in esecuzione. Quando vengono richieste le autorizzazioni (ad esempio all'avvio dell'app o quando l'utente accede a un funzionalità) dipende dall'app, ma l'utente concede o nega l'accesso all'app a specifiche gruppi di autorizzazioni. Gli OEM/gli operatori possono preinstallare le app, ma non possono preconcedere le autorizzazioni a meno che non segui la procedura di eccezione. Consulta la sezione Creazione di eccezioni.

    (Android 10). Gli utenti notano una maggiore trasparenza e hanno controllo sulle app con autorizzazioni di runtime AR (Riconoscimento attività). Gli utenti vengono suggeriti da finestra di dialogo delle autorizzazioni di runtime per consentire sempre, consentire durante l'uso o negare le autorizzazioni. In un upgrade del sistema operativo ad Android 10, le autorizzazioni concesse alle app vengono mantenute, ma gli utenti possono andare in Impostazioni e modificarle.

Le autorizzazioni di runtime impediscono alle app di accedere a dati privati senza il consenso dell'utente. e fornire loro ulteriore contesto e visibilità sui tipi di autorizzazioni che che le app cercano o sono state concesse. Il modello di runtime incoraggia gli sviluppatori aiutare gli utenti a capire perché le app richiedono le autorizzazioni richieste, e offre una maggiore 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 usare un modello di autorizzazioni di runtime. Le autorizzazioni pericolose sono autorizzazioni ad alto rischio (ad esempio READ_CALENDAR) che concedono Richiedere l'accesso delle app a dati privati dell'utente o il controllo di un dispositivo, il che può essere negativo avere un impatto sull'utente. Per visualizzare un elenco delle autorizzazioni pericolose, esegui il comando:

adb shell pm list permissions -g -d

Android 6.0 e versioni successive non modifica il comportamento normale autorizzazioni. Queste sono tutte autorizzazioni non pericolose, tra cui quelle normali, le autorizzazioni di accesso al sistema e le autorizzazioni di firma. Le autorizzazioni normali sono autorizzazioni a rischio inferiore (come SET_WALLPAPER) che concedono l'accesso alle app di richiesta a livello di app isolata funzionalità con rischi minimi per altre app, il sistema o l'utente. Come in Android 5.1 e release precedenti, il sistema concede automaticamente le normali autorizzazioni a un'app richiedente all'indirizzo l'installazione senza richiedere l'approvazione dell'utente. Per maggiori dettagli sulle autorizzazioni, leggi l'articolo <permission> .

Limitazioni rigide e flessibili in Android 10

Oltre a essere pericolosa, un'autorizzazione può essere soggetta a restrizioni o con restrizioni temporanee. In entrambi i casi, anche l'autorizzazione limitata deve essere inclusa nella lista consentita. Non incluso nella lista consentita le limitazioni rigidi si comportano in modo diverso rispetto alle restrizioni non consentite nella lista consentita restrizioni:

  • (Limitazioni rigorose) Alle app non è possibile concedere autorizzazioni che non sono inserito nella lista consentita.
  • (Limitazioni tecniche) Le app che non sono state inserite nella lista consentita si comportano in base ai l'autorizzazione specifica richiesta. Il comportamento viene descritto pubblicamente documentazione relativa all'autorizzazione richiesta.

Durante l'installazione di un'app, il programma di installazione (ad esempio Google Play Store) potrebbe selezionare per non inserire nella lista consentita le autorizzazioni limitate per l'app. Le autorizzazioni sono sono limitati dalla piattaforma e sono concessi solo se un'app soddisfa criteri speciali in base ai criteri della piattaforma. Esempi di tipi di autorizzazioni con restrizioni hard includono gli SMS e le autorizzazioni Registro chiamate.

La lista consentita viene inserita durante l'installazione e

  • un'app è già installata durante un upgrade di Android dalla versione 9 alla 10.
  • è stata preconcessa un'autorizzazione o un'app è preinstallata.
  • è necessaria un'autorizzazione per un ruolo già definito autorizzazione.
  • il programma di installazione (ad esempio Google Play Store) contrassegna l'autorizzazione come inserito 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 app, incluse le app e le app preinstallate inviati al dispositivo durante la procedura di configurazione. I requisiti del software dell'app includono:

  • Il modello di autorizzazione di runtime deve essere coerente tra tutti i dispositivi con Android 6.0 e superiori. Questo requisito viene applicato dai test della suite per il test di compatibilità Android (CTS).
  • Le app devono richiedere agli utenti di concedere le autorizzazioni app in fase di runtime. Per maggiori dettagli, consulta Aggiornamento Google Cloud. Possono essere concesse eccezioni limitate ad app e gestori predefiniti che forniscono funzionalità di base del dispositivo fondamentali per il funzionamento previsto del dispositivo. Ad esempio, l'app Telefono predefinita del dispositivo per la gestione di ACTION_CALL potrebbe avere Accesso alle autorizzazioni del telefono. Per maggiori dettagli, consulta la sezione Creare eccezioni.
  • App precaricate con autorizzazioni pericolose deve avere il livello API target 23 e mantenere il modello di autorizzazioni di runtime. ovvero il flusso dell'interfaccia utente durante l'installazione dell'app non devono discostarsi dall'implementazione AOSP PermissionController, gli utenti possono revocare autorizzazioni pericolose di app preinstallate e così via attiva.
  • Le app headless devono utilizzare un'attività per richiedere autorizzazioni o per UID di un'altra app che dispone delle autorizzazioni necessarie. Per maggiori dettagli, vedi App headless.

Migrazione delle autorizzazioni

Le autorizzazioni concesse alle app su Android 5.x rimangono concesse dopo l'aggiornamento ad Android 6.0 o superiore, ma gli utenti possono revocare queste autorizzazioni in qualsiasi momento.

In un aggiornamento di Android da 9 a 10, tutte le autorizzazioni limitate ricevono inserito nella lista consentita. Per maggiori dettagli sull'implementazione delle autorizzazioni di suddivisione in primo piano/in background, consulta Modifica della privacy di Android 10, che inizia con Richiedi background posizione.

Integrazione

Quando integri il modello di autorizzazioni di runtime delle app per Android 6.0 e versioni successive, devi: aggiornare le app preinstallate affinché siano compatibili con il nuovo modello. Puoi anche definire eccezioni per le app che sono gestori/provider predefiniti per la funzionalità di base, definiscono autorizzazioni personalizzate e personalizza il tema utilizzato nell'app PermissionController.

Aggiorna le app

Le app nell'immagine di sistema e le app preinstallate non vengono preconcesse automaticamente autorizzazioni aggiuntive. Ti invitiamo a collaborare con sviluppatori di app preinstallate (OEM, operatore e parte) di apportare le modifiche necessarie all'app utilizzando lo strumento di generazione linee guida. Nello specifico, devi assicurarti che le app preinstallate vengano modificate per evitare arresti anomali e altri problemi quando gli utenti revocano le autorizzazioni.

App precaricate

In Android 9 e versioni precedenti, le app precaricate che usano autorizzazioni pericolose devono avere il livello API target 23 o versioni successive e mantieni il modello di autorizzazione AOSP Android 6.0 e versioni successive. Ad esempio, il flusso UI durante l'installazione di un'app non devono discostarsi dall'implementazione AOSP PermissionController. Gli utenti possono anche revocare autorizzazioni pericolose di app preinstallate.

Nelle versioni da 6.0 a 9 di Android, alcune autorizzazioni vengono concesse durante il flusso di installazione. Tuttavia, a partire da in 10, il flusso di installazione (eseguito dall'app Package Installer) è una funzione separata dalla concessione delle autorizzazioni (nel Permission Controller).

App headless

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

  • In Android 5.1 e versioni precedenti, le app headless possono richiedere autorizzazioni quando installati o se sono stati preinstallati senza l'utilizzo di alcuna attività.
  • Nella Per le app headless di Android 6.0 e versioni successive è necessario usare uno dei seguenti metodi richiedi le autorizzazioni:
    • Aggiungi un'attività per richiedere le autorizzazioni. Questo è il metodo preferito.
    • Condividere un UID con un'altra app che dispone delle autorizzazioni necessarie. Usa questa solo quando è necessario che la piattaforma gestisca più APK come singole dell'app.

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

Personalizzare l'interfaccia utente di PackageInstaller

Se vuoi, puoi personalizzare il tema dell'interfaccia utente Autorizzazioni aggiornamento dei 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 puoi personalizzare il posizionamento, la posizione e le regole relative a quando le autorizzazioni nell'interfaccia utente.

Per includere stringhe per altre lingue, aggiungi il da stringhe ad AOSP.

Crea eccezioni

Puoi pre-concedere autorizzazioni ad app che sono gestori predefiniti o ai provider per le funzionalità di base del sistema operativo DefaultPermissionGrantPolicy.java classe in PackageManager. Esempi:

ACTION_CALL (Dialer) Default
Phone, Contacts, SMS, Microphone

SMS_DELIVER_ACTION (SMS/MMS) Default
Phone, Contacts, SMS

Definisci autorizzazioni personalizzate

Puoi definire autorizzazioni e gruppi personalizzati come normale o pericoloso e aggiungi autorizzazioni specifiche dell'operatore/OEM alle gruppi di autorizzazioni, proprio come in Android 5.x e versioni precedenti.

In Android 6.0 e versioni successive, se aggiungi una nuova autorizzazione pericolosa, questa deve essere gestita in allo stesso modo di altre autorizzazioni pericolose (richieste durante il runtime dell'app e revocabile dagli utenti). Nello specifico:

  • Puoi aggiungere nuove autorizzazioni a un gruppo corrente, ma non puoi modificare le Mappatura AOSP di autorizzazioni pericolose e gruppi di autorizzazioni pericolosi. (In altre parole, non può rimuovere un'autorizzazione da un gruppo per assegnarla a un altro gruppo).
  • Puoi aggiungere nuovi gruppi di autorizzazioni nelle app installate sul dispositivo. ma non puoi aggiungere nuovi gruppi di autorizzazioni nel file manifest della piattaforma.

Autorizzazioni di test

Android include test della Compatibility Test Suite (CTS) che verificano 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.

Revoca autorizzazioni

In Android 13 e versioni successive, puoi revocare le tue autorizzazioni le autorizzazioni di runtime Context.revokeSelfPermissionsOnKill(). La revoca avviene in modo asincrono e viene attivata quando è sicuro farlo senza interrompere per l'utente. Quando la revoca viene attivata, tutti i processi in esecuzione nell'UID di chiamata vengono terminati.

È importante capire che la revoca di una singola autorizzazione potrebbe non avere effetto nel di Google Cloud, che gestisce le autorizzazioni per gruppo. Generalmente, un gruppo di autorizzazioni viene visualizzato come purché sia concessa almeno una delle autorizzazioni del gruppo. Se devi assicurarti che gli utenti verificare che la revoca nelle impostazioni sia importante per te, assicurati di revocare ogni nel gruppo di autorizzazioni. Per sapere quali autorizzazioni appartengono a un determinato gruppo, puoi usa PackageManager.getGroupOfPlatformPermission e PackageManager.getPlatformPermissionsForGroup.

Quando il sistema revoca le autorizzazioni richieste, revoca anche lo sfondo corrispondente autorizzazioni se nessuna delle autorizzazioni in primo piano corrispondenti è ancora concessa.

La revoca non viene attivata finché il processo rimane in primo piano, ma può possono essere attivati immediatamente terminando manualmente tutti i processi in esecuzione nell'uid corrente, utilizzando System.exit(). Tuttavia, è consigliabile lasciare che sia il sistema a decidere quando attivarlo.

Una volta che la revoca di un'autorizzazione diventa effettiva, potrai richiederla nuovamente e l'utente potrà se viene richiesto di accettare o rifiutare la richiesta. Non è possibile richiedere un'autorizzazione con sia stata rifiutata in precedenza dall'utente. Nonostante ti invitiamo a revocare le autorizzazioni che ti al momento sono sospesi ma non sono più necessari, devi prestare attenzione a non informare l'utente del revoca fino alla sua entrata in vigore.