Android Gradle-Plug-in 4.1.0 (August 2020)

Kompatibilität

Für diese Version des Android-Plug-ins ist Folgendes erforderlich:

• Gradle 6.5 Weitere Informationen finden Sie im Abschnitt zum Aktualisieren von Gradle.

• SDK Build Tools 29.0.2 oder höher.

Die NDK-Standardversion in diesem Release ist 21.1.6352462. Informationen zum Installieren einer anderen NDK-Version finden Sie unter Bestimmte Version des NDK installieren.

Neue Funktionen

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

DSL-Unterstützung für Kotlin-Skript

Um die Bearbeitung für Kotlin-Buildscript-Nutzer zu verbessern, sind die DSL und die 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 Veränderlichkeit werden jetzt explizit für Kotlin-Typen deklariert.
• Die über diese Schnittstellen generierte Dokumentation finden Sie in der Kotlin API-Referenz.
• Die API-Oberfläche des Android Gradle-Plug-ins ist klar definiert, um das Erweitern von Android-Builds in Zukunft weniger kompliziert zu gestalten.

Wichtig: Wenn du bereits KTS-Build-Scripts verwendest oder Kotlin in buildSrc verwendest, kann dies bei bestimmten Fehlern, die in früheren Releases als Laufzeitfehler zu sehen waren, zu Problemen bei der Quellkompatibilität führen.

Sammlungstypen, die in DSL geändert werden sollen, werden nun einheitlich so definiert:

val collection: MutableCollectionType

Daher ist es nicht mehr möglich, Folgendes in Kotlin-Skripts für einige Sammlungen zu schreiben, in denen sie zuvor unterstützt wurden:

collection = collectionTypeOf(...)

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

Sollten beim Upgrade eines Projekts, das die Kotlin-APIs des Android-Gradle-Plug-ins und DSL verwendet, Probleme auftreten, melden Sie einen Fehler.

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

Das Android-Gradle-Plug-in 4.0 bietet jetzt die Möglichkeit, Prefab-Pakete in AAR-Abhängigkeiten zu importieren. In AGP 4.1 ist es jetzt möglich, Bibliotheken aus Ihrem externen nativen Build in ein AAR für ein Android Library-Projekt zu exportieren.

Zum Exportieren nativer Bibliotheken 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 mylibrary- und myotherlibrary-Bibliotheken aus dem externen nativen Build ndk-build oder CMake in das von Ihrem Build erstellte AAR verpackt. Jede dieser Bibliotheken 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 das Importieren vordefinierter nativer Bibliotheken geändert. Weitere Informationen finden Sie in den Versionshinweisen für 4.0.

R8-Unterstützung für Kotlin-Metadaten

Kotlin verwendet benutzerdefinierte Metadaten in Java-Klassendateien, um Kotlin-Sprachkonstrukte zu identifizieren. R8 bietet jetzt Unterstützung für das Verwalten und Umschreiben von Kotlin-Metadaten, um die Verkleinerung von Kotlin-Bibliotheken und -Anwendungen mithilfe von kotlin-reflect vollständig zu unterstützen.

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

-keep class kotlin.Metadata { *; }


-keepattributes RuntimeVisibleAnnotations

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

Weitere Informationen finden Sie auf Medium unter Kotlin-Bibliotheken und -Anwendungen mithilfe von Kotlin-Reflexion mit R8 verkleinern {:.external}.

Assertions in Debug-Builds

Wenn Sie die Debug-Version Ihrer App mit dem Android-Gradle-Plug-in 4.1.0 und höher erstellen, schreibt der integrierte Compiler (D8) den Code Ihrer App um, um Assertions bei der Kompilierung zu aktivieren, sodass immer Assertion-Prüfungen aktiviert sind.

Änderungen des Verhaltens

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 des Gradle-Build-Cache eingeführt und wurde in AGP 4.1 vollständig durch den Gradle-Build-Cache ersetzt. Diese Änderung hat keine Auswirkungen auf die Build-Dauer.

Die Aufgabe cleanBuildCache und die Attribute android.enableBuildCache und android.buildCacheDir wurden verworfen und werden in AGP 7.0 entfernt. Das Attribut android.enableBuildCache hat derzeit keine Auswirkungen. Die Attribute android.buildCacheDir und die Aufgabe cleanBuildCache können bis AGP 7.0 verwendet werden, um vorhandene AGP-Build-Cache-Inhalte zu löschen.

Die App-Größe wurde für Anwendungen mit Codeverkleinerung erheblich reduziert.

Ab diesem Release werden Felder aus R-Klassen nicht mehr standardmäßig beibehalten. Dies kann zu erheblichen Einsparungen bei der APK-Größe bei Apps führen, bei denen das Verkleinern des Codes möglich ist. Dies sollte nicht zu einer Verhaltensänderung führen, es sei denn, Sie greifen über Reflexion auf R-Klassen zu. In diesem Fall müssen Sie für diese R-Klassen Aufbewahrungsregeln hinzufügen.

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

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

Dieses Flag wird in der Datei gradle.properties festgelegt und ermöglicht die Namespaces der R-Klasse jeder Bibliothek, sodass ihre R-Klasse nur die Ressourcen enthält, die in der Bibliothek selbst deklariert sind, 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 findest du unter Unterstützung des JavaScript API-Tools für die Java 8+ API (Android Gradle-Plug-in 4.0.0 oder höher).

Versionsattribute aus Bibliotheksprojekten aus der BuildConfig-Klasse entfernt

Nur für Bibliotheksprojekte wurden die Attribute BuildConfig.VERSION_NAME und BuildConfig.VERSION_CODE aus der generierten Klasse BuildConfig entfernt, da diese statischen Werte nicht die endgültigen Werte des Versionscodes und -namens der Anwendung widerspiegeln und daher irreführend waren. Außerdem wurden diese Werte bei der Zusammenführung der Manifeste verworfen.

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

Bei Anwendungsmodulen gibt es keine Änderung. Sie können versionCode und versionName in der DSL weiterhin Werte zuweisen. Diese Werte werden an das Manifest und die BuildConfig-Felder der App weitergegeben.

NDK-Pfad festlegen

Du kannst den Pfad zu deiner lokalen NDK-Installation mithilfe des Attributs android.ndkPath in der build.gradle-Datei deines Moduls festlegen.

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

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

Wenn Sie dieses Attribut zusammen mit dem Attribut android.ndkVersion verwenden, muss dieser Pfad eine NDK-Version enthalten, die mit android.ndkVersion übereinstimmt.

Änderungen am Verhalten des Bibliothekstests

Wir haben das Verhalten beim Kompilieren und Ausführen von Bibliothekseinheitentests geändert. Die Einheitentests einer Bibliothek werden jetzt kompiliert und mit Compile-/Laufzeitklassen der Bibliothek selbst ausgeführt. Dadurch wird die Bibliothek vom Einheitentest wie bei externen Unterprojekten genutzt. Diese Konfiguration führt in der Regel zu besseren Tests.

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

Gradle-Plug-in „io.fabric“ verworfen

Das io.fabric-Gradle-Plug-in wurde verworfen 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.