Cette page a été traduite par l'API Cloud Translation.

<uses-feature>

Google Play utilise les éléments <uses-feature> déclarés dans le fichier manifeste de votre application pour la filtrer dans les appareils qui ne répondent pas aux exigences de sa bibliothèque.

En spécifiant les fonctionnalités requises par votre application, vous autorisez Google Play à la présenter uniquement aux utilisateurs dont les appareils répondent aux spécificités de cette application.

Des informations importantes sur la manière dont Google Play utilise les fonctionnalités comme base de filtrage sont disponibles dans la section Google Play et filtrage basé sur les fonctionnalités.

Syntaxe :

<uses-feature
  android:name="string"
  android:required=["true" | "false"]
  android:glEsVersion="integer" />

Contenu dans :

<manifest>

description :

Déclare une seule fonctionnalité matérielle ou logicielle utilisée par l'application.

Le but d'une déclaration <uses-feature> est d'informer toute entité externe de l'ensemble des fonctionnalités matérielles et logicielles dont dépend votre application. L'élément comporte un attribut required qui vous permet de spécifier si le fonctionnement de votre application l'exige ou le recommande.

Étant donné que la prise en charge de certaines fonctionnalités peut varier selon les appareils Android, l'élément <uses-feature> joue un rôle important, car il permet à une application de décrire les fonctionnalités qu'elle utilise.

L'ensemble des fonctionnalités disponibles déclaré par votre application correspond à l'ensemble des constantes de fonctionnalités mises à disposition par le PackageManager Android. Les constantes de fonctionnalités disponibles sont présentées dans la section Documentation de référence sur les fonctionnalités de ce document.

Vous devez spécifier chaque fonctionnalité dans un élément <uses-feature> distinct. Par conséquent, si votre application nécessite plusieurs fonctionnalités, elle déclarera autant d'éléments <uses-feature>. Par exemple, une application qui requiert à la fois les fonctionnalités Bluetooth et de caméra sur l'appareil déclarerait ces deux éléments :

<uses-feature android:name="android.hardware.bluetooth" android:required="true" />
<uses-feature android:name="android.hardware.camera.any" android:required="true" />

En règle générale, déclarez toujours des éléments <uses-feature> pour toutes les fonctionnalités requises par votre application.

Les éléments <uses-feature> déclarés ne sont fournis qu'à titre indicatif, ce qui signifie que le système Android ne vérifie pas la compatibilité des fonctionnalités de l'appareil avant d'installer une application.

Toutefois, d'autres services (tels que Google Play) ou applications peuvent vérifier les déclarations <uses-feature> de votre application lors de leur interaction avec celle-ci. C'est pourquoi vous devez absolument déclarer l'ensemble des fonctionnalités qu'elle utilise.

Pour certaines fonctionnalités, un attribut spécifique peut vous permettre de définir une version de la fonctionnalité, par exemple la version d'Open GL utilisée (déclarée avec glEsVersion). L'existence et l'absence d'autres fonctionnalités d'un appareil, telles que la caméra, sont déclarées à l'aide de l'attribut name.

Bien que l'élément <uses-feature> ne soit activé que pour les appareils exécutant le niveau d'API 4 ou supérieur, vous devez l'inclure dans toutes vos applications, même si la valeur de minSdkVersion est inférieure ou égale à 3. Les appareils exécutant d'anciennes versions de la plate-forme ignoreront cet élément.

Remarque : Lorsque vous déclarez une fonctionnalité, n'oubliez pas que vous devez également demander les autorisations appropriées. Par exemple, vous devez demander l'autorisation CAMERA pour que votre application puisse accéder à l'API de la caméra. Ce faisant, votre application aura accès au matériel et aux logiciels appropriés. La déclaration des fonctionnalités utilisées par votre application garantit la compatibilité de l'appareil.

Attributs :

android:name

Spécifie une fonctionnalité matérielle ou logicielle unique utilisée par l'application, sous la forme d'une chaîne de descripteur. Les valeurs d'attribut valides sont recensées dans les sections Fonctionnalités matérielles et Fonctionnalités logicielles. Elles sont sensibles à la casse.

android:required

Valeur booléenne indiquant si l'application nécessite la fonctionnalité spécifiée dans android:name.

Déclarer android:required="true" pour une fonctionnalité indique que l'application ne peut pas fonctionner ou n'est pas conçue pour fonctionner si la fonctionnalité spécifiée n'est pas présente sur l'appareil.
Déclarer android:required="false" pour une fonctionnalité indique que l'application utilise cette fonctionnalité si elle est présente sur l'appareil, mais qu'elle est conçue pour fonctionner sans elle si nécessaire.

La valeur par défaut d'android:required est "true".

android:glEsVersion

Version d'OpenGL ES requise par l'application. Les 16 bits supérieurs représentent le nombre principal et les 16 bits inférieurs représentent le nombre mineur. Par exemple, pour spécifier OpenGL ES version 2.0, vous devez définir la valeur sur "0x00020000" ou, pour OpenGL ES 3.2, sur "0x00030002".

Une application doit spécifier au maximum un attribut android:glEsVersion dans son fichier manifeste. Si plusieurs valeurs sont spécifiées, la propriété android:glEsVersion ayant la valeur numérique la plus élevée est utilisée et toutes les autres valeurs sont ignorées.

Lorsqu'une application ne spécifie pas d'attribut android:glEsVersion, il est entendu qu'elle ne requiert qu'OpenGL ES 1.0, qui est compatible avec tous les appareils Android.

Une application peut supposer qu'une plate-forme compatible avec une version d'OpenGL ES donnée l'est également avec toutes les versions d'OpenGL ES dont la valeur numérique est inférieure. Par conséquent, pour une application qui nécessite à la fois OpenGL ES 1.0 et 2.0, spécifiez qu'elle nécessite OpenGL ES 2.0.

Pour une application compatible avec plusieurs versions d'OpenGL ES, spécifiez uniquement la version numérique la plus basse dont elle a besoin. Elle pourra vérifier au moment de l'exécution si une mouture supérieure d'OpenGL ES est disponible.

Pour en savoir plus sur l'utilisation d'OpenGL ES, y compris en ce qui concerne la vérification de la version compatible au moment de l'exécution, consultez le guide de l'API OpenGL ES.

Première apparition :

Niveau d'API 4

voir aussi :

Google Play et filtrage basé sur les fonctionnalités

Google Play filtre les applications visibles par les utilisateurs afin qu'ils ne puissent afficher et télécharger que celles qui sont compatibles avec leur appareil. L'une des méthodes de filtrage employées repose sur la compatibilité des fonctionnalités.

Pour déterminer la compatibilité d'une application avec l'appareil d'un utilisateur donné, Google Play compare entre eux les éléments suivants :

Fonctionnalités requises par l'application, telles que déclarées dans les éléments <uses-feature> du fichier manifeste de l'application
Fonctionnalités disponibles sur l'appareil, sous forme de matériel ou de logiciel, comme indiquées à l'aide de propriétés système en lecture seule.

Pour comparer les fonctionnalités avec précision, le gestionnaire de paquets Android fournit un ensemble partagé de constantes que les applications et les appareils utilisent pour déclarer les fonctionnalités requises et leur compatibilité. Les constantes de fonctionnalités disponibles sont présentées dans la section Documentation de référence sur les fonctionnalités de ce document, ainsi que dans la documentation des classes pour PackageManager.

Lorsque l'utilisateur lance Google Play, l'application interroge le gestionnaire de paquets pour obtenir la liste des fonctionnalités disponibles sur l'appareil en appelant getSystemAvailableFeatures(). L'application Store transmet ensuite la liste des fonctionnalités à Google Play lors de l'établissement de la session.

Chaque fois que vous importez une application dans la Google Play Console, son fichier manifeste est analysé. Google Play recherche les éléments <uses-feature> et les évalue au regard d'autres éléments, dans certains cas, tels que <uses-sdk> et <uses-permission>. Après avoir déterminé l'ensemble des fonctionnalités requises pour l'application, Google Play stocke cette liste en interne en tant que métadonnées associées au fichier APK de l'application et à sa version.

Lorsqu'un utilisateur recherche ou consulte des applications à l'aide de l'application Google Play, le service compare les fonctionnalités requises par chaque application à celles disponibles sur l'appareil de l'utilisateur. Si toutes les fonctionnalités requises sont présentes sur l'appareil, Google Play permet à l'utilisateur de voir l'application et de la télécharger.

Si une fonctionnalité requise n'est pas compatible avec l'appareil, Google Play filtre l'application afin qu'elle ne soit pas visible par l'utilisateur et qu'elle ne soit pas disponible au téléchargement.

Étant donné que les fonctionnalités que vous déclarez dans les éléments <uses-feature> affectent directement la manière dont Google Play filtre votre application, il est important de comprendre comment Google Play évalue le fichier manifeste de l'application et établit l'ensemble des fonctionnalités requises. Les sections suivantes fournissent plus d'informations.

Filtrage basé sur des fonctionnalités déclarées explicitement

Les fonctionnalités explicites de votre application se déclarent dans un élément <uses-feature>. Cette déclaration peut inclure un attribut android:required=["true" | "false"] si vous compilez à partir d'un niveau d'API 5 ou supérieur.

Il vous permet de spécifier si l'application nécessite la fonctionnalité et ne peut pas fonctionner correctement sans elle "true" ou si elle est disponible, mais conçue pour pouvoir s'exécuter sans ("false").

Voici comment Google Play gère les fonctionnalités déclarées explicitement :

Si une fonctionnalité est explicitement déclarée comme obligatoire, comme illustré dans l'exemple suivant, Google Play l'ajoute à la liste des fonctionnalités requises par l'application. Ensuite, filtre l'application pour les utilisateurs d'appareils qui ne proposent pas cette fonctionnalité.
```
<uses-feature android:name="android.hardware.camera.any" android:required="true" />
```
Si une fonctionnalité est explicitement déclarée comme non requise, comme illustré dans l'exemple suivant, Google Play ne l'ajoute pas à la liste des fonctionnalités requises. Pour cette raison, une fonctionnalité non requise déclarée explicitement n'est jamais prise en compte lors du filtrage de l'application. Même si l'appareil ne fournit pas les identifiants déclarés fonctionnalité, Google Play considère que l'application est compatible avec et la présente à l'utilisateur, sauf si d'autres règles de filtrage s'appliquent.
```
<uses-feature android:name="android.hardware.camera" android:required="false" />
```
Si une fonctionnalité a été déclarée explicitement, mais sans attribut android:required, Google Play suppose que celle-ci est obligatoire et configure un filtrage sur cette fonctionnalité.

En général, si votre application est conçue pour Android 1.6 ou une version antérieure, l'attribut android:required n'est pas disponible dans l'API. Google Play suppose que toutes les déclarations <uses-feature> sont obligatoires.

Remarque : En déclarant explicitement une fonctionnalité et en incluant un attribut android:required="false", vous pouvez désactiver tous les filtres sur Google Play pour la fonctionnalité spécifiée.

Filtrage basé sur des fonctionnalités implicites

Une fonctionnalité implicite est nécessaire au bon fonctionnement de l'application, mais elle n'est pas déclarée dans un élément <uses-feature> du fichier manifeste. Il est préférable que chaque application déclare toujours toutes les fonctionnalités qu'elle utilise ou nécessite. L'absence de déclaration pour une fonctionnalité utilisée par une application peut être considérée comme une erreur.

Toutefois, afin de protéger les utilisateurs et les développeurs, Google Play recherche des fonctionnalités implicites dans chaque application et configure des filtres pour celles-ci, exactement comme pour les fonctionnalités déclarées explicitement.

Une application peut nécessiter une fonctionnalité, mais ne pas la déclarer pour les raisons suivantes :

L'application a été compilée avec une ancienne version de la bibliothèque Android (Android 1.5 ou version antérieure), pour laquelle l'élément <uses-feature> n'est pas disponible.
Le développeur suppose à tort que la fonctionnalité est présente sur tous les appareils et qu'une déclaration n'est pas nécessaire.
Le développeur omet de déclarer la fonctionnalité par erreur.
Le développeur déclare explicitement la fonctionnalité, mais la déclaration n'est pas valide. Une faute d'orthographe dans le nom de l'élément <uses-feature> ou une valeur de chaîne non reconnue pour l'attribut android:name invalide la déclaration de la fonctionnalité.

Pour tenir compte de ces cas de figure, Google Play tente d'identifier les exigences de fonctionnalité implicites d'une application en examinant d'autres éléments déclarés dans le fichier manifeste, en particulier les éléments <uses-permission>.

Lorsqu'une application sollicite des autorisations liées au matériel, Google Play suppose qu'elle utilise les fonctionnalités matérielles sous-jacentes et que, par conséquent, elle les requiert, même en l'absence de déclarations <uses-feature> correspondantes. Pour ces autorisations, Google Play ajoute les fonctionnalités matérielles sous-jacentes aux métadonnées qu'il stocke pour l'application et configure des filtres pour celles-ci.

Par exemple, si une application demande l'autorisation CAMERA, Google Play suppose qu'elle requiert la présence d'une caméra arrière (tournée vers l'extérieur), même si aucun élément <uses-feature> n'est déclaré pour android.hardware.camera. Par conséquent, Google Play filtre les appareils sans caméra arrière.

Si vous ne souhaitez pas que Google Play effectue un filtrage en fonction d'une fonctionnalité implicite spécifique, déclarez explicitement la fonctionnalité dans un élément <uses-feature> et incluez l'attribut android:required="false". Par exemple, pour désactiver le filtrage impliquant l'autorisation CAMERA, déclarez les fonctionnalités suivantes :

<uses-feature android:name="android.hardware.camera" android:required="false" />
<uses-feature android:name="android.hardware.camera.autofocus" android:required="false" />

Attention : Les autorisations que vous demandez dans les éléments <uses-permission> peuvent avoir une incidence directe sur le filtrage de votre application par Google Play. La section Autorisations impliquant des exigences de fonctionnalités indique l'ensemble des autorisations qui impliquent des exigences de fonctionnalité et qui déclenchent donc un filtrage.

Traitement spécial de la fonctionnalité Bluetooth

Pour déterminer le filtrage Bluetooth, Google Play applique des règles légèrement différentes de celles décrites dans l'exemple précédent.

Lorsqu'une application déclare une autorisation Bluetooth dans un élément <uses-permission>, mais ne déclare pas explicitement la fonctionnalité Bluetooth dans un élément <uses-feature>, Google Play vérifie la ou les versions de la plate-forme Android sur laquelle l'application est conçue pour s'exécuter, comme spécifié dans l'élément <uses-sdk>.

Comme indiqué dans le tableau suivant, Google Play n'autorise le filtrage de la fonctionnalité Bluetooth que si l'application déclare sa plate-forme la plus basse ou ciblée comme étant Android 2.0 (niveau d'API 5) ou une version ultérieure. Toutefois, notez que Google Play applique les règles de filtrage normales lorsque l'application déclare explicitement la fonctionnalité Bluetooth dans un élément <uses-feature>.

Tableau 1. Comment Google Play détermine les exigences concernant les fonctionnalités Bluetooth pour une application qui demande une autorisation Bluetooth, mais ne déclare pas la fonctionnalité Bluetooth dans un élément <uses-feature>.

Si `minSdkVersion` est…	et `targetSdkVersion` est	Résultat
<=4, ou `<uses-sdk>` n'est pas déclaré	<=4	Google Play ne filtre pas l'application sur les appareils en fonction de leur compatibilité avec la fonctionnalité `android.hardware.bluetooth`.
<=4	>=5	Google Play filtre l'application sur tous les appareils qui ne sont pas compatibles avec la fonctionnalité `android.hardware.bluetooth` (y compris les versions antérieures).
>=5	>=5

Les exemples suivants illustrent les différents effets de filtrage, en fonction de la manière dont Google Play gère la fonctionnalité Bluetooth.

Dans le premier exemple, une application conçue pour s'exécuter à des niveaux d'API plus anciens déclare une autorisation Bluetooth, mais ne déclare pas la fonctionnalité Bluetooth dans un élément <uses-feature>.

Résultat : Google Play ne filtre l'application sur aucun appareil.

<manifest ...>
    <uses-permission android:name="android.permission.BLUETOOTH_ADMIN" />
    <uses-sdk android:minSdkVersion="3" />
    ...
</manifest>

</ph> Dans le deuxième exemple, la même application déclare également une cible Niveau d'API : "5".

Résultat:Google Play considère désormais que la fonctionnalité est requise et filtre l'application de tous les appareils qui ne prennent pas en charge le Bluetooth, y compris les appareils exécutant d'anciennes versions de la plateforme.

<manifest ...>
    <uses-permission android:name="android.permission.BLUETOOTH_ADMIN" />
    <uses-sdk android:minSdkVersion="3" android:targetSdkVersion="5" />
    ...
</manifest>

</ph> Ici, la même application déclare spécifiquement la fonctionnalité Bluetooth.

Résultat : Même chose que dans l'exemple précédent (le filtrage est appliqué).

<manifest ...>
    <uses-feature android:name="android.hardware.bluetooth" />
    <uses-permission android:name="android.permission.BLUETOOTH_ADMIN" />
    <uses-sdk android:minSdkVersion="3" android:targetSdkVersion="5" />
    ...
</manifest>

</ph> Enfin, dans le cas suivant, la même application ajoute android:required="false".

Résultat:Google Play désactive le filtrage basé sur le Bluetooth. la prise en charge des fonctionnalités pour tous les appareils.

<manifest ...>
    <uses-feature android:name="android.hardware.bluetooth" android:required="false" />
    <uses-permission android:name="android.permission.BLUETOOTH_ADMIN" />
    <uses-sdk android:minSdkVersion="3" android:targetSdkVersion="5" />
    ...
</manifest>

Tester les fonctionnalités requises par votre application

Vous pouvez utiliser l'outil aapt2 inclus dans le SDK Android pour déterminer comment Google Play filtre votre application en fonction de ses fonctionnalités et autorisations déclarées. Pour ce faire, exécutez aapt2 à l'aide de la commande dump badging. aapt2 analyse alors le fichier manifeste de votre application et applique les mêmes règles que celles utilisées par Google Play pour déterminer les fonctionnalités requises par l'application.

Pour utiliser cet outil, procédez comme suit :

Créez et exportez votre application en tant qu'APK non signé. Si vous effectuez le développement dans Android Studio, créez votre application avec Gradle, comme suit :
1. Ouvrez le projet et sélectionnez Run > Edit Configurations (Exécuter > Modifier les configurations).
2. Sélectionnez le signe plus en haut à gauche de la fenêtre Exécuter/Déboguer les configurations.
3. Sélectionnez Gradle.
4. Dans le champ Name (Nom), saisissez "Unsigned APK" (APK non signé).
5. Choisissez votre module dans la section Gradle project (Projet Gradle).
6. Saisissez "assemble" dans Tasks (Tâches).
7. Sélectionnez OK pour terminer la nouvelle configuration.
8. Assurez-vous que la configuration d'exécution Unsigned APK (APK non signé) est sélectionnée dans la barre d'outils, puis choisissez Run > Run 'Unsigned APK' (Exécuter > Exécuter "APK non signé").
Vous trouverez l'APK non signé dans le répertoire <ProjectName>/app/build/outputs/apk/.
Recherchez l'outil aapt2 s'il ne se trouve pas déjà dans la variable PATH. Si vous utilisez la version r8 ou ultérieure de SDK Tools, vous trouverez aapt2 dans le répertoire <SDK>/build-tools/<tools version number>.
Remarque : Vous devez utiliser la version d'aapt2 fournie pour le dernier composant Build-Tools disponible. Si vous ne disposez pas du dernier composant Build-Tools, téléchargez-le à l'aide d'Android SDK Manager.
Exécutez aapt2 via la syntaxe suivante :

$ aapt2 dump badging <path_to_exported_.apk>

Voici un exemple de résultat de la commande pour le deuxième exemple Bluetooth présenté précédemment :

$ ./aapt2 dump badging BTExample.apk
package: name='com.example.android.btexample' versionCode='' versionName=''
uses-permission:'android.permission.BLUETOOTH_ADMIN'
uses-feature:'android.hardware.bluetooth'
sdkVersion:'3'
targetSdkVersion:'5'
application: label='BT Example' icon='res/drawable/app_bt_ex.png'
launchable activity name='com.example.android.btexample.MyActivity'label='' icon=''
uses-feature:'android.hardware.touchscreen'
main
supports-screens: 'small' 'normal' 'large'
locales: '--_--'
densities: '160'

Documentation de référence sur les fonctionnalités

Les sections suivantes fournissent des informations de référence sur les fonctionnalités matérielles et logicielles, ainsi que sur les ensembles d'autorisations impliquant des exigences de fonctionnalité spécifiques.

Fonctionnalités matérielles

Cette section présente les fonctionnalités matérielles compatibles avec la dernière version de la plate-forme. Pour indiquer que votre application utilise ou nécessite une fonctionnalité matérielle, déclarez la valeur correspondante (en commençant par "android.hardware") dans un attribut android:name. Utilisez chaque fois un élément <uses-feature> distinct.

Fonctionnalités matérielles audio

android.hardware.audio.low_latency: L'application utilise le pipeline audio à faible latence de l'appareil, ce qui réduit les retards et les délais de traitement des entrées et sorties audio.
android.hardware.audio.output: L'application transmet le son à l'aide des haut-parleurs de l'appareil, du connecteur audio, de fonctionnalités de streaming Bluetooth ou d'un mécanisme similaire.
android.hardware.audio.pro: L'application utilise les fonctionnalités audio et les performances haut de gamme de l'appareil.
android.hardware.microphone: L'application enregistre le son à l'aide du micro de l'appareil.

Fonctionnalités matérielles Bluetooth

android.hardware.bluetooth: L'application utilise les fonctionnalités Bluetooth de l'appareil, généralement pour communiquer avec d'autres appareils sur lesquels le Bluetooth est activé.
android.hardware.bluetooth_le: L'application utilise les fonctionnalités radio Bluetooth à basse consommation de l'appareil.

Fonctionnalités matérielles liées à la caméra

Remarque : Pour éviter de filtrer inutilement votre application en fonction de Google Play, ajoutez android:required="false" à n'importe quelle fonctionnalité de caméra que votre application ne peut pas utiliser. Sinon, Google Play suppose que la fonctionnalité est requise et empêche les appareils non compatibles d'accéder à votre application.

Compatibilité avec les grands écrans

Certains appareils à grand écran ne sont pas compatibles avec toutes les fonctionnalités de l'appareil photo. Les Chromebooks ne sont généralement pas équipés d'une caméra à l'arrière, d'une mise au point automatique ni d'un flash. Toutefois, ils disposent d'une caméra avant (tournée vers l'utilisateur) et sont souvent connectés à des équipements externes.

Pour que votre application soit compatible avec le plus d'appareils possible, ajoutez les paramètres de fonctionnalité de caméra suivants au fichier manifeste de l'application :

<uses-feature android:name="android.hardware.camera.any" android:required="false" />
<uses-feature android:name="android.hardware.camera" android:required="false" />
<uses-feature android:name="android.hardware.camera.autofocus" android:required="false" />
<uses-feature android:name="android.hardware.camera.flash" android:required="false" />

Ajustez les paramètres de la fonctionnalité selon les cas d'utilisation de votre application. Toutefois, pour rendre votre application disponible sur le plus grand nombre d'appareils possible, incluez toujours l'attribut required afin de spécifier explicitement si une fonctionnalité est indispensable.

Liste des fonctionnalités

android.hardware.camera.any

L'application utilise l'une des caméras de l'appareil ou une caméra externe connectée à celui-ci. Utilisez cette fonctionnalité à la place d'android.hardware.camera ou android.hardware.camera.front si votre application n'a pas besoin d'orienter la caméra vers l'extérieur ou vers l'utilisateur, respectivement.

L'autorisation CAMERA implique que votre application utilise également android.hardware.camera. Une caméra arrière est une fonctionnalité obligatoire, sauf si android.hardware.camera est déclaré avec android:required="false".

android.hardware.camera

L'application utilise la caméra arrière de l'appareil.

Attention : Cette fonctionnalité est indisponible sur les appareils équipés seulement d'une caméra avant (côté utilisateur), comme les Chromebook. Utilisez android.hardware.camera.any si votre application peut utiliser n'importe quelle caméra, quelle que soit son orientation.

Remarque : L'autorisation CAMERA implique qu'une caméra arrière est requise. Pour garantir un filtrage approprié sur Google Play lorsque le fichier manifeste de votre application inclut l'autorisation CAMERA, spécifiez explicitement qu'elle utilise la fonctionnalité camera et indiquez si elle est requise :
<uses-feature android:name="android.hardware.camera" android:required="false" />

android.hardware.camera.front

L'application utilise la caméra avant (orientée vers l'utilisateur) de l'appareil.

Attention : Si votre application utilise android.hardware.camera.front, mais ne déclare pas explicitement android.hardware.camera avec android.required="false", les appareils sans caméra arrière (comme les Chromebooks) seront filtrés par Google Play. Si votre application n'accepte les appareils qu'avec les caméras avant, déclarez android.hardware.camera avec android.required="false" pour éviter tout filtrage inutile.

android.hardware.camera.external

L'application communique avec une caméra externe sur laquelle l'utilisateur se connecte à l'appareil. Cette fonctionnalité ne garantit pas l'utilisation d'une caméra externe pour votre application.

android.hardware.camera.autofocus

L'application utilise la fonctionnalité de mise au point automatique compatible avec la caméra de l'appareil.

Remarque : L'autorisation CAMERA implique que la mise au point automatique est une fonctionnalité requise. Pour garantir un filtrage approprié sur Google Play lorsque le fichier manifeste de votre application inclut l'autorisation CAMERA, spécifiez explicitement que votre application utilise la fonctionnalité de mise au point automatique et indiquez si elle est requise ou non :
<uses-feature android:name="android.hardware.camera.autofocus" android:required="false" />.

android.hardware.camera.flash

L'application utilise la fonctionnalité flash compatible avec l'appareil photo de votre appareil.

android.hardware.camera.capability.manual_post_processing

L'application utilise la fonctionnalité MANUAL_POST_PROCESSING compatible avec la caméra de votre appareil.

Elle permet à votre application d'ignorer la fonctionnalité de balance des blancs automatique de l'appareil photo. Utilisez android.colorCorrection.transform, android.colorCorrection.gains, ainsi qu'un mode android.colorCorrection.mode défini sur TRANSFORM_MATRIX.

android.hardware.camera.capability.manual_sensor

L'application utilise la fonctionnalité MANUAL_SENSOR compatible avec la caméra de l'appareil.

Cette fonctionnalité implique la prise en charge du verrouillage automatique de l'exposition (android.control.aeLock), qui permet de définir le temps d'exposition et la sensibilité de l'appareil photo à des valeurs spécifiques.

android.hardware.camera.capability.raw

L'application utilise la fonctionnalité RAW compatible avec la caméra de votre appareil.

Cette fonctionnalité implique que l'appareil peut enregistrer des fichiers DNG (bruts). La caméra fournit les métadonnées DNG dont votre application a besoin pour traiter directement les images brutes.

android.hardware.camera.level.full

L'application utilise le niveau de prise en charge FULL de la capture d'image fourni par au moins une des caméras de l'appareil. La compatibilité FULL inclut des fonctionnalités de capture intensive, par contrôle de frame et par contrôle de post-traitement manuel. Voir INFO_SUPPORTED_HARDWARE_LEVEL_FULL pour plus d'informations.

Fonctionnalités matérielles liées à l'UI de l'appareil

android.hardware.type.automotive

L'application est conçue pour afficher son UI sur un ensemble d'écrans à bord d'un véhicule. L'utilisateur interagit avec l'application à l'aide de boutons physiques, de commandes tactiles et d'interfaces de type souris. Les écrans du véhicule apparaissent généralement dans la console centrale ou au niveau du combiné d'instruments. Ces écrans ont généralement une taille et une résolution limitées.

Remarque : Comme l'utilisateur interagit avec ce type d'UI applicative tout en conduisant, l'application doit réduire au maximum les distractions au volant.

android.hardware.type.television

(Obsolète : utilisez plutôt android.software.leanback.)

L'application est conçue pour afficher son UI sur un téléviseur. Cette fonctionnalité définit le concept de "télévision" en tant qu'expérience TV classique : elle s'affiche sur un grand écran auquel l'utilisateur fait face, assis à une certaine distance, et où la forme d'entrée principale est semblable à un pavé directionnel au lieu d'une souris, d'un pointeur ou d'un appareil tactile.

android.hardware.type.watch

L'application est conçue pour afficher son UI sur une montre. Une montre se porte généralement au poignet. L'utilisateur est donc très proche de l'appareil lorsqu'il interagit avec lui.

android.hardware.type.pc

L'application est conçue pour afficher son UI (interface utilisateur) sur les Chromebooks. Cette fonctionnalité désactive l'émulation de saisie pour la souris et le pavé tactile, car les Chromebooks disposent de ce type de matériel. Consultez Saisie à la souris.

Remarque : définissez required="false" pour cet élément. Si vous ne le faites pas, Google Play Store rendra votre application indisponible pour les appareils autres que les Chromebooks.

Fonctionnalités matérielles liées aux empreintes digitales

android.hardware.fingerprint: L'application lit les empreintes digitales à l'aide du matériel biométrique de l'appareil.

Fonctionnalités matérielles liées aux manettes

android.hardware.gamepad: L'application capture l'entrée du contrôleur de jeu, soit depuis l'appareil lui-même, soit à partir d'une manette connectée.

Fonctionnalités matérielles infrarouges

android.hardware.consumerir: L'application utilise les fonctionnalités infrarouges (IR) de l'appareil, généralement pour communiquer avec d'autres appareils infrarouges grand public.

Fonctionnalités matérielles de localisation

android.hardware.location

L'application utilise une ou plusieurs fonctionnalités de l'appareil pour déterminer la géolocalisation, comme la position GPS, réseau ou cellulaire.

android.hardware.location.gps

L'application utilise des coordonnées de localisation précises obtenues à partir d'un récepteur GPS sur l'appareil.

En utilisant cette fonctionnalité, l'application implique qu'elle utilise également android.hardware.location, sauf si cette fonctionnalité parente est déclarée avec l'attribut android:required="false".

android.hardware.location.network

L'application utilise des coordonnées de localisation générales obtenues à partir d'un système de géolocalisation basé sur le réseau compatible avec l'appareil.

Fonctionnalités matérielles NFC

android.hardware.nfc: L'application utilise les fonctionnalités de communication NFC de l'appareil.
android.hardware.nfc.hce: L'application utilise l'émulation de carte NFC hébergée sur l'appareil.

Fonctionnalités matérielles OpenGL ES

android.hardware.opengles.aep: L'application utilise le pack d'extensions Android OpenGL ES installé sur l'appareil.

Fonctionnalités matérielles des capteurs

android.hardware.sensor.accelerometer: L'application utilise les mesures de mouvements de l'accéléromètre de l'appareil pour détecter son orientation actuelle. Ce faisant, l'application peut par exemple déterminer à quel moment elle doit basculer entre un affichage en mode portrait et paysage.
android.hardware.sensor.ambient_temperature: L'application utilise le capteur de température ambiante (environnement). Exemple : une application météo indique la température en intérieur ou en extérieur.
android.hardware.sensor.barometer: L'application utilise le baromètre de l'appareil. Exemple : une application météo indique la pression atmosphérique.
android.hardware.sensor.compass: L'application utilise le magnétomètre (la boussole) de l'appareil. Exemple : une application de navigation affiche la direction actuelle d'un utilisateur.
android.hardware.sensor.gyroscope: L'application utilise le gyroscope de l'appareil pour détecter la rotation et l'inclinaison, créant ainsi un système d'orientation à six axes. Grâce à ce capteur, une application peut détecter plus facilement le moment où il est nécessaire de passer du mode portrait au mode paysage, ou inversement.
android.hardware.sensor.hifi_sensors: L'application utilise les capteurs haute fidélité (Hi-Fi) de l'appareil. Exemple : une application de jeu vidéo détecte les mouvements haute précision de l'utilisateur.
android.hardware.sensor.heartrate: L'application utilise le cardiofréquencemètre de l'appareil. Exemple : une application de fitness indique l'évolution des tendances de la fréquence cardiaque d'un utilisateur.
android.hardware.sensor.heartrate.ecg: L'application utilise le capteur de fréquence cardiaque (ECG) de l'appareil. Exemple : une application de fitness fournit des informations plus détaillées sur la fréquence cardiaque d'un utilisateur.
android.hardware.sensor.light: L'application utilise le capteur de luminosité de l'appareil. Exemple : une application affiche un jeu de couleurs différents en fonction des conditions d'éclairage ambiant.
android.hardware.sensor.proximity: L'application utilise le capteur de proximité de l'appareil. Exemple : une application de téléphonie éteint l'écran de l'appareil lorsqu'elle détecte que l'utilisateur tient l'appareil à proximité de son oreille.
android.hardware.sensor.relative_humidity: L'application utilise le capteur d'humidité relative de l'appareil. Exemple : une application météo utilise le taux d'humidité pour calculer et indiquer le point de rosée actuel.
android.hardware.sensor.stepcounter: L'application utilise le compteur de pas de l'appareil. Exemple : une application de fitness indique le nombre de pas qu'un utilisateur doit effectuer pour atteindre son objectif quotidien.
android.hardware.sensor.stepdetector: L'application utilise le détecteur de pas de l'appareil. Exemple : une application de fitness utilise l'intervalle de temps entre les étapes pour déduire le type d'exercice effectué par l'utilisateur.

Fonctionnalités matérielles de l'écran

android.hardware.screen.landscape

android.hardware.screen.portrait

L'application nécessite que l'appareil utilise l'orientation portrait ou paysage. Si votre application est compatible avec ces deux modes, vous n'avez pas besoin de déclarer l'une ou l'autre des fonctionnalités.

Par exemple, si votre application nécessite l'orientation portrait, vous devez déclarer la fonctionnalité suivante afin que seuls les appareils compatibles avec l'orientation portrait (toujours ou par choix de l'utilisateur) puissent l'exécuter :

<uses-feature android:name="android.hardware.screen.portrait" />

Les deux orientations sont supposées ne pas être requises par défaut. Votre application peut donc être installée sur les appareils compatibles avec l'une ou l'autre des orientations. Toutefois, si l'une de vos activités demande une exécution spécifique à l'aide de l'attribut android:screenOrientation, cette déclaration implique que votre application nécessite cette orientation.

Par exemple, si vous déclarez android:screenOrientation avec "landscape", "reverseLandscape" ou "sensorLandscape", votre application ne sera disponible que sur les appareils compatibles avec l'orientation paysage.

Nous vous recommandons de déclarer votre exigence pour cette orientation à l'aide d'un élément <uses-feature>. Si vous déclarez un mode d'affichage pour votre activité à l'aide de android:screenOrientation, mais que vous n'en avez pas besoin, vous pouvez désactiver l'exigence de conformité en déclarant l'orientation avec un élément <uses-feature> et inclure android:required="false".

Pour assurer la rétrocompatibilité, tous les appareils équipés d'Android 3.1 (niveau d'API 12) ou d'une version antérieure sont compatibles avec les orientations paysage et portrait.

Fonctionnalités matérielles de téléphonie

android.hardware.telephony

L'application utilise les fonctionnalités de téléphonie de l'appareil, par exemple la radiotéléphonie avec des services de communication de données.

android.hardware.telephony.cdma

L'application utilise le système de radiotéléphonie d'accès multiple par différence de code (AMDC).

En utilisant cette fonctionnalité, l'application implique qu'elle utilise également android.hardware.telephony, sauf si cette fonctionnalité parente est déclarée avec l'attribut android:required="false".

android.hardware.telephony.gsm

L'application utilise le système de radiotéléphonie GSM (Global System for Mobile Communications).

Fonctionnalités matérielles de l'écran tactile

android.hardware.faketouch

L'application utilise les événements d'interaction tactile de base (appuyer, faire glisser, etc.).

Lorsqu'elle est déclarée comme obligatoire, cette fonctionnalité indique que l'application n'est compatible avec un appareil que si celui-ci émule un écran tactile simulé ou s'il dispose d'un écran tactile réel.

Un appareil doté d'une interface tactile simulée fournit un système de saisie utilisateur qui émule un sous-ensemble des fonctionnalités d'un écran tactile. Par exemple, une souris ou une télécommande peut orienter un curseur à l'écran.

Si votre application nécessite une interaction de base de type "pointer et cliquer" et qu'elle ne fonctionne pas uniquement avec un pavé directionnel, déclarez cette fonctionnalité. Comme il s'agit du niveau minimal d'interaction tactile, vous pouvez également utiliser une application qui déclare cette fonctionnalité sur les appareils offrant des interfaces tactiles plus complexes.

Remarque : Les applications nécessitent la fonctionnalité android.hardware.faketouch par défaut. Si vous souhaitez que votre application se limite aux appareils dotés d'un écran tactile, vous devez l'indiquer explicitement :

<uses-feature android:name="android.hardware.touchscreen"
    android:required="true" />

Toutes les applications qui ne nécessitent pas explicitement l'autorisation android.hardware.touchscreen, comme illustré dans l'exemple suivant, fonctionnent également sur les appareils avec android.hardware.faketouch.

<uses-feature android:name="android.hardware.touchscreen" android:required="false" />

android.hardware.faketouch.multitouch.distinct

L'application détecte et suit les commandes à deux doigts ou plus sur une interface tactile simulée. Il s'agit d'un sur-ensemble de la fonctionnalité android.hardware.faketouch. Lorsqu'elle est déclarée comme obligatoire, cette fonctionnalité indique que l'application n'est compatible avec un appareil que si celui-ci émule un suivi distinct de deux doigts ou plus, ou dispose d'un écran tactile réel.

Contrairement au multipoint distinct défini par android.hardware.touchscreen.multitouch.distinct, les périphériques d'entrée qui acceptent le multipoint distinct avec une interface tactile simulée ne sont pas compatibles avec les gestes à deux doigts, car l'entrée est transformée en mouvement de curseur sur l'écran. Autrement dit, sur un tel appareil, les gestes à un doigt déplacent le curseur, les gestes à deux doigts provoquent des événements tactiles à un doigt, tandis que les autres gestes à deux doigts déclenchent l'événement tactile correspondant.

Un appareil doté d'un pavé tactile à deux doigts pour déplacer le curseur est compatible avec cette fonctionnalité.

android.hardware.faketouch.multitouch.jazzhand

L'application détecte et suit les commandes à cinq doigts ou plus sur une interface tactile simulée. Il s'agit d'un sur-ensemble de la fonctionnalité android.hardware.faketouch. Lorsqu'elle est déclarée comme obligatoire, cette fonctionnalité indique que l'application n'est compatible avec un appareil que si celui-ci émule un suivi distinct de cinq doigts ou plus, ou dispose d'un écran tactile réel.

Contrairement au multipoint distinct défini par android.hardware.touchscreen.multitouch.jazzhand, les périphériques d'entrée qui acceptent le multipoint jazzhand avec une interface tactile simulée ne sont pas compatibles avec les gestes à cinq doigts, car l'entrée est transformée en mouvement de curseur sur l'écran. Autrement dit, sur un tel appareil, les gestes à un doigt déplacent le curseur, les gestes à plusieurs doigts provoquent des événements tactiles à un doigt, tandis que les autres gestes à plusieurs doigts déclenchent l'événement tactile correspondant.

Un appareil doté d'un pavé tactile à cinq doigts pour déplacer le curseur est compatible avec cette fonctionnalité.

android.hardware.touchscreen

L'application utilise les fonctionnalités de l'écran tactile de l'appareil pour les gestes plus interactifs que les événements tactiles de base, par exemple l'action de faire glisser d'un geste vif. Il s'agit d'un sur-ensemble de la fonctionnalité android.hardware.faketouch.

Par défaut, toutes les applications nécessitent cette fonctionnalité et ne sont donc pas disponibles pour les appareils qui ne proposent qu'une interface tactile simulée. Pour que votre application soit disponible sur les appareils dotés d'une interface tactile simulée, ou même sur des appareils ne disposant que d'un pavé directionnel, déclarez explicitement qu'un écran tactile n'est pas nécessaire en utilisant android.hardware.touchscreen avec android:required="false". Ajoutez cette déclaration si votre application utilise une véritable interface tactile, mais ne l'exige pas. Toutes les applications qui ne requièrent pas explicitement l'autorisation android.hardware.touchscreen fonctionneront également sur les appareils avec android.hardware.faketouch.

Si votre application nécessite une interface tactile, par exemple pour effectuer des gestes tactiles plus avancés comme les glissements d'un geste vif, vous n'avez pas besoin de déclarer les fonctionnalités de l'interface tactile, car elles sont requises par défaut. Toutefois, il est préférable de déclarer explicitement toutes les fonctionnalités qu'utilise votre application.

Si vous avez besoin d'interactions tactiles plus complexes, telles que des gestes à plusieurs doigts, déclarez que votre application utilise les fonctionnalités avancées de l'écran tactile.

android.hardware.touchscreen.multitouch

L'application utilise les fonctionnalités multipoint de base à deux points, telles que le pincement, mais elle n'a pas besoin de suivre les gestes de façon indépendante. Il s'agit d'un sur-ensemble de la fonctionnalité android.hardware.touchscreen.

En utilisant cette fonctionnalité, l'application implique qu'elle utilise également android.hardware.touchscreen, sauf si cette fonctionnalité parente est déclarée avec l'attribut android:required="false".

android.hardware.touchscreen.multitouch.distinct

L'application utilise les fonctionnalités multipoint avancées de l'appareil pour suivre deux points ou plus indépendamment. Il s'agit d'un sur-ensemble de la fonctionnalité android.hardware.touchscreen.multitouch.

En utilisant cette fonctionnalité, l'application implique qu'elle utilise également android.hardware.touchscreen.multitouch, sauf si cette fonctionnalité parente est déclarée avec l'attribut android:required="false".

android.hardware.touchscreen.multitouch.jazzhand

L'application utilise les fonctionnalités multipoint avancées de l'appareil pour suivre cinq points ou plus indépendamment. Il s'agit d'un sur-ensemble de la fonctionnalité android.hardware.touchscreen.multitouch.

Fonctionnalités matérielles USB

android.hardware.usb.accessory: L'application se comporte comme un périphérique USB et se connecte aux hôtes USB.
android.hardware.usb.host: L'application utilise les accessoires USB connectés à l'appareil. L'appareil sert d'hôte USB.

Fonctionnalités matérielles Vulkan

android.hardware.vulkan.compute

L'application utilise les fonctionnalités de calcul Vulkan. Cette fonctionnalité indique que l'application nécessite la mise en œuvre de Vulkan avec accélération matérielle. La version indique le niveau des fonctionnalités de calcul facultatives requises par l'application au-delà des exigences de Vulkan 1.0. Par exemple, si votre application nécessite la compatibilité avec le niveau de calcul 0 de Vulkan, déclarez la fonctionnalité suivante:

<uses-feature
    android:name="android.hardware.vulkan.compute"
    android:version="0"
    android:required="true" />

Pour en savoir plus sur la version de la fonctionnalité, consultez


    FEATURE_VULKAN_HARDWARE_COMPUTE

android.hardware.vulkan.level

L'application utilise les fonctionnalités de niveau Vulkan. Cette fonctionnalité indique que l'application nécessite la mise en œuvre de Vulkan avec accélération matérielle. La version indique le niveau des fonctionnalités matérielles facultatives requises par l'application. Par exemple, si votre application nécessite le niveau de matériel Vulkan 0 , déclarez la fonctionnalité suivante:

<uses-feature
    android:name="android.hardware.vulkan.level"
    android:version="0"
    android:required="true" />

Pour en savoir plus sur la version de la fonctionnalité, consultez


    FEATURE_VULKAN_HARDWARE_LEVEL

android.hardware.vulkan.version

L'application utilise Vulkan. Cette fonctionnalité indique que l'application nécessite la mise en œuvre de Vulkan avec accélération matérielle. La version de la fonctionnalité indique la version minimale compatible avec l'API Vulkan requise par l'application. Par exemple, si votre application nécessite la compatibilité avec Vulkan 1.0, déclarez le fonctionnalité suivante:

<uses-feature
    android:name="android.hardware.vulkan.version"
    android:version="0x400003"
    android:required="true" />

Pour en savoir plus sur la version de la fonctionnalité, consultez


    FEATURE_VULKAN_HARDWARE_VERSION

Fonctionnalités matérielles Wi-Fi

android.hardware.wifi: L'application utilise les fonctionnalités de réseau 802.11 (Wi-Fi) de l'appareil.
android.hardware.wifi.direct: L'application utilise les fonctionnalités de réseau Wi-Fi Direct de l'appareil.

Fonctionnalités logicielles

Cette section présente les fonctionnalités logicielles compatibles avec la dernière version de la plate-forme. Pour indiquer que votre application utilise ou nécessite une fonctionnalité logicielle, déclarez la valeur correspondante (en commençant par "android.software") dans un attribut android:name. Chaque fois que vous déclarez une fonctionnalité logicielle, utilisez un élément <uses-feature> distinct.

Fonctionnalités logicielles de communication

android.software.sip

L'application utilise les services SIP (Session Initiation Protocol). Elle peut ainsi prendre en charge les opérations de téléphonie sur Internet, telles que la visioconférence et la messagerie instantanée.

android.software.sip.voip

L'application utilise des services VoIP basés sur SIP. Grâce à la technologie VoIP, l'application peut prendre en charge les opérations de téléphonie Internet en temps réel, telles que les visioconférences bidirectionnelles.

En utilisant cette fonctionnalité, l'application implique qu'elle utilise également android.software.sip, sauf si cette fonctionnalité parente est déclarée avec l'attribut android:required="false".

android.software.webview

L'application affiche du contenu provenant d'Internet.

Fonctionnalités logicielles d'entrée personnalisée

android.software.input_methods: L'application utilise un nouveau mode de saisie, que le développeur définit dans un élément InputMethodService.

Fonctionnalités logicielles de gestion de l'appareil

android.software.backup: L'application inclut une logique pour gérer les opérations de sauvegarde et de restauration.
android.software.device_admin: L'application utilise des administrateurs d'appareils pour appliquer une règle relative aux appareils.
android.software.managed_users: L'application est compatible avec les profils gérés et les utilisateurs secondaires.
android.software.securely_removes_users: L'application peut supprimer définitivement les utilisateurs et leurs données associées.
android.software.verified_boot: L'application inclut une logique permettant de gérer les résultats de la fonctionnalité de démarrage validé de l'appareil, qui détecte si la configuration de l'appareil change lors d'une opération de redémarrage.

Fonctionnalités logicielles multimédias

android.software.midi: L'application se connecte aux instruments de musique ou émet un son à l'aide du protocole MIDI (Musical Instrument Digital Interface).
android.software.print: L'application inclut des commandes permettant d'imprimer les documents affichés sur l'appareil.
android.software.leanback: L'application est conçue pour s'exécuter sur des appareils Android TV.
android.software.live_tv: L'application diffuse des émissions de télévision en direct.

Fonctionnalités logicielles liées aux interfaces d'écran

android.software.app_widgets: L'application utilise ou fournit des widgets. Elle est destinée uniquement aux appareils dotés d'un écran d'accueil ou d'un emplacement similaire, où les utilisateurs peuvent intégrer des widgets applicatifs.
android.software.home_screen: L'application remplace l'écran d'accueil de l'appareil.
android.software.live_wallpaper: L'application utilise ou fournit des fonds d'écran qui incluent des animations.

Autorisations impliquant des exigences de fonctionnalités

Certaines constantes de fonctionnalités matérielles et logicielles sont mises à la disposition des applications après l'API correspondante. De ce fait, certaines applications peuvent utiliser l'API avant de déclarer qu'elles la nécessitent via le système <uses-feature>.

Pour éviter que ces applications soient rendues disponibles involontairement, Google Play part du principe que certaines autorisations liées au matériel indiquent que les fonctionnalités matérielles sous-jacentes sont requises par défaut. Par exemple, les applications qui utilisent le Bluetooth doivent demander l'autorisation BLUETOOTH dans un élément <uses-permission>.

Pour les anciennes applications, Google Play suppose que la déclaration d'autorisation signifie que la fonctionnalité android.hardware.bluetooth sous-jacente est requise par l'application et configure le filtrage en fonction de cette fonctionnalité. Le tableau 2 présente les autorisations qui impliquent des exigences de fonctionnalité équivalentes à celles déclarées dans les éléments <uses-feature>.

Les déclarations <uses-feature>, y compris tout attribut android:required déclaré, ont toujours priorité sur les fonctionnalités impliquées par les autorisations dans le tableau 2. Pour chacune de ces autorisations, vous pouvez désactiver le filtrage en fonction de la fonctionnalité implicite en déclarant explicitement la fonctionnalité dans un élément <uses-feature> avec l'attribut required défini sur false.

Par exemple, pour désactiver le filtrage en fonction de l'autorisation CAMERA, ajoutez les déclarations <uses-feature> suivantes au fichier manifeste :

<uses-feature android:name="android.hardware.camera" android:required="false" />
<uses-feature android:name="android.hardware.camera.autofocus" android:required="false" />

Attention : Si votre application cible Android 5.0 (niveau d'API 21) ou une version ultérieure, et qu'elle utilise l'autorisation ACCESS_COARSE_LOCATION ou ACCESS_FINE_LOCATION afin de recevoir les mises à jour de position du réseau ou d'un GPS, vous devez également déclarer explicitement que votre application utilise les fonctionnalités matérielles android.hardware.location.network ou android.hardware.location.gps.

Tableau 2. Autorisations liées à l'utilisation matérielle de l'appareil.

Catégorie	Autorisation	Fonctionnalité implicite requise
Bluetooth	`BLUETOOTH`	`android.hardware.bluetooth` Pour en savoir plus, consultez la section Traitement spécial de la fonctionnalité Bluetooth.
Bluetooth	`BLUETOOTH_ADMIN`	`android.hardware.bluetooth`
Caméra	`CAMERA`	`android.hardware.camera` `android.hardware.camera.autofocus`
Localisation	`ACCESS_MOCK_LOCATION`	`android.hardware.location`
	`ACCESS_LOCATION_EXTRA_COMMANDS`	`android.hardware.location`
	`INSTALL_LOCATION_PROVIDER`	`android.hardware.location`
	`ACCESS_COARSE_LOCATION`	`android.hardware.location` `android.hardware.location.network`(Uniquement lorsque le niveau d'API cible est inférieur ou égal à 20.)
	`ACCESS_FINE_LOCATION`	`android.hardware.location` `android.hardware.location.gps`(Uniquement lorsque le niveau d'API cible est inférieur ou égal à 20.)
Micro	`RECORD_AUDIO`	`android.hardware.microphone`
Téléphonie	`CALL_PHONE`	`android.hardware.telephony`
	`CALL_PRIVILEGED`	`android.hardware.telephony`
	`MODIFY_PHONE_STATE`	`android.hardware.telephony`
	`PROCESS_OUTGOING_CALLS`	`android.hardware.telephony`
	`READ_SMS`	`android.hardware.telephony`
	`RECEIVE_SMS`	`android.hardware.telephony`
	`RECEIVE_MMS`	`android.hardware.telephony`
	`RECEIVE_WAP_PUSH`	`android.hardware.telephony`
	`SEND_SMS`	`android.hardware.telephony`
	`WRITE_APN_SETTINGS`	`android.hardware.telephony`
	`WRITE_SMS`	`android.hardware.telephony`
Wi-Fi	`ACCESS_WIFI_STATE`	`android.hardware.wifi`
	`CHANGE_WIFI_STATE`	`android.hardware.wifi`
	`CHANGE_WIFI_MULTICAST_STATE`	`android.hardware.wifi`