APK vs AAB : le nouveau format de distribution Android expliqué
Ce qu'est vraiment un APK (et pourquoi il a régné sur Android pendant 15 ans)
Pendant 15 ans, l'Android Package Kit — l'APK — était la seule option. C'est le standard pour les applications Android depuis le lancement de la plateforme en 2008. Un APK n'est en fait qu'une archive ZIP avec une structure interne très spécifique : il contient le fichier AndroidManifest.xml compilé, le bytecode DEX (classes.dex), une table resources.arsc, et des dossiers pour les assets, les bibliothèques natives et d'autres ressources brutes. Quand tu récupères une application sur un site web ou que tu l'envoies à un ami par Bluetooth, tu envoies un unique fichier .apk qui contient tout le nécessaire pour fonctionner sur n'importe quel appareil Android. Cette approche universelle est à la fois la plus grande force de l'APK et son plus grand défaut. Un seul APK du Google Play Store doit tout prendre en charge, d'un Samsung Galaxy S25 Ultra avec une puce ARM 64 bits à un téléphone Tecno d'entrée de gamme avec une puce ARM 32 bits, en plus des Chromebooks sur processeurs x86 et de toutes les densités d'écran imaginables. Pour ce faire, les développeurs devaient empaqueter chaque version de chaque bibliothèque native, chaîne de caractères traduite et image pour chaque densité d'écran dans un seul et même énorme package. Le résultat ? Des applications comme Google Maps livraient des APK de 100 Mo alors que ton appareil n'avait besoin que d'environ 40 Mo de tout ça. Le reste n'était que du poids mort : téléchargé et stocké, mais jamais utilisé.
Android App Bundle : ce qui a changé en 2018 et pourquoi Google l'a rendu obligatoire
Google a finalement attaqué le problème de surpoids de l'APK lors de la Google I/O 2018 avec l'Android App Bundle (AAB), le rendant obligatoire pour les nouvelles applications du Play Store en août 2021. Bien qu'il ait une extension .aab et soit aussi une archive ZIP, ce n'est pas une application installable. Imagine-le comme une recette et une boîte d'ingrédients, pas comme le gâteau fini. Un AAB contient le code compilé et les ressources dans des modules, mais ce sont les serveurs de Google Play qui réalisent l'assemblage final. Ce processus s'appelle la Dynamic Delivery. Lorsqu'un utilisateur clique sur « Installer » dans le Play Store, les serveurs de Google examinent son appareil spécifique : son architecture de processeur (ABI), sa densité d'écran et ses paramètres de langue. Ensuite, ils construisent et servent un ensemble personnalisé d'APK découpés (split APKs) ne contenant que ce dont cet appareil précis a besoin. Un Pixel 9 sous Android 15 en anglais pourrait recevoir un téléchargement de 38 Mo, alors que l'ancien APK monolithique aurait pesé un bon 95 Mo. La réduction de taille n'est pas théorique ; elle est significative et mesurable. Les propres données de Google de 2021 montraient une réduction de taille moyenne de 15 % pour les applications passées à l'AAB, certaines réduisant leur taille de plus de 50 %. Pour un jeu avec d'énormes atlas de textures conçus pour différents formats de compression GPU (comme ETC2, ASTC et S3TC), les économies peuvent être astronomiques, supprimant facilement des centaines de mégaoctets de l'installation finale sur le téléphone de l'utilisateur.
La structure interne d'un fichier AAB
Si tu ouvres un AAB avec un utilitaire ZIP, tu verras immédiatement que ce n'est pas un APK. Au premier niveau, on trouve un fichier BundleConfig.pb, qui définit la configuration du bundle, un répertoire BUNDLE-METADATA et au moins un répertoire de module. Le module principal s'appelle toujours `base/`, et il ressemble un peu à un APK à l'intérieur, avec des dossiers `dex/`, `manifest/`, `res/`, `root/` et `lib/`. Mais il y a une différence cruciale : les ressources sont stockées dans un format proto `resources.pb`, et non dans le format binaire plat `resources.arsc` d'un APK. C'est une raison clé pour laquelle un AAB ne peut pas être installé directement. D'autres modules de fonctionnalités apparaissent à côté du module `base/`, avec des noms comme `onboarding/` ou `ar_features/`. Chacun a son propre manifeste et ses propres ressources et peut être configuré pour être téléchargé au moment de l'installation, juste après l'installation (fast-follow), ou seulement en cas de besoin. C'est grâce à ce modèle à la demande qu'une application comme Google Earth peut éviter d'imposer à chaque utilisateur des données de villes en 3D, en ne les récupérant via la bibliothèque Play Core que lorsque quelqu'un essaie réellement de visualiser une ville avec cette couverture. Le répertoire `lib/` à l'intérieur de chaque module est là où la vraie magie opère pour les économies de taille. Un jeu multiplateforme pourrait avoir des sous-répertoires `arm64-v8a`, `armeabi-v7a` et `x86_64`, chacun rempli de bibliothèques .so compilées. Un APK monolithique les inclurait tous. Avec un AAB, la Dynamic Delivery garantit que seul le répertoire ABI correspondant est envoyé. Pour un jeu avec 80 Mo de code natif par ABI, c'est une économie instantanée de 160 Mo sur un téléphone 64 bits moderne qui n'a aucune utilité pour les bibliothèques 32 bits ou x86.
APK vs AAB : une comparaison directe de ce qui compte pour les développeurs
Alors, que signifient ces différences en pratique pour les développeurs, l'assurance qualité (QA) et les utilisateurs ? Décortiquons la comparaison en fonction de ce qui compte vraiment dans ton travail quotidien. **Support des canaux de distribution :** Google Play exige des AAB pour les nouvelles applications. C'est aussi simple que ça. Cependant, les AAB sont une technologie propre à Google. Les magasins d'applications Android alternatifs comme l'Amazon Appstore, le Samsung Galaxy Store, la Huawei AppGallery et F-Droid exigent tous les bons vieux APK. Si tu distribues ton application en dehors de Google Play, tu dois toujours gérer des APK. Ce n'est pas un détail mineur, surtout sur les marchés où Google Play n'est pas disponible et où la distribution par APK est la norme. **Installation directe :** Tu ne peux pas installer un AAB en sideloading. Essayer d'en installer un avec `adb install app.aab` te donnera simplement une erreur. Pour tester un AAB localement, tu dois utiliser l'outil `bundletool` de Google pour générer un ensemble d'APK locaux ou utiliser l'option `--local-testing` dans ton build. Quiconque a déjà essayé de faire tester un build par un interlocuteur non technique sait que l'ajout d'étapes supplémentaires est la recette parfaite pour la frustration. Cela ajoute clairement de la friction aux processus de QA. **Outils de build :** Dans Android Studio, tu crées un AAB avec Build > Generate Signed Bundle/APK > Android App Bundle, ou avec la tâche `./gradlew bundleRelease`. Tu construis un APK avec `./gradlew assembleRelease`. La plupart des équipes utilisent les deux, construisant des APK pour les tests internes et des AAB pour l'envoi final sur le Play Store. **Taille du fichier sur le disque :** Voici un point qui prête souvent à confusion : ton fichier AAB sera presque toujours plus volumineux que ton APK. Un APK de 60 Mo peut générer un AAB de 80 Mo car l'AAB contient les ressources pour *toutes* les configurations d'appareils. Les économies de taille n'apparaissent que sur l'appareil de l'utilisateur, une fois que Google Play a fait sa magie. **Modèle de sécurité :** Les deux formats sont signés, mais le processus diffère. Avec les AAB, tu dois utiliser la signature d'application Play. Cela signifie que tu envoies ton bundle et que Google re-signe les APK découpés finaux qu'il génère avec une clé qu'il gère. Bien que tu enregistres cette clé, c'est Google qui la détient au final, un fait qui rend nerveuses certaines équipes soucieuses de la sécurité. Avec les APK, tu peux contrôler l'ensemble du processus de signature avec tes propres clés, sans aucune intervention de Google.
Convertir entre APK et AAB : ce qui est possible et ce qui ne l'est pas
C'est là que des réponses honnêtes comptent plus que des promesses marketing. Soyons clairs : reconvertir un APK existant en AAB n'est pas quelque chose de réaliste, et tu devrais être extrêmement sceptique envers tout outil qui prétend pouvoir le faire automatiquement. Le problème est fondamental. Un AAB a besoin des informations sources originales : les fichiers de ressources soigneusement organisés par densité d'écran et par langue, la table de ressources au format proto, la structure des modules. Toutes ces données sont compilées, aplaties et optimisées jusqu'à disparaître lors de la création d'un APK. Le fichier `resources.arsc` dans un APK est un blob binaire ; la structure de dossiers originale `res/drawable-hdpi/` a disparu. Essayer de reconstruire cela à partir d'un APK compilé n'est pas une conversion ; c'est un processus douloureux de rétro-ingénierie, et les résultats sont presque toujours incomplets. CocoConvert est conçu pour les opérations d'APK à APK. Tu peux l'utiliser pour reconditionner, renommer et, surtout, extraire le contenu des fichiers APK pour inspection. Envoie un APK, et tu pourras en extraire son manifeste, voir sa table de ressources ou récupérer des assets spécifiques. Mais ce que CocoConvert ne peut pas faire, c'est générer un AAB valide et prêt pour le Play Store à partir d'un APK. Franchement, aucun outil ne peut le faire de manière fiable si tu n'as pas le projet de code source original. Si tu as perdu tes sources et que tu n'as qu'un APK, ta meilleure option est un outil comme `apktool`. Il peut décompiler le package en bytecode smali et te donner une approximation des ressources, mais transformer cela en un projet correct qui peut être compilé en AAB nécessite une quantité énorme de travail manuel. Là où CocoConvert *est* vraiment utile, c'est pour les tâches qui reviennent tout le temps en QA mobile et en recherche de sécurité. Tu peux convertir des APK en fichiers ZIP pour parcourir leur contenu, extraire des images ou des fichiers audio spécifiques, et même traiter par lots tout un dossier d'APK pour les auditer. Ce sont les tâches concrètes et réelles pour lesquelles nous pouvons t'aider.
Le problème du sideloading et pourquoi l'APK n'est pas près de disparaître
Malgré la forte incitation de Google en faveur de l'AAB, l'humble APK n'est pas près de disparaître. Sa pérennité vient de tous les cas d'usage qui existent complètement en dehors du contrôle de Google. Le sideloading — installer un APK depuis l'extérieur du Play Store — est une fonctionnalité essentielle d'Android, activée par un petit tour dans les paramètres de ton téléphone (généralement sous Paramètres > Applications > Accès spécial des applis > Installer applis inconnues, bien que le chemin varie). Et l'écosystème du sideloading est immense. APKMirror héberge des APK vérifiés d'applications du Play Store, permettant aux utilisateurs d'obtenir des mises à jour avant qu'un déploiement progressif ne les atteigne ou d'installer des versions plus anciennes. Les outils de gestion des appareils mobiles d'entreprise (MDM) de VMware et Microsoft déploient des APK sur des milliers d'appareils d'entreprise sans jamais passer par le Play Store. Les communautés de modding de jeux vivent et respirent grâce aux APK modifiés. Pour les développeurs dans les régions où l'accès au Play Store est limité, le partage d'APK est la principale méthode de distribution. Pour n'importe lequel de ces utilisateurs, l'AAB est tout simplement hors de propos. C'est un format qui vit et meurt à l'intérieur du jardin clos de Google. Dès qu'une application doit être partagée, déployée ou installée en dehors de cet écosystème, elle doit être un APK. Cela devient encore plus pertinent avec les nouvelles réglementations. Le Digital Markets Act de l'UE force Apple et Google à s'ouvrir aux magasins d'applications alternatifs. À mesure que les marketplaces Android tierces gagneront du terrain en Europe, elles auront besoin d'un format universel pour les soumissions. Comme elles ne peuvent pas utiliser l'infrastructure propriétaire de Dynamic Delivery de Google, ce format sera l'APK. Ironiquement, cela pourrait conduire à une résurgence de l'importance de l'APK sur certains des plus grands marchés mondiaux, alors même que Google mise encore plus sur l'AAB pour son propre magasin.
Recommandations pratiques en fonction de ta situation
Alors, allons droit au but. Le bon format dépend entièrement de ce que tu essaies de faire. Voici un guide pragmatique basé sur ton rôle. **Si tu publies une nouvelle application sur Google Play :** Tu n'as pas le choix. Tu dois soumettre un AAB pour toute nouvelle application depuis août 2021. Configure la signature d'application Play dans la Play Console (Configuration > Intégrité de l'application), configure ta configuration de signature Gradle et exécute `./gradlew bundleRelease`. Assure-toi de le tester localement avec `bundletool build-apks --bundle=app.aab --output=app.apks --local-testing` suivi de `bundletool install-apks --apks=app.apks`. **Si tu distribues à des appareils d'entreprise via MDM :** Reste avec les APK. Construis-en un avec `./gradlew assembleRelease`. Ta solution MDM pousse l'APK directement sur les appareils. Utiliser un AAB ici n'apporte aucune valeur ajoutée et ne fait que compliquer les choses. **Si tu distribues sur des magasins d'applications alternatifs :** Construis des APK. L'Amazon Appstore, par exemple, a son propre portail développeur pour les envois d'APK et sa propre logique de ciblage d'appareils. Ils n'utilisent pas le système de Google. **Si tu es un ingénieur QA testant un build :** Utilise des APK pour tes smoke tests quotidiens et tes tests de régression ; ils sont rapides et s'installent directement avec `adb install`. Pour la validation finale avant la sortie, tu devrais construire un AAB et utiliser `bundletool` pour t'assurer que tu testes ce que les utilisateurs recevront réellement du Play Store. **Si tu as besoin d'inspecter un APK que tu as reçu :** Tu peux l'envoyer sur CocoConvert pour en extraire rapidement le contenu, ou utiliser l'APK Analyzer d'Android Studio (Build > Analyze APK). L'analyseur offre une excellente décomposition visuelle de la taille des fichiers et est parfait pour comparer deux builds différents afin de voir ce qui a changé. En fin de compte, le débat APK vs AAB ne porte pas sur le format techniquement supérieur dans l'absolu. C'est une question de logistique. Le bon choix est déterminé par ton canal de distribution et tes outils. Les deux formats sont là pour durer, servant des chemins différents dans l'écosystème tentaculaire d'Android.