Android Gradle-Plug-in 7.1.0 (Januar 2022)

Das Android Gradle-Plug-in 7.1.0 ist eine Hauptversion, die eine Vielzahl neuer Funktionen und Verbesserungen enthält.

Kompatibilität

	Mindestversion	Standardversio
Gradle	7,2	7,2
SDK-Build-Tools	30.0.3	30.0.3
Logo: NDK	–	21.4.7075529
JDK	11	11

Lint-Analyseaufgabe ist jetzt im Cache speicherbar

AndroidLintAnalysisTask ist jetzt mit dem Gradle-Build-Cache kompatibel. Wenn Sie den Build-Cache aktivieren, indem Sie org.gradle.caching=true in der Datei gradle.properties festlegen, erhält die Lint-Analyseaufgabe nach Möglichkeit ihre Ausgabe aus dem Build-Cache.

Die Lint-Analyse ist oft der größte Engpass, wenn Lint mit dem Android-Gradle-Plug-in ausgeführt wird. Daher verbessert die Aktivierung des Build-Cache die Build-Geschwindigkeit, wenn Lint in vielen Situationen ausgeführt wird. Sie sollten eine deutliche Leistungsverbesserung feststellen können, z. B. wenn Sie ein Projekt mit mehreren Modulen haben und das Build-Verzeichnis bereinigen, bevor Sie Lint auf dem CI-Server ausführen.

C-/C++-Module können jetzt auf andere C-/C++-Module im selben Projekt verweisen.

Ein Gradle Android-Modul mit C/C++-Code kann jetzt eingerichtet werden, um auf Headerdateien und Bibliothekscode in einem anderen Gradle-Modul zu verweisen. Das Prefab-Protokoll wird verwendet, um die Header und Bibliotheken zwischen Gradle-Modulen zu kommunizieren.

Voraussetzungen

• Das Modul Nutzung muss CMake und nicht ndk-build sein. Die Unterstützung von ndk-build erfordert ein zukünftiges NDK-Update. Das Publishing-Modul kann CMake oder ndk-build sein.

• Das Modul using muss prefab in der Datei build.gradle aktivieren.

android {
  buildFeatures {
    prefab true
  }
}

• Für das Modul Publishing muss prefabPublishing in der Datei build.gradle aktiviert sein.

android {
  buildFeatures {
    prefabPublishing true
  }
}

• Das Modul Nutzung muss auf das Modul Veröffentlichung verweisen. Dazu fügt es eine Zeile in den Block build.gradle der Datei dependencies ein. Beispiele:

dependencies {
  implementation project(':mylibrary')
}

• Das Modul Publishing muss ein Paket über einen prefab-Abschnitt verfügbar machen. Beispiele:

android {
  prefab {
    mylibrary {
      libraryName "libmylibrary"
      headers "src/main/cpp/include"
    }
  }
}

• Die Datei CMakeLists.txt des nutzenden Moduls kann find_package() verwenden, um das vom produzierende Modul veröffentlichte Paket zu finden. Beispiele:

find_package(mylibrary REQUIRED CONFIG)
target_link_libraries(
  myapplication
  mylibrary::mylibrary)

• Es muss eine STL für die gesamte Anwendung vorhanden sein. So können beispielsweise sowohl die Modulen als auch die Veröffentlichung von Modulen ein gemeinsam genutztes C++-STL verwenden.

   android {
      defaultConfig {
        externalNativeBuild {
          cmake {
            arguments '-DANDROID_STL=c++_shared'
          }
        }
      }
    }

Weitere Informationen zum Konfigurieren nativer AAE-Nutzer und -Ersteller mit AGP finden Sie unter Native Abhängigkeiten mit AGP.

Repository-Einstellungen in settings.gradle-Datei

Wenn ein neues Projekt in Android Studio Bumblebee erstellt wird, enthält die übergeordnete Datei build.gradle den Block plugins gefolgt von Code zum Bereinigen des Build-Verzeichnisses:

plugins {
    id 'com.android.application' version '7.1.0-beta02' apply false
    id 'com.android.library' version '7.1.0-beta02' apply false
    id 'org.jetbrains.kotlin.android' version '1.5.30' apply false
}
task clean(type: Delete) {
  delete rootProject.buildDir
}

Die Repository-Einstellungen, die zuvor in der Datei build.gradle auf oberster Ebene enthalten waren, befinden sich jetzt in der Datei settings.gradle:

pluginManagement {
  repositories {
    gradlePluginPortal()
    google()
    mavenCentral()
  }
}
dependencyResolutionManagement {
  repositoriesMode.set(RepositoriesMode.FAIL_ON_PROJECT_REPOS)
  repositories {
    google()
    mavenCentral()
  }
}
rootProject.name = 'GradleManagedDeviceTestingNew'
include ':app'

Die Datei build.gradle auf Modulebene hat sich nicht geändert. Verwende also die Datei build.gradle auf oberster Ebene und die Datei settings.gradle, um Build-Konfigurationen zu definieren, die für alle Module in deinem Projekt oder die Repositories und Abhängigkeiten gelten, die für Gradle selbst gelten. Mit der Datei build.gradle auf Modulebene kannst du Build-Konfigurationen definieren, die für ein bestimmtes Modul in deinem Projekt spezifisch sind.

Verbessertes Ressourcenverkleinern

Android Studio Bumblebee enthält einen verbesserten Ressourcenschrumpf, mit dem du die App-Größe verringern kannst.

Unterstützung für Apps mit dynamischen Funktionen

Die Standardimplementierung des Android-Ressourcen-Shrinkers wurde im Android Gradle-Plug-in 7.1.0-alpha09 aktualisiert. Die neue Implementierung unterstützt die Verkleinerung von Anwendungen mit dynamischen Funktionen.

Weitere experimentelle Größenreduzierungen der App

Mit der neuen Ressourcenverkleinerung lässt sich die Größe der verkleinerten Anwendung noch weiter reduzieren. Dazu wird die Ressourcentabelle geändert, um nicht verwendete Wertressourcen und Verweise auf nicht verwendete Dateiressourcen zu entfernen. Mit dem neuen Ressourcen-Shinker können nicht verwendete Dateiressourcen vollständig gelöscht werden, sodass sich die Größe Ihrer App weiter verringert. Dieses Verhalten ist noch nicht standardmäßig aktiviert. Sie können es aber ausprobieren, indem Sie der Datei gradle.properties Ihres Projekts die experimentelle Option android.experimental.enableNewResourceShrinker.preciseShrinking=true hinzufügen.

Melden Sie alle Probleme, die Sie mit dem neuen Ressourcenshrinker oder dem experimentellen Flag feststellen. Zur Unterstützung bei der Diagnose von Problemen oder als vorübergehende Problemumgehung können Sie zur vorherigen Implementierung zurückkehren. Fügen Sie dazu android.enableNewResourceShrinker=false zur gradle.properties Ihres Projekts hinzu. Der neue Verkleinerer ersetzt nicht verwendete dateibasierte Ressourcen durch geringfügig abweichende Mindestdateien als der vorherige Ressourcenverkleinerer. Dies wird jedoch voraussichtlich keine Auswirkungen auf die Laufzeit haben.

Die alte Implementierung wird voraussichtlich im Android-Gradle-Plug-in 8.0.0 entfernt.

Veröffentlichung von Build-Varianten

Mit dem Android-Gradle-Plug-in 7.1.0 und höher können Sie konfigurieren, welche Build-Varianten in einem Apache Maven-Repository veröffentlicht werden sollen. AGP erstellt eine Komponente mit einer oder mehreren Build-Varianten basierend auf der neuen veröffentlichten DSL, mit der Sie eine Publikation für ein Maven-Repository anpassen können. Im Vergleich zu früheren Versionen vermeidet dies außerdem unnötige Arbeit, da standardmäßig keine Komponenten erstellt werden. Weitere Informationen finden Sie unter Codebeispiel für die Veröffentlichung.

Javadoc-JAR-Datei veröffentlichen

Mit AGP 7.1.0 und höher können Sie Javadoc aus Java- und Kotlin-Quellen generieren und Javadoc-JAR-Dateien zusätzlich zu AARs für Bibliotheksprojekte veröffentlichen. Das Javadoc wird den POM- und Gradle-Modulmetadaten{:.external}-Dateien hinzugefügt. Aktivieren Sie diese Funktion, indem Sie withJavadocJar() in den Veröffentlichungsblock singleVariant oder multipleVariants einfügen. Weitere Informationen finden Sie im Codebeispiel für Veröffentlichungsoptionen.

JAR-Datei zur Veröffentlichung von Quellen

Mit AGP 7.1.0 und höher können Sie zusätzlich zu AAE für Bibliotheksprojekte Java- und Kotlin-Quell-JAR-Dateien veröffentlichen. Die Quellen werden den POM- und Gradle Module Metadata-{:.external}-Dateien hinzugefügt. Sie können dieses Feature aktivieren, indem Sie withSourcesJar() in den Veröffentlichungsblock singleVariant oder multipleVariants einfügen. Weitere Informationen finden Sie im Codebeispiel für Veröffentlichungsoptionen.

Semantische Änderung von Lint-Blocks

Bei allen Lint-Methoden, die den angegebenen Schweregrad eines Problems überschreiben (enable, disable/ignore, informational, warning, error, fatal), wird jetzt die Reihenfolge der Konfiguration berücksichtigt. Wenn in finalizeDsl() beispielsweise ein Problem als schwerwiegend festgelegt wird, wird es jetzt in der Haupt-DSL überschrieben. Weitere Informationen finden Sie in der Referenzdokumentation zum lint{}-Block und unter Android-Build-Ablauf und Erweiterungspunkte.

Kompatibilität mit sicheren Args für die Navigation

AGP APIs, von denen das Navigation Safe Args Gradle-Plug-in abhängig ist, wurden entfernt. AGP 7.1 funktioniert nicht mit den Versionen 2.4.0-rc1 oder 2.4.0, aber mit den Versionen 2.5.0-alpha01 und 2.4.1. In der Zwischenzeit können Sie als Behelfslösung AGP 7.1 mit einem Snapshot-Build von Navigation Safe Args, Navigation 2.5.0-SNAPSHOT verwenden. Folgen Sie der Snapshot-Anleitung mit der Build-ID #8054565, um den Snapshot-Build zu verwenden.

Darüber hinaus funktionieren Navigation Safe Args in den Versionen 2.4.1 und 2.5.0 nicht mehr mit AGP 4.2. Um diese Versionen von Safe Args nutzen zu können, müssen Sie AGP 7.0 oder höher verwenden.

Automatische Komponentenerstellung deaktivieren

Ab AGP 8.0 ist die automatische Komponentenerstellung standardmäßig deaktiviert. Derzeit erstellt AGP 7.1 automatisch für jede Build-Variante eine Komponente, die denselben Namen wie die Build-Variante hat, sowie eine all-Komponente, die alle Build-Varianten enthält. Diese automatische Komponentenerstellung wird deaktiviert. Um zum neuen Verhalten zu wechseln, sollten Sie die automatische Erstellung von Komponenten manuell deaktivieren. Dazu setzen Sie android.disableAutomaticComponentCreation auf true.. Weitere Informationen finden Sie unter Maven Publish-Plug-in verwenden.

Kompatibilität mit Firebase Performance Monitoring

AGP 7.1 ist nicht mit dem Firebase Performance Monitoring Gradle-Plug-in Version 1.4.0 und niedriger kompatibel. Der AGP Upgrade Assistant aktualisiert das Plug-in nicht automatisch auf Version 1.4.1. Wenn Sie also firebase-perf verwenden und ein Upgrade von AGP auf 7.1 ausführen möchten, müssen Sie dieses Upgrade manuell ausführen.

Bekannte Probleme

In diesem Abschnitt werden bekannte Probleme im Android-Gradle-Plug-in 7.1.0 beschrieben.

Probleme beim Unittest eines App-Projekts, das das Hilt-Plug-in verwendet

Der Unittest-Klassenpfad enthält die nicht instrumentierten App-Klassen. Das bedeutet, dass Hilt die App-Klassen nicht instrumentiert, um beim Ausführen von Unittests durch Abhängigkeitsinjektionen zu verarbeiten.

Dieses Problem wird mit Version 7.1.1 behoben, siehe Problem #213534628.