Bonnes pratiques pour les autorisations des applications

Les demandes d'autorisation protègent les informations sensibles disponibles depuis un appareil et ne doivent être utilisées que lorsque l'accès aux informations est nécessaire au bon fonctionnement de votre application. Ce document fournit des conseils sur la façon d'obtenir la même fonctionnalité (ou de l'améliorer) sans avoir besoin d'accéder à ces informations. Il ne s'agit pas d'une discussion exhaustive sur le fonctionnement des autorisations dans le système d'exploitation Android.

Pour une présentation plus générale des autorisations Android, consultez Présentation des autorisations. Pour savoir comment utiliser les autorisations dans votre code, consultez Demander des autorisations d'application.

Autorisations dans Android 6.0+

Sous Android 6.0 (niveau d'API 23) ou version ultérieure, les applications peuvent demander des autorisations à l'utilisateur lors de l'exécution, plutôt qu'avant l'installation. Cela permet aux applications de demander des autorisations lorsqu'elles nécessitent réellement les services ou les données protégées par ces services. Bien que cela ne change pas (nécessairement) le comportement général de l'application, cela entraîne quelques changements liés à la manière dont les données utilisateur sensibles sont traitées :

Contexte accru

Dans le cadre de votre application, au moment de l'exécution, les utilisateurs sont invités à autoriser l'accès à la fonctionnalité couverte par les groupes d'autorisations à accorder. Les utilisateurs sont plus sensibles au contexte dans lequel l'autorisation est demandée. S'il existe une incohérence entre ce que vous demandez et le but de votre application, il est encore plus important de fournir une explication détaillée à l'utilisateur sur le motif de cette demande. Dans la mesure du possible, fournissez une explication de votre demande au moment où vous la formulez et dans une boîte de dialogue de suivi si l'utilisateur la refuse.

Pour augmenter les chances d'acceptation, n'envoyez une invite que lorsqu'une fonctionnalité spécifique est requise. Par exemple, ne demandez l'accès au micro que lorsqu'un utilisateur clique sur le bouton du micro. Les utilisateurs sont plus susceptibles d'accorder une autorisation s'ils s'attendent à devoir le faire.

Plus grande flexibilité pour l'attribution des autorisations

Les utilisateurs peuvent refuser l'accès à des autorisations individuelles au moment où elles sont demandées et dans les paramètres, mais être tout de même surpris par le dysfonctionnement de la fonctionnalité. Nous vous recommandons de surveiller le nombre d'utilisateurs qui refusent des autorisations (par exemple, à l'aide de Google Analytics) afin de refactoriser votre application pour éviter de dépendre de cette autorisation ou de fournir une meilleure explication des raisons pour lesquelles vous en avez besoin pour que votre application fonctionne correctement. Vous devez également vous assurer que votre application gère les exceptions lorsque les utilisateurs refusent les demandes d'autorisation ou désactivent les autorisations dans les paramètres.

Augmentation de la contrainte transactionnelle

Les utilisateurs sont invités à accorder l'accès aux groupes d'autorisations de manière individuelle et non groupée. Il est donc extrêmement important de réduire au minimum le nombre d'autorisations que vous demandez. Cela augmente la charge de l'utilisateur pour l'attribution des autorisations et augmente donc la probabilité qu'au moins une des requêtes soit refusée.

Autorisations qui nécessitent de devenir un gestionnaire par défaut

Certaines applications dépendent de l'accès aux informations utilisateur sensibles liées aux journaux d'appels et aux SMS. Si vous souhaitez demander les autorisations propres aux journaux d'appels et aux SMS et publier votre application sur le Play Store, vous devez inviter l'utilisateur à désigner votre application comme gestionnaire par défaut pour une fonction système essentielle avant de demander ces autorisations d'exécution.

Pour en savoir plus sur les gestionnaires par défaut, y compris sur la manière d'afficher une invite de gestionnaire par défaut aux utilisateurs, consultez le guide des autorisations propres aux gestionnaires par défaut.

Connaître les bibliothèques avec lesquelles vous travaillez

Les autorisations sont parfois requises par les bibliothèques que vous utilisez dans votre application. Par exemple, les bibliothèques d'annonces et d'analyse peuvent nécessiter un accès au groupe d'autorisations LOCATION pour implémenter la fonctionnalité requise. Toutefois, du point de vue de l'utilisateur, la demande d'autorisation provient de votre application, et non de la bibliothèque.

Tout comme les utilisateurs sélectionnent des applications qui utilisent moins d'autorisations pour la même fonctionnalité, les développeurs doivent examiner leurs bibliothèques et sélectionner des SDK tiers qui n'utilisent pas d'autorisations inutiles. Par exemple, si vous utilisez une bibliothèque offrant une fonctionnalité de localisation, assurez-vous de ne pas demander l'autorisation FINE_LOCATION, sauf si vous utilisez la fonctionnalité de ciblage géographique.

Limiter l'accès en arrière-plan à la localisation

Lorsque votre application s'exécute en arrière-plan, l'accès à la position doit être essentiel au fonctionnement de base de l'application et présenter un avantage évident pour les utilisateurs.

Tester pour les deux modèles d'autorisations

Sous Android 6.0 (niveau d'API 23) ou version ultérieure, les utilisateurs accordent et révoquent les autorisations de l'application au moment de l'exécution, plutôt que de le faire lorsqu'ils installent l'application. Par conséquent, vous devez tester votre application dans un plus grand nombre de conditions. Avant la version 6.0 d'Android, vous pouviez raisonnablement supposer que si votre application était en cours d'exécution, elle disposait de toutes les autorisations déclarées dans le fichier manifeste. L'utilisateur peut désormais activer ou désactiver les autorisations pour n'importe quelle application, quel que soit son niveau d'API. Vous devez effectuer des tests pour vous assurer que votre application fonctionne correctement dans différents scénarios d'autorisation.

Les conseils suivants vous aideront à détecter les problèmes de code liés aux autorisations sur les appareils exécutant l'API niveau 23 ou supérieur :

• Identifier les autorisations actuelles de votre application et les chemins d'accès de code associés
• Testez les parcours utilisateur sur l'ensemble des données et services protégés par des autorisations.
• Effectuez un test avec différentes combinaisons d'autorisations accordées ou révoquées. Par exemple, une application d'appareil photo peut répertorier CAMERA, READ_CONTACTS et ACCESS_FINE_LOCATION dans son fichier manifeste. Nous vous recommandons de tester l'application en activant et en désactivant chacune de ces autorisations pour vous assurer qu'elle peut gérer correctement toutes les configurations d'autorisation.
• Utilisez l'outil adb pour gérer les autorisations à partir de la ligne de commande :
  • Listez les autorisations et l'état par groupe :

    $ adb shell pm list permissions -d -g

  • Accordez ou révoquez une ou plusieurs autorisations :

    $ adb shell pm [grant|revoke] <permission-name> ...

• Analysez votre application pour identifier les services qui utilisent des autorisations.

Ressources supplémentaires

• Consignes Material Design pour les autorisations Android
• Android Marshmallow 6.0 : demande d'autorisation : cette vidéo explique le modèle d'autorisation d'exécution Android et la méthode à suivre pour demander des autorisations.
• Expliquer pourquoi l'application a besoin d'autorisations
• Bonnes pratiques pour les identifiants uniques