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.

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:

1. Erstellen Sie Ihre App, falls noch nicht geschehen. 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 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 und java.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ü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 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:

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 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 und targetSdk 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.