Android-Gradle-Plug-in 3.0.0 (Oktober 2017)

Das Android-Gradle-Plug-in 3.0.0 enthält eine Reihe von Änderungen, mit denen Leistungsprobleme bei großen Projekten behoben werden sollen.

Bei einem Beispielprojekt mit etwa 130 Modulen und einer großen Anzahl externer Abhängigkeiten (aber ohne Code oder Ressourcen) können Sie beispielsweise die folgenden Leistungsverbesserungen feststellen:

Einige dieser Änderungen führen zu Fehlern bei vorhandenen Builds. Sie sollten daher den
Aufwand für die Migration Ihres Projekts berücksichtigen, bevor Sie das neue Plug-in verwenden.

Wenn Sie die oben beschriebenen Leistungsverbesserungen nicht feststellen, melden Sie bitte einen Fehler und fügen Sie einen Trace Ihres Builds mit dem Gradle Profiler bei.

Für diese Version des Android-Plug-ins ist Folgendes erforderlich:

	Mindestversion	Standardversion	Hinweise
Gradle	4.1	4.1	Weitere Informationen finden Sie unter Gradle aktualisieren.
SDK-Build-Tools	26.0.2	26.0.2	Installieren oder konfigurieren Sie die SDK-Build-Tools. Mit diesem Update müssen Sie keine Version für die Build-Tools mehr angeben. Das Plug-in verwendet standardmäßig die mindestens erforderliche Version. Sie können jetzt also die Property `android.buildToolsVersion` entfernen.

Optimierungen

• Bessere Parallelität für Projekte mit mehreren Modulen durch einen detaillierten Aufgabenplan.
• Wenn Sie Änderungen an einer Abhängigkeit vornehmen, führt Gradle schnellere Builds aus, da Module, die keinen Zugriff auf die API dieser Abhängigkeit haben, nicht neu kompiliert werden. Sie sollten einschränken, welche Abhängigkeiten ihre APIs an andere Module weitergeben. Verwenden Sie dazu die neuen Abhängigkeitskonfigurationen von Gradle: implementation, api, compileOnly, und runtimeOnly.
• Schnellere inkrementelle Builds durch Dexing pro Klasse. Jede Klasse wird jetzt in separate DEX-Dateien kompiliert und nur die geänderten Klassen werden neu dexiert. Außerdem sollten Sie mit schnelleren Builds für Apps rechnen, bei denen minSdkVersion auf 20 oder niedriger festgelegt ist und die Legacy-Multi-Dex verwenden.
• Verbesserte Build-Geschwindigkeit durch Optimierung bestimmter Aufgaben zur Verwendung von Cache-Ausgaben. Damit Sie von dieser Optimierung profitieren können, müssen Sie zuerst den Gradle-Build-Cache aktivieren.
• Verbesserte inkrementelle Ressourcenverarbeitung mit AAPT2, das jetzt aktiviert ist. Wenn bei der Verwendung von AAPT2 Probleme auftreten, melden Sie bitte einen Fehler. Sie können AAPT2 auch deaktivieren, indem Sie android.enableAapt2=false in Ihrer gradle.properties Datei festlegen und den Gradle-Daemon neu starten. Führen Sie dazu in der Befehlszeile ./gradlew --stop aus.

Neue Funktionen

• Variantenabhängige Abhängigkeits verwaltung. Wenn Sie eine bestimmte Variante eines Moduls erstellen, werden die Varianten der lokalen Bibliotheksmodulabhängigkeiten jetzt automatisch an die Variante des Moduls angepasst, das Sie erstellen.
• Enthält ein neues Funktionsmodul-Plug-in zur Unterstützung von Android Instant Apps und dem Android Instant Apps SDK, das Sie mit dem SDK-Manager herunterladen können. Weitere Informationen zum Erstellen von Feature-Modulen mit dem neuen Plug-in finden Sie unter Struktur einer Instant App mit mehreren Features.
• Integrierte Unterstützung für bestimmte Java 8-Sprachfunktionen und Java 8 Bibliotheken. Jack ist jetzt veraltet und nicht mehr erforderlich. Sie sollten Jack zuerst deaktivieren, um die verbesserte Java 8-Unterstützung zu nutzen, die in die Standard-Toolchain integriert ist. Weitere Informationen finden Sie unter Java 8-Sprachfunktionen verwenden.

• Unterstützung für das Ausführen von Tests mit Android Test Orchestrator, mit dem Sie jeden Test Ihrer App in einer eigenen Instrumentation-Instanz ausführen können. Da jeder Test in einer eigenen Instrumentation-Instanz ausgeführt wird, wird kein gemeinsamer Status zwischen Tests auf der CPU oder im Arbeitsspeicher Ihres Geräts gespeichert. Und selbst wenn ein Test abstürzt, wird nur die eigene Instrumentation-Instanz beendet, sodass Ihre anderen Tests weiterhin ausgeführt werden.

  • testOptions.execution wurde hinzugefügt, um festzulegen, ob die Testorchestrierung auf dem Gerät verwendet werden soll. Wenn Sie Android Test Orchestrator verwenden möchten, müssen Sie ANDROID_TEST_ORCHESTRATOR angeben, wie unten gezeigt. Standardmäßig ist diese Property auf HOST festgelegt. Dadurch wird die Orchestrierung auf dem Gerät deaktiviert und die Tests werden auf die Standardmethode ausgeführt.

  Groovy

          android {
            testOptions {
              execution 'ANDROID_TEST_ORCHESTRATOR'
            }
          }
          

  Kotlin

          android {
            testOptions {
              execution = "ANDROID_TEST_ORCHESTRATOR"
            }
          }
          

• Mit der neuen androidTestUtil Abhängigkeitskonfiguration können Sie vor dem Ausführen Ihrer Instrumentation-Tests eine weitere Testhelfer-APK installieren, z. B. Android Test Orchestrator:

  Groovy

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

  Kotlin

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

• testOptions.unitTests.includeAndroidResources wurde hinzugefügt, um Unittests zu unterstützen, für die Android-Ressourcen erforderlich sind, z. B. Roboelectric. Wenn Sie diese Property auf true setzen, werden Ressourcen, Assets und Manifeste zusammengeführt, bevor die Unittests ausgeführt werden. Ihre Tests können dann inspect com/android/tools/test_config.properties on the classpath for the following keys:

  • android_merged_assets: der absolute Pfad zum Anlagenverzeichnis mit den zusammengeführten Assets.

    Hinweis: Bei Bibliotheksmodulen enthalten die zusammengeführten Assets nicht die Assets von Abhängigkeiten (siehe Problem #65550419).

  • android_merged_manifest: der absolute Pfad zur zusammengeführten Manifestdatei.

  • android_merged_resources: der absolute Pfad zum Verzeichnis mit den zusammengeführten Ressourcen, das alle Ressourcen aus dem Modul und allen zugehörigen Abhängigkeiten enthält.

  • android_custom_package: der Paketname der endgültigen R-Klasse. Wenn Sie die Anwendungs-ID dynamisch ändern, stimmt dieser Paketname möglicherweise nicht mit dem package Attribut im Manifest der App überein.

• Unterstützung für Schriftarten als Ressourcen (eine neue Funktion in Android 8.0 (API-Level 26)).
• Unterstützung für sprachspezifische APKs mit Android Instant Apps SDK 1.1 und höher.

• Sie können jetzt das Ausgabeverzeichnis für Ihr externes natives Build Projekt ändern, wie unten gezeigt:

  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"
                  }
              }
          }
          

• Sie können jetzt CMake 3.7 oder höher verwenden, wenn Sie native Projekte in Android Studio erstellen.

• Mit der neuen Abhängigkeitskonfiguration lintChecks können Sie eine JAR-Datei erstellen, die benutzerdefinierte Lint-Regeln definiert, und sie in Ihre AAR- und APK-Projekte einbinden.

  Ihre benutzerdefinierten Lint-Regeln müssen zu einem separaten Projekt gehören, das eine einzelne JAR-Datei ausgibt und nur compileOnly Abhängigkeiten enthält. Andere App- und Bibliotheksmodule können dann mit der Konfiguration lintChecks von Ihrem Lint Projekt abhängen:

  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"))
          }
          

Geändertes Verhalten

• In Android-Plug-in 3.0.0 wurden bestimmte APIs entfernt. Wenn Sie sie verwenden, schlägt der Build fehl. Sie können beispielsweise nicht mehr mit der Variants API auf outputFile() Objekte zugreifen oder mit processManifest.manifestOutputFile() die Manifestdatei für jede Variante abrufen. Weitere Informationen finden Sie unter API-Änderungen.
• Sie müssen keine Version für die Build-Tools mehr angeben. Sie können also die android.buildToolsVersion Property entfernen. Standardmäßig verwendet das Plug-in automatisch die mindestens erforderliche Version der Build-Tools für die verwendete Version des Android-Plug-ins.
• Sie können PNG-Crunching jetzt im buildTypes Block aktivieren oder deaktivieren, wie unten gezeigt. PNG-Crunching ist standardmäßig für alle Builds außer Debug-Builds aktiviert, da es die Build-Zeiten für Projekte mit vielen PNG-Dateien verlängert. Um die Build-Zeiten für andere Build-Typen zu verbessern, sollten Sie PNG-Crunching entweder deaktivieren oder Ihre Bilder in WebP konvertieren.

  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
            }
          }
        }
        

• Das Android-Plug-in erstellt jetzt automatisch ausführbare Ziele, die Sie in Ihren externen CMake-Projekten konfigurieren.
• Sie müssen jetzt Annotationsprozessoren mit der annotationProcessor Abhängigkeitskonfiguration zum Klassenpfad des Prozessors hinzufügen.
• Die Verwendung des veralteten ndkCompile ist jetzt eingeschränkter. Sie sollten stattdessen zu CMake oder ndk-build migrieren, um nativen Code zu kompilieren, den Sie in Ihr APK einbinden möchten. Weitere Informationen finden Sie unter Von ndkcompile migrieren.