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 plus tard dans le processus de développement. Cette leçon vous explique comment créer plusieurs APK de votre application, chacun prenant en charge un sous-ensemble différent de formats de texture OpenGL. Vous obtiendrez également des outils nécessaires pour faciliter la maintenance d'un codebase multi-APK.
Vérifier que vous avez besoin de plusieurs APK
Lorsque vous essayez de créer une application qui fonctionne sur tous les appareils Android disponibles, vous voulez naturellement que votre application soit la plus attrayante possible sur chaque appareil, même s'ils ne sont pas tous compatibles avec le même ensemble de textures GL. Au premier abord, il peut sembler que la prise en charge de plusieurs APK soit la meilleure solution, mais ce n'est souvent pas le cas. La section Utiliser un seul APK à la place du guide du développeur pour plusieurs APK inclut des informations utiles pour y parvenir avec un seul APK, y compris pour détecter les formats de texture compatibles au moment de l'exécution. Selon votre situation, il peut être plus simple de regrouper tous les formats avec votre application et de choisir simplement celui à utiliser au moment de l'exécution.
Si vous pouvez le gérer, confiner votre application à un seul APK présente plusieurs avantages, dont les suivants:
- La publication et les tests sont plus faciles
- Il n'y a qu'une seule base de code à gérer
- Votre application peut s'adapter aux changements de configuration de l'appareil
- La restauration des applications sur plusieurs appareils fonctionne simplement
- Vous n'avez pas à vous soucier des préférences du marché, du comportement lors des "mises à niveau" d'un APK à l'autre, ni de l'APK associé à quelle classe d'appareils.
Le reste de cette leçon suppose que vous avez effectué des recherches sur le sujet, que vous avez absorbé le contenu des ressources associées et que vous avez déterminé que plusieurs APK sont le bon choix pour votre application.
Représenter vos exigences
Le guide du développeur Android fournit une référence pratique de certaines textures compatibles courantes sur la page supports-gl-texture. Cette page contient également des indications sur les téléphones (ou familles de téléphones) compatibles avec des formats de texture particuliers. Notez qu'il est généralement recommandé 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 sont compatibles avec 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 aura la priorité la plus faible (il s'agira probablement d'ETC1, un paramètre par défaut très solide en termes de performances et de compatibilité). Colorez ensuite le graphique de sorte que chaque cellule représente un APK.
| ETC1 | ATI | PowerVR |
Colorier le graphique ne sert pas seulement à rendre ce guide moins monochrome. Il permet également de faciliter la communication au sein de l'équipe. Vous pouvez désormais simplement désigner chaque APK par "bleu", "vert" ou "rouge", au lieu de "celui qui prend en charge les formats de texture ETC1", etc.
Placer tout le code et toutes les ressources communs dans un projet de bibliothèque
Qu'il s'agisse de modifier une application Android existante ou d'en créer une en partant de zéro, c'est la première chose que vous devez faire au codebase, et de loin la plus importante. Tout ce qui est inclus dans le projet de bibliothèque ne doit être mis à jour qu'une seule fois (pensez aux chaînes localisées en fonction de la langue, aux thèmes de couleurs, aux bugs corrigés dans le code partagé), ce qui améliore le temps de développement et réduit le risque d'erreurs qui auraient pu être facilement évitées.
Remarque:Bien que les détails de l'implémentation de la création et de l'inclusion de projets de bibliothèque ne relèvent pas du champ d'application de ce cours, vous pouvez vous familiariser avec le sujet en lisant Créer une bibliothèque Android.
Si vous convertissez une application existante pour qu'elle prenne en charge plusieurs APK, recherchez dans votre codebase tous les fichiers de chaînes localisées, les listes de valeurs, les couleurs de thème, les icônes de menu et la mise en page qui ne changeront pas entre les APK, puis placez-les tous dans le projet de bibliothèque. Le code qui ne changera pas beaucoup doit également être placé dans le projet de bibliothèque. Vous devrez probablement étendre ces classes pour ajouter une ou deux méthodes d'un APK à un autre.
Si, en revanche, 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 de ne le déplacer vers un APK individuel que si nécessaire. Cela est beaucoup plus facile à gérer à long terme que d'ajouter ce blob à un, puis à un autre, puis à un autre, puis des mois plus tard, d'essayer de déterminer si ce blob peut être déplacé vers la section de la bibliothèque sans tout gâcher.
Créer des projets APK
Chaque APK que vous allez publier doit disposer d'un projet Android distinct. 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, bien qu'il ne soit pas nécessaire de le partager avec la bibliothèque. Si vous aviez trois APK suivant le schéma décrit précédemment, votre répertoire racine pourrait 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 en tant que référence à chaque projet d'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 regrouper toute l'initialisation de votre application au même endroit, de sorte que chaque APK individuel n'ait pas à réimplémenter des tâches "universelles" telles que l'initialisation d'Analytics, l'exécution de vérifications de licence et toute autre procédure d'initialisation qui ne change pas beaucoup d'APK à l'autre.
Ajuster les fichiers manifestes
Lorsqu'un utilisateur télécharge une application qui utilise plusieurs APK via Google Play, l'APK approprié est sélectionné à l'aide de règles simples:
- Le fichier manifeste doit indiquer que l'APK en question est éligible
- Parmi les APK éligibles, celui dont le numéro de version est le plus élevé remporte la mise aux enchères.
- Si l'un des formats de texture listés dans votre APK est compatible avec l'appareil sur le marché, cet appareil est considéré comme éligible.
Cette dernière règle est importante pour les textures GL. Par exemple, vous devez très veiller à utiliser différents formats GL dans la même application. Si vous utilisiez PowerVR 99% du temps, mais que vous utilisiez ETC1 pour votre écran de démarrage, par exemple... Votre fichier manifeste indiquera alors nécessairement la compatibilité avec les deux formats. Un appareil qui n'accepte que ETC1 serait considéré comme compatible, votre application serait téléchargée et l'utilisateur verrait des messages de plantage passionnants. En règle générale, si vous utilisez plusieurs APK spécifiquement pour cibler différents appareils en fonction de la compatibilité avec les textures GL, vous utiliserez un format de texture par APK.
Cela rend la prise en charge des textures un peu différente des deux autres dimensions d'APK multiples, à savoir le niveau d'API et la taille de l'écran. Un appareil donné n'a qu'un seul niveau d'API et une seule taille d'écran. C'est à l'APK de prendre en charge une gamme de niveaux et de tailles. Avec les textures, l'APK accepte généralement une texture, tandis que l'appareil en accepte plusieurs. Il y aura souvent des chevauchements au niveau des appareils compatibles avec de nombreux APK, mais la solution est la même: les codes de version.
Par exemple, prenez quelques appareils et vérifiez combien d'APK définis précédemment correspondent à chacun d'eux.
| FooPhone | Nexus S | Evo |
| ETC1 | ETC1 | ETC1 |
| PowerVR | ATI TC |
En partant du principe que les formats PowerVR et ATI sont tous les deux préférés à ETC1 lorsqu'ils sont disponibles, plutôt que selon la règle du "numéro de version le plus élevé l'emporte", si nous définissons l'attribut versionCode dans chaque APK de sorte que rouge ≥ vert ≥ bleu, le rouge et le vert seront toujours choisis sur bleu sur les appareils qui les prennent en charge, et si jamais un appareil compatible avec le rouge et le vert, le rouge sera choisi.
Pour que tous vos APK soient sur des "canaux" distincts, il est important de disposer d'un bon schéma de code de version. Vous trouverez la valeur recommandée dans la section "Codes de version" de notre guide du développeur. Étant donné que l'exemple d'ensemble d'APK ne traite qu'une des trois dimensions possibles, il suffirait de séparer chaque APK par 1 000 et d'incrémenter la valeur à partir de cette valeur. Cela peut se présenter comme suit :
Bleu: 1001, 1002, 1003, 1004…
Vert : 2001, 2002, 2003, 2004…
Rouge:3001, 3002, 3003, 3004...
En regroupant tout, 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" />
...
Consulter votre checklist de pré-lancement
Avant d'importer votre application sur Google Play, vérifiez les points suivants. N'oubliez pas qu'ils sont particulièrement pertinents pour plusieurs APK et qu'ils 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 ne contiennent pas d'informations contradictoires (un APK qui n'est compatible qu'avec Cupcake sur les écrans XLARGE ne sera vu par personne).
- Le fichier manifeste de chaque APK doit être unique pour au moins un écran, une texture OpenGL ou une version de plate-forme compatibles.
- Essayez de tester chaque APK sur au moins un appareil. À part cela, vous disposez de l'un des émulateurs d'appareils les plus personnalisables du secteur sur votre ordinateur de développement. Allez-y !
Il est également utile d'inspecter l'APK compilé avant de le mettre sur le marché, afin de s'assurer qu'il n'y a pas de surprises qui pourraient masquer votre application sur Google Play. C'est en fait très simple à l'aide de l'outil "aapt". Aapt (Android Asset Packaging Tool) fait partie du processus de compilation pour créer et empaqueter vos applications Android. Il est également 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 qu'il n'existe pas de valeurs contradictoires pour "supports-screens" et "compatible-screens", et qu'il n'existe pas de valeurs "uses-feature" non intentionnelles ajoutées en raison des autorisations que vous avez définies dans le fichier manifeste. Dans l'exemple ci-dessus, l'APK sera invisible pour la plupart des appareils, voire pour tous.
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 (sinon tous) des appareils très grands sont des tablettes sans matériel de téléphonie, Google Play filtre cet APK dans ce cas, jusqu'à ce que de futurs appareils soient suffisamment grands pour être signalés comme ayant une taille d'écran très grande et disposent d'un matériel de téléphonie.
Heureusement, ce problème est facile à résoudre 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 des appareils à écran tactile, vous devez ajouter ce qui suit à 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 sur Google Play. Il peut s'écouler un certain temps avant que l'application ne s'affiche lorsque vous parcourez Google Play. Une fois qu'elle apparaît, effectuez une dernière vérification. Téléchargez l'application sur tous les appareils de test dont vous disposez pour vous assurer que les APK ciblent les appareils prévus. Félicitations, vous avez terminé !