Richiedi autorizzazioni di runtime

Ogni app Android viene eseguita in una sandbox ad accesso limitato. Se la tua app deve utilizzare risorse o informazioni al di fuori della propria sandbox, puoi dichiarare un autorizzazione e configurare una richiesta di autorizzazione. che fornisce questo accesso. Questi passaggi fanno parte del flusso di lavoro per l'utilizzo autorizzazioni.

Se dichiari un pericoloso autorizzazioni e se la tua app sia installata su un dispositivo con Android 6.0 (livello API 23) oppure devi richiedere le autorizzazioni pericolose in fase di runtime, seguendo le passaggi in questa guida.

Se non dichiari autorizzazioni pericolose o se la tua app è installata su un dispositivo con Android 5.1 (livello API 22) o versioni precedenti, le autorizzazioni vengono automaticamente e non devi completare nessuno dei passaggi rimanenti in questa pagina.

Principi di base

Di seguito sono riportati i principi di base per la richiesta di autorizzazioni in fase di runtime:

• Chiedi un'autorizzazione nel contesto, quando l'utente inizia a interagire con la funzionalità che lo richiede.
• Non bloccare l'utente. Fornisci sempre la possibilità di annullare un'interfaccia utente didattica ad esempio un flusso che spiega la motivazione della richiesta di autorizzazioni.
• Se l'utente nega o revoca un'autorizzazione di cui ha bisogno una funzionalità, ridurre la qualità della tua app in modo che l'utente possa continuare a utilizzarla, possibilmente la disattivazione della funzionalità che richiede l'autorizzazione.
• Non dare per scontato alcun comportamento del sistema. Ad esempio, non dare per scontato che le autorizzazioni Appaiono nello stesso gruppo di autorizzazioni. Un gruppo di autorizzazioni aiuta semplicemente minimizzare il numero di finestre di dialogo di sistema presentate all'utente quando un'app richiede autorizzazioni strettamente correlate.

Flusso di lavoro per la richiesta di autorizzazioni

Prima di dichiarare e richiedere le autorizzazioni di runtime nella tua app, valuta se la tua app deve farlo. Puoi soddisfano molti casi d'uso nell'app, ad esempio scattare foto, mettere in pausa i contenuti multimediali la riproduzione e la visualizzazione di annunci pertinenti, senza la necessità di dichiarare autorizzazioni aggiuntive.

Se concludi che la tua app deve dichiarare e richiedere autorizzazioni di runtime, completa questi passaggi:

1. Nel file manifest dell'app, dichiara il autorizzazioni necessarie alla tua app richiesta.
2. Progetta l'esperienza utente della tua app in modo da associare determinate azioni al suo interno autorizzazioni di runtime specifiche. Fai sapere agli utenti quali azioni potrebbero richiederli per concedere alla tua app l'autorizzazione ad accedere ai dati utente privati.
3. Attendi che l'utente richiami l'attività o l'azione nella tua app che richiedono l'accesso a specifici dati privati dell'utente. A quel punto, la tua app può e richiedere l'autorizzazione di runtime necessaria per accedere ai dati.

4. Controllare se l'utente ha già concesso il runtime autorizzazione richiesta dalla tua app. In questo caso, la tua app può accedere i dati privati dell'utente. In caso contrario, vai al passaggio successivo.

   Devi verificare se disponi dell'autorizzazione ogni volta che esegui una che richiede questa autorizzazione.

5. Verifica se la tua app deve mostrare una motivazione all'utente, che spiega perché la tua app richiede all'utente di concedere una determinata autorizzazione di runtime. Se il sistema stabilisce che la tua app non deve mostrare una motivazione, continua a al passaggio successivo, senza mostrare un elemento UI.

   Se invece il sistema stabilisce che la tua app deve mostrare una motivazione: presentare la logica all'utente in un elemento dell'interfaccia utente. In questa logica, spiegare chiaramente a quali dati sta cercando di accedere la tua app e quali vantaggi che l'app può fornire all'utente se concede l'autorizzazione di runtime. Dopo il giorno Se l'utente riconosce la motivazione, vai al passaggio successivo.

6. Richiedi l'autorizzazione di runtime richiesta dalla tua app per accedere ai dati privati dell'utente. Il sistema visualizza come quello mostrato nella panoramica delle autorizzazioni .

7. Verifica la risposta dell'utente, se ha scelto di concedere o negare l'autorizzazione l'autorizzazione di runtime.

8. Se l'utente ha concesso l'autorizzazione alla tua app, puoi accedere ai dati utente. Se invece l'utente ha negato l'autorizzazione, riduci in modo gentile la tua esperienza nell'app in modo che forniscano funzionalità all'utente senza le informazioni protette da tale autorizzazione.

La figura 1 illustra il flusso di lavoro e l'insieme di decisioni associati di elaborazione:

Determinare se alla tua app è già stata concessa l'autorizzazione

Per verificare se l'utente ha già concesso alla tua app un'autorizzazione specifica, passa quella autorizzazione ContextCompat.checkSelfPermission() . Questo metodo restituisce PERMISSION_GRANTED o PERMISSION_DENIED, a seconda che l'app disponga o meno dell'autorizzazione.

Spiega perché la tua app ha bisogno dell'autorizzazione

La finestra di dialogo delle autorizzazioni mostrata dal sistema quando chiami requestPermissions() indica quale autorizzazione richiede la tua app, ma non dice perché. In alcuni casi, l'utente potrebbe trovare questo sconcertante. È consigliabile Spiega all'utente perché la tua app richiede le autorizzazioni prima della chiamata requestPermissions().

La ricerca dimostra che gli utenti si sentono molto più a loro agio con le richieste di autorizzazione se sanno perché l'app ne ha bisogno, ad esempio se è necessaria l'autorizzazione per supportare una funzionalità principale dell'app o per la pubblicità. Di conseguenza, se utilizzando solo una frazione delle chiamate API che rientrano in un gruppo di autorizzazioni, aiuta a elencare esplicitamente quali di queste autorizzazioni stai utilizzando e perché. Per Ad esempio, se utilizzi solo la posizione approssimativa, informa l'utente nel tuo descrizione dell'app o negli articoli del Centro assistenza relativi all'app.

In determinate condizioni, è utile anche informare gli utenti della l'accesso ai dati sensibili in tempo reale. Ad esempio, se accedi al fotocamera o microfono, è una buona idea informare l'utente utilizzando una di notifica in qualsiasi punto dell'app o nella barra delle notifiche (se dell'applicazione è in esecuzione in background), quindi non sembra che tu stia raccolgono i dati in modo occulto.

In definitiva, se devi richiedere l'autorizzazione per creare qualcosa nella tua app, funzionano, ma il motivo non è chiaro all'utente; cerca un modo per permettere all'utente capire perché ti serve le autorizzazioni più sensibili.

Se il metodo ContextCompat.checkSelfPermission() restituisce PERMISSION_DENIED, chiama shouldShowRequestPermissionRationale(). Se questo metodo restituisce true, mostra all'utente un'interfaccia utente formativa. In questa UI, descrivere perché la funzionalità che l'utente vuole attivare richiede un particolare autorizzazione.

Inoltre, se l'app richiede un'autorizzazione relativa a posizione, microfono, o la fotocamera, valuta la possibilità di spiegare perché la tua app richiede l'accesso a queste informazioni.

Richiedi autorizzazioni

Dopo che l'utente visualizza un'interfaccia utente formativa o il valore restituito shouldShowRequestPermissionRationale() indica che non devi mostrare un'interfaccia utente didattica, richiedi l'autorizzazione. Gli utenti vedono un sistema finestra di dialogo di autorizzazione, dove possono scegliere se concedere o meno autorizzazione per la tua app.

Per farlo, utilizza la RequestPermission incluso in una libreria AndroidX, in cui consenti al sistema di gestire il codice della richiesta di autorizzazione. Poiché utilizzando il contratto RequestPermission semplifica la logica, è consigliabile soluzione quando possibile. Tuttavia, se necessario, puoi anche gestire un codice di richiesta di te nell'ambito della richiesta di autorizzazione. includi questo codice di richiesta nella logica di callback delle autorizzazioni.

Consenti al sistema di gestire il codice di richiesta di autorizzazione

Per consentire al sistema di gestire il codice di richiesta associato a un di autorizzazione, aggiungi dipendenze nelle librerie seguenti file build.gradle del modulo:

• androidx.activity, versione 1.2.0 o successiva
• androidx.fragment, versione 1.3.0 o successiva

Puoi quindi utilizzare una delle seguenti classi:

• Per richiedere una singola autorizzazione, utilizza RequestPermission
• Per richiedere più autorizzazioni contemporaneamente, utilizza RequestMultiplePermissions

I passaggi seguenti spiegano come utilizzare il contratto RequestPermission. La è quasi la stessa procedura prevista per il contratto RequestMultiplePermissions.

1. Nella logica di inizializzazione dell'attività o del frammento, passa un'implementazione di ActivityResultCallback in una chiamata a registerForActivityResult(). L'ActivityResultCallback definisce il modo in cui la tua app gestisce la risposta dell'utente a la richiesta di autorizzazione.

   Tieni un riferimento al valore restituito di registerForActivityResult(), che è di tipo ActivityResultLauncher

2. Per visualizzare la finestra di dialogo delle autorizzazioni di sistema quando necessario, richiama il launch() sull'istanza di ActivityResultLauncher che hai salvato nel passaggio precedente.

   Dopo aver chiamato launch(), viene visualizzata la finestra di dialogo delle autorizzazioni di sistema. Quando l'utente fa una scelta, il sistema richiama la tua implementazione in modo asincrono di ActivityResultCallback che hai definito nel passaggio precedente.

   Nota: la tua app non può personalizzare la finestra di dialogo visualizzata. quando chiami launch(). Per fornire ulteriori informazioni o contesto per l'utente, modifica l'UI dell'app in modo che per gli utenti sia più facile Comprendere perché una funzionalità della tua app richiede un'autorizzazione specifica. Per Ad esempio, potresti modificare il testo nel pulsante che attiva funzionalità.

   Inoltre, il testo nella finestra di dialogo delle autorizzazioni di sistema fa riferimento autorizzazione gruppo associato all'autorizzazione che hai richiesto. Questo Il raggruppamento delle autorizzazioni è progettato per la facilità d'uso del sistema e non devono fare affidamento su autorizzazioni che si trovano all'interno o all'esterno di un gruppo di autorizzazioni.

Il seguente snippet di codice mostra come gestire la risposta relativa alle autorizzazioni:

// Register the permissions callback, which handles the user's response to the
// system permissions dialog. Save the return value, an instance of
// ActivityResultLauncher. You can use either a val, as shown in this snippet,
// or a lateinit var in your onAttach() or onCreate() method.
val requestPermissionLauncher =
    registerForActivityResult(RequestPermission()
    ) { isGranted: Boolean ->
        if (isGranted) {
            // Permission is granted. Continue the action or workflow in your
            // app.
        } else {
            // Explain to the user that the feature is unavailable because the
            // feature requires a permission that the user has denied. At the
            // same time, respect the user's decision. Don't link to system
            // settings in an effort to convince the user to change their
            // decision.
        }
    }

// Register the permissions callback, which handles the user's response to the
// system permissions dialog. Save the return value, an instance of
// ActivityResultLauncher, as an instance variable.
private ActivityResultLauncher<String> requestPermissionLauncher =
    registerForActivityResult(new RequestPermission(), isGranted -> {
        if (isGranted) {
            // Permission is granted. Continue the action or workflow in your
            // app.
        } else {
            // Explain to the user that the feature is unavailable because the
            // feature requires a permission that the user has denied. At the
            // same time, respect the user's decision. Don't link to system
            // settings in an effort to convince the user to change their
            // decision.
        }
    });

Questo snippet di codice mostra la procedura consigliata per verificare la presenza di un'autorizzazione e per richiedere un'autorizzazione all'utente quando necessario:

when {
    ContextCompat.checkSelfPermission(
            CONTEXT,
            Manifest.permission.REQUESTED_PERMISSION
            ) == PackageManager.PERMISSION_GRANTED -> {
        // You can use the API that requires the permission.
    }
    ActivityCompat.shouldShowRequestPermissionRationale(
            this, Manifest.permission.REQUESTED_PERMISSION) -> {
        // In an educational UI, explain to the user why your app requires this
        // permission for a specific feature to behave as expected, and what
        // features are disabled if it's declined. In this UI, include a
        // "cancel" or "no thanks" button that lets the user continue
        // using your app without granting the permission.
        showInContextUI(...)
    }
    else -> {
        // You can directly ask for the permission.
        // The registered ActivityResultCallback gets the result of this request.
        requestPermissionLauncher.launch(
                Manifest.permission.REQUESTED_PERMISSION)
    }
}

if (ContextCompat.checkSelfPermission(
        CONTEXT, Manifest.permission.REQUESTED_PERMISSION) ==
        PackageManager.PERMISSION_GRANTED) {
    // You can use the API that requires the permission.
    performAction(...);
} else if (ActivityCompat.shouldShowRequestPermissionRationale(
        this, Manifest.permission.REQUESTED_PERMISSION)) {
    // In an educational UI, explain to the user why your app requires this
    // permission for a specific feature to behave as expected, and what
    // features are disabled if it's declined. In this UI, include a
    // "cancel" or "no thanks" button that lets the user continue
    // using your app without granting the permission.
    showInContextUI(...);
} else {
    // You can directly ask for the permission.
    // The registered ActivityResultCallback gets the result of this request.
    requestPermissionLauncher.launch(
            Manifest.permission.REQUESTED_PERMISSION);
}

Gestire autonomamente il codice della richiesta di autorizzazione

In alternativa a consentire al sistema di gestire la richiesta di autorizzazione Google Cloud, puoi gestire la richiesta di autorizzazione codice tu stesso. Per farlo, includi il codice di richiesta in una chiamata a requestPermissions()

Il seguente snippet di codice mostra come richiedere un'autorizzazione utilizzando un codice di richiesta:

when {
    ContextCompat.checkSelfPermission(
            CONTEXT,
            Manifest.permission.REQUESTED_PERMISSION
            ) == PackageManager.PERMISSION_GRANTED -> {
        // You can use the API that requires the permission.
        performAction(...)
    }
    ActivityCompat.shouldShowRequestPermissionRationale(
            this, Manifest.permission.REQUESTED_PERMISSION) -> {
        // In an educational UI, explain to the user why your app requires this
        // permission for a specific feature to behave as expected, and what
        // features are disabled if it's declined. In this UI, include a
        // "cancel" or "no thanks" button that lets the user continue
        // using your app without granting the permission.
        showInContextUI(...)
    }
    else -> {
        // You can directly ask for the permission.
        requestPermissions(CONTEXT,
                arrayOf(Manifest.permission.REQUESTED_PERMISSION),
                REQUEST_CODE)
    }
}

if (ContextCompat.checkSelfPermission(
        CONTEXT, Manifest.permission.REQUESTED_PERMISSION) ==
        PackageManager.PERMISSION_GRANTED) {
    // You can use the API that requires the permission.
    performAction(...);
} else if (ActivityCompat.shouldShowRequestPermissionRationale(
        this, Manifest.permission.REQUESTED_PERMISSION)) {
    // In an educational UI, explain to the user why your app requires this
    // permission for a specific feature to behave as expected, and what
    // features are disabled if it's declined. In this UI, include a
    // "cancel" or "no thanks" button that lets the user continue
    // using your app without granting the permission.
    showInContextUI(...);
} else {
    // You can directly ask for the permission.
    requestPermissions(CONTEXT,
            new String[] { Manifest.permission.REQUESTED_PERMISSION },
            REQUEST_CODE);
}

Dopo che l'utente risponde alla finestra di dialogo delle autorizzazioni di sistema, il sistema richiama l'implementazione dell'app onRequestPermissionsResult() nella tua app. Il sistema trasmette l'utente alla finestra di dialogo di autorizzazione, nonché al codice di richiesta che hai definito, come mostrato nello snippet di codice riportato di seguito:

override fun onRequestPermissionsResult(requestCode: Int,
        permissions: Array<String>, grantResults: IntArray) {
    when (requestCode) {
        PERMISSION_REQUEST_CODE -> {
            // If request is cancelled, the result arrays are empty.
            if ((grantResults.isNotEmpty() &&
                    grantResults[0] == PackageManager.PERMISSION_GRANTED)) {
                // Permission is granted. Continue the action or workflow
                // in your app.
            } else {
                // Explain to the user that the feature is unavailable because
                // the feature requires a permission that the user has denied.
                // At the same time, respect the user's decision. Don't link to
                // system settings in an effort to convince the user to change
                // their decision.
            }
            return
        }

        // Add other 'when' lines to check for other
        // permissions this app might request.
        else -> {
            // Ignore all other requests.
        }
    }
}

@Override
public void onRequestPermissionsResult(int requestCode, String[] permissions,
        int[] grantResults) {
    switch (requestCode) {
        case PERMISSION_REQUEST_CODE:
            // If request is cancelled, the result arrays are empty.
            if (grantResults.length > 0 &&
                    grantResults[0] == PackageManager.PERMISSION_GRANTED) {
                // Permission is granted. Continue the action or workflow
                // in your app.
            }  else {
                // Explain to the user that the feature is unavailable because
                // the feature requires a permission that the user has denied.
                // At the same time, respect the user's decision. Don't link to
                // system settings in an effort to convince the user to change
                // their decision.
            }
            return;
        }
        // Other 'case' lines to check for other
        // permissions this app might request.
    }
}

Richiedi autorizzazioni posizione

Quando richiedi le autorizzazioni di accesso alla posizione, segui le stesse best practice per qualsiasi altra autorizzazione di runtime. Una differenza importante per quanto riguarda le autorizzazioni di accesso alla posizione è che include più autorizzazioni relative alla posizione. Quali autorizzazioni richiesta e dalle modalità di richiesta, dipendono dai requisiti per le località in base al caso d'uso dell'app.

Posizione in primo piano

Se la tua app contiene una funzionalità che condivide o riceve soltanto informazioni sulla posizione una volta o per un periodo di tempo definito, la funzionalità richiede in primo piano accesso alla posizione. Ecco alcuni esempi:

• All'interno di un'app di navigazione, una funzionalità consente agli utenti di ricevere indicazioni passo passo indicazioni stradali.
• All'interno di un'app di messaggistica, una funzionalità consente agli utenti di condividere la loro posizione attuale con un altro utente.

Il sistema considera che la tua app utilizzi la posizione in primo piano se una funzionalità di l'app accede alla posizione attuale del dispositivo in uno dei seguenti modi situazioni seguenti:

• Un'attività appartenente alla tua app è visibile.

• La tua app esegue un servizio in primo piano. Quando un servizio in primo piano viene il sistema aumenta la consapevolezza degli utenti mostrando una notifica persistente. L'app mantiene l'accesso quando viene posizionata in background, ad esempio quando: l'utente preme il pulsante Home sul proprio dispositivo o ruota il display del dispositivo disattivata.

  Su Android 10 (livello API 29) e versioni successive, devi dichiarare un primo piano tipo di servizio di location, come mostrato nel seguente snippet di codice. Nelle versioni precedenti di Android, ti consigliamo di dichiarare questo tipo di servizio in primo piano.

  <!-- Recommended for Android 9 (API level 28) and lower. -->
  <!-- Required for Android 10 (API level 29) and higher. -->
  <service
      android:name="MyNavigationService"
      android:foregroundServiceType="location" ... >
      <!-- Any inner elements go here. -->
  </service>
  

Dichiari la necessità della posizione in primo piano quando la tua app richiede ACCESS_COARSE_LOCATION autorizzazione o ACCESS_FINE_LOCATION come mostrato nello snippet seguente:

<manifest ... >
  <!-- Include this permission any time your app needs location information. -->
  <uses-permission android:name="android.permission.ACCESS_COARSE_LOCATION" />

  <!-- Include only if your app benefits from precise location access. -->
  <uses-permission android:name="android.permission.ACCESS_FINE_LOCATION" />
</manifest>

Posizione in background

Un'app richiede l'accesso alla posizione in background se una funzionalità all'interno dell'app condivide costantemente la posizione con altri utenti o utilizza il geofencing tramite Google Cloud. Ecco alcuni esempi:

• All'interno di un'app di condivisione della posizione della famiglia, una funzione consente condividere la posizione con i membri del gruppo Famiglia.
• All'interno di un'app IoT, una funzionalità consente agli utenti di configurare i dispositivi per la casa, che disattivino quando l'utente esce di casa e si riaccendano quando l'utente torna alla home page.

Il sistema considera l'app di utilizzare la posizione in background se accede al la posizione attuale del dispositivo in qualsiasi situazione diversa da quella descritta nei posizione in primo piano. La precisione della posizione in background equivale alla precisione della posizione in primo piano, che dipende Le autorizzazioni di accesso alla posizione dichiarate dalla tua app.

Su Android 10 (livello API 29) e versioni successive, devi dichiarare ACCESS_BACKGROUND_LOCATION autorizzazione nel file manifest dell'app per richiedere la posizione in background l'accesso in fase di runtime. Nelle versioni precedenti di Android, quando la tua app riceve l'accesso alla posizione in primo piano, riceve anche l'accesso alla posizione in background.

<manifest ... >
  <!-- Required only when requesting background location access on
       Android 10 (API level 29) and higher. -->
  <uses-permission android:name="android.permission.ACCESS_BACKGROUND_LOCATION" />
</manifest>

Gestire il rifiuto di autorizzazioni

Se l'utente rifiuta una richiesta di autorizzazione, l'app deve aiutare gli utenti a comprendere le implicazioni derivanti dalla negazione di un'autorizzazione. In particolare, la tua app dovrebbe Utenti a conoscenza di funzionalità che non funzionano a causa dell'autorizzazione mancante. Per farlo, tieni presente le seguenti best practice:

• Indirizza l'attenzione dell'utente. Mettere in evidenza una parte specifica dell'UI dell'app in cui le funzionalità sono limitate perché l'app non dispone della funzionalità autorizzazione. Ecco alcuni esempi di ciò che puoi fare:

  • Mostra un messaggio in cui sarebbero stati visualizzati i risultati o i dati dell'elemento.
  • Mostra un pulsante diverso contenente un'icona e un colore di errore.

• Scrivi un titolo specifico. Non mostrare un messaggio generico. Chiarisci invece quali non sono disponibili perché la tua app non dispone dell'autorizzazione necessaria.

• Non bloccare l'interfaccia utente. In altre parole, non mostrare messaggio di avviso a schermo intero che impedisce agli utenti di continuare a utilizzare la tua app .

Allo stesso tempo, la tua app deve rispettare la decisione dell'utente di rifiutare autorizzazione. A partire da Android 11 (livello API 30), se l'utente tocca Rifiuta per un'autorizzazione specifica più di una volta nel corso del ciclo di installazione dell'app su un dispositivo, l'utente non vede la finestra di dialogo delle autorizzazioni di sistema se la tua app richiede di nuovo quell'autorizzazione. L'azione dell'utente implica "Non chiedermelo più". Attivato precedenti, gli utenti vedevano la finestra di dialogo delle autorizzazioni di sistema ogni volta l'app ha richiesto un'autorizzazione, a meno che in precedenza non avesse selezionato "Non chiedere di nuovo" casella di controllo o opzione.

Se un utente nega una richiesta di autorizzazione più di una volta, questa azione viene considerata rifiuto del messaggio. È molto importante chiedere agli utenti le autorizzazioni solo quando devono a una funzionalità specifica, altrimenti potresti perdere inavvertitamente la possibilità per richiedere nuovamente le autorizzazioni.

In alcune situazioni, l'autorizzazione potrebbe essere negata automaticamente, senza il l'utente sta eseguendo una qualsiasi azione. Potrebbe essere concessa un'autorizzazione automaticamente.) È importante non dare per scontato nulla sugli comportamento degli utenti. Ogni volta che l'app deve accedere a funzionalità che richiedono un verifica che alla tua app sia ancora concessa questa autorizzazione.

Per offrire la migliore esperienza utente quando richiedi un'app autorizzazioni, vedi anche Best practice per le autorizzazioni app.

Controlla lo stato del rifiuto durante i test e il debug

Per capire se a un'app sono state negate definitivamente le autorizzazioni (per il debug) e test), utilizza questo comando:

adb shell dumpsys package PACKAGE_NAME

Dove PACKAGE_NAME è il nome del pacchetto da ispezionare.

L'output del comando contiene sezioni simili alla seguente:

...
runtime permissions:
  android.permission.POST_NOTIFICATIONS: granted=false, flags=[ USER_SENSITIVE_WHEN_GRANTED|USER_SENSITIVE_WHEN_DENIED]
  android.permission.ACCESS_FINE_LOCATION: granted=false, flags=[ USER_SET|USER_FIXED|USER_SENSITIVE_WHEN_GRANTED|USER_SENSITIVE_WHEN_DENIED]
  android.permission.BLUETOOTH_CONNECT: granted=false, flags=[ USER_SENSITIVE_WHEN_GRANTED|USER_SENSITIVE_WHEN_DENIED]
...

Le autorizzazioni che sono state negate una volta dall'utente vengono segnalate da USER_SET. Le autorizzazioni che sono state rifiutate in modo permanente selezionando Rifiuta due volte vengono segnalato da USER_FIXED.

Per assicurarti che i tester vedano la finestra di dialogo di richiesta durante il test, reimposta questi flag al termine del debug dell'app. Per farlo, utilizza il comando:

adb shell pm clear-permission-flags PACKAGE_NAME PERMISSION_NAME user-set user-fixed

PERMISSION_NAME è il nome dell'autorizzazione che vuoi resettare.

Per visualizzare un elenco completo delle autorizzazioni app per Android, visita l'API Authorization di riferimento.

Autorizzazioni una tantum

A partire da Android 11 (livello API 30), ogni volta che la tua app richiede un'autorizzazione relative a posizione, microfono o fotocamera, la finestra di dialogo delle autorizzazioni rivolta agli utenti contiene l'opzione Solo questa volta, come mostrato nella figura 2. Se l'utente seleziona questa opzione in alla finestra di dialogo, alla tua app viene concessa un'autorizzazione una tantum temporanea.

L'app può quindi accedere ai relativi dati per un periodo di tempo che dipende da: il comportamento della tua app e le azioni dell'utente:

• Mentre l'attività dell'app è visibile, l'app può accedere ai dati.
• Se l'utente invia la tua app in background, l'app può continuare ad accedervi i dati per un breve periodo di tempo.
• Se avvii un servizio in primo piano mentre l'attività è visibile e l'utente quindi sposta l'app in background, l'app può continuare ad accedere ai dati fino all'arresto del servizio in primo piano.

Il processo dell'app si interrompe quando viene revocata l'autorizzazione

Se l'utente revoca l'autorizzazione una tantum, ad esempio nelle impostazioni di sistema, l'app non può accedere ai dati, anche se hai avviato o meno un primo piano completamente gestito di Google Cloud. Come per qualsiasi autorizzazione, se l'utente revoca l'autorizzazione una tantum l'autorizzazione, il processo della tua app si interrompe.

Quando l'utente apre la tua app e una funzionalità della tua app richiede l'accesso a posizione, microfono o fotocamera, all'utente verrà chiesta nuovamente l'autorizzazione.

Reimposta le autorizzazioni inutilizzate

Android offre diversi modi per reimpostare le autorizzazioni di runtime inutilizzate stato predefinito, negato:

• Un'API che consente di rimuovere l'accesso dell'app in modo proattivo a un'autorizzazione di runtime inutilizzata.
• Un meccanismo di sistema che reimposta le autorizzazioni delle app inutilizzate.

Rimuovere l'accesso delle app

Su Android 13 (livello API 33) e versioni successive, puoi rimuovere l'accesso della tua app a le autorizzazioni di runtime non più richieste dalla tua app. Quando aggiorni l'app, esegui questo passaggio per aumentare le probabilità che gli utenti capiscano perché la tua app continua a richiedere autorizzazioni specifiche. Queste informazioni aiutano a rafforzare la fiducia degli utenti all'interno dell'app.

Per rimuovere l'accesso a un'autorizzazione di runtime, trasmetti il nome dell'autorizzazione in revokeSelfPermissionOnKill() Per rimuovere contemporaneamente l'accesso a un gruppo di autorizzazioni di runtime, passa un di nomi di autorizzazioni revokeSelfPermissionsOnKill() La procedura di rimozione delle autorizzazioni avviene in modo asincrono e termina tutti i processi. associati all'UID dell'app.

Per consentire al sistema di rimuovere l'accesso dell'app alle autorizzazioni, devono i processi legati alla tua app devono essere terminati. Quando chiami l'API, il sistema determina quando è sicuro terminare questi processi. Di solito, il sistema attende Finché la tua app non trascorre un lungo periodo di tempo in esecuzione in background anziché in primo piano.

Per informare l'utente che la tua app non richiede più l'accesso a un runtime specifico autorizzazioni, mostra una finestra di dialogo al successivo avvio dell'app. Questa finestra di dialogo può includere l'elenco delle autorizzazioni.

Reimposta automaticamente le autorizzazioni delle app inutilizzate

Se la tua app ha come target Android 11 (livello API 30) o versioni successive e non viene utilizzata mesi, il sistema protegge i dati utente reimpostando automaticamente i dati autorizzazioni di runtime concesse dall'utente alla tua app. Scopri di più nella guida sulla ibernazione delle app.

Richiedi di diventare il gestore predefinito, se necessario

Alcune app dipendono dall'accesso a informazioni sensibili dell'utente relative ai registri chiamate e SMS. Se vuoi richiedere autorizzazioni specifiche per i registri chiamate e SMS e pubblicare la tua app sul Play Store, devi inserire all'utente di impostare l'app come gestore predefinito per una funzione di sistema di base prima richiedendo queste autorizzazioni di runtime.

Per ulteriori informazioni sui gestori predefiniti, incluse le indicazioni sulla visualizzazione di un richiesta relativa al gestore predefinito per gli utenti, consulta la guida sulle autorizzazioni utilizzate solo in e gestori predefiniti.

Concedi tutte le autorizzazioni di runtime a scopo di test

Per concedere automaticamente tutte le autorizzazioni di runtime quando installi un'app su un emulatore o dispositivo di test, usa l'opzione -g per adb shell install come mostrato nello snippet di codice riportato di seguito:

adb shell install -g PATH_TO_APK_FILE

Risorse aggiuntive

Per ulteriori informazioni sulle autorizzazioni, leggi questi articoli:

• Panoramica delle autorizzazioni
• Best practice per le autorizzazioni app

Per scoprire di più sulla richiesta di autorizzazioni, consulta le esempi di autorizzazioni

Puoi anche completare questo codelab che dimostra la migliore privacy possibile pratiche.