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.
Chaque projet peut avoir des objectifs de compilation différents. Par exemple, la compilation d'une bibliothèque tierce génère des bibliothèques AAR ou JAR. 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.
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, ou fichiers build.gradle. Ces fichiers en texte brut utilisent le langage spécifique au domaine (DSL) pour décrire et manipuler la logique de compilation à l'aide de Groovy, un langage dynamique pour la machine virtuelle Java (JVM), ou d'un script Kotlin, qui est un type de langage Kotlin.
Vous n'avez pas besoin de connaître Groovy ni le script Kotlin 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 pour Groovy. 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, comme le montre la figure 1, et les remplit en fonction de valeurs par défaut raisonnables.
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 des paramètres Gradle
Le fichier settings.gradle (pour Groovy) ou settings.gradle.kts
(pour le script Kotlin) se trouve dans le répertoire racine du projet. Ce fichier 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 création de votre application. Les projets multimodules doivent spécifier chaque module qui doit faire partie de la compilation finale.
Pour la plupart des projets, ce fichier se présente comme suit par défaut :
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’
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")
Fichier de compilation de premier niveau
Le fichier build.gradle de premier niveau (pour Groovy) ou le fichier build.gradle.kts (pour le script Kotlin) se trouve dans le répertoire racine du projet. Il définit les dépendances qui s'appliquent à tous les modules de votre projet. Par défaut, le fichier de compilation de premier niveau utilise le bloc plugins pour définir les dépendances Gradle communes à l'ensemble des modules du projet. En outre, ce fichier contient du code permettant de nettoyer le répertoire de compilation.
L'exemple de code suivant décrit les éléments DSL et les paramètres par défaut que vous pouvez trouver dans le fichier build.gradle de premier niveau après avoir créé un projet :
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 '7.4.1' apply false
id 'com.android.library' version '7.4.1' apply false
id 'org.jetbrains.kotlin.android' version '1.8.10' apply false
}
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 "7.4.1" apply false
id("com.android.library") version "7.4.1" apply false
id("org.jetbrains.kotlin.android") version "1.8.10" apply false
}
Configurer des propriétés à l'échelle du projet à l'aide de propriétés supplémentaires (obsolète)
Dans le cas des projets Android comprenant plusieurs modules, il peut être utile de définir certaines propriétés au niveau du projet et de les partager entre tous les modules. Pour ce faire, ajoutez des propriétés supplémentaires au bloc ext du fichier build.gradle de premier niveau (pour Groovy) ou build.gradle.kts (pour le script Kotlin) :
Groovy
// This block encapsulates custom properties and makes them available to all
// modules in the project. The following are only a few examples of the types
// of properties you can define.
ext {
sdkVersion = 33
// You can also create properties to specify versions for dependencies.
// Having consistent versions between modules can avoid conflicts with behavior.
appcompatVersion = "1.6.1"
...
}
...
Kotlin
// This block encapsulates custom properties and makes them available to all
// modules in the project. The following are only a few examples of the types
// of properties you can define.
ext {
extra["sdkVersion"] = 33
// You can also create properties to specify versions for dependencies.
// Having consistent versions between modules can avoid conflicts with behavior.
extra["appcompatVersion"] = "1.6.1"
...
}
...
Pour accéder à ces propriétés à partir d'un module du même projet, utilisez la syntaxe suivante dans le fichier build.gradle au niveau du module.
Groovy
android {
// Use the following syntax to access properties you defined at the project level:
// rootProject.ext.property_name
compileSdk rootProject.ext.sdkVersion
...
}
...
dependencies {
implementation "androidx.appcompat:appcompat:${rootProject.ext.appcompatVersion}"
...
}
Kotlin
android {
// Use the following syntax to access properties you defined at the project level:
// rootProject.extra["property_name"]
compileSdk = rootProject.extra["sdkVersion"]
// Alternatively, you can access properties using a type safe delegate:
val sdkVersion: Int by rootProject.extra
...
compileSdk = sdkVersion
}
...
dependencies {
implementation("androidx.appcompat:appcompat:${rootProject.ext.appcompatVersion}")
...
}
Fichier de compilation au niveau du module
Le fichier build.gradle au niveau du module (pour Groovy) ou build.gradle.kts (pour le script Kotlin) se trouve dans chaque répertoire project/module/. Il vous permet de configurer les paramètres de compilation du module dans lequel il se trouve. La configuration de ces paramètres de compilation vous permet de fournir des options de packaging personnalisées, telles que des types de compilation et des types de produit supplémentaires, et de remplacer les paramètres du fichier manifeste d'application main/, ou du fichier build.gradle ou build.gradle.kts de premier niveau.
Cet exemple de fichier de module d'application Android build.gradle présente certains éléments et paramètres DSL de base :
Groovy
/**
* The first line in the build configuration applies the Android Gradle plugin
* to this build and makes the android block available to specify
* Android-specific build options.
*/
plugins {
id 'com.android.application'
}
/**
* The android block is where you configure all your Android-specific
* build options.
*/
android {
/**
* The app's namespace. Used primarily to access app resources.
*/
namespace 'com.example.myapp'
/**
* compileSdk specifies the Android API level Gradle should use to
* compile your app. This means your app can use the API features included in
* this API level and lower.
*/
compileSdk 33
/**
* The defaultConfig block encapsulates default settings and entries for all
* build variants and can override some attributes in main/AndroidManifest.xml
* dynamically from the build system. You can configure product flavors to override
* these values for different versions of your app.
*/
defaultConfig {
// Uniquely identifies the package for publishing.
applicationId 'com.example.myapp'
// Defines the minimum API level required to run the app.
minSdk 21
// Specifies the API level used to test the app.
targetSdk 33
// Defines the version number of your app.
versionCode 1
// Defines a user-friendly version name for your app.
versionName "1.0"
}
/**
* The buildTypes block is where you can configure multiple build types.
* By default, the build system defines two build types: debug and release. The
* debug build type is not explicitly shown in the default build configuration,
* but it includes debugging tools and is signed with the debug key. The release
* build type applies ProGuard settings and is not signed by default.
*/
buildTypes {
/**
* By default, Android Studio configures the release build type to enable code
* shrinking, using minifyEnabled, and specifies the default ProGuard rules file.
*/
release {
minifyEnabled true // Enables code shrinking for the release build type.
proguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-rules.pro'
}
}
/**
* The productFlavors block is where you can configure multiple product flavors.
* This lets you create different versions of your app that can
* override the defaultConfig block with their own settings. Product flavors
* are optional, and the build system does not create them by default.
*
* This example creates a free and paid product flavor. Each product flavor
* then specifies its own application ID, so that they can exist on the Google
* Play Store, or an Android device, simultaneously.
*
* If you declare product flavors, you must also declare flavor dimensions
* and assign each flavor to a flavor dimension.
*/
flavorDimensions "tier"
productFlavors {
free {
dimension "tier"
applicationId 'com.example.myapp.free'
}
paid {
dimension "tier"
applicationId 'com.example.myapp.paid'
}
}
}
/**
* The dependencies block in the module-level build configuration file
* specifies dependencies required to build only the module itself.
* To learn more, go to Add build dependencies.
*/
dependencies {
implementation project(":lib")
implementation 'androidx.appcompat:appcompat:1.6.1'
implementation fileTree(dir: 'libs', include: ['*.jar'])
}
Kotlin
/**
* The first section in the build configuration applies the Android Gradle plugin
* to this build and makes the android block available to specify
* Android-specific build options.
*/
plugins {
id("com.android.application")
}
/**
* The android block is where you configure all your Android-specific
* build options.
*/
android {
/**
* The app's namespace. Used primarily to access app resources.
*/
namespace = "com.example.myapp"
/**
* compileSdk specifies the Android API level Gradle should use to
* compile your app. This means your app can use the API features included in
* this API level and lower.
*/
compileSdk = 33
/**
* The defaultConfig block encapsulates default settings and entries for all
* build variants and can override some attributes in main/AndroidManifest.xml
* dynamically from the build system. You can configure product flavors to override
* these values for different versions of your app.
*/
defaultConfig {
// Uniquely identifies the package for publishing.
applicationId = "com.example.myapp"
// Defines the minimum API level required to run the app.
minSdk = 21
// Specifies the API level used to test the app.
targetSdk = 33
// Defines the version number of your app.
versionCode = 1
// Defines a user-friendly version name for your app.
versionName = "1.0"
}
/**
* The buildTypes block is where you can configure multiple build types.
* By default, the build system defines two build types: debug and release. The
* debug build type is not explicitly shown in the default build configuration,
* but it includes debugging tools and is signed with the debug key. The release
* build type applies ProGuard settings and is not signed by default.
*/
buildTypes {
/**
* By default, Android Studio configures the release build type to enable code
* shrinking, using minifyEnabled, and specifies the default ProGuard rules file.
*/
getByName("release") {
isMinifyEnabled = true // Enables code shrinking for the release build type.
proguardFiles(
getDefaultProguardFile("proguard-android.txt"),
"proguard-rules.pro"
)
}
}
/**
* The productFlavors block is where you can configure multiple product flavors.
* This lets you create different versions of your app that can
* override the defaultConfig block with their own settings. Product flavors
* are optional, and the build system does not create them by default.
*
* This example creates a free and paid product flavor. Each product flavor
* then specifies its own application ID, so that they can exist on the Google
* Play Store, or an Android device, simultaneously.
*
* If you declare product flavors, you must also declare flavor dimensions
* and assign each flavor to a flavor dimension.
*/
flavorDimensions += "tier"
productFlavors {
create("free") {
dimension = "tier"
applicationId = "com.example.myapp.free"
}
create("paid") {
dimension = "tier"
applicationId = "com.example.myapp.paid"
}
}
}
/**
* The dependencies block in the module-level build configuration file
* specifies dependencies required to build only the module itself.
* To learn more, go to Add build dependencies.
*/
dependencies {
implementation(project(":lib"))
implementation("androidx.appcompat:appcompat:1.6.1")
implementation(fileTree(mapOf("dir" to "libs", "include" to listOf("*.jar"))))
}
Fichiers de propriétés Gradle
Gradle comprend également deux fichiers de propriétés, situés dans le répertoire racine de votre projet, que vous pouvez utiliser pour spécifier des paramètres pour le kit d'outils de compilation Gradle proprement dit :
-
gradle.properties - Ce fichier vous permet de configurer les paramètres Gradle à l'échelle du projet, tels que la taille maximale du tas de mémoire du daemon Gradle. Pour en savoir plus, consultez la section Environnement de compilation.
-
local.properties -
Configure les propriétés de l'environnement local du système de compilation, dont :
ndk.dir: chemin d'accès au NDK. Cette propriété est maintenant obsolète. Toutes les versions téléchargées du NDK seront installées dans le répertoirendk, au sein du répertoire du SDK Android.sdk.dir: chemin d'accès au SDK.cmake.dir: chemin d'accès à CMake.ndk.symlinkdir: dans Android Studio 3.5 et versions ultérieures, cette propriété crée un lien symbolique vers le NDK qui peut être plus court que le chemin d'accès au NDK installé.
Remapper le NDK sur un chemin d'accès plus court (Windows uniquement)
Sous Windows, les outils du dossier NDK installé, tels que ld.exe, se terminent par de longs chemins d'accès. Ces outils ne sont pas adaptés aux longs chemins d'accès.
Pour créer un chemin d'accès plus court, dans local.properties, définissez la propriété ndk.symlinkdir pour que le plug-in Android Gradle crée un lien symbolique vers le NDK. Le chemin d'accès de ce lien symbolique peut être plus court que celui du dossier NDK existant.
Par exemple, ndk.symlinkdir = C:\ donne le lien symbolique suivant : C:\ndk\19.0.5232133
Synchroniser le projet avec les fichiers Gradle
Lorsque vous modifiez les fichiers de configuration de compilation de votre projet, Android Studio exige que vous synchronisiez vos fichiers de projet, de manière à pouvoir importer les modifications apportées à la configuration de compilation et exécuter certaines vérifications pour garantir que votre configuration n'entraîne pas d'erreurs de compilation.
Pour synchroniser les fichiers de votre projet, cliquez sur Sync Now (Synchroniser) dans la barre de notification qui s'affiche lorsque vous effectuez une modification, comme illustré dans la figure 2, ou sur Sync Project (Synchroniser le projet) 
dans la barre de menu. Si Android Studio détecte des erreurs dans votre configuration (par exemple, si votre code source utilise des fonctionnalités d'API qui ne sont disponibles qu'à un niveau d'API supérieur à votre compileSdkVersion), la fenêtre Messages décrit le problème.
Ensembles de sources
Android Studio regroupe, de manière logique, le code source et les ressources de chaque module dans des ensembles de sources. Lorsque vous créez un module, Android Studio crée un ensemble de sources main/ dans le module. L'ensemble de sources main/ d'un module comprend le code et les ressources utilisés par toutes ses variantes de compilation.
Les répertoires d'ensembles de sources supplémentaires sont facultatifs, et Android Studio ne les crée pas automatiquement lorsque vous configurez de nouvelles variantes de compilation. Toutefois, la création d'ensembles de sources, semblables à main/, permet d'organiser les fichiers et les ressources que Gradle ne doit utiliser que lors de la compilation de certaines versions de votre application :
-
src/main/ - Cet ensemble de sources contient le code et les ressources communs à toutes les variantes de compilation.
-
src/buildType/ - Créez cet ensemble de sources pour n'inclure du code et des ressources que pour un type de compilation spécifique.
-
src/productFlavor/ -
Créez cet ensemble de sources pour n'inclure du code et des ressources que pour un type de produit spécifique.
Remarque : Si vous configurez votre build pour qu'il combine plusieurs types de produit, vous pouvez créer des répertoires d'ensembles de sources pour chaque combinaison entre les groupes de types :
src/productFlavor1ProductFlavor2/. -
src/productFlavorBuildType/ - Créez cet ensemble de sources pour n'inclure du code et des ressources que pour une variante de compilation spécifique.
Par exemple, pour générer la version "fullDebug" de votre application, le système de compilation fusionne le code, les paramètres et les ressources des ensembles de sources suivants :
-
src/fullDebug/(ensemble de sources de la variante de compilation) -
src/debug/(ensemble de sources du type de compilation) -
src/full/(ensemble de sources du type de produit) -
src/main/(ensemble de sources principal)
Remarque : Lorsque vous créez un fichier ou un répertoire dans Android Studio, utilisez les options de menu File > New (Fichier > Nouveau) afin de le créer pour un ensemble de sources spécifique. Les ensembles de sources que vous pouvez choisir dépendent de vos configurations de compilation. Android Studio crée automatiquement les répertoires requis s'ils n'existent pas.
Si différents ensembles de sources contiennent différentes versions du même fichier, Gradle utilise l'ordre de priorité suivant pour déterminer le fichier à utiliser (les ensembles de sources de gauche remplacent les fichiers et paramètres des ensembles de sources de droite) :
variante de compilation > type de compilation > type de produit > ensemble de sources principal > dépendances de bibliothèque
Cela permet à Gradle d'utiliser des fichiers spécifiques à la variante de compilation que vous essayez de créer tout en réutilisant les activités, la logique d'application et les ressources communes aux autres versions de votre application.
Lors de la fusion de plusieurs fichiers manifestes, Gradle utilise le même ordre de priorité, de sorte que chaque variante de compilation puisse définir des autorisations ou composants différents dans le fichier manifeste final. Pour en savoir plus sur la création d'ensembles de sources personnalisées, consultez la section Créer des ensembles de sources.
Autres systèmes de compilation
La compilation d'applications Android avec Bazel est possible, mais n'est pas officiellement prise en charge. Android Studio n'est pas officiellement compatible avec les projets Bazel.
Pour mieux comprendre les limites actuelles liées à la compilation avec Bazel, consultez les problèmes connus.