Android Gradle Plugin 7.1.0 (Januar 2022)

Das Android Gradle-Plug-in 7.1.0 ist eine Hauptversion mit einer Vielzahl neuer Funktionen und Verbesserungen.

Kompatibilität

Lint-Analyseaufgabe kann jetzt im Cache gespeichert werden

AndroidLintAnalysisTask ist jetzt mit dem Gradle-Build-Cache kompatibel. Wenn Sie den Build-Cache aktivieren, indem Sie org.gradle.caching=true in Ihrer gradle.properties-Datei festlegen, ruft die Aufgabe „Lint-Analyse“ die Ausgabe nach Möglichkeit aus dem Build-Cache ab.

Die Lint-Analyse ist oft der größte Engpass, wenn Lint mit dem Android Gradle-Plug-in ausgeführt wird. Wenn Sie den Build-Cache aktivieren, wird die Build-Geschwindigkeit beim Ausführen von Lint in vielen Fällen verbessert. Sie sollten eine deutliche Leistungssteigerung feststellen, wenn Sie beispielsweise ein mehrmoduliges Projekt haben und Ihr Build-Verzeichnis bereinigen, bevor Sie lint auf Ihrem 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 so eingerichtet werden, dass es auf Headerdateien und Bibliothekscode in einem anderen Gradle-Modul verweist. Das Prefab-Protokoll wird verwendet, um die Header und Bibliotheken zwischen Gradle-Modulen auszutauschen.

Voraussetzungen

• Das nutzende Modul muss CMake und nicht ndk-build sein. Für die Unterstützung von ndk-build ist ein zukünftiges NDK-Update erforderlich. Das Veröffentlichungsmodul kann CMake oder ndk-build sein.

• Im Nutzermodul muss prefab in der build.gradle-Datei aktiviert sein.

android {
  buildFeatures {
    prefab true
  }
}

• Im Modul publishing muss prefabPublishing in der Datei build.gradle aktiviert sein.

android {
  buildFeatures {
    prefabPublishing true
  }
}

• Das Nutzermodul muss auf das Veröffentlichungsmodul verweisen. Fügen Sie dazu eine Zeile in den Block dependencies der Datei build.gradle hinzu. Beispiel:

dependencies {
  implementation project(':mylibrary')
}

• Das publishing-Modul muss ein Paket mit einem prefab-Abschnitt bereitstellen. Beispiel:

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

• In der CMakeLists.txt-Datei des konsumierenden Moduls kann find_package() verwendet werden, um das vom produzierenden Modul veröffentlichte Paket zu finden. Beispiel:

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

• Es muss ein STL für die gesamte Anwendung geben. So können beispielsweise sowohl konsumierende als auch veröffentlichende Module die freigegebene C++-STL verwenden.

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

Weitere Informationen zum Konfigurieren nativer AAR-Abnehmer und ‑Produzenten mit AGP finden Sie unter Native Abhängigkeiten mit AGP.

Repository-Einstellungen in der Datei settings.gradle

Wenn in Android Studio Bumblebee ein neues Projekt erstellt wird, enthält die Datei build.gradle auf oberster Ebene 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 sich zuvor in der Datei build.gradle der obersten Ebene befanden, 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. Verwenden Sie also die build.gradle-Datei auf oberster Ebene und die settings.gradle-Datei, um Buildkonfigurationen zu definieren, die für alle Module in Ihrem Projekt oder für die Repositories und Abhängigkeiten gelten, die für Gradle selbst gelten. Verwenden Sie die build.gradle-Datei auf Modulebene, um Buildkonfigurationen zu definieren, die für ein bestimmtes Modul in Ihrem Projekt spezifisch sind.

Verbessertes Tool zum Entfernen von Ressourcen

Android Studio Bumblebee enthält einen verbesserten Ressourcen-Minimierungstool, mit dem sich die App-Größe reduzieren lässt.

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 das Schrumpfen von Apps mit dynamischen Funktionen.

Experimentelle weitere Reduzierung der App-Größe

Mit der neuen Implementierung des Ressourcen-Shrinkers lässt sich die Größe Ihrer verkleinerten App noch weiter reduzieren. Dazu wird die Ressourcentabelle so geändert, dass nicht verwendete Ressourcenwerte und Verweise auf nicht verwendete Dateiressourcen entfernt werden. Mit dem neuen Ressourcen-Minimierungstool können nicht verwendete Dateiressourcen vollständig gelöscht werden, wodurch die Größe Ihrer App weiter reduziert wird. 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.

Bitte melden Sie alle Probleme, die Sie mit dem neuen Ressourcen-Minimierungstool oder dem experimentellen Flag feststellen. Zur Fehlerbehebung oder als vorübergehende Problemumgehung können Sie zur vorherigen Implementierung zurückkehren, indem Sie android.enableNewResourceShrinker=false zur gradle.properties Ihres Projekts hinzufügen. Der neue Komprimierungstool ersetzt nicht verwendete dateibasierte Ressourcen durch etwas andere Miniaturdateien als der vorherige Ressourcenkomprimierungstool. Dies sollte jedoch keine Auswirkungen auf die Laufzeit haben.

Die alte Implementierung wird voraussichtlich in Android Gradle Plugin 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 Buildvarianten in einem Apache Maven-Repository veröffentlicht werden sollen. AGP erstellt eine Komponente mit einer oder mehreren Buildvarianten basierend auf der neuen Veröffentlichungs-DSL, mit der Sie eine Veröffentlichung für ein Maven-Repository anpassen können. Im Vergleich zu früheren Versionen werden so auch unnötige Arbeitsschritte vermieden, da standardmäßig keine Komponenten erstellt werden. Weitere Informationen finden Sie im Beispiel für den Veröffentlichungscode.

Javadoc-JAR 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. Der Javadoc wird der POM-Datei und den Gradle-Modulmetadaten{:.external} hinzugefügt. Aktivieren Sie diese Funktion, indem Sie withJavadocJar() in den singleVariant- oder multipleVariants-Veröffentlichungsblock einfügen. Weitere Informationen finden Sie im Beispielcode für die Veröffentlichungsoptionen.

JAR-Datei mit Quellen veröffentlichen

Mit AGP 7.1.0 und höher können Sie neben AARs für Bibliotheksprojekte auch Java- und Kotlin-Quell-JAR-Dateien veröffentlichen. Die Quellen werden den Dateien POM und Gradle-Modulmetadaten{:.external} hinzugefügt. Sie können diese Funktion aktivieren, indem Sie withSourcesJar() in den singleVariant- oder multipleVariants-Block für die Veröffentlichung einfügen. Weitere Informationen finden Sie im Beispielcode für die Veröffentlichungsoptionen.

Änderung der Semantik von Lint-Blöcken

Alle Lint-Methoden, die den angegebenen Schweregrad eines Problems überschreiben (enable, disable/ignore, informational, warning, error, fatal), berücksichtigen jetzt die Konfigurationsreihenfolge. Wenn Sie ein Problem beispielsweise in finalizeDsl() als fatal markieren, wird die Deaktivierung im Haupt-DSL überschrieben. Weitere Informationen finden Sie in den Blockreferenzdokumenten zu lint{} und in den Artikeln Android-Build-Ablauf und Erweiterungspunkte.

Kompatibilität von Safe Args für die Navigation

AGP-APIs, von denen das Navigation Safe Args Gradle-Plug-in abhängt, wurden entfernt. AGP 7.1 funktioniert nicht mit den Versionen „Navigation Safe Args“ 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 Problemumgehung AGP 7.1 mit einem Snapshot-Build von Navigation Safe Args, Navigation 2.5.0-SNAPSHOT, verwenden. Wenn Sie den Snapshot-Build verwenden möchten, folgen Sie der Anleitung für Snapshots mit der Build-ID 8054565.

Außerdem funktionieren die Navigation Safe Args-Versionen 2.4.1 und 2.5.0 nicht mehr mit AGP 4.2. Wenn Sie diese Versionen von Safe Args verwenden möchten, 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 eine Komponente für jede Buildvariante mit demselben Namen wie die Buildvariante und eine all-Komponente, die alle Buildvarianten enthält. Die automatische Komponentenerstellung wird deaktiviert. Wenn Sie zum neuen Verhalten wechseln möchten, sollten Sie die automatische Komponentenerstellung manuell deaktivieren, indem Sie android.disableAutomaticComponentCreation auf true. festlegen. 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 der Version 1.4.0 und niedriger kompatibel. Der AGP-Upgrade-Assistent aktualisiert das Plug-in nicht automatisch auf Version 1.4.1. Wenn Sie firebase-perf verwenden und AGP auf Version 7.1 aktualisieren 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 Unit-Testen eines App-Projekts, das das Hilt-Plug-in verwendet

Der Klassenpfad für den Unit-Test enthält die nicht instrumentierten App-Klassen. Das bedeutet, dass Hilt die App-Klassen beim Ausführen von Unit-Tests nicht für die Abhängigkeitsinjektion instrumentiert.

Dieses Problem wird in der Version 7.1.1 behoben. Weitere Informationen finden Sie unter Issue 213534628.