Richiedere autorizzazioni speciali

Un'autorizzazione speciale protegge l'accesso alle risorse di sistema particolarmente sensibili o non direttamente correlate alla privacy dell'utente. Queste autorizzazioni sono diverse dalle autorizzazioni di installazione e dalle autorizzazioni di runtime.

Ecco alcuni esempi di autorizzazioni speciali:

• Programmazione di sveglie esatte.
• Visualizzazione e disegno sopra altre app.
• Accesso a tutti i dati di archiviazione.

Le app che dichiarano un'autorizzazione speciale vengono mostrate nella pagina Accesso speciale per le app nelle impostazioni di sistema (figura 1). Per concedere un'autorizzazione speciale all'app, un utente deve visitare questa pagina: Impostazioni > App > Accesso speciale per le app.

Flusso di lavoro

Per richiedere un'autorizzazione speciale:

1. Nel file manifest dell'app, dichiara le autorizzazioni speciali che l'app potrebbe dover richiedere.
2. Progetta l'esperienza utente della tua app in modo che azioni specifiche siano associate a autorizzazioni speciali specifiche. Comunica agli utenti quali azioni potrebbero richiedere la concessione dell'autorizzazione per consentire alla tua app di accedere ai dati utente privati.
3. Attendi che l'utente richiami la task o l'azione nella tua app che richiede l'accesso a dati privati specifici dell'utente. A quel punto, l'app può richiedere l'autorizzazione speciale necessaria per accedere a questi dati.
4. Verifica se l'utente ha già concesso l'autorizzazione speciale richiesta dalla tua app. Per farlo, utilizza la funzione di controllo personalizzato di ogni autorizzazione. Se concessa, la tua app può accedere ai dati privati dell'utente. In caso contrario, vai al passaggio successivo. Nota: devi verificare di disporre dell'autorizzazione ogni volta che esegui un'operazione che la richiede.
5. Fornisci una motivazione all'utente in un elemento dell'interfaccia utente che spieghi chiaramente a quali dati sta tentando di accedere la tua app e quali vantaggi può offrire all'utente se concede l'autorizzazione speciale. Inoltre, poiché la tua app invia gli utenti alle impostazioni di sistema per concedere l'autorizzazione, includi anche brevi istruzioni che spieghino come gli utenti possono concederla. L'interfaccia utente della motivazione deve fornire all'utente un'opzione chiara per disattivare la concessione dell'autorizzazione. Dopo che l'utente ha confermato il ragionamento, vai al passaggio successivo.
6. Richiedi l'autorizzazione speciale necessaria per l'accesso ai dati privati dell'utente. Probabilmente si tratta di un'intent alla pagina corrispondente nelle impostazioni di sistema in cui l'utente può concedere l'autorizzazione. A differenza delle autorizzazioni di runtime, non è presente nessuna finestra di dialogo popup per le autorizzazioni.
7. Controlla la risposta dell'utente, che ha scelto di concedere o negare l'autorizzazione speciale, nel metodo onResume().
8. Se l'utente ha concesso l'autorizzazione alla tua app, puoi accedere ai suoi dati privati. Se invece l'utente ha negato l'autorizzazione, riduci gradualmente la tua esperienza con l'app in modo da fornire all'utente la funzionalità senza le informazioni protette da quell'autorizzazione.

Richiedere autorizzazioni speciali

A differenza delle autorizzazioni di runtime, l'utente deve concedere le autorizzazioni speciali dalla pagina Accesso speciale per le app nelle impostazioni di sistema. Le app possono inviare gli utenti lì utilizzando un'intent, che mette in pausa l'app e avvia la pagina delle impostazioni corrispondente per una determinata autorizzazione speciale. Quando l'utente torna nell'app, l'app può controllare se l'autorizzazione è stata concessa nella funzione onResume().

Il seguente codice di esempio mostra come richiedere agli utenti l'autorizzazione speciale SCHEDULE_EXACT_ALARMS:

val alarmManager = getSystemService<AlarmManager>()!!
when {
   // if permission is granted, proceed with scheduling exact alarms…
   alarmManager.canScheduleExactAlarms() -> {
       alarmManager.setExact(...)
   }
   else -> {
       // ask users to grant the permission in the corresponding settings page
       startActivity(Intent(ACTION_REQUEST_SCHEDULE_EXACT_ALARM))
   }
}

Codice di esempio per controllare l'autorizzazione e gestire le decisioni dell'utente in onResume():

override fun onResume() {
   // ...

   if (alarmManager.canScheduleExactAlarms()) {
       // proceed with the action (setting exact alarms)
       alarmManager.setExact(...)
   }
   else {
       // permission not yet approved. Display user notice and gracefully degrade
       your app experience.
       alarmManager.setWindow(...)
   }
}

Best practice e suggerimenti

Le sezioni seguenti forniscono alcune best practice e considerazioni per la richiesta di autorizzazioni speciali.

Ogni autorizzazione ha il proprio metodo di controllo

Le autorizzazioni speciali funzionano in modo diverso rispetto alle autorizzazioni di runtime. In alternativa, consulta la pagina di riferimento dell'API per le autorizzazioni e utilizza le funzioni di controllo dell'accesso personalizzato per ogni autorizzazione speciale. Alcuni esempi sono AlarmManager#canScheduleExactAlarms() per la permissione SCHEDULE_EXACT_ALARMS e Environment#isExternalStorageManager() per la permissione MANAGE_EXTERNAL_STORAGE.

Richiesta in contesto

Analogamente alle autorizzazioni di runtime, le app devono richiedere autorizzazioni speciali in-context quando l'utente richiede un'azione specifica che richiede l'autorizzazione. Ad esempio, attendi di richiedere l'autorizzazione SCHEDULE_EXACT_ALARMSfinché l'utente non pianifica l'invio di un'email a un'ora specifica.

Spiega la richiesta

Fornisci una motivazione prima di reindirizzare alle impostazioni di sistema. Poiché gli utenti abbandonano temporaneamente l'app per concedere autorizzazioni speciali, mostra un'interfaccia utente in-app prima di avviare l'intent alla pagina Accesso speciale per le app nelle impostazioni di sistema. Questa UI deve spiegare chiaramente perché l'app ha bisogno dell'autorizzazione e come l'utente deve concederla nella pagina delle impostazioni.