Si vous publiez votre application sur Google Play, vous devez compiler et importer un Android App Bundle (AAB). Google Play génère et diffuse automatiquement des APK optimisés pour la configuration de l'appareil de chaque utilisateur. Ils ne téléchargent ainsi que le code et les ressources dont ils ont besoin pour exécuter votre application. La publication de plusieurs 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 profiter de plusieurs APK sur Google Play, il est important d'adopter dès le départ de bonnes pratiques et d'éviter les problèmes inutiles plus tard dans le 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 obtiendrez également des outils nécessaires pour faciliter la maintenance d'un codebase multi-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 pour plusieurs APK inclut des informations utiles pour y parvenir avec un seul APK, y compris l'utilisation de notre bibliothèque d'assistance. 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 le pouvez, limiter votre application à un seul APK présente plusieurs avantages, dont les suivants:
- La publication et les tests sont plus faciles
- Il n'y a qu'une seule base de code à 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 des "mises à niveau" d'un APK à un autre, ni de l'APK associé à une classe d'appareils.
Le reste de cette leçon suppose que vous avez effectué des recherches sur le sujet, que vous avez absorbé le contenu des ressources associées et que vous avez déterminé que plusieurs APK sont la bonne solution 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, 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. De plus, bien que cela semble facile au premier abord, suivre l'ensemble de niveaux d'API que chaque APK va cibler devient rapidement difficile, en particulier s'il y a des chevauchements (il y en a souvent). Heureusement, il est facile de dresser vos exigences rapidement et facilement, et de les consulter facilement plus tard.
Pour créer votre graphique multi-APK, commencez par 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 colorier 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 ce graphique créé, distribuez-le à votre équipe. La communication en équipe sur votre projet vient d'être immédiatement simplifiée, car au lieu de demander "Comment va l'APK pour les niveaux d'API 3 à 6, euh, vous savez, celui d'Android 1.x. Comment ça avance ?" Vous pouvez simplement dire "Comment avance l'APK Blue ?"
Placer tout le code et toutes les ressources communs dans un projet de bibliothèque
Que vous modifiiez une application Android existante ou que vous en créiez une à partir de zéro, c'est la première chose que vous devez faire avec le 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 et 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 de l'implémentation de la création et de l'inclusion de projets de bibliothèque ne relèvent pas du champ d'application de ce cours, vous pouvez vous familiariser avec le sujet en lisant Créer une bibliothèque Android.
Si vous convertissez une application existante pour qu'elle prenne en charge plusieurs APK, recherchez dans votre codebase tous les fichiers de chaînes localisées, les listes de valeurs, les couleurs de thème, les icônes de menu et la mise en page qui ne changeront pas entre les APK, puis placez-les tous 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 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 aviez trois APK suivant le schéma décrit précédemment, votre répertoire racine pourrait 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émarrage dans le projet de bibliothèque et étendez-la 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é est sélectionné à l'aide de deux règles simples:
- Le fichier manifeste doit indiquer qu'un APK particulier est éligible.
- Parmi les APK éligibles, celui dont le numéro de version est le plus élevé remporte l'enchère.
Par exemple, prenons l'ensemble de plusieurs APK décrit précédemment et supposons que nous n'avons pas défini de niveau d'API maximal pour aucun d'entre eux. 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 versionCode, le rouge ≥ le vert ≥ le bleu. Nous pouvons donc réduire le graphique pour qu'il se présente comme suit:
| 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | + |
Supposons maintenant que l'APK rouge présente une exigence que les deux autres n'ont pas. La page Filtres sur Google Play du guide du développeur Android contient une liste complète des 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 compatibles avec l'API 11 ne disposent pas d'une caméra avant. 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 verra alors que Green n'est pas seulement rétrocompatible avec les appareils équipés de l'API 11 (puisqu'aucune valeur maxSdkVersion n'a été définie), mais qu'il ne se soucie 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 ce niveau d'API particulier.
Pour que tous vos APK soient sur des "canaux" distincts, il est important de disposer d'un bon schéma de code de version. Vous trouverez la valeur recommandée dans la section Codes de version de notre guide du développeur. Étant donné que l'exemple d'ensemble d'APK ne concerne que l'une des trois dimensions possibles, il suffit de séparer chaque APK par 1 000, de définir les deux premiers chiffres sur la valeur minSdkVersion de cet APK particulier, puis d'augmenter à 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 devraient se présenter 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" /> ...
Vérifier votre checklist de pré-lancement
Avant d'importer votre application sur Google Play, vérifiez les points suivants. N'oubliez pas que ces points sont spécifiquement pertinents pour plusieurs APK et 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 fichier manifeste ne contiennent pas d'informations contradictoires (un APK qui n'est compatible qu'avec Cupcake sur les écrans XLARGE ne sera vu 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. À défaut, vous disposez de l'un des émulateurs d'appareils les plus personnalisables du marché sur votre ordinateur de développement. Allez-y !
Il est également utile d'inspecter l'APK compilé avant de le mettre sur le marché, afin de s'assurer qu'il n'y a pas de surprises qui pourraient masquer votre application sur Google Play. C'est en fait très simple à l'aide de 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'y a pas de valeurs contradictoires pour "supports-screens" et "compatible-screens", et qu'il n'y a 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 par de très 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 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 un matériel de téléphonie soient disponibles.
Heureusement, ce problème est facile à résoudre 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 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 terminé la checklist de 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 pour vous assurer que les APK ciblent les appareils prévus. Félicitations, vous avez terminé !