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.

Dans Présentation de la compilation Gradle et Structure de compilation Android, nous avons abordé les concepts de compilation et la structure d'une application Android. Il est maintenant temps de configurer la compilation.

Glossaire de la 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 dans les deux, vous devez choisir une version de JDK ou de langage Java pour votre compilation à plusieurs endroits. Pour en savoir plus, consultez la section Versions de Java dans les builds Android.

Fichiers de configuration de compilation

Pour créer des configurations de compilation personnalisées, vous devez modifier un ou plusieurs fichiers de configuration de compilation. Ces fichiers en texte brut utilisent un langage spécifique au domaine (DSL) pour décrire et manipuler la logique de compilation à l'aide d'un script Kotlin, qui est un type de langage Kotlin. Vous pouvez également utiliser Groovy, un langage dynamique pour la machine virtuelle Java (JVM), pour configurer vos compilations.

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

Lorsque vous démarrez un nouveau projet, Android Studio crée automatiquement certains de ces fichiers et les remplit en fonction de valeurs par défaut raisonnables. Pour obtenir une présentation des fichiers créés, consultez Structure de compilation Android.

Fichier Gradle Wrapper

Le wrapper Gradle (gradlew) est une petite application incluse avec votre code source qui télécharge et lance Gradle lui-même. Cela permet d'obtenir une exécution de compilation plus cohérente. Les développeurs téléchargent la source de l'application et exécutent gradlew. Cette action télécharge la distribution Gradle requise et lance Gradle pour compiler votre application.

Le fichier gradle/wrapper/gradle-wrapper.properties contient une propriété, distributionUrl, qui décrit la version de Gradle utilisée pour exécuter votre compilation.

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 settings.gradle (pour le DSL Groovy) se trouve dans le répertoire racine du projet. Ce fichier de paramètres définit les paramètres du dépôt au niveau du projet et indique à Gradle les modules qu'il doit inclure lors de la compilation de votre application. Les projets multimodules doivent spécifier chaque module à inclure dans la compilation finale.

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. Here we
      * define 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. Here we
      * define 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 dans le répertoire racine du projet. Il définit généralement les versions courantes des plug-ins utilisés par les modules de votre projet.

L'exemple de code suivant décrit les éléments DSL et les paramètres 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.7.0" apply false
    id("com.android.library") version "8.7.0" apply false
    id("org.jetbrains.kotlin.android") version "2.0.20" 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.7.0' apply false
    id 'com.android.library' version '8.7.0' apply false
    id 'org.jetbrains.kotlin.android' version '2.0.20' apply false
}