<autorisation>

Syntaxe :
<permission android:description="string resource"
            android:icon="drawable resource"
            android:label="string resource"
            android:name="string"
            android:permissionGroup="string"
            android:protectionLevel=["normal" | "dangerous" |
                                     "signature" | ...] />
Contenu dans :
<manifest>
Description :
Déclare une autorisation de sécurité utilisée pour limiter l'accès à des composants ou à des fonctionnalités propres à cette application ou à d'autres. Pour en savoir plus sur le fonctionnement des autorisations, consultez la section Autorisations dans la présentation du fichier manifeste d'application et les conseils de sécurité.
Attributs :
android:description
Description de l'autorisation lisible par l'utilisateur, qui est plus longue et plus détaillée que le libellé. Cet attribut peut s'afficher, par exemple, pour expliquer l'autorisation à l'utilisateur lorsqu'il est invité à accorder l'autorisation à une autre application.

Cet attribut est défini comme référence à une ressource de chaîne. Contrairement à l'attribut label, il ne peut pas s'agir d'une chaîne brute.

android:icon
Référence à une ressource drawable pour une icône représentant l'autorisation.
android:label
Nom de l'autorisation lisible par les utilisateurs.

Pour plus de commodité, vous pouvez définir le libellé directement en tant que chaîne brute lorsque vous développez l'application. Cependant, lorsque l'application sera prête à être publiée, définissez-le en tant que référence à une ressource de chaîne, afin qu'il puisse être localisé comme les autres chaînes de l'UI.

android:name
Nom à utiliser dans le code pour faire référence à l'autorisation, par exemple dans un élément <uses-permission> ou les attributs permission des composants d'application.

Remarque : Le système ne permet pas à plusieurs packages de déclarer une autorisation portant le même nom, sauf si tous les packages sont signés avec le même certificat. Si un package déclare une autorisation, le système ne permet pas non plus à l'utilisateur d'installer d'autres packages avec le même nom d'autorisation, sauf si ces packages sont signés avec le même certificat que le premier.

C'est pourquoi Google recommande d'ajouter le nom du package de l'application comme préfixe aux autorisations, selon la méthode du nom de domaine inversé. Faites suivre ce préfixe par .permission., puis par une description (en majuscules SNAKE_CASE) de la fonctionnalité représentée par l'autorisation. Par exemple : com.example.myapp.permission.ENGAGE_HYPERSPACE.

Suivez cette recommandation pour éviter les conflits dans les noms et pour identifier clairement le propriétaire et le rôle d'une autorisation personnalisée.

android:permissionGroup
Attribue cette autorisation à un groupe. La valeur de cet attribut est le nom du groupe, qui est déclaré avec l'élément <permission-group> dans cette application ou dans une autre. Si cet attribut n'est pas défini, l'autorisation n'appartient pas à un groupe.
android:protectionLevel

Caractérise le risque associé à l'autorisation et indique la procédure que le système doit suivre pour déterminer s'il convient d'accorder l'autorisation à une application qui la demande.

Chaque niveau de protection se compose d'un type d'autorisation de base et, le cas échéant, d'un nombre variable d'indicateurs. Par exemple, le niveau de protection "dangerous" ne comporte aucun indicateur. En revanche, le niveau de protection "signature|privileged" combine le type d'autorisation de base "signature" et l'indicateur "privileged".

Le tableau suivant présente tous les types d'autorisations de base. Pour obtenir la liste des indicateurs, consultez la rubrique protectionLevel.

Valeur Signification
"normal" Valeur par défaut. Autorisation à faible risque qui permet aux applications qui la demandent d'accéder à des fonctionnalités isolées au niveau de l'application, avec un risque minimal pour d'autres applications, le système ou l'utilisateur. Le système accorde automatiquement ce type d'autorisation à une application qui la demande lors de l'installation, sans demander explicitement l'approbation de l'utilisateur (qui a toujours la possibilité de passer ces autorisations en revue avant l'installation).
"dangerous" Autorisation présentant un risque plus élevé, qui donne accès aux données utilisateur privées ou au contrôle de l'appareil à une application qui le demande, ce qui peut avoir un impact négatif sur l'utilisateur. Étant donné que ce type d'autorisation présente un risque, le système peut ne pas l'accorder automatiquement à l'application à l'origine de la demande. Par exemple, toutes les autorisations dangereuses demandées par une application peuvent être présentées à l'utilisateur et nécessiter une confirmation. Une autre approche peut être appliquée pour éviter que l'utilisateur autorise automatiquement l'utilisation des fonctionnalités concernées.
"signature" Autorisation accordée par le système uniquement si l'application demandeuse est signée avec le même certificat que l'application qui a déclaré l'autorisation. Si les certificats correspondent, le système accorde automatiquement l'autorisation sans avertir l'utilisateur ni demander son approbation explicite.
"knownSigner" Autorisation accordée par le système uniquement si l'application demandeuse est signée avec un certificat autorisé. Si le certificat du demandeur est répertorié, le système accorde automatiquement l'autorisation sans avertir l'utilisateur ni demander son approbation explicite.
"signatureOrSystem"

Ancien synonyme de "signature|privileged". Obsolète à partir du niveau d'API 23.

Autorisation que le système n'accorde qu'aux applications qui se trouvent dans un dossier dédié sur l'image du système Android ou qui sont signées avec le même certificat que l'application qui a déclaré l'autorisation. Évitez d'utiliser cette option, car le niveau de protection "signature" est suffisant pour la plupart des besoins et fonctionne quel que soit l'emplacement d'installation des applications.

L'autorisation "signatureOrSystem" est utilisée dans certaines situations spéciales où plusieurs fournisseurs ont des applications intégrées dans une image système et doivent partager explicitement des fonctionnalités spécifiques, car ces fonctionnalités sont développées simultanément.
Première apparition :
Niveau d'API 1
Voir aussi :
<uses-permission>
<permission-tree>
<permission-group>