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.

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 JDK 11 jetzt die zum Ausführen von Gradle erforderlich sind. Android Studio Arctic Fox enthält JDK 11 und wird Gradle konfiguriert, sodass Gradle standardmäßig verwendet wird. Das bedeutet, dass die meisten Android Studio- Nutzer müssen keine Konfigurationsänderungen an ihren Projekten vornehmen.

Wenn Sie den Parameter JDK-Version, die von AGP in Android Studio verwendet wird, müssen Sie JDK 11 verwenden. oder höher.

Wenn Sie AGP unabhängig von Android Studio verwenden, führen Sie ein Upgrade der JDK-Version durch, indem Sie JAVA_HOME-Umgebungsvariable festlegen oder die Befehlszeilenoption -Dorg.gradle.java.home in Ihr Installationsverzeichnis von JDK 11.

SDK Manager und AVD Manager sind im eingestellten SDK Tools-Paket enthalten. nicht mit JDK 11 funktionieren. Wenn Sie SDK Manager und AVD Manager weiterhin verwenden möchten mit AGP 7.0 und höher müssen Sie zu den neuen Versionen der Tools in die aktuelle Android SDK-Befehlszeilentools Paket.

Variant API – stabil

Die neue Variant API ist jetzt stabil. Die neuen Oberflächen finden Sie in der com.android.build.api.variant und Beispiele im GitHub-Projekt gradle-recipes Im Rahmen der neuen Variant API eine Reihe von Zwischendateien zur Verfügung gestellt, Artefakte durch das Artefakte . Diese Artefakte, wie das zusammengeführte Manifest, können und mithilfe von Drittanbieter-Plug-ins und Code angepasst werden.

Wir werden die Variant API um neue Funktionen erweitern und die Anzahl der Zwischenartefakte, die wir für Personalisierung.

Verhaltensänderungen für Lint

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

Verbessertes Lint für Bibliotheksabhängigkeiten

Lint mit checkDependencies = true läuft jetzt schneller als zuvor. Für Android-Projekte, die aus einer App mit Bibliothek bestehen abhängig ist, wird empfohlen, checkDependencies auf true, wie unten gezeigt, und für Lint über ./gradlew :app:lint, das alle Abhängigkeiten analysiert und erstellen einen einzigen Bericht, der Probleme aus der und allen zugehörigen Abhängigkeiten enthält.

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

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

Lint-Aufgaben können jetzt AKTUALISIERT sein

Wenn sich die Quellen und Ressourcen eines Moduls nicht geändert haben, führt die Lint-Analyse für das Modul muss nicht erneut ausgeführt werden. In diesem Fall Ausführung der Task wird als „AKTUALISIERT“ angezeigt. in Gradle . Wenn Sie Lint für ein Anwendungsmodul mit checkDependencies = true ausführen, werden nur die geänderten Module geändert. ihre Analyse durchführen müssen. Dadurch kann Lint noch schneller ausgeführt werden.

Die Lint-Berichtsaufgabe muss auch nicht ausgeführt werden, wenn ihre Eingaben nicht geändert. Ein damit verbundenes bekanntes Problem besteht darin, dass keine Lint- Textausgabe, die an stdout ausgegeben wird, wenn die Lint-Aufgabe AKTUELL ist (Problem-Nr. 191897708)

Lint für Module mit dynamischen Funktionen ausführen

AGP unterstützt die Ausführung von Lint aus Modulen mit dynamischen Funktionen nicht mehr. Wenn Sie Lint im entsprechenden Anwendungsmodul ausführen, der dynamischen Funktionsmodule und schließt alle Probleme in den Lint der App ein. Bericht. Ein ähnliches bekanntes Problem besteht darin, dass beim Ausführen von Lint mit checkDependencies = true aus einem App-Modul Abhängigkeiten der Bibliothek mit dynamischen Funktionen werden nur geprüft, wenn sie auch Abhängigkeiten (Problem #191977888).

Lint nur für Standardvariante ausführen

Bei Ausführung von ./gradlew :app:lint wird Lint jetzt nur für die Standardvariante. In früheren Versionen von AGP würde lint für alle Varianten.

Fehlende Klassenwarnungen im R8-Schrumpfer

R8 genauer und behandelt fehlende Klassen und die Option -dontwarn regelmäßig. Daher sollten Sie damit beginnen, die ausgegebenen fehlenden Klassenwarnungen auszuwerten von R8.

Wenn R8 auf eine Klassenreferenz stößt, die nicht in Ihrer App definiert ist, oder einer seiner Abhängigkeiten gibt er eine Warnung aus, die in Ihrem Build . Beispiel:

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

Diese Warnung bedeutet, dass die Klassendefinition java.lang.instrument.ClassFileTransformer wurde nicht gefunden wenn Sie Ihren App-Code analysieren. Dies bedeutet zwar in der Regel, dass ein Fehler vorliegt, können Sie diese Warnung ignorieren. Zwei häufige Gründe zum Ignorieren der Warnung sind:

1. Bibliotheken, die auf die JVM abzielen und die fehlende Klasse, sind von JVM Bibliothekstyp aus (siehe Beispiel oben).

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

Sie können eine Warnung zu fehlenden Kursen ignorieren, indem Sie einen -dontwarn hinzufügen. in die Datei proguard-rules.pro ein. Beispiel:

-dontwarn java.lang.instrument.ClassFileTransformer

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

In AGP 7.0 werden fehlende Kursnachrichten als Warnungen angezeigt und Sie können in Fehler umwandeln, indem Sie android.r8.failOnMissingClasses = true Zoll gradle.properties. Ab Version 8.0 von AGP 8.0 werden diese Warnungen zu Fehler, die Ihren Build beschädigen. Es ist möglich, das AGP 7.0-Verhalten beizubehalten, Hinzufügen der Option -ignorewarnings zu Ihrem proguard-rules.pro-Datei. Dies wird jedoch nicht empfohlen.

Build-Cache des Android-Gradle-Plug-ins entfernt

Der AGP-Build-Cache wurde in AGP 4.1 entfernt. Zuvor in AGP eingeführt Als Ergänzung zum Gradle-Build-Cache wurde der AGP-Build-Cache mit Version 2.3 ersetzt. vollständig über den Gradle-Build-Cache in AGP 4.1. Diese Änderung hat keine Auswirkungen die Build-Dauer.

In AGP 7.0 wird die android.enableBuildCache-Eigenschaft android.buildCacheDir-Property und die cleanBuildCache Aufgabe wurde entfernt.

Java 11-Quellcode in einem Projekt verwenden

Du kannst jetzt im Projekt deiner App bis zu Java 11-Quellcode kompilieren. die Verwendung neuerer Sprachfunktionen wie Private-Interface-Methoden, und die Syntax lokaler Variablen für Lambda-Parameter.

Wenn Sie diese Funktion aktivieren möchten, setzen Sie compileOptions auf den gewünschten Wert Java-Version und legen Sie compileSdkVersion auf 30 oder höher fest:

// 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 sie durch api ersetzt. oder implementation.
  Gilt auch für *Compile-Varianten, z. B. debugCompile.
• provided
  Es wurde durch compileOnly ersetzt.
  Gilt auch für Varianten vom Typ *Bereitgestellt. Beispiel: releaseProvided.
• apk
  Es wurde durch runtimeOnly ersetzt.
• publish
  Es wurde durch runtimeOnly ersetzt.

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

Änderung des Klassenpfads bei der Kompilierung für Android Gradle-Plug-in

Bei der Kompilierung über das Android-Gradle-Plug-in classpath kann sich ändern. Weil AGP jetzt api/implementation verwendet Konfigurationen intern haben, werden einige Artefakte möglicherweise aus der Kompilierung entfernt. classpath zurück. Wenn Sie bei der Kompilierung von einer AGP-Abhängigkeit abhängig sind, achten Sie darauf, und fügen sie als explizite Abhängigkeit hinzu.

Zusätzliche native Bibliotheken in Java-Ressourcen Ordner wird nicht unterstützt

Bisher konnten Sie eine native Bibliothek in einem Java-Ressourcenordner hinzufügen und den Ordner mit android.sourceSets.main.resources.srcDirs registrieren, damit die native Bibliothek extrahiert und der APK Ab AGP 7.0 wird dies nicht mehr unterstützt. Java-Ressourcenordner werden ignoriert. Verwenden Sie stattdessen die DSL-Methode für native Bibliotheken, android.sourceSets.main.jniLibs.srcDirs. Für finden Sie unter Konfiguration Quellsätzen.

Bekannte Probleme

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

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

Das Android-Gradle-Plug-in 7.0.0 ist kompatibel mit Kotlin Multiplatform Plugin 1.5.0 und höher. Projekte, die Kotlin verwenden Die plattformübergreifende Unterstützung muss auf Kotlin 1.5.0 aktualisiert werden, um Android Gradle nutzen zu können. Plug-in 7.0.0. Als Behelfslösung können Sie ein Downgrade des Android-Gradle-Plug-ins ausführen. auf Version 4.2.x. Dies wird jedoch nicht empfohlen.

Weitere Informationen finden Sie unter KT-43944.

Lint-Ausgabe fehlt

Es wird kein Lint-Text an stdout ausgegeben, wenn die Lint-Aufgabe ist aktuell (Problem-Nr. 191897708) Weitere Informationen findest du unter Verhaltensänderungen für Lint Dieses Problem wird im Android-Gradle-Plug-in 7.1 behoben.

Nicht alle Abhängigkeiten der Bibliothek mit dynamischen Funktionen werden mit Lint geprüft

Wenn Lint mit checkDependencies = true von einer App-Moduls werden Abhängigkeiten von Bibliotheksbibliotheken für dynamische Funktionen nur geprüft, sind auch Anwendungsabhängigkeiten, (Problem-Nr. 191977888) Als Behelfslösung kann die Lint-Aufgabe auf diesen Bibliotheken ausgeführt werden. Um mehr Kontext zu erhalten, Weitere Informationen finden Sie unter Verhaltensänderungen für Lint.