Diese Seite wurde von der Cloud Translation API übersetzt.

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. Methodenreferenzen und statischen Schnittstellenmethoden. Zur vollständigen Liste der unterstützten Funktionen finden Sie in der Java 8-Dokumentation.

Um das alte Verhalten beizubehalten, geben Sie Java 7 explizit in Ihrer Modulebene an. Datei build.gradle.kts oder build.gradle:

// 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. Um eines oder beide dieser Formate in Ihrem erstellen, fügen Sie dem build.gradle auf Modulebene die folgenden Attribute hinzu oder build.gradle.kts-Datei:

// 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`

AGP 4.2 filtert Nachrichten, um für mehr Ordnung in der Build-Ausgabe zu sorgen aus nativen Builds, die CMake und ndk-build verwenden, Zeigt standardmäßig nur die C/C++-Compiler-Ausgabe an. 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 Versionen würde AGP beispielsweise Werte aus <var>projectDir</var>/gradle.properties, <var>projectDir</var>/app/gradle.properties, <var>projectDir</var>/library/gradle.properties, Wenn bei App-Modulen dieselbe Gradle-Eigenschaft in beiden <var>projectDir</var>/gradle.properties und <var>projectDir</var>/app/gradle.properties, den Wert von <var>projectDir</var>/app/gradle.properties Vorrang haben.

In AGP 4.2 wurde dieses Verhalten geändert. gradle.properties in Teilprojekten (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 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 Stattdessen ist jetzt jedoch JDK 11 gebündelt. Bei Verwendung des neuen gebündelten JDK für die Ausführung Gradle verwendet werden, kann dies zu Inkompatibilitäten führen oder die JVM-Leistung beeinträchtigen. aufgrund von Änderungen an der automatischen Speicherbereinigung. Diese Probleme werden im Folgenden 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. Wenn Sie diese Einstellung ändern, wird nur das JDK geändert, das zum Ausführen von Gradle verwendet wird. hat keine Auswirkungen auf das JDK, das zum Ausführen von Studio verwendet wird.

Studio-Kompatibilität mit 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 potenziell zu verbessern, empfehlen wir Sie testen Ihre Gradle-Builds mit der parallelen automatischen Speicherbereinigung. 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 Erstellen Sie ein Profil für Ihren Build.

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 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 mithilfe von DSL verpacken

Wir empfehlen, native Bibliotheken unkomprimiert zu verpacken, führt zu einer kleineren App-Installationsgröße, einer geringeren Downloadgröße und einer schnelleren App der Ladezeiten für Ihre Nutzer. 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.