Plug-in Android Gradle 7.0.0 (juillet 2021)
Le plug-in Android Gradle 7.0.0 est une version majeure qui comprend de nombreux nouveaux et des améliorations.
Version 7.0.1 (août 2021)
Cette mise à jour mineure inclut plusieurs corrections de bugs. Pour consulter la liste des corrections de bugs principaux, lisez le post correspondant sur le <ph type="x-smartling-placeholder"></ph> Blog des mises à jour des versions.
Compatibilité
Version minimale | Version par défaut | |
---|---|---|
Gradle | 7.0.2 | 7.0.2 |
Build Tools SDK | 30.0.2 | 30.0.2 |
NDK | N/A | 21.4.7075529 |
JDK | 11 | 11 |
JDK 11 est requis pour exécuter AGP 7.0
Lorsque vous utilisez le plug-in Android Gradle 7.0 pour compiler votre application, JDK 11 est désormais nécessaires pour exécuter Gradle. Android Studio Arctic Fox inclut JDK 11 et configure Gradle pour l'utiliser par défaut, ce qui signifie que la plupart des applications Android Studio les utilisateurs n'ont pas besoin de modifier la configuration de leurs projets.
Si vous devez définir manuellement le paramètre Version de JDK utilisée par AGP dans Android Studio, vous devez vous servir de JDK 11 ou supérieur.
Si vous utilisez l'AGP indépendamment d'Android Studio, mettez à niveau la version du JDK en
Paramétrez la variable d'environnement JAVA_HOME.
ou l'option de ligne de commande -Dorg.gradle.java.home
.
dans votre répertoire d'installation de JDK 11.
Notez que SDK Manager et AVD Manager dans le package SDK Tools obsolète ne fonctionnent pas avec JDK 11. Pour continuer à utiliser SDK Manager et AVD Manager avec AGP 7.0 ou version ultérieure, vous devez passer aux nouvelles versions des outils dans l'actuel Outils de ligne de commande du SDK Android package.
Variante d'API stable
La nouvelle variante d'API est désormais stable. Découvrez les nouvelles interfaces dans le com.android.build.api.variant. package et les exemples dans projet GitHub gradle-recipes. Dans le cadre du nouveau Variant API, nous avons mis à disposition un certain nombre de fichiers intermédiaires, appelés des artefacts, Artefacts de commande. Ces artefacts, comme le fichier manifeste fusionné, peuvent être obtenus en toute sécurité. et personnalisées à l'aide de plug-ins et de code tiers.
Nous allons continuer à étendre la variante d'API en ajoutant de nouvelles fonctionnalités. et en augmentant le nombre d'artefacts intermédiaires que nous mettons à disposition la personnalisation.
Changements de comportement pour le linting
Cette section décrit plusieurs modifications du comportement de lint dans Android Gradle plug-in 7.0.0.
lint amélioré pour les dépendances de bibliothèque
L'exécution de lint avec checkDependencies = true
est désormais plus rapide
qu'auparavant. Pour les projets Android constitués d'une application avec bibliothèque
nous vous recommandons de définir checkDependencies
sur
true
comme indiqué ci-dessous, et pour exécuter lint via
./gradlew :app:lint
, qui analysera toutes les dépendances
modules en parallèle et génèrent un rapport unique incluant les problèmes
l'application et toutes ses dépendances.
Groovy
// build.gradle
android {
...
lintOptions {
checkDependencies true
}
}
Kotlin
// build.gradle.kts
android {
...
lint {
isCheckDependencies = true
}
}
Les tâches lint peuvent désormais être à jour
Si les sources et les ressources d'un module n'ont pas changé, l'analyse lint
du module n'a pas besoin de s'exécuter à nouveau. Dans ce cas,
l'exécution de la tâche apparaît comme UP-TO-DATE dans Gradle
de sortie. Avec cette modification, lors de l'exécution de lint sur un module d'application avec checkDependencies = true
, seuls les modules qui ont été modifiés
besoin pour exécuter
leur analyse. lint peut ainsi s'exécuter encore plus rapidement.
La tâche de rapport lint n'a pas non plus besoin de s'exécuter si ses entrées n'ont pas été modifié. Un problème connu associé est l'absence de lint sortie de texte imprimée sur stdout lorsque la tâche lint est UP-TO-DATE (problème 191897708).
Exécuter lint sur les modules de fonctionnalités dynamiques
L'AGP ne prend plus en charge l'exécution de lint à partir de modules de fonctionnalités dynamiques.
L'exécution de lint à partir du module d'application correspondant exécute lint sur
ses modules de fonctionnalités dynamiques et incluent tous les problèmes dans le lint de l'application
. Un problème connu associé réside dans le fait que, lors de l'exécution de lint,
avec checkDependencies = true
à partir d'un module d'application,
les dépendances de la bibliothèque de fonctionnalités dynamiques ne sont pas vérifiées, sauf s'il s'agit également
les dépendances (problème
#191977888).
Exécuter lint sur la variante par défaut uniquement
Exécuter ./gradlew :app:lint
n'exécute désormais que lint pour les
variante par défaut. Dans les versions précédentes d'AGP, lint exécutait
.
Avertissements de classe manquante dans le réducteur R8
R8 avec plus de précision
gère de manière cohérente les classes manquantes et l'option -dontwarn
.
Par conséquent, vous devez commencer à évaluer les avertissements de classe manquants émis
par R8.
Lorsque R8 rencontre une référence de classe non définie dans votre application ou l'une de ses dépendances, un avertissement s'affiche dans votre build de sortie. Exemple :
R8: Missing class: java.lang.instrument.ClassFileTransformer
Cet avertissement signifie que la définition de classe
java.lang.instrument.ClassFileTransformer
est introuvable
lors de l'analyse du code de votre application. Bien que cela signifie
généralement qu'il y a une erreur,
vous pouvez ignorer cet avertissement. Deux raisons courantes
pour ignorer l'avertissement sont les suivants:
-
Les bibliothèques qui ciblent la JVM et la classe manquante appartiennent à JVM type de bibliothèque (comme dans l'exemple ci-dessus).
-
L'une de vos dépendances utilise une API au moment de la compilation uniquement.
Vous pouvez ignorer un avertissement de classe manquante en ajoutant un -dontwarn
.
à votre fichier proguard-rules.pro
. Exemple :
-dontwarn java.lang.instrument.ClassFileTransformer
Pour plus de commodité, l'AGP génère un fichier contenant toutes les clés
les règles manquantes, en les écrivant dans un chemin de fichier comme celui-ci:
app/build/outputs/mapping/release/missing_rules.txt
Ajoutez le
à votre fichier proguard-rules.pro
pour ignorer les avertissements.
Dans l'AGP 7.0, les messages de classe manquants apparaîtront comme des avertissements, et vous pourrez
les transformer en erreurs
en définissant
android.r8.failOnMissingClasses = true
po
gradle.properties
Dans l'AGP 8.0, ces avertissements deviendront
qui nuisent à votre build. Il est possible de conserver
le comportement d'AGP 7.0 en
en ajoutant l'option -ignorewarnings
à votre
proguard-rules.pro
, mais cela n'est pas recommandé.
Cache de build du plug-in d'Android Gradle supprimé
Le cache de build de l'AGP a été supprimé dans l'AGP 4.1. Déjà introduit dans AGP 2.3 pour compléter le cache de compilation Gradle, le cache de compilation de l'AGP a été remplacé entièrement par le cache de compilation Gradle dans AGP 4.1. Ce changement n'a aucune incidence la durée de la compilation.
Dans l'AGP 7.0, la propriété android.enableBuildCache
la propriété android.buildCacheDir
et
cleanBuildCache
tâche a été supprimée.
Utiliser le code source de Java 11 dans votre projet
Vous pouvez désormais compiler jusqu'à Java 11 du code source dans le projet de votre application, ce qui permet d'utiliser des fonctionnalités linguistiques plus récentes, telles que les méthodes d'interface privée, pour les classes anonymes et la syntaxe des variables locales pour les paramètres lambda.
Pour activer cette fonctionnalité, définissez compileOptions
sur la valeur
Version de Java, et définissez compileSdkVersion
sur 30 ou une version ultérieure:
// build.gradle
android {
compileSdkVersion 30
compileOptions {
sourceCompatibility JavaVersion.VERSION_11
targetCompatibility JavaVersion.VERSION_11
}
// For Kotlin projects
kotlinOptions {
jvmTarget = "11"
}
}
// build.gradle.kts
android {
compileSdkVersion(30)
compileOptions {
sourceCompatibility(JavaVersion.VERSION_11)
targetCompatibility(JavaVersion.VERSION_11)
}
kotlinOptions {
jvmTarget = "11"
}
}
Configurations de dépendances supprimées
Dans l'AGP 7.0, les configurations (ou niveaux d'accès des dépendances) suivantes ont été supprimé:
-
compile
Selon le cas d'utilisation, cet élément a été remplacé parapi
. ouimplementation
.
S'applique également aux variantes *Compile, commedebugCompile
. -
provided
Cet élément a été remplacé parcompileOnly
.
S'applique également aux variantes *fournies, par exemple:releaseProvided
-
apk
Cet élément a été remplacé parruntimeOnly
. -
publish
Cet élément a été remplacé parruntimeOnly
.
Dans la plupart des cas, l'AGP L'assistant de mise à niveau migrera automatiquement votre projet vers le nouveau de configuration.
Modification du chemin de classe lors de la compilation sur Android Plug-in Gradle
Si vous compilez à l'aide du plug-in Android Gradle, votre compilation
classpath peut changer. Comme AGP utilise désormais api/implementation
configurations en interne, certains artefacts peuvent être supprimés de votre compilation
"classpath". Si vous dépendez d'une dépendance AGP au moment de la compilation, assurez-vous de
l'ajouter en tant que dépendance explicite.
Ajout de bibliothèques natives dans une ressource Java dossier non compatible
Auparavant, vous pouviez ajouter une bibliothèque native dans un dossier de ressources Java.
enregistrer le dossier à l'aide de android.sourceSets.main.resources.srcDirs
afin que la bibliothèque native soit extraite et ajoutée au
APK. À partir de la version 7.0 d'AGP, cela n'est plus pris en charge et les bibliothèques natives dans un
Les dossiers de ressources Java sont ignorés. Utilisez plutôt la méthode DSL
destinée à
bibliothèques natives, android.sourceSets.main.jniLibs.srcDirs
. Pour
Pour en savoir plus, consultez
comment configurer
d'ensembles de sources.
Problèmes connus
Cette section décrit les problèmes connus du plug-in Android Gradle 7.0.0.
Incompatibilité avec le plug-in 1.4.x multiplateforme de Kotlin
Le plug-in Android Gradle 7.0.0 est compatible avec Kotlin Plug-in de multiplateforme 1.5.0 ou version ultérieure. Les projets utilisant le langage Kotlin La compatibilité avec la multiplateforme doit passer à Kotlin 1.5.0 pour utiliser Android Gradle Plugin 7.0.0. Pour contourner ce problème, vous pouvez revenir à une version antérieure du plug-in Android Gradle vers 4.2.x, bien que cela ne soit pas recommandé.
Pour en savoir plus, consultez KT-43944.
Sortie lint manquante
Aucune sortie de texte lint n'est imprimée sur stdout lorsque la tâche lint est à jour (problème 191897708). Pour en savoir plus, consultez Changements de comportement pour lint Ce problème seront corrigés dans la version 7.1 du plug-in Android Gradle.
Les dépendances de la bibliothèque de fonctionnalités dynamiques ne sont pas toutes vérifiées par lint
Lorsque vous exécutez lint avec checkDependencies = true
à partir d'un
le module d'application, les dépendances de la bibliothèque de fonctionnalités dynamiques ne sont pas vérifiées à moins
ce sont aussi des dépendances
d'application
(problème 191977888).
Pour contourner ce problème, vous pouvez exécuter la tâche lint sur ces bibliothèques. Pour plus de contexte,
consultez la section Changements de comportement pour lint.