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 dès le départ quelques bonnes pratiques et d'éviter les problèmes inutiles lors du processus de développement. Cette leçon vous explique comment créer plusieurs APK de votre application, chacun couvrant une plage de niveaux d'API légèrement différente. Vous bénéficierez également des outils nécessaires pour simplifier au maximum la gestion de plusieurs codebases APK.
Vérifier que vous avez besoin de plusieurs APK
Lorsque vous essayez de créer une application qui fonctionne sur plusieurs générations de la plate-forme Android, vous souhaitez naturellement qu'elle profite des nouvelles fonctionnalités sur les nouveaux appareils, sans sacrifier la rétrocompatibilité. Au premier abord, il peut sembler que la prise en charge de plusieurs APK est la meilleure solution, mais ce n'est souvent pas le cas. La section Utiliser un seul APK à la place du guide du développeur concernant plusieurs APK contient des informations utiles sur la façon de procéder avec un seul APK, y compris l'utilisation de notre bibliothèque Support. Vous pouvez également apprendre à écrire du code qui ne s'exécute qu'à certains niveaux d'API dans un seul APK, sans avoir recours à des techniques coûteuses en termes de calcul, comme la réflexion, en consultant cet article.
Si vous pouvez le gérer, confiner votre application à un seul APK présente plusieurs avantages. En voici quelques-uns:
- La publication et les tests sont plus simples
- Il n'y a qu'un seul codebase à gérer
- Votre application peut s'adapter aux modifications de la 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.
Dans la suite de cette leçon, nous partons du principe que vous avez fait des recherches sur le sujet, que vous avez bien assimilé tous les documents des ressources associées et déterminé que plusieurs APK sont le bon chemin pour votre application.
Représenter vos exigences
Commencez par créer un graphique simple pour déterminer rapidement le nombre d'APK dont vous avez besoin et la plage d'API couverte par chaque APK. Pour référence pratique, la page Versions de la plate-forme du site Web pour les développeurs Android fournit des données sur le nombre relatif d'appareils actifs exécutant une version donnée de la plate-forme Android. De plus, bien que cela semble facile au premier abord, il devient difficile plutôt rapidement de suivre l'ensemble de niveaux d'API que chaque APK cible, en particulier en cas de chevauchement (ce qui arrive souvent). Heureusement, il est facile de déterminer vos besoins rapidement et facilement, et de vous y reporter facilement par la suite.
Pour créer votre graphique pour plusieurs APK, commencez avec une ligne de cellules représentant les différents niveaux d'API de la plate-forme Android. Ajoutez une cellule supplémentaire à la fin pour représenter les futures versions d'Android.
| 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | + |
Il vous suffit maintenant de colorer le graphique de sorte que chaque couleur représente un APK. Voici un exemple d'application de chaque APK à une certaine plage de niveaux d'API.
| 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | + |
Une fois que vous avez créé ce graphique, distribuez-le à votre équipe. La communication de votre projet est immédiatement plus simple, car au lieu de demander "Comment est l'APK pour les niveaux d'API 3 à 6 ?" Android 1.x. Comment ça se passe ? » Dites simplement "Comment se passe l'APK bleu ?"
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 d'implémentation concernant la création et l'inclusion de projets de bibliothèque sortent du cadre de cette leçon, vous pouvez passer à la vitesse supérieure en lisant Créer une bibliothèque Android.
Si vous convertissez une application existante pour qu'elle prenne en charge plusieurs fichiers APK, parcourez votre codebase pour rechercher tous les fichiers de chaîne localisés, la liste de valeurs, les couleurs de thème, les icônes de menu et la mise en page qui ne changent pas d'un APK à l'autre, puis placez tout dans le projet de bibliothèque. Le code qui ne va pas changer grand-chose doit également être placé dans le projet Bibliothèque. Vous devrez probablement étendre ces classes pour ajouter une ou deux méthodes d'un APK à un APK.
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
Un projet Android distinct doit être créé 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, bien qu'il ne soit pas nécessaire de le partager avec la bibliothèque. Si vous disposez de trois APK selon 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 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é à utiliser est choisi selon deux règles simples:
- Le fichier manifeste doit indiquer que l'APK en question est éligible
- Parmi les APK éligibles, le numéro de version le plus élevé l'emporte.
À titre d'exemple, prenons l'ensemble de plusieurs APK décrits précédemment et supposons que nous n'avons défini aucun niveau d'API maximal pour aucun des APK. Pris individuellement, la plage possible de chaque APK se présente comme suit :
| 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | + |
| 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | + |
| 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | + |
Étant donné qu'un APK avec une version minSdkVersion supérieure doit également avoir un code de version plus élevé, nous savons qu'en termes de valeurs de code de version, le rouge ≥ le vert ≥ le bleu. Par conséquent, nous pouvons réduire efficacement le graphique pour qu'il se présente comme suit:
| 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | + |
Supposons maintenant que le fichier APK rouge présente des exigences contraires aux deux autres. La page Filters on Google Play (Filtres sur Google Play) du guide du développeur Android contient toute une liste de causes possibles. Par exemple, supposons que le rouge nécessite une caméra avant. En fait, l'objectif de l'APK rouge est de combiner la caméra avant avec de nouvelles fonctionnalités ajoutées dans l'API 11. Mais il s'avère que tous les appareils qui prennent en charge l'API 11 n'ont même pas de caméra frontale ! L'horreur !
Heureusement, si un utilisateur parcourt Google Play à partir d'un tel appareil, Google Play examine le fichier manifeste, voit que Red indique que la caméra avant est obligatoire et l'ignore discrètement, ayant déterminé que Red et cet appareil ne sont pas faits pour s'entendre. Il constate alors que Green n'est pas seulement rétrocompatible avec les appareils utilisant l'API 11 (car aucune valeur maxSdkVersion n'a été définie), mais qu'il importe s'il existe ou non une caméra frontale. L'utilisateur peut toujours télécharger l'application depuis Google Play, car malgré le problème de la caméra avant, il existe toujours un APK compatible avec ce niveau d'API particulier.
Pour conserver tous vos APK sur des canaux distincts, il est important de disposer d'un bon schéma de code de version. Le type recommandé est disponible dans la zone 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, de définir les deux premiers chiffres sur la version minSdkVersion de cet APK, puis d'incrémenter à partir de là. Cela peut se présenter comme suit :
Bleu: 03001, 03002, 03003, 03004...
Vert: 07001, 07002, 07003, 07004...
Rouge:11001, 11002, 11003, 11004...
En réunissant tous ces éléments, vos fichiers manifestes Android se présenteront probablement comme suit :
Bleu :
<manifest xmlns:android="http://schemas.android.com/apk/res/android"
android:versionCode="03001" android:versionName="1.0" package="com.example.foo">
<uses-sdk android:minSdkVersion="3" />
...
Vert :
<manifest xmlns:android="http://schemas.android.com/apk/res/android"
android:versionCode="07001" android:versionName="1.0" package="com.example.foo">
<uses-sdk android:minSdkVersion="7" />
...
Rouge :
<manifest xmlns:android="http://schemas.android.com/apk/res/android"
android:versionCode="11001" android:versionName="1.0" package="com.example.foo">
<uses-sdk android:minSdkVersion="11" />
...
Consulter votre checklist de pré-lancement
Avant d'importer des données sur Google Play, vérifiez les éléments suivants. N'oubliez pas qu'elles s'appliquent particulièrement à 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
- Si les versions de plate-forme des APK se chevauchent, celui dont la valeur minSdkVersion est la plus élevée doit avoir un code de version plus élevé.
- Vérifiez que vos filtres de fichiers manifestes ne contiennent pas d'informations contradictoires (un APK compatible uniquement avec cupcake sur les écrans XLARGE ne sera visible par personne)
- Le fichier manifeste de chaque APK doit être unique sur au moins un écran, une texture OpenGL ou une version de plate-forme compatibles
- Essayez de tester chaque APK sur au moins un appareil. Sauf cela, l'un des émulateurs d'appareils les plus personnalisables du secteur se trouve sur votre ordinateur de développement. Devenez dingue !
Il est également utile d'inspecter l'APK compilé avant de le lancer sur le marché, afin de vous assurer qu'aucune surprise ne pourrait cacher 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 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: 'small' 'normal' 'large' '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 ne sera pas visible sur de nombreux appareils.
Pourquoi ? En ajoutant l'autorisation requise SEND_SMS, l'exigence de fonctionnalité d'android.hardware.telephony a été implicitement ajoutée. Étant donné que l'API 11 est Honeycomb (la version d'Android optimisée spécifiquement pour les tablettes) et qu'aucun appareil Honeycomb ne dispose de matériel de téléphonie, Google Play filtre cet APK dans tous les cas, jusqu'à ce que de futurs appareils avec un niveau d'API supérieur ET disposant de matériel de téléphonie soient disponibles.
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, vous devez ajouter ce qui suit à votre fichier manifeste:
<uses-feature android:name="android.hardware.touchscreen" android:required="false" />
Une fois que vous avez terminé la checklist 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, afin de vous assurer que les APK ciblent les appareils appropriés. Félicitations, vous avez terminé !