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

Kompatibilität

Mindestversion Standardversion 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 die Java-Sprachversion 8. 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-Ressourcen-Compiler

Ein neuer JVM-Ressourcen-Compiler im Android-Gradle-Plug-in 4.2 ersetzt Teile des AAPT2-Ressourcen-Compilers und kann so die Build-Leistung verbessern, insbesondere auf Windows-Computern. Der neue JVM-Ressourcen-Compiler ist standardmäßig aktiviert.

Unterstützung für v3- und v4-Signatur

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 dem APK-Signaturformat v4 und der inkrementellen APK-Installation über ADB können Sie in Android 11 schnell große APKs 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 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 C/C++-Compiler-Ausgabe 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 nicht im Stammprojekt, sondern in einem Unterprojekt 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. Ab Version 4.2 wird jedoch JDK 11 geliefert. Wenn Sie zum Ausführen von Gradle im Bundle enthaltene neue JDK 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 zwar, Gradle mit JDK 11 auszuführen, aber Sie können im Dialogfeld Projektstruktur ändern, welches JDK verwendet wird. 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.

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

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

Optimierung von Gradle-Builds für JDK 11

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 Profil für Build erstellen.

Unkomprimiertes Verpacken von 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
        }
    }
}

Verwendung der DSL für das Verpacken komprimierter nativer Bibliotheken

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 beim Erstellen Ihrer App native Bibliotheken komprimiert verpackt, legen Sie in der build.gradle-Datei Ihrer App useLegacyPackaging auf true fest:

android {
    packagingOptions {
        jniLibs {
            useLegacyPackaging true
        }
    }
}

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