Plug-in Android Gradle 4.1.0 (août 2020)

Compatibilité

<p>This version of the Android plugin requires the following:</p>
<ul>
  <li>
    <p><a href="https://docs.gradle.org/6.5.1/release-notes.html">Gradle 6.5</a>.
    To learn more, read the section about <a href="#updating-gradle">updating
    Gradle</a>.</p>
  </li>
  <li>
    <p><a href="/studio/releases/build-tools.html#notes">SDK Build Tools
    29.0.2</a> or higher.</p>
  </li>
</ul>
<p>The default NDK version in this release is 21.1.6352462. To install a
different NDK version, see <a href="/studio/projects/install-ndk#specific-version">Install a specific version of the NDK</a>.</p>

Nouvelles fonctionnalités

Cette version du plug-in d'Android Gradle inclut les nouvelles fonctionnalités suivantes.

Compatibilité avec le script DSL de Kotlin

Afin d'améliorer l'expérience de modification pour les utilisateurs de buildscript Kotlin, le DSL et les API du plug-in Android Gradle 4.1 sont désormais définis dans un ensemble d'interfaces Kotlin indépendamment de leurs classes d'implémentation. Voici les conséquences de ce changement :

• Désormais, les types Kotlin peuvent être explicitement de valeur nulle et modifiables.
• Les documents générés à partir de ces interfaces sont publiés dans les documents de référence de l'API Kotlin.
• La surface de l'API du plug-in Android Gradle est clairement définie, ce qui permet de renforcer l'extension de builds Android à l'avenir.

Important : Si vous avez déjà adopté les scripts de build KTS ou si vous utilisez Kotlin dans buildSrc, cela peut entraîner des problèmes de compatibilité de la source pour certaines erreurs pouvant se manifester en tant qu'erreurs d'exécution dans les versions précédentes.

Les types de collections conçus pour être transformés dans le DSL sont désormais définis de manière uniforme comme suit :

val collection: MutableCollectionType

Cela signifie qu'il n'est plus possible d'écrire les éléments suivants dans les scripts Kotlin pour certaines collections qui les acceptaient auparavant :

collection = collectionTypeOf(...)

Toutefois, la mutation de la collection étant prise en charge de manière uniforme, collection += … et collection.add(...) devraient désormais fonctionner partout.

Si vous rencontrez des problèmes lorsque vous mettez à niveau un projet qui utilise le DSL et les API Kotlin du plug-in Android Gradle, veuillez signaler un bug.

Exporter des dépendances C/C++ à partir d'AAR

Le plug-in Android Gradle 4.0 permet d'importer des packages Prefab dans des dépendances AAR. Avec l'AGP 4.1, il est maintenant possible d'exporter des bibliothèques depuis votre build natif externe vers un fichier AAR pour un projet de bibliothèque Android.

Pour exporter vos bibliothèques natives, ajoutez le code suivant au bloc android du fichier build.gradle de votre projet de bibliothèque :

buildFeatures {
    prefabPublishing true
}


prefab {
    <var>mylibrary</var&;gt {
      headers "src/main/cpp/<var>mylibrary</var>/include"
    }
<var>myotherlibrary</var> {
    headers "src/main/cpp/<var>myotherlibrary</var>/include"
}

}
      
buildFeatures {
    prefabPublishing = true
}


prefab {
    create("<var>mylibrary</var>") {
      headers = "src/main/cpp/<var>mylibrary</var>/include"
    }
create("<var>myotherlibrary</var>") {
    headers = "src/main/cpp/<var>myotherlibrary</var>/include"
}

}
      

Dans cet exemple, les bibliothèques mylibrary et myotherlibrary de votre build natif externe ndk-build ou CMake seront empaquetées dans l'AAR produite par votre build, et chacune exportera les en-têtes à partir du répertoire spécifié vers leurs dépendances.

Remarque : Pour les utilisateurs du plug-in Android Gradle 4.0 ou version ultérieure, les paramètres de configuration pour importer des bibliothèques natives prédéfinies ont changé. Pour en savoir plus, consultez les notes de la version 4.0.

Compatibilité R8 avec les métadonnées Kotlin

Kotlin utilise des métadonnées personnalisées dans les fichiers de classe Java pour identifier les constructions en langage Kotlin. R8 est désormais compatible avec la maintenance et la réécriture des métadonnées de Kotlin afin de permettre la réduction complète des bibliothèques et des applications Kotlin à l'aide de kotlin-reflect.

Pour conserver les métadonnées de Kotlin, ajoutez les règles de conservation suivantes :

-keep class kotlin.Metadata { *; }


-keepattributes RuntimeVisibleAnnotations

Vous indiquez ainsi à R8 de garder les métadonnées Kotlin de toutes les classes directement conservées.

Pour en savoir plus, consultez Shrinking Kotlin libraries and applications using Kotlin reflection with R8{:.external} (Réduire les bibliothèques et les applications Kotlin à l'aide de la réflexion Kotlin avec R8) sur Medium.

Assertions dans les versions de débogage

Lorsque vous créez la version de débogage de votre application à l'aide du plug-in version Android Gradle 4.1.0 ou version ultérieure, le compilateur intégré (D8) réécrit le code de votre application pour activer les assertions au moment de la compilation, de sorte que vous ayez toujours des vérifications d'assertion actives.

Changements de comportement

Cache de build du plug-in d'Android Gradle supprimé

Le cache de compilation 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 aucun effet sur la durée de la compilation.

La tâche cleanBuildCache ainsi que les propriétés android.enableBuildCache et android.buildCacheDir sont obsolètes et seront supprimées de la version 7.0 de l'AGP. La propriété android.enableBuildCache n'a actuellement aucun effet, tandis que la propriété android.buildCacheDir et la tâche cleanBuildCache continueront de fonctionner jusqu'à la version 7.0 de l'AGP pour supprimer le contenu d'un cache de compilation de l'AGP existant.

Réduction significative de la taille des applications utilisant la minification de code

À partir de cette version, les champs des classes R ne sont plus conservés par défaut, ce qui peut réduire considérablement la taille des APK pour les applications qui autorisent la minification de code. Cela ne devrait pas entraîner de changement de comportement, sauf si vous accédez par réflexion aux classes R, auquel cas il est nécessaire d'ajouter des règles de conservation pour ces classes.

Propriété android.namespacedRClass renommée android.nonTransitiveRClass

L'indicateur expérimental android.namespacedRClass a été renommé android.nonTransitiveRClass.

Défini dans le fichier gradle.properties, cet indicateur active l'espace de noms de la classe R de chaque bibliothèque, de sorte que cette classe n'inclut que les ressources déclarées dans la bibliothèque elle-même et non dans ses dépendances, ce qui réduit la taille de la classe R de cette bibliothèque.

DSL Kotlin : coreLibraryDesugaringEnabled renommé

L'option de compilation du DSL Kotlin coreLibraryDesugaringEnabled a été remplacée par isCoreLibraryDesugaringEnabled. Pour en savoir plus sur cet indicateur, consultez Compatibilité du désucrage d'API avec Java 8 ou version ultérieure (plug-in Android Gradle 4.0.0 et versions ultérieures).

Propriétés de version supprimées de la classe BuildConfig dans les projets de bibliothèque

Dans les projets de bibliothèque uniquement, les propriétés BuildConfig.VERSION_NAME et BuildConfig.VERSION_CODE ont été supprimées de la classe BuildConfig générée, car ces valeurs statiques ne reflétaient pas les valeurs finales de code et de nom de la version de l'application. Par conséquent, elles étaient trompeuses. De plus, ces valeurs ont été supprimées lors de la fusion du fichier manifeste.

Dans une prochaine version du plug-in Android Gradle, les propriétés versionName et versionCode seront également supprimées du DSL pour les bibliothèques. Il n'existe actuellement aucun moyen d'accéder automatiquement au code ou au nom de la version de l'application à partir d'un sous-projet de la bibliothèque.

Pour les modules d'application, il n'y a aucun changement, vous pouvez toujours attribuer des valeurs à versionCode et versionName dans le DSL. Ces valeurs sont propagées dans le fichier manifeste et dans les champs BuildConfig de l'application.

Définir le chemin d'accès du NDK

Vous pouvez définir le chemin d'accès à l'emplacement où le NDK est installé en local à l'aide de la propriété android.ndkPath dans le fichier build.gradle de votre module.

android {
  ndkPath "your-custom-ndk-path"
}

android {
  ndkPath = "your-custom-ndk-path"
}

Si vous utilisez cette propriété avec la propriété android.ndkVersion, ce chemin doit contenir une version du NDK correspondant à android.ndkVersion.

Modifications du comportement des tests unitaires de la bibliothèque

Nous avons modifié le comportement de compilation et d'exécution des tests unitaires de la bibliothèque. Les tests unitaires d'une bibliothèque sont désormais compilés et exécutés sur les classes de compilation/d'exécution de la bibliothèque elle-même. Le test unitaire se sert donc de la bibliothèque de la même manière que les sous-projets externes. Cette configuration permet généralement d'améliorer les tests.

Il arrive que les tests unitaires des bibliothèques qui utilisent la liaison de données rencontrent des classes DataBindingComponent ou BR manquantes. Ces tests doivent être transférés vers un test d'instrumentation dans le projet androidTest, car la compilation et l'exécution sur ces classes dans un test unitaire peuvent produire un résultat incorrect.

Plug-in io.fabric de Gradle obsolète

Le plug-in io.fabric de Gradle est obsolète et n'est pas compatible avec la version 4.1 du plug-in Android Gradle. Pour en savoir plus sur le SDK Fabric obsolète et sur la migration vers le SDK Firebase Crashlytics, consultez Mise à niveau vers le SDK Firebase Crashlytics.