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

Die Lint-Analyseaufgabe kann jetzt im Cache gespeichert werden

Der 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, wird die Ausgabe der Lint-Analyseaufgabe nach Möglichkeit aus dem Build-Cache abgerufen.

Die Lint-Analyse ist oft der größte Engpass, wenn Lint mit dem Android-Gradle-Plugin ausgeführt wird. Wenn Sie den Build-Cache aktivieren, wird die Build-Geschwindigkeit in vielen Situationen verbessert, wenn Lint ausgeführt wird. Sie sollten eine deutliche Leistungssteigerung feststellen, z. B. wenn Sie ein Projekt mit mehreren Modulen haben und das 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 zu übertragen.

Voraussetzungen

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

• Im Modul consuming muss prefab in der Datei build.gradle aktiviert sein.

android {
  buildFeatures {
    prefab true
  }
}

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

android {
  buildFeatures {
    prefabPublishing true
  }
}

• Das consuming-Modul muss auf das publishing-Modul verweisen. Fügen Sie dazu eine Zeile im dependencies-Block der Datei build.gradle hinzu. Beispiel:

dependencies {
  implementation project(':mylibrary')
}

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

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

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

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

• Es muss eine STL für die gesamte Anwendung geben. Sowohl beim Verwenden als auch beim Veröffentlichen von Modulen kann beispielsweise die freigegebene STL von C++ verwendet werden.

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

Weitere Informationen zum Konfigurieren von nativen AAR-Consumern und -Producern 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 build.gradle-Datei auf oberster Ebene den plugins-Block, 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, sind 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 Build-Konfigurationen zu definieren, die für alle Module in Ihrem Projekt gelten, oder die Repositories und Abhängigkeiten, die für Gradle selbst gelten. Verwenden Sie die build.gradle-Datei auf Modulebene, um Build-Konfigurationen zu definieren, die für ein bestimmtes Modul in Ihrem Projekt gelten.

Verbesserte Entfernung von Ressourcen

Android Studio Bumblebee enthält eine verbesserte Funktion zum Verkleinern von Ressourcen, mit der Sie die Größe Ihrer App reduzieren können.

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

Experimentelle weitere Reduzierungen der App-Größe

Die neue Implementierung des Resource Shrinker kann die Größe Ihrer verkleinerten App noch weiter reduzieren, indem die Ressourcentabelle so geändert wird, dass nicht verwendete Wertressourcen und Verweise auf nicht verwendete Dateiresourcen entfernt werden. Mit dem neuen Resource Shrinker können ungenutzte Dateiresourcen vollständig gelöscht werden, wodurch die Größe Ihrer App noch weiter reduziert wird. Dieses Verhalten ist noch nicht standardmäßig aktiviert. Sie können es jedoch testen, indem Sie die experimentelle Option android.experimental.enableNewResourceShrinker.preciseShrinking=true der Datei gradle.properties Ihres Projekts hinzufügen.

Bitte melden Sie alle Probleme, die Sie mit dem neuen Resource Shrinker oder dem experimentellen Flag finden. Um Probleme zu beheben 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 Shrinker ersetzt ungenutzte dateibasierte Ressourcen durch etwas andere Minimaldateien als der vorherige Resource Shrinker. Dies sollte jedoch keine Auswirkungen auf die Laufzeit haben.

Die alte Implementierung soll im Android-Gradle-Plug-in 8.0.0 entfernt werden.

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 Publishing-DSL, mit der Sie eine Veröffentlichung in einem Maven-Repository anpassen können. Im Vergleich zu früheren Versionen wird dadurch auch unnötige Arbeit vermieden, da standardmäßig keine Komponenten erstellt werden. Weitere Informationen finden Sie im Beispielcode für die Veröffentlichung.

Javadoc-JAR veröffentlichen

Mit AGP 7.1.0 und höher können Sie Javadoc aus Java- und Kotlin-Quellen generieren und zusätzlich zu AARs für Bibliotheksprojekte Javadoc-JAR-Dateien veröffentlichen. Die Javadoc wird der POM-Datei und den 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.

Quell-JAR veröffentlichen

Mit AGP 7.1.0 und höher können Sie zusätzlich zu AARs auch JAR-Dateien mit Java- und Kotlin-Quellcode für Bibliotheksprojekte veröffentlichen. Die Quellen werden der POM-Datei und den Gradle-Modul-Metadatendateien{:.external} hinzugefügt. Sie können diese Funktion 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 des 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 Sie beispielsweise ein Problem in finalizeDsl() als schwerwiegend festlegen, wird es jetzt auch dann nicht deaktiviert, wenn Sie es in der Haupt-DSL deaktivieren. Weitere Informationen finden Sie in der lint{}-Blockreferenzdokumentation und unter Android-Build-Ablauf und Erweiterungspunkte.

Kompatibilität von Safe Args mit der Navigation

AGP-APIs, von denen das Navigation Safe Args Gradle-Plug-in abhängt, wurden entfernt. AGP 7.1 ist nicht mit Navigation Safe Args-Versionen 2.4.0-rc1 oder 2.4.0 kompatibel, funktioniert aber mit den Versionen 2.5.0-alpha01 und 2.4.1. In der Zwischenzeit können Sie als Workaround 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 Snapshot-Anleitung mit der Build-ID 8054565.

Außerdem funktionieren die 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 und 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 Build-Variante, die denselben Namen wie die Build-Variante hat, sowie eine all-Komponente, die alle Build-Varianten enthält. Die automatische Komponentenerstellung wird deaktiviert. Um auf das neue Verhalten umzustellen, sollten Sie die automatische Komponentenerstellung manuell deaktivieren, indem Sie android.disableAutomaticComponentCreation auf true. setzen. Weitere Informationen finden Sie unter Maven-Publish-Plug-in verwenden.

Kompatibilität von Firebase Performance Monitoring

AGP 7.1 ist nicht mit dem Firebase Performance Monitoring Gradle-Plug-in 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 AGP auf Version 7.1 aktualisieren möchten, müssen Sie dieses Upgrade manuell durchführen.

Bekannte Probleme

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

Probleme beim Unittesting eines App-Projekts, in dem das Hilt-Plug-in verwendet wird

Der Classpath für Einheitentests enthält die nicht instrumentierten App-Klassen. Das bedeutet, dass Hilt die App-Klassen nicht instrumentiert, um die Abhängigkeitsinjektion beim Ausführen von Einheitentests zu verarbeiten.

Dieses Problem wird mit Version 7.1.1 behoben. Weitere Informationen finden Sie unter Problem 213534628.