Richiedi autorizzazioni di runtime

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

Se dichiari autorizzazioni pericolose e se la tua app è installata su un dispositivo con Android 6.0 (livello API 23) o versioni successive, devi richiedere le autorizzazioni pericolose in fase di runtime seguendo i passaggi descritti 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 concesse automaticamente e non devi completare nessuno dei passaggi rimanenti in questa pagina.

Principi di base

I principi di base per richiedere le autorizzazioni in fase di runtime sono i seguenti:

• Chiedi un'autorizzazione nel contesto, quando l'utente inizia a interagire con la funzionalità che la richiede.
• Non bloccare l'utente. Fornisci sempre l'opzione per annullare un flusso dell'interfaccia utente didattica, ad esempio un flusso che spiega la logica alla base della richiesta di autorizzazioni.
• Se l'utente nega o revoca un'autorizzazione necessaria per una funzionalità, applica la riduzione controllata per la tua app in modo che l'utente possa continuare a usarla, magari disattivando la funzionalità che richiede l'autorizzazione.
• Non dare per scontato alcun comportamento del sistema. Ad esempio, non dare per scontato che le autorizzazioni vengano visualizzate nello stesso gruppo di autorizzazioni. Un gruppo di autorizzazioni aiuta semplicemente il sistema a ridurre al minimo il numero di finestre di dialogo di sistema presentate all'utente quando un'app richiede autorizzazioni strettamente correlate.

Workflow per la richiesta di autorizzazioni

Prima di dichiarare e richiedere autorizzazioni di runtime nella tua app, valuta se la tua app deve farlo. Puoi soddisfare molti casi d'uso nella tua app, ad esempio scattare foto, mettere in pausa la riproduzione dei contenuti multimediali e mostrare annunci pertinenti, senza dover dichiarare alcuna autorizzazione.

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

1. Nel file manifest della tua app, dichiara le autorizzazioni che la tua app potrebbe dover richiedere.
2. Progetta l'esperienza utente della tua app in modo che azioni specifiche nell'app siano associate a permessi di runtime specifici. Comunica agli utenti quali azioni potrebbero richiedere loro di concedere l'autorizzazione alla tua app per accedere ai dati privati degli utenti.
3. Attendi che l'utente richiami l'attività o l'azione nella tua app che richiede l'accesso a dati utente privati specifici. A quel punto, la tua app può richiedere l'autorizzazione di runtime necessaria per accedere a questi dati.

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

   Devi verificare di disporre di un'autorizzazione ogni volta che esegui un'operazione che la richiede.

5. Controlla se la tua app deve mostrare una motivazione all'utente, spiegando perché la tua app ha bisogno che l'utente conceda una determinata autorizzazione di runtime. Se il sistema determina che la tua app non deve mostrare una motivazione, continua direttamente al passaggio successivo, senza mostrare un elemento dell'interfaccia utente.

   Se il sistema determina che la tua app deve mostrare una motivazione, presenta la motivazione all'utente in un elemento UI. In questa motivazione, spiega chiaramente a quali dati la tua app sta cercando di accedere e quali vantaggi l'app può fornire all'utente se concede l'autorizzazione di runtime. Dopo che l'utente ha preso atto della motivazione, continua con il passaggio successivo.

6. Richiedi l'autorizzazione di runtime necessaria alla tua app per accedere ai dati utente privati. Il sistema mostra una richiesta di autorizzazione di runtime, come quella mostrata nella pagina di panoramica delle autorizzazioni.

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

8. Se l'utente ha concesso l'autorizzazione alla tua app, puoi accedere ai dati privati dell'utente. Se invece l'utente ha negato l'autorizzazione, riduci gradualmente l'esperienza della tua app in modo che fornisca funzionalità all'utente senza le informazioni protette da questa autorizzazione.

La figura 1 illustra il flusso di lavoro e l'insieme di decisioni associati a questo processo:

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

Per verificare se l'utente ha già concesso alla tua app una determinata autorizzazione, passa questa autorizzazione al metodo ContextCompat.checkSelfPermission(). Questo metodo restituisce PERMISSION_GRANTED o PERMISSION_DENIED, a seconda che la tua app disponga dell'autorizzazione.

Spiega il motivo per cui la tua app ha bisogno dell'autorizzazione

La finestra di dialogo delle autorizzazioni mostrata dal sistema quando chiami requestPermissions() indica l'autorizzazione che la tua app vuole, ma non il motivo. In alcuni casi, l'utente potrebbe trovare la cosa sconcertante. È una buona idea spiegare all'utente perché la tua app richiede le autorizzazioni prima di chiamare requestPermissions().

Le ricerche dimostrano che gli utenti si sentono molto più a loro agio con le richieste di autorizzazione se sanno perché l'app le richiede, ad esempio se l'autorizzazione è necessaria per supportare una funzionalità principale dell'app o per la pubblicità. Di conseguenza, se utilizzi solo una frazione delle chiamate API che rientrano in un gruppo di autorizzazioni, è utile elencare esplicitamente quali di queste autorizzazioni utilizzi e perché. Ad esempio, se utilizzi solo la posizione approssimativa, comunicalo all'utente nella descrizione dell'app o negli articoli della Guida relativi alla tua app.

In determinate condizioni, è anche utile informare gli utenti dell'accesso ai dati sensibili in tempo reale. Ad esempio, se accedi alla fotocamera o al microfono, è consigliabile informare l'utente utilizzando un'icona di notifica in un punto qualsiasi dell'app o nella barra delle notifiche (se l'applicazione è in esecuzione in background), in modo che non sembri che tu stia raccogliendo dati di nascosto.

In definitiva, se devi richiedere un'autorizzazione per far funzionare qualcosa nella tua app, ma il motivo non è chiaro all'utente, trova un modo per comunicare all'utente perché hai bisogno delle autorizzazioni più sensibili.

Se il metodo ContextCompat.checkSelfPermission() restituisce PERMISSION_DENIED, chiama shouldShowRequestPermissionRationale(). Se questo metodo restituisce true, mostra all'utente una UI didattica. In questa UI, descrivi il motivo per cui la funzionalità che l'utente vuole attivare richiede una determinata autorizzazione.

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

Richiedi autorizzazioni

Dopo che l'utente visualizza un'interfaccia utente didattica o il valore restituito di shouldShowRequestPermissionRationale() indica che non è necessario mostrare un'interfaccia utente didattica, richiedi l'autorizzazione. Gli utenti vedono una finestra di dialogo con le autorizzazioni di sistema, in cui possono scegliere se concedere una determinata autorizzazione alla tua app.

A questo scopo, utilizza il contratto RequestPermission, incluso in una libreria AndroidX, in cui consenti al sistema di gestire il codice di richiesta di autorizzazione per te. Poiché l'utilizzo del contratto RequestPermission semplifica la logica, è la soluzione consigliata quando possibile. Tuttavia, se necessario, puoi anche gestire autonomamente un codice di richiesta nell'ambito della richiesta di autorizzazione e includere questo codice di richiesta nella logica di callback dell'autorizzazione.

Consenti al sistema di gestire il codice di richiesta di autorizzazione

Per consentire al sistema di gestire il codice di richiesta associato a una richiesta di autorizzazioni, aggiungi dipendenze alle seguenti librerie nel file build.gradle del modulo:

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

Puoi quindi utilizzare una delle seguenti classi:

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

I seguenti passaggi mostrano come utilizzare il contratto RequestPermission. Il processo è quasi identico per il contratto RequestMultiplePermissions.

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

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

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

   Dopo la chiamata a launch(), viene visualizzata la finestra di dialogo delle autorizzazioni di sistema. Quando l'utente fa una scelta, il sistema richiama in modo asincrono l'implementazione 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 maggiori informazioni o contesto all'utente, modifica l'interfaccia utente della tua app in modo che sia più facile per gli utenti capire perché una funzionalità della tua app ha bisogno di una determinata autorizzazione. Ad esempio, puoi modificare il testo nel pulsante che attiva la funzionalità.

   Inoltre, il testo nella finestra di dialogo delle autorizzazioni di sistema fa riferimento al gruppo di autorizzazioni associato all'autorizzazione che hai richiesto. Questo raggruppamento di autorizzazioni è progettato per la facilità d'uso del sistema e la tua app non deve fare affidamento sul fatto che le autorizzazioni si trovino all'interno o all'esterno di un gruppo di autorizzazioni specifico.

Il seguente snippet di codice mostra come gestire la risposta 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 un'autorizzazione e per richiederla 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 di richiesta di autorizzazione

In alternativa a consentire al sistema di gestire il codice della richiesta di autorizzazione, puoi gestire autonomamente il codice della richiesta di autorizzazione. Per farlo, includi il codice della 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 ha risposto alla finestra di dialogo delle autorizzazioni di sistema, il sistema richiama l'implementazione della tua app di onRequestPermissionsResult(). Il sistema passa la risposta dell'utente alla finestra di dialogo delle autorizzazioni, nonché il codice di richiesta che hai definito, come mostrato nello snippet di codice seguente:

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.
    }
}

Richiedere le autorizzazioni di accesso alla posizione

Quando richiedi le autorizzazioni di accesso alla posizione, segui le stesse best practice previste per qualsiasi altra autorizzazione di runtime. Una differenza importante per quanto riguarda le autorizzazioni di localizzazione è che il sistema include più autorizzazioni correlate alla posizione. Le autorizzazioni che richiedi e la modalità di richiesta dipendono dai requisiti di localizzazione per il caso d'uso della tua app.

Posizione in primo piano

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

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

Il sistema considera la tua app come se utilizzasse la posizione in primo piano se una funzionalità della tua app accede alla posizione attuale del dispositivo in una delle seguenti situazioni:

• È visibile un'attività che appartiene alla tua app.

• La tua app esegue un servizio in primo piano. Quando un servizio in primo piano è in esecuzione, il sistema aumenta la consapevolezza dell'utente mostrando una notifica persistente. L'app mantiene l'accesso quando viene messa in background, ad esempio quando l'utente preme il pulsante Home sul dispositivo o spegne il display del dispositivo.

  Su Android 10 (livello API 29) e versioni successive, devi dichiarare un tipo di servizio in primo piano 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 l'autorizzazione ACCESS_COARSE_LOCATION o l'autorizzazione ACCESS_FINE_LOCATION, come mostrato nel seguente snippet:

<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 l'API Geofencing. Ecco alcuni esempi:

• All'interno di un'app di condivisione della posizione con il gruppo Famiglia, una funzionalità consente agli utenti di condividere continuamente 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 in modo che si spengano quando l'utente esce di casa e si riaccendano quando rientra.

Il sistema considera che la tua app utilizzi la posizione in background se accede alla posizione attuale del dispositivo in qualsiasi situazione diversa da quelle descritte nella sezione Posizione in primo piano. La precisione della localizzazione in background è la stessa della precisione della localizzazione in primo piano, che dipende dalle autorizzazioni di accesso alla posizione dichiarate dall'app.

Su Android 10 (livello API 29) e versioni successive, devi dichiarare l'autorizzazione ACCESS_BACKGROUND_LOCATION nel file manifest della tua app per richiedere l'accesso alla posizione in background in fase di runtime. Nelle versioni precedenti di Android, quando la tua app riceve l'accesso alla posizione in primo piano, riceve automaticamente 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 autorizzazione

Se l'utente nega una richiesta di autorizzazione, la tua app deve aiutarlo a comprendere le implicazioni del rifiuto dell'autorizzazione. In particolare, la tua app deve informare gli utenti delle funzionalità che non funzionano a causa dell'autorizzazione mancante. Quando lo fai, tieni presente le seguenti best practice:

• Guida l'attenzione dell'utente. Evidenzia una parte specifica dell'interfaccia utente della tua app in cui la funzionalità è limitata perché l'app non dispone dell'autorizzazione necessaria. Ecco alcuni esempi di ciò che potresti fare:

  • Mostra un messaggio nel punto in cui sarebbero apparsi i risultati o i dati della funzionalità.
  • Mostra un pulsante diverso che contiene un'icona e un colore di errore.

• Fornisci informazioni specifiche. Non visualizzare un messaggio generico. Indica chiaramente quali funzionalità non sono disponibili perché la tua app non dispone dell'autorizzazione necessaria.

• Non bloccare l'interfaccia utente. In altre parole, non mostrare un 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 negare un'autorizzazione. A partire da Android 11 (livello API 30), se l'utente tocca Nega per un'autorizzazione specifica più di una volta durante il ciclo di vita dell'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 l'autorizzazione. L'azione dell'utente implica "non chiedere più". Nelle versioni precedenti, gli utenti vedevano la finestra di dialogo delle autorizzazioni di sistema ogni volta che la tua app richiedeva un'autorizzazione, a meno che non avessero selezionato in precedenza una casella di controllo o un'opzione "Non chiedere di nuovo".

Se un utente rifiuta una richiesta di autorizzazione più di una volta, il rifiuto viene considerato definitivo. È molto importante richiedere le autorizzazioni agli utenti solo quando hanno bisogno dell'accesso a una funzionalità specifica, altrimenti potresti perdere inavvertitamente la possibilità di richiedere nuovamente le autorizzazioni.

In determinate situazioni, l'autorizzazione potrebbe essere negata automaticamente, senza che l'utente intraprenda alcuna azione. Un'autorizzazione potrebbe essere concessa automaticamente. È importante non dare per scontato nulla sul comportamento automatico. Ogni volta che la tua app deve accedere a funzionalità che richiedono un'autorizzazione, verifica che l'autorizzazione sia ancora concessa.

Per offrire la migliore esperienza utente quando chiedi le autorizzazioni dell'app, consulta anche Best practice per le autorizzazioni delle app.

Controllare lo stato di rifiuto durante i test e il debug

Per identificare se a un'app sono state negate definitivamente le autorizzazioni (a scopo di debug e test), utilizza il seguente comando:

adb shell dumpsys package PACKAGE_NAME

Dove PACKAGE_NAME è il nome del pacchetto da esaminare.

L'output del comando contiene sezioni simili a queste:

...
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 negate una volta dall'utente vengono contrassegnate da USER_SET. Le autorizzazioni che sono state rifiutate definitivamente selezionando Rifiuta due volte sono contrassegnate da USER_FIXED.

Per assicurarti che i tester vedano la finestra di dialogo della 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 reimpostare.

Per visualizzare un elenco completo delle autorizzazioni app per Android, visita la pagina di riferimento dell'API Permissions.

Autorizzazioni una tantum

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

La tua app può quindi accedere ai dati correlati per un periodo di tempo che dipende dal comportamento dell'app e dalle azioni dell'utente:

• Mentre l'attività dell'app è visibile, l'app può accedere ai dati.
• Se l'utente invia la tua app in background, questa può continuare ad accedere ai dati per un breve periodo di tempo.
• Se avvii un servizio in primo piano mentre l'attività è visibile e l'utente sposta l'app in background, l'app può continuare ad accedere ai dati finché il servizio in primo piano non si arresta.

Il processo dell'app termina quando l'autorizzazione viene revocata

Se l'utente revoca l'autorizzazione una tantum, ad esempio nelle impostazioni di sistema, la tua app non può accedere ai dati, indipendentemente dal fatto che tu abbia avviato un servizio in primo piano. Come per qualsiasi autorizzazione, se l'utente revoca l'autorizzazione una tantum della tua app, il processo dell'app termina.

La prossima volta che l'utente apre la tua app e una funzionalità dell'app richiede l'accesso a posizione, microfono o fotocamera, all'utente viene chiesto di nuovo di concedere l'autorizzazione.

Reimposta le autorizzazioni inutilizzate

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

• Un'API in cui puoi rimuovere in modo proattivo l'accesso della tua app a un'autorizzazione di runtime inutilizzata.
• Un meccanismo di sistema che reimposta automaticamente le autorizzazioni delle app inutilizzate.

Rimuovere l'accesso alle app

Su Android 13 (livello API 33) e versioni successive, puoi rimuovere l'accesso della tua app alle autorizzazioni di runtime che non sono più necessarie. Quando aggiorni la tua app, esegui questo passaggio in modo che gli utenti comprendano più facilmente perché la tua app continua a richiedere autorizzazioni specifiche. Queste conoscenze contribuiscono a creare fiducia degli utenti nella tua app.

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

Affinché il sistema rimuova l'accesso dell'app alle autorizzazioni, tutti i processi associati all'app devono essere interrotti. Quando chiami l'API, il sistema determina quando è sicuro terminare questi processi. In genere, il sistema attende che l'app trascorra un periodo di tempo prolungato in esecuzione in background anziché in primo piano.

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

Reimpostare 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 per alcuni mesi, il sistema protegge i dati dell'utente reimpostando automaticamente le autorizzazioni di runtime sensibili che l'utente aveva concesso alla tua app. Scopri di più nella guida sull'ibernazione delle app.

Richiedere di diventare il gestore predefinito, se necessario

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

Per ulteriori informazioni sui gestori predefiniti, incluse le indicazioni su come mostrare agli utenti un prompt del gestore predefinito, consulta la guida sulle autorizzazioni utilizzate solo nei 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 un dispositivo di test, utilizza l'opzione -g per il comando adb shell install, come illustrato nel seguente snippet di codice:

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 gli esempi di autorizzazioni.

Puoi anche completare questo codelab che illustra le best practice per la privacy.