Android Gradle-Plug-in 3.0.0 (Oktober 2017)

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

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

Version des Android-Plug-ins + Gradle-Version Android-Plug-in 2.2.0 + Gradle 2.14.1 Android-Plug-in 2.3.0 + Gradle 3.3 Android-Plug-in 3.0.0 + Gradle 4.1
Konfiguration (z.B. Ausführung von ./gradlew --help) ~2 Min. ~9 Sek. ~2,5 Sek.
Einzeilige Java-Änderung (Implementierungsänderung) ~2 Min. 15 Sek. ~ 29 Sek. ~6,4 Sek.

Einige dieser Änderungen beeinträchtigen vorhandene Builds. Daher sollten Sie den Aufwand
für die Migration Ihres Projekts berücksichtigen, bevor Sie das neue Plug-in verwenden.

Wenn die oben beschriebenen Leistungsverbesserungen nicht auftreten, melden Sie den Fehler und fügen Sie mit dem Gradle Profiler einen Trace Ihres Builds hinzu.

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

  • Gradle 4.1 oder höher Weitere Informationen finden Sie im Abschnitt zum Aktualisieren von Gradle.
  • Build Tools 26.0.2 oder höher. Mit diesem Update müssen Sie keine Version für die Build-Tools mehr angeben. Das Plug-in verwendet standardmäßig die erforderliche Mindestversion. Jetzt können Sie die Eigenschaft android.buildToolsVersion entfernen.

3.0.1 (November 2017)

Dies ist ein kleineres Update zur Unterstützung von Android Studio 3.0.1. Es enthält allgemeine Fehlerkorrekturen und Leistungsverbesserungen.

Optimierungen

  • Bessere Parallelität für Projekte mit mehreren Modulen durch eine detailgenaue Aufgabengrafik.
  • Wenn Änderungen an einer Abhängigkeit vorgenommen werden, führt Gradle schnellere Builds aus, da Module, die keinen Zugriff auf die API der Abhängigkeit haben, nicht neu kompiliert werden. Sie sollten einschränken, welche Abhängigkeiten ihre APIs auf andere Module übertragen. 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 ist mit verbesserten Build-Geschwindigkeiten für Anwendungen zu rechnen, in denen minSdkVersion auf 20 oder weniger festgelegt wird und Legacy-Multi-DEX verwendet wird.
  • Verbesserte Build-Geschwindigkeiten durch Optimierung bestimmter Aufgaben, um im Cache gespeicherte Ausgaben zu verwenden. Damit Sie von dieser Optimierung profitieren können, müssen Sie zuerst den Gradle-Build-Cache aktivieren.
  • Die inkrementelle Ressourcenverarbeitung mit AAPT2, das jetzt standardmäßig aktiviert ist, wurde verbessert. Wenn bei der Verwendung von AAPT2 Probleme auftreten, melden Sie den Fehler. Sie können AAPT2 auch deaktivieren, indem Sie android.enableAapt2=false in der Datei gradle.properties festlegen und den Gradle-Daemon neu starten. Dazu führen Sie ./gradlew --stop über die Befehlszeile aus.

Neue Funktionen

  • Variantensensitives Abhängigkeitsmanagement: Wenn eine bestimmte Variante eines Moduls erstellt wird, gleicht das Plug-in jetzt automatisch Varianten der Modulabhängigkeiten der lokalen Bibliothek der Variante des Moduls ab, das Sie erstellen.
  • Enthält ein neues Featuremodul-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 die Verwendung bestimmter Java 8-Sprachfunktionen und Java 8-Bibliotheken. Jack ist jetzt veraltet und wird nicht mehr benötigt. Deaktivieren Sie zuerst Jack, um die verbesserte Java 8-Unterstützung zu verwenden, die in die Standard-Toolchain integriert ist. Weitere Informationen finden Sie unter Sprachfeatures für Java 8 verwenden.
  • Unterstützung für die Ausführung von Tests mit Android Test Orchestrator wurde hinzugefügt. So können Sie jeden Test Ihrer App mit einem eigenen Aufruf der Instrumentierung ausführen. Da jeder Test in seiner eigenen Instrumentierungsinstanz ausgeführt wird, werden sich keine zwischen den Tests gemeinsamen Status auf der CPU oder im Arbeitsspeicher Ihres Geräts akkumulieren. Selbst wenn ein Test abstürzt, wird nur seine eigene Instrumentierungsinstanz deaktiviert, sodass die anderen Tests weiterhin ausgeführt werden.

    • testOptions.execution wurde hinzugefügt, um zu bestimmen, ob die On-Device-Testorchestrierung 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, wodurch die Orchestrierung auf dem Gerät deaktiviert wird und die Standardmethode zum Ausführen von Tests ist.

    Groovig

            android {
              testOptions {
                execution 'ANDROID_TEST_ORCHESTRATOR'
              }
            }
            

    Kotlin

            android {
              testOptions {
                execution = "ANDROID_TEST_ORCHESTRATOR"
              }
            }
            
  • Mit der neuen androidTestUtil-Abhängigkeitskonfiguration können Sie ein anderes Testhilfs-APK installieren, bevor Sie Ihre Instrumentierungstests wie Android Test Orchestrator ausführen:

    Groovig

            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 Einheitentests zu unterstützen, die Android-Ressourcen wie Roboelectric erfordern. Wenn Sie dieses Attribut auf true setzen, führt das Plug-in Ressourcen, Assets und Manifeste zusammen, bevor die Einheitentests ausgeführt werden. Ihre Tests können dann com/android/tools/test_config.properties im Klassenpfad auf die folgenden Schlüssel prüfen:

    • android_merged_assets: der absolute Pfad zum zusammengeführten Asset-Verzeichnis.

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

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

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

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

  • Unterstützung für Schriftarten als Ressourcen (neue Funktion in Android 8.0 (API-Level 26)).
  • Unterstützung sprachspezifischer APKs mit dem 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 dargestellt:

    Groovig

            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, um native Projekte über Android Studio zu erstellen.
  • Mit der neuen lintChecks-Abhängigkeitskonfiguration können Sie eine JAR-Datei erstellen, die benutzerdefinierte Lint-Regeln definiert, und sie in Ihre AAR- und APK-Projekte verpacken.

    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 Anwendungs- und Bibliotheksmodule können dann mithilfe der lintChecks-Konfiguration von Ihrem Lint-Projekt abhängig sein:

    Groovig

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

Änderungen des Verhaltens

  • Das Android-Plug-in 3.0.0 entfernt bestimmte APIs und Ihr Build funktioniert nicht mehr, wenn Sie sie verwenden. Sie können beispielsweise nicht mehr die Variants API für den Zugriff auf outputFile()-Objekte oder processManifest.manifestOutputFile() verwenden, um die Manifestdatei für jede Variante abzurufen. Weitere Informationen finden Sie unter API-Änderungen.
  • Sie müssen für die Build-Tools keine Version mehr angeben. Deshalb können Sie das Attribut android.buildToolsVersion jetzt entfernen. Standardmäßig verwendet das Plug-in automatisch die mindestens erforderliche Build-Tool-Version für die Version des von Ihnen verwendeten Android-Plug-ins.
  • Sie aktivieren/deaktivieren jetzt die PNG-Bearbeitung im buildTypes-Block, wie unten dargestellt. Die PNG-Bearbeitung ist standardmäßig für alle Builds aktiviert, mit Ausnahme von Debug-Builds, da dies die Build-Zeit für Projekte erhöht, die viele PNG-Dateien enthalten. Um also die Build-Zeiten für andere Build-Typen zu verbessern, sollten Sie entweder die PNG-Bearbeitung deaktivieren oder Ihre Bilder in WebP konvertieren.

    Groovig

          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 dem Prozessorklassenpfad jetzt Annotationsprozessoren hinzufügen. Verwenden Sie dazu die Abhängigkeitskonfiguration annotationProcessor.
  • Die Verwendung des eingestellten ndkCompile ist jetzt stärker eingeschränkt. Sie sollten stattdessen entweder zu CMake oder ndk-build migrieren, um nativen Code zu kompilieren, den Sie in Ihr APK verpacken möchten. Weitere Informationen findest du unter Von ndkcompile migrieren.