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.
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.
Hinweis:Wir empfehlen zwar, Gradle mit JDK 11 auszuführen. Sie können aber das zum Ausführen von Gradle verwendete JDK im Dialogfeld Projektstruktur ändern. Wenn Sie diese Einstellung ändern, wird nur das JDK geändert, mit dem Gradle ausgeführt wird. Das zum Ausführen von Studio verwendete JDK 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 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.