Le syst�me de compilation Android compile des ressources d'application et du code source, puis les empaquette dans des APK ou des Android App Bundles (AAB) que vous pouvez tester, d�ployer, signer et distribuer.
Android�Studio utilise Gradle, une bo�te � outils de compilation avanc�e, pour automatiser et g�rer le processus de compilation, tout en vous permettant de d�finir des configurations de compilation personnalis�es flexibles. Chaque configuration de compilation peut d�finir son propre ensemble de code et de ressources, tout en r�utilisant les parties communes � toutes les versions de votre application. Le plug-in Android�Gradle fonctionne avec le kit d'outils de compilation pour fournir des processus et des param�tres configurables sp�cifiques � la compilation et aux tests des applications Android.
Gradle et le plug-in Android�Gradle s'ex�cutent ind�pendamment d'Android�Studio. Cela signifie que vous pouvez compiler vos applications Android � partir d'Android�Studio, de la ligne de commande sur votre ordinateur ou sur des ordinateurs sur lesquels Android�Studio n'est pas install�, comme des serveurs d'int�gration continue.
Si vous n'utilisez pas Android�Studio, d�couvrez comment cr�er et ex�cuter votre application � partir de la ligne de commande. Que vous compiliez un projet � partir de la ligne de commande, sur une machine distante ou � l'aide d'Android�Studio, le r�sultat de la compilation est le m�me.
Remarque�: �tant donn� que Gradle et le plug-in Android�Gradle s'ex�cutent ind�pendamment d'Android�Studio, vous devez mettre � jour les outils de compilation s�par�ment. Consultez les notes de version pour d�couvrir comment mettre � jour Gradle et le plug-in Android�Gradle.
Gr�ce � la souplesse du syst�me de compilation Android, vous pouvez effectuer des configurations de compilation personnalis�es sans avoir � modifier les fichiers sources principaux de votre application. Cette page vous aide � comprendre le fonctionnement du syst�me de compilation Android, ainsi que la fa�on dont il peut vous aider � personnaliser et automatiser plusieurs configurations de compilation. Pour en savoir plus sur le d�ploiement de votre application, consultez la section Compiler et ex�cuter votre application. Pour commencer � cr�er imm�diatement des configurations de compilation personnalis�es � l'aide d'Android�Studio, consultez la section Configurer des variantes de compilation.
Processus de compilation
Le processus de compilation comporte de nombreux outils et processus qui convertissent votre projet en Android Application Bundle (APK) ou Android App�Bundle (AAB).
Le plug-in Android�Gradle effectue la majeure partie du processus de compilation pour vous. Toutefois, il peut �tre utile de comprendre certains aspects de ce processus afin que vous puissiez l'ajuster pour r�pondre � vos besoins.
Les projets peuvent avoir des objectifs de compilation diff�rents. Par exemple, la compilation d'un une biblioth�que tierce g�n�re une archive Android (AAR) ou Java Archive (JAR) biblioth�ques. Cependant, une application est le type de projet le plus courant, et la compilation d'un projet d'application g�n�re un APK ou un AAB "debug" ou "release" de votre application que vous pouvez d�ployer, tester ou publier aupr�s des utilisateurs externes.
Cette page se concentre sur le d�veloppement d'applications, mais une grande partie des �tapes et des concepts de compilation est commune � la plupart des types de compilation.
Glossaire de compilation Android
Gradle et le plug-in Android�Gradle vous aident � configurer les aspects suivants de votre build�:
- Types de compilation
-
Les types de compilation d�finissent certaines propri�t�s que Gradle utilise lors de la cr�ation et du packaging de votre application. Ils sont g�n�ralement configur�s pour diff�rentes �tapes de votre cycle de d�veloppement.
Par exemple, le type de compilation "debug" active les options de d�bogage et signe l'application avec la cl� de d�bogage, tandis que le type de compilation "release" peut r�duire, obscurcir et signer votre application avec une cl� de release en vue de la distribution.
Vous devez d�finir au moins un type de compilation pour pouvoir compiler votre application. Android�Studio cr�e les types de compilation "debug" et "release" par d�faut. Pour commencer � personnaliser les param�tres de packaging de votre application, d�couvrez comment configurer les types de compilation.
- Types de produit
- Les types de produit repr�sentent diff�rentes versions de votre application que vous pouvez proposer aux utilisateurs, telles que des versions gratuites et payantes. Vous pouvez personnaliser les types de produits pour qu'ils utilisent des ressources et du code diff�rents, tout en partageant et en r�utilisant les parties communes � toutes les versions de votre application. Les types de produit sont facultatifs. Vous devez les cr�er manuellement. Pour commencer � cr�er diff�rentes versions de votre application, d�couvrez comment configurer les types de produit.
- Variantes de compilation
- Une variante de compilation est un produit crois� d'un type de compilation et d'un type de produit. Il s'agit de la configuration que Gradle utilise pour cr�er votre application. Les variantes de compilation vous permettent de cr�er la version de d�bogage de vos types de produit pendant le d�veloppement ou les versions sign�es de ces types pour les distribuer. Bien que vous ne configuriez pas directement les variantes de compilation, vous configurez les types de compilation et les types de produit dont elles sont constitu�es. La cr�ation de types de compilation ou de produit suppl�mentaires entra�ne �galement la cr�ation de variantes de compilation. Pour apprendre � cr�er et � g�rer des variantes de compilation, consultez la pr�sentation Configurer des variantes de compilation.
- Entr�es du fichier manifeste
- Vous pouvez sp�cifier des valeurs pour certaines propri�t�s du fichier manifeste dans la configuration de la variante de compilation. Ces valeurs de compilation remplacent les valeurs existantes dans le fichier manifeste. Cela s'av�re utile si vous souhaitez g�n�rer plusieurs variantes de votre application avec une version de SDK minimale, une version de SDK cible ou un nom d'application diff�rent. Lorsque plusieurs fichiers manifestes sont pr�sents, l'outil de fusion de fichiers manifestes fusionne leurs param�tres.
- D�pendances
- Le syst�me de compilation g�re les d�pendances du projet � partir de votre syst�me de fichiers local et des d�p�ts distants. Vous n'avez donc pas besoin de rechercher, t�l�charger ni copier manuellement les packages binaires de vos d�pendances dans le r�pertoire de votre projet. Pour en savoir plus, consultez Ajouter des d�pendances de compilation.
- Signature
- Le syst�me de compilation vous permet de sp�cifier des param�tres de signature dans la configuration de compilation. De plus, il peut signer automatiquement votre application lors du processus de compilation. Le syst�me de compilation signe la version de d�bogage avec une cl� et un certificat par d�faut � l'aide d'identifiants connus pour �viter une invite de saisie du mot de passe au moment de la compilation. Il ne signe pas la version de release, sauf si vous d�finissez explicitement une configuration de signature pour ce build. Si vous ne disposez pas de cl� de publication, vous pouvez en g�n�rer une comme d�crit dans la section Signer votre application. Les builds sign�s sont requis pour la distribution des applications via la plupart des plates-formes de t�l�chargement d'applications.
- Minification du code et des ressources
- Le syst�me de compilation vous permet de sp�cifier un fichier de r�gles ProGuard diff�rent pour chaque variante de compilation. Lors de la compilation de votre application, le syst�me de compilation applique l'ensemble de r�gles appropri� pour r�duire votre code et vos ressources � l'aide de ses outils de r�duction int�gr�s tels que R8. La minification de votre code et de vos ressources peut vous aider � r�duire la taille de votre fichier APK ou AAB.
- Prendre en charge plusieurs fichiers APK
- Le syst�me de compilation vous permet de compiler automatiquement diff�rents APK ne contenant chacun que le code et les ressources n�cessaires pour une densit� d'�cran ou une interface binaire d'application (ABI) sp�cifiques. Pour en savoir plus, consultez Compiler plusieurs fichiers APK. Cependant, la publication d'un seul fichier AAB est l'approche recommand�e, car elle permet une division par langue en plus de la densit� d'�cran et de l'ABI, tout en �vitant d'avoir � importer plusieurs artefacts sur Google�Play. Toutes les nouvelles applications envoy�es apr�s ao�t�2021 devront utiliser des AAB.
Versions de Java dans les builds Android
Que votre code source soit �crit en Java, en Kotlin ou les deux, vous devez choisir un langage JDK ou Java � plusieurs endroits pour votre build. Consultez les versions de Java dans les builds Android. pour en savoir plus.
Fichiers de configuration de compilation
Pour cr�er des configurations de compilation personnalis�es, vous devez modifier un ou plus de fichiers de configuration de compilation. Ces de texte brut utilisent le langage sp�cifique au domaine (DSL, Domain Specific Language) pour d�crire et manipuler la logique de compilation Script Kotlin qui est un type de langage Kotlin. Vous pouvez �galement utiliser Groovy, dynamique pour la machine virtuelle Java (JVM) afin de configurer vos compilations.
Vous n'avez pas besoin de conna�tre le script Kotlin ni Groovy pour commencer � configurer build, car le plug-in Android Gradle introduit la plupart des �l�ments DSL dont vous avez besoin. Pour en savoir plus sur le DSL du plug-in Android Gradle, consultez le Documentation de r�f�rence DSL Le script Kotlin s'appuie �galement sur sous-jacentes DSL Kotlin Gradle.
Lorsque vous d�marrez un nouveau projet, Android Studio crée automatiquement certains ces fichiers pour vous et les remplit en fonction de valeurs par défaut raisonnables. Le projet présente la mise en page suivante:
└── MyApp/ # Project
├── gradle/
│ └── wrapper/
│ └── gradle-wrapper.properties
├── build.gradle(.kts)
├── settings.gradle(.kts)
└── app/ # Module
│ ├── build.gradle(.kts)
│ ├── build/
│ ├── libs/
│ └── src/
│ └── main/ # Source set
│ ├── java/
│ │ └── com.example.myapp
│ ├── res/
│ │ ├── drawable/
│ │ ├── values/
│ │ └── ...
│ └── AndroidManifest.xml
Certains fichiers de configuration de compilation Gradle font partie de la structure de projet standard d'une application Android. Avant de commencer à configurer votre build, il est important de comprendre le champ d'application et la finalité de chacun de ces fichiers, ainsi que les éléments DSL de base qu'ils définissent.
Fichier Gradle Wrapper
Le wrapper Gradle (gradlew) est une petite application incluse dans votre
qui télécharge et lance Gradle lui-même.
Cela crée une exécution de compilation plus cohérente. Les développeurs téléchargent
source de l'application et exécuter gradlew. Le fichier Gradle requis est alors téléchargé
et lance Gradle pour créer votre application.
Le fichier gradle/wrapper/gradle-wrapper.properties
contient une propriété, distributionUrl, qui décrit la version de
Gradle permet d'exécuter votre build.
distributionBase=GRADLE_USER_HOME
distributionPath=wrapper/dists
distributionUrl=https\://services.gradle.org/distributions/gradle-8.0-bin.zip
zipStoreBase=GRADLE_USER_HOME
zipStorePath=wrapper/dists
Fichier des paramètres Gradle
Le fichier settings.gradle.kts (pour le DSL Kotlin) ou
Le fichier settings.gradle (pour le DSL Groovy) se trouve à la racine
dans le répertoire du projet. Ce fichier de paramètres définit le dépôt au niveau du projet
et indique � Gradle les modules qu'il doit inclure lors de la compilation de votre
l'application. Les projets multimodules doivent sp�cifier chaque module devant acc�der au
le build final.
Pour la plupart des projets, ce fichier se pr�sente comme suit par d�faut�:
Kotlin
pluginManagement {
/**
* The pluginManagement.repositories block configures the
* repositories Gradle uses to search or download the Gradle plugins and
* their transitive dependencies. Gradle pre-configures support for remote
* repositories such as JCenter, Maven Central, and Ivy. You can also use
* local repositories or define your own remote repositories. The code below
* defines the Gradle Plugin Portal, Google's Maven repository,
* and the Maven Central Repository as the repositories Gradle should use to look for its
* dependencies.
*/
repositories {
gradlePluginPortal()
google()
mavenCentral()
}
}
dependencyResolutionManagement {
/**
* The dependencyResolutionManagement.repositories
* block is where you configure the repositories and dependencies used by
* all modules in your project, such as libraries that you are using to
* create your application. However, you should configure module-specific
* dependencies in each module-level build.gradle file. For new projects,
* Android Studio includes Google's Maven repository and the Maven Central
* Repository by default, but it does not configure any dependencies (unless
* you select a template that requires some).
*/
repositoriesMode.set(RepositoriesMode.FAIL_ON_PROJECT_REPOS)
repositories {
google()
mavenCentral()
}
}
rootProject.name = "My Application"
include(":app")
Groovy
pluginManagement {
/**
* The pluginManagement.repositories block configures the
* repositories Gradle uses to search or download the Gradle plugins and
* their transitive dependencies. Gradle pre-configures support for remote
* repositories such as JCenter, Maven Central, and Ivy. You can also use
* local repositories or define your own remote repositories. The code below
* defines the Gradle Plugin Portal, Google's Maven repository,
* and the Maven Central Repository as the repositories Gradle should use to look for its
* dependencies.
*/
repositories {
gradlePluginPortal()
google()
mavenCentral()
}
}
dependencyResolutionManagement {
/**
* The dependencyResolutionManagement.repositories
* block is where you configure the repositories and dependencies used by
* all modules in your project, such as libraries that you are using to
* create your application. However, you should configure module-specific
* dependencies in each module-level build.gradle file. For new projects,
* Android Studio includes Google's Maven repository and the Maven Central
* Repository by default, but it does not configure any dependencies (unless
* you select a template that requires some).
*/
repositoriesMode.set(RepositoriesMode.FAIL_ON_PROJECT_REPOS)
repositories {
google()
mavenCentral()
}
}
rootProject.name = "My Application"
include ':app'
Fichier de compilation de premier niveau
Le fichier build.gradle.kts de premier niveau (pour le DSL Kotlin) ou
Le fichier build.gradle (pour le DSL Groovy) se trouve � la racine
dans le r�pertoire du projet. Il d�finit g�n�ralement les versions courantes des plug-ins utilis�s
par modules de votre projet.
L'exemple de code suivant d�crit les param�tres et les �l�ments DSL par d�faut dans le script de compilation de premier niveau apr�s avoir cr�� un projet:
Kotlin
plugins {
/**
* Use `apply false` in the top-level build.gradle file to add a Gradle
* plugin as a build dependency but not apply it to the current (root)
* project. Don't use `apply false` in sub-projects. For more information,
* see Applying external plugins with same version to subprojects.
*/
id("com.android.application") version "8.6.0" apply false
id("com.android.library") version "8.6.0" apply false
id("org.jetbrains.kotlin.android") version "1.9.23" apply false
}
Groovy
plugins {
/**
* Use `apply false` in the top-level build.gradle file to add a Gradle
* plugin as a build dependency but not apply it to the current (root)
* project. Don't use `apply false` in sub-projects. For more information,
* see Applying external plugins with same version to subprojects.
*/
id 'com.android.application' version '8.6.0' apply false
id 'com.android.library' version '8.6.0' apply false
id 'org.jetbrains.kotlin.android' version '1.9.23' apply false
}
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 -
compileSdkd�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
compileSdkavec la version actuelle d'Android Studio, d'AGP ou de la biblioth�que de votre projet ; les exigences de d�pendance. -
minSdk -
minSdksp�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>Appcompatpour assurer la r�trocompatibilit�. -
targetSdk -
Le
targetSdka 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 votretargetSdkPar 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�finisseztargetSdksur 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
targetSdkdoit �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:
compileSdkvous donne acc�s � de nouvelles APItargetSdkd�finit le comportement de votre application lors de l'ex�cutiontargetSdkdoit �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.
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.