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 loin dans le processus de développement. Cette leçon vous explique comment créer plusieurs APK de votre application, chacun couvrant une plage légèrement différente de niveaux d'API. Vous bénéficierez également des outils nécessaires pour faciliter au maximum la gestion de plusieurs fichiers APK.
Confirmer 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 que votre application bénéficie des nouvelles fonctionnalités sur les nouveaux appareils, sans sacrifier la rétrocompatibilité. Vous pouvez sembler dès le départ la meilleure solution pour la compatibilité avec plusieurs fichiers APK, mais ce n'est souvent pas le cas. La section Utiliser un seul fichier APK du guide du développeur pour les fichiers APK multiples contient des informations utiles sur la façon de procéder avec un seul fichier APK, y compris sur l'utilisation de notre bibliothèque d'aide. 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 calcul telles que la réflexion décrite dans cet article.
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
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 plus de commodité, la page Versions de la plate-forme du site Web des 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. En outre, bien que cela semble facile au premier abord, il est assez rapidement difficile de savoir quel ensemble de niveaux d'API cibler chaque APK, surtout en cas de chevauchement (ce qui arrive souvent). Heureusement, il est facile de déterminer rapidement et facilement vos besoins, et vous pouvez vous y référer facilement par la suite.
Pour créer un graphique avec plusieurs fichiers APK, commencez par une ligne de cellules représentant les différents niveaux d'API de la plate-forme Android. Lancement d'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 ans | + |
Il 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 ans | + |
Une fois que vous avez créé ce graphique, distribuez-le à votre équipe. La communication d'équipe sur votre projet a été immédiatement simplifiée, puisqu'au lieu de demander "Quel est l'état de l'APK pour les niveaux d'API 3 à 6 ? Euh, vous savez, celui d'Android 1.x. Comment ça se passe ? » Vous pouvez simplement dire : "Comment se passe l'APK bleu ?".
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 deux 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,
À titre d'exemple, prenons l'ensemble de plusieurs APK décrit 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 ressemblerait à ceci:
| 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 ans | + |
| 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 ans | + |
| 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 ans | + |
É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 versionCode, rouge ≥ vert ≥ 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 ans | + |
Supposons maintenant que le fichier Red APK comporte une exigence que les deux autres n'ont pas. La page Filtres sur Google Play du guide du développeur Android présente la liste complète des causes possibles. Par exemple, supposons que le rouge nécessite une caméra frontale. En fait, l'objectif de l'APK rouge est de combiner la caméra frontale avec de nouvelles fonctionnalités intéressantes ajoutées dans l'API 11. Mais il s'avère que tous les appareils compatibles avec l'API 11 n'ont même pas de caméra frontale. L'horreur !
Heureusement, si un utilisateur navigue sur Google Play à partir de l'un de ces appareils, Google Play consulte le fichier manifeste, voit que Red liste la caméra frontale comme obligatoire, puis l'ignore discrètement, après avoir déterminé que rouge et cet appareil ne correspondent pas au paradis numérique. Il constatera alors que le vert n'est pas seulement compatible avec les appareils avec l'API 11 (puisqu'aucune valeur maxSdkVersion n'a été définie), mais qu'il ne se soucie pas non plus de la présence ou non d'une caméra frontale. L'utilisateur peut toujours télécharger l'application depuis Google Play, car malgré le problème avec la caméra avant, il existait toujours un APK compatible avec ce niveau d'API particulier.
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 celui recommandé dans la section Codes de version de notre guide du développeur. Étant donné que l'exemple d'ensemble d'APK ne traite que l'une des trois dimensions possibles, il suffirait de séparer chaque APK par 1 000, de définir les deux premiers chiffres sur la valeur minSdkVersion pour cet APK spécifique, puis de procéder à l'incrémentation. Cela peut se présenter comme suit:
Bleu: 03001, 03002, 03003, 03004...
Vert: 07001, 07002, 07003, 07004...
Rouge:11 001, 11 002, 11 003, 11 004...
En résumé, vos fichiers manifestes Android ressembleront probablement à ceci:
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" />
...
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'il s'applique spécifiquement à plusieurs APK et qu'il ne s'agit en aucun cas d'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 APK se chevauchent dans la version de la plate-forme, celui dont la version minSdkVersion est la plus élevée doit avoir un code de version plus élevé
- Vérifiez que les filtres de votre fichier manifeste ne contiennent pas d'informations contradictoires (un APK compatible uniquement avec cupcake sur les écrans XLARGE n'est visible par personne).
- Le fichier manifeste de chaque APK doit être unique sur au moins une version d'écran, de texture OpenGL ou de plate-forme compatible
- Essayez de tester chaque APK sur au moins un appareil. À défaut, l'un des émulateurs d'appareils les plus personnalisables du marché 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: 'small' 'normal' 'large' '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 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é ajoutée implicitement. Étant donné que l'API 11 est Honeycomb (la version d'Android optimisée spécifiquement pour les tablettes) et qu'aucun appareil Honeycomb n'est équipé de matériel de téléphonie, Google Play filtrera cet APK dans tous les cas, jusqu'à ce que de futurs appareils de niveau d'API supérieur ET possèdent du 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 tous les appareils de test que vous possédez afin de vous assurer que les fichiers APK ciblent bien les appareils souhaités. Félicitations, vous avez terminé !