Demander des autorisations sur Wear OS

keywords: wear, permissions, collection_guideslandingwear image_path: images/training/wear/multiple_permissions.png

Le processus de demande d'autorisations sur Wear OS est semblable à celui utilisé dans les applications mobiles, avec quelques cas d'utilisation supplémentaires. Dans ce document, nous partons du principe que vous connaissez déjà le fonctionnement des autorisations Android. Si ce n'est pas le cas, rendez-vous sur la page traitant du fonctionnement des autorisations sur Android.

Comme dans une application mobile, l'utilisateur doit accorder des autorisations à une application Wear pour accéder à certaines fonctionnalités. Dans vos applications Wear, certaines fonctionnalités importantes doivent être accessibles sans demander d'autorisation.

Scénarios d'autorisation

Vous pouvez être confronté à plusieurs scénarios lorsque vous demandez des autorisations dangereuses sur Wear OS :

  • L'application Wear demande des autorisations pour une application exécutée sur l'accessoire connecté.

  • L'application Wear demande des autorisations pour une application exécutée sur le téléphone.

  • L'application pour téléphone demande des autorisations pour une application exécutée sur l'accessoire connecté.

  • L'application pour téléphone demande plusieurs autorisations qui peuvent uniquement être utilisées lorsque l'accessoire est connecté.

Pour voir tous ces scénarios dans une application opérationnelle, consultez l'exemple ExerciseSampleCompose sur GitHub.

Vous trouverez une explication des différents scénarios dans les sections suivantes. Pour en savoir plus sur la demande d'autorisations, consultez la section Modèles de demande d'autorisation.

L'application Wear demande une autorisation "wearable"

Lorsque l'application Wear demande une autorisation pour une application exécutée sur l'objet connecté, le système affiche une boîte de dialogue invitant l'utilisateur à accorder cette autorisation. Dans votre application, demandez uniquement des autorisations lorsque l'utilisateur comprend clairement pourquoi elles sont nécessaires à une opération donnée.

Consultez les principes d'autorisation pour vous assurer de fournir une expérience optimale à vos utilisateurs, et n'oubliez pas de vérifier shouldShowRequestPermissionRationale() et de fournir des informations supplémentaires si nécessaire.

Si une application ou un cadran nécessitent plusieurs autorisations à la fois, les demandes d'autorisation apparaissent les unes après les autres.

Affichage de plusieurs écrans d'autorisation successifs.
Figure 1. Affichage d'écrans d'autorisation successifs

L'application Wear demande l'autorisation d'accéder au téléphone

Lorsque l'application Wear demande l'autorisation d'accéder au téléphone (par exemple, une application connectée souhaite accéder à des photos ou à d'autres données sensibles sur la version mobile de l'application), elle doit rediriger l'utilisateur vers le téléphone pour qu'il accepte l'autorisation en question. L'application pour téléphone peut alors fournir des informations supplémentaires à l'utilisateur à l'aide d'une activité. Dans l'activité, incluez deux boutons : un pour accorder l'autorisation et un pour la refuser.

L'application Wear redirige l'utilisateur vers le téléphone pour qu'il accorde l'autorisation.
Figure 2. L'utilisateur est redirigé vers le téléphone pour accorder l'autorisation

L'application pour téléphone demande l'autorisation "wearable"

Si une application pour téléphone a besoin d'une autorisation "wearable" (par exemple, pour précharger de la musique au cas où le téléphone serait déconnecté), elle redirige l'utilisateur vers l'accessoire connecté pour qu'il accepte cette autorisation. La version de l'application pour accessoires connectés utilise la méthode requestPermissions() pour déclencher l'affichage de la boîte de dialogue des autorisations système.

L'application pour téléphone redirige l'utilisateur vers l'accessoire connecté pour qu'il accorde l'autorisation.
Figure 3. L'utilisateur est redirigé vers l'accessoire connecté pour accorder l'autorisation

L'application pour téléphone demande plusieurs autorisations à la fois

Figure 4. Boîte de dialogue d'autorisations utilisant un profil d'appareil associé pour demander plusieurs autorisations dans une seule requête

Les applications partenaires fonctionnant sous Android 12 (niveau d'API 31) ou version ultérieure peuvent utiliser des profils d'appareils associés pour se connecter à une montre. L'utilisation d'un profil simplifie le processus d'enregistrement en regroupant l'attribution d'un ensemble d'autorisations spécifiques au type d'appareil dans une seule étape.

Les autorisations groupées sont accordées à l'application associée une fois que l'appareil se connecte. Elles ne sont valables que lorsque l'appareil est associé. La suppression de l'application ou de l'association supprime les autorisations. Pour en savoir plus, consultez AssociationRequest.Builder.setDeviceProfile().

Modèles de demande d'autorisations

Il existe différents modèles pour demander des autorisations aux utilisateurs. Les voici, par ordre de priorité :

  • Demander en contexte s'il est évident que l'autorisation est nécessaire pour une fonctionnalité spécifique, mais qu'elle n'est pas indispensable pour exécuter l'application elle-même

  • Informer en contexte lorsque le motif de la demande d'autorisation n'est pas clair et que l'autorisation n'est aucunement nécessaire pour exécuter l'application elle-même

Ces modèles sont expliqués dans les sections suivantes.

Demander en contexte

Demandez des autorisations lorsque l'utilisateur comprend clairement pourquoi elles sont nécessaires à une opération donnée. Les utilisateurs sont plus enclins à accorder une autorisation s'ils comprennent le lien avec la fonctionnalité qu'ils souhaitent utiliser.

Par exemple, une application peut avoir besoin de connaître la position de l'utilisateur pour afficher les lieux d'intérêt à proximité. Lorsque l'utilisateur appuie sur l'appareil pour rechercher des lieux à proximité, l'application peut immédiatement demander l'autorisation d'accéder à la position, car il existe un lien évident entre ce type de recherche et l'octroi de cette autorisation. Vu le caractère évident de cette relation, il est inutile que l'application affiche des écrans d'information supplémentaires.

L'application demande une autorisation lorsque cela est manifestement nécessaire.
Figure 5. Demande d'une autorisation en contexte

Informer en contexte

La figure 6 illustre un exemple d'information en contexte. L'application ne nécessite aucune autorisation pour démarrer le chronomètre, mais un repère visuel intégré montre qu'une partie de l'activité (à savoir la détection de la position) est verrouillée. Lorsque l'utilisateur appuie sur le repère, un écran de demande d'autorisation s'affiche, ce qui lui permet de déverrouiller la détection de la position.

Utilisez la méthode shouldShowRequestPermissionRationale() pour aider votre application à déterminer si elle doit fournir plus d'informations. Pour en savoir plus, consultez Demander des autorisations. Vous pouvez également examiner comment l'exemple d'application pour haut-parleur sur GitHub gère l'affichage des informations.

Lorsque l'autorisation s'avère nécessaire, l'application explique pourquoi.
Figure 6. Informer en contexte

Gérer le refus

Si l'utilisateur refuse une autorisation qui n'est pas essentielle pour une activité prévue, ne l'empêchez pas de poursuivre l'activité en question. Si certaines parties de l'activité sont désactivées en raison du refus de l'autorisation, fournissez des commentaires visuels pertinents.

La figure 7 illustre l'utilisation d'une icône en forme de cadenas pour indiquer qu'une fonctionnalité est verrouillée, car l'utilisateur n'a pas accordé l'autorisation appropriée.

Lorsque l'utilisateur refuse une autorisation, une icône en forme de cadenas apparaît à côté de la fonctionnalité associée.
Figure 7. Icône en forme de cadenas indiquant qu'une fonctionnalité est verrouillée en raison d'un refus d'autorisation

Lorsqu'une boîte de dialogue d'autorisation "wearable" précédemment refusée s'affiche une deuxième fois, elle contient l'option Refuser, ne plus afficher. Si l'utilisateur sélectionne cette option, le seul moyen dont il dispose pour accorder cette autorisation à l'avenir est d'accéder à l'application Paramètres de l'accessoire connecté.

Le système propose de ne plus demander d'autorisations.
Figure 8. L'utilisateur peut accéder à une demande d'autorisation qui a été refusée deux fois via les paramètres

Découvrez comment gérer le refus d'autorisation.

Autorisations pour les services

Seule une activité peut appeler la méthode requestPermissions(). Par conséquent, si l'utilisateur interagit avec votre application à l'aide d'un service (par le biais d'un cadran, par exemple), le service doit ouvrir une activité avant de demander l'autorisation. Dans cette activité, fournissez des informations supplémentaires sur la nécessité d'accorder cette autorisation.

En règle générale, ne demandez pas d'autorisations pour un cadran. Implémentez plutôt une complication et laissez l'utilisateur choisir les données à afficher via cette complication.

Paramètres

Un utilisateur peut, à tout moment, modifier les autorisations d'une application Wear dans les paramètres. Lorsque l'utilisateur tente d'effectuer une opération nécessitant une autorisation, appelez d'abord la méthode checkSelfPermission() pour vérifier si l'application dispose de l'autorisation appropriée.

Effectuez cette vérification même si l'utilisateur a déjà accordé l'autorisation, car il peut l'avoir révoquée entre temps.

L'utilisateur peut modifier les autorisations dans l'application Paramètres.
Figure 9. L'utilisateur peut modifier les autorisations dans l'application Paramètres.