Plug-in Android Gradle 7.0.0 (juillet 2021)

Le plug-in Android Gradle 7.0.0 est une version majeure qui comprend plusieurs nouvelles fonctionnalités et améliorations.

Compatibilité

JDK 11 est requis pour exécuter AGP 7.0

Si vous utilisez le plug-in Android Gradle 7.0 pour compiler votre application, JDK 11 est désormais nécessaire pour exécuter Gradle. Arctic Fox d'Android Studio inclut JDK 11 et configure Gradle pour l'utiliser par défaut. La plupart des utilisateurs d'Android Studio n'ont donc pas besoin de modifier la configuration de leurs projets.

Si vous devez définir manuellement la version de JDK utilisée par l'AGP dans Android Studio, vous devez utiliser JDK version 11 ou ultérieure.

Lorsque vous utilisez l'AGP indépendamment d'Android Studio, mettez à niveau la version du JDK en définissant 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 dans le package obsolète SDK Tools, SDK Manager et AVD Manager ne fonctionnent pas avec JDK 11. Pour continuer à utiliser SDK Manager et AVD Manager avec l'AGP 7.0 ou une version ultérieure, vous devez passer aux nouvelles versions des outils dans le package actuel d'outils de ligne de commande du SDK Android.

Variante d'API stable

La nouvelle variante d'API est désormais stable. Découvrez les nouvelles interfaces du package com.android.build.api.variant et les exemples du projet GitHub gradle-recipes. Dans la nouvelle Variante d'API, nous avons mis à disposition un certain nombre de fichiers intermédiaires, appelés artefacts, via l'interface Artefacts. Ces artefacts, comme le fichier manifeste fusionné, peuvent être obtenus et personnalisés en toute sécurité à l'aide de plug-ins et de code tiers.

Nous continuerons à développer l'API Variant en ajoutant de nouvelles fonctionnalités et en augmentant le nombre d'artefacts intermédiaires que nous mettons à disposition pour la personnalisation.

Changements de comportement pour le linting

Cette section décrit plusieurs modifications de comportement de lint dans la version 7.0.0 du plug-in Android Gradle.

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 des dépendances de bibliothèque, il est recommandé de définir checkDependencies sur true, comme indiqué ci-dessous, et d'exécuter lint via ./gradlew :app:lint, qui analysera tous les modules de dépendance en parallèle et générera un rapport unique incluant les problèmes de l'application et de toutes ses dépendances.

// build.gradle
android {
  ...
  lintOptions {
    checkDependencies true
  }
}

// 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é, la tâche d'analyse lint pour ce module n'a pas besoin d'être exécutée à nouveau. Dans ce cas, l'exécution de la tâche apparaît comme à jour (UP-TO-DATE) dans la sortie Gradle. Avec cette modification, lorsque vous exécutez lint sur un module d'application avec checkDependencies = true, seuls les modules qui ont été modifiés doivent exécuter leur analyse. lint peut ainsi s'exécuter encore plus rapidement.

De plus, la tâche de rapport lint ne doit pas être exécutée si ses entrées n'ont pas changé. Un problème connu lié est l'absence de sortie de texte lint imprimée sur stdout lorsque la tâche lint est à jour (problème n° 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 se produit sur ses modules de fonctionnalités dynamiques et inclut tous les problèmes du rapport lint de l'application. Un problème connu lié est 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 caractéristiques dynamiques ne sont pas vérifiées, sauf s'il s'agit également de dépendances d'applications (problème n° 191977888).

Exécuter lint sur la variante par défaut uniquement

Exécuter ./gradlew :app:lint ne concerne désormais plus que la variante par défaut. Dans les versions précédentes de l'AGP, lint se serait exécuté sur toutes les variantes.

Avertissements de classe manquante dans le réducteur R8

R8 gère de manière plus précise et cohérente les classes manquantes et l'option -dontwarn. Vous devez donc 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 ni dans l'une de ses dépendances, un avertissement s'affiche dans le résultat de compilation. Par 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 indique généralement une erreur, vous pouvez ignorer cet avertissement. Voici deux raisons courantes pour ignorer l'avertissement:

1. Les bibliothèques qui ciblent JVM et la classe manquante sont de type Bibliothèque JVM (comme dans l'exemple ci-dessus).

2. 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 une règle -dontwarn à votre fichier proguard-rules.pro. Par exemple :

-dontwarn java.lang.instrument.ClassFileTransformer

Pour plus de commodité, l'AGP génère un fichier contenant toutes les règles potentiellement manquantes en les répertoriant dans un chemin de fichier comme celui-ci : app/build/outputs/mapping/release/missing_rules.txt. Ajoutez les règles à votre fichier proguard-rules.pro pour ignorer les avertissements.

Dans l'AGP 7.0, les messages de classe manquants apparaîtront en tant qu'avertissements. Vous pouvez les transformer en erreurs en définissant android.r8.failOnMissingClasses = true dans gradle.properties. Dans l'AGP 8.0, ces avertissements deviendront des erreurs et nuiront à votre build. Il est possible de conserver le comportement de l'AGP 7.0 en ajoutant l'option -ignorewarnings à votre fichier 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. Précédemment introduit dans l'AGP 2.3 pour compléter le cache de compilation Gradle, le cache de compilation de l'AGP a été entièrement remplacé par le cache de compilation Gradle dans l'AGP 4.1. Ce changement n'a pas d'incidence sur la durée de la compilation.

Dans l'AGP 7.0, les propriétés android.enableBuildCache, android.buildCacheDir et la tâche cleanBuildCache ont été supprimées.

Utiliser le code source de Java 11 dans votre projet

Vous pouvez désormais compiler du code source jusqu'à Java 11 dans le projet de votre application, ce qui vous permet d'utiliser des fonctionnalités de langage plus récentes telles que des méthodes d'interface privée, l'opérateur losange pour les classes anonymes et la syntaxe de variable locale pour les paramètres lambda.

Pour activer cette fonctionnalité, définissez compileOptions sur la version Java souhaitée et définissez compileSdkVersion sur 30 ou plus:

// 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 champs d'application de dépendances) suivantes ont été supprimées:

• compile
  Selon le cas d'utilisation, cet élément a été remplacé par api ou implementation.
  S'applique également aux variantes *Compile, comme debugCompile.
• provided
  Remplacé par compileOnly.
  S'applique également aux variantes *fournies, comme releaseProvided.
• apk
  Remplacé par runtimeOnly.
• publish
  Remplacé par runtimeOnly.

Dans la plupart des cas, l'assistant de mise à niveau AGP migre automatiquement votre projet vers les nouvelles configurations.

Modification du classpath lors de la compilation du plug-in Android Gradle

Si vous compilez le plug-in Android Gradle, le classpath de compilation peut changer. Comme l'AGP utilise désormais les configurations api/implementation en interne, certains artefacts peuvent être supprimés du classpath de compilation. Si vous dépendez d'une dépendance de l'AGP au moment de la compilation, veillez à l'ajouter en tant que dépendance explicite.

Ajout de bibliothèques natives dans un dossier de ressources Java non pris en charge

Auparavant, vous pouviez ajouter une bibliothèque native dans un dossier de ressources Java et enregistrer ce dossier à l'aide de android.sourceSets.main.resources.srcDirs afin que la bibliothèque native soit extraite et ajoutée à l'APK final. Cela n'est plus pris en charge à partir de la version 7.0 de l'AGP, et les bibliothèques natives d'un dossier de ressources Java sont ignorées. Utilisez plutôt la méthode DSL destinée aux bibliothèques natives, android.sourceSets.main.jniLibs.srcDirs. Pour en savoir plus, consultez la section Configurer des 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 le plug-in multiplateforme Kotlin 1.5.0 ou version ultérieure. Les projets compatibles avec Kotlin multiplateforme doivent passer à Kotlin 1.5.0 pour utiliser le plug-in Android Gradle 7.0.0. Pour contourner ce problème, vous pouvez revenir à la version 4.2.x du plug-in Android Gradle, bien que cela ne soit pas recommandé.

Pour en savoir plus, consultez KT-43944.

Sortie lint manquante

Aucune sortie de texte lint imprimée 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 sera résolu dans le plug-in Android Gradle 7.1.

Les dépendances de la bibliothèque de fonctionnalités dynamiques ne sont pas toutes vérifiées par lint

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 de 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 en savoir plus, consultez la section Changements de comportement pour lint.