Filtres sur Google Play

Lorsqu'un utilisateur recherche ou parcourt des applications à télécharger sur Google Play, les résultats sont filtrés en fonction des applications compatibles avec l'appareil. Par exemple, si une application nécessite un appareil photo, Google Play ne la proposera pas aux appareils qui n'en sont pas équipés. Ce filtrage aide les développeurs à gérer la distribution de leurs applications et garantit une expérience optimale aux utilisateurs.

Le filtrage dans Google Play repose sur plusieurs types de paramètres de configuration et de métadonnées d'application, y compris les déclarations de fichiers manifestes, les bibliothèques requises, les dépendances d'architecture et les contrôles de distribution définis dans la Google Play Console, tels que le ciblage géographique, les tarifs, etc.

Le filtrage de Google Play est en partie basé sur des déclarations de fichiers manifestes et d'autres aspects du framework Android, mais les comportements de filtrage réels sont différents du framework et ne sont pas liés à des niveaux d'API spécifiques. Ce document spécifie les règles de filtrage actuelles utilisées par Google Play.

Fonctionnement des filtres sur Google Play

Google Play utilise les restrictions de filtrage décrites ci-dessous pour déterminer si votre application doit être présentée à un utilisateur qui recherche ou parcourt des applications à partir de l'application Google Play.

Pour déterminer si votre application doit être affichée, Google Play vérifie la configuration matérielle et logicielle requise pour l'appareil, ainsi que l'opérateur, la zone géographique et d'autres caractéristiques. Il les compare ensuite aux restrictions et aux dépendances exprimées par le fichier manifeste et les détails de publication de l'application.

Si l'application est compatible avec l'appareil selon les règles de filtrage, Google Play la rend visible à l'utilisateur. Sinon, Google Play masque votre application des résultats de recherche et de la recherche par catégorie, même si un utilisateur demande spécifiquement l'application en cliquant sur un lien profond qui dirige directement vers l'ID de l'application dans Google Play.

Vous pouvez utiliser n'importe quelle combinaison de filtres disponibles pour votre application. Vous pouvez par exemple définir minSdkVersion sur "4" et définir smallScreens="false" dans l'application. Ainsi, lors de la mise en ligne de l'application sur Google Play, vous pouvez cibler uniquement les pays européens (opérateurs). Les filtres de Google Play empêcheront donc l'application d'être disponible sur les appareils qui ne répondent pas à ces trois exigences.

Toutes les restrictions de filtrage sont associées à une version d'une application et peuvent changer d'une version à l'autre. Par exemple, si un utilisateur a installé votre application et que vous publiez une mise à jour rendant l'application invisible, l'utilisateur ne verra pas de mise à jour disponible.

Filtrer sur le site Web de Google Play

Lorsque les utilisateurs parcourent le site Web de Google Play, ils peuvent voir toutes les applications publiées. Le site Web de Google Play compare les exigences de l'application à chacun des appareils enregistrés de l'utilisateur pour la compatibilité et ne permet à l'utilisateur d'installer l'application que si cette dernière est compatible avec son appareil.

Filtrer en fonction du fichier manifeste de l'application

La plupart des filtres sont déclenchés par des éléments du fichier manifeste AndroidManifest.xml de l'application (bien que tous les éléments du fichier manifeste ne puissent pas déclencher de filtrage). Le tableau 1 liste les éléments manifestes que vous devez utiliser pour déclencher le filtrage, et explique comment fonctionne le filtrage pour chaque élément.

Tableau 1 : Éléments du fichier manifeste déclenchant le filtrage sur Google Play.

Élément du fichier manifeste Nom du filtre Comment ça marche
<supports-screens> Taille d'écran

Une application indique les tailles d'écran qu'elle peut accepter en définissant les attributs de l'élément <supports-screens>. Lorsque l'application est publiée, Google Play utilise ces attributs pour déterminer si elle doit être proposée aux utilisateurs, en fonction de la taille de l'écran de leurs appareils.

En règle générale, Google Play part du principe que la plate-forme sur l'appareil peut adapter des mises en page plus petites aux grands écrans, mais qu'elle ne peut pas adapter de grandes mises en pages aux petits écrans. Ainsi, si une application n'accepte que la taille d'écran "normale", Google Play la rend disponible à la fois pour les appareils équipés d'écrans normaux et grands, mais filtre l'application afin qu'elle ne soit pas disponible pour les appareils dotés de petits écrans.

Si une application ne déclare pas d'attributs pour <supports-screens>, Google Play utilise les valeurs par défaut pour ces attributs, qui varient en fonction du niveau d'API. Plus précisément :

  • Pour les applications qui définissent android: minSdkVersion ou android: targetSdkVersion sur 3 ou moins, l'élément <supports-screens> lui-même n'est pas défini et aucun attribut n'est disponible. Dans ce cas, Google Play suppose que l'application est conçue pour les écrans de taille normale et la rend visible aux appareils dotés d'un écran de taille normale ou supérieure.

  • Lorsque android: minSdkVersion ou android: targetSdkVersion est défini sur 4 ou plus, la valeur par défaut pour tous les attributs est "true" (vrai). De cette manière, l'application est considérée comme compatible avec toutes les tailles d'écran par défaut.

Exemple 1
Le fichier manifeste déclare <uses-sdk android:minSdkVersion="3"> et n'inclut pas d'élément <supports-screens>. Résultat : Google Play ne proposera pas l'application aux utilisateurs d'appareils dotés d'un petit écran, mais seulement à ceux possédant un écran normal ou grand, sauf si d'autres filtres s'appliquent.

Exemple 2
Le fichier manifeste déclare <uses-sdk android:minSdkVersion="3" android:targetSdkVersion="4"> et n'inclut pas d'élément <supports-screens>. Résultat : Google Play proposera l'application à tous les utilisateurs, sauf si d'autres filtres s'appliquent.

Exemple 3
Le fichier manifeste déclare <uses-sdk android:minSdkVersion="4"> et n'inclut pas d'élément <supports-screens>. Résultat : Google Play proposera l'application à tous les utilisateurs, sauf si d'autres filtres s'appliquent.

Pour savoir comment déclarer la compatibilité avec les tailles d'écran dans votre application, consultez <supports-screens> et Compatibilité avec plusieurs écrans.

<uses-configuration> Configuration de l'appareil :
clavier, navigation, écran tactile

Une application peut demander certaines fonctionnalités matérielles, et Google Play ne la proposera que sur les appareils disposant du matériel requis.

Exemple 1
Le fichier manifeste inclut <uses-configuration android:reqFiveWayNav="true" />, et un utilisateur recherche des applications sur un appareil qui ne possède pas de commande de navigation à cinq sens. Résultat : Google Play ne proposera pas l'application à l'utilisateur.

Exemple 2
Le fichier manifeste ne comporte pas d'élément <uses-configuration>. Résultat : Google Play proposera l'application à tous les utilisateurs, sauf si d'autres filtres s'appliquent.

Pour en savoir plus, consultez <uses-configuration>.

<uses-feature> Fonctionnalités de l'appareil
(name)

Une application peut nécessiter qu'un appareil soit équipé de certaines fonctionnalités. Cette fonctionnalité a été introduite dans Android 2.0 (niveau d'API 5).

Exemple 1
Le fichier manifeste inclut <uses-feature android:name="android.hardware.sensor.light" />, et un utilisateur recherche des applications sur un appareil qui ne possède pas de capteur de lumière. Résultat : Google Play ne proposera pas l'application à l'utilisateur.

Exemple 2
Le fichier manifeste ne comporte pas d'élément <uses-feature>. Résultat : Google Play proposera l'application à tous les utilisateurs, sauf si d'autres filtres s'appliquent.

Pour en savoir plus, consultez <uses-feature> .

Filtrage basé sur des caractéristiques implicites : dans certains cas, Google Play interprète les autorisations demandées via des éléments <uses-permission> comme des exigences de fonctionnalités équivalentes à celles déclarées dans les éléments <uses-feature>. Voir <uses-permission> ci-dessous.

Version d'OpenGL ES
(openGlEsVersion)

Une application peut exiger que l'appareil prenne en charge une version spécifique d'OpenGL ES à l'aide de l'attribut <uses-feature android:openGlEsVersion="int">.

Exemple 1
Une application demande plusieurs versions d'OpenGL ES en spécifiant openGlEsVersion plusieurs fois dans le fichier manifeste. Résultat : Google Play suppose que l'application exige la version la plus élevée des versions indiquées.

Exemple 2
Une application requiert la version 1.1 d'OpenGL ES, et un utilisateur recherche des applications sur un appareil prenant en charge la version 2.0 d'OpenGL ES. Résultat : Google Play proposera l'application à l'utilisateur, sauf si d'autres filtres s'appliquent. Si un appareil est compatible avec la version X d'OpenGL ES, Google Play suppose qu'il prend également en charge toutes les versions antérieures à X.

Exemple 3
Un utilisateur recherche des applications sur un appareil qui ne signale pas de version d'OpenGL ES (par exemple, un appareil fonctionnant sous Android 1.5 ou version antérieure). Résultat : Google Play suppose que l'appareil n'est compatible qu'avec OpenGL ES 1.0. Google Play ne proposera à l'utilisateur que les applications qui ne spécifient pas openGlEsVersion, ou celles ne spécifiant que des versions d'OpenGL ES antérieures à la version 1.0.

Exemple 4
Le fichier manifeste ne spécifie pas openGlEsVersion. Résultat : Google Play proposera l'application à tous les utilisateurs, sauf si d'autres filtres s'appliquent.

Pour en savoir plus, consultez <uses-feature>.

<uses-library> Bibliothèques de logiciels

Une application peut exiger la présence de bibliothèques partagées spécifiques sur l'appareil.

Exemple 1
Une application exige la bibliothèque com.google.android.maps, et un utilisateur recherche des applications sur un appareil qui ne possède pas la bibliothèque com.google.android.maps Résultat : Google Play ne proposera pas l'application à l'utilisateur.

Exemple 2
Le fichier manifeste ne comporte pas d'élément <uses-library>. Résultat : Google Play proposera l'application à tous les utilisateurs, sauf si d'autres filtres s'appliquent.

Pour en savoir plus, consultez <uses-library>.

<uses-permission>  

Google Play ne filtre pas strictement sur les éléments <uses-permission>. Toutefois, Google Play lit les éléments pour déterminer si l'application présente des exigences en termes de fonctionnalité matérielle qui n'ont peut-être pas été déclarées correctement dans les éléments <uses-feature>. Par exemple, si une application demande l'autorisation CAMERA (appareil photo), mais ne déclare pas d'élément <uses-feature> pour android.hardware.camera, Google Play considère que l'application nécessite un appareil photo et ne doit pas être proposée aux utilisateurs n'en possédant pas.

En général, lorsqu'une application sollicite des autorisations liées au matériel, Google Play suppose qu'elle exige les fonctionnalités matérielles sous-jacentes, même en l'absence de déclarations <uses-feature> correspondantes. Google Play configure ensuite le filtrage en fonction des fonctionnalités implicites des déclarations <uses-feature>.

Pour obtenir la liste des autorisations qui impliquent des fonctionnalités matérielles, consultez les documents concernant l'élément <uses-feature>.

<uses-sdk> Version minimale du framework (minSdkVersion)

Une application peut exiger un niveau d'API minimal.

Exemple 1
Le fichier manifeste inclut <uses-sdk android:minSdkVersion="3">, et l'application utilise des API introduites dans le niveau d'API 3. Un utilisateur recherche des applications sur un appareil disposant du niveau d'API 2. Résultat : Google Play ne proposera pas l'application à l'utilisateur.

Exemple 2
Le fichier manifeste n'inclut pas minSdkVersion, et l'application utilise des API introduites dans le niveau d'API 3. Un utilisateur recherche des applications sur un appareil disposant du niveau d'API 2. Résultat : Google Play suppose que minSdkVersion est "1" et que l'application est compatible avec toutes les versions d'Android. Google Play propose l'application à l'utilisateur et autorise le téléchargement. L'application plante au moment de l'exécution.

Comme vous souhaitez éviter ce scénario, nous vous recommandons de toujours déclarer une minSdkVersion. Pour plus d'informations, consultez android:minSdkVersion.

Version maximale du framework (maxSdkVersion).

Obsolète. Android 2.1 et versions ultérieures ne vérifient pas et n'appliquent pas l'attribut maxSdkVersion. Le SDK ne sera pas compilé si maxSdkVersion est défini dans le fichier manifeste d'une application. Google Play respectera les appareils déjà compilés avec maxSdkVersion et l'utilisera pour le filtrage.

Il n'est pas recommandé de déclarer maxSdkVersion. Pour plus d'informations, consultez android:maxSdkVersion.

Filtres de fichiers manifestes avancés

Outre les éléments du fichier manifeste du tableau 1, Google Play peut également filtrer les applications en fonction des éléments du fichier manifeste du tableau 2.

Ces éléments manifestes et le filtrage qu'ils déclenchent ne sont utilisés que dans des cas d'utilisation exceptionnels. Ils sont conçus pour certains types de jeux hautes performances et d'applications similaires nécessitant des contrôles stricts sur leur distribution. La plupart des applications ne doivent jamais utiliser ces filtres.

Tableau 2 : Éléments de fichiers manifestes avancés pour le filtrage de Google Play.

Élément du fichier manifesteRésumé
<compatible-screens>

Google Play filtre l'application si la taille et la densité de l'écran de l'appareil ne correspondent à aucune des configurations d'écran (déclarées par un élément <screen>) dans l'élément <compatible-screens>.

Attention : normalement, vous ne devez pas utiliser cet élément manifeste. L'utilisation de cet élément peut réduire considérablement la base d'utilisateurs potentielle de votre application, en excluant toutes les combinaisons de taille d'écran et de densité que vous n'avez pas précisées. Vous devez plutôt utiliser l'élément du fichier manifeste <supports-screens> (décrit plus haut dans le tableau 1) pour activer le mode de compatibilité d'écran pour les configurations d'écran que vous n'avez pas prises en compte avec d'autres ressources.

<supports-gl-texture>

Google Play filtre l'application, sauf si un ou plusieurs formats de compression de texture GL compatibles avec l'application sont également compatibles avec l'appareil.

Autres filtres

Google Play utilise d'autres caractéristiques d'application pour déterminer si une application doit être affichée ou masquée sur un appareil donné, comme décrit dans le tableau ci-dessous.

Tableau 3 : Caractéristiques d'application et de publication affectant le filtrage sur Google Play.

Nom du filtre Comment ça marche
État de publication

Seules les applications publiées apparaîtront dans les recherches et la navigation sur Google Play.

Même si une application n'est pas publiée, elle peut être installée si les utilisateurs peuvent la voir dans leurs "Téléchargements", parmi les applications achetées, installées ou récemment désinstallées.

Si une application a été suspendue, les utilisateurs ne pourront pas la réinstaller ni la mettre à jour, même si elle apparaît dans leurs téléchargements.

État des prix

Tous les utilisateurs ne peuvent pas voir les applications payantes. Pour afficher les applications payantes, votre appareil doit être équipé d'Android 1.1 ou version ultérieure, et l'appareil doit être situé dans un pays où les applications payantes sont disponibles. Si un appareil est équipé d'une carte SIM, l'opérateur de la carte SIM détermine si des applications payantes sont disponibles. Si un appareil ne possède pas de carte  SIM, son adresse IP est utilisée pour déterminer si l'appareil se trouve dans un pays où les applications payantes sont disponibles.

Ciblage par pays

Lorsque vous importez votre application sur Google Play, vous pouvez sélectionner les pays dans lesquels elle sera distribuée sous Tarifs et disponibilité. L'application sera alors disponible aux utilisateurs situés dans les pays que vous sélectionnez.

Architecture de processeur (ABI)

Une application qui inclut des bibliothèques natives ciblant une architecture de processeur spécifique (ARM EABI v7 ou x86, par exemple) n'est visible que sur les appareils compatibles avec cette architecture. Pour en savoir plus sur le NDK et l'utilisation des bibliothèques natives, consultez la page Qu'est-ce que le Android NDK ?

Applications protégées contre la copie

Google Play n'est plus compatible avec la fonctionnalité de protection contre la copie dans la Play Console et ne filtre plus les applications en fonction de cette fonctionnalité. Pour sécuriser votre application, veuillez utiliser les licences d'application. Pour en savoir plus, consultez la page Remplacer la protection contre la copie.

Publier plusieurs APK avec différents filtres

Certains filtres Google Play vous permettent de publier plusieurs APK pour une même application afin de fournir un APK différent pour plusieurs configurations d'appareil. Par exemple, si vous créez un jeu vidéo qui utilise des éléments graphiques haute fidélité, vous pouvez créer deux APK compatibles avec différents formats de compression de texture. De cette façon, vous pouvez réduire la taille du fichier APK en incluant uniquement les textures requises pour chaque configuration d'appareil. En fonction de la compatibilité de chaque appareil avec vos formats de compression de texture, Google Play lui fournira l'APK que vous avez déclaré comme compatible avec cet appareil.

Actuellement, Google Play vous permet de publier plusieurs APK pour une même application uniquement lorsque chaque APK fournit des filtres différents en fonction des configurations suivantes :

  • Formats de compression de texture OpenGL

    En utilisant l'élément <supports-gl-texture>.

  • Taille de l'écran (et, éventuellement, densité de l'écran)

    En utilisant l'élément <supports-screens> ou <compatible-screens>.

  • Niveau d'API

    En utilisant l'élément <uses-sdk>.

  • Architecture de processeur (ABI)

    En incluant des bibliothèques natives créées avec Android NDK qui ciblent une architecture de processeur spécifique (ARM EABI v7 ou x86, par exemple).

Tous les autres filtres fonctionnent toujours et de la même façon, mais les quatre filtres ci-dessus sont les seuls à pouvoir distinguer les APK d'une même fiche d'application sur Google Play. Par exemple, vous ne pouvez pas publier plusieurs APK pour la même application si les APK diffèrent seulement selon que l'appareil est équipé d'un appareil photo ou non.

Attention : la publication de plusieurs APK pour une même application est considérée comme étant une fonctionnalité avancée. La plupart des applications ne doivent publier qu'un seul APK compatible avec un large éventail de configurations d'appareils. La publication de plusieurs APK nécessite de suivre des règles spécifiques dans vos filtres et de porter une attention particulière aux codes de version pour chaque APK afin de garantir des chemins de mise à jour corrects pour chaque configuration.

Pour en savoir plus sur la publication de plusieurs APK sur Google Play, consultez la page Compatibilité avec plusieurs fichiers APK.

Voir aussi

  1. Compatibilité avec Android
  2. Compatibilité avec plusieurs fichiers APK