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 les sections 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 builds.
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 la section Structure de compilation Android.
Fichier du wrapper Gradle
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'exécuter le build de manière plus cohérente. Les développeurs téléchargent la source de l'application et exécutent gradlew. La distribution Gradle requise est alors téléchargée, et Gradle est lancé 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 le fichier 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 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 :
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.11.0" apply false id("com.android.library") version "8.11.0" apply false id("org.jetbrains.kotlin.android") version "2.1.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.11.0' apply false id 'com.android.library' version '8.11.0' apply false id 'org.jetbrains.kotlin.android' version '2.1.20' apply false }
Fichier de compilation au niveau du module
Le fichier build.gradle.kts au niveau du module (pour le DSL Kotlin) ou build.gradle (pour le DSL Groovy) 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 script de compilation de premier niveau.
Paramètres du SDK Android
Le fichier de compilation au niveau du module de votre application inclut des paramètres qui indiquent les versions du SDK Android utilisées lors de la compilation, la sélection des comportements de la plate-forme et la spécification de la version minimale sur laquelle votre application s'exécute.
-
compileSdk -
compileSdkdétermine les API Android et Java disponibles lors de la compilation de votre code source. Pour utiliser les dernières fonctionnalités Android, utilisez la dernière version du SDK Android lors de la compilation.Il est possible que certaines API de la plate-forme Android ne soient pas disponibles dans les niveaux d'API plus anciens. Vous pouvez protéger de manière conditionnelle l'utilisation des nouvelles fonctionnalités ou utiliser des bibliothèques de compatibilité AndroidX pour utiliser les nouvelles fonctionnalités avec des niveaux d'API Android inférieurs.
Chaque SDK Android fournit un sous-ensemble d'API Java à utiliser dans votre application. Le tableau de la section Quelles API Java puis-je utiliser dans mon code source Java ou Kotlin ? indique le niveau d'API Java disponible en fonction de la version du SDK Android. Les nouvelles API Java sont compatibles avec les versions antérieures d'Android via le désucrage, qui doit être activé dans votre build.
Android Studio affiche des avertissements si votre
compileSdkest en conflit avec la version actuelle d'Android Studio, d'AGP ou des exigences de dépendance de bibliothèque de votre projet. -
minSdk -
minSdkspécifie la version d'Android la plus ancienne compatible avec votre application. Le paramètreminSdklimite les appareils pouvant installer votre application.La prise en charge de versions antérieures d'Android peut nécessiter davantage de vérifications conditionnelles dans votre code ou une utilisation plus intensive des bibliothèques de compatibilité AndroidX. Vous devez comparer le coût de maintenance de la prise en charge de versions antérieures au pourcentage d'utilisateurs qui utilisent encore ces versions antérieures. Consultez le graphique des versions dans l'assistant de création de projet d'Android Studio pour connaître les pourcentages d'utilisation actuels.
Lorsque vous modifiez votre code dans Android Studio ou exécutez des vérifications lors de la compilation, lint émet un avertissement concernant les API que vous utilisez qui ne sont pas disponibles dans
minSdk. Vous devez les corriger en conditionnant les nouvelles fonctionnalités ou en utilisantAppcompatpour la rétrocompatibilité. -
targetSdk -
targetSdka deux fonctions :- Il définit le comportement d'exécution de votre application.
- Il atteste de la version d'Android sur laquelle vous avez effectué les tests.
Si vous exécutez votre application sur un appareil qui utilise une version d'Android supérieure à celle de votre
targetSdk, Android exécute votre application dans un mode de compatibilité qui se comporte de manière similaire à la version inférieure indiquée dans votretargetSdk. Par exemple, lorsque l'API 23 a introduit le modèle d'autorisations d'exécution, toutes les applications n'étaient pas prêtes à l'adopter immédiatement. En définissanttargetSdksur 22, ces applications pouvaient s'exécuter sur les appareils équipés de l'API 23 sans utiliser d'autorisations d'exécution et pouvaient utiliser les fonctionnalités incluses dans la dernière version decompileSdk. Le règlement sur la distribution de Google Play applique des Règles supplémentaires au niveau de l'API cible.La valeur de
targetSdkdoit être inférieure ou égale à celle decompileSdk.
Remarque : Les valeurs de compileSdk et de targetSdk n'ont pas besoin d'être identiques. Gardez à l'esprit les principes de base suivants :
compileSdkvous permet d'accéder à de nouvelles APItargetSdkdéfinit le comportement d'exécution de votre applicationtargetSdkdoit être inférieur ou égal àcompileSdk
Exemple de script de compilation du module d'application
Cet exemple de script de compilation de module d'application Android présente certains éléments et paramètres DSL de base :
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") } /** * Locate (and possibly download) a JDK used to build your kotlin * source code. This also acts as a default for sourceCompatibility, * targetCompatibility and jvmTarget. Note that this does not affect which JDK * is used to run the Gradle build itself, and does not need to take into * account the JDK version required by Gradle plugins (such as the * Android Gradle Plugin) */ kotlin { jvmToolchain(11) } /** * 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" } } /** * To override source and target compatibility (if different from the * toolchain JDK version), add the following. All of these * default to the same value as kotlin.jvmToolchain. If you're using the * same version for these values and kotlin.jvmToolchain, you can * remove these blocks. */ //compileOptions { // sourceCompatibility = JavaVersion.VERSION_11 // targetCompatibility = JavaVersion.VERSION_11 //} //kotlinOptions { // jvmTarget = "11" //} } /** * 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.7.1") implementation(fileTree(mapOf("dir" to "libs", "include" to listOf("*.jar")))) }
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' } /** * Locate (and possibly download) a JDK used to build your kotlin * source code. This also acts as a default for sourceCompatibility, * targetCompatibility and jvmTarget. Note that this does not affect which JDK * is used to run the Gradle build itself, and does not need to take into * account the JDK version required by Gradle plugins (such as the * Android Gradle Plugin) */ kotlin { jvmToolchain 11 } /** * 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' } } /** * To override source and target compatibility (if different from the * tool chain JDK version), add the following. All of these * default to the same value as kotlin.jvmToolchain. If you're using the * same version for these values and kotlin.jvmToolchain, you can * remove these blocks. */ //compileOptions { // sourceCompatibility JavaVersion.VERSION_11 // targetCompatibility JavaVersion.VERSION_11 //} //kotlinOptions { // jvmTarget = '11' //} } /** * 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.7.1' implementation fileTree(dir: 'libs', include: ['*.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 Android.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.
Catalogues de versions
Si votre build contient plusieurs modules avec des dépendances communes ou si vous avez plusieurs projets indépendants avec des dépendances communes, nous vous recommandons d'utiliser un catalogue de versions ou une nomenclature (BOM) pour spécifier les versions communes.
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.