Android-Gradle-Plug-in 4.2.0 (März 2021)

Kompatibilität

Neue Funktionen

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

Java-Sprachversion 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 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-Ressourcen-Compiler

Ein neuer JVM-Ressourcen-Compiler im Android-Gradle-Plug-in 4.2 ersetzt Teile des AAPT2-Ressourcen-Compilers und verbessert möglicherweise die Build-Leistung, insbesondere auf Windows-Computern. 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. 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 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 kannst du große APKs schnell mithilfe der inkrementellen ADB-APK-Installation unter Android 11 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 einzelne Varianten zu aktivieren oder zu deaktivieren.

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

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

Neue Gradle-Eigenschaft: 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 C/C++-Compiler-Ausgaben an. Zuvor 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 das neue Gradle-Attribut 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 dieses Attributs 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. Wenn Sie also ein Attribut in einer gradle.properties-Datei in einem untergeordneten Projekt statt im Stammprojekt deklarieren, wird es 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 dieselbe Gradle-Property sowohl in <var>projectDir</var>/gradle.properties als auch in <var>projectDir</var>/app/gradle.properties vorhanden ist, hat der Wert aus <var>projectDir</var>/app/gradle.properties Vorrang.

In AGP 4.2 wurde 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 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 gebündelte JDK von Studio. In früheren Versionen war JDK 8 mit Studio gebündelt. In Version 4.2 ist stattdessen 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ät oder zu einer geringeren JVM-Leistung führen. Diese Probleme werden im Folgenden beschrieben.

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 und höher verwenden, sofern in AGP 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 des JDK 11 wirkt sich auf die Standardkonfiguration des JVM Garbage Collector aus, da JDK 8 die parallele automatische Speicherbereinigung verwendet, während JDK 11 den G1-Garbage Collector verwendet.

Wenn Sie die Build-Leistung potenziell verbessern möchten, sollten Sie Ihre Gradle-Builds mit dem parallelen Garbage Collector 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-Profil erstellen.

Unkomprimierte DEX-Dateien in APKs bei 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 höheren APK-Größe, aber auch zu einer geringeren Installationsgröße auf dem Gerät. Die Downloadgröße ist in etwa 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
        }
    }
}

Komprimierte native Bibliotheken mithilfe von DSL verpacken

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

android {
    packagingOptions {
        jniLibs {
            useLegacyPackaging true
        }
    }
}

Das Flag useLegacyPackaging ersetzt das Manifestattribut extractNativeLibs. Weitere Informationen finden Sie im Versionshinweise Standardmäßig unkomprimierte native Bibliotheken.