Prendre en charge plusieurs fichiers APK

Si vous publiez votre application sur Google Play, vous devez compiler et importer un Android App Bundle (AAB). Dans ce cas, Google Play génère et diffuse automatiquement des APK optimisés pour chaque configuration d'appareil, afin que l'utilisateur télécharge uniquement le code et les ressources nécessaires pour exécuter votre application. La publication de plusieurs fichiers APK est utile si vous ne publiez pas sur Google Play, mais que vous devez créer, signer et gérer chaque APK vous-même.

La compatibilité avec plusieurs APK est une fonctionnalité de Google Play qui vous permet de publier différents APK pour votre application, chacun ciblant des configurations d'appareil différentes. Chaque APK est une version complète et indépendante de votre application qui partage la même fiche d'application sur Google Play, doit avoir le même nom de package et être signée avec la même clé de version. Cette fonctionnalité est utile dans les cas où votre application ne peut pas atteindre tous les appareils souhaités avec un seul APK.

Les appareils Android peuvent être différents les uns des autres. Il est donc important que votre application soit disponible sur le plus d'appareils possible. Les applications Android s'exécutent généralement sur la plupart des appareils compatibles avec un seul APK, en fournissant des ressources alternatives pour différentes configurations (par exemple, différentes mises en page pour différentes tailles d'écran). Le système Android sélectionne les ressources appropriées pour l'appareil au moment de l'exécution. Toutefois, dans certains cas, un seul APK ne peut prendre en charge toutes les configurations d'appareil, car d'autres ressources rendent le fichier APK trop volumineux ou d'autres problèmes techniques empêchent un seul APK de fonctionner sur tous les appareils.

Pour vous aider à publier votre application sur le plus d'appareils possible, Google Play vous permet de publier plusieurs APK dans la même fiche d'application. Google Play fournit ensuite chaque APK aux appareils appropriés en fonction des configurations prises en charge, telles que déclarées dans le fichier manifeste de chaque APK.

En publiant votre application avec plusieurs APK, vous pouvez :

• Prendre en charge différents formats de compression de texture OpenGL avec chaque APK.
• Prendre en charge différentes tailles et densités d'écran avec chaque APK.
• Prendre en charge différents ensembles de fonctionnalités d'appareils avec chaque APK.
• Prendre en charge différentes versions de plate-forme avec chaque APK.
• Prendre en charge différentes architectures de processeur avec chaque APK (par exemple, pour ARM ou x86, lorsque votre application utilise Android NDK).
• Optimisez votre application pour les appareils d'entrée de gamme tels que ceux équipés d'Android (édition Go).

Actuellement, Google Play ne prend en charge que les caractéristiques suivantes pour la publication de plusieurs APK pour la même application.

Remarque : Pour en savoir plus sur la préparation et la publication des APK sur Google Play, consultez l'article du centre d'aidepréparer et déployer des versions.

Fonctionnement de plusieurs APK

Pour utiliser plusieurs APK sur Google Play, vous ne disposez que d'une seule entrée pour votre application, mais plusieurs appareils peuvent télécharger un APK différent. Par conséquent :

• Vous ne gérez qu'un seul ensemble d'informations détaillées sur le produit (description de l'application, icônes, captures d'écran, etc.). Cela signifie également que vous ne pouvez pas facturer un prix différent pour différents APK.
• Les utilisateurs ne voient qu'une seule version de votre application sur Google Play. Ils ne sont donc pas perturbés par d'autres versions "pour tablettes" ou "pour téléphones" que vous avez peut-être publiées.
• Tous les avis des utilisateurs sont appliqués à la même fiche d'application, même si les utilisateurs de différents appareils peuvent avoir des APK différents.
• Si vous publiez différents APK pour différentes versions d'Android (pour différents niveaux d'API), alors lorsque l'appareil d'un utilisateur reçoit une mise à jour du système qui lui permet d'utiliser un autre APK que vous avez publié, Google Play met à jour l'application de l'utilisateur pour que cette dernière utilise le bon APK pour cette version d'Android. Toutes les données système associées à l'application sont conservées (comme pour les mises à jour normales lorsque vous utilisez un seul APK).

Filtres compatibles

L'attribution des APK en fonction des appareils est déterminée par les filtres Google Play, spécifiés par les éléments du fichier manifeste de chaque APK. Cependant, Google Play vous permet de publier plusieurs APK uniquement lorsque chacun d'eux utilise des filtres pour prendre en charge une variante des caractéristiques suivantes :

• Formats de compression de texture OpenGL

  Reposent sur le ou les éléments <supports-gl-texture> de votre fichier manifeste.

  Par exemple, lorsque vous développez un jeu qui utilise OpenGL ES, vous pouvez fournir un APK pour les appareils prenant en charge la compression de textures ATI et un autre APK pour les appareils compatibles avec la compression PowerVR (entre autres).

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

  Repose sur l'élément <supports-screens> ou <compatible-screens> de votre fichier manifeste. Vous ne devez jamais utiliser les deux éléments et n'utiliser que <supports-screens> dans la mesure du possible.

  Par exemple, vous pouvez fournir un APK pour la prise en charge des petits et moyens écrans, et un autre pour les écrans de grande et très grande taille. Pour en savoir plus sur la génération d'APK distincts en fonction de la taille ou de la densité de l'écran, consultez la page créer plusieurs APK.

  Tenez compte des bonnes pratiques suivantes pour prendre en charge toutes les tailles d'écran :

  • Le système Android offre une compatibilité élevée aux applications afin de prendre en charge toutes les configurations d'écran avec un seul APK. Vous devez éviter de créer plusieurs APK pour la prise en charge de différents écrans, sauf si cela est absolument nécessaire. À la place, suivez le guide pour prendre en charge plusieurs écrans afin que votre application soit flexible et puisse s'adapter à toutes les configurations d'écran avec un seul APK.
  • Par défaut, tous les attributs de taille d'écran dans l'élément <supports-screens> sont "true" (vrais) si vous ne les déclarez pas autrement. Toutefois, comme l'attribut android:xlargeScreens a été ajouté dans Android 2.3 (niveau d'API 9), Google Play considère l'attribut comme "false" (faux) si votre application ne définit ni android:minSdkVersion ni android:targetSdkVersion sur "9" ou plus.
  • Vous ne devez pas combiner les éléments <supports-screens> et <compatible-screens> dans votre fichier manifeste. L'utilisation des deux options augmente les chances d'introduire une erreur en raison de conflits entre ces options. Si vous avez besoin d'aide pour choisir laquelle utiliser, consultez la page distribuer sur des écrans spécifiques. Si vous n'avez d'autre choix que d'utiliser les deux options, notez qu'en cas de conflit sur une taille donnée, la valeur "false" l'emporte.
• Ensembles de fonctionnalités de l'appareil

  Reposent sur le ou les éléments <uses-feature> de votre fichier manifeste.

  Par exemple, vous pouvez fournir un APK pour les appareils prenant en charge le multipoint et un autre pour tous les autres appareils. Consultez la documentation de référence sur les fonctionnalités pour obtenir la liste des fonctionnalités prises en charge par la plate-forme.

• Android (édition Go)

  Pour cibler les appareils équipés d'Android (édition Go), votre APK doit déclarer <uses-feature android:name="android.hardware.ram.low" android:required="true">, cibler au moins le niveau d'API 26 et avoir un code de version plus élevé que votre APK pour les autres éditions.

• Niveau d'API

  Cette valeur repose sur l'élément <uses-sdk> de votre fichier manifeste. Vous pouvez utiliser les attributs android:minSdkVersion et android:maxSdkVersion pour spécifier la prise en charge de différents niveaux d'API.

  Par exemple, vous pouvez publier votre application avec un APK compatible avec les niveaux d'API 16 à 19 (Android 4.1.x à 4.4.4), en n'utilisant que les API disponibles depuis le niveau d'API 16 ou inférieur, et un autre APK compatible avec les niveaux d'API 21 et supérieurs (Android 5.0 ou supérieur) à l'aide d'API disponibles à partir du niveau d'API 21 ou inférieur. Pour apprendre à créer des APK distincts qui ciblent chacun une plage d'API différente, consultez la page configurer des types de produit.

  Si vous utilisez cette caractéristique comme facteur pour distinguer plusieurs APK, alors l'APK ayant la valeur android:minSdkVersion la plus haute doit avoir une valeur android:versionCode plus élevée. Ceci s'applique également si deux APK se chevauchent quant à leur prise en charge de l'appareil, en fonction d'un filtre compatible différent. Cela garantit que lorsqu'un appareil reçoit une mise à jour du système, Google Play peut proposer à l'utilisateur une mise à jour de votre application (car les mises à jour sont basées sur une augmentation du code de version de l'application). Cette exigence est décrite plus en détail dans la section ci-dessous sur les règles pour plusieurs APK.

  De manière générale, évitez d'utiliser android:maxSdkVersion. Tant que vous avez correctement développé votre application avec des API publiques, elle est toujours compatible avec les futures versions d'Android. Si vous souhaitez publier un autre APK pour les niveaux d'API supérieurs, vous n'avez toujours pas besoin de spécifier la version maximale, car si android:minSdkVersion a une valeur de "16" dans un APK et de "21" dans un autre, les appareils prenant en charge le niveau d'API 21 ou supérieur recevront toujours le second APK (car son code de version est plus élevé, comme nous l'avons expliqué précédemment).



• Architecture de processeur (ABI)

  Certaines bibliothèques natives fournissent des packages distincts pour certaines architectures de processeur, ou interfaces binaires d'application (ABI). Au lieu d'empaqueter toutes les bibliothèques disponibles dans un seul APK, vous pouvez créer un APK distinct pour chaque ABI et n'inclure que les bibliothèques dont vous avez besoin pour cet ABI. Pour en savoir plus sur la génération d'APK distincts en fonction de l'ABI cible, consultez la page Créer plusieurs APK.

D'autres éléments manifestes qui activent les filtres Google Play, mais qui ne sont pas listés ci-dessus, sont toujours appliqués pour chaque APK, comme d'habitude. Cependant, Google Play ne vous permet pas de publier des APK distincts en fonction des variantes de ces caractéristiques d'appareils. Ainsi, vous ne pouvez pas publier plusieurs APK si les filtres listés ci-dessus sont identiques pour chaque APK (mais les APK diffèrent en fonction d'autres caractéristiques dans le fichier manifeste ou l'APK). Par exemple, vous ne pouvez pas fournir des APK différents qui ne diffèrent que par les caractéristiques <uses-configuration>.

Règles pour plusieurs APK

Avant de publier plusieurs APK pour votre application, vous devez comprendre les règles suivantes :

• Tous les APK que vous publiez pour la même application doivent avoir le même nom de package et être signés avec la même clé de certificat.
• Chaque APK doit avoir un code de version différent, spécifié par l'attribut android:versionCode.
• Chaque APK ne doit pas correspondre exactement à la compatibilité de configuration d'un autre APK.

  Autrement dit, chaque APK doit déclarer une compatibilité légèrement différente pour au moins l'un des filtres Google Play compatibles (répertoriés ci-dessus).

  Généralement, vous différencierez vos APK en fonction d'une caractéristique spécifique (comme les formats de compression de texture acceptés), et chaque APK déclarera sa compatibilité avec différents appareils. Toutefois, vous pouvez publier plusieurs APK dont les compatibilités se chevauchent légèrement. Lorsque deux APK se chevauchent (ils sont compatibles avec certaines configurations d'appareil identiques), un appareil compris dans cette plage de chevauchement recevra l'APK dont le code de version est le plus élevé (défini par android:versionCode).

• Vous ne pouvez pas activer un nouvel APK dont le code de version est inférieur à celui de l'APK qu'il remplace. Par exemple, supposons que vous ayez un APK actif pour les tailles d'écrans petites et moyennes avec le code de version 0400, puis que vous essayez de le remplacer par un APK pour cette même taille d'écran, mais avec le code de version 0300. Cela gén��re une erreur, car, ce faisant, les utilisateurs de l'APK précédent ne pourront pas mettre à jour l'application.
• Un APK nécessitant un niveau d'API plus élevé doit avoir un code de version plus élevé.

  Cela n'est vrai que lorsque les APK diffèrent uniquement en fonction des niveaux d'API compatibles (aucun autre filtre compatible ne différencie les APK) ou lorsque les APK utilisent un autre filtre compatible, mais qu'il existe un chevauchement entre les APK dans ce filtre.

  Cette notion est importante, car l'appareil d'un utilisateur ne reçoit une mise à jour de l'application de Google Play que si le code de version de l'APK sur Google Play est supérieur à celui actuellement installé sur l'appareil. Ainsi, si un appareil reçoit une mise à jour du système qui lui permet d'installer l'APK pour des niveaux d'API plus élevés, il reçoit une mise à jour de l'application, car le code de version augmente.

  Remarque : La taille de l'augmentation du code de version n'est pas pertinente. Elle doit simplement être plus grande dans la version compatible avec les niveaux d'API les plus élevés.

  Voici quelques exemples :

  • Si vous avez importé un APK pour les niveaux d'API 16 et supérieurs (Android 4.1.x ou version ultérieure) ayant 0400 pour code de version, alors un APK pour les niveaux d'API 21 et supérieurs (Android 5.0 ou version ultérieure) doit être 0401 ou plus. Dans ce cas, le niveau d'API est le seul filtre compatible utilisé. Par conséquent, les codes de version doivent augmenter en corrélation avec la compatibilité du niveau d'API pour chaque fichier APK, afin que les utilisateurs reçoivent une mise à jour dès qu'ils font une mise à jour du système.
  • Si vous avez un APK pour le niveau d'API 16 (et supérieurs) et pour les petits et grands écrans, un autre APK pour le niveau d'API 21 (et supérieurs) et pour les grands et très grands écrans, alors les codes de version doivent augmenter conjointement aux niveaux d'API. Dans ce cas, le filtre du niveau d'API est utilisé pour distinguer chaque APK, mais il en va de même pour la taille de l'écran. Étant donné que les tailles d'écran se chevauchent (les deux APK sont compatibles avec les grands écrans), les codes de version doivent toujours être en ordre. Cela garantit qu'un appareil avec un grand écran recevant une mise à jour du système au niveau d'API 21 recevra une mise à jour pour le second APK.
  • Si vous avez un APK pour le niveau d'API 16 (et supérieurs) et pour les petits et moyens écrans, un autre APK pour le niveau d'API 21 (et supérieurs) et pour les grands et très grands écrans, alors les codes de version n'ont pas besoin d'augmenter conjointement aux niveaux d'API. Comme il n'y a pas de chevauchement au sein du filtre de taille d'écran, aucun appareil ne pourrait basculer entre ces deux APK. Il n'est donc pas nécessaire d'augmenter les codes de version du niveau d'API inférieur au niveau d'API supérieur.
  • Si vous avez un APK pour les niveaux d'API 16 (et supérieurs) et pour les processeurs ARMv7, et un autre APK pour les niveaux d'API 21 (et supérieurs) et pour les processeurs ARMv5TE, les codes de version doivent augmenter conjointement aux niveaux d'API. Dans ce cas, le filtre du niveau d'API est utilisé pour différencier chaque APK, tout comme celui pour l'architecture du processeur. Étant donné qu'un APK doté de bibliothèques ARMv5TE est compatible avec les appareils possédant un processeur ARMv7, les APK se chevauchent sur cette caractéristique. Par conséquent, le code de version de l'APK compatible avec le niveau d'API 21 (ou supérieur) doit être supérieur. Cela garantit qu'un appareil doté d'un processeur ARMv7 recevant une mise à jour du système au niveau d'API 21 reçoive une mise à jour pour le deuxième APK conçu pour le niveau d'API 21. Toutefois, comme ce type de mise à jour oblige l'appareil doté du processeur ARMv7 à utiliser un APK qui n'est pas entièrement optimisé pour ce processeur, vous devez fournir un APK pour les architectures ARMv5TE et ARMv7 à chaque niveau d'API afin d'optimiser les performances des applications sur chaque processeur. Remarque : Cela s'applique uniquement lors de la comparaison des APK avec les bibliothèques ARMv5TE et ARMv7, et non lorsque vous comparez d'autres bibliothèques natives.

Le non-respect des règles ci-dessus génère une erreur dans la Google Play Console lorsque vous activez vos APK. Vous ne pourrez pas publier votre application tant que vous n'aurez pas résolu l'erreur.

D'autres conflits peuvent se produire lorsque vous activez vos APK, mais ils se traduisent par des avertissements plutôt que par des erreurs. Les causes de ces avertissements peuvent être les suivantes :

• Lorsque vous modifiez un APK afin de "réduire" sa compatibilité avec les caractéristiques d'un appareil et qu'aucun autre APK n'est compatible avec les appareils qui n'appartiennent pas à la plage prise en charge. Par exemple, si un APK est actuellement compatible avec les petits et moyens écrans et que vous le modifiez pour qu'il n'accepte que les petits écrans, vous avez réduit le nombre d'appareils compatibles et certains appareils ne verront plus votre application sur Google Play. Pour résoudre ce problème, ajoutez un autre APK compatible avec les écrans de taille normale afin que tous les appareils précédemment compatibles continuent à l'être.
• En cas de "chevauchement" entre deux APK ou plus. Par exemple, si un APK est compatible avec les petits, moyens et grands écrans, alors qu'un autre est compatible avec les grands et très grands écrans, il y a chevauchement, car les deux APK sont compatibles avec les grands écrans. Si vous ne résolvez pas ce problème, les appareils éligibles pour les deux APK (appareils à grand écran dans l'exemple) recevront l'APK ayant le code de version le plus élevé.

  Remarque : Si vous créez des APK distincts pour différentes architectures de processeur, sachez qu'un APK pour ARMv5TE chevauchera un APK pour ARMv7. Autrement dit, un APK conçu pour ARMv5TE est compatible avec un appareil ARMv7, mais l'inverse n'est pas vrai (un APK contenant uniquement les bibliothèques ARMv7 n'est pas compatible avec un appareil ARMv5TE).

Dans ce cas, un message d'avertissement s'affiche, mais vous pouvez tout de même publier votre application.

Créer plusieurs APK

Une fois que vous avez décidé de publier plusieurs APK, vous devez probablement créer des projets Android distincts pour chaque APK que vous souhaitez publier afin de pouvoir les développer séparément. Pour ce faire, il vous suffit de dupliquer votre projet existant et de lui attribuer un nouveau nom. (Vous pouvez également utiliser un système de compilation capable de générer différentes ressources, telles que des textures, en fonction de la configuration de compilation.)

Conseil : Pour éviter de dupliquer des parties conséquentes du code de votre application, vous pouvez utiliser un projet de bibliothèque. Un projet de bibliothèque contient le code et les ressources partagés, que vous pouvez inclure dans vos projets d'application en cours.

Lorsque vous créez plusieurs projets pour la même application, il est recommandé d'identifier chacun de ces projets à l'aide d'un nom indiquant les restrictions des appareils à placer sur l'APK, afin de pouvoir les identifier facilement. Par exemple, "HelloWorld_21" peut correspondre à un nom d'application conçu pour le niveau d'API 21 ou supérieur.

Remarque : Tous les APK que vous publiez pour la même application doivent avoir le même nom de package et être signés avec la même clé de certificat. Assurez-vous également de bien comprendre lesrègles applicables à plusieurs APK.

Attribuer des codes de version

Chaque APK d'une même application doit avoir un code de version unique, spécifié par l'attribut android:versionCode. Vous devez veiller à attribuer les codes de version lorsque vous publiez plusieurs APK, car ils doivent tous être différents, mais dans certains cas ils doivent être ou devraient être définis dans un ordre spécifique, en fonction des configurations prises en charge par chaque APK.

Ordonner des codes de version

Un APK nécessitant un niveau d'API plus élevé doit généralement avoir un code de version plus élevé. Par exemple, si vous créez deux APK compatibles avec différents niveaux d'API, l'APK avec le niveau d'API le plus élevé doit avoir le code de version le plus élevé. Ainsi, si un appareil reçoit une mise à jour du système qui lui permet d'installer l'APK pour des niveaux d'API plus élevés, l'utilisateur reçoit une notification pour mettre à jour l'application. Pour en savoir plus sur l'application de cette exigence, consultez la section ci-dessus : Règles pour plusieurs APK.

Vous devez également déterminer dans quelle mesure l'ordre des codes de version pourrait affecter l'APK reçu par vos utilisateurs, en raison du chevauchement des couvertures des différents APK ou des modifications que vous pourriez apporter ultérieurement à vos APK.

Par exemple, si vous disposez de différents APK relatifs à la taille de l'écran (par exemple, un pour les petits et moyens et un autre pour les grands et très grands), mais que vous prévoyez de les remplacer, à l'avenir, par un APK pour les petits écrans et un autre pour les moyens à très grands, vous devez faire en sorte que le code de version pour l'APK concernant les grands et très grands écrans soit le plus élevé des deux. Ainsi, un appareil de taille normale recevra la mise à jour appropriée une fois la modification effectuée, car le code de version passera de l'APK existant au nouvel APK compatible avec l'appareil.

Par ailleurs, lorsque vous créez plusieurs APK qui diffèrent en fonction des différents formats de compression de textures OpenGL, notez que de nombreux appareils acceptent plusieurs formats. Étant donné qu'un appareil reçoit l'APK avec le code de version le plus élevé lorsqu'il y a chevauchement de couverture entre deux APK, vous devez ordonner les codes de version parmi vos APK pour que celui ayant le format de compression préféré ait le code de version le plus élevé. Par exemple, vous pouvez effectuer des builds différents pour votre application à l'aide des formats de compression PVRTC, ATITC et ETC1. Si vous préférez ces formats dans cet ordre exact, l'APK qui utilise PVRTC doit avoir le code de version le plus élevé, l'APK qui utilise ATITC, un code de version inférieur et celui utilisant ETC1 doit avoir la version la plus basse. Ainsi, si un appareil est compatible avec PVRTC et ETC1, il reçoit l'APK avec PVRTC, car il possède le code de version le plus élevé.

Si le Google Play Store ne parvient pas à identifier quel APK installer pour un appareil cible, vous pouvez également créer un APK universel qui inclut des ressources pour toutes les variantes d'appareil que vous souhaitez prendre en charge. Si vous fournissez un APK universel, attribuez-lui le versionCode (code de version) le plus bas. Comme le Google Play Store installe la version de votre application qui est à la fois compatible avec l'appareil cible et qui possède le versionCode le plus élevé, l'attribution d'un versionCode plus faible à l'APK universel garantit que le Google Play Store tente d'installer un autre de vos APK avant de revenir à l'APK universel, plus volumineux.

Utiliser un schéma de code de version

Pour autoriser différents APK à mettre à jour leurs codes de version indépendamment des autres (par exemple, lorsque vous corrigez un bug dans un seul APK, pour ne pas avoir besoin de mettre à jour tous les APK), vous devez utiliser un schéma pour vos codes de version qui laisse suffisamment d'espace entre chaque APK pour que vous puissiez augmenter le code dans l'un sans l'augmenter dans les autres. Vous devez également inclure le nom de votre version en cours dans le code (c'est-à-dire la version visible par l'utilisateur attribuée à android:versionName) afin que vous puissiez facilement associer la version au nom de la version.

Remarque : Lorsque vous augmentez le code de version d'un APK, Google Play invite les utilisateurs de la version précédente à mettre à jour l'application. Ainsi, pour éviter des mises à jour inutiles, vous ne devez pas augmenter le code de version pour les APK n'ayant pas été modifiés.

Nous vous recommandons d'utiliser un code de version comportant au moins sept chiffres : les entiers qui représentent les configurations compatibles se trouvent dans les bits d'ordre supérieur, et le nom de la version (issu d'android:versionName) dans ceux d'ordre inférieur. Par exemple, lorsque le nom de version de l'application est 3.1.0, les codes de version pour un APK de niveau d'API 4 et pour un APK de niveau d'API 11 se présentent respectivement sous la forme "0400310" et "1100310". Les deux premiers chiffres sont réservés au niveau d'API (4 et 11, respectivement), les deux chiffres du milieu correspondent à des tailles d'écran ou à des formats de texture GL (non utilisés dans ces exemples), et les trois derniers chiffres renvoient au nom de la version de l'application (3.1.0). Le schéma 1 montre deux exemples de répartition en fonction de la version de la plate-forme (niveau d'API) et de la taille de l'écran.

Figure 1. Schéma suggéré pour vos codes de version, en utilisant les deux premiers chiffres pour le niveau d'API, les deuxième et troisième chiffres pour la taille minimale et maximale de l'écran (1 à 4, pour chacune des quatre tailles) ou pour indiquer les formats de texture, et enfin les trois derniers chiffres pour la version de l'application.

Ce schéma pour les codes de version n'est qu'une suggestion qui vous permettra d'établir un modèle qui suivra l'évolution de votre application. Ce schéma n'est d'ailleurs pas une solution permettant d'identifier différents formats de compression de texture. Une solution possible serait de définir votre propre tableau spécifiant un entier différent pour chacun des différents formats de compression pris en charge par votre application (par exemple, 1 correspondrait à ETC1 et 2 à ATITC, etc.).

Vous pouvez utiliser le schéma de votre choix, mais vous devez bien réfléchir à la manière dont les futures versions de votre application devront augmenter leurs codes de version et à la manière dont les appareils pourront recevoir des mises à jour lorsque leur configuration changera (par exemple, en raison d'une mise à jour du système) ou lorsque vous modifierez la compatibilité de la configuration pour un ou plusieurs APK.