Créer plusieurs fichiers APK pour différents niveaux d'API

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 chacun couvrant un éventail légèrement différent de niveaux d'API. Vous découvrirez également des outils pour que la gestion de plusieurs codebases APK soit aussi simple que possible.

Vérifier que vous avez besoin de plusieurs APK

Lorsque vous essayez de créer une application compatible avec plusieurs générations d'applications Vous voulez que votre application bénéficie des nouvelles fonctionnalités sur les nouveaux appareils, sans sacrifier la rétrocompatibilité. Au départ, vous pouvez avoir l'impression que plusieurs fichiers APK est la meilleure solution, mais ce n'est souvent pas le cas. L'option Utiliser un seul APK Au lieu de cela, la section du guide du développeur utilisant plusieurs fichiers APK contient des informations utiles sur la façon de avec un seul APK, en utilisant notre bibliothèque Support. Vous pouvez également apprendre à écrire du code qui ne s'exécute qu'à certains niveaux d'API dans un seul APK, sans avoir à utiliser techniques coûteuses en calcul, telles que la réflexion à partir de consultez cet article.

Si vous pouvez le gérer, confiner votre application à un seul APK comporte plusieurs tels que les suivants:

  • La publication et les tests sont plus faciles
  • 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 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 de fichiers APK dont vous avez besoin et l'API concernée. plage couverte par chaque APK. Pour plus d'informations, consultez la page Versions de la plate-forme de la Le site Web des développeurs Android fournit des données sur le nombre relatif d'appareils actifs exécutant de la plate-forme Android. Aussi, même si cela semble facile au premier abord, garder une trace de quel jeu de niveaux d'API que chaque APK cible devient difficile assez rapidement, surtout s'il y a un chevauchement (cela se produit souvent). Heureusement, il est facile de déterminer rapidement vos besoins, facilement et d’avoir une référence facile pour plus tard.

Pour créer un graphique comportant plusieurs APK, commencez avec une ligne de cellules représentant le différents niveaux d'API de la plate-forme Android. Générer une cellule supplémentaire à la fin pour représenter le futur versions d'Android.

3 4 5 6 7 8 9 10 11 12 13 +

Maintenant, colorez simplement le graphique de sorte que chaque couleur représente un APK. Voici un exemple de la façon dont vous pouvez appliquer chaque APK à une certaine plage de niveaux d'API.

3 4 5 6 7 8 9 10 11 12 13 +

Une fois que vous avez créé ce graphique, distribuez-le à votre équipe. Communication d’équipe sur votre projet est immédiatement plus simple, puisqu'au lieu de demander "Comment se porte l'APK pour les niveaux d'API 3 à 6 ?", celui d'Android 1.x. Comment ça se passe ? » Dites simplement "Qu'est-ce que le fichier APK bleu sera bientôt prêt ?" en cours de route ? »

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, des thèmes de couleur, des bugs corrigés dans le code partagé), ce qui accélère le développement la probabilité d'erreurs qui auraient pu être facilement évitées.

Remarque:Bien que les détails d'implémentation concernant la création et des projets de bibliothèque sortent du cadre de cette leçon, vous pouvez vous familiariser consultez 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 aller également dans le projet 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 disposiez 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 comme référence pour chaque projet APK. Si définissez votre activité de départ dans le projet de bibliothèque et étendez cette activité dans votre APK. projet. 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 que l'APK en question 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 nous n'avons pas définir un niveau d'API maximal pour chaque APK ; Prises 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 +

Parce qu'il est nécessaire qu'un APK avec une version minSdkVersion supérieure ait également une code de version supérieur, nous savons qu'en termes de valeurs versionCode, rouge ≥ vert ≥ bleu. Par conséquent, nous pouvons réduire efficacement le graphique pour qu'il se présente comme suit:

3 4 5 6 7 8 9 10 11 12 13 +

Supposons maintenant que le fichier APK rouge présente des exigences contraires aux deux autres. Filtres sur Google Play sur la page le guide du développeur Android contient toute une liste de coupables possibles. Pour le À titre d'exemple, supposons que le rouge nécessite une caméra frontale. En fait, tout l’intérêt de L'APK rouge combine l'appareil photo avant avec une nouvelle fonctionnalité qui a été ajoutée dans l'API. 11. Mais il s'avère que tous les appareils compatibles avec l'API 11 n'ont même pas de caméra frontale ! La horreur !

Heureusement, si un utilisateur navigue sur Google Play à partir de l'un de ces appareils, Google Play examine manifeste, regardez que Red indique que la caméra frontale est une exigence et ignorez-la discrètement, a déterminé que Red et que l’appareil ne correspondait pas au paradis numérique. Il verra ensuite que Le vert n'est pas seulement rétrocompatible avec les appareils utilisant l'API 11 (puisqu'aucun maxSdkVersion n'a été défini). mais peu importe qu'il y ait ou non une caméra frontale. L'application peut toujours être téléchargée sur Google Play. En effet, malgré l'erreur de la caméra avant, APK compatible avec ce niveau d'API particulier.

Pour conserver tous vos APK sur des canaux distincts, il est important d'avoir un code de version efficace. d'un schéma. Le code recommandé est indiqué dans la zone Codes de version de consultez notre guide du développeur. Puisque l'exemple d'ensemble d'APK ne concerne qu'un des trois , il suffirait de séparer chaque APK par 1 000, de définir les deux premiers chiffres sur le minSdkVersion pour cet APK spécifique, puis incrémentez-le à partir de là. Voici un exemple:

Bleu: 03001, 03002, 03003, 03004...
Vert: 07001, 07002, 07003, 07004...
Rouge:11 001, 11 002, 11 003, 11 004...

En regroupant tous ces éléments, vos fichiers manifestes Android ressembleront probablement à ceci:

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" />
    ...

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'elles s'appliquent particulièrement à 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 le code de version est minSdkVersion le plus élevé doit être plus élevé.
  • Vérifiez que vos filtres de fichiers manifestes ne contiennent pas d'informations contradictoires (un APK compatible uniquement avec cupcake sur les écrans XLARGE ne sera visible par personne)
  • Le fichier manifeste de chaque APK doit être unique sur au moins un écran, une texture OpenGL ou une version 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 se trouve sur votre ordinateur de développement. Devenez dingue !

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: 'small' 'normal' 'large' '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 ne sera pas visible sur de nombreux 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 l'API 11 est Honeycomb (la version d'Android optimisée spécifiquement pour les tablettes) et qu'aucun appareil Honeycomb n'inclut de matériel de téléphonie, Google Play filtrera cet APK dans tous les cas, jusqu'à ce que de nouveaux appareils aient un niveau d'API supérieur ET qu'ils disposent 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, 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. Dans ce cas, effectuez une dernière vérification. Téléchargez l'application sur tous les appareils de test dont vous disposez, afin de vous assurer que les APK ciblent les appareils appropriés. Félicitations, vous avez terminé !