Plug-in Android Gradle 7.1.0 (janvier 2022)

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

Compatibilité

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

Le AndroidLintAnalysisTask est désormais compatible avec le Gradle cache de build. Si vous activez le cache de build en définissant org.gradle.caching=true dans votre gradle.properties fichier, la tâche d'analyse lint obtient sa sortie du cache de build quand c'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 si vous disposez par exemple 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 un code C/C++ peut désormais être configuré pour référencer des fichiers d'en-tête et un 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.

Conditions requises

• 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 fichier build.gradle dependencies block. Exemple :

dependencies {
  implementation project(':mylibrary')
}

• Le module de publication doit exposer un package à l'aide d' prefab section. 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. 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 modules de consommation et de publication d'AAR natifs avec l'AGP, consultez Dépendances natives avec l'AGP.

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

Lorsqu'un nouveau projet est créé dans Android Studio Bumblebee, le fichier de niveau supérieur build.gradle 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 niveau supérieur 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é. Utilisez donc les fichiers build.gradle de niveau supérieur et le fichier settings.gradle pour définir les 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'intégration par défaut du réducteur de ressources d'Android a été mise à jour dans le plug-in d'Android Gradle version 7.1.0-alpha09. La nouvelle intégration 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 intégration de réducteurs de ressources permet de réduire davantage la taille de votre application en modifiant le tableau des ressources pour supprimer les ressources de valeur inutilisées et les références aux ressources de valeur inutilisées. Le nouveau réducteur de ressources peut complètement supprimer les ressources de fichiers inutilisées, ce qui réduit encore la taille de votre application. Ce comportement n'est pas encore activé par défaut, mais vous pouvez l'activer en ajoutant l'option (en test) 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'intégration 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 répercussion à prévoir au moment de l'exécution.

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

Publication de la variante de compilation

Le plug-in version 7.1.0 ou supérieure d'Android Gradle 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 et supérieures 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 singleVariant ou multipleVariants bloc de publication. Pour en savoir plus, consultez l 'exemple de code des options de publication.

Publier les sources JAR

L'AGP version 7.1.0 et supérieures vous permet de publier des fichiers JAR de 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 des options de publication.

Modification sémantique de bloc lint

Toutes les méthodes lint qui ignorent le niveau de sévérité d'un problème (enable, disable/ignore, informational, warning, error, fatal) respectent à présent 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 lint{} documents de référence concernant le bloc, 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 le Navigation Safe Args Gradle plugin dépendent 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 le 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 supérieures.

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 cette dernière, et un composant all contenant toutes les variantes de build. 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 et antérieures du plug-in Gradle de Firebase Performance Monitoring. L'assistant de mise à niveau de l'AGP ne mettra pas automatiquement à jour le plug-in vers la version 1.4.1. Si vous utilisez firebase-perf et que vous souhaitez passer à la version 7.1, vous devez effectuer manuellement cette mise à niveau.

Problèmes connus

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

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 au moment d'exécuter des tests unitaires.

Ce problème sera résolu avec la version 7.1.1. Consultez le problème n° 213534628.