Sous Android 6.0 et versions ultérieures, le modèle d'autorisations des applications Android est conçu pour rendre les autorisations plus claires, utiles et sécurisées pour les utilisateurs. Le modèle a déplacé les applications Android qui nécessitent des autorisations dangereuses (voir la section Autorisations concernées) d'un modèle d'autorisation au moment de l'installation vers un modèle d'autorisation d'exécution:
- Autorisations d'installation
(Android 5.1 et versions antérieures) Les utilisateurs accordent des autorisations dangereuses à une application lorsqu'ils l'installent ou la mettent à jour. Les fabricants d'appareils et les opérateurs peuvent préinstaller des applications avec des autorisations préaccordées sans en informer l'utilisateur.
- Autorisations d'exécution
(Android 6.0 à 9) Les utilisateurs accordent des autorisations dangereuses à une application lorsqu'elle est en cours d'exécution. Le moment où les autorisations sont demandées (par exemple, au lancement de l'application ou lorsque l'utilisateur accède à une fonctionnalité spécifique) dépend de l'application, mais l'utilisateur accorde/refuse l'accès de l'application à des groupes d'autorisations spécifiques. Les OEM/opérateurs peuvent préinstaller des applications, mais ne peuvent pas accorder d'autorisations préalables, sauf s'ils passent par le processus d'exception. (Voir Créer des exceptions.)
(Android 10) Les utilisateurs bénéficient d'une transparence accrue et peuvent contrôler les applications disposant d'autorisations d'exécution de la reconnaissance d'activité (RA). La boîte de dialogue des autorisations d'exécution invite les utilisateurs à autoriser toujours, autoriser en cas d'utilisation ou refuser les autorisations. Lors de la mise à niveau de l'OS vers Android 10, les autorisations accordées aux applications sont conservées, mais les utilisateurs peuvent accéder à Paramètres et les modifier.
Les autorisations d'exécution empêchent les applications d'accéder aux données privées sans l'autorisation de l'utilisateur, et leur fournissent un contexte et une visibilité supplémentaires sur les types d'autorisations que les applications recherchent ou qui leur ont été accordées. Le modèle d'exécution encourage les développeurs à aider les utilisateurs à comprendre pourquoi les applications ont besoin des autorisations demandées et offre une plus grande transparence afin que les utilisateurs puissent prendre de meilleures décisions pour les accorder ou les refuser.
Autorisations concernées
Android 6.0 et versions ultérieures nécessitent des autorisations dangereuses pour utiliser un modèle d'autorisations d'exécution.
Les autorisations dangereuses sont des autorisations à risque plus élevé (telles que READ_CALENDAR) qui accordent aux applications à l'origine de la demande un accès aux données utilisateur privées ou un contrôle sur un appareil, ce qui peut avoir un impact négatif sur l'utilisateur. Pour afficher la liste des autorisations dangereuses, exécutez la commande suivante:
adb shell pm list permissions -g -d
Android 6.0 ou version ultérieure ne modifie pas le comportement des autorisations normales. Il s'agit d'autorisations non dangereuses, y compris les autorisations normales, système et signature. Les autorisations normales sont des autorisations à faible risque (telles que SET_WALLPAPER) qui permettent aux applications à demander l'accès à des fonctionnalités isolées au niveau de l'application, avec un risque minimal pour d'autres applications, le système ou l'utilisateur. Comme dans Android 5.1 et les versions antérieures, le système accorde automatiquement des autorisations normales à une application qui en fait la demande lors de l'installation et n'invite pas l'utilisateur à les approuver. Pour en savoir plus sur les autorisations, consultez la documentation sur l'élément <permission>.
Restrictions strictes et flexibles dans Android 10
En plus d'être dangereuse, une autorisation peut être soumise à une restriction stricte ou à une restriction souple. Dans les deux cas, l'autorisation limitée doit également être ajoutée à la liste d'autorisation. Les restrictions strictes non incluses dans la liste d'autorisation se comportent différemment des restrictions souples non incluses dans la liste d'autorisation:
- (Restrictions strictes) Les applications ne peuvent pas être autorisées à utiliser des autorisations qui ne figurent pas sur la liste d'autorisation.
- (Restrictions souples) Les applications sans liste d'autorisation se comportent en fonction de l'autorisation spécifique qu'elles demandent. Le comportement est décrit dans la documentation publique de l'autorisation demandée.
Lors de l'installation d'une application, le programme d'installation (tel que le Google Play Store) peut choisir de ne pas ajouter les autorisations limitées à la liste d'autorisation. Les autorisations sont limitées par la plate-forme et ne peuvent être accordées que si une application répond à des critères spéciaux conformément aux règles de la plate-forme. Les autorisations concernant les SMS et le journal d'appels sont des exemples de types d'autorisations soumises à des restrictions strictes.
L'ajout à la liste d'autorisation se produit lors de l'installation et lorsque
- une application est déjà installée lors d'une mise à niveau d'Android 9 vers Android 10.
- une autorisation est préaccordée ou une application est préinstallée.
- Une autorisation est requise pour un rôle déjà défini afin d'ajouter l'autorisation à la liste d'autorisation.
- Le programme d'installation (tel que le Google Play Store) marque l'autorisation comme étant sur la liste d'autorisation.
Les utilisateurs ne peuvent pas ajouter manuellement des autorisations à la liste d'autorisation.
Conditions requises
Le modèle d'autorisation d'exécution s'applique à toutes les applications, y compris les applications préinstallées et les applications fournies à l'appareil lors du processus de configuration. Les logiciels requis pour les applications incluent les suivants:
- Le modèle d'autorisation d'exécution doit être cohérent sur tous les appareils équipés d'Android 6.0 ou version ultérieure. Cette exigence est appliquée par les tests de la suite de tests de compatibilité Android (CTS).
- Les applications doivent inviter les utilisateurs à accorder des autorisations à l'application au moment de l'exécution. Pour en savoir plus, consultez Mettre à jour les applications. Des exceptions limitées peuvent être accordées aux applications et aux gestionnaires par défaut qui fournissent des fonctionnalités de base de l'appareil essentielles au fonctionnement attendu de l'appareil.
(Par exemple, l'application Téléphone par défaut de l'appareil pour gérer
ACTION_CALLpeut avoir accès à l'autorisation Téléphone.) Pour en savoir plus, consultez la section Créer des exceptions. - Les applications préchargées disposant d'autorisations dangereuses doivent cibler le niveau d'API 23 et conserver le modèle d'autorisation d'exécution. Autrement dit, le flux de l'UI lors de l'installation de l'application ne doit pas s'écarter de l'implémentation AOSP de PermissionController, les utilisateurs peuvent révoquer les autorisations dangereuses des applications préinstallées, etc.
- Les applications headless doivent utiliser une activité pour demander des autorisations ou partager un UID avec une autre application disposant des autorisations nécessaires. Pour en savoir plus, consultez Applications headless.
Migration des autorisations
Les autorisations accordées aux applications sur Android 5.x restent accordées après la mise à niveau vers Android 6.0 ou version ultérieure, mais les utilisateurs peuvent les révoquer à tout moment.
Lors d'une mise à jour d'Android 9 vers Android 10, toutes les autorisations à accès restreint sont ajoutées à la liste d'autorisation. Pour en savoir plus sur l'implémentation des autorisations de fractionnement au premier plan/en arrière-plan, consultez Modification de la confidentialité d'Android 10, en commençant par Demander la position en arrière-plan.
Intégration
Lorsque vous intégrez le modèle d'autorisations d'exécution de l'application pour Android 6.0 et versions ultérieures, vous devez mettre à jour les applications préinstallées pour qu'elles fonctionnent avec le nouveau modèle. Vous pouvez également définir des exceptions pour les applications qui sont les gestionnaires/fournisseurs par défaut des fonctionnalités de base, définir des autorisations personnalisées et personnaliser le thème utilisé dans l'application PermissionController.
Mettre à jour les applications
Les applications de l'image système et les applications préinstallées ne sont pas automatiquement autorisées. Nous vous encourageons à collaborer avec les développeurs d'applications préinstallées (OEM, opérateur et tiers) pour apporter les modifications requises à l'application en suivant les consignes pour les développeurs. Plus précisément, vous devez vous assurer que les applications préinstallées sont modifiées pour éviter les plantages et autres problèmes lorsque les utilisateurs révoquent des autorisations.
Applications préchargées
Sous Android 9 et versions antérieures, les applications préchargées qui utilisent des autorisations dangereuses doivent cibler le niveau d'API 23 ou version ultérieure, et conserver le modèle d'autorisations AOSP d'Android 6.0 et versions ultérieures. Par exemple, le flux de l'UI lors de l'installation d'une application ne doit pas s'écarter de l'implémentation AOSP de PermissionController. Les utilisateurs peuvent même révoquer les autorisations dangereuses des applications préinstallées.
Sous Android 6.0 à 9, certaines autorisations sont accordées lors du processus d'installation. Toutefois, à partir de la version 10, le flux d'installation (effectué par l'application Package
Installer) est une fonction distincte de l'octroi d'autorisations (dans l'application Permission Controller).
Applications sans interface graphique
Seules les activités peuvent demander des autorisations. Les services ne peuvent pas demander d'autorisations directement.
- Sous Android 5.1 et versions antérieures, les applications headless peuvent demander des autorisations lors de leur installation ou si elles ont été préinstallées sans utiliser d'activité.
- Sous Android 6.0 et versions ultérieures, les applications headless doivent utiliser l'une des méthodes suivantes pour demander des autorisations:
- Ajoutez une activité pour demander des autorisations. (méthode recommandée)
- Partager un UID avec une autre application disposant des autorisations nécessaires N'utilisez cette méthode que lorsque vous avez besoin que la plate-forme gère plusieurs APK en tant qu'application unique.
L'objectif est d'éviter de perturber les utilisateurs avec des demandes d'autorisation qui ne sont pas en contexte.
Personnaliser l'UI de PackageInstaller
Si vous le souhaitez, vous pouvez personnaliser le thème de l'UI des autorisations en mettant à jour les thèmes d'appareil par défaut (Theme.DeviceDefault.Settings et Theme.DeviceDefault.Light.Dialog.NoActionBar) utilisés par PackageInstaller. Toutefois, comme la cohérence est essentielle pour les développeurs d'applications, vous ne pouvez pas personnaliser l'emplacement, la position et les règles de l'UI des autorisations.
Pour inclure des chaînes pour d'autres langues, ajoutez-les à AOSP.
Créer des exceptions
Vous pouvez pré-accorder des autorisations aux applications qui sont des gestionnaires ou des fournisseurs par défaut pour les fonctionnalités de base de l'OS à l'aide de la classe DefaultPermissionGrantPolicy.java dans PackageManager. Exemples :
ACTION_CALL (Dialer) Default Phone, Contacts, SMS, Microphone
SMS_DELIVER_ACTION (SMS/MMS) Default Phone, Contacts, SMS
Définir des autorisations personnalisées
Vous pouvez définir des autorisations et des groupes personnalisés comme normaux ou dangereux, et ajouter des autorisations spécifiques à l'OEM/l'opérateur aux groupes d'autorisations existants, comme vous le pouviez dans Android 5.x et les versions antérieures.
Sous Android 6.0 et versions ultérieures, si vous ajoutez une autorisation dangereuse, elle doit être gérée de la même manière que les autres autorisations dangereuses (demandées lors de l'exécution de l'application et révocables par les utilisateurs). Plus spécifiquement :
- Vous pouvez ajouter de nouvelles autorisations à un groupe existant, mais vous ne pouvez pas modifier le mappage AOSP des autorisations dangereuses et des groupes d'autorisations dangereuses. (en d'autres termes, vous ne pouvez pas supprimer une autorisation d'un groupe et l'attribuer à un autre).
- Vous pouvez ajouter des groupes d'autorisations dans les applications installées sur l'appareil, mais pas dans le fichier manifeste de la plate-forme.
Tester les autorisations
Android inclut des tests CTS (Compatibility Test Suite) qui vérifient que les autorisations individuelles sont mappées aux bons groupes. Réussir ces tests est une exigence pour la compatibilité CTS d'Android 6.0 et versions ultérieures.
Révoquer les autorisations
Sous Android 13 et versions ultérieures, vous pouvez révoquer vos propres autorisations d'exécution accordées à l'aide de Context.revokeSelfPermissionsOnKill().
La révocation se produit de manière asynchrone et est déclenchée lorsqu'il est possible de le faire sans perturber l'utilisateur. Lorsque la révocation est déclenchée, tous les processus exécutés dans l'UID appelant sont arrêtés.
Il est important de comprendre que la révocation d'une seule autorisation peut ne pas être reflétée dans l'interface utilisateur des paramètres, qui traite les autorisations par groupe. En règle générale, un groupe d'autorisations est affiché comme accordé tant qu'au moins l'une des autorisations de ce groupe est accordée. Si vous souhaitez vous assurer que les utilisateurs peuvent confirmer la révocation dans les paramètres, veillez à révoquer toutes les autorisations du groupe d'autorisations. Pour savoir quelles autorisations appartiennent à un groupe donné, vous pouvez utiliser PackageManager.getGroupOfPlatformPermission et PackageManager.getPlatformPermissionsForGroup.
Lorsque le système révoque les autorisations demandées, il révoque également les autorisations en arrière-plan correspondantes si aucune de leurs autorisations au premier plan correspondantes n'est toujours accordée.
La révocation n'est pas déclenchée tant que le processus reste au premier plan, mais elle peut également être déclenchée immédiatement en arrêtant manuellement tous les processus exécutés dans l'UID actuel, par exemple à l'aide de System.exit().
Toutefois, nous vous recommandons de laisser le système décider du moment où il doit être déclenché.
Une fois la révocation d'une autorisation effective, vous pouvez la demander à nouveau, et l'utilisateur est invité à l'accepter ou à la refuser. Il n'est pas possible de demander une autorisation qui a déjà été refusée par l'utilisateur. Nous vous encourageons à révoquer les autorisations que vous détenez actuellement, mais qui ne sont plus nécessaires. Toutefois, veillez à ne pas informer l'utilisateur de la révocation avant qu'elle ne soit effective.