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 des appareils Android de différentes tailles, vous souhaitez naturellement qu'elle exploite tout l'espace disponible sur les appareils plus grands, sans sacrifier la compatibilité ou la facilité d'utilisation sur les petits écrans. Au début, 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 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. Nous vous invitons également à lire le guide sur la prise en charge de plusieurs écrans. Vous pouvez même télécharger une bibliothèque Support à l'aide du SDK Android. Elle vous permet d'utiliser des fragments sur des appareils antérieurs à Honeycomb, ce qui facilite grandement la compatibilité avec plusieurs écrans dans un seul APK.
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 de disposer d'une référence ultérieure. Commencez par une ligne de cellules représentant les différentes tailles d'écran disponibles sur la plate-forme Android.
| petit | normale | grand | xlarge |
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 tailles d'écran.
| petit | normale | grand | xlarge |
En fonction de vos besoins, vous pouvez également avoir deux APK : "petit et tout le reste" ou "XL et tout le reste". La coloration du graphique facilite également la communication au sein de l'équipe. Vous pouvez désormais désigner chaque APK comme "bleu", "vert" ou "rouge", quel que soit le nombre de types d'écrans différents qu'il couvre.
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écrits précédemment et supposons que chaque APK a été configuré pour prendre en charge toutes les tailles d'écran plus grandes que sa taille d'écran "cible". Pris individuellement, la plage possible de chaque APK ressemblerait à ceci:
| petit | normale | grand | xlarge |
| petit | normale | grand | xlarge |
| petit | normale | grand | xlarge |
Toutefois, si vous utilisez la règle "le numéro de version le plus élevé l'emporte", si vous définissez l'attribut versionCode dans chaque APK de sorte que rouge ≥ vert ≥ bleu, le graphique se réduit effectivement à ceci:
| petit | normale | grand | xlarge |
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. L'objectif de l'APK rouge est d'utiliser l'espace supplémentaire disponible à l'écran pour divertir vos spectateurs avec cette caméra frontale. Mais, il s'avère que tous les appareils très grands n'ont même pas une caméra frontale ! Quelle 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 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é le problème avec la caméra avant, il existait toujours un APK compatible avec cette taille d'écran particulière.
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 serait suffisant de séparer chaque APK de 1 000 et de l'incrémenter. 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-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="2001" android:versionName="1.0" package="com.example.foo">
<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="3001" android:versionName="1.0" package="com.example.foo">
<supports-screens android:smallScreens="false"
android:normalScreens="false"
android:largeScreens="false"
android:xlargeScreens="true" />
...
Notez que, techniquement, plusieurs APK fonctionnent avec la balise "support-screens" ou "compatible-screens" L'utilisation des écrans compatibles est généralement préférable, et il est généralement déconseillé d'utiliser les deux balises dans le même fichier manifeste. 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 la suite. Par exemple, pour un fichier manifeste avec un SDK cible inférieur à 9, l'option 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.
- Toutes les tailles d'écran que vous souhaitez que votre APK prenne en charge, définies sur "true" dans le fichier manifeste. Chaque taille d'écran que vous voulez éviter, définissez 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 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, ce problème peut être facilement résolu 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 peu de temps avant que l'application ne s'affiche lorsque vous naviguez sur Google Play, mais lorsque c'est le cas, effectuez une dernière vérification. Téléchargez l'application sur tous les appareils de test que vous devrez peut-être vous assurer que les APK ciblent les appareils prévus.
Pour en savoir plus sur la publication de plusieurs APK sur Google Play, consultez la section Prendre en charge plusieurs fichiers APK.