Plug-in Android Gradle 7.1.0 (janvier 2022)

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

Compatibilité

	Version minimale	Version par défaut
Gradle	7.2	7.2
Build Tools SDK	30.0.3	30.0.3
NDK	N/A	21.4.7075529
JDK	11	11

La tâche d'analyse lint peut désormais être mise en cache

AndroidLintAnalysisTask est désormais compatible avec le cache de build Gradle. Si vous activez le cache de build en définissant org.gradle.caching=true dans votre fichier gradle.properties, la tâche d'analyse lint obtient sa sortie du cache de build lorsque cela est possible.

La tâche d'analyse lint est souvent le plus grand goulot d'étranglement lors de l'exécution de lint avec le plug-in Android Gradle. Activer le cache de build permet donc souvent d'améliorer la vitesse de compilation lors de l'exécution de lint. Vous devriez constater une amélioration notable des performances, par exemple si vous disposez d'un projet multimodule et que vous nettoyez votre répertoire de compilation avant d'exécuter lint sur votre serveur CI.

Les modules C/C++ peuvent désormais référencer d'autres modules C/C++ du même projet

Un module Gradle pour Android avec du code C/C++ peut désormais être configuré pour référencer des fichiers d'en-tête et le code de bibliothèque dans un autre module Gradle. Le protocole Prefab permet de communiquer les en-têtes et les bibliothèques entre les modules Gradle.

Exigences

• Le module de consommation doit être CMake et non ndk-build. La compatibilité avec ndk-build nécessitera une mise à jour NDK ultérieure. Le module de publication peut être CMake ou ndk-build.

• Le module de consommation doit activer prefab dans le fichier build.gradle.

android {
  buildFeatures {
    prefab true
  }
}

• Le module de publication doit activer prefabPublishing dans le fichier build.gradle.

android {
  buildFeatures {
    prefabPublishing true
  }
}

• Le module de consommation doit référencer le module de publication en ajoutant une ligne dans le bloc dependencies du fichier build.gradle. Par exemple :

dependencies {
  implementation project(':mylibrary')
}

• Le module de publication doit exposer un package à l'aide d'une section prefab. Par exemple :

android {
  prefab {
    mylibrary {
      libraryName "libmylibrary"
      headers "src/main/cpp/include"
    }
  }
}

• Le fichier CMakeLists.txt du module de consommation peut utiliser find_package() pour localiser le package publié par le module de production. Par exemple :

find_package(mylibrary REQUIRED CONFIG)
target_link_libraries(
  myapplication
  mylibrary::mylibrary)

• Il doit y avoir un STL pour l'ensemble de l'application. Ainsi, les modules de consommation et de publication peuvent par exemple utiliser des STL partagées en C++.

   android {
      defaultConfig {
        externalNativeBuild {
          cmake {
            arguments '-DANDROID_STL=c++_shared'
          }
        }
      }
    }

Pour en savoir plus sur la configuration des consommateurs et des producteurs d'AAR natifs avec l'AGP, consultez la section Dépendances natives avec l'AGP.

Paramètres de dépôt dans le fichier settings.gradle

Lorsqu'un projet est créé dans Android Studio Bumblebee, le fichier build.gradle de premier niveau contient le bloc plugins, suivi du code permettant de nettoyer le répertoire de compilation:

plugins {
    id 'com.android.application' version '7.1.0-beta02' apply false
    id 'com.android.library' version '7.1.0-beta02' apply false
    id 'org.jetbrains.kotlin.android' version '1.5.30' apply false
}
task clean(type: Delete) {
  delete rootProject.buildDir
}

Les paramètres de dépôt qui étaient auparavant dans le fichier build.gradle de premier niveau se trouvent désormais dans le fichier settings.gradle:

pluginManagement {
  repositories {
    gradlePluginPortal()
    google()
    mavenCentral()
  }
}
dependencyResolutionManagement {
  repositoriesMode.set(RepositoriesMode.FAIL_ON_PROJECT_REPOS)
  repositories {
    google()
    mavenCentral()
  }
}
rootProject.name = 'GradleManagedDeviceTestingNew'
include ':app'

Le fichier build.gradle au niveau du module n'a pas changé. Vous devez donc utiliser le fichier build.gradle de premier niveau et le fichier settings.gradle pour définir des configurations de compilation qui s'appliquent à tous les modules de votre projet, ou les dépôts et dépendances qui s'appliquent à Gradle lui-même. Utilisez le fichier build.gradle au niveau du module pour définir des configurations de compilation spécifiques à un module donné de votre projet.

Réducteur de ressources amélioré

Android Studio Bumblebee inclut un réducteur de ressources amélioré qui permet de réduire la taille de votre application.

Compatibilité des applications comportant des fonctionnalités dynamiques

L'implémentation par défaut du réducteur de ressources Android a été mise à jour dans le plug-in Android Gradle 7.1.0-alpha09. La nouvelle implémentation prend en charge la réduction d'applications comportant des fonctionnalités dynamiques.

Réductions supplémentaires pour les tailles d'applications (en test)

La nouvelle implémentation de réducteur de ressources peut encore réduire la taille de votre application en modifiant la table des ressources pour supprimer les ressources de valeur inutilisées et les références à des ressources de fichiers inutilisées. Le nouveau réducteur de ressources peut complètement supprimer les ressources de fichiers inutilisées, ce qui réduit davantage la taille de votre application. Ce comportement n'est pas encore activé par défaut, mais vous pouvez l'activer en ajoutant l'option android.experimental.enableNewResourceShrinker.preciseShrinking=true au fichier gradle.properties de votre projet.

Veuillez signaler tout problème rencontré avec le nouveau réducteur de ressources ou l'indicateur expérimental. Pour diagnostiquer ou contourner temporairement les problèmes, vous pouvez revenir à l'implémentation précédente en ajoutant android.enableNewResourceShrinker=false au gradle.properties de votre projet. Le nouveau réducteur remplace les ressources basées sur des fichiers inutilisées par des fichiers minimaux légèrement différents de ceux du précédent, sans incidence sur l'exécution.

La suppression de l'ancienne implémentation est planifiée dans la version 8.0.0 du plug-in Android Gradle.

Publication de la variante de compilation

Le plug-in Android Gradle 7.1.0 ou version ultérieure vous permet de configurer les variantes de compilation à publier dans un dépôt Apache Maven. L'AGP crée un composant avec une ou plusieurs variantes de compilation basées sur le nouveau DSL de publication, que vous pouvez utiliser pour personnaliser une publication dans un dépôt Maven. Par rapport aux versions précédentes, cela évite également des tâches inutiles, car aucun composant n'est créé par défaut. Pour en savoir plus, consultez l'exemple de code de publication.

Publier le fichier JAR Javadoc

L'AGP version 7.1.0 ou ultérieure vous permet de générer Javadoc à partir de sources Java et Kotlin et de publier des fichiers JAR Javadoc en plus d'AAR pour les projets Bibliothèque. Le fichier Javadoc est ajouté aux fichiers POM et de métadonnées du module Gradle{:.external}. Activez cette fonctionnalité en ajoutant withJavadocJar() dans le bloc de publication singleVariant ou multipleVariants. Pour en savoir plus, consultez l'exemple de code pour les options de publication.

Publier les sources JAR

L'AGP version 7.1.0 et ultérieures vous permet de publier des fichiers JAR sources Java et Kotlin en plus d'AAR pour les projets Bibliothèque. Les sources sont ajoutées aux fichiers POM et de métadonnées du module Gradle{:.external}. Vous pouvez activer cette fonctionnalité en ajoutant withSourcesJar() au bloc de publication singleVariant ou multipleVariants. Pour en savoir plus, consultez l'exemple de code pour les options de publication.

Modification sémantique de bloc lint

Toutes les méthodes lint qui ignorent le niveau de gravité d'un problème (enable, disable/ignore, informational, warning, error, fatal) respectent désormais l'ordre de la configuration. Par exemple, si vous définissez un problème comme fatal dans finalizeDsl(), il sera désormais désactivé dans le DSL principal. Pour en savoir plus, consultez les documents de référence sur le bloc lint{}, ainsi que le flux de compilation et les points d'extension Android.

Compatibilité avec le plug-in Safe Args de Navigation

Les API de l'AGP dont dépend le plug-in Gradle pour Navigation Safe Args ont été supprimées. L'AGP 7.1 ne fonctionne pas avec les versions 2.4.0-rc1 ou 2.4.0 de Navigation Safe Args, mais fonctionne avec les versions 2.5.0-alpha01 et 2.4.1. En attendant, pour contourner ce problème, vous pouvez utiliser l'AGP 7.1 avec un build d'instantané pour Navigation Safe Args, Navigation 2.5.0-SNAPSHOT. Pour utiliser le build d'instantané, suivez les instructions d'instantané avec l'ID de build n° 8054565.

En outre, les versions 2.4.1 et 2.5.0 de Navigation Safe Args ne fonctionneront plus avec l'AGP 4.2. Pour utiliser ces versions de Safe Args, vous devez utiliser l'AGP version 7.0 ou ultérieure.

Désactiver la création automatique de composants

À partir de la version 8.0 de l'AGP, la création automatique de composants est désactivée par défaut. Actuellement, l'AGP 7.1 crée automatiquement un composant pour chaque variante de compilation, qui porte le même nom que celle-ci, et un composant all contenant toutes les variantes de compilation. La création automatique de composants sera désactivée. Pour passer au nouveau comportement, vous devez désactiver manuellement la création automatique de composants en définissant android.disableAutomaticComponentCreation sur true.. Pour en savoir plus, consultez Utiliser le plug-in Maven Publish.

Compatibilité avec Firebase Performance Monitoring

L'AGP 7.1 n'est pas compatible avec la version 1.4.0 ou antérieure du plug-in Gradle de Firebase Performance Monitoring. L'assistant de mise à niveau de l'AGP ne met pas automatiquement à jour le plug-in vers la version 1.4.1. Par conséquent, si vous utilisez firebase-perf et que vous souhaitez mettre à niveau AGP vers la version 7.1, vous devez effectuer cette mise à niveau manuellement.

Problèmes connus

Cette section décrit les problèmes connus du plug-in Android Gradle 7.1.0.

Problèmes liés aux unités testant un projet d'application avec le plug-in Hilt

Le classpath du test unitaire contient les classes d'application non instrumentées, ce qui signifie que Hilt n'instrumente pas les classes d'application pour gérer l'injection de dépendances lors de l'exécution de tests unitaires.

Ce problème sera résolu dans la version 7.1.1 (voir le problème 213534628).