Android-Gradle-Plug-in 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.

Standardmäßig Java-Sprachversion 8

Ab Version 4.2 verwendet AGP standardmäßig das Java 8-Sprachniveau. Java 8 bietet Zugriff auf eine Reihe neuerer Sprachfunktionen, darunter Lambda-Ausdrü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 explizit in der Datei build.gradle.kts oder build.gradle auf Modulebene 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-Plugin 4.2 ersetzt Teile des AAPT2-Ressourcencompilers und kann so die Build-Leistung verbessern, insbesondere auf Windows-Computern. Der neue JVM-Ressourcencompiler ist standardmäßig aktiviert.

v3- und v4-Signierung werden 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 die folgenden Attribute der Datei build.gradle oder build.gradle.kts auf Modulebene hinzu:

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

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

App-Signatur pro Variante konfigurieren

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

In diesem Beispiel wird gezeigt, wie Sie die App-Signierung pro 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-Property: android.native.buildOutput

Um die Build-Ausgabe übersichtlicher zu gestalten, filtert AGP 4.2 Nachrichten aus nativen Builds, die CMake und ndk-build verwenden. Standardmäßig wird nur die Ausgabe des C/C++-Compilers angezeigt. Bisher wurde für jede erstellte Datei eine Zeile mit der Ausgabe 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-Property android.native.buildOutput auf verbose.

Sie können dieses Attribut 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 Eigenschaft ist quiet.

Verhaltensänderung für gradle.properties-Dateien

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

In früheren Versionen hat AGP beispielsweise Werte aus <var>projectDir</var>/gradle.properties, <var>projectDir</var>/app/gradle.properties, <var>projectDir</var>/library/gradle.properties usw. gelesen. Wenn dieselbe Gradle-Eigenschaft in App-Modulen 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 Unterprojekten (z. B. <var>projectDir</var>/app/gradle.properties). Diese Änderung entspricht dem neuen Gradle-Verhalten und unterstützt Konfigurations-Caching.

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

Gradle-Kompatibilität und Konfigurationsänderungen

Bei der Ausführung in Android Studio verwendet das Gradle-Build-Tool das in Studio enthaltene JDK. In früheren Versionen war JDK 8 in Studio enthalten. In Version 4.2 ist jedoch JDK 11 enthalten. Wenn Sie das neue gebündelte JDK zum Ausführen von Gradle verwenden, kann dies aufgrund von Änderungen am Garbage Collector zu Inkompatibilitäten oder Leistungseinbußen bei der JVM führen. Diese Probleme werden unten beschrieben.

Hinweis:Wir empfehlen, Gradle mit JDK 11 auszuführen. Sie können das JDK, das zum Ausführen von Gradle verwendet wird, jedoch im Dialogfeld Projektstruktur ändern. Wenn Sie diese Einstellung ändern, 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, wird nicht geändert.

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

In Android Studio 4.2 können Projekte geöffnet werden, die AGP 3.1 und höher verwenden, sofern AGP mit Gradle 4.8.1 und höher ausgeführt wird. Weitere Informationen zur Gradle-Kompatibilität finden Sie unter Gradle aktualisieren.

Gradle-Builds für JDK 11 optimieren

Diese Aktualisierung auf JDK 11 wirkt sich auf die Standardkonfiguration des JVM-Garbage Collectors aus, da JDK 8 den parallelen Garbage Collector und JDK 11 den G1-Garbage Collector verwendet.

Um die Build-Leistung möglicherweise zu verbessern, empfehlen wir, Ihre Gradle-Builds mit dem parallelen Garbage Collector zu testen. Legen Sie in 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 Build-Geschwindigkeit mit verschiedenen Konfigurationen finden Sie unter Build profilieren.

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

AGP verpackt DEX-Dateien jetzt standardmäßig unkomprimiert in APKs, wenn minSdk = 28 oder höher ist. Dadurch erhöht sich die APK-Größe, die Installationsgröße auf dem Gerät ist jedoch geringer und die Downloadgröße bleibt in etwa gleich.

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

android {
    packagingOptions {
        dex {
            useLegacyPackaging true
        }
    }
}

DSL zum Verpacken komprimierter nativer Bibliotheken verwenden

Wir empfehlen, native Bibliotheken unkomprimiert zu verpacken, da dies zu einer kleineren App-Installationsgröße, einer kleineren App-Downloadgröße und einer schnelleren App-Ladezeit für Ihre Nutzer führt. Wenn Sie jedoch möchten, dass das Android-Gradle-Plug-in komprimierte native Bibliotheken beim Erstellen Ihrer App verpackt, legen Sie useLegacyPackaging in der build.gradle-Datei Ihrer App auf true fest:

android {
    packagingOptions {
        jniLibs {
            useLegacyPackaging true
        }
    }
}

Das Flag useLegacyPackaging ersetzt das Manifestattribut extractNativeLibs. Weitere Informationen finden Sie in den Versionshinweisen unter Native libraries packaged uncompressed by default.