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 o aktualizowaniu Gradle.

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

Nowe funkcje

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

Obsługa analizatora kompilacji w Android Studio

Okno 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 Android Studio w wersji 4.0 lub nowszej z wtyczką Androida do obsługi Gradle w wersji 4.0.0 lub nowszej. Aby otworzyć okno Analizator kompilacji w Android Studio:

1. Jeśli jeszcze tego nie zrobiono, skompiluj aplikację, wybierając w pasku menu Kompilacja > Utwórz Projekt.
2. W pasku menu wybierz Widok > Okna narzędzi > Kompilacja.
3. W oknie Kompilacja otwórz okno Analizator kompilacji w 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 Dane wyjściowe 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ć jego 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ń. Możesz też wyświetlić szczegóły ostrzeżeń, rozwijając węzeł Ostrzeżenia.

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

Desugaryzacja biblioteki Java 8 w D8 i R8

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

Dzięki procesowi zwanemu desugaryzacją kompilator DEX, D8, w Android Studio w wersji 3.0 lub nowszej zapewnia już znaczną obsługę funkcji języka Java 8 (takich jak wyrażenia lambda, domyślne metody interfejsu, try with resources itp.). W Android Studio w wersji 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ługiwany jest ten zestaw interfejsów API:

• Strumienie sekwencyjne (java.util.stream)
• Podzbiór java.time
• java.util.function
• Ostatnie dodatki do java.util.{Map,Collection,Comparator}
• 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 w 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 kod do pliku modułu aplikacji's build.gradle:

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ż konieczny w pliku modułu biblioteki's build.gradle , jeśli:

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

• Chcesz uruchomić lintera w module biblioteki w izolacji. Pomaga to linterowi 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, które funkcje kompilacji chcesz włączyć i wyłączyć, np. powiązanie widoku i powiązanie danych. Gdy dodawane są nowe funkcje, są one domyślnie wyłączone. Możesz wtedy użyć bloku buildFeatures, aby włączyć tylko te funkcje, które chcesz, co pomoże Ci zoptymalizować wydajność kompilacji w projekcie. Opcje dla 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ć ustawienie domyślne tych funkcji we wszystkich modułach projektu, dodając co najmniej 1 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 ustawienia domyślne dla całego 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 funkcji od funkcji

W poprzednich wersjach wtyczki Androida do obsługi Gradle wszystkie moduły funkcji mogły zależeć tylko od modułu podstawowego aplikacji. Gdy 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 funkcja :video może zależeć od funkcji :camera która zależy od modułu podstawowego, jak pokazano na ilustracji poniżej.

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

Oznacza to, że gdy aplikacja poprosi o pobranie modułu funkcji, pobierze też inne moduły funkcji, od których zależy. Po utworzeniu modułów funkcji dla aplikacji możesz zadeklarować zależność funkcji od funkcji w pliku build.gradle modułu. Na przykład moduł :video deklaruje zależność od :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 musisz włączyć funkcję zależności funkcji od funkcji (aby obsługiwać tę funkcję np. podczas edytowania konfiguracji uruchamiania). W tym celu w pasku menu kliknij Pomoc > Edytuj niestandardowe opcje maszyny wirtualnej i dodaj ten kod:

-Drundebug.feature.on.feature=true

Metadane zależności

Gdy kompilujesz aplikację 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:

• Otrzymuj alerty o znanych problemach z pakietami SDK i zależnościami używanymi przez aplikację.
• Otrzymuj praktyczne wskazówki, które pomogą Ci rozwiązać te problemy.

Dane są kompresowane, szyfrowane za pomocą klucza podpisywania Google Play i przechowywane w bloku podpisywania aplikacji do publikowania. 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ć, dodając ten kod do pliku build.gradle modułu:

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 automatycznie udostępni te biblioteki natywne do użycia z zewnętrznym systemem kompilacji natywnej, takim jak CMake. Pamiętaj, że Gradle udostępnia te biblioteki tylko do kompilacji. Musisz skonfigurować skrypty kompilacji, aby ich używać.

Biblioteki są eksportowane w formacie pakietu Prefab.

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

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

Konfigurowanie zewnętrznego systemu kompilacji natywnej

Aby zobaczyć, jakie kroki musisz wykonać, postępuj zgodnie z instrukcjami podanymi poniżej dla zewnętrznego systemu kompilacji natywnej którego zamierzasz używać.

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 przeszukuje ścieżki określone za pomocą właściwości import&endash;add&endash;path w projekcie ndk-build. Jeśli na przykład Twoja aplikacja definiuje libapp.so i używa curl, w pliku Android.mk powinny się znajdować te elementy:

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 w projekcie CMake za pomocą CMAKE_FIND_ROOT_PATH{: .external} zmiennej. Ta wartość zostanie automatycznie ustawiona przez Gradle po wywołaniu CMake, więc jeśli system kompilacji modyfikuje tę zmienną, pamiętaj, aby do niej dołączyć raczej niż przypisywać.

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

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 skompilujesz projekt, zewnętrzny system kompilacji natywnej automatycznie połączy libapp.so z libcurl.so i spakuje libcurl.so w pliku APK lub pakiecie aplikacji. Więcej informacji znajdziesz w przykładzie prefab curl{:.external}.

Zmiany w zachowaniu

Podczas korzystania z tej wersji wtyczki możesz zauważyć te zmiany w działaniu.

Aktualizacje konfiguracji podpisywania w wersji 1 i 2

Zmieniliśmy działanie konfiguracji podpisywania aplikacji w bloku signingConfig na następujące:

Podpisywanie w wersji 1

• Jeśli v1SigningEnabled jest włączone, wtyczka Androida do obsługi Gradle wykonuje podpisywanie aplikacji w wersji 1.
• Jeśli użytkownik wyłączy v1SigningEnabled, podpisywanie aplikacji w wersji 1 nie jest wykonywane.
• Jeśli użytkownik nie włączył podpisywania w wersji 1, może ono zostać automatycznie wyłączone na podstawie minSdk i targetSdk.

Podpisywanie w wersji 2

• Jeśli v2SigningEnabled jest włączone, wtyczka Androida do obsługi Gradle wykonuje podpisywanie aplikacji w wersji 2.
• Jeśli użytkownik wyłączy v2SigningEnabled, podpisywanie aplikacji w wersji 2 nie jest wykonywane.
• Jeśli użytkownik nie włączył podpisywania w wersji 2, może ono zostać automatycznie wyłączone na podstawie targetSdk.

Te zmiany pozwalają wtyczce Androida do obsługi Gradle optymalizować kompilacje przez wyłączanie mechanizmu podpisywania na podstawie tego, czy użytkownik włączył te flagi. Przed tą wersją v1Signing mogło zostać wyłączone nawet wtedy, gdy było włączone, co mogło być mylące.

Usunięcie wtyczek 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 używania wtyczki funkcji dynamicznej (com.android.dynamic-feature) do kompilowania i pakowania aplikacji błyskawicznych za pomocą 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 korzystać z najnowszej wtyczki Androida do obsługi Gradle, musisz przeprowadzić migrację aplikacji błyskawicznej, 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 używają usuniętych wtyczek, w Android Studio w wersji 4.0 lub nowszej, projekt musi używać wtyczki Androida do obsługi Gradle w wersji 3.6.0 lub starszej.

Usunięcie funkcji oddzielnego przetwarzania adnotacji

Usunęliśmy możliwość oddzielenia przetwarzania adnotacji w osobnym zadaniu. Usunęliśmy możliwość oddzielenia przetwarzania adnotacji w osobnym zadaniu. Ta opcja była używana do utrzymywania przyrostowej kompilacji Java, gdy w projektach tylko w języku Java używane są nieprzyrostowe procesory adnotacji. Była ona włączana przez ustawienie android.enableSeparateAnnotationProcessing na true w pliku gradle.properties, co już nie działa.

Zamiast tego, aby poprawić wydajność kompilacji, przeprowadź migrację na używanie przyrostowych procesorów adnotacji.

Wycofanie includeCompileClasspath

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

Error: Annotation processors must be explicitly declared now.

Aby rozwiązać ten problem, musisz uwzględnić procesory adnotacji w swoich build.gradle plikach za pomocą 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 src/main/jniLibs katalogu modułu lub w innym katalogu skonfigurowanym w build.gradle pliku:

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 wtyczce Androida do obsługi Gradle w wersji 4.0 powyższa konfiguracja nie jest już konieczna i spowoduje niepowodzenie 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 spakowanie biblioteki za pomocą jniLibs powoduje duplikat. 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, które występują w wtyczce Androida do obsługi Gradle w wersji 4.0.0.

Sytuacja wyścigu w mechanizmie elementów roboczych Gradle

Zmiany w wtyczce Androida do obsługi Gradle w wersji 4.0 mogą powodować sytuację wyścigu w Gradle podczas uruchamiania z parametrem &endash;&endash;no&endash;daemon i w wersjach Gradle 6.3 lub starszych, co powoduje zawieszanie się kompilacji po jej zakończeniu.

Ten problem zostanie rozwiązany w Gradle 6.4.