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

Ta wersja wtyczki na Androida wymaga:

4.0.1 (lipiec 2020 r.)

Ta niewielka aktualizacja zapewnia zgodność z nowymi ustawieniami domyślnymi i funkcjami dotyczącymi widoczności pakietów w Androidzie 11.

W poprzednich wersjach Androida można było wyświetlić listę wszystkich aplikacji zainstalowanych na urządzeniu. Od Androida 11 (poziom interfejsu API 30) aplikacje mają domyślnie dostęp tylko do przefiltrowanej listy zainstalowanych pakietów. Aby wyświetlić szerszą listę aplikacji w systemie, musisz dodać element<queries> do pliku manifestu Androida aplikacji lub biblioteki.

Wtyczka Androida do obsługi Gradle w wersji 4.1 lub nowszej jest już zgodna z nową deklaracją <queries>, ale starsze wersje nie są zgodne. Jeśli dodasz element <queries> lub zaczniesz polegać na bibliotece lub pakiecie SDK obsługującym kierowanie na Androida 11, podczas kompilowania aplikacji możesz napotkać błędy scalania pliku manifestu.

Aby rozwiązać ten problem, udostępniamy zestaw poprawek dla wersji AGP 3.3 i wyższych. Jeśli używasz starszej wersji AGP, uaktualnij ją do jednej z tych wersji:

Minimalna wersja Wersja domyślna Uwagi
Gradle 6.1.1 6.1.1 Więcej informacji znajdziesz w artykule Aktualizowanie Gradle.
Narzędzia do kompilowania pakietu SDK 29.0.2 29.0.2 Zainstaluj lub skonfiguruj narzędzia do kompilowania pakietu SDK.

Więcej informacji o tej nowej funkcji znajdziesz w artykule Widoczność pakietów w Androidzie 11.

Nowe funkcje

Ta wersja wtyczki Gradle do Androida zawiera te nowe funkcje:

Obsługa narzędzia Android Studio Build Analyzer

Okno Analizatora 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ą Android Gradle w wersji 4.0.0 lub nowszej. Aby otworzyć okno Analizatora kompilacji w Android Studio, wykonaj te czynności:

  1. Jeśli jeszcze tego nie zrobiono, utwórz aplikację, wybierając Build > Make Project na pasku menu.
  2. Na pasku menu kliknij Widok > Okna narzędzi > Kompilacja.
  3. W oknie Tworzenie otwórz okno Analizator kompilacji w jeden z tych sposobów:
    • Gdy Android Studio zakończy kompilację projektu, kliknij kartę Analizator kompilacji.
    • Gdy Android Studio skończy kompilować projekt, kliknij link po prawej stronie okna Wyniki kompilacji.

W oknie Analizator kompilacji możliwe problemy z kompilacją są grupowane w drzewie po lewej stronie. Aby sprawdzić szczegóły danego problemu, kliknij go w panelu po prawej stronie. Podczas analizowania kompilacji Android Studio oblicza zestaw zadań, które określiły czas jej trwania, oraz zapewnia wizualizację, która ułatwia zrozumienie wpływu 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.

desugaring biblioteki Java 8 w D8 i R8,

Wtyczka Gradle dla Androida obsługuje teraz interfejsy API języka Java 8, nie wymagając minimalnego poziomu interfejsu API dla aplikacji.

Dzięki procesowi zwanemu desugaring kompilator DEX, D8, w Android Studio 3.0 i nowszych wersjach zapewnia już znaczne wsparcie dla funkcji języka Java 8 (takich jak wyrażenia lambda, domyślne metody interfejsu, instrukcja try z zasobami itp.). W Android Studio 4.0 mechanizm desugaringu został rozszerzony, aby umożliwić desugaring interfejsów API w języku Java. Oznacza to, że teraz możesz używać standardowych interfejsów API języka, które były dostępne tylko w najnowszych wersjach Androida (takich jak java.util.streams) w aplikacjach obsługujących starsze wersje Androida.

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

  • Sekwencyjne strumienie (java.util.stream)
  • Podzbiór java.time
  • java.util.function
  • Ostatnie dodane elementy w tabeli java.util.{Map,Collection,Comparator}
  • Opcjonalne (java.util.Optional, java.util.OptionalInt i java.util.OptionalDouble) oraz inne nowe klasy przydatne w przypadku wymienionych interfejsów 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 obsługiwać te interfejsy API języka, D8 kompiluje oddzielny plik biblioteki DEX, który zawiera implementację brakujących interfejsów API i włącza go w aplikacji. Proces decukrowania przepisuje kod aplikacji, aby używał tej biblioteki w czasie wykonywania.

Aby włączyć obsługę tych interfejsów API języka, dodaj 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 ten 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 lub jego zależności). Dzięki temu brakujące interfejsy API są dostępne w stworzonym przez Ciebie testowym pliku APK z instrumentacją.

  • chcesz uruchomić lint na module biblioteki w osobnym środowisku; Ma to pomóc lintowi rozpoznać prawidłowe użycie interfejsów API języka i uniknąć raportowania 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łączać i wyłączać, np. View Binding i Data Binding. 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órych potrzebujesz. Pomoże Ci to zoptymalizować wydajność kompilacji w przypadku 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, podając w pliku gradle.properties projektu co najmniej 1 z tych opcji, 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 funkcji od funkcji

W poprzednich wersjach wtyczki Androida do obsługi Gradle wszystkie moduły funkcji mogły zależeć tylko od podstawowego modułu aplikacji. Korzystając z 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 z kolei zależy od modułu podstawowego, jak pokazano na rysunku poniżej.

Zależność funkcji od funkcji

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

Oznacza to, że gdy aplikacja poprosi o pobieranie modułu funkcji, pobiera również inne moduły funkcji, od których zależy. Po utworzeniu modułów funkcji w 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 (aby funkcja była obsługiwana podczas edytowania konfiguracji uruchomienia) włącz funkcję zależności funkcji od funkcji, klikając Pomoc > Edytuj niestandardowe opcje maszyny wirtualnej na pasku menu.

-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 skompilowane w aplikacji. Podczas przesyłania aplikacji Konsola Play sprawdza te metadane, aby zapewnić Ci następujące korzyści:

  • otrzymywać alerty o znanych problemach z pakietami SDK i zależnymi komponentami, których używa Twoja aplikacja;
  • otrzymywać praktyczne informacje, które pomogą rozwiązać te problemy.

Dane są kompresowane, szyfrowane kluczem podpisywania Google Play i przechowywane w bloku podpisywania aplikacji. 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 ich udostępniania, dodając do pliku build.gradle modułu następujące informacje:

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żnych plików AAR

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

Biblioteki są eksportowane w formacie pakietu Prefab.

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

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

Konfigurowanie zewnętrznego systemu kompilacji natywnych

Aby dowiedzieć się, co należy zrobić, wykonaj czynności opisane poniżej w przypadku zewnętrznego systemu kompilacji natywnych, 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. Plik ten importujesz 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 aplikacja definiuje libapp.so i korzysta z curl, w pliku Android.mk należy uwzględnić 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. Do witryn 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)

Natywne zależności zawarte w pliku AAR są udostępniane projektowi CMake za pomocą zmiennej CMAKE_FIND_ROOT_PATH{: .external}. Ta wartość zostanie ustawiona automatycznie przez Gradle, gdy wywołasz CMake, więc jeśli Twój system kompilacji modyfikuje tę zmienną, dołącz ją, a nie przypisuj.

Każda zależność udostępnia pakiet pliku konfiguracyjnego {: .external} w kompilacji CMake, który możesz zaimportować za pomocą polecenia find_package{: .external}. To polecenie wyszukuje pakiety z plikami konfiguracyjnymi, które pasują do podanej nazwy i wersji pakietu, oraz udostępnia cele zdefiniowane przez te pakiety do użycia w kompilacji. Jeśli na przykład Twoja aplikacja definiuje zmienną libapp.so i korzysta z polecenia curl, w pliku CMakeLists.txt musisz uwzględnić te informacje:


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. Podczas kompilowania projektu zewnętrzny system kompilacji natywnych aplikacji automatycznie łączy libapp.so z libcurl.so oraz pakietami libcurl.so w pliku APK lub pakiecie aplikacji. Więcej informacji znajdziesz w pliku curl prefab sample{:.external}.

Zmiany w zachowaniu

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

Aktualizacje konfiguracji podpisywania w wersji 1 i 2

Zmieniliśmy sposób działania konfiguracji podpisywania aplikacji w bloku signingConfig:

podpisywanie w wersji 1,

  • Jeśli opcja v1SigningEnabled jest wyraźnie włączona, AGP wykonuje podpisywanie aplikacji w wersji 1.
  • Jeśli użytkownik wyraźnie wyłączy opcję v1SigningEnabled, podpisywanie aplikacji w wersji 1 nie będzie wykonywane.
  • Jeśli użytkownik nie włączył wyraźnie podpisywania w wersji 1, może ono zostać automatycznie wyłączone na podstawie minSdk i targetSdk.

Podpisywanie w wersji 2

  • Jeśli opcja v2SigningEnabled jest wyraźnie włączona, AGP wykonuje podpisywanie aplikacji w wersji 2.
  • Jeśli użytkownik wyraźnie wyłączy opcję v2SigningEnabled, podpisywanie aplikacji w wersji 2 nie zostanie wykonane.
  • Jeśli użytkownik nie włączył wyraźnie podpisywania v2, może ono zostać automatycznie wyłączone na podstawie targetSdk.

Te zmiany umożliwiają AGP optymalizowanie wersji przez wyłączenie mechanizmu podpisywania w zależności od tego, czy użytkownik wyraźnie włączył te flagi. Przed tą wersją v1Signing mogło być wyłączone, nawet jeśli zostało wyraźnie włączone, co mogło być mylące.

Usunięcie wtyczek feature i instantapp Androida do obsługi Gradle

Wtyczka Androida do obsługi Gradle 3.6.0 wycofuje wtyczkę funkcji (com.android.feature) i wtyczkę aplikacji błyskawicznej (com.android.instantapp) na rzecz wtyczki funkcji dynamicznych (com.android.dynamic-feature), aby kompilować i pakować aplikacje błyskawiczne za pomocą pakietów aplikacji na Androida.

W wersji 4.0.0 wtyczki Androida do obsługi Gradle i starsze zostały całkowicie usunięte. Aby więc korzystać z najnowszej wersji wtyczki Gradle na Androida, musisz przeprowadzić migrację swojej aplikacji błyskawicznej, aby obsługiwała pakiety Android App Bundle. Migrując aplikacje błyskawiczne, możesz korzystać z zalet pakietów aplikacji i uprościć modularną strukturę aplikacji.

Uwaga: aby otworzyć projekty korzystające z usuniętej wtyczki w Android Studio 4.0 lub nowszej wersji, projekt musi używać wtyczki Android Gradle w wersji 3.6.0 lub starszej.

Usunięcie funkcji osobnego przetwarzania adnotacji

Usunięto możliwość oddzielnego przetwarzania adnotacji w ramach dedykowanego zadania. Ta opcja była używana do utrzymywania kompilacji przyrostowej w Javie, gdy w projektach zawierających tylko Javę używane są procesory adnotacji nieprzyrostowych. Została włączona przez ustawienie wartości android.enableSeparateAnnotationProcessing na true w pliku gradle.properties, który nie działa już poprawnie.

Zamiast tego musisz przejść na wykorzystanie procesorów z wykorzystaniem anotacji incremental, aby zwiększyć skuteczność kompilacji.

Argument includeCompileClasspath został wycofany

Wtyczka Android Gradle nie sprawdza już procesorów adnotacji ani ich nie uwzględnia w ścieżce kompilacji. Właściwość DSL annotationProcessorOptions.includeCompileClasspath nie ma już żadnego wpływu. Jeśli do ścieżki kompilacji dodasz 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 utworzonych zależności używanych przez CMake;

W poprzednich wersjach wtyczki Android Gradle wymagane było jawne pakowanie wszystkich wstępnie utworzonych bibliotek używanych przez zewnętrzną kompilację natywną CMake za pomocą jniLibs. Biblioteki mogą znajdować się w katalogu src/main/jniLibs w module 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 wersji 4.0 wtyczki Androida do obsługi Gradle powyższa konfiguracja nie jest już potrzebna 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'

Kompilacja natywnych bibliotek zewnętrznych jest teraz automatycznie pakowana, więc jawne zapakowanie biblioteki za pomocą jniLibs spowoduje jej 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 opisano znane problemy występujące w wersji 4.0.0 wtyczki Androida do obsługi Gradle.

Sytuacja wyścigu w mechanizmie instancji roboczej Gradle

Zmiany w wtyczce Androida do obsługi Gradle w wersji 4.0 mogą wywołać stan wyścigu w Gradle, gdy jest ona uruchamiana 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.