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.
Standardmäßig Java-Version 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 Methoden für statische Schnittstellen. 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 in der Datei build.gradle.kts
oder build.gradle
auf Modulebene explizit Java 7 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-Ressourcencompiler im Android-Gradle-Plug-in 4.2 ersetzt Teile des AAPT2-Ressourcencompilers, wodurch die Build-Leistung insbesondere auf Windows-Computern möglicherweise verbessert wird. 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.
Um eines oder beide dieser Formate in Ihrem Build zu aktivieren, 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 können Sie unter Android 11 schnell große APKs über die inkrementelle ADB-APK-Installation 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 jede Variante zu aktivieren oder zu deaktivieren.
In diesem Beispiel wird gezeigt, wie Sie die App-Signatur pro Variante mithilfe der Methode onVariants()
in Kotlin oder Groovy einrichten:
androidComponents {
onVariants(selector().withName("fooDebug"), {
signingConfig.enableV1Signing.set(false)
signingConfig.enableV2Signing.set(true)
})
Neues Gradle-Attribut: 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 die C/C++-Compilerausgabe an. Bisher wurde für jede erstellte Datei eine Ausgabezeile generiert, was zu einer großen Menge an Informationsnachrichten 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 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-Attribute aus Unterprojekten zu überschreiben. Mit anderen Worten: Wenn Sie ein Attribut in einer gradle.properties
-Datei in einem Unterprojekt anstelle des Stammprojekts deklarieren, wird dies 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 dasselbe Gradle-Attribut sowohl in <var>projectDir</var>/gradle.properties
als auch in <var>projectDir</var>/app/gradle.properties
vorhanden war, hatte der Wert von <var>projectDir</var>/app/gradle.properties
Vorrang.
In AGP 4.2 hat sich 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 Caching von Konfigurationen.
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 Releases war JDK 8 in Studio enthalten. In 4.2 ist jetzt jedoch 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äten oder zu Leistungseinbußen bei der JVM führen. Diese Probleme werden im Folgenden beschrieben.
Hinweis:Wir empfehlen, Gradle mit JDK 11 auszuführen. Es ist aber möglich, das zur Ausführung von Gradle verwendete JDK im Dialogfeld Projektstruktur zu ändern. Durch das Ändern dieser Einstellung wird nur das JDK geändert, mit dem Gradle ausgeführt wird. Das JDK, mit dem Studio ausgeführt wird, 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 oder höher verwenden, sofern in AGP Gradle 4.8.1 oder höher ausgeführt wird. Weitere Informationen zur Gradle-Kompatibilität finden Sie unter Gradle aktualisieren.
Gradle-Builds für JDK 11 optimieren
Dieses Update auf JDK 11 wirkt sich auf die Standardkonfiguration der JVM-automatischen Speicherbereinigung aus, da JDK 8 die parallele automatische Speicherbereinigung und JDK 11 den G1-automatischen Speicherbereinigung verwendet.
Wenn Sie die Build-Leistung verbessern möchten, empfehlen wir, Ihre Gradle-Builds mit der parallelen Speicherbereinigung 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 hinzu:
org.gradle.jvmargs=-Xmx1536m -XX:+UseParallelGC
Informationen zum Messen der Build-Geschwindigkeit mit verschiedenen Konfigurationen finden Sie unter Build-Profil erstellen.
Dekomprimierte DEX-Dateien in APKs, wenn minSdk
= 28 oder höher ist
AGP verpackt jetzt standardmäßig unkomprimierte DEX-Dateien in APKs, wenn minSdk
= 28 oder höher ist. Das führt zu einer größeren APK-Größe, verringert aber die Installationsgröße auf dem Gerät und die Downloadgröße ist ungefähr 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
}
}
}
Mit DSL komprimierte native Bibliotheken verpacken
Wir empfehlen, native Bibliotheken in unkomprimierter Form zu packen. Das führt zu einer geringeren App-Installationsgröße, einer geringeren App-Downloadgröße und kürzeren App-Ladezeiten. Wenn Sie jedoch möchten, dass das Android-Gradle-Plug-in beim Erstellen Ihrer App komprimierte native Bibliotheken verpackt, setzen Sie useLegacyPackaging
in der Datei build.gradle
Ihrer App auf true
:
android {
packagingOptions {
jniLibs {
useLegacyPackaging true
}
}
}
Das Flag useLegacyPackaging
ersetzt das Manifestattribut extractNativeLibs
. Weitere Informationen finden Sie in der Versionshinweise zu Standardmäßig unkomprimiert verpackte native Bibliotheken.