Dans Android 6.0 et versions ultérieures, le modèle d'autorisations d'application 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 nécessitant des autorisations dangereuses (voir Autorisations affectées ) d'un modèle d'autorisation d' installation vers un modèle d'autorisation d' 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éaccordées sans en informer l'utilisateur.
- Autorisations d'exécution
( Android 6.0 - 9 ) Les utilisateurs accordent des autorisations dangereuses à une application lorsque l'application est en cours d'exécution. Le moment où les autorisations sont demandées (par exemple, lorsque l'application démarre 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 préaccorder d'autorisations à moins qu'ils ne passent par le processus d'exception. (Voir Création d'exceptions .)
( Android 10 ) Les utilisateurs bénéficient d'une transparence accrue et contrôlent les applications disposant 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 que les applications demandent ou ont été accordées. 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 pour les accorder ou les refuser.
Autorisations affectées
Android 6.0 et supérieur nécessite des autorisations dangereuses pour utiliser un modèle d'autorisations d'exécution. Les autorisations dangereuses sont des autorisations à haut risque (telles que READ_CALENDAR ) qui accordent aux applications demandeuses l'accès aux données utilisateur privées 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 des autorisations normales à une application demandeuse lors de l'installation et n'invite pas l'utilisateur à approuver. 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 strictement restreinte ou souple. Dans les deux cas, l'autorisation restreinte doit également figurer sur la liste d'autorisation. Les restrictions strictes non répertoriées sur la liste d'autorisation se comportent différemment des restrictions souples non répertoriées sur la liste d'autorisation :
- ( Restrictions strictes ) Les applications ne peuvent pas se voir accorder des autorisations qui ne sont 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 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 peuvent être accordées que si une application répond à des critères spéciaux par politique de plate-forme. Les autorisations SMS et Call Log sont des exemples de types d'autorisation strictement restreints.
La liste blanche se produit lors de l'installation et lorsque
- une application est déjà installée lors d'une mise à niveau Android 9 vers 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 pour autoriser l'autorisation.
- le programme d'installation (tel que Google Play Store) marque l'autorisation comme étant sur liste blanche.
Les utilisateurs ne peuvent pas manuellement autoriser les autorisations.
Conditions
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 dans le cadre du processus de configuration. Les exigences du logiciel d'application incluent :
- 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 lors 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 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 de numérotation par défaut de l'appareil pour gérer
ACTION_CALLpeut avoir un accès à l'autorisation Téléphone.) Pour plus de détails, voir Création d'exceptions . - Les applications préchargées qui ont des 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 écran .
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 supérieur, mais les utilisateurs peuvent révoquer ces autorisations à tout moment.
Dans une mise à jour Android 9 à 10, toutes les autorisations strictement restreintes sont autorisées. Pour plus de détails sur la mise en œuvre des autorisations de séparation avant-plan/arrière-plan, consultez Modification de la confidentialité d'Android 10 , en commençant par Demander l'emplacement de l'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 supérieur, 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 principales, définir des autorisations personnalisées et personnaliser le thème utilisé dans l'application PermissionController .
Mise à jour des candidatures
Les applications sur l'image système et les applications préinstallées ne sont pas automatiquement des autorisations pré-accordées. Nous vous encourageons à travailler avec les développeurs d'applications préinstallées (OEM, opérateur et tiers) pour apporter les modifications requises à l'application en suivant les directives du développeur . 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
Dans 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 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.
Dans Android 6.0 à 9, certaines autorisations sont accordées pendant le flux d'installation. Cependant, à partir de 10, le flux d'installation (exécuté par l'application Package Installer ) est une fonction distincte de l'octroi des 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 tête peuvent demander des autorisations lorsqu'elles sont installées ou si elles ont été préinstallées sans l'utilisation d'une activité.
- Dans 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. (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 fichiers APK comme une seule application.
L'objectif est d'éviter de confondre les utilisateurs avec des demandes d'autorisation qui semblent 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. Cependant, étant donné que 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'affichage de l'interface utilisateur des autorisations.
Pour inclure des chaînes pour des langues supplémentaires, ajoutez les chaînes à AOSP.
Création d'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 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 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 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). 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.
Autorisations de test
Android inclut des tests Compatibility Test Suite (CTS) qui vérifient que les autorisations individuelles sont mappées aux groupes appropriés. La réussite de ces tests est une exigence pour la compatibilité avec Android 6.0 et versions ultérieures CTS.
Révoquer les autorisations
Dans Android 13 et versions ultérieures, vous pouvez révoquer vos propres autorisations d'exécution accordées à l'aide 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 en cours d'exécution dans l'UID appelant seront tué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 s'affichera comme accordé tant qu'au moins l'une des autorisations de ce groupe est accordée. S'il est important pour vous de vous assurer que les utilisateurs peuvent 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 encore 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 tuant manuellement tous les processus en cours d'exécution dans l'uid actuel, par exemple en utilisant System.exit() . Cependant, il est recommandé de laisser le système décider quand le déclencher.
Une fois qu'une révocation d'autorisation est effective, vous pouvez la redemander et l'utilisateur sera invité à accorder 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.