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

Das Android-Gradle-Plug-in 3.0.0 enthält eine Reihe von Änderungen, die darauf abzielen, Leistungsprobleme bei großen Projekten zu beheben.

Bei einem Beispielprojekt mit Skelettstruktur 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 dazu, dass vorhandene Builds nicht mehr funktionieren. Sie sollten also 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	Standardversio	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 erforderliche Mindestversion. Sie können die Property „android.buildToolsVersion“ jetzt entfernen.

Optimierungen

• Bessere Parallelität für Projekte mit mehreren Modulen durch einen detaillierten Task-Graphen.
• 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, indem Sie die neuen Abhängigkeitskonfigurationen von Gradle verwenden: 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 einer höheren Build-Geschwindigkeit für Apps rechnen, bei denen minSdkVersion auf 20 oder niedriger festgelegt ist und die Legacy-Multi-Dex verwenden.
• Die Build-Geschwindigkeit wurde verbessert, indem bestimmte Aufgaben so optimiert wurden, dass sie zwischengespeicherte Ausgaben verwenden. Damit Sie von dieser Optimierung profitieren können, müssen Sie zuerst den Gradle-Build-Cache aktivieren.
• Verbesserte inkrementelle Ressourcenverarbeitung mit AAPT2, die jetzt standardmäßig 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, indem Sie ./gradlew --stop über die Befehlszeile ausführen.

Neue Funktionen

• Variantenabhängige Abhängigkeitsverwaltung: Wenn Sie eine bestimmte Variante eines Moduls erstellen, gleicht das Plug-in jetzt automatisch Varianten von lokalen Bibliotheksmodulabhängigkeiten mit der Variante des Moduls ab, das Sie erstellen.
• Enthält ein neues Feature-Modul-Plug-in zur Unterstützung von Android-Sofort-Apps und dem Android-Sofort-Apps-SDK (das Sie mit dem SDK Manager herunterladen können). Weitere Informationen zum Erstellen von Funktionsmodulen mit dem neuen Plug-in finden Sie unter Struktur einer Instant-App mit mehreren Funktionen.
• Integrierte Unterstützung für die Verwendung bestimmter 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 hinzugefügt. Damit können Sie jeden Test Ihrer App in einem eigenen Aufruf von Instrumentation ausführen. 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. Selbst wenn ein Test abstürzt, wird nur die zugehörige Instrumentation-Instanz beendet, sodass die anderen Tests weiterhin ausgeführt werden.

  • testOptions.execution wurde hinzugefügt, um festzulegen, ob die Testorchestration auf dem Gerät verwendet werden soll. Wenn Sie Android Test Orchestrator verwenden möchten, müssen Sie ANDROID_TEST_ORCHESTRATOR wie unten gezeigt angeben. Standardmäßig ist diese Eigenschaft auf HOST gesetzt. Dadurch wird die Orchestrierung auf dem Gerät deaktiviert. Dies ist die Standardmethode zum Ausführen von Tests.

  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 Instrumentierungstests ein weiteres Test-Helper-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 wie Roboelectric erforderlich sind. Wenn Sie diese Eigenschaft auf true setzen, führt das Plug-in das Zusammenführen von Ressourcen, Assets und Manifesten durch, bevor die Unit-Tests ausgeführt werden. Ihre Tests können dann com/android/tools/test_config.properties im Klassenpfad nach den folgenden Schlüsseln durchsuchen:

  • android_merged_assets: der absolute Pfad zum Verzeichnis 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, die in Android 8.0 (API-Level 26) eingeführt wurde).
• 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 lintChecks-Abhängigkeitskonfiguration können Sie eine JAR-Datei erstellen, in der benutzerdefinierte Lint-Regeln definiert sind, und sie in Ihre AAR- und APK-Projekte einfügen.

  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 lintChecks-Konfiguration 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

• Im Android-Plug-in 3.0.0 wurden bestimmte APIs entfernt. Wenn Sie diese verwenden, schlägt der Build fehl. Sie können beispielsweise nicht mehr über die Variants API auf outputFile()-Objekte zugreifen oder processManifest.manifestOutputFile() verwenden, um die Manifest-Datei für jede Variante abzurufen. Weitere Informationen finden Sie unter API-Änderungen.
• Sie müssen keine Version mehr für die Build-Tools angeben. Sie können die Property android.buildToolsVersion also entfernen. Standardmäßig verwendet das Plug-in automatisch die mindestens erforderliche Version der Build-Tools für die Version des Android-Plug-ins, die Sie verwenden.
• Sie aktivieren/deaktivieren die PNG-Kompression jetzt im Block buildTypes, wie unten gezeigt. Die PNG-Kompression ist standardmäßig für alle Builds außer Debug-Builds aktiviert, da sie die Build-Zeiten für Projekte mit vielen PNG-Dateien verlängert. Wenn Sie die Build-Zeiten für andere Build-Typen verbessern möchten, sollten Sie entweder die PNG-Kompression 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 Abhängigkeitskonfiguration annotationProcessor zum Prozessor-Classpath hinzufügen.
• Die Verwendung der eingestellten ndkCompile ist jetzt eingeschränkter. Stattdessen sollten Sie entweder CMake oder ndk-build verwenden, um nativen Code zu kompilieren, den Sie in Ihr APK aufnehmen möchten. Weitere Informationen finden Sie unter Von ndkcompile migrieren.