Stay organized with collections Save and categorize content based on your preferences.
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" | ...] />
Collections la contenant :
<manifest>
Description :
Déclare une autorisation de sécurité pouvant être utilisée pour limiter l'accès à des composants ou à des fonctionnalités propres à cette application ou à d'autres. Consultez la section Autorisations de l'introduction et le document Sécurité et autorisations pour en savoir plus sur le fonctionnement des autorisations.
Caractéristiques :
android:description
Description de l'autorisation lisible par l'utilisateur, plus longue et contenant plus d'information que le libellé. Cet attribut peut être affiché pour expliquer l'autorisation à l'utilisateur, par exemple lorsqu'il est invité à accorder l'autorisation à une autre application.

Il doit être défini comme référence à une ressource de chaîne. Contrairement à l'attribut label, il ne peut pas être constitué 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 pouvant être affiché à l'attention des 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 est prête à être publiée, ce libellé doit être défini en référence à une ressource de chaîne, afin qu'il puisse être localisé au même titre que les autres chaînes de l'interface utilisateur.

android:name
Nom de l'autorisation. Ce nom sera utilisé dans le code pour désigner l'autorisation, par exemple dans un élément <uses-permission> et dans les attributs permission des composants d'application.

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

Nous vous recommandons de préfixer les noms d'autorisations avec le nom du package de l'application concernée, selon la méthode du nom de domaine inversé. Ce préfixe doit être suivi de .permission., puis d'une description de la fonction associée à l'autorisation, en majuscules avec un tiret bas à la place des espaces (SNAKE_CASE). 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 doit être 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'option "privileged".

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

Valeur Signification
"normal" Valeur par défaut. Autorisation à faible risque qui permet aux applications de demander l'accès à 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 avant de continuer. Une autre méthode peut permettre d'éviter que l'utilisateur autorise automatiquement l'utilisation de ces installations.
"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.
"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 devrait suffire à la plupart des besoins et fonctionne, quel que soit l'emplacement exact 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 API 1
Voir aussi :
<uses-permission>
<permission-tree>
<permission-group>