Google Play utilise les éléments <uses-feature> déclarés dans le fichier manifeste de votre application pour filtrer celle-ci et l'exclure des appareils non conformes à ses exigences matérielles et logicielles.

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 ci-dessous.

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 sont présentées dans la section Documentation de référence sur les fonctionnalités au bas 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éclare 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, vous devez toujours veiller à déclarer les éléments <uses-feature> pour l'ensemble 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 (en vous appuyant sur la liste ci-dessous) qu'utilise votre application.

Certaines fonctionnalités acceptent un attribut spécifique qui vous permet d'en définir la version (en déclarant par exemple glEsVersion pour Open GL). 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 tout simplement l'élément.

Remarque : Lorsque vous déclarez une fonctionnalité, n'oubliez pas, le cas échéant, que vous devez également demander des autorisations. Par exemple, vous devez toujours 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.
  • Lorsque vous déclarez android:required="true" pour une fonctionnalité, vous indiquez que l'application ne peut pas fonctionner ou n'est pas conçue pour fonctionner sans la présence de cette fonctionnalité sur l'appareil.
  • Lorsque vous déclarez android:required="false" pour une fonctionnalité, cela signifie que l'application préfère utiliser cette fonctionnalité si elle est présente sur l'appareil, mais qu'elle est conçue pour fonctionner sans, si nécessaire.

La valeur par défaut pour android:required, si elle n'est pas déclarée, 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, une application qui nécessite à la fois OpenGL ES 1.0 et 2.0 doit spécifier qu'elle nécessite OpenGL ES 2.0.

Une application compatible avec plusieurs versions d'OpenGL ES ne doit spécifier que la version numérique la plus basse dont elle a besoin (elle peut 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 leurs appareils. 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 – une application déclare des fonctionnalités dans les éléments <uses-feature> de son fichier manifeste.
  • Fonctionnalités disponibles sur l'appareil, sous forme de matériel ou de logiciel – un appareil indique les fonctionnalités compatibles en tant que propriétés système en lecture seule.

Pour garantir la précision de la comparaison, le gestionnaire de packages d'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 au bas de ce document, ainsi que dans la documentation des classes du PackageManager.

Lorsque l'utilisateur lance Google Play, l'application interroge le gestionnaire de packages 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 à l'application .apk 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. Lisez les sections suivantes pour obtenir 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 absolument la fonctionnalité ("true") ou bien si elle préfère l'utiliser, mais qu'elle est conçue pour s'exécuter sans elle ("false").

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

  • Si une fonctionnalité est déclarée comme étant obligatoire, Google Play l'ajoute à la liste des fonctionnalités requises pour l'application. Il filtre ensuite l'application afin qu'elle ne soit pas visible pour les utilisateurs d'appareils qui ne proposent pas cette fonctionnalité. Par exemple :
    <uses-feature android:name="android.hardware.camera.any" android:required="true" />
    
  • Si une fonctionnalité est explicitement déclarée comme non requise, 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 n'assure pas la fonctionnalité déclarée, Google Play considère que l'application est compatible avec l'appareil et la présente à l'utilisateur, sauf si d'autres règles de filtrage s'appliquent. Exemple :
    <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. À proprement parler, chaque application doit toujours déclarer toutes les fonctionnalités qu'elle utilise ou nécessite. Par conséquent, l'absence de déclaration pour une fonctionnalité utilisée par une application doit ê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 une fonctionnalité explicite.

Une application peut nécessiter une fonctionnalité sans la déclarer pour les raisons suivantes :

  • L'application a été compilée sur une ancienne version de la bibliothèque Android (Android 1.5 ou version antérieure), et l'élément <uses-feature> n'était pas disponible.
  • Le développeur a supposé à tort que la fonctionnalité était présente sur tous les appareils et qu'une déclaration n'était pas nécessaire.
  • Le développeur a omis de déclarer la fonctionnalité par erreur.
  • Le développeur a explicitement déclaré la fonctionnalité, mais la déclaration n'était 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 peut invalider la déclaration de fonctionnalités.

Pour tenir compte des cas ci-dessus, 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 de référence Autorisations impliquant des exigences de fonctionnalités présente l'ensemble complet des autorisations impliquant des exigences de fonctionnalité et qui, par conséquent, déclenchent 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 ci-dessus.

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 ci-dessous, 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… ou que 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 ci-dessous 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 elle 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>
Dans le deuxième exemple ci-dessous, la même application déclare également un niveau d'API cible de "5".
Résultat : Google Play suppose que cette fonctionnalité est désormais requise et filtrera l'application sur tous les appareils non compatibles avec le Bluetooth, y compris les appareils exécutant d'anciennes versions de la plate-forme.
<manifest ...>
    <uses-permission android:name="android.permission.BLUETOOTH_ADMIN" />
    <uses-sdk android:minSdkVersion="3" android:targetSdkVersion="5" />
    ...
</manifest>
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>
Enfin, dans le cas ci-dessous, la même application ajoute un attribut android:required="false".
Résultat : Google Play désactive le filtrage en fonction de la compatibilité des fonctionnalités Bluetooth, 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 aapt, inclus dans le SDK Android, pour déterminer comment Google Play filtrera votre application, en fonction de ses fonctionnalités et autorisations déclarées. Pour ce faire, exécutez aapt à l'aide de la commande dump badging. aapt 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 :

  1. Commencez par créer et exporter votre application en tant que fichier .apk non signé. Si vous développez dans Android Studio, créez votre application avec Gradle :
    1. Ouvrez le projet et sélectionnez 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. Saisissez Unsigned APK dans le champ Nom.
    5. Choisissez votre module dans la section Projet Gradle.
    6. Saisissez assemble dans Tâches.
    7. Sélectionnez OK pour terminer la nouvelle configuration.
    8. Assurez-vous que la configuration d'exécution APK non signé est sélectionnée dans la barre d'outils, puis choisissez Exécuter > Exécuter "APK non signé".
    Votre fichier .apk non signé se trouve dans le répertoire <ProjectName>/app/build/outputs/apk/.
  2. Recherchez ensuite l'outil aapt, s'il ne se trouve pas déjà dans votre chemin d'accès. Si vous utilisez la version r8 ou ultérieure de SDK Tools, vous trouverez aapt dans le répertoire <SDK>/build-tools/<tools version number>.

    Remarque : Vous devez utiliser la version d'aapt 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.

  3. Exécutez aapt via la syntaxe suivante :
$ aapt dump badging <path_to_exported_.apk>

Voici un exemple de résultat de commande pour le deuxième exemple Bluetooth ci-dessus :

$ ./aapt 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 de android.hardware.camera ou de android.hardware.camera.front si votre application exige que la caméra soit orientée vers l'arrière (extérieur) ou vers l'avant (utilisateur).

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 appli inclut l'autorisation CAMERA, indiquez explicitement que votre application utilise la fonctionnalité camera et indiquez si elle est nécessaire. Exemple :
<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.

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".

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'est compatible 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.

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.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. Exemple :
<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 de l'appareil photo.

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 : Gardez à l'esprit que, puisque 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 (et rarement une souris, un pointeur ou 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.

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.

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".

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'appli 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 appli 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 s'il est nécessaire de passer du mode portrait au mode paysage.
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. Par conséquent, votre application peut être installée sur des appareils compatibles avec l'une ou les deux 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).

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".

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 s'il émule un écran tactile (interface tactile simulée) ou possède 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 déclencher un curseur à l'écran. Si votre application nécessite une interaction de base de type pointer-cliquer (en d'autres termes, elle ne peut fonctionner avec un pavé directionnel seul), vous devez déclarer 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 fonctionneront é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 multitouch distinct défini par android.hardware.touchscreen.multitouch.distinct, les périphériques d'entrée qui acceptent le multitouch 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 multitouch distinct défini par android.hardware.touchscreen.multitouch.jazzhand, les périphériques d'entrée qui acceptent le multitouch 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.

Votre application nécessite cette fonctionnalité par défaut. Par conséquent, votre application n'est pas disponible sur les appareils qui ne fournissent qu'une interface tactile simulée par défaut. Si vous souhaitez que votre application soit disponible sur des appareils dotés d'une interface tactile simulée (ou même sur des appareils ne disposant que d'un pavé directionnel), vous devez indiquer explicitement qu'un écran tactile n'est pas nécessaire. en déclarant android.hardware.touchscreen avec android:required="false". Vous devez ajouter 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 (pour effectuer des gestes tactiles plus avancés comme l'action de faire glisser d'un gest 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, vous devez déclarer que votre application utilise les fonctionnalités avancées de l'écran tactile.

android.hardware.touchscreen.multitouch

L'application utilise les fonctionnalités multitouch de base à deux doigts de l'appareil, comme 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 multitouch 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 multitouch 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.

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".

Fonctionnalités matérielles USB

android.hardware.usb.accessory
L'application se comporte comme le 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, vous devez déclarer 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 la compatibilité avec le matériel Vulkan de niveau 0, vous devez déclarer 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, vous devez déclarer la 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 ne doit être installée que sur des 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 ont été mises à la disposition des applications après l'API correspondante. Par exemple, la fonctionnalité android.hardware.bluetooth a été ajoutée dans Android 2.2 (API de niveau 8), mais l'API Bluetooth à laquelle elle fait référence a été ajoutée dans Android 2.0 (API de niveau 5). Pour cette raison, certaines applications pouvaient utiliser l'API avant de pouvoir déclarer qu'elles la nécessitent à l'aide du 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 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>.

Notez que les déclarations <uses-feature>, y compris tout attribut android:required déclaré, ont toujours priorité sur les fonctionnalités implicites des 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_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