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 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, einschließlich Lambda. Methodenreferenzen und statischen Schnittstellenmethoden. Zur vollständigen 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-Ressourcen-Compiler
Ein neuer JVM-Ressourcen-Compiler im Android-Gradle-Plug-in 4.2-Tool ersetzt Teile des AAPT2-Ressourcen-Compilers, möglicherweise die Build-Leistung verbessert, insbesondere auf Windows-Computern. Die neue JVM Der Ressourcen-Compiler ist standardmäßig aktiviert.
v3- und v4-Signaturen werden jetzt unterstützt
Android-Gradle-Plug-in 4.2 unterstützt jetzt 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 v4-Signatur können Sie große APKs schnell über den ADB-Standard bereitstellen. Inkrementelle APK-Installation in Android 11 Dieses neue Flag übernimmt den APK-Signaturschritt in der Bereitstellung .
App-Signatur pro Variante konfigurieren
In Android-Gradle ist es jetzt möglich, die App-Signatur zu aktivieren oder zu deaktivieren. Plug-in pro Variante.
In diesem Beispiel wird gezeigt, wie Sie die App-Signatur pro Variante mit dem
onVariants()
in Kotlin oder Groovy:
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, die CMake und ndk-build
verwenden. Standardmäßig wird nur die C/C++-Compilerausgabe angezeigt. Zuvor wurde eine Ausgabezeile
für jede erstellte Datei generiert wurde, was zu einer großen Anzahl
zu informieren.
Wenn Sie die gesamte native Ausgabe sehen möchten, legen 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.
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 zu überschreiben
aus Unterprojekten. Wenn Sie also eine Property in einem
Datei gradle.properties
in einem Unterprojekt anstelle des Stammverzeichnisses
wird er 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 spiegelt die
neues 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
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 Allerdings ist jetzt stattdessen JDK 11 gebündelt. 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 zwar, Gradle mit JDK 11 auszuführen, es ist jedoch das zum Ausführen von Gradle verwendete JDK im Projektstruktur Dialogfeld. 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)
Android Studio 4.2 kann Projekte öffnen, die AGP 3.1 und vorausgesetzt, in AGP wird Gradle 4.8.1 und höher ausgeführt. Weitere Informationen Informationen zur Gradle-Kompatibilität finden Sie unter Aktualisiere Gradle.
Gradle-Builds für JDK 11 optimieren
Diese Aktualisierung des JDK 11 wirkt sich auf die Standardkonfiguration des JVM-Speichers aus Collector, da JDK 8 den parallelen Garbage Collector verwendet, während JDK 11 die G1-Speicherbereinigung.
Um die Build-Leistung 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 Buildgeschwindigkeit mit verschiedenen Konfigurationen finden Sie unter Builds 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 liegen. Dies führt zu einer höheren APK-Größe,
auf dem Gerät installiert ist und die Downloadgröße ungefähr gleich ist.
Um zu erzwingen, dass AGP die DEX-Dateien stattdessen komprimiert verpackt, können Sie den Parameter
Folgendes zu Ihrer build.gradle
-Datei 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
beim Erstellen der App komprimierte native Bibliotheken verpacken,
useLegacyPackaging
in true
in der build.gradle
-Datei Ihrer App:
android {
packagingOptions {
jniLibs {
useLegacyPackaging true
}
}
}
Das Flag useLegacyPackaging
ersetzt das Manifestattribut extractNativeLibs
. Weitere Informationen finden Sie in den Versionshinweisen.
Native Bibliotheken, die standardmäßig unkomprimiert verpackt sind.