Autorisations d'exécution

Dans Android 6.0 et versions ultérieures, le modèle d'autorisations d'application Android est conçu pour les autorisations plus compréhensibles, utiles et sécurisées pour les utilisateurs. Le modèle a déplacé Android applications qui requièrent des autorisations dangereuses (consultez Autorisations concernées) à partir d'un install-time sur un modèle d'autorisation d'environnement d'exécution:

  • Autorisations d'installation

    (Android 5.1 ou version antérieure) Les utilisateurs accordent des autorisations dangereuses à une application lorsqu'ils l'installent ou la mettent à jour. Appareil les fabricants et les opérateurs peuvent préinstaller des applications avec les autorisations pré-accordées sans en avertir 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. Lorsque des autorisations sont demandées (par exemple, lorsque l'application se lance ou lorsque l'utilisateur accède à une fonctionnalité) dépend de l'application, mais l'utilisateur accorde ou refuse à l'application l'accès groupes d'autorisations. Les OEM/opérateurs peuvent préinstaller des applications, mais ne peuvent pas préaccorder d'autorisations suivre la procédure d'exception. (Voir Création exceptions.)

    (Android 10) Les utilisateurs constatent une meilleure transparence et ont pour contrôler quelles applications disposent d'autorisations d'exécution pour la reconnaissance de l'activité (RA). Les utilisateurs sont invités par le <ph type="x-smartling-placeholder"></ph> des autorisations d'exécution pour toujours autoriser, autoriser pendant l'utilisation ou refuser les autorisations. Lors d’une mise à niveau de l’OS vers Android 10, les autorisations accordées aux applications sont conservées, mais les utilisateurs peuvent les modifier en accédant à Paramètres.

Les autorisations d'exécution empêchent les applications d'accéder à des données privées sans le consentement de l'utilisateur. et leur fournira plus de contexte et de visibilité sur les types d'autorisations applications recherchent ou ont été accordées. Le modèle d'exécution encourage les développeurs à aident les utilisateurs à comprendre pourquoi les applications nécessitent les autorisations demandées la transparence afin que les utilisateurs puissent prendre de meilleures décisions concernant leur acceptation ou leur refus.

Autorisations concernées

Android 6.0 ou version ultérieure nécessite des autorisations dangereuses pour utiliser un modèle d'autorisations d'exécution. Les autorisations dangereuses sont celles qui présentent un risque plus élevé (comme READ_CALENDAR) demander à des applications d'accéder à des données utilisateur privées ou de contrôler un appareil, ce qui peut nuire avoir un impact 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 de la normale autorisations. Ce sont toutes des autorisations non dangereuses, y compris les autorisations normales, le système et les autorisations de signature. Les autorisations normales sont des autorisations à faible risque SET_WALLPAPER) qui accordent aux applications qui les demandent l'accès à des applications isolées fonctionnalités avec un risque minimal pour les autres applications, le système ou l'utilisateur. Comme pour Android 5.1 et versions antérieures, le système accorde automatiquement les autorisations normales à l'application à l'origine de la demande l’installation et n’invite pas l’utilisateur d’approbation. Pour plus d'informations sur les autorisations, consultez la section <permission> .

Restrictions strictes et faibles sous Android 10

En plus d'être dangereuse, une autorisation peut être restreinte ou restreint de manière temporaire. Dans les deux cas, l'autorisation restreinte doit également être ajoutée à la liste d'autorisation. Non ajouté à la liste d'autorisation les restrictions strictes se comportent différemment des restrictions logicielles non autorisées restrictions:

  • (Restrictions strictes) Il est impossible d'accorder des autorisations qui ne sont pas ajoutés à la liste d'autorisation.
  • (Restrictions souples) Les applications ne figurant pas sur la liste d'autorisation se comportent conformément aux l’autorisation spécifique qu’ils demandent. Le comportement est décrit dans le public pour obtenir l'autorisation demandée.

Lors de l'installation d'une application, le programme d'installation (tel que le Google Play Store) peut sélectionner de ne pas ajouter les autorisations restreintes à la liste d'autorisation pour l'application. Les autorisations sont restreints par la plate-forme et ne peuvent être accordées que si une appli répond à des critères spéciaux par règle de plate-forme. Exemples de types d’autorisations restreints : SMS et les autorisations du journal d'appels.

L'ajout à la liste d'autorisation a lieu pendant l'installation et lorsque

  • une application est déjà installée lors d'une mise à niveau d'Android 9 à 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 ajouter à la liste d'autorisation l'autorisation.
  • le programme d'installation (tel que le Google Play Store) marque l'autorisation comme ajoutés à la liste d'autorisation.

Les utilisateurs ne peuvent pas ajouter manuellement les autorisations à la liste d'autorisation.

Conditions requises

Le modèle d'autorisation d'exécution s'applique à toutes les applications, y compris celles préinstallées à l'appareil lors du processus de configuration. Les exigences relatives aux logiciels de l'application sont les suivantes:

  • Le modèle d'autorisation d'exécution doit être cohérent sur tous les appareils équipés d'Android 6.0 et supérieurs. Cela est mis en œuvre par les tests CTS (Compatibility Test Suite) d'Android.
  • Les applications doivent inviter les utilisateurs à accorder des autorisations d'application au moment de l'exécution. Pour en savoir plus, consultez la section Mettre à jour applications. Des exceptions limitées peuvent être accordées aux applications et gestionnaires par défaut qui fournissent des fonctionnalités de base essentielles au bon fonctionnement de l'appareil. (Par exemple, l'application Téléphone par défaut de l'appareil, qui gère les ACTION_CALL, peut avoir Accès à l'autorisation du téléphone.) Pour en savoir plus, consultez la section Créer des exceptions.
  • Applications préchargées avec des autorisations dangereuses doit cibler le niveau d'API 23 et maintenir le modèle d'autorisation d'exécution. C'est-à-dire que le flux de l'UI pendant l'installation de l'application ne doit pas déroger à l'implémentation AOSP de PermissionController, les utilisateurs peuvent révoquer les autorisations dangereuses des applications préinstallées, et donc activé.
  • Les applications sans interface graphique doivent utiliser une activité pour demander des autorisations ou partager un Identifiant unique de l'utilisateur d'une autre application disposant des autorisations nécessaires Pour en savoir plus, consultez Applications headless.

Migration des autorisations

Les autorisations accordées aux applications sous Android 5.x restent accordées après la mise à jour vers Android 6.0. ou supérieure, mais les utilisateurs peuvent révoquer ces autorisations à tout moment.

Dans une mise à jour Android 9 à 10, toutes les autorisations soumises à des restrictions ajoutés à la liste d'autorisation. Pour savoir comment implémenter les autorisations de fractionnement au premier plan/arrière-plan, consultez Modification de la confidentialité dans Android 10, en commençant par Demander un arrière-plan. emplacement.

Intégration

Lorsque vous intégrez le modèle d'autorisations d'exécution de l'application pour Android 6.0 ou version ultérieure, 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 gestionnaires/fournisseurs par défaut des fonctionnalités de base, définir des autorisations personnalisées personnaliser le thème utilisé dans l'application PermissionController.

Mettre à jour les applications

Les applications sur l'image système et les applications préinstallées ne sont pas automatiquement pré-autorisées autorisations. Nous vous encourageons à collaborer avec des développeurs d'applications préinstallées (OEM, opérateurs tiers) d'apporter les modifications requises à l'application via consignes. Plus précisément, vous devez vous assurer que les applications préinstallées sont modifiées pour éviter des plantages et d'autres problèmes lorsque les utilisateurs révoquent des autorisations.

Applications préchargées

Sous Android 9 ou version antérieure, 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'autorisation AOSP d'Android 6.0 ou version ultérieure. Par exemple, le flux de l'UI pendant l'installation d'une application ne doit pas déroger à l'implémentation AOSP de PermissionController Les utilisateurs peuvent même révoquer les autorisations dangereuses des des applications préinstallées.

Dans les versions 6.0 à 9 d'Android, certaines autorisations sont accordées pendant le processus d'installation. Toutefois, en commençant dans 10, le flux d'installation (effectué par l'application Package Installer) est une fonction distincte de celle des autorisations accordées dans le Permission Controller).

Applications headless

Seules les activités peuvent demander des autorisations. Les services ne peuvent pas demander d'autorisations directement.

  • Sur Android 5.1 et versions antérieures, les applications headless peuvent demander des autorisations lorsqu'elles installés, ou s'ils ont été préinstallés sans l'utilisation d'une activité.
  • Dans Sur Android 6.0 ou version ultérieure, les applications headless doivent utiliser l'une des méthodes suivantes pour : demander des autorisations:
    • Ajoutez une activité pour demander des autorisations. Il s'agit de la méthode à privilégier.
    • Partagez un UID avec une autre application disposant des autorisations nécessaires. Utiliser ceci uniquement lorsque vous avez besoin que la plate-forme gère plusieurs APK comme un seul et même l'application.

L'objectif est d'éviter de perturber les utilisateurs avec des demandes d'autorisation qui apparaissent hors contexte.

Personnaliser l'UI PackageInstaller

Si vous le souhaitez, vous pouvez personnaliser le thème de l'interface utilisateur des autorisations de l'une des manières suivantes : mise à jour des thèmes par défaut de l'appareil (Theme.DeviceDefault.Settings et Theme.DeviceDefault.Light.Dialog.NoActionBar) utilisés par PackageInstaller. Cependant, la cohérence étant essentielle pour les développeurs d'applications, vous ne pouvez pas personnaliser l'emplacement, la position ni les règles concernant le moment où les autorisations L'interface utilisateur s'affiche.

Pour inclure des chaînes dans d'autres langues, ajoutez les en AOSP.

Créer des exceptions

Vous pouvez préaccorder des autorisations aux applications qui sont des gestionnaires par défaut ou pour les principales fonctionnalités du système d'exploitation à l'aide 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 sur normal ou dangereux et d'ajouter des autorisations OEM/propres à l'opérateur aux les groupes d'autorisations, tout comme dans Android 5.x et versions antérieures.

Dans Android 6.0 et versions ultérieures, si vous ajoutez une nouvelle autorisation dangereuse, elle doit être gérée dans de la même manière que les autres autorisations dangereuses (demandées pendant l'exécution et révocables par les utilisateurs). Plus spécifiquement :

  • Vous pouvez ajouter de nouvelles autorisations à un groupe actuel, mais vous ne pouvez pas modifier les Mappage AOSP des autorisations dangereuses et des groupes d'autorisations dangereux. (En d'autres termes, vous vous ne pouvez pas retirer une autorisation d'un groupe pour 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 fichier manifeste de la plate-forme.

Tester les autorisations

Android inclut des tests CTS (Compatibility Test Suite) qui vérifient les autorisations individuelles sont mappés aux bons groupes. Réussir ces tests est une exigence pour la compatibilité avec Android 6.0 et versions ultérieures avec CTS.

Révoquer les autorisations

Sous Android 13 et versions ultérieures, vous pouvez révoquer vos propres droits les autorisations d'exécution Context.revokeSelfPermissionsOnKill() La révocation s'effectue de manière asynchrone et se déclenche dès que vous pouvez le faire sans risque et 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 le des paramètres, qui traite les autorisations par groupe. En général, un groupe d'autorisations est affiché sous la forme accordées tant qu’au moins une des autorisations de ce groupe est accordée. Si s’assurer que les utilisateurs êtes en mesure de confirmer que la révocation dans les paramètres est importante pour vous, assurez-vous de révoquer autorisation dans le 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 l'arrière-plan correspondant. autorisations si aucune des autorisations de 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, également être déclenchés immédiatement en arrêtant manuellement tous les processus en cours d'exécution dans l'UID actuel, par exemple : à l'aide de System.exit(). Toutefois, il est recommandé de laisser le système décider quand le déclencher.

Une fois la révocation d'une autorisation effective, vous pouvez redemander cette autorisation. invité à accepter ou à refuser la requête. Il n’est pas possible de demander une autorisation qui aurait refusé par l'utilisateur. Même si nous vous encourageons à révoquer les autorisations actuellement détenues, mais qui ne sont plus nécessaires, veillez à ne pas informer l'utilisateur de la révocation jusqu'à son entrée en vigueur.