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

Ta wersja wtyczki na Androida wymaga:

• Gradle 6.1.1. Więcej informacji znajdziesz w sekcji o aktualizowaniu Gradle.

• SDK Build Tools w wersji 29.0.2 lub nowszej.

Nowe funkcje

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

Obsługa Analizatora kompilacji Android Studio

Okno Analizator kompilacji pomaga w analizowaniu i diagnozowaniu problemów procesu kompilacji, na przykład wyłączone optymalizacje i nieprawidłowo skonfigurowane zadania. Ta funkcja jest dostępna, jeśli używasz Androida Studio 4.0 lub nowszego i Wtyczka Androida do obsługi Gradle w wersji 4.0.0 lub nowszej. Możesz otworzyć Analizator kompilacji w Android Studio w ten sposób:

1. Jeśli jeszcze tego nie zrobiłeś, utwórz aplikację, wybierając Utwórz > Marka Projekt na pasku menu.
2. Wybierz Widok > Okna narzędziowe > Utwórz kompilację z paska menu.
3. W oknie Kompilacja otwórz okno Analizator kompilacji w jednym z w następujący sposób:
   • Gdy Android Studio zakończy kompilowanie projektu, kliknij ikonę kompilacji Analizatora.
   • Gdy Android Studio zakończy kompilowanie projektu, kliknij link po prawej stronie okna Dane wyjściowe kompilacji.

Okno Analizator kompilacji zawiera listę możliwych problemów z kompilacjami w drzewie Użytkownik rozłączył się. Możesz przejrzeć i kliknąć każdy problem, aby przeanalizować jego szczegóły w po prawej stronie. Gdy Android Studio analizuje kompilację, oblicza zestaw zadań określających czas trwania kompilacji i udostępniających wizualizację i pozwoli Ci poznać efekty każdego z tych zadań. Możesz też sprawdzić szczegóły na ostrzeżenia, rozwijając węzeł Ostrzeżenia.

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

Usuwanie cukru z biblioteki Java 8 w D8 i R8

Wtyczka Androida do obsługi Gradle obsługuje teraz obsługę wielu wersji środowiska Java 8 interfejsów API języków, nie wymagając przy tym minimalnego poziomu interfejsu API aplikacji.

Za pomocą procesu o nazwie desugaring, czyli kompilatora DEX (D8) w Android Studio, Wersja 3.0 i nowsza zapewnia już istotną obsługę funkcji w języku Java 8. (takich jak wyrażenia lambda, domyślne metody interfejsu, wypróbuj z zasobami i więcej). W Android Studio 4.0 mechanizm usuwania odlustrzania został rozszerzony, do usuwania cukrów z interfejsów API w języku Java. Oznacza to, że w reklamach można teraz umieszczać reklamy standardowe interfejsów API w różnych językach, które były dostępne tylko w najnowszych wersjach Androida (np. java.util.streams) w aplikacjach, które obsługują starsze wersje Androida.

W tej wersji obsługiwany jest ten zestaw interfejsów API:

• Strumienie sekwencyjne (java.util.stream)
• Podzbiór typu java.time
• java.util.function
• Najnowsze dodatki do java.util.{Map,Collection,Comparator}
• Opcjonalne (java.util.Optional, java.util.OptionalInt i java.util.OptionalDouble) i kilka innych nowych klas przydatnych z powyższymi. Interfejsy API
• Niektóre dodatki do java.util.concurrent.atomic (nowe metody w AtomicInteger, AtomicLong i AtomicReference)
• ConcurrentHashMap (z poprawkami błędów dla Androida 5.0)

Aby zapewnić obsługę tych interfejsów API, D8 kompiluje oddzielny plik DEX biblioteki, który zawiera implementację brakujących interfejsów API i uwzględnia je w Twojej aplikacji. powoduje przepisanie kodu aplikacji tak, aby używała tej biblioteki w środowisku wykonawczym.

Aby włączyć obsługę tych interfejsów API, umieść w Plik 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 może być również konieczne umieszczenie powyższego fragmentu kodu w sekcji pliku build.gradle biblioteki biblioteki, jeśli

• Testy instrumentalne modułu biblioteki korzystają z tych interfejsów API bezpośrednio lub za pomocą modułu biblioteki bądź jego zależności). Dzięki temu brakujące interfejsy API są udostępnione dla zinstrumentowanego testowego pakietu APK.

• Chcesz uruchomić lint w module biblioteki osobno. Ma to pomóc lint rozpozna prawidłowe zastosowania interfejsów API języka i unikaj zgłaszania wartości „false” (fałsz) ostrzeżeniami.

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ć, takie jak „Wyświetl powiązanie” czy „Wiązanie danych”. Po dodaniu nowych funkcji są one domyślnie wyłączone. Dostępne opcje a następnie użyj bloku buildFeatures, aby włączyć tylko wybrane funkcje. pomaga zoptymalizować wydajność kompilacji w projekcie. Jako dla każdego modułu w pliku build.gradle na poziomie modułu zgodnie z podanymi niżej opcjami:

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 ustawienia tych funkcji we wszystkich modułach w projekcie, dodając co najmniej jeden z tych elementów w polu gradle.properties, jak pokazano poniżej. Pamiętaj, że na stronie buildFeatures w pliku build.gradle na poziomie modułu, aby je zastąpić domyślnych ustawieniach 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 dotyczących funkcji

W poprzednich wersjach wtyczki Androida do obsługi Gradle wszystkie moduły funkcji może zależeć wyłącznie od podstawowego modułu aplikacji. W przypadku korzystania z wtyczki Androida do obsługi Gradle 4.0.0 można teraz uwzględnić moduł funkcji, który zależy od innej funkcji . Oznacza to, że funkcja :video może zależeć od :camera, która zależy od modułu podstawowego, jak pokazano na ilustracji na ilustracji poniżej.

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

Oznacza to, że gdy aplikacja poprosi o pobranie modułu funkcji, pobiera też inne moduły funkcji, od których jest zależna. Po utwórz moduły funkcji dla aplikacji, możesz zadeklarować zależność od funkcji w module build.gradle. Na przykład moduł :video deklaruje zależność :camera w następujący 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 (aby obsługiwać tę funkcję podczas edytowania konfiguracji uruchamiania, przykład), klikając Pomoc > Edytuj opcje niestandardowych maszyn wirtualnych na pasku menu w tym:

-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 zawiera metadane opisujące zależności, które są zbierane w . Podczas przesyłania aplikacji Konsola Play sprawdza te metadane, aby zapewnić o następujące korzyści:

• Otrzymuj alerty o znanych problemach z pakietami SDK i zależnościami, z których korzysta Twoja aplikacja
• otrzymywać praktyczne opinie pomagające w rozwiązaniu tych problemów;

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

Jeśli nie chcesz udostępniać tych informacji, możesz z nich zrezygnować, dodając w 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
  }
}

Importuj biblioteki natywne z zależności AAR

Teraz możesz importować biblioteki C/C++ z zależności AAR aplikacji. Po wykonaniu czynności konfiguracyjnych opisane poniżej, Gradle automatycznie udostępnia te biblioteki natywne z zewnętrznym natywnym systemem kompilacji, takim jak CMake. Pamiętaj, że tylko Gradle udostępnia te biblioteki kompilacji; nadal musisz skonfigurować tworzyć skrypty, które będą z nich korzystać.

Biblioteki są eksportowane w formacie pakietu Prefab.

Każda zależność może ujawniać maksymalnie 1 pakiet Prefab, który składa się z jednego lub modułach. Moduł Prefab to jedna biblioteka, która może być udostępnianych, statycznych lub zawierających tylko nagłówek.

Zwykle nazwa pakietu odpowiada nazwie artefaktu Maven i modułu. pasuje do nazwy biblioteki, ale nie zawsze tak jest. Ponieważ trzeba wiedzieć, nazwy pakietu i modułu bibliotek, zapoznaj się z w dokumentacji zależności.

Konfigurowanie zewnętrznego natywnego systemu kompilacji

Aby zapoznać się z instrukcjami, wykonaj czynności opisane poniżej w przypadku zewnętrznego systemu kompilacji natywnego których zamierzasz użyć.

Każda z zależności AAR aplikacji, która obejmuje kod natywny, ujawnia Android.mk plik, który musisz zaimportować do projektu ndk-build. Importujesz ten plik za pomocą polecenia import&endash;module, które przeszukuje ścieżki należy określić za pomocą właściwości import&endash;add&endash;path w projekcie ndk-build. Dla: Jeśli na przykład Twoja aplikacja definiuje libapp.so i używa curl, w pliku Android.mk powinny znaleźć się te informacje:

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. Dla usługi 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 uwzględnione w AAR są udostępniane projektowi CMake za pomocą Cmake_FIND_ROOT_PATH{: .external}. Ta wartość zostanie ustawiona automatycznie przez Gradle, gdy: Metoda CMake jest wywoływana, więc jeśli Twój system kompilacji modyfikuje tę zmienną, pamiętaj o dodaniu zamiast je przypisywać.

Każda zależność ujawnia pakiet pliku konfiguracji {: .external} dla kompilacji CMake, której za pomocą polecenia find_package{: .external}. To polecenie wyszukuje plik config-file pakiety pasujące do podanej nazwy i wersji pakietu oraz ujawniające obiekty docelowe, do użycia w kompilacji. Jeśli na przykład aplikacja określa libapp.so i wykorzystuje curl, w swojej Plik CMakeLists.txt:

add_library(app SHARED app.cpp)


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

Teraz możesz określić #include "curl/curl.h" w app.cpp. Gdy tworzysz projekt, zewnętrzny natywny system kompilacji automatycznie łączy libapp.so z libcurl.so i pakietami libcurl.so w pliku APK lub pakiecie aplikacji. Dla: więcej informacji znajdziesz tutaj: curl prefab sample {:.external}.

Zmiany w działaniu

Podczas korzystania z tej wersji wtyczki możesz natrafić na te zmiany w jaki sposób.

Aktualizacje konfiguracji podpisywania w wersji 1 lub 2

Działanie konfiguracji podpisywania aplikacji w bloku signingConfig powoduje zmieniono na:

Podpisywanie w wersji 1

• Jeśli zasada 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 jest nie wykonano.
• Jeśli użytkownik nie włączył jawnie podpisywanie w wersji 1, może zostać ono włączone automatycznie. wyłączono na podstawie zasad minSdk i targetSdk.

Podpisywanie w wersji 2

• Jeśli zasada 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 jest nie wykonano.
• Jeśli użytkownik nie włączył jawnie podpisania wersji 2, może ono zostać automatycznie wyłączono na podstawie: targetSdk.

Te zmiany pozwalają AGP optymalizować kompilacje przez wyłączenie mechanizmu podpisywania zależnie od tego, czy użytkownik wyraźnie włączył te flagi. Wcześniej wersji usługi, możliwe było wyłączenie interfejsu v1Signing nawet wtedy, gdy zostało jawnie jest włączone, co może być mylące.

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

Wtyczka Androida do obsługi Gradle w wersji 3.6.0 wycofała wtyczkę funkcji (com.android.feature) i wtyczka aplikacji błyskawicznej (com.android.instantapp) w zalety korzystania z wtyczki funkcji dynamicznych (com.android.dynamic-feature), aby utworzyć i opakować aplikacji błyskawicznych korzystających z pakietów Android App Bundle.

We wtyczce Androida do obsługi Gradle w wersji 4.0.0 lub nowszej te wycofane wtyczki są całkowicie usunięte. Aby korzystać z najnowszej wtyczki Androida do obsługi Gradle, musisz przeprowadzić migrację aplikacja błyskawiczna obsługująca aplikację na Androida Pakiety. Dzięki migracji aplikacji błyskawicznych możesz korzystać z zalet aplikacji pakuj i uprość modułowy moduł aplikacji .

Uwaga: aby otworzyć projekty korzystające z usuniętych wtyczek w Android Studio 4.0 lub nowszy, projekt musi korzystać z wtyczki Android do obsługi Gradle 3.6.0 lub starsza.

Usunięto funkcję przetwarzania osobnych adnotacji

Możliwość pogrupowania przetwarzania adnotacji w dedykowane zadanie usunięto. Ta opcja została użyta do zachowania przyrostowa kompilacja Javy, gdy procesory adnotacji nieprzyrostowe są używane w projektach opartych wyłącznie na Javie; została włączona przez ustawienie android.enableSeparateAnnotationProcessing do true w gradle.properties, który już nie działa.

Zamiast tego zastosuj adnotacje przyrostowe procesory, które można usprawnić i zwiększaj wydajność.

Parametr includeCompileClasspath został wycofany

Wtyczka Androida do obsługi Gradle nie sprawdza już procesorów adnotacji ani ich nie uwzględnia zadeklarowanego w ścieżce klasy kompilacji, a tag Usługa DSL w annotationProcessorOptions.includeCompileClasspath nie ma już nie da żadnego efektu. Jeśli w ścieżce klasy kompilacji umieścisz procesory adnotacji, może otrzymać taki błąd:

Error: Annotation processors must be explicitly declared now.

Aby rozwiązać ten problem, uwzględnij procesory adnotacji w pliku build.gradle plików używających konfiguracji zależności annotationProcessor. Więcej informacji można znaleźć w sekcji Dodawanie adnotacji .

Automatyczne pakowanie gotowych zależności używane przez CMake

Wcześniejsze wersje wtyczki Androida do obsługi Gradle wymagały spakuj wszystkie gotowe biblioteki używane przez zewnętrzną kompilację natywną CMake za pomocą funkcji jniLibs. Możesz mieć biblioteki w src/main/jniLibs w katalogu Twojego modułu, a prawdopodobnie w niektórych inny katalog skonfigurowany 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 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 reklam natywnych jest teraz automatycznie pakowana biblioteki, więc wyraźnie spakowanie biblioteki za pomocą atrybutu jniLibs daje duplikat. Aby uniknąć błędu kompilacji, przenieś gotową bibliotekę do lokalizacji spoza organizacji jniLibs lub usuń konfigurację jniLibs z: build.gradle .

Znane problemy

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

Warunek wyścigu w mechanizmie instancji roboczej Gradle

Zmiany we wtyczce Androida do obsługi Gradle w wersji 4.0 mogą aktywować warunek wyścigu w Gradle w przypadku działania z &endash;&endash;no&endash;daemon i wersją Gradle 6.3 lub starszym, co powoduje konstrukcja do zawieszenia po zakończeniu tworzenia.

Ten problem zostanie rozwiązany w Gradle w wersji 6.4.