Android Gradle Plugin 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 zum Aktualisieren von Gradle.

• 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 oder höher mit dem Android Gradle-Plug-in 4.0.0 oder höher verwenden. So öffnen Sie das Fenster Build Analyzer in Android Studio:

1. Erstellen Sie gegebenenfalls Ihre Anwendung. Wählen Sie dazu in der Menüleiste Build > Make Project aus.
2. Wählen Sie in der Menüleiste Ansicht > Toolfenster > Build aus.
3. Öffnen Sie im Fenster Build das Fenster Build Analyzer auf eine der folgenden Arten:
   • Nachdem das Projekt in Android Studio erstellt wurde, klicken Sie auf den Tab Build Analyzer (Build-Analyse).
   • Nachdem Android Studio das Projekt erstellt hat, klicken Sie rechts im Fenster Build-Ausgabe auf den Link.

Im Fenster Build Analyzer (Build-Analyse) werden mögliche Build-Probleme links in einem Baum organisiert. Sie können die einzelnen Probleme prüfen 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 angezeigt, mit der 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 Rückgänge bei der Build-Geschwindigkeit erkennen.

Java 8-Bibliotheksdesugaring in D8 und R8

Das Android Gradle-Plug-in unterstützt jetzt die Verwendung einer Reihe von Java 8-Sprach-APIs, ohne dass eine API-Mindestebene für Ihre App erforderlich ist.

Durch ein Verfahren namens Desugaring bot der DEX-Compiler D8 in Android Studio 3.0 und höher bereits eine umfassende Unterstützung für Java 8-Sprachfeatures wie Lambda-Ausdrücke, Standard-Schnittstellenmethoden und „try with resources“. In Android Studio 4.0 wurde die Desugaring-Engine erweitert, sodass Java-Sprach-APIs desugared werden können. Das bedeutet, dass Sie jetzt Standard-Sprach-APIs, die nur in den letzten Android-Releases (z. B. java.util.streams) verfügbar waren, in Apps einbinden können, die ältere Android-Versionen unterstützen.

In dieser Version werden die folgenden APIs unterstützt:

• Sequenzielle Streams (java.util.stream)
• Eine Teilmenge von java.time
• java.util.function
• Kürzlich zu java.util.{Map,Collection,Comparator} hinzugefügte Elemente
• Optionale Optionen (java.util.Optional, java.util.OptionalInt und java.util.OptionalDouble) sowie einige andere neue Klassen, die für die 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-Bibliotheksdatei, die eine Implementierung der fehlenden APIs enthält, und fügt sie Ihrer App hinzu. Beim Entfernen der Verschleierung wird der Code Ihrer App umgeschrieben, damit 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 das obige Code-Snippet auch in die build.gradle-Datei 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 separat 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

Das Android-Gradle-Plug-in 4.0.0 bietet eine neue Möglichkeit, Build-Funktionen wie View- und Data Binding zu aktivieren und zu deaktivieren. Neue Funktionen sind standardmäßig deaktiviert. Anschließend können Sie mit dem Block buildFeatures 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 build.gradle-Datei auf Modulebene so 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 angeben, indem Sie eine oder mehrere der folgenden Optionen in die gradle.properties-Datei Ihres Projekts einfügen, wie unten gezeigt. Sie können weiterhin den Block buildFeatures in der build.gradle-Datei auf Modulebene 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 Feature-Modul einschließen, das von einem anderen Feature-Modul 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 dargestellt.

Das Funktionsmodul :video hängt von der Funktion :camera ab, die wiederum vom Basismodul :app abhängt.

Wenn Ihre App also den Download eines Funktionsmoduls anfordert, werden auch andere Funktionsmodule heruntergeladen, von denen sie abhängt. Nachdem Sie Funktionsmodule für Ihre App erstellt haben, können Sie in der build.gradle-Datei des Moduls eine Abhängigkeit zwischen Funktionen deklarieren. Im Modul :video wird beispielsweise eine Abhängigkeit von :camera so deklariert:

// 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 „Funktionsabhängigkeit“ 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 geben Sie Folgendes ein:

-Drundebug.feature.on.feature=true

Abhängigkeitsmetadaten

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. Beim Hochladen Ihrer App werden diese Metadaten in der Play Console geprüft. Dadurch ergeben sich folgende Vorteile:

• Benachrichtigungen zu bekannten Problemen mit SDKs und Abhängigkeiten erhalten, die Ihre App verwendet
• Um umsetzbares Feedback zur Behebung dieser Probleme zu erhalten

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 Zwischenbuilddateien 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 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 für die 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-Scripts noch so konfigurieren, dass sie verwendet werden.

Bibliotheken werden im Paketformat Prefab exportiert.

Jede Abhängigkeit kann höchstens ein Prefab-Paket bereitstellen, das ein oder mehrere Module enthält. Ein Prefab-Modul ist eine einzelne Bibliothek, die entweder eine freigegebene, statische oder reine Header-Bibliothek sein kann.

Normalerweise stimmen der Paketname mit dem Maven-Artefaktnamen und der Modulname mit dem Bibliotheksnamen überein. Das ist jedoch 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 Buildsystem konfigurieren

Folgen Sie der Anleitung 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 bereit, 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 import&endash;add&endash;path-Eigenschaft in Ihrem ndk-build-Projekt angeben. Wenn Ihre Anwendung beispielsweise libapp.so definiert und curl verwendet, sollten Sie Folgendes in die Datei „Android.mk“ 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 automatisch von Gradle festgelegt, wenn CMake aufgerufen wird. Wenn Ihr Build-System diese Variable ändert, fügen Sie ihr einen Wert hinzu, anstatt ihn zuzuweisen.

Jede Abhängigkeit stellt Ihrem CMake-Build ein Konfigurationsdateipaket{: .external} zur Verfügung, das Sie mit dem Befehl find_package{: .external} importieren. Mit diesem Befehl wird nach Konfigurationsdateipaketen gesucht, die mit dem angegebenen Paketnamen und der angegebenen Version übereinstimmen. Die darin definierten Ziele werden für Ihren Build freigegeben. Wenn Ihre Anwendung beispielsweise libapp.so definiert und curl verwendet, sollten Sie Folgendes in die Datei CMakeLists.txt 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 verpackt libcurl.so im APK oder App-Bundle. Weitere Informationen finden Sie im Beispiel für Curl-Prefab{:.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 der App-Signaturkonfigurationen im Block signingConfig hat sich so geändert:

V1-Signatur

• Wenn v1SigningEnabled explizit aktiviert ist, führt AGP die App-Signatur v1 aus.
• Wenn v1SigningEnabled vom Nutzer ausdrücklich deaktiviert wird, wird die App-Signatur der Version 1 nicht durchgeführt.
• Wenn der Nutzer die V1-Signatur nicht explizit aktiviert hat, kann sie basierend auf minSdk und targetSdk automatisch deaktiviert werden.

V2-Signatur

• Wenn v2SigningEnabled explizit aktiviert ist, führt AGP die App-Signatur V2 aus.
• Wenn v2SigningEnabled vom Nutzer ausdrücklich deaktiviert wird, wird die V2-App-Signatur nicht ausgeführt.
• Wenn der Nutzer die V2-Signatur nicht explizit aktiviert hat, kann sie basierend auf targetSdk automatisch deaktiviert werden.

Durch diese Änderungen kann AGP Builds optimieren, indem der Signaturmechanismus deaktiviert wird, je nachdem, ob der Nutzer diese Flags explizit aktiviert hat. Vor dieser Version war es möglich, dass v1Signing deaktiviert wurde, auch wenn es ausdrücklich aktiviert war. Das konnte verwirrend sein.

feature und instantapp werden aus den Android-Gradle-Plug-ins 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) eingestellt. Stattdessen wird das Plug-in für dynamische Funktionen (com.android.dynamic-feature) verwendet, um Instant-Apps mit Android App Bundles zu erstellen und zu verpacken.

Im Android-Gradle-Plug-in 4.0.0 und höher sind diese veralteten Plug-ins vollständig entfernt. Wenn Sie also das neueste Android Gradle-Plug-in verwenden möchten, müssen Sie Ihre Instant-App zur Unterstützung von Android App Bundles migrieren. 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, die die entfernten Plug-ins verwenden, in Android Studio 4.0 und höher öffnen möchten, muss das Projekt das Android Gradle-Plug-in 3.6.0 oder niedriger verwenden.

Separate Funktion zur Anmerkungsverarbeitung 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 Anmerkungs-Prozessoren verwendet werden. Sie wurde aktiviert, indem in der Datei gradle.properties android.enableSeparateAnnotationProcessing auf true gesetzt wurde. Dies funktioniert nicht mehr.

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

„includeCompileClasspath“ wird nicht mehr unterstützt

Das Android Gradle-Plug-in prüft nicht mehr auf Annotation-Prozessoren, die Sie im Compile-Classpath angeben, und die DSL-Eigenschaft annotationProcessorOptions.includeCompileClasspath hat keine Auswirkungen mehr. Wenn Sie Annotation-Prozessoren in den Compile-Classpath aufnehmen, wird möglicherweise der folgende Fehler ausgegeben:

Error: Annotation processors must be explicitly declared now.

Um dieses Problem zu beheben, müssen Sie Anmerkungs-Prozessoren in Ihre build.gradle-Dateien aufnehmen, indem Sie die annotationProcessor-Abhängigkeitskonfiguration verwenden. Weitere Informationen finden Sie unter Hinweis-Ebenen hinzufügen.

Automatisches Paketieren vorgefertigter Abhängigkeiten, die von CMake verwendet werden

Bei früheren Versionen des Android Gradle-Plug-ins mussten Sie alle vorkonfigurierten Bibliotheken, die von Ihrem externen nativen CMake-Build verwendet werden, mit jniLibs explizit 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'

Diese Bibliotheken werden jetzt automatisch im externen nativen Build verpackt. Wenn Sie die Bibliothek also explizit mit jniLibs verpacken, führt dies zu einer Duplizierung. Verschieben Sie die vorkonfigurierte Bibliothek an einen Speicherort außerhalb von jniLibs oder entfernen Sie die jniLibs-Konfiguration aus der build.gradle-Datei, um den Buildfehler zu vermeiden.

Bekannte Probleme

In diesem Abschnitt werden bekannte Probleme mit dem Android Gradle-Plug-in 4.0.0 beschrieben.

Race-Bedingung im Gradle-Worker-Mechanismus

Änderungen am Android Gradle-Plug-in 4.0 können bei Verwendung mit &endash;&endash;no&endash;daemon und Versionen von Gradle 6.3 oder niedriger zu einer Race-Condition in Gradle führen, was dazu führt, dass Builds nach dem Build hängen bleiben.

Dieses Problem wird in Gradle 6.4 behoben.