Android-Gradle-Plug-in 7.1.0 (Januar 2022)

Das Android-Gradle-Plug-in 7.1.0 ist ein wichtiger Release, der eine Vielzahl neuer Funktionen und Verbesserungen enthält.

Kompatibilität

Lint-Analyseaufgabe ist jetzt cachefähig

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

Die Lint-Analyseaufgabe ist oft der größte Engpass, wenn Lint mit dem Android-Gradle-Plug-in ausgeführt wird. Durch Aktivieren des Build-Cache wird die Build Geschwindigkeit in vielen Fällen verbessert. Sie sollten eine spürbare 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 in demselben 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 verwendende Modul muss CMake und nicht ndk-build sein. Die Unterstützung für „ndk-build“ erfordert ein zukünftiges NDK-Update. Das veröffentlichende Modul kann CMake oder ndk-build sein.

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

android {
  buildFeatures {
    prefab true
  }
}

• Im veröffentlichenden Modul muss prefabPublishing in der build.gradle Datei aktiviert sein.

android {
  buildFeatures {
    prefabPublishing true
  }
}

• Das verwendende Modul muss auf das veröffentlichende Modul verweisen, indem im dependencies Block der build.gradle Datei eine Zeile hinzugefügt wird. Beispiel:

dependencies {
  implementation project(':mylibrary')
}

• Das veröffentlichende Modul muss ein Paket mit einem prefab Abschnitt verfügbar machen. Beispiel:

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

• In der Datei CMakeLists.txt des verwendenden 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)

• Für die gesamte Anwendung muss eine STL vorhanden sein. So können beispielsweise sowohl das verwendende als auch das veröffentlichende Modul die gemeinsame C++-STL verwenden.

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

Weitere Informationen zum Konfigurieren von nativen AAR-Verwendern und -Erstellern 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 auf oberster Ebene 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 sich zuvor in der Datei auf oberster Ebene build.gradle 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 Datei auf oberster Ebene build.gradle und die Datei settings.gradle, um Build Konfigurationen zu definieren, die für alle Module in Ihrem Projekt gelten, oder die Repositorys und Abhängigkeiten, die für Gradle selbst gelten. Verwenden Sie die Datei auf Modulebene build.gradle, um Build-Konfigurationen zu definieren, die für ein bestimmtes Modul in Ihrem Projekt gelten.

Verbesserter Resource Shrinker

Android Studio Bumblebee enthält einen verbesserten Resource Shrinker, mit dem Sie die Größe Ihrer App reduzieren können.

Unterstützung für Apps mit dynamischen Funktionen

Die Standardimplementierung des Android Resource Shrinker wurde im Android-Gradle-Plug-in 7.1.0-alpha09 aktualisiert. Die neue Implementierung unterstützt das Komprimieren von Apps mit dynamischen Funktionen.

Experimentelle weitere Reduzierungen der App-Größe

Die neue Implementierung des Resource Shrinker kann die Größe Ihrer komprimierten App noch weiter reduzieren, indem die Ressourcentabelle so geändert wird, dass nicht verwendete Wertressourcen und Verweise auf nicht verwendete Dateiressourcen entfernt werden. Der neue Resource Shrinker kann nicht verwendete Dateiressourcen vollständig löschen und so die Größe Ihrer App weiter reduzieren. Dieses Verhalten ist noch nicht standardmäßig aktiviert. Sie können es aber testen, indem Sie die experimentelle Option android.experimental.enableNewResourceShrinker.preciseShrinking=true zur 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 diagnostizieren oder als temporäre Problemumgehung, können Sie zur vorherigen Implementierung zurückkehren, indem Sie android.enableNewResourceShrinker=false zur Datei gradle.properties Ihres Projekts hinzufügen. Der neue Shrinker ersetzt nicht verwendete dateibasierte Ressourcen durch etwas andere minimale Dateien als der vorherige Resource Shrinker. Dies sollte sich jedoch nicht auf die Laufzeit auswirken.

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 Veröffentlichungs-DSL, mit der Sie eine Veröffentlichung in einem Maven-Repository anpassen können. Im Vergleich zu früheren Versionen wird so auch unnötige Arbeit vermieden, da standardmäßig keine Komponenten erstellt werden. Weitere Informationen finden Sie im Codebeispiel zur 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 Bibliothek Projekte Javadoc-JAR-Dateien veröffentlichen. Javadoc wird den Dateien POM und Gradle Module Metadata{:.external} hinzugefügt. Aktivieren Sie diese Funktion, indem Sie withJavadocJar() in dem singleVariant oder multipleVariants Veröffentlichungsblock hinzufügen. Weitere Informationen finden Sie im Codebeispiel zu den Veröffentlichungsoptionen.

Quell-JAR veröffentlichen

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

Semantische Änderung des Lint-Blocks

Alle Lint-Methoden, die die angegebene Schweregradstufe eines Problems überschreiben (enable, disable/ignore, informational, warning, error, fatal), berücksichtigen jetzt die Reihenfolge der Konfiguration. Wenn Sie beispielsweise ein Problem als schwerwiegend festlegen in finalizeDsl() wird es jetzt überschrieben, wenn es in der Haupt-DSL deaktiviert wird. Weitere Informationen finden Sie in der lint{} Referenzdokumentation zum Block und unter Android-Build-Ablauf und Erweiterungspunkte.

Kompatibilität mit Navigation Safe Args

AGP-APIs, von denen das Navigation Safe Args Gradle-Plug-in abhängt, wurden entfernt. AGP 7.1 funktioniert nicht mit Navigation Safe Args-Version 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 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, und eine all Komponente, die alle Build-Varianten enthält. Diese automatische Komponentenerstellung wird deaktiviert. Um zum neuen Verhalten zu wechseln, 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 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-Assistent aktualisiert das Plug-in nicht automatisch auf Version 1.4.1. Wenn Sie also firebase-perf verwenden und AGP auf 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 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 nicht für die Abhängigkeitsinjektion instrumentiert, wenn Unit-Tests ausgeführt werden.

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