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 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-Version 8

Ab Version 4.2 verwendet AGP standardmäßig die Java 8-Sprachebene. Java 8 bietet Zugriff auf eine Reihe neuerer Sprachfunktionen, einschließlich Lambda-Ausdrücke, Methodenreferenzen und Methoden für statische Schnittstellen. 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 in der Datei build.gradle.kts oder build.gradle auf Modulebene explizit Java 7 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-Ressourcen-Compiler

Ein neuer JVM-Ressourcencompiler im Android-Gradle-Plug-in 4.2 ersetzt Teile des AAPT2-Ressourcencompilers, wodurch die Build-Leistung insbesondere auf Windows-Computern möglicherweise verbessert wird. Der neue JVM-Ressourcen-Compiler ist standardmäßig aktiviert.

v3- und v4-Signaturen werden jetzt unterstützt

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

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

Mit der APK v4-Signatur können Sie unter Android 11 schnell große APKs über die inkrementelle ADB-APK-Installation bereitstellen. Dieses neue Flag übernimmt den APK-Signaturschritt im Bereitstellungsprozess.

App-Signatur pro Variante konfigurieren

Im Android-Gradle-Plug-in ist es jetzt möglich, die App-Signatur für jede Variante zu aktivieren oder zu deaktivieren.

In diesem Beispiel wird gezeigt, wie Sie die App-Signatur pro Variante mithilfe der Methode onVariants() in Kotlin oder Groovy einrichten:

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

Neues Gradle-Attribut: android.native.buildOutput

Um Unordnung in der Build-Ausgabe zu vermeiden, filtert AGP 4.2 Nachrichten aus nativen Builds, die CMake und ndk-build verwenden, und zeigt standardmäßig nur die C/C++-Compilerausgabe an. Bisher wurde für jede erstellte Datei eine Ausgabezeile generiert, was zu einer großen Menge an Informationsnachrichten 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 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-Attribute aus Unterprojekten zu überschreiben. Mit anderen Worten: Wenn Sie ein Attribut in einer gradle.properties-Datei in einem Unterprojekt anstelle des Stammprojekts deklarieren, wird dies ignoriert.

In früheren Releases 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 bei App-Modulen dasselbe Gradle-Attribut sowohl in <var>projectDir</var>/gradle.properties als auch in <var>projectDir</var>/app/gradle.properties vorhanden war, hatte der Wert von <var>projectDir</var>/app/gradle.properties Vorrang.

In AGP 4.2 hat sich dieses Verhalten geändert und AGP lädt keine Werte aus gradle.properties in Unterprojekten (z.B. <var>projectDir</var>/app/gradle.properties). Diese Änderung spiegelt das neue Gradle-Verhalten wider und unterstützt das Caching von Konfigurationen.

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 gebündelte JDK von Studio. In früheren Releases war JDK 8 in Studio enthalten. In 4.2 ist jetzt jedoch JDK 11 gebündelt. Wenn Sie das neue gebündelte JDK zum Ausführen von Gradle verwenden, kann dies aufgrund von Änderungen an der automatischen Speicherbereinigung zu Inkompatibilitäten oder zu Leistungseinbußen bei der JVM führen. Diese Probleme werden im Folgenden beschrieben.

Hinweis:Wir empfehlen, Gradle mit JDK 11 auszuführen. Es ist aber möglich, das zur Ausführung von Gradle verwendete JDK im Dialogfeld Projektstruktur zu ändern. Durch das Ändern dieser Einstellung wird nur das JDK geändert, mit dem Gradle ausgeführt wird. Das JDK, mit dem Studio ausgeführt wird, bleibt unverändert.

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

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

Gradle-Builds für JDK 11 optimieren

Dieses Update auf JDK 11 wirkt sich auf die Standardkonfiguration der JVM-automatischen Speicherbereinigung aus, da JDK 8 die parallele automatische Speicherbereinigung und JDK 11 den G1-automatischen Speicherbereinigung verwendet.

Wenn Sie die Build-Leistung verbessern möchten, empfehlen wir, Ihre Gradle-Builds mit der parallelen Speicherbereinigung 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 hinzu:

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

Informationen zum Messen der Build-Geschwindigkeit mit verschiedenen Konfigurationen finden Sie unter Build-Profil erstellen.

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

AGP verpackt jetzt standardmäßig unkomprimierte DEX-Dateien in APKs, wenn minSdk = 28 oder höher ist. Das führt zu einer größeren APK-Größe, verringert aber die Installationsgröße auf dem Gerät und die Downloadgröße ist ungefähr gleich.

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

android {
    packagingOptions {
        dex {
            useLegacyPackaging true
        }
    }
}

Mit DSL komprimierte native Bibliotheken verpacken

Wir empfehlen, native Bibliotheken in unkomprimierter Form zu packen. Das führt zu einer geringeren App-Installationsgröße, einer geringeren App-Downloadgröße und kürzeren App-Ladezeiten. Wenn Sie jedoch möchten, dass das Android-Gradle-Plug-in beim Erstellen Ihrer App komprimierte native Bibliotheken verpackt, setzen Sie useLegacyPackaging in der Datei build.gradle Ihrer App auf true:

android {
    packagingOptions {
        jniLibs {
            useLegacyPackaging true
        }
    }
}

Das Flag useLegacyPackaging ersetzt das Manifestattribut extractNativeLibs. Weitere Informationen finden Sie in der Versionshinweise zu Standardmäßig unkomprimiert verpackte native Bibliotheken.