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 auf Modulebene
build.gradle.kts oder build.gradle 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,
und zeigt standardmäßig nur die C/C++-Compiler-Ausgabe an. 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-Property android.native.buildOutput auf verbose.
Sie können diese Property entweder in der gradle.properties Datei oder über die
Befehlszeile festlegen.
gradle.properties
android.native.buildOutput=verbose
Befehlszeile
-Pandroid.native.buildOutput=verbose
Der Standardwert dieser Property 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-Property 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 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 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.
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.
Optimierung von Gradle-Builds für JDK 11
Dieses Update 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:+UseParallelGCWenn in diesem Feld bereits andere Optionen festgelegt sind, fügen Sie eine neue Option hinzu:
org.gradle.jvmargs=-Xmx1536m -XX:+UseParallelGCInformationen 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.