Android Gradle Plugin 4.1.0 (August 2020)

Kompatibilität

<p>This version of the Android plugin requires the following:</p>
<ul>
  <li>
    <p><a href="https://docs.gradle.org/6.5.1/release-notes.html">Gradle 6.5</a>.
    To learn more, read the section about <a href="#updating-gradle">updating
    Gradle</a>.</p>
  </li>
  <li>
    <p><a href="/studio/releases/build-tools.html#notes">SDK Build Tools
    29.0.2</a> or higher.</p>
  </li>
</ul>
<p>The default NDK version in this release is 21.1.6352462. To install a
different NDK version, see <a href="/studio/projects/install-ndk#specific-version">Install a specific version of the NDK</a>.</p>

Neue Funktionen

Diese Version des Android Gradle-Plug-ins enthält die folgenden neuen Funktionen.

Kotlin Script DSL-Unterstützung

Um die Bearbeitung für Nutzer von Kotlin-Buildscripts zu verbessern, werden die DSL und APIs des Android Gradle-Plug-ins 4.1 jetzt in einer Reihe von Kotlin-Schnittstellen getrennt von ihren Implementierungsklassen definiert. Das bedeutet Folgendes:

• Nullbarkeit und Mutabilität werden jetzt explizit für Kotlin-Typen deklariert.
• Die aus diesen Schnittstellen generierte Dokumentation wird in der Kotlin API-Referenz veröffentlicht.
• Die API-Oberfläche des Android Gradle-Plug-ins ist klar definiert, damit die Erweiterung von Android-Builds in Zukunft weniger fehleranfällig ist.

Wichtig: Wenn Sie bereits KTS-Buildscripts verwenden oder Kotlin in buildSrc verwenden, kann dies zu Problemen mit der Quellkompatibilität bei bestimmten Fehlern führen, die sich in früheren Releases als Laufzeitfehler manifestiert hätten.

Sammlungstypen, die in der DSL mutiert werden sollen, werden jetzt einheitlich so definiert:

val collection: MutableCollectionType

Das bedeutet, dass für einige Sammlungen, die dies zuvor unterstützt haben, die folgenden Anweisungen nicht mehr in Kotlin-Scripts geschrieben werden können:

collection = collectionTypeOf(...)

Die Sammlung kann jedoch einheitlich mutiert werden, sodass collection += … und collection.add(...) jetzt überall funktionieren sollten.

Wenn Sie beim Upgrade eines Projekts, das Kotlin APIs und DSLs des Android Gradle-Plug-ins verwendet, Probleme feststellen, melden Sie bitte einen Fehler.

C/C++-Abhängigkeiten aus AARs exportieren

Mit dem Android-Gradle-Plug-in 4.0 können Sie Prefab-Pakete in AAR-Abhängigkeiten importieren. In AGP 4.1 ist es jetzt möglich, Bibliotheken aus Ihrem externen nativen Build in eine AAR für ein Android-Bibliotheksprojekt zu exportieren.

Wenn Sie Ihre nativen Bibliotheken exportieren möchten, fügen Sie dem android-Block der build.gradle-Datei Ihres Bibliotheksprojekts Folgendes hinzu:

buildFeatures {
    prefabPublishing true
}


prefab {
    <var>mylibrary</var&;gt {
      headers "src/main/cpp/<var>mylibrary</var>/include"
    }
<var>myotherlibrary</var> {
    headers "src/main/cpp/<var>myotherlibrary</var>/include"
}

}
      
buildFeatures {
    prefabPublishing = true
}


prefab {
    create("<var>mylibrary</var>") {
      headers = "src/main/cpp/<var>mylibrary</var>/include"
    }
create("<var>myotherlibrary</var>") {
    headers = "src/main/cpp/<var>myotherlibrary</var>/include"
}

}
      

In diesem Beispiel werden die Bibliotheken mylibrary und myotherlibrary aus Ihrem ndk-build- oder CMake-externen Native-Build in das AAR verpackt, das durch Ihren Build erstellt wird. Jede Bibliothek exportiert die Header aus dem angegebenen Verzeichnis in ihre abhängigen Elemente.

Hinweis:Für Nutzer des Android Gradle-Plug-ins 4.0 und höher haben sich die Konfigurationseinstellungen für den Import vorgefertigter nativer Bibliotheken geändert. Weitere Informationen finden Sie in den Versionshinweisen zur Version 4.0.

R8-Unterstützung für Kotlin-Metadaten

Kotlin verwendet benutzerdefinierte Metadaten in Java-Klassendateien, um Kotlin-Konstrukte zu identifizieren. R8 unterstützt jetzt die Pflege und Neuschreibung von Kotlin-Metadaten, um das Schrumpfen von Kotlin-Bibliotheken und ‑Anwendungen mit kotlin-reflect vollständig zu unterstützen.

Wenn Sie Kotlin-Metadaten beibehalten möchten, fügen Sie die folgenden Regeln hinzu:

-keep class kotlin.Metadata { *; }


-keepattributes RuntimeVisibleAnnotations

Dadurch wird R8 angewiesen, Kotlin-Metadaten für alle Klassen beizubehalten, die direkt beibehalten werden.

Weitere Informationen finden Sie im Medium-Artikel Shrinking Kotlin libraries and applications using Kotlin reflection with R8{:.external}.

Behauptungen in Debug-Builds

Wenn Sie die Debugversion Ihrer App mit dem Android Gradle-Plug-in 4.1.0 oder höher erstellen, wird der Code Ihrer App vom integrierten Compiler (D8) neu geschrieben, um Assertions zur Kompilierungszeit zu aktivieren. So sind Assertions immer aktiv.

Geändertes Verhalten

Build-Cache des Android-Gradle-Plug-ins entfernt

Der AGP-Build-Cache wurde in AGP 4.1 entfernt. Der AGP-Build-Cache wurde in AGP 2.3 als Ergänzung zum Gradle-Build-Cache eingeführt und in AGP 4.1 vollständig durch den Gradle-Build-Cache ersetzt. Diese Änderung hat keine Auswirkungen auf die Buildzeit.

Die Aufgabe cleanBuildCache und die Properties android.enableBuildCache und android.buildCacheDir werden nicht mehr unterstützt und in AGP 7.0 entfernt. Die Property android.enableBuildCache hat derzeit keine Auswirkungen. Die Property android.buildCacheDir und die Aufgabe cleanBuildCache sind bis AGP 7.0 zum Löschen vorhandener AGP-Build-Cache-Inhalte verfügbar.

App-Größe bei Apps mit Codekomprimierung deutlich reduziert

Ab dieser Version werden Felder aus R-Klassen nicht mehr standardmäßig beibehalten. Dies kann zu erheblichen Einsparungen bei der APK-Größe für Apps führen, bei denen das Schrumpfen von Code aktiviert ist. Das sollte keine Verhaltensänderung zur Folge haben, es sei denn, Sie greifen per Reflection auf R-Klassen zu. In diesem Fall müssen Sie für diese R-Klassen Aufbewahrungsregeln hinzufügen.

Die Property „android.namespacedRClass“ wurde in „android.nonTransitiveRClass“ umbenannt.

Das experimentelle Flag android.namespacedRClass wurde in android.nonTransitiveRClass umbenannt.

Dieses Flag wird in der Datei gradle.properties festgelegt und ermöglicht das Benennen der R-Klasse jeder Bibliothek so, dass sie nur die in der Bibliothek selbst deklarierten Ressourcen enthält und keine aus den Abhängigkeiten der Bibliothek. Dadurch wird die Größe der R-Klasse für diese Bibliothek reduziert.

Kotlin DSL: coreLibraryDesugaringEnabled umbenannt

Die Kotlin-DSL-Kompilierungsoption coreLibraryDesugaringEnabled wurde in isCoreLibraryDesugaringEnabled geändert. Weitere Informationen zu diesem Flag finden Sie unter Unterstützung für die Desugaring-API von Java 8 und höher (Android Gradle Plugin 4.0.0 und höher).

Versionseigenschaften wurden aus der BuildConfig-Klasse in Bibliotheksprojekten entfernt

Nur bei Bibliotheksprojekten wurden die Eigenschaften BuildConfig.VERSION_NAME und BuildConfig.VERSION_CODE aus der generierten BuildConfig-Klasse entfernt, da diese statischen Werte nicht die endgültigen Werte des Versionscodes und des Namens der Anwendung widerspiegelten und daher irreführend waren. Außerdem wurden diese Werte beim Zusammenführen des Manifests verworfen.

In einer zukünftigen Version des Android-Gradle-Plug-ins werden die Eigenschaften versionName und versionCode auch aus der DSL für Bibliotheken entfernt. Derzeit gibt es keine Möglichkeit, automatisch über ein Bibliotheks-Unterprojekt auf den Code/Namen der App-Version zuzugreifen.

Für Anwendungsmodule ändert sich nichts. Sie können weiterhin Werte für versionCode und versionName in der DSL festlegen. Diese Werte werden in das Manifest und die BuildConfig-Felder der App übernommen.

NDK-Pfad festlegen

Sie können den Pfad zu Ihrer lokalen NDK-Installation mithilfe der Eigenschaft android.ndkPath in der build.gradle-Datei Ihres Moduls festlegen.

android {
  ndkPath "your-custom-ndk-path"
}

android {
  ndkPath = "your-custom-ndk-path"
}

Wenn Sie diese Property zusammen mit der Property android.ndkVersion verwenden, muss dieser Pfad eine NDK-Version enthalten, die mit android.ndkVersion übereinstimmt.

Änderungen am Verhalten von Bibliotheks-Unittests

Wir haben das Verhalten der Kompilierung und Ausführung von Bibliotheks-Unit-Tests geändert. Die Unittests einer Bibliothek werden jetzt kompiliert und mit den Kompilierungs-/Laufzeitklassen der Bibliothek selbst ausgeführt. Dadurch wird die Bibliothek im Unittest auf die gleiche Weise verwendet wie externe Unterprojekte. Diese Konfiguration führt in der Regel zu besseren Tests.

In einigen Fällen können bei Bibliotheks-Unit-Tests, bei denen die Datenbindung verwendet wird, fehlende DataBindingComponent- oder BR-Klassen auftreten. Diese Tests müssen in einen instrumentierten Test im androidTest-Projekt übertragen werden, da das Kompilieren und Ausführen dieser Klassen in einem Unit-Test zu einer falschen Ausgabe führen kann.

Das io.fabric-Gradle-Plug-in wurde eingestellt

Das Gradle-Plug-in „io.fabric“ wird nicht mehr unterstützt und ist nicht mit Version 4.1 des Android-Gradle-Plug-ins kompatibel. Weitere Informationen zum eingestellten Fabric SDK und zur Migration zum Firebase Crashlytics SDK finden Sie unter Upgrade auf das Firebase Crashlytics SDK durchführen.