Le plug-in Android Gradle 4.0 est compatible avec l'utilisation de Kotlin dans votre build Gradle. en remplacement de Groovy, le langage de programmation généralement utilisés dans les fichiers de configuration Gradle.
Il est préférable d'utiliser Kotlin plutôt que Groovy pour écrire des scripts Gradle, car Kotlin est plus lisible, et offre une meilleure vérification au moment de la compilation et une meilleure prise en charge de l'IDE.
Bien que Kotlin offre actuellement une meilleure intégration dans le code d'Android Studio par rapport à Groovy, les compilations utilisant Kotlin ont tendance à être plus lentes à l'aide de Groovy. Vous devez donc tenir compte des performances migrer.
Cette page fournit des informations de base sur la conversion du format Fichiers de compilation Gradle de Groovy à Kotlin. Pour une migration plus complète consultez la documentation documentation officielle.
Vos trajets
À partir d'Android Studio Giraffe, les nouveaux projets utilisent le DSL Kotlin
(build.gradle.kts
) par défaut pour la configuration de compilation. Cela offre une meilleure
que le DSL Groovy (build.gradle
) avec une syntaxe
la mise en surbrillance du code,
la complétion de code et la navigation vers les déclarations. Pour en savoir plus,
consultez les
Introduction au DSL Kotlin Kotlin
Termes courants
DSL Kotlin : fait principalement référence au DSL Kotlin du plug-in Android Gradle ou, occasionnellement, au DSL Kotlin Gradle sous-jacent.
Dans ce guide de migration, "Kotlin" et "DSL Kotlin" sont utilisés de manière interchangeable. De même, "Groovy" et "Groovy DSL" sont utilisés de manière interchangeable.
Dénomination des fichiers de script
Les noms des extensions de fichier de script sont basés sur le langage dans lequel le fichier de compilation est écrit :
- Les fichiers de compilation Gradle écrits en Groovy utilisent l'extension de nom de fichier
.gradle
. - Les fichiers de compilation Gradle écrits en Kotlin utilisent l'extension de nom de fichier
.gradle.kts
.
Convertir la syntaxe
Il existe des différences générales de syntaxe entre Groovy et Kotlin. Vous devez donc appliquer ces modifications à vos scripts de compilation.
Ajouter des parenthèses aux appels de méthode
Groovy vous permet d'omettre les parenthèses dans les appels de méthode, tandis que Kotlin les exige. Pour migrer votre configuration, ajoutez des parenthèses à ces types d'appels de méthode. Ce code montre comment configurer un paramètre en Groovy :
compileSdkVersion 30
Voici le même code écrit en Kotlin :
compileSdkVersion(30)
Ajouter =
aux appels d'attribution
Le DSL Groovy vous permet d'omettre l'opérateur d'affectation =
lorsque
en attribuant des propriétés, alors que Kotlin l'exige. Ce code montre comment attribuer des propriétés en Groovy :
java {
sourceCompatibility JavaVersion.VERSION_17
targetCompatibility JavaVersion.VERSION_17
}
Ce code montre comment attribuer des propriétés en Kotlin :
java {
sourceCompatibility = JavaVersion.VERSION_17
targetCompatibility = JavaVersion.VERSION_17
}
Convertir les chaînes
Voici les différences de chaîne entre Groovy et Kotlin :
- Guillemets doubles pour les chaînes : alors que Groovy permet de définir des chaînes à l'aide de guillemets simples, Kotlin nécessite des guillemets doubles.
-
Interpolation de chaîne sur les expressions en pointillés : en Groovy, vous pouvez simplement utiliser le préfixe
$
pour les interpolations de chaîne sur les expressions en pointillés, mais Kotlin nécessite d'encapsuler ces expressions avec des accolades. Par exemple, en Groovy, vous pouvez utiliser$project.rootDir
comme indiqué dans l'extrait suivant :myRootDirectory = "$project.rootDir/tools/proguard-rules-debug.pro"
En langage Kotlin, cependant, le code précédent appelle
toString()
surproject
, et non surproject.rootDir
. Pour obtenir la valeur du répertoire racine, encapsulez l'expression${project.rootDir}
avec des accolades :myRootDirectory = "${project.rootDir}/tools/proguard-rules-debug.pro"
Pour en savoir plus, consultez la section Modèles de chaîne dans la documentation Kotlin.
Renommer les extensions de fichier
Ajoutez .kts
à chaque fichier de compilation lorsque vous migrez son contenu. Par exemple, sélectionnez un fichier de compilation, comme le fichier settings.gradle
. Renommer le fichier en
settings.gradle.kts
et convertir le contenu du fichier en Kotlin. Assurez-vous que la compilation du projet se poursuit après la migration de chaque fichier de compilation.
Migrez d'abord vos fichiers les plus petits, gagnez en expérience, puis attelez-vous aux fichiers de plus grande envergure. Vous pouvez comme des fichiers de compilation Kotlin et Groovy dans un projet, prenez le temps faire le changement avec prudence.
Remplacez def
par val
ou var
.
Remplacez def
par val
ou var
, ce qui est la façon dont les variables sont définies en Kotlin.
Voici une déclaration de variable en Groovy :
def building64Bit = false
Voici le même code écrit en Kotlin :
val building64Bit = false
Ajouter le préfixe is
aux propriétés booléennes
Groovy utilise une logique de déduction des propriétés
en fonction des noms des propriétés. Pour une propriété booléenne foo
, ses méthodes déduites peuvent être getFoo
, setFoo
ou isFoo
. Une fois convertis en Kotlin, ces noms de propriété doivent être remplacés par les méthodes déduites qui ne sont pas compatibles avec Kotlin. Par exemple, pour les éléments booléens DSL buildTypes
, vous devez leur ajouter le préfixe is
. Ce code montre comment définir des propriétés booléennes en Groovy :
android {
buildTypes {
release {
minifyEnabled true
shrinkResources true
...
}
debug {
debuggable true
...
}
...
Voici le même code en Kotlin. Notez que les propriétés sont précédées par is
.
android {
buildTypes {
getByName("release") {
isMinifyEnabled = true
isShrinkResources = true
...
}
getByName("debug") {
isDebuggable = true
...
}
...
Convertir les listes et les cartes
Les listes et les cartes Groovy sont définies à l'aide d'une syntaxe différente à celle de Kotlin. Groovy utilise []
, tandis que Kotlin appelle explicitement les méthodes de création de collections à l'aide de listOf
ou de mapOf
. Veillez à remplacer []
par listOf
ou mapOf
lors de la migration.
Voici comment définir une liste en Groovy par rapport à Kotlin :
jvmOptions += ["-Xms4000m", "-Xmx4000m", "-XX:+HeapDumpOnOutOfMemoryError</code>"]
Voici le même code écrit en Kotlin :
jvmOptions += listOf("-Xms4000m", "-Xmx4000m", "-XX:+HeapDumpOnOutOfMemoryError")
Voici comment définir une carte en Groovy par rapport à Kotlin :
def myMap = [key1: 'value1', key2: 'value2']
Voici le même code écrit en Kotlin :
val myMap = mapOf("key1" to "value1", "key2" to "value2")
Configurer les types de compilation
Dans le langage DSL Kotlin, seuls les types de version "release" et "debug" sont disponibles implicitement. Tous les autres types de compilation personnalisés doivent être créés manuellement.
En Groovy, vous pouvez utiliser "release", "debug" et d'autres types de compilation sans avoir à les créer au préalable. L'extrait de code suivant montre une configuration avec les types de compilation debug
, release
et benchmark
en Groovy.
buildTypes {
debug {
...
}
release {
...
}
benchmark {
...
}
}
Pour créer la configuration équivalente en Kotlin, vous devez créer explicitement la classe
Type de compilation benchmark
.
buildTypes {
debug {
...
}
release {
...
}
register("benchmark") {
...
}
}
Migrer du bloc buildscript vers le bloc plugins
Si votre build utilise le
buildscript {}
pour ajouter des plug-ins au projet, vous devez refactoriser le fichier pour utiliser
plugins {}
. Le bloc plugins {}
facilite l'application de plug-ins.
fonctionne bien avec
les catalogues de versions.
De plus, lorsque vous utilisez le bloc plugins {}
dans vos fichiers de compilation,
Android Studio tient compte du contexte même en cas d'échec de la compilation. Ce contexte
permet de corriger vos fichiers DSL Kotlin, car il permet à l'IDE Studio de
effectuer la saisie semi-automatique du code
et fournir d'autres suggestions utiles.
Trouver les ID de plug-in
Alors que le bloc buildscript {}
ajoute les plug-ins au chemin de classe de compilation à l'aide de
la
Coordonnées Maven
du plug-in, par exemple com.android.tools.build:gradle:7.4.0
,
le bloc plugins {}
utilise à la place les ID de plug-in.
Pour la plupart des plug-ins, l'ID de plug-in est la chaîne utilisée lorsque vous les appliquez à l'aide de
apply plugin
Par exemple, les ID de plug-in suivants font partie
Plug-in Android Gradle:
com.android.application
com.android.library
com.android.lint
com.android.test
Vous trouverez la liste complète des plug-ins dans le Dépôt Maven de Google
Les plug-ins Kotlin peuvent être référencés par plusieurs ID de plug-in. Nous vous recommandons d'utiliser ID du plug-in en espace de noms et refactorisation du raccourci vers l'ID du plug-in avec espace de noms à l'aide de tableau suivant:
Raccourcir les ID de plug-in | ID de plug-in en espace de noms |
---|---|
kotlin |
org.jetbrains.kotlin.jvm |
kotlin-android |
org.jetbrains.kotlin.android |
kotlin-kapt |
org.jetbrains.kotlin.kapt |
kotlin-parcelize |
org.jetbrains.kotlin.plugin.parcelize |
Vous pouvez également rechercher des plug-ins Portail du plug-in Gradle le dépôt central Maven et Dépôt Maven de Google Lue Développer des plug-ins Gradle personnalisés pour en savoir plus sur le fonctionnement des ID de plug-in.
Effectuer la refactorisation
Une fois que vous connaissez les ID des plug-ins que vous utilisez, procédez comme suit:
Si vous avez toujours des dépôts pour les plug-ins déclarés dans le fichier
buildscript {}
, déplacez-les vers lesettings.gradle
.Ajoutez les plug-ins au bloc
plugins {}
dans le répertoire racinebuild.gradle
. Vous devez spécifier l'ID et le du plug-in. Si le plug-in n'a pas besoin au projet racine, utilisezapply false
.Supprimez les entrées
classpath
du fichierbuild.gradle.kts
de premier niveau.Appliquez les plug-ins en les ajoutant au bloc
plugins {}
dans la section fichierbuild.gradle
au niveau du module. Il vous suffit de spécifier le paramètre ID ici, car la version est héritée du projet racine.Supprimez l'appel
apply plugin
pour le plug-in au niveau du module.build.gradle
.
Par exemple, cette configuration utilise le bloc buildscript {}
:
// Top-level build.gradle file
buildscript {
repositories {
google()
mavenCentral()
gradlePluginPortal()
}
dependencies {
classpath("com.android.tools.build:gradle:7.4.0")
classpath("org.jetbrains.kotlin:kotlin-gradle-plugin:1.8.0")
...
}
}
// Module-level build.gradle file
apply(plugin: "com.android.application")
apply(plugin: "kotlin-android")
Voici une configuration équivalente qui utilise le bloc plugins {}
:
// Top-level build.gradle file
plugins {
id 'com.android.application' version '7.4.0' apply false
id 'org.jetbrains.kotlin.android' version '1.8.0' apply false
...
}
// Module-level build.gradle file
plugins {
id 'com.android.application'
id 'org.jetbrains.kotlin.android'
...
}
// settings.gradle
pluginManagement {
repositories {
google()
mavenCentral()
gradlePluginPortal()
}
}
Convertir le bloc "plugins"
L'application de plug-ins à partir du bloc plugins {}
est similaire en Groovy et en Kotlin.
Le code suivant montre comment appliquer des plug-ins en Groovy lorsque vous utilisez
catalogues de versions:
// Top-level build.gradle file
plugins {
alias libs.plugins.android.application apply false
...
}
// Module-level build.gradle file
plugins {
alias libs.plugins.android.application
...
}
Le code suivant montre comment faire la même chose en Kotlin :
// Top-level build.gradle.kts file
plugins {
alias(libs.plugins.android.application) apply false
...
}
// Module-level build.gradle.kts file
plugins {
alias(libs.plugins.android.application)
...
}
Le code suivant montre comment appliquer des plug-ins en Groovy lorsque vous n'êtes pas à l'aide des catalogues de versions:
// Top-level build.gradle file
plugins {
id 'com.android.application' version '7.3.0' apply false
...
}
// Module-level build.gradle file
plugins {
id 'com.android.application'
...
}
Le code suivant montre comment faire la même chose en Kotlin :
// Top-level build.gradle.kts file
plugins {
id("com.android.application") version "7.3.0" apply false
...
}
// Module-level build.gradle.kts file
plugins {
id("com.android.application")
...
}
Pour en savoir plus sur le bloc plugins {}
, consultez Appliquer
plug-ins
dans la documentation Gradle.
Divers
Pour obtenir des exemples de code Kotlin pour d'autres fonctionnalités, consultez les pages de documentation suivantes :
- Si vous disposez d'une configuration ProGuard, reportez-vous à la section Activer la minification, l'obscurcissement et l'optimisation.
- Si vous disposez d'un bloc
signingConfig {}
, consultez Supprimer les informations de signature de vos fichiers de compilation. - Si vous utilisez des propriétés à l'échelle du projet, consultez la section Configurer les propriétés à l'échelle du projet.
Problèmes connus
À l'heure actuelle, un problème connu la vitesse de compilation peut être plus lente avec Kotlin qu'avec Groovy.
Signaler des problèmes
Pour découvrir comment nous fournir les informations dont nous avons besoin pour catégoriser votre problème, consultez Informations supplémentaires pour les bugs dans Gradle et les outils de compilation. Signalez ensuite un bug à l'aide de l'outil public de suivi des problèmes de Google.
Autres ressources
Pour obtenir un exemple pratique de fichiers de compilation Gradle écrits en Kotlin, consultez la Application exemple Now In Android sur GitHub.