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, 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 dexed. Außerdem sollten Sie mit schnelleren Builds für Apps rechnen, bei denen minSdkVersion auf 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=false in Ihrer gradle.properties Datei festlegen und den Gradle-Daemon neu starten. Führen Sie dazu in der Befehlszeile ./gradlew --stop aus.

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.execution wurde hinzugefügt, um festzulegen, ob die Testorchestrierung 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 dieses Attribut auf HOST festgelegt. 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 androidTestUtil Abhä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.includeAndroidResources wurde hinzugefügt, um Unittests zu unterstützen, für die Android-Ressourcen erforderlich sind, z. B. Roboelectric. Wenn Sie dieses Attribut auf true setzen, werden Ressourcen, Assets und Manifeste zusammengeführt, bevor die Unittests ausgeführt werden. Ihre Tests können dann inspect com/android/tools/test_config.properties on 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 dem package Attribut 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 lintChecks 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 mit der Konfiguration lintChecks 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

  • 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 mit processManifest.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.buildToolsVersion 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-Komprimierung jetzt im buildTypes Block, 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 annotationProcessor Abhängigkeitskonfiguration zum Klassenpfad des Prozessors hinzufügen.
  • Die Verwendung des veralteten ndkCompile ist 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.