Android Gradle-Plug-in 7.0.0 (Juli 2021)

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

Kompatibilität

JDK 11 zur Ausführung von AGP 7.0 erforderlich

Wenn Sie Ihre App mit dem Android Gradle-Plug-in 7.0 erstellen, ist jetzt JDK 11 zum Ausführen von Gradle erforderlich. In Android Studio Arctic Fox wird JDK 11 gebündelt und Gradle so konfiguriert, dass es standardmäßig verwendet wird. Das bedeutet, dass die meisten Android Studio-Nutzer keine Änderungen an der Konfiguration ihrer Projekte vornehmen müssen.

Wenn Sie die von AGP in Android Studio verwendete JDK-Version manuell festlegen müssen, müssen Sie JDK 11 oder höher verwenden.

Wenn Sie AGP unabhängig von Android Studio verwenden, führen Sie ein Upgrade der JDK-Version aus. Dazu legen Sie für die Umgebungsvariable JAVA_HOME oder die Befehlszeilenoption -Dorg.gradle.java.home das Installationsverzeichnis von JDK 11 fest.

SDK Manager und AVD Manager im eingestellten SDK Tools-Paket funktionieren nicht mit JDK 11. Wenn Sie SDK Manager und AVD Manager weiterhin mit AGP 7.0 und höher verwenden möchten, müssen Sie auf die neuen Versionen der Tools im aktuellen Android SDK-Befehlszeilentools-Paket umstellen.

Variant API (stabile Version)

Die neue Variant API ist jetzt stabil. Sehen Sie sich die neuen Schnittstellen im Paket com.android.build.api.variant und Beispiele im GitHub-Projekt gradle-recipes an. Im Rahmen der neuen Variant API haben wir über die Schnittstelle Artifacts eine Reihe von Zwischendateien, sogenannte Artefakte, zur Verfügung gestellt. Diese Artefakte, wie das zusammengeführte Manifest, können mithilfe von Drittanbieter-Plug-ins und -Code sicher abgerufen und angepasst werden.

Wir werden die Variant API weiter ausbauen, um neue Funktionen hinzuzufügen und die Anzahl der Zwischenartefakte zu erhöhen, die wir für die Anpassung zur Verfügung stellen.

Verhaltensänderungen bei Lint

In diesem Abschnitt werden mehrere Änderungen des Lint-Verhaltens im Android-Gradle-Plug-in 7.0.0 beschrieben.

Verbesserter Lint für Bibliotheksabhängigkeiten

Das Ausführen von Lint mit checkDependencies = true ist jetzt schneller als zuvor. Bei Android-Projekten, die aus einer App mit Bibliotheksabhängigkeiten bestehen, wird empfohlen, checkDependencies auf true festzulegen und Lint über ./gradlew :app:lint auszuführen. Dadurch werden alle Abhängigkeitsmodule parallel analysiert und ein einziger Bericht mit Problemen der App und aller Abhängigkeiten erstellt.

// build.gradle
android {
  ...
  lintOptions {
    checkDependencies true
  }
}

// build.gradle.kts
android {
  ...
  lint {
    isCheckDependencies = true
  }
}

Lint-Aufgaben können jetzt auf dem neuesten Stand sein

Wenn sich die Quellen und Ressourcen eines Moduls nicht geändert haben, muss die Lint-Analyseaufgabe für das Modul nicht noch einmal ausgeführt werden. In diesem Fall wird die Ausführung der Aufgabe in der Gradle-Ausgabe als "UP-TO-DATE" angezeigt. Durch diese Änderung müssen beim Ausführen von Lint für ein Anwendungsmodul mit checkDependencies = true nur geänderte Module die Analyse ausführen. Dadurch kann Lint noch schneller ausgeführt werden.

Die Lint-Berichtsaufgabe muss auch nicht ausgeführt werden, wenn sich ihre Eingaben nicht geändert haben. Ein ähnliches bekanntes Problem besteht darin, dass keine Lint-Textausgabe in stdout ausgegeben wird, wenn die Lint-Aufgabe den AKTUELLEN DATUM hat (Problem #191897708).

Lint auf Module mit dynamischen Funktionen ausführen

AGP unterstützt das Ausführen von Lint aus dynamischen Funktionsmodulen nicht mehr. Wenn Sie Lint aus dem entsprechenden Anwendungsmodul ausführen, wird Lint auf den Modulen der dynamischen Funktionen ausgeführt und alle Probleme werden in den Lint-Bericht der App aufgenommen. Ein ähnliches bekanntes Problem besteht darin, dass beim Ausführen von Lint mit checkDependencies = true aus einem Anwendungsmodul die Abhängigkeiten der Dynamic Feature Library nur geprüft werden, wenn es sich auch um Anwendungsabhängigkeiten handelt (Problem Nr. 191977888).

Lint nur für die Standardvariante ausführen

Wenn Sie ./gradlew :app:lint ausführen, wird Lint jetzt nur für die Standardvariante ausgeführt. In früheren Versionen von AGP wurde Lint für alle Varianten ausgeführt.

Fehlende Klassenwarnungen in R8 Shrinker

R8 verarbeitet fehlende Klassen und die Option -dontwarn präziser und konsistenter. Daher sollten Sie mit der Auswertung der fehlenden Klassenwarnungen beginnen, die von R8 ausgegeben werden.

Wenn R8 auf einen Klassenverweis stößt, der in der Anwendung oder in einer ihrer Abhängigkeiten nicht definiert ist, wird in der Build-Ausgabe eine Warnung ausgegeben. Beispiele:

R8: Missing class: java.lang.instrument.ClassFileTransformer

Diese Warnung bedeutet, dass die Klassendefinition java.lang.instrument.ClassFileTransformer beim Analysieren des Anwendungscodes nicht gefunden wurde. Das bedeutet normalerweise, dass ein Fehler vorliegt. Es ist aber möglich, dass Sie diese Warnung ignorieren. Zwei häufige Gründe für das Ignorieren der Warnung sind:

1. Bibliotheken, die auf die JVM und die fehlende Klasse abzielen, haben einen JVM-Bibliothekstyp (wie im obigen Beispiel).

2. Eine Ihrer Abhängigkeiten verwendet eine API, die nur zur Kompilierungszeit verwendet wird.

Sie können eine Warnung über fehlende Klassen ignorieren, indem Sie der Datei proguard-rules.pro die Regel -dontwarn hinzufügen. Beispiele:

-dontwarn java.lang.instrument.ClassFileTransformer

Der Einfachheit halber generiert AGP eine Datei, die alle potenziell fehlenden Regeln enthält, und schreibt sie in einen Dateipfad wie den folgenden: app/build/outputs/mapping/release/missing_rules.txt. Fügen Sie die Regeln der Datei proguard-rules.pro hinzu, um Warnungen zu ignorieren.

In AGP 7.0 werden fehlende Klassennachrichten als Warnungen angezeigt. Sie können sie in Fehler umwandeln, indem Sie android.r8.failOnMissingClasses = true in gradle.properties festlegen. In AGP 8.0 werden diese Warnungen zu Fehlern, die Ihren Build beschädigen. Sie können das Verhalten von AGP 7.0 beibehalten, indem Sie der Datei proguard-rules.pro die Option -ignorewarnings hinzufügen. Dies wird jedoch nicht empfohlen.

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 des Gradle-Build-Cache eingeführt. Er wurde in AGP 4.1 vollständig durch den Gradle-Build-Cache ersetzt. Diese Änderung hat keine Auswirkungen auf die Build-Dauer.

In AGP 7.0 wurden die Attribute android.enableBuildCache, android.buildCacheDir und die Aufgabe cleanBuildCache entfernt.

Java 11-Quellcode in Ihrem Projekt verwenden

Sie können im Projekt Ihrer App jetzt bis zu Java 11-Quellcode kompilieren. Dadurch können Sie neuere Sprachfunktionen wie private Schnittstellenmethoden, den Diamant-Operator für anonyme Klassen und die Syntax lokaler Variablen für Lambda-Parameter verwenden.

Um diese Funktion zu aktivieren, setzen Sie compileOptions auf die gewünschte Java-Version und compileSdkVersion auf 30 oder höher:

// build.gradle
android {
  compileSdkVersion 30
  compileOptions {
    sourceCompatibility JavaVersion.VERSION_11
    targetCompatibility JavaVersion.VERSION_11
  }
  // For Kotlin projects
  kotlinOptions {
    jvmTarget = "11"
  }
}

// build.gradle.kts
android {
  compileSdkVersion(30)
  compileOptions {
    sourceCompatibility(JavaVersion.VERSION_11)
    targetCompatibility(JavaVersion.VERSION_11)
  }
  kotlinOptions {
    jvmTarget = "11"
  }
}

Abhängigkeitskonfigurationen entfernt

In AGP 7.0 wurden die folgenden Konfigurationen (oder Abhängigkeitsbereiche) entfernt:

• compile
  Je nach Anwendungsfall wurde dies durch api oder implementation ersetzt.
  Gilt auch für *Kompilierung-Varianten, z. B. debugCompile.
• provided
  Dies wurde durch compileOnly ersetzt.
  Gilt auch für *bereitgestellte Varianten, z. B. releaseProvided.
• apk
  Dies wurde durch runtimeOnly ersetzt.
• publish
  Dies wurde durch runtimeOnly ersetzt.

In den meisten Fällen migriert der AGP-Upgrade-Assistent Ihr Projekt automatisch zu den neuen Konfigurationen.

Klassenpfadänderung beim Kompilieren mit dem Android-Gradle-Plug-in

Wenn Sie mit dem Android-Gradle-Plug-in kompilieren, kann sich Ihr kompilierungsklassenpfad ändern. Da AGP jetzt api/implementation-Konfigurationen intern verwendet, werden möglicherweise einige Artefakte aus Ihrem kompilierten Klassenpfad entfernt. Wenn Sie bei der Kompilierung von einer AGP-Abhängigkeit abhängig sind, achten Sie darauf, sie als explizite Abhängigkeit hinzuzufügen.

Native Bibliotheken können nicht in einen Java-Ressourcenordner eingefügt werden.

Bisher konntest du einem Java-Ressourcenordner eine native Bibliothek hinzufügen und den Ordner mit android.sourceSets.main.resources.srcDirs registrieren. Dadurch wurde die native Bibliothek extrahiert und dem endgültigen APK hinzugefügt. Ab AGP 7.0 wird dies nicht unterstützt und native Bibliotheken in einem Java-Ressourcenordner werden ignoriert. Verwenden Sie stattdessen die für native Bibliotheken vorgesehene DSL-Methode (android.sourceSets.main.jniLibs.srcDirs). Weitere Informationen finden Sie unter Quellsätze konfigurieren.

Bekannte Probleme

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

Inkompatibilität mit Kotlin-Multiplatform-Plug-in 1.4.x

Das Android Gradle-Plug-in 7.0.0 ist mit dem Kotlin Multiplatform-Plug-in 1.5.0 und höher kompatibel. Projekte, die Kotlin-Multiplattform-Unterstützung nutzen, müssen auf Kotlin 1.5.0 aktualisiert werden, um das Android Gradle-Plug-in 7.0.0 verwenden zu können. Um das Problem zu umgehen, können Sie ein Downgrade des Android-Gradle-Plug-ins auf 4.2.x ausführen. Dies wird jedoch nicht empfohlen.

Weitere Informationen findest du unter KT-43944.

Fehlende Lint-Ausgabe

Wenn die Lint-Aufgabe auf dem neuesten Stand ist, wird keine Lint-Textausgabe in stdout ausgegeben (Problem #191897708). Weitere Informationen finden Sie unter Verhaltensänderungen bei Lint. Dieses Problem wird im Android-Gradle-Plug-in 7.1 behoben.

Nicht alle Abhängigkeiten der Bibliothek mit dynamischen Funktionen sind mit Lint überprüft

Wenn Sie Lint mit checkDependencies = true aus einem Anwendungsmodul ausführen, werden Abhängigkeiten der Dynamic Feature Library nicht geprüft, es sei denn, es sind auch Anwendungsabhängigkeiten (Problem #191977888). Als Behelfslösung kann die Lint-Task für diese Bibliotheken ausgeführt werden. Weitere Informationen finden Sie unter Verhaltensänderungen bei Lint.