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.5.0" apply false id("com.android.library") version "8.5.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.5.0' apply false id 'com.android.library' version '8.5.0' apply false id 'org.jetbrains.kotlin.android' version '1.9.23' apply false }
Fichier de compilation au niveau du module
Le build.gradle.kts
au niveau du module (pour le DSL Kotlin) ou
le fichier build.gradle
(pour le DSL Groovy) se trouve dans chaque
project/module/
. Il vous permet de configurer les paramètres de compilation du module dans lequel il se trouve. Configurer
ces paramètres de compilation vous permettent 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 dans
Fichier manifeste d'application main/
ou 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 Versions du SDK Android utilisées lors de la compilation et de la sélection des comportements de la plate-forme en spécifiant la version minimale sur laquelle votre application s'exécute.
-
compileSdk
-
compileSdk
détermine les API Android et Java qui sont disponibles lors de la compilation de votre code source. Pour utiliser la dernière version d'Android , utilisez le dernier SDK Android lors de la compilation.Il est possible que certaines API de la plate-forme Android ne soient pas disponibles dans les anciens niveaux d'API. Vous pouvez <ph type="x-smartling-placeholder"></ph> protéger sous condition l'utilisation de fonctionnalités plus récentes ou l'utilisation <ph type="x-smartling-placeholder"></ph> Bibliothèques de compatibilité AndroidX pour utiliser des fonctionnalités plus récentes avec des Niveaux d'API Android
Chaque SDK Android fournit un sous-ensemble d'API Java à utiliser dans votre application. Le tableau de 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 désucrage, qui doit être activé dans votre build.
Android Studio affiche des avertissements en cas de conflit entre
compileSdk
avec la version actuelle d'Android Studio, d'AGP ou de la bibliothèque de votre projet ; les exigences de dépendance. -
minSdk
-
minSdk
spécifie la version d'Android la plus récente souhaitez que votre application soit prise en charge. Si vous définissezminSdk
, peuvent installer votre application.La prise en charge des versions antérieures d'Android peut nécessiter des vérifications plus conditionnelles dans votre code ou toute autre utilisation des bibliothèques de compatibilité AndroidX. Vous devez évaluer le coût de maintenance lié à la prise en charge des versions antérieures le pourcentage d'utilisateurs qui se servent encore de ces versions antérieures. Consultez le graphique de version dans l'assistant de création de projet d'Android Studio pour les pourcentages d'utilisation de la version actuelle.
Lorsque vous modifiez votre code dans Android Studio ou effectuez des vérifications pendant votre build, lint vous avertit que les API que vous utilisez ne sont pas disponibles dans
minSdk
. Vous devez les corriger d'ici le <ph type="x-smartling-placeholder"></ph> en rendant les nouvelles fonctionnalités conditionnelles ou en utilisant <ph type="x-smartling-placeholder"></ph>Appcompat
pour assurer la rétrocompatibilité. -
targetSdk
-
Le
targetSdk
a une double finalité:- Il définit le comportement de votre application lors de l'exécution.
- Il atteste de la version d'Android avec laquelle le test a été effectué.
Si votre appareil est équipé d'une version supérieure d'Android votre
targetSdk
, Android exécute votre application en mode de compatibilité qui se comporte de la même manière que la version antérieure indiquée dans votretargetSdk
Par exemple, lorsque l'API 23 a introduit l'environnement d'exécution d'autorisation, mais toutes les applications n'étaient pas prêtes à l'adopter immédiatement. Si vous définisseztargetSdk
sur 22, ces applications pourraient s'exécuter sur Appareils utilisant l'API 23 sans autorisation d'exécution et qui pourraient utiliser des fonctionnalités inclus dans la dernière version decompileSdk
. Google Play la règle de distribution applique des règles supplémentaires sur le niveau d'API cible.La valeur de
targetSdk
doit être inférieure ou égale à à celle decompileSdk
.
Remarque:Les valeurs de compileSdk
et targetSdk
n'ont pas besoin d'être identiques. Gardez à l'esprit les principes de base suivants:
compileSdk
vous donne accès à de nouvelles APItargetSdk
définit le comportement de votre application lors de l'exécutiontargetSdk
doit être inférieur ou égal àcompileSdk
Exemple de script de compilation de module d'application
Cet exemple de script de compilation de module d'application Android présente des é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.0") 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.0' 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:\
génère 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 le
barre de notification qui s'affiche lorsque vous effectuez une modification, comme illustré dans
figure 1, ou cliquez sur Sync Project (Synchroniser le projet) .
dans la barre de menus. Si Android Studio détecte des erreurs dans votre
configuration. Par exemple, votre code source utilise des fonctionnalités d'API qui ne sont
disponible à un niveau d'API supérieur à votre
compileSdkVersion
la fenêtre Messages décrit le problème.
![](https://developer.android.com/static/images/tools/as-gradlesync.png?hl=fr)
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. Un module
L'ensemble de sources main/
inclut le code et les ressources utilisés par tous ses
des 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 plusieurs projets indépendants avec des dépendances communes, nous vous recommandons vous utilisez catalogue de versions ou nomenclature, spécifier les versions communes.
Autres systèmes de compilation
Créer des applications Android avec Bazel possible mais pas officiellement prise en charge. Android Studio ne fournit pas pour les projets Bazel.
Pour mieux comprendre les limites actuelles liées à la compilation avec Bazel, consultez les problèmes connus.