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
undruntimeOnly
. - 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 Dateigradle.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 SieANDROID_TEST_ORCHESTRATOR
wie unten gezeigt angeben. Standardmäßig ist diese Eigenschaft aufHOST
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 auftrue
setzen, führt das Plug-in Ressourcen, Assets und Manifeste zusammen, bevor die Einheitentests ausgeführt werden. Ihre Tests können danncom/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 Attributpackage
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 derlintChecks
-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 oderprocessManifest.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.