Gradle : l'essence du système de build pour Android et build.gradle
Gradle est un système de build qui automatise la compilation, les tests et le packaging des applications Android. Contrairement à Apache Ant ou Maven, il prend en charge le build incrémental et la mise en cache des résultats. Pour en savoir plus sur ses fonctionnalités, consultez la documentation officielle de Gradle. Depuis 2013, l'outil est utilisé comme système de build standard pour les projets Android dans Android Studio.
Points clés
- Gradle — le système de build standard pour Android depuis 2013, remplaçant Ant et Maven
- Build.gradle.kts avec Kotlin DSL — le standard de configuration moderne avec vérification de types
- Les variantes de build combinent les types de build et les saveurs de produit pour différentes versions de l'application
- Les plugins étendent les fonctionnalités : de l'application des outils Android à la publication des builds
- Le build incrémental et la mise en cache réduisent le temps de recompilation de plusieurs fois
Qu'est-ce que Gradle ?
Gradle est un outil d'automatisation de build open source écrit en Java et fonctionnant sur la JVM. Il prend en entrée le code source, les dépendances et les ressources, et produit en sortie une application prête — APK ou AAB pour Android. À son cœur, Gradle utilise le concept d'un graphe orienté acyclique (DAG) de tâches, où chaque tâche est une unité atomique de travail et les connexions entre elles déterminent l'ordre d'exécution. Contrairement à Make ou Ant, Gradle ne nécessite pas de décrire manuellement une séquence d'étapes : il suffit de déclarer les dépendances entre les tâches, et le système détermine lui-même l'ordre optimal. Cette approche rend Gradle flexible et évolutif pour des projets de toute taille.
Le système utilise trois phases d'exécution : l'initialisation (identification des projets participants), la configuration (construction du graphe de tâches) et l'exécution (exécution des tâches dans l'ordre requis). La phase de configuration est une caractéristique clé de Gradle : l'intégralité du script de build s'exécute avant le début des tâches, permettant des modifications dynamiques du graphe en fonction des conditions. Cela permet, par exemple, d'ajouter des tâches uniquement pour des variantes de build spécifiques sans dupliquer le code. Le builder est écrit en Groovy, mais les fichiers de configuration prennent en charge deux langages : Groovy DSL et Kotlin DSL.
Comment Gradle gère-t-il le build des projets Android ?
Le plugin Android pour Gradle se compose de com.android.application et com.android.library, qui ajoutent des tâches au projet pour travailler avec les outils Android. Lorsqu'un développeur lance un build, Gradle exécute séquentiellement des dizaines de tâches : compiler Kotlin et Java via javac ou kotlinc, traiter les ressources via AAPT2, générer R.java, compiler le bytecode en DEX via D8 ou R8, signer et zipper l'APK. Chaque tâche vérifie si ses données d'entrée ont changé et, si ce n'est pas le cas, utilise le résultat mis en cache. Ce mécanisme est appelé build incrémental et accélère la recompilation de 60 à 80 % par rapport à une reconstruction complète.
La configuration du module Android est définie dans le bloc android du fichier build.gradle.kts. À l'intérieur du bloc, compileSdk, minSdk, targetSdk, la version de l'application, les signatures et d'autres paramètres sont définis. Gradle crée automatiquement plusieurs variantes de build pour chaque module — une combinaison de type (release, debug) et de saveur. Par exemple, pour un module avec deux saveurs et deux types, Gradle génère quatre tâches : assembleDemoDebug, assembleDemoRelease, assembleFullDebug, assembleFullRelease. Toutes ces tâches peuvent être exécutées individuellement ou lancées avec une seule commande pour toutes les variantes à la fois.
Build.gradle et build.gradle.kts : structure de configuration
Chaque projet Android contient deux niveaux de configuration : le build.gradle.kts racine (paramètres pour tous les modules) et le build.gradle.kts au niveau du module (paramètres pour un module spécifique). Dans le fichier racine, les plugins sont déclarés sans application, les dépôts et les variables communes. Dans le fichier du module, les plugins sont appliqués au module spécifique et les paramètres de build sont configurés. Cette approche permet une gestion centralisée des versions de dépendances via un catalogue de versions ou un bloc ext.
Kotlin
@Suppress("UnstableApiUsage")
plugins {
id("com.android.application") version "8.2.2"
id("org.jetbrains.kotlin.android") version "1.9.22"
}
android {
namespace = "com.example.myapp"
compileSdk = 34
defaultConfig {
applicationId = "com.example.myapp"
minSdk = 24
targetSdk = 34
versionCode = 1
versionName = "1.0"
}
}Le bloc dependencies est un autre élément critique de build.gradle.kts. Il liste les bibliothèques, modules et dépendances de fichiers dont l'application a besoin. Gradle prend en charge plusieurs configurations de dépendance : implementation (disponible uniquement pour le module actuel), api (également disponible pour les modules dépendants), testImplementation (uniquement pour les tests), androidTestImplementation (pour les tests instrumentés) et compileOnly (uniquement à la compilation). Chaque configuration gère la visibilité des classes dans le graphe de dépendances, ce qui affecte le temps de build et la taille de l'artefact final.
Kotlin
dependencies {
implementation("androidx.core:core-ktx:1.12.0")
implementation("androidx.lifecycle:lifecycle-runtime-ktx:2.7.0")
implementation("androidx.activity:activity-compose:1.8.2")
testImplementation("junit:junit:4.13.2")
androidTestImplementation("androidx.test.ext:junit:1.1.5")
}Variantes de build : options de build de l'application
Une variante de build est une combinaison de type de build et de saveur de produit qui définit une version de l'application avec des paramètres, un code et des ressources uniques. Le type de build définit les paramètres de packaging : debug (avec débogage et suffixe .debug) ou release (avec obscurcissement et signature). La saveur de produit définit des variantes fonctionnelles : par exemple, demo (version limitée) et full (version complète avec fonctionnalités supplémentaires). Gradle génère automatiquement des tâches pour chaque combinaison, permettant de construire toutes les versions avec une seule commande.
Kotlin
android {
buildTypes {
release {
isMinifyEnabled = true
proguardFiles(
getDefaultProguardFile("proguard-android-optimize.txt"),
"proguard-rules.pro"
)
}
debug {
applicationIdSuffix = ".debug"
}
}
flavorDimensions += "version"
productFlavors {
create("demo") {
dimension = "version"
applicationIdSuffix = ".demo"
}
create("full") {
dimension = "version"
applicationIdSuffix = ".full"
}
}
}Chaque variante de build possède un ensemble de sources séparé. Gradle utilise des répertoires src/demo/release, src/full/debug et autres, qui stockent des ressources, manifestes et fichiers sources uniques pour une variante spécifique. Le code commun reste dans src/main. Cette approche permet de réutiliser la logique principale et de ne remplacer que les parties différentes : chaînes, icônes, points de terminaison API ou fichiers de configuration. Un ensemble de sources peut remplacer toutes les ressources de main : manifeste, drawable, values ou même des classes Kotlin. Lors de la construction d'une variante spécifique, Gradle fusionne les fichiers de main et de l'ensemble de sources correspondant, les fichiers de la variante ayant la priorité.
Plugins Gradle pour Android : extension des capacités
L'écosystème de plugins Gradle couvre toutes les étapes du développement d'applications Android. Les plugins officiels de Google incluent com.android.application (pour le module d'application), com.android.library (pour le module de bibliothèque), com.android.test (pour les modules de test) et les plugins Kotlin de JetBrains. Les plugins ajoutent de nouvelles tâches au projet, étendent le DSL avec de nouveaux blocs de configuration et connectent des outils supplémentaires. Sans le plugin com.android.application, un projet ne peut pas construire d'APK : ce plugin enregistre toutes les tâches spécifiques à Android et les lie dans le graphe de build.
Les plugins tiers résolvent des tâches plus spécifiques. Google Services (com.google.gms.google-services) intègre Firebase et Google Play Services, insérant automatiquement google-services.json dans le build. Hilt (dagger.hilt.android.plugin) génère du code d'injection de dépendances à la compilation. Safe Args (androidx.navigation.safeargs.kotlin) crée des classes type-safe pour la navigation entre les fragments. Chaque plugin est ajouté dans le build.gradle.kts racine via le bloc plugins et nécessite généralement une configuration minimale. Gradle résout automatiquement les dépendances transitives entre les plugins et garantit la compatibilité des versions via des fichiers Bom et des catalogues de versions.
Tâches Gradle : automatisation des processus de build
Une tâche est une unité atomique de travail dans Gradle. Chaque tâche a des données d'entrée, des données de sortie et une action. Les tâches intégrées pour Android incluent assemble (construction de toutes les variantes), lint (vérification du code), test (exécution de tests unitaires) et clean (nettoyage des fichiers temporaires). Les développeurs peuvent ajouter leurs propres tâches en utilisant Groovy ou Kotlin DSL. Les tâches personnalisées sont utiles pour automatiser des opérations routinières : générer des rapports, copier des artefacts, déployer sur des appareils de test ou intégrer avec des systèmes CI.
Kotlin
tasks.register("printBuildInfo") {
description = "Affiche les informations de build"
group = "custom"
doLast {
println("Build variant: ${project.name}")
println("Version: ${android.defaultConfig.versionName}")
}
}Chaque tâche peut dépendre d'autres tâches via le mécanisme dependsOn. Si la tâche A dépend de la tâche B, Gradle garantit que B s'exécutera avant A. Le système ne nécessite pas de spécifier manuellement l'ordre pour chaque paire — il suffit de déclarer les dépendances, et Gradle construira un graphe orienté optimisé pour l'exécution parallèle de tâches indépendantes. Les tâches intégrées du plugin Android sont déjà liées entre elles : lint dépend de la compilation, test dépend de assemble, assembleDebug dépend de compileDebugKotlin. Les développeurs peuvent insérer leurs propres tâches dans n'importe quel nœud du graphe en utilisant dependsOn, mustRunAfter ou shouldRunAfter.
Erreurs courantes lors du travail avec Gradle
L'un des problèmes fréquents est le conflit de versions de dépendances, lorsque deux bibliothèques nécessitent des versions différentes de la même dépendance transitive. Gradle signale une erreur de conflit, mais n'offre pas toujours de solution automatique. Pour le diagnostic, utilisez la commande ./gradlew :app:dependencies, qui affiche l'arbre complet des dépendances. Il est recommandé de forcer la version de la bibliothèque conflictuelle via le bloc resolutionStrategy. Un autre scénario courant est le build lent dû à l'absence de traitement incrémental. Assurez-vous que tous les plugins sont mis à jour, que le démon Gradle est activé (org.gradle.daemon=true) et qu'une mémoire suffisante est définie dans gradle.properties : org.gradle.jvmargs=-Xmx4096m.
Les problèmes de cache surviennent après la mise à jour des dépendances : Gradle peut utiliser un cache obsolète et le build échoue. La solution consiste à exécuter le build avec le flag --refresh-dependencies ou à vider le cache manuellement via ./gradlew cleanBuildCache. La troisième erreur la plus courante est l'incompatibilité de version entre Android Gradle Plugin (AGP) et Gradle. Chaque version d'AGP nécessite une version minimale spécifique de Gradle. Le tableau de compatibilité est publié sur developer.android.com. Si les versions sont incompatibles, Gradle échoue à l'étape de configuration avec un message concernant la version minimale requise. Vérifiez toujours que la version du wrapper Gradle correspond aux exigences d'AGP.
Questions fréquemment posées
Qu'est-ce que Gradle en termes simples ?
Gradle est un programme d'automatisation pour construire des projets. Il prend votre code source en Kotlin ou Java, connecte des bibliothèques depuis Internet, compile tout en bytecode et le package en APK. Il fonctionne sur la JVM et utilise des scripts déclaratifs au lieu d'instructions manuelles. Le développeur n'a qu'à décrire les règles, et Gradle fait le reste.
En quoi build.gradle.kts diffère-t-il de build.gradle ?
Build.gradle est écrit en Groovy — un langage dynamique avec une syntaxe flexible et moins de rigueur. Build.gradle.kts utilise Kotlin DSL : typage fort, autocomplétion dans Android Studio et vérification des erreurs à la compilation. Google recommande Kotlin DSL pour tous les nouveaux projets. Les fichiers Groovy sont plus faciles à migrer, mais les fichiers Kotlin sont plus fiables à maintenir.
Comment accélérer le build Gradle ?
Activez le démon Gradle (org.gradle.daemon=true) et le build parallèle (org.gradle.parallel=true). Augmentez la mémoire JVM à 4–8 Go via org.gradle.jvmargs. Utilisez la configuration de projet à la demande (org.gradle.configureondemand=true). Pour les projets Android, configurez la mise en cache des tâches et ne construisez que pour l'ABI requise. Dans Android Studio, exécutez Build Analyzer pour trouver les goulots d'étranglement.
Qu'est-ce qu'une variante de build dans Android ?
Une variante de build est une combinaison de type de build (par exemple, debug ou release) et de saveur de produit (par exemple, demo ou full). Chaque variante peut avoir son propre nom de package, version, ressources et fichiers sources. Gradle crée automatiquement une tâche de build séparée pour chaque variante. Cela permet de construire plusieurs versions de l'application à partir d'un seul projet.
Comment ajouter une dépendance dans Gradle ?
Les dépendances sont ajoutées dans le bloc dependencies du fichier build.gradle.kts. Le format est : configuration("group:artifact:version"). Par exemple, implementation("androidx.core:core-ktx:1.12.0"). Pour les tests, utilisez testImplementation, pour les tests instrumentés — androidTestImplementation. Les versions sont commodément organisées dans un catalogue de versions séparé via le fichier libs.versions.toml.
Résumé
- Gradle — le système de build standard pour Android, fonctionnant sur la JVM et utilisant un DAG de tâches
- Build incrémental et mise en cache réduisent le temps de recompilation de 60 à 80%
- Kotlin DSL (build.gradle.kts) — un format de configuration moderne avec autocomplétion et vérification de types
- Variantes de build combinent type de build et saveur de produit, créant des ensembles de sources séparés pour chaque variante
- Plugins étendent Gradle : du plugin Android de base à Firebase, Hilt et Safe Args
- Tâches personnalisées permettent d'automatiser toutes les étapes de build et d'intégration
- Problèmes courants — conflits de versions, builds lents et incompatibilité d'AGP avec la version de Gradle
Nous développerons une application mobile clé en main
IT Sectr crée des applications iOS et Android pour les startups et les entreprises depuis 2017. Nous vous conseillerons et vous proposerons la meilleure solution.
Lisez aussi