Android Gradle Plugin 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.
Java-Sprachversion 8 als Standard
Ab Version 4.2 verwendet AGP standardmäßig die Java 8-Sprachebene. Java 8 bietet Zugriff auf eine Reihe neuerer Sprachfunktionen, darunter Lambdaausdrü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 in der Datei build.gradle.kts
oder build.gradle
auf Modulebene explizit 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-Plug-in 4.2 ersetzt Teile des AAPT2-Ressourcencompilers. Dadurch kann die Build-Leistung insbesondere auf Windows-Computern verbessert werden. Der neue JVM-Ressourcencompiler ist standardmäßig aktiviert.
Signatur von Version 3 und 4 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 Eigenschaften hinzu:
// build.gradle
android {
...
signingConfigs {
config {
...
enableV3Signing true
enableV4Signing true
}
}
}
// build.gradle.kts
android {
...
signingConfigs {
config {
...
enableV3Signing = true
enableV4Signing = true
}
}
}
Mit der APK-Signatur Version 4 können Sie große APKs mit der inkrementellen APK-Installation von ADB unter Android 11 schnell 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 für jede 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-Eigenschaft:
android.native.buildOutput
Um die Build-Ausgabe übersichtlich zu gestalten, filtert AGP 4.2 Nachrichten aus nativen Builds heraus, die CMake und ndk-build
verwenden. Standardmäßig wird nur die C/C++-Compilerausgabe angezeigt. 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-Eigenschaft android.native.buildOutput
auf verbose
.
Sie können diese Eigenschaft 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 Property ist quiet
.
Verhaltensänderung bei gradle.properties-Dateien
Ab AGP 4.2 ist es nicht mehr möglich, Gradle-Properties aus Unterprojekten zu überschreiben. Wenn Sie also eine Property in einer gradle.properties
-Datei in einem untergeordneten Projekt anstelle des Stammprojekts deklarieren, wird sie ignoriert.
In früheren Releases las AGP beispielsweise Werte aus <var>projectDir</var>/gradle.properties
, <var>projectDir</var>/app/gradle.properties
, <var>projectDir</var>/library/gradle.properties
usw. Wenn für App-Module dieselbe Gradle-Eigenschaft 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 untergeordnete Projekte (z. B.
<var>projectDir</var>/app/gradle.properties
).
Diese Änderung entspricht dem neuen Gradle-Verhalten und unterstützt das Caching von Konfigurationen.
Weitere Informationen zum Festlegen von Werten in gradle.properties
-Dateien finden Sie in der Gradle-Dokumentation.
Änderungen an der Gradle-Kompatibilität und -Konfiguration
Wenn das Gradle-Build-Tool in Android Studio ausgeführt wird, verwendet es das mitgelieferte JDK von Studio. In früheren Releases war JDK 8 im Lieferumfang von Studio enthalten. In Version 4.2 ist stattdessen JDK 11 enthalten. Wenn Sie das neue mitgelieferte JDK zum Ausführen von Gradle verwenden, kann dies aufgrund von Änderungen am Garbage Collector zu Inkompatibilitäten oder Leistungseinbußen 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. Durch Ändern dieser Einstellung 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, bleibt unverändert.
Kompatibilität von Studio 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 AGP Gradle 4.8.1 oder höher ausführt. Weitere Informationen zur Kompatibilität von Gradle finden Sie unter Gradle aktualisieren.
Gradle-Builds für JDK 11 optimieren
Dieses Update auf JDK 11 wirkt sich auf die Standardkonfiguration des JVM-Garbage-Collectors aus, da in JDK 8 der parallele Garbage-Collector verwendet wird, während in JDK 11 der G1-Garbage-Collector verwendet wird.
Um die Build-Leistung zu verbessern, empfehlen wir, Ihre Gradle-Builds mit dem parallelen Garbage Collector zu testen. Legen Sie unter 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 Buildgeschwindigkeit mit verschiedenen Konfigurationen finden Sie unter Build analysieren.
DEX-Dateien in APKs unkomprimiert, wenn 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 Erhöhung der APK-Größe, aber zu einer kleineren Installationsgröße auf dem Gerät. Die Downloadgröße bleibt dabei ungefähr gleich.
Wenn Sie AGP zwingen möchten, die DEX-Dateien stattdessen komprimiert zu verpacken, können Sie der Datei build.gradle
Folgendes hinzufügen:
android {
packagingOptions {
dex {
useLegacyPackaging true
}
}
}
Komprimierte native Bibliotheken mit der DSL verpacken
Wir empfehlen, native Bibliotheken in unkomprimierter Form zu verpacken, da dies zu einer geringeren App-Installationsgröße, einer geringeren App-Downloadgröße und einer kürzeren App-Ladezeit für Ihre Nutzer führt. Wenn das Android Gradle-Plug-in jedoch komprimierte native Bibliotheken beim Erstellen Ihrer App verpacken soll, setzen Sie in der build.gradle
-Datei Ihrer App useLegacyPackaging
auf true
:
android {
packagingOptions {
jniLibs {
useLegacyPackaging true
}
}
}
Das Flag useLegacyPackaging
ersetzt das Manifestattribut extractNativeLibs
. Weitere Informationen finden Sie in den Versionshinweisen Native Bibliotheken werden standardmäßig unkomprimiert verpackt.