Créer plusieurs APK pour différentes textures GL

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.

Lorsque vous développez votre application Android pour tirer parti de plusieurs APK sur Google Play, il est important d'adopter de bonnes pratiques dès le départ et d'éviter les problèmes inutiles tout au long du processus de développement. Cette leçon explique comment créer plusieurs APK de votre application, chacun compatible avec un sous-ensemble différent de formats de texture OpenGL. Vous disposerez également des outils nécessaires pour rendre la gestion de plusieurs fichiers APK aussi simple que possible.

Confirmer que vous avez besoin de plusieurs APK

Lorsque vous essayez de créer une application qui fonctionne sur tous les appareils Android disponibles, vous souhaitez naturellement que votre application s'affiche au mieux sur chaque appareil, même s'ils ne sont pas tous compatibles avec le même ensemble de textures GL. Au départ, il peut sembler que la prise en charge de plusieurs fichiers APK constitue la meilleure solution, mais ce n'est souvent pas le cas. La section Utiliser un seul fichier APK du guide du développeur pour plusieurs fichiers APK contient des informations utiles sur la façon d'effectuer cette opération avec un seul fichier APK, y compris sur la détection des formats de texture acceptés au moment de l'exécution. Selon votre situation, il peut être plus facile d'associer tous les formats à votre application et de choisir simplement celui à utiliser au moment de l'exécution.

Si vous pouvez le gérer, limiter votre application à un seul APK présente plusieurs avantages, y compris les suivants:

  • La publication et les tests sont simplifiés
  • Il n'y a qu'un seul codebase à gérer
  • Votre application peut s'adapter aux modifications apportées à la configuration de l'appareil
  • La restauration d'applications sur tous les appareils fonctionne parfaitement
  • Vous n'avez pas à vous soucier des préférences du marché, du comportement des "mises à niveau" d'un APK à l'autre ni de l'APK associé à quelle classe d'appareils

Dans le reste de cette leçon, nous partons du principe que vous avez effectué des recherches sur le sujet, assimilé scrupuleusement le contenu des ressources associées et déterminé que plusieurs fichiers APK constituaient le chemin d'accès approprié pour votre application.

Représenter vos besoins sous forme graphique

Le guide du développeur Android fournit une référence pratique de certaines textures courantes compatibles sur la page supports-gl-texture. Cette page contient également des indications concernant les téléphones (ou familles de téléphones) compatibles avec des formats de texture particuliers. Notez qu'il est généralement judicieux que l'un de vos APK soit compatible avec ETC1, car ce format de texture est compatible avec tous les appareils Android compatibles avec la spécification OpenGL ES 2.0.

Étant donné que la plupart des appareils Android acceptent plusieurs formats de texture, vous devez établir un ordre de préférence. Créez un graphique incluant tous les formats compatibles avec votre application. La cellule la plus à gauche sera la priorité la plus basse (il s'agira probablement d'ETC1, une valeur par défaut très fiable en termes de performances et de compatibilité). Colorez ensuite le graphique de sorte que chaque cellule représente un APK.

ETC1 ATI (Advanced Technology Innovation) PowerVR

La coloration dans le graphique ne se limite pas à rendre ce guide moins monochrome. Elle permet également de faciliter la communication au sein des équipes. Vous pouvez désormais simplement désigner chaque APK en tant que "bleu", "vert" ou "rouge" au lieu de "ceux qui prend en charge les formats de texture ETC1", etc.

Placer l'ensemble du code et des ressources courants dans un projet de bibliothèque

Que vous souhaitiez modifier une application Android existante ou en créer une à partir de zéro, c'est la première chose que vous devez faire dans le codebase et de loin la plus importante. Tout ce qui se trouve dans le projet de bibliothèque ne doit être mis à jour qu'une seule fois (par exemple, les chaînes localisées, les thèmes de couleurs, les bugs corrigés dans le code partagé), ce qui accélère le développement et réduit le risque d'erreurs qui auraient pu être facilement évitées.

Remarque:Bien que les détails d'implémentation pour créer et inclure des projets de bibliothèque dépassent le cadre de cette leçon, vous pouvez lire Créer une bibliothèque Android.

Si vous convertissez une application existante pour qu'elle prenne en charge plusieurs APK, parcourez votre codebase à la recherche de chaque fichier de chaîne localisée, liste de valeurs, couleurs de thème, icônes de menu et mise en page qui ne changeront pas entre les APK, puis placez le tout dans le projet de bibliothèque. Le code qui ne va pas changer grand-chose devrait également figurer dans le projet de bibliothèque. Vous devrez probablement étendre ces classes pour ajouter une ou deux méthodes d'APK à un APK.

En revanche, si vous créez l'application à partir de zéro, essayez autant que possible d'écrire du code dans le projet de bibliothèque d'abord, puis ne le déplacez vers le bas que si nécessaire. C'est beaucoup plus facile à gérer à long terme que de l'ajouter à un, puis à un autre, puis à un autre, puis des mois plus tard pour tenter de déterminer si ce blob peut être déplacé vers la section de la bibliothèque sans rien gâcher.

Créer des projets APK

Il doit y avoir un projet Android distinct pour chaque APK que vous allez publier. Pour faciliter l'organisation, placez le projet de bibliothèque et tous les projets APK associés dans le même dossier parent. N'oubliez pas non plus que chaque APK doit avoir le même nom de package, même s'il n'est pas nécessaire de partager ce nom avec la bibliothèque. Si vous disposez de trois APK en suivant le schéma décrit précédemment, votre répertoire racine peut se présenter comme suit:

alexlucas:~/code/multi-apks-root$ ls
foo-blue
foo-green
foo-lib
foo-red

Une fois les projets créés, ajoutez le projet de bibliothèque comme référence pour chaque projet APK. Si possible, définissez votre activité de départ dans le projet de bibliothèque et étendez cette activité dans votre projet APK. La définition d'une activité de démarrage dans le projet de bibliothèque vous permet de centraliser l'initialisation de votre application au même endroit. Ainsi, chaque APK individuel n'a pas besoin de réimplémenter des tâches "universelles" telles que l'initialisation d'Analytics, l'exécution de vérifications des licences et toute autre procédure d'initialisation qui ne change pas grand-chose d'un APK à l'autre.

Ajuster les fichiers manifestes

Lorsqu'un utilisateur télécharge une application qui utilise plusieurs APK via Google Play, le bon APK à utiliser est choisi à l'aide de quelques règles simples:

  • Le fichier manifeste doit indiquer que l'APK spécifique est éligible.
  • Parmi les APK éligibles, le numéro de version le plus élevé l'emporte,
  • Si l'un des formats de texture listés dans votre APK est compatible avec l'appareil sur le marché, celui-ci est considéré comme éligible.

En ce qui concerne les textures GL, cette dernière règle est importante. Cela signifie que vous devez, par exemple, faire très attention lorsque vous utilisez différents formats GL dans la même application. Si vous utilisiez PowerVR 99% du temps, mais que vous utilisez ETC1 pour votre écran de démarrage, par exemple... Dans ce cas, votre fichier manifeste indique nécessairement la compatibilité avec les deux formats. Un appareil qui n'acceptait que ETC1 serait considéré comme compatible, votre application serait téléchargée et l'utilisateur verrait des messages de plantage palpitants. Le cas courant sera que si vous utilisez plusieurs APK spécifiquement pour cibler différents appareils en fonction de la compatibilité avec les textures GL, vous devrez utiliser un format de texture par APK.

La prise en charge des textures diffère donc légèrement de celle des deux autres dimensions d'APK multiples, du niveau d'API et de la taille d'écran. Chaque appareil ne possède qu'un seul niveau d'API et une seule taille d'écran. L'APK doit les prendre en charge. Avec les textures, l'APK accepte généralement une seule texture, et l'appareil en accepte plusieurs. Il y aura souvent chevauchement entre les données d'un appareil prenant en charge de nombreux APK, mais la solution reste la même: les codes de version.

À titre d'exemple, prenons quelques appareils et voyez combien d'APK définis précédemment correspondent à chaque appareil.

FooPhone Nexus S Evo
ETC1 ETC1 ETC1
PowerVR ATI TC

En supposant que les formats PowerVR et ATI sont privilégiés par rapport aux formats ETC1 lorsqu'ils sont disponibles, plutôt que selon la règle "le numéro de version le plus élevé l'emporte", si nous définissons l'attribut versionCode dans chaque APK de sorte que le rouge ≥ vert ≥ bleu, le rouge et le vert soient toujours choisis sur bleu sur les appareils compatibles, et si un appareil compatible à la fois rouge et vert est choisi.

Afin de conserver tous vos APK sur des "canaux" distincts, il est important d'avoir un bon schéma de code de version. Vous trouverez ceux recommandés dans la section "Codes de version" de notre guide du développeur. Étant donné que l'exemple d'ensemble d'APK ne traite que de l'une des trois dimensions possibles, il serait suffisant de séparer chaque APK de 1 000 et d'incrémenter ce nombre. Cela peut se présenter comme suit:

Bleu: 1 001, 1 002, 1 003, 1 004...
Vert: 2001, 2002, 2003, 2004...
Rouge:3001, 3002, 3003, 3004...

En résumé, vos fichiers manifestes Android se présenteront probablement comme suit:

Bleu :

<manifest xmlns:android="http://schemas.android.com/apk/res/android"
    android:versionCode="1001" android:versionName="1.0" package="com.example.foo">
    <supports-gl-texture android:name="GL_OES_compressed_ETC1_RGB8_texture" />
    ...

Vert :

<manifest xmlns:android="http://schemas.android.com/apk/res/android"
    android:versionCode="2001" android:versionName="1.0" package="com.example.foo">
    <supports-gl-texture android:name="GL_AMD_compressed_ATC_texture" />
    ...

Rouge :

<manifest xmlns:android="http://schemas.android.com/apk/res/android"
    android:versionCode="3001" android:versionName="1.0" package="com.example.foo">
    <supports-gl-texture android:name="GL_IMG_texture_compression_pvrtc" />
    ...

Vérifiez votre checklist de pré-lancement

Avant d'importer une application sur Google Play, vérifiez les éléments suivants. N'oubliez pas qu'elles sont particulièrement pertinentes pour plusieurs APK et qu'elles ne constituent en aucun cas une checklist complète pour toutes les applications importées sur Google Play.

  • Tous les APK doivent avoir le même nom de package
  • Tous les APK doivent être signés avec le même certificat.
  • Vérifiez que vos filtres de fichier manifeste contiennent des informations en conflit (un APK qui n'est compatible qu'avec cupcake sur les écrans XLARGE n'est visible par personne).
  • Le fichier manifeste de chaque APK doit être unique pour au moins une version d'écran, une texture OpenGL ou une version de plate-forme compatibles.
  • Essayez de tester chaque APK sur au moins un appareil. À défaut, l'un des émulateurs d'appareils les plus personnalisables dans l'entreprise est installé sur votre ordinateur de développement. Ça alors !

Il est également utile d'inspecter l'APK compilé avant de le commercialiser pour vous assurer qu'aucune surprise ne risque de dissimuler votre application sur Google Play. C'est en fait assez simple avec l'outil "aapt". Aapt (Android Asset Packaging Tool) fait partie du processus de compilation pour créer et empaqueter vos applications Android. Il s'agit également d'un outil très pratique pour les inspecter.

>aapt dump badging
package: name='com.example.hello' versionCode='1' versionName='1.0'
sdkVersion:'11'
uses-permission:'android.permission.SEND_SMS'
application-label:'Hello'
application-icon-120:'res/drawable-ldpi/icon.png'
application-icon-160:'res/drawable-mdpi/icon.png'
application-icon-240:'res/drawable-hdpi/icon.png'
application: label='Hello' icon='res/drawable-mdpi/icon.png'
launchable-activity: name='com.example.hello.HelloActivity'  label='Hello' icon=''
uses-feature:'android.hardware.telephony'
uses-feature:'android.hardware.touchscreen'
main
supports-screens: 'xlarge'
supports-any-density: 'true'
locales: '--_--'
densities: '120' '160' '240'

Lorsque vous examinez la sortie aapt, assurez-vous que vous n'avez pas de valeurs contradictoires pour "supports-screens" et "compatible-screens", et que vous n'avez pas de valeurs "uses-feature" involontaires ajoutées à la suite d'autorisations que vous avez définies dans le fichier manifeste. Dans l'exemple ci-dessus, l'APK sera invisible pour la plupart, voire tous les appareils.

Pourquoi ? En ajoutant l'autorisation requise SEND_SMS, l'exigence de fonctionnalité d'android.hardware.telephony a été ajoutée implicitement. Étant donné que la plupart des grands appareils (voire tous) sont des tablettes sans matériel de téléphonie, Google Play filtrera cet APK dans ces cas, jusqu'à ce que de futurs appareils soient à la fois suffisamment grands pour être considérés comme de très grande taille et dotés de matériel de téléphonie.

Heureusement, vous pouvez facilement résoudre ce problème en ajoutant le code suivant à votre fichier manifeste:

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

L'exigence android.hardware.touchscreen est également ajoutée implicitement. Si vous souhaitez que votre APK soit visible sur les téléviseurs qui ne sont pas à écran tactile, ajoutez les éléments suivants à votre fichier manifeste:

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

Une fois que vous avez suivi la checklist de pré-lancement, importez vos APK dans Google Play. Il peut s'écouler un certain temps avant que l'application ne s'affiche lorsque vous naviguez sur Google Play, mais lorsque cela se produit, effectuez une dernière vérification. Téléchargez l'application sur n'importe quel appareil de test pour vous assurer que les fichiers APK ciblent bien les appareils souhaités. Félicitations, vous avez terminé !