Wtyczka Androida do obsługi Gradle w wersji 4.0.0 (kwiecień 2020 r.)

Ta wersja wtyczki Androida wymaga:

• Gradle 6.1.1. Więcej informacji znajdziesz w sekcji dotyczącej aktualizowania Gradle.

• Narzędzia do kompilacji pakietu SDK w wersji 29.0.2 lub nowszej.

Nowe funkcje

Ta wersja wtyczki Androida do obsługi Gradle zawiera te nowe funkcje:

Obsługa narzędzia Build Analyzer w Android Studio

Okno Build Analyzer (Analizator kompilacji) pomaga zrozumieć i zdiagnozować problemy z procesem kompilacji, takie jak wyłączone optymalizacje i nieprawidłowo skonfigurowane zadania. Ta funkcja jest dostępna, gdy używasz Androida Studio 4.0 lub nowszego z wtyczką Androida do obsługi Gradle w wersji 4.0.0 lub nowszej. Okno Analizator kompilacji możesz otworzyć w Android Studio w ten sposób:

1. Jeśli jeszcze tego nie zrobiono, skompiluj aplikację, wybierając Build > Make Project (Kompilacja > Utwórz projekt) na pasku menu.
2. Na pasku menu wybierz View (Widok) > Tool Windows (Okna narzędzi) > Build (Kompilacja).
3. W oknie Kompilacja otwórz okno Analizator kompilacji na jeden z tych sposobów:
   • Gdy Android Studio zakończy kompilowanie projektu, kliknij kartę Analizator kompilacji.
   • Gdy Android Studio zakończy kompilowanie projektu, kliknij link po prawej stronie okna Build Output (Wyniki kompilacji).

W oknie Analizator kompilacji możliwe problemy z kompilacją są uporządkowane w drzewie po lewej stronie. Możesz sprawdzić każdy problem i kliknąć go, aby wyświetlić szczegóły w panelu po prawej stronie. Gdy Android Studio analizuje kompilację, oblicza zestaw zadań, które wpłynęły na czas trwania kompilacji, i wyświetla wizualizację, która pomaga zrozumieć wpływ każdego z tych zadań. Szczegółowe informacje o ostrzeżeniach możesz też uzyskać, rozwijając węzeł Ostrzeżenia.

Więcej informacji znajdziesz w artykule Identyfikowanie regresji szybkości kompilacji.

Usuwanie cukru syntaktycznego z biblioteki Java 8 w D8 i R8

Wtyczka Androida do Gradle obsługuje teraz używanie wielu interfejsów API języka Java 8 bez konieczności określania minimalnego poziomu API aplikacji.

Dzięki procesowi desugaryzacji kompilator DEX, D8, w Android Studio 3.0 i nowszych zapewniał już znaczną obsługę funkcji języka Java 8 (takich jak wyrażenia lambda, domyślne metody interfejsu, try with resources i inne). W Androidzie Studio 4.0 silnik desugaryzacji został rozszerzony, aby mógł desugaryzować interfejsy API języka Java. Oznacza to, że możesz teraz uwzględniać standardowe interfejsy API języka, które były dostępne tylko w najnowszych wersjach Androida (np. java.util.streams), w aplikacjach obsługujących starsze wersje Androida.

W tej wersji obsługiwane są te interfejsy API:

• Strumienie sekwencyjne (java.util.stream)
• Podzbiór java.time
• java.util.function
• Ostatnio dodane do java.util.{Map,Collection,Comparator}
• Klasy opcjonalne (java.util.Optional, java.util.OptionalInt i java.util.OptionalDouble) oraz inne nowe klasy przydatne w przypadku powyższych interfejsów API
• Niektóre dodatki do java.util.concurrent.atomic (nowe metody na AtomicInteger, AtomicLong i AtomicReference)
• ConcurrentHashMap (z poprawkami błędów w Androidzie 5.0)

Aby obsługiwać te interfejsy API języka, D8 kompiluje osobny plik DEX biblioteki, który zawiera implementację brakujących interfejsów API i dołącza go do aplikacji. Proces desugaryzacji przepisuje kod aplikacji, aby w czasie działania używać tej biblioteki.

Aby włączyć obsługę tych interfejsów API języka, dodaj ten ciąg do pliku build.gradle modułu aplikacji:

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")
}

Pamiętaj, że powyższy fragment kodu może być też potrzebny w pliku build.gradle modułu biblioteki, jeśli

• Testy z instrumentacją modułu biblioteki korzystają z tych interfejsów API języka (bezpośrednio lub za pomocą modułu biblioteki bądź jego zależności). Dzięki temu w testowym pliku APK z instrumentacją będą dostępne brakujące interfejsy API.

• Chcesz uruchomić lint na module biblioteki w izolacji. Dzięki temu narzędzie lint będzie rozpoznawać prawidłowe użycie interfejsów API języka i unikać zgłaszania fałszywych ostrzeżeń.

Nowe opcje włączania i wyłączania funkcji kompilacji

Wtyczka Androida do obsługi Gradle w wersji 4.0.0 wprowadza nowy sposób kontrolowania funkcji kompilacji, które chcesz włączyć lub wyłączyć, takich jak powiązanie widoków i powiązanie danych. Gdy dodamy nowe funkcje, będą one domyślnie wyłączone. Następnie możesz użyć bloku buildFeatures, aby włączyć tylko te funkcje, które Cię interesują. Pomoże Ci to zoptymalizować wydajność kompilacji projektu. Opcje każdego modułu możesz ustawić w pliku build.gradle na poziomie modułu w ten sposób:

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
  }
}

Możesz też określić domyślne ustawienie tych funkcji we wszystkich modułach w projekcie, dodając co najmniej jeden z tych elementów do pliku gradle.properties projektu, jak pokazano poniżej. Pamiętaj, że nadal możesz używać bloku buildFeatures w pliku build.gradle na poziomie modułu, aby zastąpić te domyślne ustawienia na poziomie projektu.

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

Zależności między funkcjami

W poprzednich wersjach wtyczki Androida do obsługi Gradle wszystkie moduły funkcji mogły zależeć tylko od modułu podstawowego aplikacji. Jeśli używasz wtyczki Androida do obsługi Gradle w wersji 4.0.0, możesz teraz uwzględnić moduł funkcji, który zależy od innego modułu funkcji. Oznacza to, że :video funkcja może zależeć od :camera funkcji, która zależy od modułu podstawowego, jak pokazano na rysunku poniżej.

Moduł funkcji :video zależy od funkcji :camera, która zależy od modułu podstawowego :app.

Oznacza to, że gdy aplikacja zażąda pobrania modułu funkcji, pobierze też inne moduły funkcji, od których zależy. Po utworzeniu modułów funkcji aplikacji możesz zadeklarować zależność funkcji od funkcji w pliku build.gradle modułu. Na przykład moduł :video deklaruje zależność od modułu :camera w ten sposób:

// 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"))
    ...
}

Dodatkowo w Android Studio włącz funkcję zależności funkcji od funkcji (aby obsługiwać funkcję np. podczas edytowania konfiguracji uruchamiania). W tym celu na pasku menu kliknij Help > Edit Custom VM Options (Pomoc > Edytuj niestandardowe opcje maszyny wirtualnej) i dodaj te opcje:

-Drundebug.feature.on.feature=true

Metadane zależności

Podczas tworzenia aplikacji za pomocą wtyczki Androida do obsługi Gradle w wersji 4.0.0 lub nowszej wtyczka zawiera metadane opisujące zależności, które są kompilowane w aplikacji. Podczas przesyłania aplikacji Konsola Play sprawdza te metadane, aby zapewnić Ci te korzyści:

• Otrzymywanie alertów o znanych problemach z pakietami SDK i zależnościami używanymi przez aplikację
• otrzymywać przydatne opinie, które pomogą rozwiązać te problemy;

Dane są kompresowane, szyfrowane kluczem podpisywania Google Play i przechowywane w bloku podpisywania aplikacji w wersji. Możesz jednak samodzielnie sprawdzić metadane w lokalnych plikach pośrednich kompilacji w tym katalogu:<project>/<module>/build/outputs/sdk-dependencies/release/sdkDependency.txt.

Jeśli nie chcesz udostępniać tych informacji, możesz zrezygnować z tej opcji, dodając do pliku build.gradle modułu ten kod:

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
  }
}

Importowanie bibliotek natywnych z zależności AAR

Możesz teraz importować biblioteki C/C++ z zależności AAR aplikacji. Gdy wykonasz opisane poniżej czynności konfiguracyjne, Gradle automatycznie udostępni te biblioteki natywne do użycia w zewnętrznym systemie kompilacji natywnej, takim jak CMake. Pamiętaj, że Gradle tylko udostępnia te biblioteki w kompilacji. Musisz skonfigurować skrypty kompilacji, aby z nich korzystać.

Biblioteki są eksportowane w formacie pakietu Prefab.

Każda zależność może udostępniać co najwyżej 1 pakiet Prefab, który składa się z co najmniej 1 modułu. Moduł Prefab to pojedyncza biblioteka, która może być biblioteką współdzieloną, statyczną lub tylko z plikami nagłówkowymi.

Zwykle nazwa pakietu jest zgodna z nazwą artefaktu Maven, a nazwa modułu z nazwą biblioteki, ale nie zawsze tak jest. Musisz znać nazwę pakietu i modułu bibliotek, więc może być konieczne zapoznanie się z dokumentacją zależności, aby ustalić te nazwy.

Konfigurowanie zewnętrznego systemu kompilacji natywnej

Aby zobaczyć czynności, które musisz wykonać, postępuj zgodnie z instrukcjami poniżej dotyczącymi zewnętrznego natywnego systemu kompilacji, którego zamierzasz użyć.

Każda zależność AAR aplikacji, która zawiera kod natywny, udostępnia plik Android.mk, który musisz zaimportować do projektu ndk-build. Importujesz ten plik za pomocą polecenia import&endash;module, które wyszukuje ścieżki określone za pomocą właściwości import&endash;add&endash;path w projekcie ndk-build. Jeśli na przykład aplikacja definiuje libapp.so i używa curl, w pliku Android.mk należy umieścić ten kod:

1. W przypadku CMake:

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

2. W przypadku 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)

Zależności natywne zawarte w pliku AAR są udostępniane projektowi CMake za pomocą zmiennej CMAKE_FIND_ROOT_PATH{: .external}. Ta wartość zostanie automatycznie ustawiona przez Gradle po wywołaniu CMake, więc jeśli Twój system kompilacji modyfikuje tę zmienną, pamiętaj, aby do niej dołączać, a nie przypisywać.

Każda zależność udostępnia pakiet pliku konfiguracyjnego{: .external} do kompilacji CMake, który importujesz za pomocą polecenia find_package{: .external}. To polecenie wyszukuje pakiety config-file pasujące do podanej nazwy pakietu i wersji oraz udostępnia zdefiniowane przez nie cele do użycia w kompilacji. Jeśli na przykład aplikacja definiuje libapp.so i używa curl, w pliku CMakeLists.txt należy umieścić ten kod:

add_library(app SHARED app.cpp)


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

Możesz teraz określić #include "curl/curl.h" w app.cpp. Gdy tworzysz projekt, zewnętrzny system kompilacji natywnej automatycznie łączy libapp.soz libcurl.so i pakuje libcurl.so w pliku APK lub pakiecie aplikacji. Więcej informacji znajdziesz w przykładowym pliku prefabrykowanym curl{:.external}.

Zmiany w działaniu

Podczas korzystania z tej wersji wtyczki możesz zauważyć następujące zmiany w jej działaniu:

Aktualizacje konfiguracji podpisywania w wersji 1 i 2

Działanie konfiguracji podpisywania aplikacji w bloku signingConfig uległo zmianie i jest teraz następujące:

Podpisywanie w wersji 1

• Jeśli v1SigningEnabled jest wyraźnie włączona, AGP wykonuje podpisywanie aplikacji w wersji 1.
• Jeśli użytkownik wyraźnie wyłączy v1SigningEnabled, podpisywanie aplikacji w wersji 1 nie będzie wykonywane.
• Jeśli użytkownik nie włączył jawnie podpisywania w wersji 1, można je automatycznie wyłączyć na podstawie ustawień minSdk i targetSdk.

Podpisywanie w wersji 2

• Jeśli v2SigningEnabled jest wyraźnie włączona, AGP wykonuje podpisywanie aplikacji w wersji 2.
• Jeśli użytkownik wyraźnie wyłączy v2SigningEnabled, podpisywanie aplikacji w wersji 2 nie zostanie wykonane.
• Jeśli użytkownik nie włączył jawnie podpisywania w wersji 2, można je automatycznie wyłączyć na podstawie ustawienia targetSdk.

Te zmiany pozwalają AGP optymalizować kompilacje przez wyłączanie mechanizmu podpisywania w zależności od tego, czy użytkownik włączył te flagi. Przed tą wersją funkcja v1Signing mogła zostać wyłączona nawet wtedy, gdy była wyraźnie włączona, co mogło być mylące.

Usunięto wtyczki Androida do obsługi Gradle feature i instantapp

Wtyczka Androida do obsługi Gradle w wersji 3.6.0 wycofała wtyczkę funkcji (com.android.feature) i wtyczkę aplikacji błyskawicznej (com.android.instantapp) na rzecz wtyczki funkcji dynamicznych (com.android.dynamic-feature), która służy do tworzenia i pakowania aplikacji błyskawicznych przy użyciu pakietów Android App Bundle.

W wtyczce Androida do obsługi Gradle w wersji 4.0.0 i nowszej te wycofane wtyczki zostały całkowicie usunięte. Aby używać najnowszej wtyczki Androida do Gradle, musisz przenieść aplikację błyskawiczną, aby obsługiwała pakiety Android App Bundle. Dzięki migracji aplikacji błyskawicznych możesz korzystać z zalet pakietów aplikacji i uprościć modułową strukturę aplikacji.

Uwaga: aby otworzyć projekty, które korzystają z usuniętych wtyczek w Androidzie Studio 4.0 i nowszych, projekt musi używać wtyczki Androida do obsługi Gradle w wersji 3.6.0 lub starszej.

Usunięcie funkcji oddzielnego przetwarzania adnotacji

Możliwość rozdzielenia przetwarzania adnotacji na osobne zadanie została usunięta. Ta opcja była używana do utrzymywania przyrostowej kompilacji Javy, gdy w projektach opartych tylko na Javie używano procesorów adnotacji nieprzyrostowych. Była ona włączana przez ustawienie wartości android.enableSeparateAnnotationProcessing na true w pliku gradle.properties, co już nie działa.

Zamiast tego, aby zwiększyć wydajność kompilacji, używaj procesorów przyrostowych adnotacji.

includeCompileClasspath został wycofany

Wtyczka Androida do obsługi Gradle nie sprawdza już procesorów adnotacji ani nie uwzględnia ich w ścieżce kompilacji, a właściwość DSL annotationProcessorOptions.includeCompileClasspath nie ma już żadnego wpływu. Jeśli w ścieżce classpath kompilacji uwzględnisz procesory adnotacji, może pojawić się ten błąd:

Error: Annotation processors must be explicitly declared now.

Aby rozwiązać ten problem, musisz uwzględnić procesory adnotacji w plikach build.gradle, używając konfiguracji zależności annotationProcessor. Więcej informacji znajdziesz w artykule Dodawanie procesorów adnotacji.

Automatyczne pakowanie wstępnie skompilowanych zależności używanych przez CMake

W poprzednich wersjach wtyczki Androida do obsługi Gradle trzeba było jawnie spakować wszystkie wstępnie skompilowane biblioteki używane przez zewnętrzną kompilację natywną CMake za pomocą jniLibs. Biblioteki mogą znajdować się w katalogu src/main/jniLibs modułu lub w innym katalogu skonfigurowanym w pliku build.gradle:

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"))
  }
}

W przypadku wtyczki Androida do obsługi Gradle w wersji 4.0 powyższa konfiguracja nie jest już konieczna i spowoduje błąd kompilacji:

* 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'

Zewnętrzna kompilacja natywna automatycznie pakuje te biblioteki, więc jawne pakowanie biblioteki za pomocą jniLibs powoduje duplikowanie. Aby uniknąć błędu kompilacji, przenieś wstępnie skompilowaną bibliotekę do lokalizacji poza jniLibs lub usuń konfigurację jniLibs z pliku build.gradle.

Znane problemy

W tej sekcji opisujemy znane problemy występujące we wtyczce Androida do obsługi Gradle w wersji 4.0.0.

Sytuacja wyścigu w mechanizmie procesów roboczych Gradle

Zmiany we wtyczce Androida do obsługi Gradle w wersji 4.0 mogą wywołać w Gradle stan wyścigu podczas działania z &endash;&endash;no&endash;daemon i wersjami Gradle 6.3 lub starszymi, co powoduje zawieszanie się kompilacji po jej zakończeniu.

Ten problem zostanie rozwiązany w Gradle 6.4.