Configurer votre build

Le système de compilation Android compile des ressources d'application et du code source, puis les empaquette dans des APK ou des Android App Bundles (AAB) que vous pouvez tester, déployer, signer et distribuer.

Android Studio utilise Gradle, une boîte à outils de compilation avancée, pour automatiser et gérer le processus de compilation, tout en vous permettant de définir des configurations de compilation personnalisées flexibles. Chaque configuration de compilation peut définir son propre ensemble de code et de ressources, tout en réutilisant les parties communes à toutes les versions de votre application. Le plug-in Android Gradle fonctionne avec le kit d'outils de compilation pour fournir des processus et des paramètres configurables spécifiques à la compilation et aux tests des applications Android.

Gradle et le plug-in Android Gradle s'exécutent indépendamment d'Android Studio. Cela signifie que vous pouvez compiler vos applications Android à partir d'Android Studio, de la ligne de commande sur votre ordinateur ou sur des ordinateurs sur lesquels Android Studio n'est pas installé, comme des serveurs d'intégration continue.

Si vous n'utilisez pas Android Studio, découvrez comment créer et exécuter votre application à partir de la ligne de commande. Que vous compiliez un projet à partir de la ligne de commande, sur une machine distante ou à l'aide d'Android Studio, le résultat de la compilation est le même.

Remarque : Étant donné que Gradle et le plug-in Android Gradle s'exécutent indépendamment d'Android Studio, vous devez mettre à jour les outils de compilation séparément. Consultez les notes de version pour découvrir comment mettre à jour Gradle et le plug-in Android Gradle.

Grâce à la souplesse du système de compilation Android, vous pouvez effectuer des configurations de compilation personnalisées sans avoir à modifier les fichiers sources principaux de votre application. Cette page vous aide à comprendre le fonctionnement du système de compilation Android, ainsi que la façon dont il peut vous aider à personnaliser et automatiser plusieurs configurations de compilation. Pour en savoir plus sur le déploiement de votre application, consultez la section Compiler et exécuter votre application. Pour commencer à créer immédiatement des configurations de compilation personnalisées à l'aide d'Android Studio, consultez la section Configurer des variantes de compilation.

Processus de compilation

Le processus de compilation comporte de nombreux outils et processus qui convertissent votre projet en Android Application Bundle (APK) ou Android App Bundle (AAB).

Le plug-in Android Gradle effectue la majeure partie du processus de compilation pour vous. Toutefois, il peut être utile de comprendre certains aspects de ce processus afin que vous puissiez l'ajuster pour répondre à vos besoins.

Les projets peuvent avoir des objectifs de compilation différents. Par exemple, la compilation d'un une bibliothèque tierce génère une archive Android (AAR) ou Java Archive (JAR) bibliothèques. Cependant, une application est le type de projet le plus courant, et la compilation d'un projet d'application génère un APK ou un AAB "debug" ou "release" de votre application que vous pouvez déployer, tester ou publier auprès des utilisateurs externes.

Cette page se concentre sur le développement d'applications, mais une grande partie des étapes et des concepts de compilation est commune à la plupart des types de compilation.

Glossaire de compilation Android

Gradle et le plug-in Android Gradle vous aident à configurer les aspects suivants de votre build :

Types de compilation

Les types de compilation définissent certaines propriétés que Gradle utilise lors de la création et du packaging de votre application. Ils sont généralement configurés pour différentes étapes de votre cycle de développement.

Par exemple, le type de compilation "debug" active les options de débogage et signe l'application avec la clé de débogage, tandis que le type de compilation "release" peut réduire, obscurcir et signer votre application avec une clé de release en vue de la distribution.

Vous devez définir au moins un type de compilation pour pouvoir compiler votre application. Android Studio crée les types de compilation "debug" et "release" par défaut. Pour commencer à personnaliser les paramètres de packaging de votre application, découvrez comment configurer les types de compilation.

Types de produit
Les types de produit représentent différentes versions de votre application que vous pouvez proposer aux utilisateurs, telles que des versions gratuites et payantes. Vous pouvez personnaliser les types de produits pour qu'ils utilisent des ressources et du code différents, tout en partageant et en réutilisant les parties communes à toutes les versions de votre application. Les types de produit sont facultatifs. Vous devez les créer manuellement. Pour commencer à créer différentes versions de votre application, découvrez comment configurer les types de produit.
Variantes de compilation
Une variante de compilation est un produit croisé d'un type de compilation et d'un type de produit. Il s'agit de la configuration que Gradle utilise pour créer votre application. Les variantes de compilation vous permettent de créer la version de débogage de vos types de produit pendant le développement ou les versions signées de ces types pour les distribuer. Bien que vous ne configuriez pas directement les variantes de compilation, vous configurez les types de compilation et les types de produit dont elles sont constituées. La création de types de compilation ou de produit supplémentaires entraîne également la création de variantes de compilation. Pour apprendre à créer et à gérer des variantes de compilation, consultez la présentation Configurer des variantes de compilation.
Entrées du fichier manifeste
Vous pouvez spécifier des valeurs pour certaines propriétés du fichier manifeste dans la configuration de la variante de compilation. Ces valeurs de compilation remplacent les valeurs existantes dans le fichier manifeste. Cela s'avère utile si vous souhaitez générer plusieurs variantes de votre application avec une version de SDK minimale, une version de SDK cible ou un nom d'application différent. Lorsque plusieurs fichiers manifestes sont présents, l'outil de fusion de fichiers manifestes fusionne leurs paramètres.
Dépendances
Le système de compilation gère les dépendances du projet à partir de votre système de fichiers local et des dépôts distants. Vous n'avez donc pas besoin de rechercher, télécharger ni copier manuellement les packages binaires de vos dépendances dans le répertoire de votre projet. Pour en savoir plus, consultez Ajouter des dépendances de compilation.
Signature
Le système de compilation vous permet de spécifier des paramètres de signature dans la configuration de compilation. De plus, il peut signer automatiquement votre application lors du processus de compilation. Le système de compilation signe la version de débogage avec une clé et un certificat par défaut à l'aide d'identifiants connus pour éviter une invite de saisie du mot de passe au moment de la compilation. Il ne signe pas la version de release, sauf si vous définissez explicitement une configuration de signature pour ce build. Si vous ne disposez pas de clé de publication, vous pouvez en générer une comme décrit dans la section Signer votre application. Les builds signés sont requis pour la distribution des applications via la plupart des plates-formes de téléchargement d'applications.
Minification du code et des ressources
Le système de compilation vous permet de spécifier un fichier de règles ProGuard différent pour chaque variante de compilation. Lors de la compilation de votre application, le système de compilation applique l'ensemble de règles approprié pour réduire votre code et vos ressources à l'aide de ses outils de réduction intégrés tels que R8. La minification de votre code et de vos ressources peut vous aider à réduire la taille de votre fichier APK ou AAB.
Prendre en charge plusieurs fichiers APK
Le système de compilation vous permet de compiler automatiquement différents APK ne contenant chacun que le code et les ressources nécessaires pour une densité d'écran ou une interface binaire d'application (ABI) spécifiques. Pour en savoir plus, consultez Compiler plusieurs fichiers APK. Cependant, la publication d'un seul fichier AAB est l'approche recommandée, car elle permet une division par langue en plus de la densité d'écran et de l'ABI, tout en évitant d'avoir à importer plusieurs artefacts sur Google Play. Toutes les nouvelles applications envoyées après août 2021 devront utiliser des AAB.

Versions de Java dans les builds Android

Que votre code source soit écrit en Java, en Kotlin ou les deux, vous devez choisir un langage JDK ou Java à plusieurs endroits pour votre build. Consultez les versions de Java dans les builds Android. pour en savoir plus.

Fichiers de configuration de compilation

Pour créer des configurations de compilation personnalisées, vous devez modifier un ou plus de fichiers de configuration de compilation. Ces de texte brut utilisent le langage spécifique au domaine (DSL, Domain Specific Language) pour décrire et manipuler la logique de compilation Script Kotlin qui est un type de langage Kotlin. Vous pouvez également utiliser Groovy, dynamique pour la machine virtuelle Java (JVM) afin de configurer vos compilations.

Vous n'avez pas besoin de connaître le script Kotlin ni Groovy pour commencer à configurer build, car le plug-in Android Gradle introduit la plupart des éléments DSL dont vous avez besoin. Pour en savoir plus sur le DSL du plug-in Android Gradle, consultez le Documentation de référence DSL Le script Kotlin s'appuie également sur sous-jacentes DSL Kotlin Gradle.

Lorsque vous démarrez un nouveau projet, Android Studio crée automatiquement certains ces fichiers pour vous et les remplit en fonction de valeurs par défaut raisonnables. Le projet présente la mise en page suivante: 

└── MyApp/  # Project
    ├── gradle/
    │   └── wrapper/
    │       └── gradle-wrapper.properties
    ├── build.gradle(.kts)
    ├── settings.gradle(.kts)
    └── app/  # Module
    │   ├── build.gradle(.kts)
    │   ├── build/
    │   ├── libs/
    │   └── src/
    │        └── main/  # Source set
    │            ├── java/
    │            │   └── com.example.myapp
    │            ├── res/
    │            │   ├── drawable/
    │            │   ├── values/
    │            │   └── ...
    │            └── AndroidManifest.xml

Certains fichiers de configuration de compilation Gradle font partie de la structure de projet standard d'une application Android. Avant de commencer à configurer votre build, il est important de comprendre le champ d'application et la finalité de chacun de ces fichiers, ainsi que les éléments DSL de base qu'ils définissent.

Fichier Gradle Wrapper

Le wrapper Gradle (gradlew) est une petite application incluse dans votre qui télécharge et lance Gradle lui-même. Cela crée une exécution de compilation plus cohérente. Les développeurs téléchargent source de l'application et exécuter gradlew. Le fichier Gradle requis est alors téléchargé et lance Gradle pour créer votre application.

Le fichier gradle/wrapper/gradle-wrapper.properties contient une propriété, distributionUrl, qui décrit la version de Gradle permet d'exécuter votre build.

distributionBase=GRADLE_USER_HOME
distributionPath=wrapper/dists
distributionUrl=https\://services.gradle.org/distributions/gradle-8.0-bin.zip
zipStoreBase=GRADLE_USER_HOME
zipStorePath=wrapper/dists

Fichier des paramètres Gradle

Le fichier settings.gradle.kts (pour le DSL Kotlin) ou Le fichier settings.gradle (pour le DSL Groovy) se trouve à la racine dans le répertoire du projet. Ce fichier de paramètres définit le dépôt au niveau du projet et indique à Gradle les modules qu'il doit inclure lors de la compilation de votre l'application. Les projets multimodules doivent spécifier chaque module devant accéder au le build final.

Pour la plupart des projets, ce fichier se présente comme suit par défaut :

Kotlin

pluginManagement {

    /**
      * The pluginManagement.repositories block configures the
      * repositories Gradle uses to search or download the Gradle plugins and
      * their transitive dependencies. Gradle pre-configures support for remote
      * repositories such as JCenter, Maven Central, and Ivy. You can also use
      * local repositories or define your own remote repositories. The code below
      * defines the Gradle Plugin Portal, Google's Maven repository,
      * and the Maven Central Repository as the repositories Gradle should use to look for its
      * dependencies.
      */

    repositories {
        gradlePluginPortal()
        google()
        mavenCentral()
    }
}
dependencyResolutionManagement {

    /**
      * The dependencyResolutionManagement.repositories
      * block is where you configure the repositories and dependencies used by
      * all modules in your project, such as libraries that you are using to
      * create your application. However, you should configure module-specific
      * dependencies in each module-level build.gradle file. For new projects,
      * Android Studio includes Google's Maven repository and the Maven Central
      * Repository by default, but it does not configure any dependencies (unless
      * you select a template that requires some).
      */

  repositoriesMode.set(RepositoriesMode.FAIL_ON_PROJECT_REPOS)
  repositories {
      google()
      mavenCentral()
  }
}
rootProject.name = "My Application"
include(":app")

Groovy

pluginManagement {

    /**
      * The pluginManagement.repositories block configures the
      * repositories Gradle uses to search or download the Gradle plugins and
      * their transitive dependencies. Gradle pre-configures support for remote
      * repositories such as JCenter, Maven Central, and Ivy. You can also use
      * local repositories or define your own remote repositories. The code below
      * defines the Gradle Plugin Portal, Google's Maven repository,
      * and the Maven Central Repository as the repositories Gradle should use to look for its
      * dependencies.
      */

    repositories {
        gradlePluginPortal()
        google()
        mavenCentral()
    }
}
dependencyResolutionManagement {

    /**
      * The dependencyResolutionManagement.repositories
      * block is where you configure the repositories and dependencies used by
      * all modules in your project, such as libraries that you are using to
      * create your application. However, you should configure module-specific
      * dependencies in each module-level build.gradle file. For new projects,
      * Android Studio includes Google's Maven repository and the Maven Central
      * Repository by default, but it does not configure any dependencies (unless
      * you select a template that requires some).
      */

    repositoriesMode.set(RepositoriesMode.FAIL_ON_PROJECT_REPOS)
    repositories {
        google()
        mavenCentral()
    }
}
rootProject.name = "My Application"
include ':app'

Fichier de compilation de premier niveau

Le fichier build.gradle.kts de premier niveau (pour le DSL Kotlin) ou Le fichier build.gradle (pour le DSL Groovy) se trouve à la racine dans le répertoire du projet. Il définit généralement les versions courantes des plug-ins utilisés par modules de votre projet.

L'exemple de code suivant décrit les paramètres et les éléments DSL par défaut dans le script de compilation de premier niveau après avoir créé un projet:

Kotlin

plugins {

    /**
     * Use `apply false` in the top-level build.gradle file to add a Gradle
     * plugin as a build dependency but not apply it to the current (root)
     * project. Don't use `apply false` in sub-projects. For more information,
     * see Applying external plugins with same version to subprojects.
     */

    id("com.android.application") version "8.6.0" apply false
    id("com.android.library") version "8.6.0" apply false
    id("org.jetbrains.kotlin.android") version "1.9.23" apply false
}

Groovy

plugins {

    /**
     * Use `apply false` in the top-level build.gradle file to add a Gradle
     * plugin as a build dependency but not apply it to the current (root)
     * project. Don't use `apply false` in sub-projects. For more information,
     * see Applying external plugins with same version to subprojects.
     */

    id 'com.android.application' version '8.6.0' apply false
    id 'com.android.library' version '8.6.0' apply false
    id 'org.jetbrains.kotlin.android' version '1.9.23' apply false
}