Autorisations d'exécution

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 déplacé applications Android qui requièrent des autorisations dangereuses (voir autorisations affectées ) à partir d' un modèle d'autorisation moment de l' installation à un modèle d'autorisation d'exécution:

  • Autorisations d'installation

    (Android 5.1 et inférieur) Les utilisateurs accordent des autorisations dangereuses à une application lors de l' installation ou mettre à 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 (comme 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 à 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 voient une plus grande transparence et le contrôle sur les applications qui ont des autorisations d'exécution reconnaissance d'activité (AR). Les utilisateurs sont invités par les droits d'exécution de dialogue soit toujours autoriser, permettent pendant l'utilisation, ou refuser des autorisations. Sur une mise à niveau du système d'exploitation Android à 10, les autorisations données aux applications sont conservées, mais les utilisateurs peuvent entrer dans les 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 recherchent 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 concernant leur octroi ou leur refus.

Autorisations affectées

Android 6.0 et versions ultérieures nécessitent des autorisations dangereuses pour utiliser un modèle d'autorisations d'exécution. Autorisations dangereuses sont des permissions plus grands risques (tels que READ_CALENDAR ) que les demandes de subvention demandant l' accès aux données privées de l' utilisateur ou le contrôle d' un dispositif 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 supérieur ne change pas le comportement des autorisations normales . Ce sont toutes des autorisations non dangereuses, y compris les autorisations normales, système et de signature. Autorisations normales sont des autorisations à faible risque ( par exemple SET_WALLPAPER ) qui accordent une demande d' accès à des applications isolées niveau d'application comporte un risque minimal pour d' autres applications, le système ou l'utilisateur. Comme dans Android 5.1 et versions antérieures, le système accorde automatiquement les autorisations normales à une application demandeuse lors de l'installation et ne demande pas l'approbation de l'utilisateur. Pour plus de détails sur les autorisations, voir l' élément <autorisation> documentation.

Restrictions matérielles et logicielles dans Android 10

En plus d'être dangereuse, une autorisation peut être soit strictement restreinte, soit souple. Dans les deux cas, l'autorisation restreinte doit également être ajoutée à la liste blanche. Les restrictions strictes non inscrites sur la liste blanche se comportent différemment des restrictions souples non inscrites sur la liste blanche :

  • (Restrictions dur) Apps ne peuvent être accordées des autorisations qui ne sont pas dans la liste blanche.
  • (Restrictions souples) Applications sans whitelisting comportent selon l'autorisation spécifique leur demande. 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 ajouter à la liste blanche 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 par politique de plate-forme. Des exemples de types d'autorisation strictement limités incluent les autorisations SMS et Journal des appels.

La liste blanche se produit pendant l'installation, et quand

  • 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 l'autorisation à la liste blanche.
  • le programme d'installation (tel que Google Play Store) marque l'autorisation comme étant sur liste blanche.

Les utilisateurs ne peuvent pas ajouter manuellement les autorisations à la liste blanche.

Conditions

Le modèle d'autorisation d'exécution s'applique à toutes les applications, y compris les applications préinstallées et les applications livrées sur 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 au moment de l'exécution. Pour plus de détails, voir les applications Mise à jour . Des exceptions limitées peuvent être accordées aux applications et aux gestionnaires par défaut qui fournissent les fonctionnalités de base de l'appareil, fondamentales pour le fonctionnement attendu de l'appareil. (Par exemple, la valeur par défaut de l' appareil app Dialer pour le traitement ACTION_CALL peut avoir accès téléphone permission.) Pour plus de détails, voir 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. C'est-à-dire que le flux d'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 les applications Headless .

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 à 10, toutes les autorisations strictement limitées sont ajoutées à la liste blanche. Pour plus de détails sur la mise en œuvre des autorisations fractionnées de premier plan / arrière - plan, voir le changement de confidentialité Android 10 , en commençant par emplacement Demande d'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 pour les fonctionnalités de base, définir des autorisations personnalisées et personnaliser le thème utilisé dans l' PermissionController application.

Mise à jour des candidatures

Les applications sur l'image système et les applications préinstallées ne sont pas automatiquement pré-accordées. Nous vous encourageons à travailler pour apporter les modifications nécessaires à l' aide d'applications aux développeurs d'applications pré - installés (OEM, transporteur et tiers) des lignes directrices 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 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 débit de l' interface utilisateur lors de l'installation de l' application ne doit pas dévier de la mise en œuvre du PSBA 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 (effectuée par le Package Installer d' Permission Controller Package Installer du Package Installer de l' application) est une fonction distincte de permissions octroi (dans l' Permission Controller du Permission Controller de l' application).

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 écran 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 sans écran 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 en tant qu'application unique.

L'objectif est d'éviter de confondre 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 l' interface utilisateur sur le thème des autorisations en mettant à jour les thèmes de l' appareil 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 le placement, la position et les règles d'affichage de l'interface utilisateur des autorisations.

Pour inclure des chaînes pour des langues supplémentaires, les chaînes contribuent à PSBA.

Création d'exceptions

Vous pouvez pré-accorder des autorisations aux applications qui sont gestionnaires par défaut ou les fournisseurs pour les fonctionnalités du système d'exploitation de base en utilisant la DefaultPermissionGrantPolicy.java classe 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 personnalisées et des groupes comme normal ou dangereux et ajouter des autorisations OEM / spécifiques-Carrier à des groupes d'autorisations existantes, tout comme vous pourriez 5.x Android 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 plate-forme.

Tester les autorisations

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 condition requise pour la compatibilité CTS Android 6.0 et versions ultérieures.