keywords: wear, permissions, collection_guideslandingwear image_path: images/training/wear/multiple_permissions.png
La richiesta di autorizzazioni su Wear OS è simile alla richiesta di autorizzazioni nelle app mobile, con un paio di casi d'uso aggiuntivi. Questo documento presuppone che tu abbia compreso come funzionano le autorizzazioni Android. In caso contrario, consulta come funzionano le autorizzazioni su Android.
Come in un'app mobile, l'utente deve concedere le autorizzazioni a un'app Wear per accedere a determinate funzionalità. Nelle tue app per Wear, fornisci funzionalità significative senza richiedere autorizzazioni.
Scenari di autorizzazione
Esistono diversi scenari che potresti riscontrare quando richiedi autorizzazioni pericolose su Wear OS:
L'app Wear richiede autorizzazioni per un'app in esecuzione sul dispositivo indossabile.
L'app Wear richiede autorizzazioni per un'app in esecuzione sullo smartphone.
L'app Telefono richiede autorizzazioni per un'app in esecuzione sul dispositivo indossabile.
L'app Telefono richiede più autorizzazioni che possono essere utilizzate solo quando il dispositivo indossabile è connesso.
Per vedere tutti questi scenari in un'app funzionante, esamina l'esempio ExerciseSampleCompose su GitHub.
Le sezioni seguenti spiegano ciascuno di questi scenari. Per informazioni più dettagliate sulla richiesta di autorizzazioni, consulta la sezione Pattern di richiesta di autorizzazione.
L'app Wear richiede l'autorizzazione per il dispositivo indossabile
Quando l'app Wear richiede un'autorizzazione per un'app in esecuzione sul dispositivo indossabile, il sistema mostra una finestra di dialogo per chiedere all'utente di concedere l'autorizzazione. Nella tua app, richiedi le autorizzazioni solo quando è chiaro all'utente perché sono necessarie per eseguire una determinata operazione.
Esamina i principi relativi alle autorizzazioni per assicurarti di offrire la migliore esperienza agli utenti e ricordati di selezionare shouldShowRequestPermissionRationale()
e di fornire informazioni aggiuntive, se necessario.
Se un'app o un quadrante richiede più di un'autorizzazione alla volta, le richieste di autorizzazione vengono visualizzate una dopo l'altra.
L'app Wear richiede l'autorizzazione di accesso al telefono
Quando l'app Wear richiede un'autorizzazione per lo smartphone, ad esempio un'app per dispositivi indossabili vuole accedere a foto o altri dati sensibili nella versione mobile dell'app, l'app Wear deve inviare l'utente allo smartphone per accettare l'autorizzazione. L'app per smartphone può fornire all'utente informazioni aggiuntive utilizzando un'attività. Nell'attività, includi due pulsanti: uno per concedere l'autorizzazione e uno per negarla.
L'app Telefono richiede l'autorizzazione per il dispositivo indossabile
Se l'utente è in un'app per smartphone e l'app richiede un'autorizzazione per il dispositivo indossabile, ad esempio per precaricare la musica nel caso in cui lo smartphone si disconnetta, l'app per smartphone indirizza l'utente al dispositivo indossabile per accettare l'autorizzazione. La versione per il dispositivo indossabile dell'app utilizza il metodo requestPermissions()
per attivare la finestra di dialogo delle autorizzazioni di sistema.
L'app Telefono richiede più autorizzazioni contemporaneamente
Le app partner su Android 12 (livello API 31) e versioni successive possono utilizzare i profili dei dispositivi complementari quando si connettono a uno smartwatch. L'utilizzo di un profilo semplifica la procedura di registrazione aggregando la concessione di un insieme di autorizzazioni specifiche per tipo di dispositivo in un unico passaggio.
Le autorizzazioni in bundle vengono concesse all'app complementare una volta che il dispositivo si connette e rimangono valide solo finché il dispositivo è associato. Le autorizzazioni vengono rimosse se elimini l'app o se rimuovi l'associazione. Per maggiori dettagli, consulta
AssociationRequest.Builder.setDeviceProfile()
.
Pattern di richieste di autorizzazione
Esistono diversi pattern per richiedere le autorizzazioni agli utenti. In ordine di priorità, sono:
Chiedi nel contesto quando l'autorizzazione è ovviamente necessaria per una funzionalità specifica, ma non è necessaria per l'esecuzione dell'app nel suo complesso.
Fornisci informazioni contestuali quando il motivo della richiesta dell'autorizzazione non è evidente e l'autorizzazione non è necessaria per il funzionamento dell'app nel suo complesso.
Questi pattern sono descritti nelle sezioni seguenti.
Chiedi nel contesto
Richiedi le autorizzazioni quando è chiaro all'utente perché è necessaria per eseguire una determinata operazione. Gli utenti sono più propensi a concedere un'autorizzazione quando comprendono il suo collegamento alla funzionalità che vogliono utilizzare.
Ad esempio, un'app potrebbe richiedere la posizione dell'utente per mostrare luoghi di interesse nelle vicinanze. Quando l'utente tocca per cercare luoghi nelle vicinanze, l'app può richiedere immediatamente l'autorizzazione di accesso alla posizione perché esiste una relazione chiara tra la ricerca di luoghi nelle vicinanze e la necessità dell'autorizzazione di accesso alla posizione. L'ovvietà di questa relazione rende superfluo per l'app mostrare schermate informative aggiuntive.
Fornire formazione contestuale
La figura 6 mostra un esempio di istruzione contestuale. L'app non richiede autorizzazioni per avviare il timer, ma un avviso didattico in linea indica che la parte dell'attività relativa al rilevamento della posizione è bloccata. Quando l'utente tocca il prompt, viene visualizzata una schermata di richiesta di autorizzazione che consente di sbloccare il rilevamento della posizione.
Utilizza il metodo
shouldShowRequestPermissionRationale()
per aiutare la tua app a decidere se fornire ulteriori informazioni. Per maggiori dettagli, vedi Richiedere le autorizzazioni per le app. In alternativa, puoi esaminare come l'applicazione di esempio per lo speaker su GitHub gestisce la visualizzazione delle informazioni.
Gestire il rifiuto
Se l'utente nega un'autorizzazione richiesta che non è fondamentale per un'attività prevista, non impedirgli di continuare l'attività. Se alcune parti dell'attività sono disattivate dall'autorizzazione negata, fornisci un feedback visivo e utile.
La Figura 7 mostra l'utilizzo di un'icona a forma di lucchetto per indicare che una funzionalità è bloccata perché l'utente non ha concesso l'autorizzazione per utilizzarla.
Quando una finestra di dialogo di autorizzazione per il dispositivo indossabile negata in precedenza viene visualizzata una seconda volta, include l'opzione Rifiuta, non mostrare di nuovo. Se l'utente sceglie questa opzione, l'unico modo per concedere questa autorizzazione in futuro è accedere all'app Impostazioni del wearable.
Scopri di più su come gestire il rifiuto dell'autorizzazione.
Autorizzazioni per i servizi
Solo un'attività può chiamare il metodo
requestPermissions()
, quindi se l'utente interagisce con la tua app utilizzando un servizio, ad esempio tramite un quadrante, il servizio deve aprire un'attività prima di richiedere l'autorizzazione. In questa attività, fornisci ulteriori informazioni sul motivo per cui è necessaria l'autorizzazione.
In generale, non richiedere autorizzazioni per un quadrante. Implementa invece una complicazione e lascia che sia l'utente a scegliere quali dati visualizzare tramite la complicazione.
Impostazioni
Un utente può modificare le autorizzazioni di un'app Wear in Impostazioni in qualsiasi momento. Quando l'utente tenta di eseguire un'azione che richiede un'autorizzazione, chiama prima il metodo checkSelfPermission()
per verificare se l'app ha l'autorizzazione per eseguire l'operazione.
Esegui questo controllo anche se l'utente ha precedentemente concesso l'autorizzazione, perché potrebbe averla revocata in un secondo momento.
Consigliati per te
- Nota: il testo del link viene visualizzato quando JavaScript è disattivato
- Richiedere le autorizzazioni di runtime
- Autorizzazioni Bluetooth
- Comunicare in background