Build Variant — qu’est-ce qu’un build type et un product flavor dans Android

Qu’est-ce qu’un Build Variant ?

Build Variant est le résultat de la combinaison d’un Build Type et d’un Product Flavor. Si aucun Product Flavor n’est défini dans le projet, le Build Variant correspond au Build Type. Gradle génère automatiquement l’ensemble complet des variantes comme le produit cartésien de tous les FlavorDimensions, Product Flavors et Build Types. Par exemple, pour les flavors free/paid et les types debug/release, 4 variantes seront créées : freeDebug, freeRelease, paidDebug, paidRelease.

Chaque Build Variant reçoit son propre nom au format <Flavor><Type> avec le flavor en majuscule. Gradle génère des tâches séparées pour cette variante : assembleFreeDebug, installFreeDebug, bundleFreeRelease. Dans Android Studio, le basculement entre les variantes est disponible via le panneau Build Variants (View → Tool Windows → Build Variants). La sélection d’une variante affecte quel code est compilé, quelles ressources sont incluses et quel APK/AAB est produit.

Le système de Build Variants résoudre trois tâches principales : séparer les configurations pour différents environnements (dev/staging/production), créer plusieurs versions d’une application (free/paid) et tester A/B des compilations. Sans Build Variants, les développeurs devraient basculer manuellement les drapeaux et configurations, ce qui entraîne des erreurs humaines. Selon une étude de Gradle Inc., 2024, l’implémentation de Build Variants réduit les erreurs de compilation de 60% dans les projets avec trois environnements de déploiement ou plus.

Comment Gradle génère les variantes

AGP (Android Gradle Plugin) calcule toutes les combinaisons lors de la phase de configuration. Si un projet a deux dimensions avec respectivement deux et trois flavors, Gradle créera 2 × 2 × 3 = 12 combinaisons, multipliées par le nombre de Build Types (généralement 2). Chaque combinaison reçoit un nom unique et un ensemble de tâches. AGP ajoute automatiquement un source set pour chaque variante : src/freeDebug/, src/paidRelease/, ainsi que les généralisés src/free/ et src/debug/. Priorité de lecture des ressources : variant → flavor → type → main.

// Exemple : 4 Build Variants
// flavorDimensions "version", "server"
// version: demo, prod
// server: mock, live
// buildTypes: debug, release
// Total : 2 × 2 × 2 = 8 variantes

android {
    flavorDimensions "version", "server"

    productFlavors {
        demo { dimension "version" }
        prod { dimension "version" }
        mock { dimension "server" }
        live { dimension "server" }
    }
}

Build Type et Product Flavor : Différences

Build Type définit comment compiler l’application — avec ou sans informations de débogage, avec ou sans optimisation, avec quelle signature. Product Flavor définit quoi compiler — quelle version du produit. Build Type est un mécanisme de compilation (debug, release, staging). Product Flavor est une variante de produit (free, paid, enterprise, demo). Les deux concepts sont orthogonaux : tout Build Type peut être appliqué à tout Product Flavor.

Les Build Types par défaut incluent debug (debuggable=true, minification=false, signing=debug.keystore) et release (debuggable=false, minification=true, signing=production.keystore). Le Product Flavor par défaut est un, sans nom (effectivement le source set main). Les développeurs peuvent ajouter leurs propres Build Types (par exemple, « staging » avec debuggable=true et minification=true) et n’importe quel nombre de Product Flavors. Une autre différence est que les Build Types ne peuvent pas être regroupés en dimensions, mais les Product Flavors le peuvent.

La différence pratique clé : defaultConfig dans build.gradle s’applique à tous les Variants mais peut être remplacé dans productFlavors et buildTypes. Un BuildConfigField ajouté à un buildType est visible dans tous les flavors de ce type, tandis qu’un ajouté à un productFlavor est visible dans tous les types de ce flavor. Si un champ est défini dans les deux, buildType a la priorité (il est appliqué en dernier dans la chaîne).

Tableau Comparatif

Configuration des Build Variants dans build.gradle

Priorité de Configuration

La configuration des Build Variants se fait dans le bloc android du fichier build.gradle au niveau du module. D’abord, les buildTypes sont déclarés avec leurs paramètres, puis flavorDimensions et productFlavors. Gradle crée automatiquement les variantes sur la base de ces déclarations. Chaque variante hérite du defaultConfig du module, en remplaçant les champs spécifiés. L’ordre de déclaration affecte la priorité : les buildTypes sont appliqués après les productFlavors.

Pour accéder à un Build Variant spécifique dans les scripts Gradle, utilisez android.applicationVariants (pour les modules d’application) ou android.libraryVariants (pour les modules de bibliothèque). Il s’agit d’une collection qui peut être parcourue pour modifier la configuration de chaque variante au moment de l’exécution de la configuration. Par exemple, vous pouvez ajouter programmatiquement buildConfigField pour toutes les variantes contenant le mot « demo ».

Android Gradle Plugin 8.x a ajouté la prise en charge de onVariants — une API plus propre pour configurer les variantes via des lambdas. L’ancienne API (variantOutput, variantFilter) est marquée comme obsolète. Il est recommandé d’utiliser onVariants avec onEach pour les modules de bibliothèque. La migration de variantOutput vers onVariants est une étape recommandée lors de la mise à niveau d’AGP de 7.x vers 8.x.

android {
    buildTypes {
        debug {
            debuggable true
            minification false
            signingConfig signingConfigs.debug
        }
        release {
            debuggable false
            minification true
            proguardFiles "proguard-rules.pro"
            signingConfig signingConfigs.release
        }
        staging {
            debuggable true
            minification true
            versionNameSuffix "-staging"
        }
    }

    flavorDimensions "tier", "region"

    productFlavors {
        free { dimension "tier" }
        paid { dimension "tier" }
        us { dimension "region" }
        eu { dimension "region" }
    }
}

android.onVariants { variant ->
    if (variant.name.contains("Demo")) {
        variant.setEnabled(false)
    }
}

Source Sets et Remplacement de Ressources

Chaque Build Variant reçoit sa propre hiérarchie de source sets — des répertoires avec code source, ressources et manifeste. Un source set se trouve dans src/<variantName>/ (par exemple, src/freeDebug/) et peut contenir java/, res/, AndroidManifest.xml, assets/. Si un fichier existe dans le source set de la variante, il remplace le fichier du même nom provenant du source set principal (src/main/). Pour les ressources, une fusion a lieu plutôt qu’un remplacement — le système fusionne les ressources de tous les source sets actifs, en donnant la priorité à celles spécifiques à la variante.

Les source sets pour un Build Variant sont construits en chaîne : src/main/ → src/flavor/ → src/type/ → src/flavorType/. Par exemple, pour paidRelease, main est appliqué d’abord, puis paid, puis release, puis paidRelease. Chaque source set suivant remplace le précédent. Cela signifie que src/release/res/values/strings.xml remplacera les mêmes chaînes de src/paid/, mais src/paidRelease/res/ a une priorité encore plus élevée.

Utiliser des source sets pour les variantes est la méthode recommandée pour personnaliser les ressources. Au lieu de vérifier BuildConfig.FLAVOR dans le code et de bifurquer la logique, vous pouvez simplement placer différents fichiers dans différents source sets. Par exemple, les icônes pour les versions free et paid vont dans src/free/res/ et src/paid/res/ respectivement, et l’AndroidManifest avec différentes autorisations va dans src/free/AndroidManifest.xml et src/paid/AndroidManifest.xml. C’est plus propre, plus rapide (les ressources sont compilées, pas vérifiées à l’exécution) et plus sûr (vous ne pouvez pas inclure accidentellement des fonctionnalités payantes dans la version gratuite à cause d’un bug dans le code).

Build Variant dans les Projets Multimodules

Dans les projets multimodules, chaque module (bibliothèque) peut avoir ses propres Build Variants. AGP synchronise automatiquement les variantes : si le module application compile paidRelease, toutes les bibliothèques dépendantes sont également compilées dans leurs variantes correspondant à paidRelease. Un problème survient lorsqu’une bibliothèque n’a pas de product flavors mais que le module application en a — alors la bibliothèque est compilée une fois (release ou debug selon le type).

Pour les modules de bibliothèque, le Build Variant correspond par défaut au Build Type du module application, car les bibliothèques n’ont pas de product flavors. Si une bibliothèque doit s’adapter au flavor du module application, les mêmes flavorDimensions et productFlavors doivent être déclarés dans la bibliothèque. AGP fait correspondre les flavors par correspondance exacte de nom. Gradle recommande de synchroniser les flavors via la configuration de compilation dans le projet racine en utilisant subprojects ou Convention Plugins.

À partir d’AGP 8.1, les bibliothèques peuvent publier plusieurs variantes — publier toutes les variantes de la bibliothèque dans un dépôt maven simultanément. Cela résout le problème lorsque le module application utilise un flavor payant mais que la bibliothèque n’est publiée que pour free. La publication de plusieurs variantes (MVP) permet au projet dépendant de sélectionner automatiquement la variante requise. Pour activer MVP, ajoutez publishing { multipleVariants { ... } } au build.gradle de la bibliothèque.

Filtrage et Désactivation des Variantes

Filtrage Dynamique via CI/CD

Il est parfois nécessaire de désactiver certains Build Variants — par exemple, si la combinaison mockRelease n’a pas de sens (le serveur mock ne devrait pas aller en production). Gradle fournit variantFilter — un bloc DSL où vous pouvez vérifier les propriétés de chaque variante et la désactiver via setIgnore(true). VariantFilter est appliqué à la phase de configuration, avant la création des tâches, donc une variante désactivée ne génère pas de tâches assemble et install.

Le filtrage est également utile pour accélérer les compilations. Si un projet a 8 variantes mais qu’un développeur travaille sur une seule, les 7 variantes restantes passent quand même par la configuration. En utilisant variantFilter, les variantes désactivées ne créent pas de tâches, ce qui réduit le temps de configuration de 30-50% pour les projets avec 6+ dimensions de flavor. En CI/CD, vous pouvez filtrer dynamiquement les variantes via des paramètres de ligne de commande -PbuildOnly=paidRelease.

android {
    variantFilter { variant ->
        // Désactiver mock pour release et demo pour production
        def names = variant.flavors*.name
        def isMock = names.contains("mock")
        def isDemo = names.contains("demo")
        def isRelease = variant.buildType.name == "release"

        if ((isMock && isRelease) || (isDemo && !isMock)) {
            variant.setIgnore(true)
        }
    }
}

// Filtrage dynamique via paramètres
if (project.hasProperty("buildOnly")) {
    def target = project.property("buildOnly")
    android.variantFilter { variant ->
        variant.setIgnore(variant.name != target)
    }
}