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.