Android-Gradle-Plug-in 4.0.0 (April 2020)
Für diese Version des Android-Plug-ins ist Folgendes erforderlich:
-
Gradle 6.1.1 Weitere Informationen finden Sie im Abschnitt Gradle aktualisieren.
-
SDK Build Tools 29.0.2 oder höher.
Dieses kleinere Update unterstützt die Kompatibilität mit neuen Standardeinstellungen und Funktionen für die Paketsichtbarkeit in Android 11.
In früheren Android-Versionen war es möglich, eine Liste aller auf einem Gerät installierten Apps aufzurufen. Ab Android 11 (API-Level 30) haben Apps standardmäßig nur Zugriff auf eine gefilterte Liste der installierten Pakete.
Wenn Sie eine umfassendere Liste von Apps auf dem System sehen möchten, müssen Sie jetzt ein <queries>
-Element im Android-Manifest Ihrer App oder Bibliothek hinzufügen.
Das Android-Gradle-Plug-in 4.1 und höher ist bereits mit der neuen <queries>
-Deklaration kompatibel. Ältere Versionen sind jedoch nicht kompatibel. Wenn Sie das <queries>
-Element hinzufügen oder eine Bibliothek oder ein SDK verwenden, das das Targeting auf Android 11 unterstützt, können beim Erstellen Ihrer App Fehler beim Zusammenführen des Manifests auftreten.
Um dieses Problem zu beheben, veröffentlichen wir eine Reihe von Patches für AGP 3.3 und höher. Wenn Sie eine ältere Version von AGP verwenden, aktualisieren Sie auf eine der folgenden Versionen:
Mindestversion | Standardversio | Hinweise | |
---|---|---|---|
Gradle | 6.1.1 | 6.1.1 | Weitere Informationen finden Sie unter Gradle aktualisieren. |
SDK-Build-Tools | 29.0.2 | 29.0.2 | Installieren oder Konfigurieren Sie die SDK-Build-Tools. |
Weitere Informationen zu dieser neuen Funktion finden Sie unter Paketsichtbarkeit in Android 11.
Neue Funktionen
Diese Version des Android-Gradle-Plug-ins enthält die folgenden neuen Funktionen.
Unterstützung für Android Studio Build Analyzer
Im Fenster Build Analyzer können Sie Probleme mit Ihrem Build-Prozess nachvollziehen und diagnostizieren, z. B. deaktivierte Optimierungen und falsch konfigurierte Aufgaben.
Diese Funktion ist verfügbar, wenn Sie Android Studio 4.0 und höher mit dem Android-Gradle-Plug-in 4.0.0
und höher verwenden. So öffnen Sie das Fenster Build Analyzer in Android Studio:
- Erstellen Sie Ihre App, falls noch nicht geschehen. Wählen Sie dazu in der Menüleiste Build > Make Project aus.
- Wählen Sie in der Menüleiste View > Tool Windows > Build aus.
- Öffnen Sie im Fenster Build das Fenster Build Analyzer auf eine der folgenden Arten:
- Klicken Sie nach dem Erstellen des Projekts in Android Studio auf den Tab Build Analyzer.
- Wenn Android Studio das Projekt fertig erstellt hat, klicken Sie auf den Link auf der rechten Seite des Fensters Build Output (Build-Ausgabe).

Im Fenster Build Analyzer werden mögliche Build-Probleme links in einer Baumstruktur organisiert. Sie können jedes Problem untersuchen und darauf klicken, um die Details im Bereich rechts zu sehen. Wenn Android Studio Ihren Build analysiert, werden die Aufgaben berechnet, die die Dauer des Builds bestimmt haben. Außerdem wird eine Visualisierung bereitgestellt, damit Sie die Auswirkungen der einzelnen Aufgaben besser nachvollziehen können. Sie können auch Details zu Warnungen abrufen, indem Sie den Knoten Warnungen maximieren.
Weitere Informationen finden Sie unter Regressionen der Build-Geschwindigkeit erkennen.
Desugaring von Java 8-Bibliotheken in D8 und R8
Das Android-Gradle-Plug-in unterstützt jetzt die Verwendung einer Reihe von Java 8-Sprach-APIs, ohne dass ein Mindest-API-Level für Ihre App erforderlich ist.
Durch einen Prozess namens Desugaring bot der DEX-Compiler D8 in Android Studio 3.0 und höher bereits eine umfassende Unterstützung für Java 8-Sprachfunktionen wie Lambda-Ausdrücke, Standard-Schnittstellenmethoden und „try-with-resources“. In Android Studio 4.0 wurde die Desugaring-Engine erweitert, sodass sie auch Java-Sprach-APIs desugarn kann. Das bedeutet, dass Sie jetzt Standard-Sprach-APIs, die nur in den letzten Android-Versionen (z. B. java.util.streams
) verfügbar waren, in Apps einbinden können, die ältere Android-Versionen unterstützen.
Die folgenden APIs werden in dieser Version unterstützt:
- Sequenzielle Streams (
java.util.stream
) - Eine Teilmenge von
java.time
-
java.util.function
- Kürzlich hinzugefügte Inhalte für
java.util.{Map,Collection,Comparator}
- Optionale Elemente (
java.util.Optional
,java.util.OptionalInt
undjava.util.OptionalDouble
) und einige andere neue Klassen, die mit den oben genannten APIs nützlich sind - Einige Ergänzungen für
java.util.concurrent.atomic
(neue Methoden fürAtomicInteger
,AtomicLong
undAtomicReference
) -
ConcurrentHashMap
(mit Fehlerkorrekturen für Android 5.0)
Zur Unterstützung dieser Sprach-APIs kompiliert D8 eine separate DEX-Datei für die Bibliothek, die eine Implementierung der fehlenden APIs enthält und in Ihre App aufgenommen wird. Beim Desugaring-Prozess wird der Code Ihrer App so umgeschrieben, dass stattdessen diese Bibliothek zur Laufzeit verwendet wird.
Um die Unterstützung für diese Sprach-APIs zu aktivieren, fügen Sie der Datei build.gradle
Ihres App-Moduls Folgendes hinzu:
android {
defaultConfig {
// Required when setting minSdkVersion to 20 or lower
multiDexEnabled true
}
compileOptions {
// Flag to enable support for the new language APIs
coreLibraryDesugaringEnabled true
// Sets Java compatibility to Java 8
sourceCompatibility JavaVersion.VERSION_1_8
targetCompatibility JavaVersion.VERSION_1_8
}
}
dependencies {
coreLibraryDesugaring 'com.android.tools:desugar_jdk_libs:1.0.4'
}
android {
defaultConfig {
// Required when setting minSdkVersion to 20 or lower
multiDexEnabled = true
}
compileOptions {
// Flag to enable support for the new language APIs
isCoreLibraryDesugaringEnabled = true
// Sets Java compatibility to Java 8
sourceCompatibility = JavaVersion.VERSION_1_8
targetCompatibility = JavaVersion.VERSION_1_8
}
}
dependencies {
coreLibraryDesugaring("com.android.tools:desugar_jdk_libs:1.0.4")
}
Möglicherweise müssen Sie das obige Code-Snippet auch in die Datei build.gradle
eines Bibliotheksmoduls einfügen, wenn
-
Die instrumentierten Tests des Bibliotheksmoduls verwenden diese Sprach-APIs (entweder direkt oder über das Bibliotheksmodul oder seine Abhängigkeiten). So werden die fehlenden APIs für Ihr instrumentiertes Test-APK bereitgestellt.
-
Sie möchten Lint für das Bibliotheksmodul isoliert ausführen. So kann Lint gültige Verwendungen der Sprach-APIs erkennen und falsche Warnungen vermeiden.
Neue Optionen zum Aktivieren oder Deaktivieren von Build-Funktionen
Mit dem Android-Gradle-Plug-in 4.0.0 wird eine neue Möglichkeit eingeführt, um zu steuern, welche Build-Funktionen aktiviert und deaktiviert werden sollen, z. B. View Binding und Data Binding. Wenn neue Funktionen hinzugefügt werden, sind sie standardmäßig deaktiviert. Anschließend können Sie mit dem buildFeatures
-Block nur die gewünschten Funktionen aktivieren und so die Build-Leistung für Ihr Projekt optimieren. Sie können die Optionen für jedes Modul in der Datei build.gradle
auf Modulebene festlegen:
android {
// The default value for each feature is shown below. You can change the value to
// override the default behavior.
buildFeatures {
// Determines whether to generate a BuildConfig class.
buildConfig = true
// Determines whether to support View Binding.
// Note that the viewBinding.enabled property is now deprecated.
viewBinding = false
// Determines whether to support Data Binding.
// Note that the dataBinding.enabled property is now deprecated.
dataBinding = false
// Determines whether to generate binder classes for your AIDL files.
aidl = true
// Determines whether to support RenderScript.
renderScript = true
// Determines whether to support injecting custom variables into the module’s R class.
resValues = true
// Determines whether to support shader AOT compilation.
shaders = true
}
}
android {
// The default value for each feature is shown below. You can change the value to
// override the default behavior.
buildFeatures {
// Determines whether to generate a BuildConfig class.
buildConfig = true
// Determines whether to support View Binding.
// Note that the viewBinding.enabled property is now deprecated.
viewBinding = false
// Determines whether to support Data Binding.
// Note that the dataBinding.enabled property is now deprecated.
dataBinding = false
// Determines whether to generate binder classes for your AIDL files.
aidl = true
// Determines whether to support RenderScript.
renderScript = true
// Determines whether to support injecting custom variables into the module’s R class.
resValues = true
// Determines whether to support shader AOT compilation.
shaders = true
}
}
Sie können die Standardeinstellung für diese Funktionen auch für alle Module in einem Projekt festlegen, indem Sie eine oder mehrere der folgenden Optionen in die gradle.properties
-Datei Ihres Projekts einfügen, wie unten gezeigt. Sie können diese projektweiten Standardeinstellungen weiterhin mit dem buildFeatures
-Block in der build.gradle
-Datei auf Modulebene überschreiben.
android.defaults.buildfeatures.buildconfig=true
android.defaults.buildfeatures.aidl=true
android.defaults.buildfeatures.renderscript=true
android.defaults.buildfeatures.resvalues=true
android.defaults.buildfeatures.shaders=true
Abhängigkeiten zwischen Funktionen
In früheren Versionen des Android-Gradle-Plug-ins konnten alle Funktionsmodule nur vom Basismodul der App abhängen. Wenn Sie das Android-Gradle-Plug-in 4.0.0 verwenden, können Sie jetzt ein Funktionsmodul einbinden, das von einem anderen Funktionsmodul abhängt. Das bedeutet, dass eine :video
-Funktion von der :camera
-Funktion abhängen kann, die wiederum vom Basismodul abhängt, wie in der Abbildung unten dargestellt.

Das Funktionsmodul :video
hängt von der Funktion :camera
ab, die vom Basismodul :app
abhängt.
Wenn Ihre App also den Download eines Funktionsmoduls anfordert, werden auch andere Funktionsmodule heruntergeladen, von denen es abhängt. Nachdem Sie Funktionsmodule für Ihre App erstellt haben, können Sie eine Feature-on-Feature-Abhängigkeit in der Datei build.gradle
des Moduls deklarieren. Das Modul :video
deklariert beispielsweise eine Abhängigkeit von :camera
so:
// In the build.gradle file of the ':video' module.
dependencies {
// All feature modules must declare a dependency
// on the base module.
implementation project(':app')
// Declares that this module also depends on the 'camera'
// feature module.
implementation project(':camera')
...
}
// In the build.gradle file of the ':video' module.
dependencies {
// All feature modules must declare a dependency
// on the base module.
implementation(project(":app"))
// Declares that this module also depends on the 'camera'
// feature module.
implementation(project(":camera"))
...
}
Außerdem sollten Sie die Funktion für die Abhängigkeit von Funktionen in Android Studio aktivieren, um die Funktion beispielsweise beim Bearbeiten der Ausführungskonfiguration zu unterstützen. Klicken Sie dazu in der Menüleiste auf Hilfe > Benutzerdefinierte VM-Optionen bearbeiten und fügen Sie Folgendes ein:
-Drundebug.feature.on.feature=true
Abhängigkeiten-Metadaten
Wenn Sie Ihre App mit dem Android-Gradle-Plug-in 4.0.0 oder höher erstellen, enthält das Plug-in Metadaten, die die Abhängigkeiten beschreiben, die in Ihre App kompiliert werden. Wenn Sie Ihre App hochladen, werden diese Metadaten von der Play Console geprüft, um Ihnen die folgenden Vorteile zu bieten:
- Benachrichtigungen zu bekannten Problemen mit SDKs und Abhängigkeiten erhalten, die von Ihrer App verwendet werden
- Relevantes Feedback erhalten, um diese Probleme zu beheben
Die Daten werden komprimiert, mit einem Google Play-Signaturschlüssel verschlüsselt und im Signaturbereich Ihrer Release-App gespeichert. Sie können die Metadaten jedoch selbst in den lokalen temporären Build-Dateien im folgenden Verzeichnis prüfen: <project>/<module>/build/outputs/sdk-dependencies/release/sdkDependency.txt
.
Wenn Sie diese Informationen nicht teilen möchten, können Sie die Funktion deaktivieren, indem Sie Folgendes in die build.gradle
-Datei Ihres Moduls einfügen:
android {
dependenciesInfo {
// Disables dependency metadata when building APKs.
includeInApk = false
// Disables dependency metadata when building Android App Bundles.
includeInBundle = false
}
}
android {
dependenciesInfo {
// Disables dependency metadata when building APKs.
includeInApk = false
// Disables dependency metadata when building Android App Bundles.
includeInBundle = false
}
}
Native Bibliotheken aus AAR-Abhängigkeiten importieren
Sie können jetzt C/C++-Bibliotheken aus den AAR-Abhängigkeiten Ihrer App importieren. Wenn Sie die unten beschriebenen Konfigurationsschritte ausführen, stellt Gradle diese nativen Bibliotheken automatisch zur Verwendung mit Ihrem externen nativen Build-System wie CMake zur Verfügung. Beachten Sie, dass Gradle diese Bibliotheken nur für Ihren Build verfügbar macht. Sie müssen Ihre Build-Skripts weiterhin so konfigurieren, dass sie verwendet werden.
Bibliotheken werden im Prefab-Paketformat exportiert.
Jede Abhängigkeit kann höchstens ein Prefab-Paket bereitstellen, das ein oder mehrere Module umfasst. Ein Prefab-Modul ist eine einzelne Bibliothek, die entweder eine gemeinsam genutzte, statische oder Header-only-Bibliothek sein kann.
Normalerweise stimmt der Paketname mit dem Namen des Maven-Artefakts und der Modulname mit dem Namen der Bibliothek überein. Das ist aber nicht immer der Fall. Da Sie den Paket- und Modulnamen der Bibliotheken kennen müssen, müssen Sie möglicherweise in der Dokumentation der Abhängigkeit nachsehen, um diese Namen zu ermitteln.
Externes natives Build-System konfigurieren
Unten finden Sie die Schritte, die Sie für das externe native Build-System ausführen müssen, das Sie verwenden möchten.
Für jede AAR-Abhängigkeit Ihrer App, die nativen Code enthält, wird eine Android.mk
-Datei bereitgestellt, die Sie in Ihr ndk-build-Projekt importieren müssen. Sie importieren diese Datei mit dem Befehl import&endash;module
, der die Pfade durchsucht, die Sie mit dem Attribut import&endash;add&endash;path
in Ihrem ndk-build-Projekt angeben. Wenn Ihre Anwendung beispielsweise libapp.so
definiert und curl verwendet, sollten Sie Folgendes in Ihre Android.mk-Datei aufnehmen:
-
Für CMake:
add_library(app SHARED app.cpp)
# Add these two lines. find_package(curl REQUIRED CONFIG) target_link_libraries(app curl::curl)
-
Für
ndk-build
:include $(CLEAR_VARS) LOCAL_MODULE := libapp LOCAL_SRC_FILES := app.cpp # Link libcurl from the curl AAR. LOCAL_SHARED_LIBRARIES := curl include $(BUILD_SHARED_LIBRARY)
# If you don't expect that your project will be built using versions of the NDK # older than r21, you can omit this block. ifneq ($(call ndk-major-at-least,21),true) $(call import-add-path,$(NDK_GRADLE_INJECTED_IMPORT_PATH)) endif
# Import all modules that are included in the curl AAR. $(call import-module,prefab/curl)
Native Abhängigkeiten, die in einem AAR enthalten sind, werden Ihrem CMake-Projekt über die Variable CMAKE_FIND_ROOT_PATH{: .external} zur Verfügung gestellt. Dieser Wert wird von Gradle automatisch festgelegt, wenn CMake aufgerufen wird. Wenn Ihr Build-System diese Variable ändert, sollten Sie also Werte anhängen, anstatt sie zuzuweisen.
Jede Abhängigkeit stellt Ihrem CMake-Build ein config-file package{: .external} zur Verfügung, das Sie mit dem Befehl find_package
{: .external} importieren. Mit diesem Befehl wird nach Konfigurationsdateipaketen gesucht, die dem angegebenen Paketnamen und der angegebenen Version entsprechen. Die darin definierten Ziele werden für Ihren Build verfügbar gemacht. Wenn Ihre Anwendung beispielsweise libapp.so
definiert und curl verwendet, sollten Sie Folgendes in Ihre CMakeLists.txt
-Datei aufnehmen:
add_library(app SHARED app.cpp)
# Add these two lines.
find_package(curl REQUIRED CONFIG)
target_link_libraries(app curl::curl)
Sie können jetzt #include "curl/curl.h"
in app.cpp
angeben. Wenn Sie Ihr Projekt erstellen, verknüpft Ihr externes natives Build-System libapp.so
automatisch mit libcurl.so
und packt libcurl.so
in das APK oder App-Bundle. Weitere Informationen finden Sie im curl-Prefab-Beispiel{:.external}.
Geändertes Verhalten
Bei Verwendung dieser Version des Plug-ins können die folgenden Verhaltensänderungen auftreten.
Aktualisierungen der v1-/v2-Signaturkonfiguration
Das Verhalten für App-Signierungskonfigurationen im Block signingConfig
hat sich geändert:
V1-Signierung
- Wenn
v1SigningEnabled
explizit aktiviert ist, führt AGP die V1-App-Signatur aus. - Wenn
v1SigningEnabled
vom Nutzer explizit deaktiviert wird, erfolgt keine V1-App-Signierung. - Wenn der Nutzer die V1-Signierung nicht explizit aktiviert hat, kann sie basierend auf
minSdk
undtargetSdk
automatisch deaktiviert werden.
V2-Signierung
- Wenn
v2SigningEnabled
explizit aktiviert ist, führt AGP die App-Signatur v2 aus. - Wenn
v2SigningEnabled
vom Nutzer explizit deaktiviert wird, wird die App-Signierung mit Version 2 nicht ausgeführt. - Wenn der Nutzer die V2-Signierung nicht explizit aktiviert hat, kann sie basierend auf
targetSdk
automatisch deaktiviert werden.
Durch diese Änderungen kann AGP Builds optimieren, indem der Signiermechanismus deaktiviert wird, je nachdem, ob der Nutzer diese Flags explizit aktiviert hat. Vor diesem Release konnte v1Signing
deaktiviert werden, obwohl es explizit aktiviert war. Das konnte zu Verwirrung führen.
feature
- und instantapp
-Android-Gradle-Plug-ins entfernt
Mit dem Android Gradle-Plug-in 3.6.0 wurden das Feature-Plug-in (com.android.feature
) und das Instant App-Plug-in (com.android.instantapp
) zugunsten des Dynamic Feature-Plug-ins (com.android.dynamic-feature
) eingestellt, mit dem Sie Ihre Instant Apps mit Android App Bundles erstellen und verpacken können.
Im Android-Gradle-Plug-in 4.0.0 und höher wurden diese eingestellten Plug-ins vollständig entfernt. Wenn Sie das aktuelle Android Gradle-Plug-in verwenden möchten, müssen Sie Ihre Instant-App migrieren, um Android App Bundles zu unterstützen. Wenn Sie Ihre Instant-Apps migrieren, können Sie die Vorteile von App Bundles nutzen und das modulare Design Ihrer App vereinfachen.
Hinweis: Wenn Sie Projekte, in denen die entfernten Plug-ins verwendet werden, in Android Studio 4.0 und höher öffnen möchten, muss im Projekt das Android-Gradle-Plug-in 3.6.0 oder niedriger verwendet werden.
Separate Funktion für die Verarbeitung von Anmerkungen entfernt
Die Möglichkeit, die Annotationsverarbeitung in eine separate Aufgabe aufzuteilen, wurde entfernt. Diese Option wurde verwendet, um die inkrementelle Java-Kompilierung beizubehalten, wenn in reinen Java-Projekten nicht inkrementelle Annotationsprozessoren verwendet werden. Sie wurde aktiviert, indem android.enableSeparateAnnotationProcessing
in der Datei gradle.properties
auf true
gesetzt wurde. Das funktioniert nicht mehr.
Stattdessen sollten Sie zu inkrementellen Annotationsprozessoren migrieren, um die Build-Leistung zu verbessern.
„includeCompileClasspath“ ist veraltet
Das Android-Gradle-Plug-in prüft nicht mehr auf Annotationsprozessoren, die Sie im Compile-Classpath deklarieren, und schließt sie auch nicht mehr ein. Die DSL-Property annotationProcessorOptions.includeCompileClasspath
hat keine Auswirkungen mehr. Wenn Sie Annotationsprozessoren im Kompilierungs-Classpath angeben, erhalten Sie möglicherweise den folgenden Fehler:
Error: Annotation processors must be explicitly declared now.
Um dieses Problem zu beheben, müssen Sie Annotationsprozessoren in Ihre build.gradle
-Dateien einfügen. Verwenden Sie dazu die Abhängigkeitskonfiguration annotationProcessor
.
Weitere Informationen finden Sie unter Annotationsprozessoren hinzufügen.
Automatisches Verpacken von vorgefertigten Abhängigkeiten, die von CMake verwendet werden
In früheren Versionen des Android-Gradle-Plug-ins mussten Sie alle vorgefertigten Bibliotheken, die von Ihrem externen nativen CMake-Build verwendet werden, explizit mit jniLibs
verpacken. Möglicherweise befinden sich Bibliotheken im Verzeichnis src/main/jniLibs
Ihres Moduls oder in einem anderen Verzeichnis, das in Ihrer build.gradle
-Datei konfiguriert ist:
sourceSets {
main {
// The libs directory contains prebuilt libraries that are used by the
// app's library defined in CMakeLists.txt via an IMPORTED target.
jniLibs.srcDirs = ['libs']
}
}
sourceSets {
main {
// The libs directory contains prebuilt libraries that are used by the
// app's library defined in CMakeLists.txt via an IMPORTED target.
jniLibs.setSrcDirs(listOf("libs"))
}
}
Mit dem Android-Gradle-Plug-in 4.0 ist die oben genannte Konfiguration nicht mehr erforderlich und führt zu einem Build-Fehler:
* What went wrong:
Execution failed for task ':app:mergeDebugNativeLibs'.
> A failure occurred while executing com.android.build.gradle.internal.tasks.Workers$ActionFacade
> More than one file was found with OS independent path 'lib/x86/libprebuilt.so'
Beim externen nativen Build werden diese Bibliotheken jetzt automatisch verpackt. Wenn Sie die Bibliothek also explizit mit jniLibs
verpacken, wird sie dupliziert. Um den Build-Fehler zu vermeiden, verschieben Sie die vorkompilierte Bibliothek an einen Speicherort außerhalb von jniLibs
oder entfernen Sie die jniLibs
-Konfiguration aus der Datei build.gradle
.
Bekannte Probleme
In diesem Abschnitt werden bekannte Probleme im Android-Gradle-Plug-in 4.0.0 beschrieben.
Race-Bedingung im Gradle-Worker-Mechanismus
Änderungen im Android-Gradle-Plug-in 4.0 können unter &endash;&endash;no&endash;daemon
und mit Gradle-Versionen 6.3 oder niedriger eine Race Condition in Gradle auslösen, wodurch Builds nach Abschluss des Builds hängen bleiben.
Dieses Problem wird in Gradle 6.4 behoben.