Diese Seite wurde von der Cloud Translation API übersetzt.

Android Gradle Plugin 3.0.0 (Oktober 2017)

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

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

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

Einige dieser Änderungen führen dazu, dass vorhandene Builds nicht mehr funktionieren. Sie sollten sich also vor der Verwendung des neuen Plug-ins darüber informieren,
wie viel Aufwand die Migration Ihres Projekts mit sich bringt.

Wenn Sie die oben beschriebenen Leistungsverbesserungen nicht feststellen, erstellen Sie bitte einen Fehlerbericht und fügen Sie einen Build-Trace mit dem Gradle-Profiler hinzu.

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 mehr für die Build-Tools angeben. Das Plug-in verwendet standardmäßig die erforderliche Mindestversion. Sie können die Property „android.buildToolsVersion“ jetzt entfernen.

3.0.1 (November 2017)

Dieses kleine Update unterstützt Android Studio 3.0.1 und enthält allgemeine Fehlerkorrekturen und Leistungsverbesserungen.

Optimierungen

Bessere Parallelität für mehrmodulige Projekte durch einen detaillierten Aufgabengraphen.
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 Buildgeschwindigkeit durch Dezimierung pro Klasse. Jede Klasse wird jetzt in separate DEX-Dateien kompiliert und nur die Klassen, die geändert werden, werden neu dexiert. Außerdem sollten Sie eine verbesserte Buildgeschwindigkeit für Apps erwarten, bei denen minSdkVersion auf 20 oder niedriger festgelegt ist und Legacy Multi-Dex verwendet wird.
Die Build-Geschwindigkeit wurde verbessert, indem bestimmte Aufgaben für die Verwendung von zwischengespeicherten Ausgaben optimiert wurden. Damit Sie von dieser Optimierung profitieren können, müssen Sie zuerst den Gradle-Build-Cache aktivieren.
Die inkrementelle Ressourcenverarbeitung wurde mit AAPT2 verbessert, das 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 in Ihrer gradle.properties-Datei android.enableAapt2=false festlegen und den Gradle-Daemon neu starten, indem Sie ./gradlew --stop über die Befehlszeile ausführen.

Neue Funktionen

Variantenspezifische Abhängigkeitsverwaltung Beim Erstellen einer bestimmten Variante eines Moduls gleicht das Plug-in jetzt automatisch die Varianten der Abhängigkeiten von lokalen Bibliotheksmodulen mit der Variante des Moduls ab, das Sie erstellen.
Enthält ein neues Feature-Modul-Plug-in zur Unterstützung von Android Instant Apps und dem Android Instant Apps SDK (das Sie über den 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 Funktionen.
Integrierte Unterstützung für die Verwendung bestimmter Java 8-Sprachfunktionen und Java 8-Bibliotheken. Jack wurde eingestellt und ist nicht mehr erforderlich. Sie sollten Jack zuerst deaktivieren, um die verbesserte Java 8-Unterstützung zu verwenden, die in der Standard-Toolchain enthalten ist. Weitere Informationen finden Sie unter Java 8-Sprachfunktionen verwenden.
Unterstützung für die Ausführung von Tests mit Android Test Orchestrator hinzugefügt. Damit können Sie die Tests Ihrer App in einer eigenen Aufrufinstanz der Instrumentierung ausführen. Da jeder Test in einer eigenen Instrumentierungsinstanz ausgeführt wird, wird der gemeinsame Status zwischen den Tests nicht auf der CPU oder im Arbeitsspeicher des Geräts angesammelt. Selbst wenn ein Test abstürzt, wird nur die entsprechende Instanz der Instrumentierung beendet. Die anderen Tests werden also weiterhin ausgeführt.
- Es wurde testOptions.execution 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 angeben, wie unten gezeigt. Standardmäßig ist diese Eigenschaft auf HOST festgelegt. Dadurch wird die On-Device-Orchestrierung 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-Hilfs-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 Unit-Tests zu unterstützen, für die Android-Ressourcen erforderlich sind, z. B. Roboelectric. Wenn Sie diese Eigenschaft auf true festlegen, führt das Plug-in vor dem Ausführen der Unit-Tests eine Zusammenführung von Ressourcen, Assets und Manifesten durch. 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 Verzeichnis mit den zusammengeführten Assets.
  
  Hinweis:Bei Bibliotheksmodulen enthalten die zusammengeführten Assets nicht die Assets der 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 alle zugehörigen Abhängigkeiten enthält.
- android_custom_package: 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 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:

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, um native Projekte in 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 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 von Ihrem Lint-Projekt mit der lintChecks-Konfiguration 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

Mit dem Android-Plug-in 3.0.0 werden bestimmte APIs entfernt. Wenn Sie diese verwenden, funktioniert Ihr Build nicht mehr. Sie können beispielsweise nicht mehr die Variants API verwenden, um auf outputFile()-Objekte zuzugreifen, oder processManifest.manifestOutputFile(), um die Manifestdatei 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 Mindestversion der Build-Tools für die Version des Android-Plug-ins, die Sie verwenden.

Sie aktivieren oder deaktivieren die PNG-Komprimierung jetzt im Block buildTypes, wie unten dargestellt. Die PNG-Komprimierung ist standardmäßig für alle Builds aktiviert, mit Ausnahme von Debug-Builds, da sich die Buildzeit für Projekte mit vielen PNG-Dateien dadurch verlängert. Wenn Sie die Build-Zeiten für andere Build-Typen verbessern möchten, sollten Sie entweder das PNG-Crunching 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 dem Prozessor-Classpath jetzt mithilfe der annotationProcessor-Abhängigkeitskonfiguration Anmerkungs-Prozessoren hinzufügen.
Die Verwendung des eingestellten ndkCompile ist jetzt stärker eingeschränkt. Sie sollten stattdessen entweder CMake oder ndk-build verwenden, um nativen Code zu kompilieren, den Sie in Ihr APK einbinden möchten. Weitere Informationen finden Sie unter Von ndkcompile migrieren.