Android-Gradle-Plug-in 4.0.0 (April 2020)

Für diese Version des Android-Plug-ins sind folgende Voraussetzungen erforderlich:

• Gradle 6.1.1. Weitere Informationen finden Sie unter Gradle aktualisieren.

• SDK-Build-Tools 29.0.2 oder höher

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 erkennen 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. Sie können das Fenster Build Analyzer in Android Studio so öffnen:

1. Erstellen Sie gegebenenfalls Ihre App. Wählen Sie dazu in der Menüleiste Build > Make Project aus.
2. Wählen Sie in der Menüleiste View > Tool Windows > Build aus.
3. Öffnen Sie das Fenster Build Analyzer im Fenster Build auf eine der folgenden Arten:
   • Nachdem Android Studio das Erstellen Ihres Projekts abgeschlossen hat, klicken Sie auf den Tab Build Analyzer.
   • Nachdem Android Studio das Erstellen Ihres Projekts abgeschlossen hat, klicken Sie auf den Link rechts im Fenster Build Output.

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 rechts im Bereich 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, mit der Sie die Auswirkungen der einzelnen Aufgaben besser nachvollziehen können. Sie können auch Details zu Warnungen aufrufen, indem Sie den Knoten Warnings 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, um Java-Sprach-APIs zu desugaren. Das bedeutet, dass Sie jetzt Standard Sprach-APIs, die nur in den letzten Android-Versionen verfügbar waren (z. B. java.util.streams), in Apps verwenden können, die ältere Android-Versionen unterstützen.

In dieser Version wird die folgende Gruppe von APIs unterstützt:

• Sequenzielle Streams (java.util.stream)
• Eine Teilmenge von java.time
• java.util.function
• Aktuelle Ergänzungen zu java.util.{Map,Collection,Comparator}
• Optionale Werte (java.util.Optional, java.util.OptionalInt und java.util.OptionalDouble) und einige andere neue Klassen, die mit den oben genannten APIs nützlich sind
• Einige Ergänzungen zu java.util.concurrent.atomic (neue Methoden für AtomicInteger, AtomicLong und AtomicReference)
• 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 fügt sie Ihrer App hinzu. Beim Desugaring-Prozess wird der Code Ihrer App so umgeschrieben, dass stattdessen diese Bibliothek zur Laufzeit verwendet wird.

Wenn Sie die Unterstützung für diese Sprach-APIs aktivieren möchten, 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 den oben genannten Code-Snippet auch in die Datei Bibliotheksmoduls' build.gradle einfügen, wenn

• die instrumentierten Tests des Bibliotheksmoduls diese Sprach-APIs verwenden (entweder direkt oder über das Bibliotheksmodul oder seine Abhängigkeiten). So werden die fehlenden APIs für das instrumentierte Test-APK bereitgestellt.

• Sie Lint für das Bibliotheksmodul isoliert ausführen möchten. So kann Lint gültige Verwendungen der Sprach-APIs erkennen und falsche Warnungen vermeiden.

Neue Optionen zum Aktivieren oder Deaktivieren von Build-Funktionen

Das Android-Gradle-Plug-in 4.0.0 bietet eine neue Möglichkeit, zu steuern, welche Build-Funktionen Sie aktivieren und deaktivieren möchten, z. B. View Binding und Data Binding. Neue Funktionen sind standardmäßig deaktiviert. Mit dem Block buildFeatures können Sie dann 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 auf Modulebene festlegen:build.gradle

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 auch die Standardeinstellung für diese Funktionen für alle Module in einem Projekt angeben, indem Sie eines oder mehrere der folgenden Elemente in die Datei gradle.properties Ihres Projekts einfügen, wie unten gezeigt. Sie können den buildFeatures Block in der Datei auf Modulebene build.gradle weiterhin verwenden, um diese projektweiten Standardeinstellungen zu ü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 einfügen, das von einem anderen Funktionsmodul abhängt. Das heißt, eine :video-Funktion kann von der :camera-Funktion abhängen, die wiederum vom Basismodul abhängt, wie in der Abbildung unten gezeigt.

Das Funktionsmodul :video hängt von der Funktion :camera ab, die vom Basismodis :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 in der Datei build.gradle des Moduls eine Abhängigkeit zwischen Funktionen 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 Abhängigkeiten zwischen 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 Help > Edit Custom VM Options 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 und höher erstellen, enthält das Plug-in Metadaten, die die Abhängigkeiten beschreiben, die in Ihre App kompiliert werden. Beim Hochladen Ihrer App prüft die Play Console diese Metadaten, um Ihnen folgende Vorteile zu bieten:

• Sie erhalten Benachrichtigungen zu bekannten Problemen mit SDKs und Abhängigkeiten, die Ihre App verwendet.
• Sie erhalten umsetzbares Feedback, um diese Probleme zu beheben.

Die Daten werden komprimiert, mit einem Google Play-Signaturschlüssel verschlüsselt und im Signaturblock Ihrer Release-App gespeichert. Sie können die Metadaten jedoch selbst in den lokalen Zwischen-Build-Dateien im folgenden Verzeichnis prüfen: <project>/<module>/build/outputs/sdk-dependencies/release/sdkDependency.txt.

Wenn Sie diese Informationen nicht freigeben möchten, können Sie die Funktion deaktivieren, indem Sie Folgendes in die Datei build.gradle 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 für die Verwendung mit Ihrem externen nativen Build-System wie CMake zur Verfügung. Gradle stellt diese Bibliotheken nur für Ihren Build zur Verfügung. Sie müssen Ihre Build-Skripts weiterhin so konfigurieren, dass sie verwendet werden.

Bibliotheken werden im Prefab-Paketformat exportiert.

Jede Abhängigkeit kann maximal ein Prefab-Paket enthalten, das ein oder mehrere Module umfasst. Ein Prefab-Modul ist eine einzelne Bibliothek, die entweder eine freigegebene, statische oder reine Header-Bibliothek sein kann.

In der Regel stimmt der Paketname mit dem Maven-Artefaktnamen und der Modulname stimmt mit dem Bibliotheksnamen überein, aber das ist 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 , wie diese Namen lauten.

Externes natives Build-System konfigurieren

Die erforderlichen Schritte finden Sie unten für das externe native Build-System das Sie verwenden möchten.

Jede AAR-Abhängigkeit Ihrer App, die nativen Code enthält, stellt eine Android.mk Datei zur Verfügung, 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 der Eigenschaft 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 die Datei „Android.mk“ einfügen:

1. Für CMake:

   add_library(app SHARED app.cpp)
   
   
   # Add these two lines.
   find_package(curl REQUIRED CONFIG)
   target_link_libraries(app curl::curl)

2. 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 CMAKE_FIND_ROOT_PATH{: .external} Variable zur Verfügung gestellt. Dieser Wert wird automatisch von Gradle festgelegt, wenn CMake aufgerufen wird. Wenn Ihr Build-System diese Variable ändert, sollten Sie sie anhängen anstatt sie zuzuweisen.

Jede Abhängigkeit stellt Ihrem CMake-Build ein Konfigurationsdateipaket{: .external} zur Verfügung, das Sie mit dem find_package{: .external} Befehl importieren. Mit diesem Befehl wird nach Konfigurationsdateipaketen gesucht, die dem angegebenen Paketnamen und der angegebenen Version entsprechen. Außerdem werden die definierten Ziele für die Verwendung in Ihrem Build zur Verfügung gestellt. Wenn Ihre Anwendung beispielsweise libapp.so definiert und curl verwendet, sollten Sie Folgendes in die Datei CMakeLists.txt einfügen:

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 Prefab-Beispiel für curl{:.external}.

Geändertes Verhalten

Wenn Sie diese Version des Plug-ins verwenden, können die folgenden Verhaltensänderungen auftreten.

Aktualisierungen der v1-/v2-Signaturkonfiguration

Das Verhalten für App-Signaturkonfigurationen im signingConfig Block hat sich wie folgt geändert:

v1-Signatur

• Wenn v1SigningEnabled explizit aktiviert ist, führt das Android-Gradle-Plug-in die v1-App-Signatur aus.
• Wenn v1SigningEnabled vom Nutzer explizit deaktiviert wird, wird die v1-App-Signatur nicht ausgeführt.
• Wenn der Nutzer die v1-Signatur nicht explizit aktiviert hat, kann sie automatisch deaktiviert werden, basierend auf minSdk und targetSdk.

v2-Signatur

• Wenn v2SigningEnabled explizit aktiviert ist, führt das Android-Gradle-Plug-in die v2-App-Signatur aus.
• Wenn v2SigningEnabled vom Nutzer explizit deaktiviert wird, wird die v2-App-Signatur nicht ausgeführt.
• Wenn der Nutzer die v2-Signatur nicht explizit aktiviert hat, kann sie automatisch deaktiviert werden basierend auf targetSdk.

Mit diesen Änderungen kann das Android-Gradle-Plug-in Builds optimieren, indem der Signaturmechanismus deaktiviert wird, je nachdem, ob der Nutzer diese Flags explizit aktiviert hat. Vor dieser Version konnte v1Signing auch dann deaktiviert werden, wenn es explizit aktiviert war, was verwirrend sein konnte.

Android-Gradle-Plug-ins feature und instantapp entfernt

Mit dem Android-Gradle-Plug-in 3.6.0 wurden das Funktions-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, um Ihre Instant Apps mit Android App Bundles zu erstellen und zu verpacken.

Im Android-Gradle-Plug-in 4.0.0 und höher wurden diese eingestellten Plug-ins vollständig entfernt. Wenn Sie das neueste Android-Gradle-Plug-in verwenden möchten, müssen Sie Ihre Instant App migrieren, um Android App Bundles zu unterstützen. Durch die Migration Ihrer Instant Apps können Sie die Vorteile von App Bundles nutzen und das modulare Design Ihrer App vereinfachen.

Hinweis: Wenn Sie Projekte öffnen möchten, die die entfernten Plug-ins in Android Studio 4.0 und höher verwenden, muss das Projekt das Android-Gradle-Plug-in 3.6.0 oder niedriger verwenden.

Separate Funktion zur Anmerkungsverarbeitung entfernt

Die Möglichkeit, die Anmerkungsverarbeitung in eine separate Aufgabe aufzuteilen, wurde entfernt. Diese Option wurde verwendet, um die inkrementelle Java-Kompilierung beizubehalten, wenn nicht inkrementelle Anmerkungsprozessoren in reinen Java-Projekten verwendet werden. Sie wurde aktiviert, indem android.enableSeparateAnnotationProcessing auf true in der gradle.properties Datei gesetzt wurde. Das funktioniert nicht mehr.

Stattdessen sollten Sie zu inkrementellen Anmerkungsprozessoren migrieren, um die Build-Leistung zu verbessern.

`includeCompileClasspath` ist veraltet

Das Android-Gradle-Plug-in prüft oder berücksichtigt keine Anmerkungsprozessoren mehr, die Sie im Kompilierungsklassenpfad deklarieren. Die annotationProcessorOptions.includeCompileClasspath DSL-Eigenschaft hat keine Auswirkungen mehr. Wenn Sie Anmerkungsprozessoren im Kompilierungsklassenpfad verwenden, wird möglicherweise der folgende Fehler angezeigt:

Error: Annotation processors must be explicitly declared now.

Um dieses Problem zu beheben, müssen Sie Anmerkungsprozessoren in Ihre build.gradle Dateien einfügen und dabei die annotationProcessor Abhängigkeitskonfiguration verwenden. Weitere Informationen finden Sie unter Annotation Processors hinzufügen.

Automatisches Verpacken vorgefertigter 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 src/main/jniLibs Verzeichnis Ihres Moduls oder in einem anderen Verzeichnis, das in der 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'

Der externe native Build verpackt diese Bibliotheken jetzt automatisch. Wenn Sie die Bibliothek also explizit mit jniLibs verpacken, entsteht ein Duplikat. Um den Build-Fehler zu vermeiden, verschieben Sie die vorgefertigte Bibliothek an einen Speicherort außerhalb von jniLibs oder entfernen Sie die jniLibs-Konfiguration aus Ihrer build.gradle Datei.

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 eine Race-Bedingung in Gradle auslösen, wenn es mit &endash;&endash;no&endash;daemon und Gradle-Versionen 6.3 oder niedriger ausgeführt wird. Dadurch können Builds nach Abschluss des Builds hängen bleiben.

Dieses Problem wird in Gradle 6.4 behoben.