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

Unterstützung für Kotlin Script DSL

Um die Bearbeitung für Nutzer von Kotlin-Buildskripts zu vereinfachen, werden 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:

• Nullwerte 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 das Erweitern von Android-Builds in Zukunft weniger fehleranfällig ist.

Wichtig: Wenn Sie bereits KTS-Build-Skripts verwenden oder Kotlin in buildSrc verwenden, kann dies zu Inkompatibilitäten bei der Quellcodekompatibilität für bestimmte Fehler führen, die in früheren Releases als Laufzeitfehler aufgetreten wären.

Sammlungstypen, die für die Mutation in der DSL vorgesehen sind, werden jetzt einheitlich so definiert:

val collection: MutableCollectionType

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

collection = collectionTypeOf(...)

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

Wenn Sie beim Aktualisieren eines Projekts, in dem Kotlin-APIs und die DSL des Android-Gradle-Plug-ins verwendet werden, Probleme feststellen, melden Sie bitte 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 ist es jetzt möglich, Bibliotheken aus Ihrem externen nativen Build in einer AAR-Datei für ein Android-Bibliotheksprojekt zu exportieren.

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

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 dem externen nativen Build mit ndk-build oder CMake in das von Ihrem Build erstellte AAR-Paket aufgenommen. Jede Bibliothek exportiert die Header aus dem angegebenen Verzeichnis an 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

In Kotlin werden benutzerdefinierte Metadaten in Java-Klassendateien verwendet, um Kotlin-Sprachkonstrukte zu identifizieren. R8 unterstützt jetzt das Beibehalten und Umschreiben von Kotlin-Metadaten, um das Verkleinern 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 Keep-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 auf Medium im Artikel Shrinking Kotlin libraries and applications using Kotlin reflection with R8{:.external}.

Assertions in Debug-Builds

Wenn Sie die Debug-Version Ihrer App mit dem Android-Gradle-Plug-in 4.1.0 oder höher erstellen, wird der Code Ihrer App vom integrierten Compiler (D8) so umgeschrieben, dass Zusicherungen zur Kompilierzeit aktiviert werden. So sind Zusicherungsprüfungen 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 Build-Zeit.

Die Aufgabe cleanBuildCache sowie die Attribute 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 Codeverkleinerung 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.

Die Eigenschaft „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 die Namespace-Zuweisung der R-Klasse jeder Bibliothek. Die R-Klasse enthält also nur die Ressourcen, 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 wurde umbenannt

Die Kotlin DSL-Kompilierungsoption coreLibraryDesugaringEnabled wurde in isCoreLibraryDesugaringEnabled geändert. Weitere Informationen zu diesem Flag finden Sie unter Unterstützung für Desugaring von Java 8+-APIs (Android-Gradle-Plug-in 4.0.0+).

Versionseigenschaften aus der BuildConfig-Klasse in Bibliotheksprojekten entfernt

Nur für Bibliotheksprojekte wurden die Eigenschaften 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 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 Attribute versionName und versionCode auch aus der DSL für Bibliotheken entfernt. Derzeit gibt es keine Möglichkeit, automatisch auf den App-Versionscode bzw. den App-Versionsnamen eines Bibliotheksunterprojekts zuzugreifen.

Bei Anwendungsmodulen ändert sich nichts. Sie können weiterhin Werte für versionCode und versionName in der DSL zuweisen. Diese Werte werden an das Manifest der App und die BuildConfig-Felder weitergegeben.

NDK-Pfad festlegen

Sie können den Pfad zu Ihrer lokalen NDK-Installation mit 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 beim Kompilieren und Ausführen von Unit-Tests für Bibliotheken geändert. Die Unittests einer Bibliothek werden jetzt mit den 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 Unit-Tests für Bibliotheken, die die Datenbindung verwenden, zu fehlenden DataBindingComponent- oder BR-Klassen kommen. Diese Tests müssen in einen instrumentierten Test im Projekt androidTest portiert werden, da das Kompilieren und Ausführen für diese Klassen in einem Einheitentest möglicherweise zu einer falschen Ausgabe führt.

io.fabric Gradle-Plug-in ist veraltet

Das Gradle-Plug-in „io.fabric“ ist veraltet 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 Upgrade auf das Firebase Crashlytics SDK.