Plug-in Android Gradle 3.0.0 (octobre 2017)

Le plug-in Android Gradle 3.0.0 inclut différentes modifications visant à résoudre les problèmes de performances des projets de grande envergure.

Par exemple, sur un exemple de squelette de projet avec environ 130 modules et un grand nombre de dépendances externes (mais sans code ni ressources), vous pouvez enregistrer une amélioration des performances comme suit :

Certaines de ces modifications font planter les builds existants. Vous devez donc prendre en compte
les efforts de migration de votre projet avant d'utiliser le nouveau plug-in.

Si vous n'avez pas constaté les améliorations de performances décrites ci-dessus, veuillez signaler un bug et inclure une trace de votre build à l'aide du profileur Gradle.

Cette version du plug-in Android nécessite les éléments suivants :

• Gradle 4.1 ou version ultérieure. Pour en savoir plus, consultez la section sur la mise à jour de Gradle.
• Build Tools 26.0.2 ou version ultérieure. Avec cette mise à jour, il n'est plus nécessaire de préciser une version spécifique pour les outils de compilation, car le plug-in utilise par défaut la version minimale requise. Vous pouvez donc supprimer la propriété android.buildToolsVersion.

Optimisations

• Amélioration du parallélisme pour les projets multimodules grâce à un graphique de tâches précis.
• Lorsque vous modifiez une dépendance, Gradle effectue des builds plus rapides en ne recompilant pas les modules qui n'ont pas accès à l'API de cette dépendance. Vous devez limiter les dépendances qui divulguent leurs API à d'autres modules en utilisant les nouvelles configurations de dépendances de Gradle : implementation, api, compileOnly et runtimeOnly.
• Compilation incrémentielle plus rapide grâce à la conversion au format .dex par classe. Chaque classe est désormais compilée dans des fichiers DEX distincts, et seules les classes modifiées sont à nouveau converties au format .dex. La vitesse de compilation devrait être améliorée pour les applications qui définissent minSdkVersion sur 20 ou moins, et qui utilisent l'ancien multidex.
• Amélioration de la vitesse de compilation en optimisant certaines tâches afin d'utiliser des résultats mis en cache. Pour bénéficier de cette optimisation, vous devez d'abord activer le cache de build Gradle.
• Amélioration du traitement incrémentiel des ressources avec AAPT2, qui est désormais activé par défaut. Si vous rencontrez des problèmes lors de l'utilisation d'AAPT2, veuillez signaler un bug. Vous pouvez également désactiver AAPT2 en définissant android.enableAapt2=false dans votre fichier gradle.properties, puis en redémarrant le daemon Gradle en exécutant ./gradlew --stop à partir de la ligne de commande.

Nouvelles fonctionnalités

• Gestion des dépendances avec variantes. Désormais, lorsque vous compilez une variante spécifique d'un module, le plug-in met automatiquement en correspondance les variantes des dépendances du module de la bibliothèque locale avec la variante du module en cours de compilation.
• Inclut un nouveau plug-in de module de fonctionnalité compatible avec les applis instantanées Android et leur SDK (que vous pouvez télécharger via SDK Manager). Pour en savoir plus sur la création de modules de fonctionnalités avec le nouveau plug-in, consultez Structure d'une appli instantanée avec plusieurs fonctionnalités.
• Prise en charge intégrée de l'utilisation de certaines fonctionnalités du langage Java 8 et bibliothèques Java 8. Jack est désormais obsolète et n'est plus obligatoire. Vous devez d'abord désactiver Jack pour utiliser la prise en charge Java 8 améliorée intégrée dans la chaîne d'outils par défaut. Pour en savoir plus, consultez Utiliser les fonctionnalités du langage Java 8.

• Possibilité d'exécuter des tests avec Android Test Orchestrator, ce qui vous permet d'exécuter chacun des tests de votre application dans son propre appel d'instrumentation. Étant donné que chaque test s'exécute dans sa propre instance d'instrumentation, les états partagés entre les tests ne s'accumulent pas sur le processeur ou la mémoire de votre appareil. De plus, même si un test plante, il ne supprime que sa propre instance de l'instrumentation. Vos autres tests continuent donc de s'exécuter.

  • Ajout de testOptions.execution pour déterminer si vous devez utiliser l'orchestration de tests sur l'appareil. Si vous souhaitez utiliser Android Test Orchestrator, vous devez spécifier ANDROID_TEST_ORCHESTRATOR, comme indiqué ci-dessous. Par défaut, cette propriété est définie sur HOST, ce qui désactive l'orchestration sur l'appareil et constitue la méthode standard d'exécution de tests.

  Groovy

          android {
            testOptions {
              execution 'ANDROID_TEST_ORCHESTRATOR'
            }
          }
          

  Kotlin

          android {
            testOptions {
              execution = "ANDROID_TEST_ORCHESTRATOR"
            }
          }
          

• La nouvelle configuration de dépendance androidTestUtil vous permet d'installer un autre APK d'assistance de test, tel qu'Android Test Orchestrator, avant d'exécuter vos tests d'instrumentation :

  Groovy

          dependencies {
            androidTestUtil 'com.android.support.test:orchestrator:1.0.0'
            ...
          }
          

  Kotlin

          dependencies {
            androidTestUtil("com.android.support.test:orchestrator:1.0.0")
            ...
          }
          

• Ajout de testOptions.unitTests.includeAndroidResources pour prendre en charge les tests unitaires nécessitant des ressources Android, comme RoboElectric. Lorsque vous définissez cette propriété sur true, le plug-in effectue la fusion des ressources, des éléments et des fichiers manifestes avant d'exécuter vos tests unitaires. Vos tests peuvent alors examiner com/android/tools/test_config.properties sur le classpath pour trouver les clés suivantes :

  • android_merged_assets : Chemin d'accès absolu au répertoire des éléments fusionnés.

    Remarque : Pour les modules de bibliothèque, les éléments fusionnés ne contiennent pas les éléments des dépendances (voir le problème 65550419).

  • android_merged_manifest : Chemin d'accès absolu au manifeste fusionné.

  • android_merged_resources : Chemin d'accès absolu au répertoire de ressources fusionné, qui contient toutes les ressources du module et de toutes ses dépendances.

  • android_custom_package : nom de package de la classe R finale. Si vous modifiez l'ID application de manière dynamique, il se peut que ce nom de package ne corresponde pas à l'attribut package dans le fichier manifeste de l'application.

• Prise en charge des polices comme ressources (nouvelle fonctionnalité introduite dans Android 8.0 (niveau d'API 26)).
• Prise en charge des APK spécifiques à la langue avec le SDK Applis instantanées Android 1.1 et versions ultérieures.

• Vous pouvez maintenant modifier le répertoire de sortie pour votre projet de compilation natif externe, comme indiqué ci-dessous :

  Groovy

          android {
              ...
              externalNativeBuild {
                  // For ndk-build, instead use the ndkBuild block.
                  cmake {
                      ...
                      // Specifies a relative path for outputs from external native
                      // builds. You can specify any path that's not a subdirectory
                      // of your project's temporary build/ directory.
                      buildStagingDirectory "./outputs/cmake"
                  }
              }
          }
          

  Kotlin

          android {
              ...
              externalNativeBuild {
                  // For ndk-build, instead use the ndkBuild block.
                  cmake {
                      ...
                      // Specifies a relative path for outputs from external native
                      // builds. You can specify any path that's not a subdirectory
                      // of your project's temporary build/ directory.
                      buildStagingDirectory = "./outputs/cmake"
                  }
              }
          }
          

• Vous pouvez désormais utiliser CMake 3.7 ou version ultérieure lorsque vous compilez des projets natifs à partir d'Android Studio.

• La nouvelle configuration des dépendances lintChecks vous permet de créer un fichier JAR qui définit des règles lint personnalisées, et de l'empaqueter dans vos projets AAR et APK.

  Vos règles lint personnalisées doivent appartenir à un projet distinct qui génère un seul fichier JAR et n'inclut que les dépendances compileOnly. D'autres modules d'application et de bibliothèque peuvent ensuite dépendre de votre projet lint à l'aide de la configuration lintChecks :

  Groovy

          dependencies {
              // This tells the Gradle plugin to build ':lint-checks' into a lint.jar file
              // and package it with your module. If the module is an Android library,
              // other projects that depend on it automatically use the lint checks.
              // If the module is an app, lint includes these rules when analyzing the app.
              lintChecks project(':lint-checks')
          }
          

  Kotlin

          dependencies {
              // This tells the Gradle plugin to build ':lint-checks' into a lint.jar file
              // and package it with your module. If the module is an Android library,
              // other projects that depend on it automatically use the lint checks.
              // If the module is an app, lint includes these rules when analyzing the app.
              lintChecks(project(":lint-checks"))
          }
          

Changements de comportement

• Le plug-in Android 3.0.0 supprime certaines API, dont l'utilisation empêchera le fonctionnement de votre build. Par exemple, vous ne pouvez plus utiliser l'API Variants pour accéder aux objets outputFile(), ni utiliser processManifest.manifestOutputFile() pour obtenir le fichier manifeste de chaque variante. Pour en savoir plus, consultez Modifications des API.
• Il n'est plus nécessaire de préciser une version spécifique pour les outils de compilation ; vous pouvez donc supprimer la propriété android.buildToolsVersion. Par défaut, le plug-in utilise automatiquement la version minimale requise des outils de compilation pour la version du plug-in Android que vous utilisez.
• Vous pouvez désormais activer/désactiver le traitement PNG dans le bloc buildTypes, comme indiqué ci-dessous. Le traitement PNG est activé par défaut pour tous les builds, à l'exception des versions de débogage, car il augmente la durée de compilation des projets qui comprennent de nombreux fichiers PNG. Ainsi, pour diminuer la durée de compilation d'autres types de compilation, vous devez désactiver le traitement PNG ou convertir vos images au format WebP.

  Groovy

        android {
          buildTypes {
            release {
              // Disables PNG crunching for the release build type.
              crunchPngs false
            }
          }
        }
        

  Kotlin

        android {
          buildTypes {
            release {
              // Disables PNG crunching for the release build type.
              isCrunchPngs = false
            }
          }
        }
        

• Le plug-in Android compile désormais automatiquement des cibles exécutables que vous configurez dans vos projets CMake externes.
• Vous devez maintenant ajouter des processeurs d'annotations au classpath du processeur à l'aide de la configuration de dépendance annotationProcessor.
• L'utilisation de ndkCompile, obsolète, est désormais plus limitée. À la place, vous devez utiliser CMake ou ndk-build pour compiler le code natif que vous souhaitez empaqueter dans votre APK. Pour en savoir plus, consultez Migrer depuis ndkcompile.