Dans Android 6.0 et versions ultérieures, le modèle d'autorisations des applications Android est conçu pour rendre les autorisations plus compréhensibles, utiles et sécurisées pour les utilisateurs. Le modèle a déplacé les applications Android qui nécessitent des autorisations dangereuses (voir Autorisations concernées ) d'un modèle d'autorisation au moment de l'installation vers un modèle d'autorisation à l'exécution :
- Autorisations au moment de l'installation
( Android 5.1 et versions antérieures ) Les utilisateurs accordent des autorisations dangereuses à une application lorsqu'ils installent ou mettent à jour l'application. Les fabricants d'appareils et les opérateurs peuvent préinstaller des applications avec des autorisations prédéfinies sans en informer l'utilisateur.
- Autorisations d'exécution
( Android 6.0 – 9 ) Les utilisateurs accordent des autorisations dangereuses à une application lorsque celle-ci est en cours d'exécution. Le moment où les autorisations sont demandées (par exemple lorsque l'application se lance ou lorsque l'utilisateur accède à une fonctionnalité spécifique) dépend de l'application, mais l'utilisateur accorde/refuse l'accès à l'application à des groupes d'autorisations spécifiques. Les OEM/opérateurs peuvent préinstaller des applications, mais ne peuvent pas accorder d'autorisations à moins de passer par le processus d'exception. (Voir Création d'exceptions .)
( Android 10 ) Les utilisateurs bénéficient d'une transparence accrue et contrôlent quelles applications disposent d'autorisations d'exécution de reconnaissance d'activité (AR). Les utilisateurs sont invités par la boîte de dialogue des autorisations d'exécution à toujours autoriser, à autoriser pendant l'utilisation ou à refuser les autorisations. Lors d'une mise à niveau du système d'exploitation vers Android 10, les autorisations accordées aux applications sont conservées, mais les utilisateurs peuvent accéder aux paramètres et les modifier.
Les autorisations d'exécution empêchent les applications d'accéder aux données privées sans le consentement de l'utilisateur et leur fournissent un contexte et une visibilité supplémentaires sur les types d'autorisations recherchées ou accordées par les applications. Le modèle d'exécution encourage les développeurs à aider les utilisateurs à comprendre pourquoi les applications nécessitent les autorisations demandées et offre une plus grande transparence afin que les utilisateurs puissent prendre de meilleures décisions concernant leur octroi ou leur refus.
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 à plus haut risque (telles que READ_CALENDAR ) qui accordent aux applications requérantes l'accès aux données privées de l'utilisateur ou le contrôle d'un appareil, ce qui peut avoir un impact négatif sur l'utilisateur. Pour afficher une liste des autorisations dangereuses, exécutez la commande :
adb shell pm list permissions -g -d
Android 6.0 et versions ultérieures ne modifient pas le comportement des autorisations normales . Ce sont toutes des autorisations non dangereuses, y compris les autorisations normales, système et de signature. Les autorisations normales sont des autorisations à faible risque (telles que SET_WALLPAPER ) qui accordent aux applications demandeuses l'accès à des fonctionnalités isolées au niveau de l'application avec un risque minimal pour les autres applications, le système ou l'utilisateur. Comme dans Android 5.1 et les versions antérieures, le système accorde automatiquement les autorisations normales à une application demandeuse lors de l'installation et ne demande pas d'approbation à l'utilisateur. Pour plus de détails sur les autorisations, consultez la documentation de l'élément <permission> .
Restrictions matérielles et logicielles dans Android 10
En plus d’être dangereuse, une autorisation peut être soit à restriction stricte, soit à restriction souple. Dans les deux cas, l’autorisation restreinte doit également être ajoutée à la liste verte. Les restrictions matérielles non autorisées se comportent différemment des restrictions logicielles non autorisées :
- ( Restrictions strictes ) Les applications ne peuvent pas bénéficier d'autorisations qui ne sont pas sur la liste verte.
- ( Restrictions douces ) Les applications sans liste blanche se comportent en fonction de l'autorisation spécifique qu'elles demandent. Le comportement est décrit dans la documentation publique pour l'autorisation demandée.
Lors de l'installation d'une application, le programme d'installation (tel que Google Play Store) peut choisir de ne pas autoriser les autorisations restreintes pour l'application. Les autorisations sont limitées par la plate-forme et ne sont accordées que si une application répond à des critères spéciaux selon la politique de la plate-forme. Des exemples de types d'autorisations strictement restreints incluent les autorisations SMS et Journal d'appels.
La mise sur liste verte se produit pendant l'installation et lorsque
- une application est déjà installée lors d'une mise à niveau d'Android 9 vers 10.
- une autorisation est accordée au préalable ou une application est préinstallée.
- une autorisation est requise pour un rôle déjà défini pour ajouter l'autorisation à la liste autorisée.
- le programme d'installation (tel que Google Play Store) marque l'autorisation comme étant sur liste verte.
Les utilisateurs ne peuvent pas ajouter manuellement des autorisations.
Exigences
Le modèle d'autorisation d'exécution s'applique à toutes les applications, y compris les applications préinstallées et les applications fournies sur l'appareil dans le cadre du processus de configuration. La configuration requise pour le logiciel d'application comprend :
- Le modèle d'autorisation d'exécution doit être cohérent sur tous les appareils exécutant Android 6.0 et versions ultérieures. Ceci est appliqué par les tests Android Compatibility Test Suite (CTS).
- Les applications doivent inviter les utilisateurs à accorder des autorisations d'application au moment de l'exécution. Pour plus de détails, voir Mise à jour des applications . Des exceptions limitées peuvent être accordées aux applications et gestionnaires par défaut qui fournissent des fonctionnalités de base de l'appareil fondamentales pour le fonctionnement attendu de l'appareil. (Par exemple, l'application de numérotation par défaut de l'appareil pour gérer
ACTION_CALLpeut disposer d'un accès à l'autorisation du téléphone.) Pour plus de détails, consultez Création d'exceptions . - Les applications préchargées dotées 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'interface utilisateur 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 sans tête doivent utiliser une activité pour demander des autorisations ou pour partager un UID avec une autre application disposant des autorisations nécessaires. Pour plus de détails, voir Applications sans tête .
Migration des autorisations
Les autorisations accordées aux applications sur Android 5.x restent accordées après la mise à jour vers Android 6.0 ou version ultérieure, mais les utilisateurs peuvent révoquer ces autorisations à tout moment.
Dans une mise à jour Android 9 vers 10, toutes les autorisations strictement restreintes sont ajoutées à la liste verte. Pour plus de détails sur la mise en œuvre des autorisations partagées au premier plan/arrière-plan, consultez Modification de la confidentialité d'Android 10 , en commençant par Demander un emplacement en arrière-plan .
L'intégration
Lors de l'intégration du modèle d'autorisations d'exécution d'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 .
Mise à jour des applications
Les applications sur l’image système et les applications préinstallées ne bénéficient pas automatiquement d’autorisations préalables. Nous vous encourageons à travailler avec des développeurs d'applications préinstallées (OEM, opérateur et tiers) pour apporter les modifications requises à l'application en suivant les directives des 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 les 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 supérieur et conserver le modèle d'autorisation AOSP d'Android 6.0 et supérieur. Par exemple, le flux de l'interface utilisateur 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 pendant le flux d'installation. Cependant, à 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 tête
Seules les activités peuvent demander des autorisations. Les services ne peuvent pas demander d'autorisations directement.
- Dans Android 5.1 et versions antérieures, les applications sans interface utilisateur peuvent demander des autorisations lorsqu'elles sont installées ou si elles ont été préinstallées sans l'utilisation d'une activité.
- Sous Android 6.0 et versions ultérieures, les applications sans interface utilisateur doivent utiliser l'une des méthodes suivantes pour demander des autorisations :
- Ajoutez une activité pour demander des autorisations. (C'est la méthode préférée.)
- Partagez un UID avec une autre application disposant des autorisations nécessaires. Utilisez cette méthode uniquement lorsque vous avez besoin que la plate-forme gère plusieurs APK comme une seule application.
L’objectif est d’éviter de dérouter les utilisateurs avec des demandes d’autorisation qui apparaissent hors contexte.
Personnalisation de l'interface utilisateur de PackageInstaller
Si vous le souhaitez, vous pouvez personnaliser le thème de l'interface utilisateur des autorisations en mettant à jour les thèmes de périphérique 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 d’apparition de l’interface utilisateur des autorisations.
Pour inclure des chaînes pour des langues supplémentaires, soumettez les chaînes à 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 principales du système d'exploitation à 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 étant 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.
Dans Android 6.0 et versions ultérieures, si vous ajoutez une nouvelle autorisation dangereuse, elle doit être traité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). Spécifiquement:
- Vous pouvez ajouter de nouvelles autorisations à un groupe actuel, mais vous ne pouvez pas modifier le mappage AOSP des autorisations dangereuses et des groupes d'autorisations dangereux. (En d’autres termes, vous ne pouvez pas supprimer une autorisation d’un groupe et l’attribuer à un autre groupe).
- Vous pouvez ajouter de nouveaux groupes d'autorisations dans les applications installées sur l'appareil, mais vous ne pouvez pas ajouter de nouveaux groupes d'autorisations dans le manifeste de la plateforme.
Tester les autorisations
Android inclut des tests CTS (Compatibility Test Suite) qui vérifient que les autorisations individuelles sont mappées aux groupes appropriés. La réussite de ces tests est une condition requise pour la compatibilité avec Android 6.0 et versions ultérieures CTS.
Révocation des 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 en toute sécurité sans perturber l'utilisateur. Lorsque la révocation est déclenchée, tous les processus exécutés dans l'UID appelant seront supprimé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 sera affiché comme accordé tant qu'au moins une des autorisations de ce groupe est accordée. S'il est important pour vous de garantir que les utilisateurs soient en mesure de confirmer la révocation dans les paramètres, assurez-vous de révoquer toutes les autorisations du groupe d'autorisations. Pour savoir quelles autorisations appartiennent à un certain groupe, vous pouvez utiliser PackageManager.getGroupOfPlatformPermission et PackageManager.getPlatformPermissionsForGroup .
Lorsque le système révoque les autorisations demandées, il révoque également les autorisations d'arrière-plan correspondantes si aucune de leurs autorisations de premier plan correspondantes n'est toujours accordée.
La révocation ne sera pas déclenchée tant que le processus reste au premier plan, mais peut également être déclenchée immédiatement en supprimant manuellement tous les processus exécutés dans l'uid actuel, par exemple en utilisant System.exit() . Il est toutefois recommandé de laisser le système décider du moment où le déclencher.
Une fois qu'une révocation d'autorisation est effective, vous pouvez la demander à nouveau et l'utilisateur sera invité à accepter ou à refuser la demande. Il n'est pas possible de demander une autorisation qui a été précédemment refusée par l'utilisateur. Bien que vous soyez encouragé à révoquer les autorisations que vous détenez actuellement mais qui ne sont plus nécessaires, vous devez veiller à ne pas informer l'utilisateur de la révocation avant qu'elle ne soit effective.