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 il est important d'adopter de bonnes pratiques dès le départ et d'éviter les maux de tête inutiles dans le processus de développement. Cette leçon vous explique comment créer plusieurs APK pour votre application, compatible avec un sous-ensemble différent de formats de texture OpenGL. 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 toutes les applications vous souhaitez que votre application s'affiche de manière optimale sur chaque appareil, quel que soit car elles ne sont pas toutes compatibles avec le même jeu de textures GL. Au départ, vous pouvez avoir l'impression la prise en charge de 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, y compris comment détecter les textures compatibles lors de l'exécution. Selon votre situation, il peut être plus simple de regrouper tous les formats avec votre application, et choisissez simplement celle à utiliser au moment de l'exécution.
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 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 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
Le guide du développeur Android fournit une référence pratique à certaines des textures courantes prises en charge sur la texture supports-gl-texture . Cette page contient également des indications sur les téléphones (ou familles de téléphones) pris en charge des formats de texture particuliers. Notez qu'il est généralement recommandé que l'un de vos APK soit compatible ETC1, ce format de texture étant pris en charge par tous les appareils Android compatibles avec OpenGL ES Spécifications 2.0.
Étant donné que la plupart des appareils Android prennent en charge plusieurs formats de texture, vous devez établir un ordre de préférence. Créer un graphique incluant tous les formats que votre application utilisera de l'assistance. La cellule la plus à gauche sera la priorité la plus basse (il s'agira probablement d'ETC1, une configuration par défaut fiable en termes de performances et de compatibilité). Puis colorez le graphique de manière à ce que chaque représente un APK.
| ETC1 | ATI | PowerVR |
La couleur du graphique ne se contente pas de rendre ce guide moins monochrome. Elle permet également de pour faciliter la communication au sein des équipes : vous pouvez désormais désigner chaque APK comme "bleu", "vert" ou "rouge", au lieu de "celui qui prend en charge les formats de texture ETC1", etc.
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 quelques 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.
- Si l'un des formats de texture répertoriés dans votre APK est compatible avec l'appareil sur le marché, cet appareil est considéré comme éligible
Cette dernière règle est importante pour les textures GL. Cela signifie que vous devez, pour instance, faites très attention à l'utilisation de différents formats GL dans la même application. Si vous utiliser PowerVR 99% du temps, mais ETC1 pour, par exemple, votre écran de démarrage... Ensuite, votre fichier manifeste indiquerait nécessairement la prise en charge des deux formats. Un appareil compatible uniquement avec ETC1 serait considérée comme compatible, votre application serait téléchargée et l'utilisateur verrait un plantage. messages. En général, si vous utilisez plusieurs APK spécifiquement pour cibler différents appareils en fonction de la compatibilité avec les textures GL, ce sera un format de texture par APK.
En fait, la prise en charge des textures est légèrement différente de celle des deux autres fichiers APK multiples. les dimensions, le niveau d'API et la taille de l'écran. Chaque appareil n'a qu'un seul niveau d'API et un seul écran. et c'est à l'APK de prendre en charge plusieurs d'entre eux. Avec les textures, l’APK sera généralement prennent en charge une seule texture, et l'appareil en accepte un grand nombre. Il y aura souvent des chevauchements appareil compatible avec de nombreux APK, mais la solution est la même: les codes de version.
À titre d'exemple, prenons quelques appareils et voyez combien des APK définis précédemment correspondent à chacun appareil.
| Foophone | Nexus S | Evo |
| ETC1 | ETC1 | ETC1 |
| PowerVR | ATI TC |
En supposant que les formats PowerVR et ATI sont tous deux préférés à ETC1 lorsqu’ils sont disponibles, que selon le "numéro de version le plus élevé l'emporte" si l'attribut versionCode est défini dans chaque APK de sorte que rouge ≥ vert ≥ bleu, alors le rouge et le vert seront toujours choisis à la place du bleu sur appareils qui les prennent en charge, et si jamais un appareil compatible avec le rouge et le vert arriverait, rouge est choisi.
Pour conserver tous vos APK sur des "voies" distinctes, il est important d'avoir un bon code de version d'un schéma. Le code recommandé est indiqué dans la zone "Codes de version" de notre guide du développeur. Depuis l'exemple d'ensemble d'APK ne concerne qu'une des trois dimensions possibles, il suffit d'indiquer séparez chaque APK par 1 000 et incrémentez-le à partir de là. Voici un exemple:
Bleu: 1001, 1002, 1003, 1004...
Vert: 2001, 2002, 2003, 2004...
Rouge:3001, 3002, 3003, 3004...
En rassemblant tous ces éléments, vos fichiers manifestes Android ressembleraient probablement à ceci : suivantes:
Bleu :
<manifest xmlns:android="http://schemas.android.com/apk/res/android" android:versionCode="1001" android:versionName="1.0" package="com.example.foo"> <supports-gl-texture android:name="GL_OES_compressed_ETC1_RGB8_texture" /> ...
Vert :
<manifest xmlns:android="http://schemas.android.com/apk/res/android" android:versionCode="2001" android:versionName="1.0" package="com.example.foo"> <supports-gl-texture android:name="GL_AMD_compressed_ATC_texture" /> ...
Rouge :
<manifest xmlns:android="http://schemas.android.com/apk/res/android" android:versionCode="3001" android:versionName="1.0" package="com.example.foo"> <supports-gl-texture android:name="GL_IMG_texture_compression_pvrtc" /> ...
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'il s'agit s'applique spécifiquement à plusieurs APK, et ne constitue en aucun cas une liste de contrôle complète des applications en cours d'importation 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
- 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 version 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. 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: '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 (voire tous) les appareils de très grande taille sont des tablettes dépourvues de matériel de téléphonie, Google Play filtrera cet APK dans ces cas-là, jusqu'à ce que les futurs appareils soient suffisamment grands pour être présentés comme des écrans de grande taille et soient équipés de matériel téléphonique.
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 n'importe quel appareil de test. Vous devrez peut-être vous assurer que les APK ciblent les appareils souhaités. Félicitations, vous avez terminé !