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 classe différente de tailles d'écran. 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 la vaste gamme d'appareils Android disponibles, vous souhaitez naturellement que votre application s'affiche au mieux sur chaque appareil. Vous souhaitez profiter de l'espace des grands écrans, mais continuer à travailler sur les petits, pour utiliser les nouvelles fonctionnalités ou textures visuelles de l'API Android disponibles sur les appareils de pointe, sans abandonner les anciens. 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 consacré à plusieurs APK 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 Support, ainsi que des liens vers les ressources du guide du développeur Android.
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 ou les tailles d'écran couvertes par chaque APK. Heureusement, il est facile de définir vos besoins rapidement et facilement, et vous pouvez facilement vous y référer ultérieurement. Imaginons que vous souhaitiez diviser vos APK en deux dimensions : l'API et la taille de l'écran. Créez une table avec une ligne et une colonne pour chaque paire de valeurs possible, et une couleur dans certains "blobs", chaque couleur représentant un APK.
| 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | + | |
| petit | |||||||||||
| normale | |||||||||||
| grand | |||||||||||
| xlarge |
L'exemple ci-dessus montre quatre APK. Le bleu correspond à tous les appareils à petit écran ou à un écran normal, le vert aux appareils à grand écran et le rouge aux appareils à très grand écran, tous avec une plage d'API comprise entre 3 et 10. Le violet est un cas particulier, car il est utilisé pour toutes les tailles d'écran, mais uniquement pour l'API 11 ou ultérieure. Plus important encore, rien qu'en regardant ce graphique, vous savez immédiatement quel APK couvre une combinaison API/taille d'écran donnée. Pour démarrer, vous avez également un nom de code chic pour chacun d'entre eux, car il est beaucoup plus facile de demander à votre cubie la question "Avons-nous testé le rouge sur le cube ?" que "Avons-nous testé le fichier APK 3-à-10 xlarge contre le Xoom ?". Imprimez ce graphique et remettez-le à toutes les personnes travaillant sur votre codebase. La vie est désormais bien plus simple.
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-purple 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écrits précédemment et supposons que chaque APK a été configuré pour prendre en charge toutes les tailles d'écran plus grandes que la taille d'écran "cible". Examinons l'exemple de graphique de tout à l'heure:
| 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | + | |
| petit | |||||||||||
| normale | |||||||||||
| grand | |||||||||||
| xlarge |
Étant donné qu'il est acceptable que la couverture se chevauche, nous pouvons décrire la zone couverte par chaque APK comme suit:
- Le bleu couvre tous les écrans. SDK 3 minimum.
- Le vert couvre les grands écrans et les versions ultérieures (SDK 3 minimum).
- Le rouge couvre les très grands écrans (généralement les tablettes), SDK minimal de 9.
- Le violet couvre tous les écrans (SDK minimal de 11).
Notez que ces règles présentent de nombreux points communs. Par exemple, un appareil de grande taille doté de l'API 11 est en mesure d'exécuter l'un des quatre APK spécifiés. Toutefois, en utilisant la règle "le numéro de version le plus élevé l'emporte", nous pouvons définir un ordre de préférence comme suit:
Violet ≥ Rouge ≥ Vert ≥ Bleu
Pourquoi autoriser tous les chevauchements ? Supposons que le fichier APK Purple ne comporte aucune exigence spécifique aux deux autres. 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 violet nécessite une caméra frontale. En fait, l'objectif de Violet est d'utiliser des choses divertissantes avec la caméra frontale ! Mais, il s'avère que tous les appareils utilisant l'API 11 ou une version ultérieure n'ONT même pas de caméra frontale ! Quelle horreur !
Heureusement, si un utilisateur navigue sur Google Play depuis l'un de ces appareils, Google Play consulte le fichier manifeste, voit que Purple indique que la caméra frontale est requise, puis l'ignore discrètement, après avoir déterminé que Purple et cet appareil ne correspondent pas au paradis numérique. Il constatera alors que le rouge n'est pas seulement compatible avec les appareils de grande taille, mais 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é tout le problème avec la caméra avant, il y avait 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. Il peut être utile de lire la section dans son intégralité, mais l'essentiel est que cet ensemble d'APK utilise deux chiffres pour représenter le SDK minimal, deux pour représenter la taille d'écran minimale/maximale et trois pour le numéro de build. Ainsi, lorsque l'appareil passera à une nouvelle version d'Android (de la version 10 à la version 11, par exemple), tous les APK désormais éligibles et préférés à ceux actuellement installés seront considérés par l'appareil comme une "mise à jour". Le schéma de numéro de version, appliqué à l'exemple d'ensemble d'APK, peut se présenter comme suit:
Bleu: 0304001, 0304002, 0304003...
Vert: 0334001, 0334002, 0334003
Rouge: 0344001, 0344002, 0344003...
Violet: 1104001, 1104002, 1104003...
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="0304001" android:versionName="1.0" package="com.example.foo">
<uses-sdk android:minSdkVersion="3" />
<supports-screens android:smallScreens="true"
android:normalScreens="true"
android:largeScreens="true"
android:xlargeScreens="true" />
...
Vert :
<manifest xmlns:android="http://schemas.android.com/apk/res/android"
android:versionCode="0334001" android:versionName="1.0" package="com.example.foo">
<uses-sdk android:minSdkVersion="3" />
<supports-screens android:smallScreens="false"
android:normalScreens="false"
android:largeScreens="true"
android:xlargeScreens="true" />
...
Rouge :
<manifest xmlns:android="http://schemas.android.com/apk/res/android"
android:versionCode="0344001" android:versionName="1.0" package="com.example.foo">
<uses-sdk android:minSdkVersion="3" />
<supports-screens android:smallScreens="false"
android:normalScreens="false"
android:largeScreens="false"
android:xlargeScreens="true" />
...
Violet:
<manifest xmlns:android="http://schemas.android.com/apk/res/android"
android:versionCode="1104001" android:versionName="1.0" package="com.example.foo">
<uses-sdk android:minSdkVersion="11" />
<supports-screens android:smallScreens="true"
android:normalScreens="true"
android:largeScreens="true"
android:xlargeScreens="true" />
...
Notez que, techniquement, plusieurs fichiers APK fonctionnent avec la balise "support-screens" ou "compatible-screens" L'utilisation des écrans compatibles est généralement préférable, et il n'est généralement pas judicieux d'utiliser les deux, car cela complique inutilement les choses et augmente le risque d'erreurs. Notez également qu'au lieu de tirer parti des valeurs par défaut (les valeurs "small" et "normal" sont toujours vraies par défaut), les fichiers manifestes définissent explicitement la valeur pour chaque taille d'écran. Cela peut vous éviter des désagréments. Par exemple, pour un fichier manifeste dont le SDK cible est inférieur à 9, la valeur xlarge est automatiquement définie sur "false", puisque cette taille n'existait pas encore. Soyez donc explicite !
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.
- 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é.
- Toutes les tailles d'écran que vous souhaitez que votre APK prenne en charge, définies sur "true" dans le fichier manifeste. Définissez toutes les tailles d'écran que vous souhaitez éviter sur "false".
- 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 un é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é !