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 afin de 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 maux de tête inutiles. plus loin dans le processus de développement. Cette leçon vous explique comment créer plusieurs APK application, chacune couvrant une classe différente de taille d'écran. Vous apprendrez également certains outils nécessaires pour la gestion de plusieurs codebases APK est aussi simple que possible.
Vérifier que vous avez besoin de plusieurs APK
Lorsque vous essayez de créer une application compatible avec la vaste gamme d'applications Android vous voulez que votre application s'affiche de manière optimale sur chaque appareil. Vous souhaitez exploiter l'espace des grands écrans tout en continuant à travailler sur les petits écrans, pour utiliser la nouvelle API Android caractéristiques ou textures visuelles disponibles sur les appareils de pointe, mais n’abandonnent pas les anciens. Il peut peut sembler au départ que la prise en charge de plusieurs fichiers APK est la meilleure solution, mais ce n'est souvent pas . La section Utilisation La section "Un seul fichier APK à la place" du guide consacré à la gestion de plusieurs fichiers APK contient des informations utiles pour savoir comment tout cela avec un seul APK, y compris en utilisant notre bibliothèque Support, et des liens vers les ressources du guide du développeur Android.
Si vous pouvez le gérer, confiner votre application à un seul APK présente plusieurs avantages. y compris:
- La publication et les tests sont plus faciles
- Il n'y a qu'un seul codebase à gérer
- Votre application peut s'adapter aux modifications de la configuration de l'appareil
- La restauration des applications sur tous les appareils fonctionne
- Vous n'avez pas à vous soucier de la préférence du marché, du comportement lié aux "mises à niveau" d'un fichier APK ou choisir quel APK correspond à quelle classe d'appareils.
Le reste de cette leçon part du principe que vous avez fait des recherches sur le sujet, assimilé attentivement dans les ressources associées, et nous avons déterminé que plusieurs APK correspondaient 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 l'écran la ou les tailles couvertes par chaque APK. Heureusement, il est facile de déterminer vos besoins afin de pouvoir s'y référer facilement par la suite. Imaginons que vous souhaitiez diviser vos APK en deux dimensions, "API" et la taille de l'écran. Créez un tableau avec une ligne et une colonne pour chaque paire de valeurs possible, puis colorez des "gouttes", chaque couleur représentant un APK.
| 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | + | |
| petit | |||||||||||
| normal | |||||||||||
| grand | |||||||||||
| xlarge |
Vous trouverez ci-dessus un exemple avec quatre APK. Le bleu correspond à tous les appareils à écran normal ou de petite taille, et le vert à ceux de grande taille. les appareils à écran, tandis que le rouge est pour les appareils à très grand écran, tous avec une plage d'API de 3 à 10. Le violet est un un cas particulier, comme c'est le cas pour toutes les tailles d'écran, mais uniquement pour l'API 11 ou une version ultérieure. Plus important encore, juste en en regardant ce graphique, vous savez immédiatement quel APK couvre une combinaison API/taille d'écran donnée. À vous avez également un nom de code chic pour chacun d'entre eux, puisque « Avons-nous testé le rouge sur le ? » est beaucoup plus simple à demander à votre client que "Avons-nous testé le fichier APK de 3 à 10 très grand APK avec la tablette Xoom ?" Imprimer créer un graphique et le transmettre à chaque personne travaillant sur votre codebase. Votre vie vient de devenir beaucoup plus simple.
Placer l'ensemble du code et des ressources courants dans un projet de bibliothèque
Qu'il s'agisse de modifier une application Android existante ou d'en créer une, c'est est la première chose que vous devez faire au codebase, et de loin la plus importante. Tout 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 langue, thèmes de couleur, bugs corrigés dans le code partagé), ce qui accélère le développement et réduit la probabilité 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 accepte plusieurs fichiers APK, Parcourez votre codebase à la recherche de fichiers de chaînes localisés, de listes de valeurs, de thèmes les couleurs, les icônes de menu et la mise en page qui ne changent pas d'un APK à l'autre, et mettez le 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 vous retrouverez probablement à étendre ces pour ajouter une ou deux méthodes d'APK à APK.
En revanche, si vous créez l'application en partant de zéro, essayez autant que possible d'écrire le code d'abord dans le projet de bibliothèque, puis de le déplacer vers le bas un APK individuel si nécessaire. C'est beaucoup plus facile à gérer à long terme que de l'ajouter à un, puis un autre, puis un autre, et plusieurs mois plus tard, on tente de déterminer si ce blob peut être déplacé vers le haut à la section de la bibliothèque sans vous ruiner.
Créer des projets APK
Chaque APK que vous allez publier doit disposer d'un projet Android distinct. Pour faciliter 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écessairement partager le nom du package 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-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émarrage dans le projet de bibliothèque et étendez-la dans votre projet APK. Avoir une activité de départ définie dans le projet Bibliothèque vous permet de mettre toutes l'initialisation de votre application au même endroit, de sorte que chaque APK n'ait pas à réimplémentez une configuration "universelle" des tâches telles que l'initialisation d'Analytics, la vérification des licences, etc. des procédures d'initialisation qui ne changent pas beaucoup d'un APK à l'autre ;
Ajuster les fichiers manifestes
Lorsqu'un utilisateur télécharge une application qui utilise plusieurs APK via Google Play, la bonne L'APK à 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écrit précédemment et supposons que chaque APK a été défini pour prendre en charge toutes les tailles d'écran supérieures à sa taille d'écran "cible". Examinons de plus près l'exemple de graphique de tout à l'heure:
| 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | + | |
| petit | |||||||||||
| normal | |||||||||||
| grand | |||||||||||
| xlarge |
Étant donné que la couverture peut se chevaucher, nous pouvons décrire la zone couverte par chaque APK comme suit : Par conséquent:
- Le bleu couvre tous les écrans, SDK minimal 3.
- Le vert s'applique aux grands écrans et aux versions ultérieures, SDK minimal 3.
- Le rouge couvre les écrans XLarge (généralement des tablettes), avec un SDK minimal de 9.
- Le violet couvre tous les écrans, SDK minimal de 11.
Notez qu'il existe de nombreux chevauchements entre ces règles. Par exemple, un Un appareil très volumineux doté de l'API 11 peut exécuter l'un des quatre fichiers 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 l'APK Purple comporte une exigence que les deux autres n'ont pas. La page Filtres sur Google Play du guide du développeur Android contient toute une liste de coupables possibles. Pour cet exemple, partons du principe que Violet nécessite une caméra frontale. En fait, le but de Violet est de Utilisez des objets de divertissement avec la caméra frontale ! Mais il s'avère que tous les appareils utilisant l'API 11+ POSSÈDENT des caméras avant ! Quelle horreur !
Heureusement, si un utilisateur navigue sur Google Play à partir de l'un de ces appareils, Google Play examine fichier manifeste, voir que Purple indique que la caméra frontale est une exigence et l'ignorer discrètement, après avoir déterminé que Violet et que cet appareil ne correspond pas au paradis numérique. Ensuite, vous voyez que Red est non seulement compatible avec les très grands appareils, mais ne se soucie pas non plus de savoir si il y a une caméra frontale ! L'utilisateur peut toujours télécharger l'application sur Google Play, car malgré l'erreur de la caméra avant, il existait encore un APK compatible avec cette niveau d'API.
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 code recommandé est indiqué dans la zone Codes de version de consultez notre guide du développeur. Il peut être utile de lire toute la section, mais l'essentiel concerne cet ensemble de APK, nous utiliserions deux chiffres pour représenter la taille minimale du SDK, deux pour la taille d'écran minimale/maximale et 3 pour représenter le numéro de build. De cette façon, lorsque l'appareil est mis à niveau vers une nouvelle version d'Android, (par exemple, de 10 à 11), tous les APK désormais éligibles et préférés par rapport à celui actuellement installé. est perçue par l'appareil comme une "mise à niveau". Schéma du numéro de version, lorsqu'il est appliqué à l'exemple d'APK, pourrait ressembler à ceci:
Bleu: 0304001, 0304002, 0304003...
Vert : 0334001, 0334002, 0334003
Rouge : 0344001, 0344002, 0344003...
Violet: 1104001, 1104002, 1104003...
En regroupant tout, 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 APK fonctionneront avec la balise "supports-screens" ou la balise "compatible-screens". Compatible avec les écrans, ce qui est généralement un problème très négatif idée d'utiliser les deux. Cela rend les choses inutilement compliquées et augmente le risque d'erreurs. Notez également qu'au lieu d'utiliser 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. Cela peut vous éviter des problèmes plus tard. Par exemple, la valeur xlarge sera 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 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 représentent en aucun cas une checklist complète pour toutes les applications mises en ligne 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 supérieur.
- Toutes les tailles d'écran compatibles avec votre APK, définies sur "true" dans le fichier manifeste. Toutes les tailles d'écran à éviter, définissez ce paramètre sur "false".
- Vérifiez que vos filtres de manifestes ne contiennent pas d'informations contradictoires (un APK qui ne prend en charge cupcake sur les écrans XLARGE ne sera vu par personne)
- Le fichier manifeste de chaque APK doit être unique sur au moins un des types d'écran, de texture OpenGL ou de la plate-forme.
- Essayez de tester chaque APK sur au moins un appareil. Sauf cela, vous avez l'un des émulateurs d'appareils personnalisables intégrés à votre ordinateur de développement. Allez-y !
Pensez également à inspecter l'APK compilé avant de le lancer sur le marché, pour vous assurer toute surprise qui pourrait cacher votre application sur Google Play. C'est en fait assez simple en utilisant "aapt" . Aapt (Android Asset Packaging Tool) fait partie du processus de compilation permettant de créer empaqueter vos applications Android et 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 que vous n'avez pas de valeurs en conflit pour prend en charge les écrans compatibles et les écrans compatibles, et que vous ne disposez pas de la caractéristique "uses-feature" involontaire valeurs qui ont été ajoutées suite à des autorisations définies dans le fichier manifeste. Dans l'exemple ci-dessus, le fichier 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é 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, 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, 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. Une dernière vérification doit être effectuée. 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é !