Diese Seite wurde von der Cloud Translation API übersetzt.

Android Gradle Plugin 4.2.0 (März 2021)

Kompatibilität

	Mindestversion	Standardversio	Hinweise
Gradle	6.7.1	–	Weitere Informationen finden Sie unter Gradle aktualisieren.
SDK-Build-Tools	30.0.2	30.0.2	Installieren oder konfigurieren Sie die SDK-Build-Tools.
NDK	–	21.4.7075529	Installieren oder konfigurieren Sie eine andere Version des NDK.

Neue Funktionen

Diese Version des Android Gradle-Plug-ins enthält die folgenden neuen Funktionen.

Java-Sprachversion 8 als Standard

Ab Version 4.2 verwendet AGP standardmäßig die Java 8-Sprachebene. Java 8 bietet Zugriff auf eine Reihe neuerer Sprachfunktionen, darunter Lambdaausdrücke, Methodenreferenzen und statische Schnittstellenmethoden. Eine vollständige Liste der unterstützten Funktionen finden Sie in der Java 8-Dokumentation.

Wenn Sie das alte Verhalten beibehalten möchten, geben Sie Java 7 in der Datei build.gradle.kts oder build.gradle auf Modulebene explizit an:

// build.gradle
android {
  ...
  compileOptions {
    sourceCompatibility JavaVersion.VERSION_1_7
    targetCompatibility JavaVersion.VERSION_1_7
  }
  // For Kotlin projects, compile to Java 6 instead of 7
  kotlinOptions {
    jvmTarget = "1.6"
  }
}

// build.gradle.kts
android {
  ...
  compileOptions {
    sourceCompatibility = JavaVersion.VERSION_1_7
    targetCompatibility = JavaVersion.VERSION_1_7
  }
  // For Kotlin projects, compile to Java 6 instead of 7
  kotlinOptions {
    jvmTarget = "1.6"
  }
}

Neuer JVM-Ressourcencompiler

Ein neuer JVM-Ressourcencompiler im Android Gradle-Plug-in 4.2 ersetzt Teile des AAPT2-Ressourcencompilers. Dadurch kann die Build-Leistung insbesondere auf Windows-Computern verbessert werden. Der neue JVM-Ressourcencompiler ist standardmäßig aktiviert.

Signatur von Version 3 und 4 jetzt unterstützt

Das Android-Gradle-Plug-in 4.2 unterstützt jetzt die Signaturformate APK v3 und APK v4. Wenn Sie eines oder beide dieser Formate in Ihrem Build aktivieren möchten, fügen Sie der Datei build.gradle oder build.gradle.kts auf Modulebene die folgenden Eigenschaften hinzu:

// build.gradle
android {
  ...
  signingConfigs {
    config {
        ...
        enableV3Signing true
        enableV4Signing true
    }
  }
}

// build.gradle.kts
android {
  ...
  signingConfigs {
      config {
          ...
          enableV3Signing = true
          enableV4Signing = true
      }
  }
}

Mit der APK-Signatur Version 4 können Sie große APKs mit der inkrementellen APK-Installation von ADB in Android 11 schnell bereitstellen. Dieses neue Flag übernimmt den Schritt der APK-Signatur im Bereitstellungsprozess.

App-Signatur pro Variante konfigurieren

Es ist jetzt möglich, die App-Signatur im Android Gradle-Plug-in pro Variante zu aktivieren oder zu deaktivieren.

In diesem Beispiel wird gezeigt, wie Sie die App-Signatur für jede Variante mit der Methode onVariants() in Kotlin oder Groovy festlegen:

androidComponents {
    onVariants(selector().withName("fooDebug"), {
        signingConfig.enableV1Signing.set(false)
        signingConfig.enableV2Signing.set(true)
    })

Neue Gradle-Eigenschaft: `android.native.buildOutput`

Um die Build-Ausgabe übersichtlich zu gestalten, filtert AGP 4.2 Nachrichten aus nativen Builds heraus, die CMake und ndk-build verwenden. Standardmäßig wird nur die C/C++-Compilerausgabe angezeigt. Bisher wurde für jede erstellte Datei eine Ausgabezeile generiert, was zu einer großen Anzahl von Informationsmeldungen führte.

Wenn Sie die gesamte native Ausgabe sehen möchten, setzen Sie die neue Gradle-Eigenschaft android.native.buildOutput auf verbose.

Sie können diese Eigenschaft entweder in der Datei gradle.properties oder über die Befehlszeile festlegen.

gradle.properties
android.native.buildOutput=verbose

Befehlszeile
-Pandroid.native.buildOutput=verbose

Der Standardwert dieser Property ist quiet.

Verhaltensänderung bei gradle.properties-Dateien

Ab AGP 4.2 ist es nicht mehr möglich, Gradle-Properties aus Unterprojekten zu überschreiben. Wenn Sie also eine Property in einer gradle.properties-Datei in einem untergeordneten Projekt anstelle des Stammprojekts deklarieren, wird sie ignoriert.

In früheren Releases las AGP beispielsweise Werte aus <var>projectDir</var>/gradle.properties, <var>projectDir</var>/app/gradle.properties, <var>projectDir</var>/library/gradle.properties usw. Wenn für App-Module dieselbe Gradle-Eigenschaft sowohl in <var>projectDir</var>/gradle.properties als auch in <var>projectDir</var>/app/gradle.properties vorhanden war, hatte der Wert aus <var>projectDir</var>/app/gradle.properties Vorrang.

In AGP 4.2 wurde dieses Verhalten geändert. AGP lädt keine Werte aus gradle.properties in untergeordnete Projekte (z. B. <var>projectDir</var>/app/gradle.properties). Diese Änderung entspricht dem neuen Gradle-Verhalten und unterstützt das Caching von Konfigurationen.

Weitere Informationen zum Festlegen von Werten in gradle.properties-Dateien finden Sie in der Gradle-Dokumentation.

Änderungen an der Gradle-Kompatibilität und -Konfiguration

Wenn das Gradle-Build-Tool in Android Studio ausgeführt wird, verwendet es das mitgelieferte JDK von Studio. In früheren Releases war JDK 8 im Lieferumfang von Studio enthalten. In 4.2 ist jedoch stattdessen JDK 11 enthalten. Wenn Sie das neue JDK zum Ausführen von Gradle verwenden, kann dies aufgrund von Änderungen am Garbage Collector zu Inkompatibilitäten oder Leistungseinbußen der JVM führen. Diese Probleme werden unten beschrieben.

Hinweis:Wir empfehlen, Gradle mit JDK 11 auszuführen. Sie können das JDK, mit dem Gradle ausgeführt wird, jedoch im Dialogfeld Projektstruktur ändern. Durch Ändern dieser Einstellung wird nur das JDK geändert, das zum Ausführen von Gradle verwendet wird. Das JDK, das zum Ausführen von Studio selbst verwendet wird, bleibt unverändert.

Kompatibilität von Studio mit dem Android Gradle-Plug-in (AGP)

Mit Android Studio 4.2 können Projekte geöffnet werden, die AGP 3.1 und höher verwenden, sofern AGP Gradle 4.8.1 oder höher ausführt. Weitere Informationen zur Kompatibilität von Gradle finden Sie unter Gradle aktualisieren.

Gradle-Builds für JDK 11 optimieren

Dieses Update auf JDK 11 wirkt sich auf die Standardkonfiguration des JVM-Garbage-Collectors aus, da in JDK 8 der parallele Garbage-Collector verwendet wird, während in JDK 11 der G1-Garbage-Collector verwendet wird.

Um die Build-Leistung zu verbessern, empfehlen wir, Ihre Gradle-Builds mit dem parallelen Garbage Collector zu testen. Legen Sie unter gradle.properties Folgendes fest:

org.gradle.jvmargs=-XX:+UseParallelGC

Wenn in diesem Feld bereits andere Optionen festgelegt sind, fügen Sie eine neue Option hinzu:

org.gradle.jvmargs=-Xmx1536m -XX:+UseParallelGC

Informationen zum Messen der Buildgeschwindigkeit mit verschiedenen Konfigurationen finden Sie unter Builds analysieren.

DEX-Dateien in APKs unkomprimiert, wenn `minSdk` = 28 oder höher

AGP verpackt DEX-Dateien jetzt standardmäßig unkomprimiert in APKs, wenn minSdk = 28 oder höher ist. Dies führt zu einer Erhöhung der APK-Größe, aber zu einer geringeren Installationsgröße auf dem Gerät. Die Downloadgröße bleibt ungefähr gleich.

Wenn Sie AGP zwingen möchten, die DEX-Dateien stattdessen komprimiert zu verpacken, können Sie der Datei build.gradle Folgendes hinzufügen:

android {
    packagingOptions {
        dex {
            useLegacyPackaging true
        }
    }
}

Komprimierte native Bibliotheken mit der DSL verpacken

Wir empfehlen, native Bibliotheken in unkomprimierter Form zu verpacken, da dies zu einer geringeren App-Installationsgröße, einer geringeren App-Downloadgröße und einer kürzeren App-Ladezeit für Ihre Nutzer führt. Wenn das Android Gradle-Plug-in jedoch komprimierte native Bibliotheken beim Erstellen Ihrer App verpacken soll, setzen Sie in der build.gradle-Datei Ihrer App useLegacyPackaging auf true:

android {
    packagingOptions {
        jniLibs {
            useLegacyPackaging true
        }
    }
}

Das Flag useLegacyPackaging ersetzt das Manifestattribut extractNativeLibs. Weitere Informationen finden Sie in den Versionshinweisen Native Bibliotheken werden standardmäßig unkomprimiert verpackt.