Android-Gradle-Plug-in 4.1.0 (August 2020)

Kompatibilität

Mindestversion Standardversion Hinweise
Gradle 6.5 – Weitere Informationen finden Sie unter Gradle aktualisieren.
SDK-Build-Tools 29.0.2 29.0.2 Installieren oder konfigurieren Sie die SDK-Build-Tools.
NDK – 21.1.6352462 Installieren oder konfigurieren Sie eine andere Version des NDK. 

<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.

Unterstützung für Kotlin-Skript-DSL

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

  • Null-Zulässigkeit 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 Android-Builds in Zukunft weniger fehleranfällig sind.

Wichtig: Wenn Sie bereits KTS-Build-Skripte verwenden oder Kotlin in buildSrc, kann dies zu Inkompatibilitäten mit dem Quellcode für bestimmte Fehler führen die in früheren Versionen als Laufzeitfehler aufgetreten wären.

Sammlungstypen, die in der DSL geändert werden sollen, werden jetzt einheitlich definiert als:

val collection: MutableCollectionType

Das bedeutet, dass es nicht mehr möglich ist, in Kotlin-Skripten für einige Sammlungen, die dies zuvor unterstützt haben, Folgendes zu schreiben:

collection = collectionTypeOf(...)

Die Mutation der Sammlung wird jedoch einheitlich unterstützt, sodass collection += … und collection.add(...) jetzt überall funktionieren sollten.

Wenn Sie beim Upgrade eines Projekts, das Android-Gradle Plug-in-Kotlin-APIs und -DSL verwendet, auf Probleme stoßen, melden Sie einen Fehler.

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

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

Fügen Sie dazu 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 mylibrary und myotherlibrary Bibliotheken aus Ihrem externen nativen Build mit ndk-build oder CMake in der von Ihrem Build erstellten AAR verpackt. Jede Bibliothek exportiert die Header aus dem angegebenen Verzeichnis in ihre Abhängigkeiten.

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 zu Version 4.0.

R8-Unterstützung für Kotlin-Metadaten

Kotlin verwendet benutzerdefinierte Metadaten in Java-Klassendateien, um Kotlin-Sprachkonstrukte zu identifizieren. R8 unterstützt jetzt das Beibehalten und Umschreiben von Kotlin Metadaten, um die Komprimierung von Kotlin-Bibliotheken und -Anwendungen mit kotlin-reflect vollständig zu unterstützen.

Fügen Sie die folgenden Keep-Regeln hinzu, um Kotlin-Metadaten beizubehalten:

-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 unter Shrinking Kotlin libraries and applications using Kotlin reflection with R8{:.external} auf Medium.

Assertions in Debug-Builds

Wenn Sie die Debug-Version Ihrer App mit dem Android-Gradle-Plug-in 4.1.0 oder höher erstellen, schreibt der integrierte Compiler (D8) den Code Ihrer App neu, um Assertions zur Kompilierdauer zu ermöglichen. So sind Assertion-Prüfungen immer aktiv.

Geändertes Verhalten

Android-Gradle-Plug-in-Build-Cache 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 Build-Dauer.

Die Aufgabe cleanBuildCache sowie die Properties android.enableBuildCache und android.buildCacheDir sind veraltet und werden in AGP 7.0 entfernt. Die android.enableBuildCache-Property hat derzeit keine Auswirkungen, während die android.buildCacheDir-Property und der cleanBuildCache-Task bis AGP 7.0 funktionieren, um vorhandene Inhalte des AGP-Build-Cache zu löschen.

App-Größe für Apps mit Codekomprimierung deutlich reduziert

Ab dieser Version werden Felder aus R-Klassen nicht mehr standardmäßig beibehalten. Das kann zu einer erheblichen Reduzierung der APK-Größe bei Apps führen, bei denen die Codekomprimierung aktiviert ist. Dies sollte nicht zu einer Verhaltensänderung führen, es sei denn, Sie greifen über Reflection auf R-Klassen zu. In diesem Fall ist es erforderlich, Keep-Regeln für diese R-Klassen hinzuzufügen.

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

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

Wenn dieses Flag in der gradle.properties Datei festgelegt ist, wird für die R-Klasse jeder Bibliothek ein Namespace erstellt, sodass die R-Klasse 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 Entzuckerung von Java 8+-APIs (Android-Gradle-Plug-in 4.0.0+).

Versions-Properties aus der BuildConfig-Klasse in Bibliotheksprojekten entfernt

Nur für Bibliotheksprojekte wurden die BuildConfig.VERSION_NAME und BuildConfig.VERSION_CODE Properties aus der generierten BuildConfig Klasse entfernt, da diese statischen Werte nicht die endgültigen Werte des Versionscodes und -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 versionName und versionCode Properties auch aus der DSL für Bibliotheken entfernt. Derzeit gibt es keine Möglichkeit, automatisch auf den App-Versionscode/-namen aus einem Bibliotheksunterprojekt zuzugreifen.

Für Anwendungsmodule gibt es keine Änderung. Sie können weiterhin Werte für versionCode und versionName in der DSL zuweisen. Diese Werte werden an das Manifest und die BuildConfig Felder der App weitergegeben.

NDK-Pfad festlegen

Sie können den Pfad zu Ihrer lokalen NDK-Installation mit der android.ndkPath Property 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 android.ndkVersion Property, verwenden, muss dieser Pfad eine NDK-Version enthalten, die mit android.ndkVersion übereinstimmt.

Verhaltensänderungen bei Unittests für Bibliotheken

Wir haben das Verhalten beim Kompilieren und Ausführen von Unittests für Bibliotheken geändert. Die Unittests einer Bibliothek werden jetzt für die Kompilierungs-/Laufzeitklassen der Bibliothek selbst kompiliert und ausgeführt. Dadurch wird die Bibliothek im Unittest auf dieselbe Weise verwendet wie in externen Unterprojekten. Diese Konfiguration führt in der Regel zu besseren Tests.

In einigen Fällen kann es bei Unittests für Bibliotheken, die die Datenbindung verwenden, zu fehlenden DataBindingComponent- oder BR-Klassen kommen. Diese Tests müssen in einen Instrumentierungstest im Projekt androidTest portiert werden, da das Kompilieren und Ausführen für diese Klassen in einem Unittest möglicherweise zu einer falschen Ausgabe führt.

Gradle-Plug-in „io.fabric“ eingestellt

Das Gradle-Plug-in „io.fabric“ ist eingestellt und 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 Auf das Firebase Crashlytics SDK upgraden.