Android-Gradle-Plug-in 3.0.0 (Oktober 2017)
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 folgende Leistungsverbesserungen feststellen:
| Android-Plug-in-Version + 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ühren von ./gradlew --help) |
~2 Minuten | ~9 Sekunden | ~2,5 Sekunden |
| 1-zeilige Java-Änderung (Implementierungsänderung) | ~2 Minuten 15 Sekunden | ~29 Sekunden | ~6,4 Sekunden |
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 hinzu.
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 das Attribut `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 einen detaillierten Aufgabenplan.
- Wenn Sie Änderungen an einer Abhängigkeit vornehmen, führt Gradle schnellere Builds aus, indem Module nicht
neu kompiliert werden, die keinen Zugriff auf die API dieser Abhängigkeit haben.
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, 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 dexed. Außerdem sollten Sie mit schnelleren Builds für
Apps rechnen, bei denen
minSdkVersionauf 20 oder niedriger festgelegt ist und die Legacy-Multi-Dex verwenden. - Schnellere Builds durch Optimierung bestimmter Aufgaben zur Verwendung von Cache-Ausgaben. Um von dieser Optimierung zu profitieren, 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 AAP12 auch deaktivieren, indem Sie
android.enableAapt2=falsein Ihrergradle.propertiesDatei festlegen und den Gradle-Daemon neu starten. Führen Sie dazu in der Befehlszeile./gradlew --stopaus.
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 Aufrufung von Instrumentation 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.executionwurde hinzugefügt, um festzulegen, ob die Testorchestrierung auf dem Gerät verwendet werden soll. Wenn Sie Android Test Orchestrator verwenden möchten, müssen SieANDROID_TEST_ORCHESTRATORangeben, wie unten gezeigt. Standardmäßig ist dieses Attribut aufHOSTfestgelegt. 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
androidTestUtilAbhä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.includeAndroidResourceswurde hinzugefügt, um Unittests zu unterstützen, für die Android-Ressourcen erforderlich sind, z. B. Roboelectric. Wenn Sie dieses Attribut auftruesetzen, werden Ressourcen, Assets und Manifeste zusammengeführt, bevor die Unittests ausgeführt werden. Ihre Tests können dann inspectcom/android/tools/test_config.propertieson the classpath for the following keys:-
android_merged_assets: der absolute Pfad zum Anlagenverzeichnis der 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 der 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 dempackageAttribut 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
lintCheckskö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
compileOnlyAbhängigkeiten enthält. Andere App- und Bibliotheksmodule können dann mit der KonfigurationlintChecksvon 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 mitprocessManifest.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 das Attribut
android.buildToolsVersionentfernen. 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-Komprimierung jetzt im
buildTypesBlock, wie unten gezeigt. Die PNG-Komprimierung 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. Um die Build-Zeiten für andere Build-Typen zu verbessern, sollten Sie die PNG-Komprimierung 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
annotationProcessorAbhängigkeitskonfiguration zum Klassenpfad des Prozessors hinzufügen. - Die Verwendung des veralteten
ndkCompileist jetzt eingeschränkter. Stattdessen sollten Sie entweder CMake oder ndk-build verwenden, um nativen Code zu kompilieren, den Sie in Ihre APK einbinden möchten. Weitere Informationen finden Sie unter Von ndkcompile migrieren.