APK, AAB, XAPK, OBB — tout comprendre sur les formats Android

بسم الله الرحمن الرحيم

Introduction

APK, XAPK, AAB, OBB… A la base tu voulais juste télécharger une app et on te balance tout ça ! Et au fond, c’est quoi tout ça ? Des fichiers exécutables ? Des installateurs ? Des formats de distribution ?

C’est ce qu’on va voir dans cet article !

Définition d’un apk

APK signifie Android Package Kit. C’est le format de fichier utilisé par Android pour distribuer et installer les applications.

Un APK n’est en réalité rien d’autre qu’une archive ZIP renomée et voici un exemple pour le prouver :

Anatomie d’un APK

Alors il y’a quoi à l’intérieur de cet APK ?

La structure typique d’un APK est :

• AndroidManifest.xml : XML binaire compilé (AXML)
• classes.dex : Bytecode Dalvik (code de l’app)
• classes2.dex : si multidex
• resources.arsc : table des ressources compilées
• res/ : ressources structurées (layouts, drawables…)
• assets/ : fichiers bruts lus tels quels
• lib/ : bibliothèques natives .so par architecture
• META-INF/ : signatures cryptographiques
• kotlin/ : métadonnées Kotlin (si app Kotlin)

On va essayer d’expliquer chaque élément de manière plus ou moins détaillée.

AndroidManifest.xml

C’est l’un des fichiers les plus importants et centraux de l’application, c’est un peu comme la carte d’identité de l’application :

• le nom du package (com.exemple.monapp)
• la version (versionCode, versionName)
• les permissions demandées (INTERNET, CAMERA, etc.)
• les composants : activities, services, broadcast receivers, content providers
• la minSdkVersion et la targetSdkVersion
• les intent-filters

Ce fichier n’est pas du XML texte mais du XML binaire compilé (AXML), il faudra passer par aapt2 dump xmltree ou apktool pour le rendre lisible.

classes.dex

C’est le code compilé de l’application au format DEX (Dalvik EXecutable), exécutable par ART (Android Runtime). Si vous voyez plusieurs fichiers .dex, c’est parce que l’application utilise le multidex. En gros, un seul fichier DEX est limité à 65 536 méthodes référencées et donc au-delà il faudra splitter en plusieurs fichiers DEX.

resources.arsc

C’est une table binaire qui mappe chaque identifiant de ressource (R.string.app_name, R.color.primary…) vers sa valeur réelle, en fonction de la configuration (langue, densité d’écran, mode sombre…). C’est ce qui permet à Android de choisir automatiquement la bonne ressource au runtime.

res/

Contient les ressources structurées : layouts XML, drawables, couleurs, chaînes traduites, dimensions, styles, etc. Le contenu est partiellement compilé (les XML sont en binaire, les PNG/JPG restent tels quels).

assets/

Contient les fichiers bruts que l’application embarque et qu’elle lira via AssetManager. Contrairement à res/, rien n’est compilé ni indexé ici. C’‘est juste un dossier de fichiers libres (polices, JSON de config, modèles ML, etc.).

lib/

Contient les bibliothèques natives (fichiers .so) compilées via le NDK, organisées par architecture CPU :

• arm64-v8a : ARM 64 bits (la majorité des téléphones récents)
• armeabi-v7a : ARM 32 bits (téléphones plus anciens)
• x86_64 : émulateurs et quelques tablettes
• x86 : rare

META-INF/

Contient la signature cryptographique et le certificat du développeur. C’est ce qui garantit l’authenticité et l’intégrité de l’APK (on y reviendra).`

Comment passe-t-on du code à un APK ?

On va décrire étape par étape pour comprendre comment on passe du java/kotlin à un APK

Compilation des sources On commencer par compiler les sources donc javac pour Java ou kotlinc pour Kotlin transforment le code en bytecode JVM (le fameux .class)

Compilation des ressources Après avoir compiler les sources, on compile les ressources avec AAPT2 (Android Asset Packaging Tool2 ) :

• il compile les XML en binaire
• il génère le fichier R.java qui contient tous les identifiants de ressources
• il produit resources.arsc

R8 : dexing (et plus si configuré) Le bytecode JVM (.class) est converti en .dex par D8, embarqué dans R8 (qui a remplacé ProGuard + D8 depuis 2018). Par défaut, R8 ne fait que ce dexing.

Si on active minifyEnabled true dans le build.gradle, R8 fait aussi du shrinking (suppression du code mort), de l’opti et de l’obfuscation (renommage par des lettres a, b, c…). C’est ce qui rend les APK release minifiés beaucoup plus légers.

4- Packaging Tous les éléments (classes.dex, resources.arsc, res/, assets/, lib/, AndroidManifest.xml) sont assemblés dans une archive ZIP : c’est l’APK, mais pas encore signé.

5. zipalign Cet outil aligne les fichiers de l’archive sur des frontières de 4 octets. Ça permet à Android de mapper directement les ressources en mémoire (mmap) sans recopier, donc des perfs et une RAM économisées au runtime.

6. Signature Toute application Android doit être signée avant d’être installée, même un APK debug. On utilise apksigner.

Il existe plusieurs schémas de signature, vous pouvez vous renseigner sur internet dont certains vulnérables

Le rôle de Gradle et de l’AGP

Heureusement que ce pipeline est géré par le Gradle configuré via les fichiers build.gradle (ou build.gradle.kts en Kotlin) et plus précisément l’AGP (Android Gradle Plugin) donc qui appelle aapt2, R8, zipalign, apksigner dans le bon ordre gère les dépendances externes , gère le téléchargement des SDK et NDK et expose les variants de build.

Les Différents Formats

XAPK (non officiel)

Si tu télécharges depuis APKPure ou APKCombo tu tomberas parfois sur des fichiers .xapk.

Ce format non officiel a été créé par APKPure pour contourner une limitation historique du Play Store : un APK seul ne peut pas dépasser 100 Mo

D’où l’introduction des OBB (Opaque Binary Blob) par Google — des fichiers de données séparés stockés dans /Android/obb/, aujourd’hui largement obsolètes au profit du Play Asset Delivery.

À l’origine, le .xapk regroupe tout (APK principal + OBB + métadonnées) dans une seule archive. Mais aujourd’hui, il a été étendu pour packager des Split APKs et c’est ce que vous verrez le plus souvent.

J’ai téléchargé Waze et Brawl Stars via APKPure, on voit bien le split APKs adapté à l’ABI avec beaucoup de langue et le fameux install_time_asset qu’on verra juste après :

Pour l’installer, vous pouvez utiliser l’installateur d’APKPURE ou dezippe et installer avec la commande adb install-mutiple

Android App Bundle (AAB) — Le format officiel

C’est le format officiel introduit par Google en 2018, et obligatoire sur le Play Store depuis août 2021 pour toute nouvelle application et pour toutes les mises à jour depuis novembre 2021.

Important : un AAB n’est pas un format d’installation, c’est un format de distribution. En gros, c’est ce que le dev envoie au Play Store et Google se charge de générer les APK finaux livrés à l’utilisateur.

Ce qui est cool avec l’AAB, c’est qu’au lieu d’embarquer toutes les densités d’écran, toutes les libs natives pour chaque architecture CPU, toutes les langues etc. comme un APK classique.

Il se charge de livrer des APK sur mesure en fonction de la densité de l’écran, de l’ABI, de la langue etc. Ça allège littéralement l’app et on parle de Split APKs.

Exemple pour comparer avec l’xapk, mais cette fois-ci téléchargé depuis le Google Play Store :

Comme on peut le voir, on a notre base.apk où se trouve la logique de notre app, et on voit bien qu’il a téléchargé les APK adaptés à mon ABI, aux 2 langues liées à mon clavier (je crois), à la densité d’écran xxhdpi et enfin le fameux install_time_asset_pack.apk qui a remplacé l’OBB.

Cool à savoir aussi : le dev garde une clé d’upload pour envoyer son AAB au Play Store, mais c’est Google qui signe les APK finaux distribués à l’utilisateur.

L’ABB a également introduit les modules de fonctionnalités dynamiques. Au lieu d’embarquer toute l’app à l’installation, certaines fonctionnalités peuvent être téléchargées à la demande comme par exemple des fonctionnalités VIP accessible à partir d’un certain niveau.

Play Asset Delivery (PAD) — l’héritier des OBB

Depuis l’obligation de l’AAB, les OBB comme expliqué précédemment ont été abandonnés pour les nouvelles apps.

À la place, Google propose Play Asset Delivery (PAD) pour gérer les gros assets (jeux, textures, sons…).

L’idée est simple : plutôt que de tout embarquer dans un seul fichier OBB de 2 Go ,le développeur choisit le mode de livraison parmi trois options : install-time, fast-follow, ou on-demand.

Mode	Quand ?	Taille max
install-time	Téléchargé avec l’app, disponible dès le premier lancement (on l’a vu avec Brawl Star)	1 Go par pack
fast-follow	Téléchargé automatiquement juste après l’install, sans ouvrir l’app	512 Mo par pack
on-demand	Téléchargé uniquement quand l’app le demande au runtime (ex: nouveau niveau débloqué)	512 Mo par pack

Important : Il faut faire la différence avec le Dynamic Feature Module ce qu’on a vu haut qui est du code téléchargeable à la demande et Play Asset Delivery qui est des ASSETS téléchargeables à la demande

Comment Android lit tout cela ?

Android utilise un mécanisme appelé SplitCompat (intégré à AndroidX). Quand l’app démarre, le framework :

1. Charge base.apk en premier
2. Détecte et charge automatiquement les split_config.*.apk présents
3. Les fusionne logiquement → pour l’app, c’est totalement transparent, elle a accès à tout comme s’il n’y avait qu’un seul APK

Ce n’est pas forcément utile mais si tu as un AAB et tu veux l’installer ou avoir les split APKs un AAB directement mais Google fournit bundletool qui simule ce que ferait le Play Store et te génère les Split APKs

الحمد لله