AAB — ce que c'est, différence avec l'APK et principe de fonctionnement

Qu'est-ce que l'AAB

L'AAB (Android App Bundle) est un format de publication développé par Google en remplacement de l'APK pour la distribution via Google Play. À l'intérieur de l'AAB se trouve une archive ZIP avec l'extension .aab contenant du code compilé, des ressources et des métadonnées. La différence clé « l'AAB ne s'installe pas directement sur un appareil.

Comment ça fonctionne

Le développeur télécharge l'AAB dans Google Play Console. Lorsqu'un utilisateur tente d'installer l'application, Google Play analyse la configuration de l'appareil : densité d'écran (DPI), architecture du CPU, langue et version d'Android. Sur la base de cette analyse, un APK minimal est généré, contenant uniquement les composants nécessaires.

Historique d'adoption

Google a présenté l'AAB en 2018 lors de la conférence I/O. Depuis août 2021, le format est devenu obligatoire pour toutes les nouvelles applications sur Google Play. Les applications existantes peuvent continuer à utiliser l'APK, mais les nouvelles doivent être publiées uniquement en AAB.

En quoi l'AAB diffère de l'APK

La différence entre l'AAB et l'APK est fondamentale : l'APK est un fichier d'installation complet prêt à être installé. L'AAB est un conteneur avec des composants sources nécessitant un traitement.

L'APK est adapté à la distribution en dehors de Google Play « via des sites Web, des e-mails ou des systèmes MDM d'entreprise. L'AAB est lié à l'infrastructure de Google Play et ne peut pas être installé directement. Pour tester l'AAB, l'outil bundletool est utilisé, qui émule la génération d'APK sur une machine locale.

Structure du fichier AAB

La structure interne de l'AAB est similaire à l'APK mais contient des répertoires et fichiers supplémentaires pour décrire les modules et leurs dépendances.

Module de base (base)

Le module base est un composant obligatoire de l'AAB. Il contient le code principal, les ressources et le manifeste de l'application. Sans le module de base, l'application ne peut pas être compilée. Tous les autres modules sont optionnels et sont connectés via Dynamic Delivery.

Format Protobuf

La configuration de l'AAB utilise Protocol Buffers (protobuf) au lieu du XML. Les fichiers .pb sont plus compacts et sont analysés plus rapidement par l'infrastructure serveur de Google. L'outil bundletool convertit le protobuf en un format lisible pour le débogage.

Dynamic Delivery et modules d'application

Dynamic Delivery est la technologie clé sur laquelle repose l'AAB. Elle permet de fournir à l'utilisateur uniquement les parties de l'application qui correspondent à son appareil et à sa langue, ainsi que de charger des modules supplémentaires à la demande.

Types de modules

Les modules Install-time sont chargés avec l'APK de base lors de l'installation. Les modules Conditional sont fournis uniquement lorsque des conditions sont remplies « par exemple, un module avec du contenu pour les écrans 4K. Les modules On-demand sont chargés à la demande de l'utilisateur dans l'application.

Play Asset Delivery (PAD)

Pour les ressources volumineuses (jusqu'à 2 Go), Play Asset Delivery est utilisé à la place des fichiers OBB. Le PAD prend en charge les trois mêmes modes de livraison : install-time, fast-follow (immédiatement après l'installation) et on-demand.

// Chargement de module à la demande via SplitInstallManager
val manager = SplitInstallManagerFactory
    .create(context)

val request = SplitInstallRequest
    .newBuilder()
    .addModule("level_pack_3")
    .build()

manager.startInstall(request)
    .addOnSuccessListener {
        Log.d("AAB", "Module installed")
    }

Configuration du module dans Gradle

Chaque module dynamique est décrit dans un fichier build.gradle séparé avec le type de livraison spécifié. Un module peut contenir ses propres ressources, code et manifeste, indépendants de l'application de base.

Compilation de l'AAB via Gradle

La compilation de l'AAB se fait via Android Gradle Plugin avec la tâche bundleRelease (ou bundleDebug). Le résultat est un fichier .aab dans le répertoire build/outputs/bundle/.

Configuration de compilation

Aucune configuration spéciale n'est nécessaire pour compiler l'AAB « Android Gradle Plugin prend en charge les bundles par défaut. Il suffit de spécifier la tâche bundle au lieu de assemble.

// build.gradle.kts — compilation AAB avec signature
android {
    bundle {
        language {
            enableSplit = true
        }
        density {
            enableSplit = true
        }
        abi {
            enableSplit = true
        }
    }
}
// Tâche : ./gradlew bundleRelease

Test local via bundletool

Google fournit l'outil bundletool pour générer des APK à partir de l'AAB sur une machine locale. La commande `bundletool build-apks --bundle=app.aab --output=app.apks` crée un ensemble d'APK pour les tests sur différentes configurations d'appareils.

bundletool peut également décompresser l'AAB, afficher sa configuration et vérifier l'intégrité de la signature avant le téléchargement dans Google Play Console. Pour le débogage, la commande `bundletool dump manifest --bundle=app.aab` est utilisée pour afficher le manifeste du module de base.

Configuration des splits dans l'AAB

Par défaut, l'AAB divise les ressources selon trois dimensions : la langue, la densité d'écran (density) et l'architecture du CPU (abi). Le développeur peut désactiver toute division dans build.gradle « par exemple, si l'application ne prend en charge que l'anglais. Désactiver une division signifie que les ressources pour toutes les variantes seront incluses dans l'APK de base.

Optimisation des ressources « l'AAB convertit automatiquement le PNG en WebP sans perte de qualité, compresse les ressources inutilisées et supprime les chaînes en double. Ces optimisations sont appliquées côté Google Play lors de la génération de l'APK final. En conséquence, l'utilisateur reçoit un APK 15 à 25 % plus petit que l'archive complète.

Publication de l'AAB sur Google Play

Le processus de publication de l'AAB dans Google Play Console ne diffère de l'APK que par le format du fichier téléchargé. La console accepte le .aab, vérifie sa structure, sa signature et la configuration des modules, puis génère des APK pour chaque type d'appareil.

App Signing by Google Play

Lors du téléchargement de l'AAB, Google Play prend en charge la gestion des clés de signature. Le développeur télécharge un paquet signé avec une clé upload, et Google re-signe les APK générés avec sa propre clé. Cela simplifie la rotation des clés et la récupération d'accès en cas de perte du keystore.

Tests avant la publication

Google Play Console fournit un test AAB intégré : vous pouvez télécharger l'APK généré pour un appareil spécifique ou exécuter des tests internes via les tracks Internal Testing, Closed Alpha et Open Beta.

Problèmes courants avec l'AAB et solutions

La migration vers l'AAB peut causer des problèmes, en particulier dans les projets comportant de nombreux modules dynamiques ou une configuration de ressources complexe.

Erreurs de configuration des modules

Si un module dynamique fait référence aux ressources du module de base avec un nom incorrect, Google Play rejette l'AAB lors de la vérification. Solution « utilisez la vérification lint avant la compilation et testez tous les modules via bundletool localement.

Divisions linguistiques et impact sur les performances

La division par langue peut ralentir le démarrage de l'application si les ressources pour la locale actuelle sont chargées dynamiquement. La recommandation de Google est de ne pas diviser les langues si elles sont moins de 10, ou d'utiliser install-time pour les plus populaires.

Compatibilité avec les SDK tiers

Certains SDK (analytique, publicité, cartes) nécessitent un accès au manifeste complet et aux ressources. La vérification de la compatibilité avec l'AAB est une étape obligatoire avant la migration. La plupart des grands SDK (Firebase, Google Ads, Crashlytics) prennent en charge l'AAB depuis 2022. Pour vérifier la compatibilité, on utilise bundletool avec le drapeau --validate, qui émule la génération d'APK côté serveur.

Versionnement de l'AAB

L'AAB utilise le versionCode du manifeste du module de base. Contrairement à l'APK, l'AAB prend également en charge un versionCode distinct pour chaque module « cela permet de mettre à jour des parties individuelles de l'application sans réinstallation complète. Dynamic Delivery suit les modules installés et ne fournit que les composants modifiés lors des mises à jour via Google Play.

Surveillance et analyse de l'AAB

Google Play Console fournit des analyses détaillées pour chaque AAB : combien d'APK ont été générés, quels splits ont été demandés, quelle est la taille moyenne de téléchargement par appareil. Android Vitals affiche les métriques de performance des APK générés. Ces données aident à optimiser la configuration des splits et à réduire la taille de téléchargement pour différentes catégories d'appareils.