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 classe de taille d'écran 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 compatible avec plusieurs tailles d'appareils Android, vous souhaitez naturellement qu'elle exploite tout l'espace disponible sur les appareils plus grands, sans sacrifier la compatibilité ni l'usabilité sur les écrans plus petits. Au départ, il peut sembler que la prise en charge de plusieurs fichiers 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 l'utilisation de notre bibliothèque d'assistance. Nous vous recommandons également de lire le guide sur la prise en charge de plusieurs écrans. Il existe même une bibliothèque Support que vous pouvez télécharger à l'aide du SDK Android, qui vous permet d'utiliser des fragments sur des appareils antérieurs à Honeycomb (ce qui rend la prise en charge de plusieurs écrans dans un seul APK beaucoup plus facile).
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 simples
- Il n'y a qu'un seul codebase à 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.
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.
Définir vos besoins
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 qu'ils couvrent. Heureusement, il est facile de déterminer vos besoins rapidement et facilement, et de disposer d'une référence pour plus tard. Commencez par une ligne de cellules représentant les différentes tailles d'écran disponibles sur la plate-forme Android.
| petit | normal | 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 | normal | grand | xlarge |
Selon vos besoins, vous pouvez également avoir deux APK, "small and everything else" (petit et tout le reste) ou "xlarge and everything else" (très grand et tout le reste). La coloration du graphique facilite également la communication au sein de l'équipe. Vous pouvez désormais simplement désigner chaque APK par "bleu", "vert" ou "rouge", quel que soit le nombre de types d'écrans qu'il couvre.
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 entre dans le projet de bibliothèque ne doit être mis à jour qu'une seule fois (par exemple, les chaînes localisées en langage, les thèmes de couleurs, les 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 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 de l'ajouter à l'un, puis à l'autre, puis à l'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 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 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é à utiliser est choisi selon deux règles simples:
- Le fichier manifeste doit indiquer qu'un APK particulier 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 supérieures à sa taille d'écran "cible". Prises individuellement, la plage possible de chaque APK ressemblerait à ceci:
| petit | normal | grand | xlarge |
| petit | normal | grand | xlarge |
| petit | normal | grand | xlarge |
Toutefois, en appliquant la règle "le numéro de version le plus élevé l'emporte", si nous définissons l'attribut versionCode dans chaque APK de sorte que le rouge ≥ le vert ≥ le bleu, le graphique se réduit à ceci :
| petit | normal | grand | xlarge |
Supposons maintenant que le fichier APK rouge présente des exigences contraires aux deux autres. La page 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 frontale. En fait, l'intérêt de l'APK rouge est d'utiliser l'espace supplémentaire disponible à l'écran pour faire des choses amusantes avec cette caméra avant. Mais il s'avère que tous les appareils de grande taille n'ont pas de caméra avant. L'horreur !
Heureusement, si un utilisateur navigue sur Google Play à partir de l'un de ces appareils, Google Play examine le fichier manifeste, constate que Red indique que la caméra frontale est requise, puis l'ignore discrètement, après avoir déterminé que Red et cet appareil ne correspondent pas au paradis numérique. Il verra alors que la couleur verte n'est pas seulement compatible avec les appareils de grande taille, mais qu'elle ne dépend pas de la présence ou non d'une caméra avant. 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 cette taille d'écran particulière.
Pour que tous vos APK soient 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 concerne qu'une seule des trois dimensions possibles, il suffit de séparer chaque APK par 1 000 et d'augmenter à partir de là. Cela peut se présenter comme suit:
Bleu: 1001, 1002, 1003, 1004...
Vert : 2001, 2002, 2003, 2004…
Rouge : 3001, 3002, 3003, 3004...
En réunissant ces éléments, vos fichiers manifestes Android ressembleraient probablement à ceci:
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 fonctionneront avec la balise "supports-screens" ou la balise "compatible-screens". Supports-screens est généralement privilégié, et il est généralement très déconseillé d'utiliser les deux balises dans le même fichier manifeste. Cela rend les choses inutilement compliquées et augmente le risque d'erreurs. Notez également qu'au lieu d'exploiter les valeurs par défaut (les valeurs "small" et "normal" sont toujours "true" par défaut), les fichiers manifestes définissent explicitement la valeur de chaque taille d'écran. Vous éviterez ainsi des problèmes plus tard. Par exemple, la valeur xlarge est automatiquement définie sur "false" pour un fichier manifeste dont le SDK cible est inférieur à 9, car cette taille n'existait pas encore. Soyez donc explicite !
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'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
- Chaque taille d'écran que vous souhaitez que votre APK prenne en charge, définie sur "true" dans le fichier manifeste. Chaque taille d'écran que vous souhaitez éviter, définie sur "false"
- Vérifiez que vos filtres de fichiers manifestes ne contiennent pas d'informations contradictoires (un APK qui ne prend en charge que cupcake sur les écrans XLARGE ne sera visible par personne).
- Le fichier manifeste de chaque APK doit être unique pour au moins un des écrans, textures OpenGL ou versions 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 est installé 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 de création et d'empaquetage de vos applications Android. C'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é implicitement ajoutée. É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 ce qui suit à 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 s'affiche lorsque vous naviguez sur Google Play. Vous devrez alors effectuer 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.
Pour en savoir plus sur la publication de plusieurs APK sur Google Play, consultez Compatibilité avec plusieurs fichiers APK.