Wtyczka Androida do obsługi Gradle w wersji 7.0.0 (lipiec 2021 r.)

Wtyczka Androida do obsługi Gradle w wersji 7.0.0 to duża wersja, która zawiera różne nowe funkcje i ulepszenia.

7.0.1 (sierpień 2021 r.)

Ta niewielka aktualizacja zawiera różne poprawki błędów. Aby zobaczyć listę ważnych poprawek błędów, przeczytaj powiązany post na blogu o aktualizacjach wersji.

Zgodność

Wersja minimalna Wersja domyślna
Gradle 7.0.2 7.0.2
Narzędzia do tworzenia pakietów SDK 30.0.2 30.0.2
NDK Nie dotyczy 21.4.7075529
JDK 11 11

Do korzystania z pakietu AGP 7.0 wymagany jest pakiet JDK 11

Jeśli do tworzenia aplikacji używasz wtyczki Androida do obsługi Gradle w wersji 7.0, do uruchomienia Gradle jest teraz wymagany pakiet JDK 11. Android Studio Arctic Fox zawiera pakiet JDK 11 i konfiguruje Gradle w taki sposób, aby domyślnie używał go. Oznacza to, że większość użytkowników Androida Studio nie musi wprowadzać żadnych zmian w konfiguracji swoich projektów.

Jeśli chcesz ręcznie ustawić wersję JDK używaną przez AGP w Android Studio, musisz użyć pakietu JDK w wersji 11 lub nowszej.

Jeśli używasz AGP niezależnego od Android Studio, uaktualnij wersję JDK, ustawiając zmienną środowiskową JAVA_HOME lub opcję wiersza poleceń -Dorg.gradle.java.home na katalog instalacyjny pakietu JDK 11.

Pamiętaj, że SDK Manager i AVD Manager z wycofanego pakietu SDK Tools nie działają z pakietem JDK 11. Aby nadal korzystać z SDK Manager i AVD Manager z interfejsem AGP w wersji 7.0 lub nowszej, musisz przełączyć się na nowe wersje narzędzi w bieżącym pakiecie narzędzi wiersza poleceń pakietu Android SDK.

Wersja stabilna interfejsu API

Nowy interfejs API wariantu jest teraz stabilny. Zobacz nowe interfejsy w pakiecie com.android.build.api.variant oraz przykłady w projekcie GitHub gradle-recipes. W nowym interfejsie API wariantu udostępniliśmy w interfejsie Artifacts szereg plików pośrednich zwanych artefaktami. Te artefakty, takie jak scalony plik manifestu, można bezpiecznie uzyskać i dostosować za pomocą wtyczek i kodu innych firm.

Nadal będziemy rozszerzać interfejs API wariantu, dodając nowe funkcje i zwiększając liczbę artefaktów pośrednich, które udostępniamy do dostosowania.

Zmiany w działaniu Lint

W tej sekcji opisano różne zmiany w działaniu Lint we wtyczce Androida do obsługi Gradle w wersji 7.0.0.

Ulepszony lint dla zależności bibliotek

Uruchamianie lintowania w aplikacji checkDependencies = true jest teraz szybsze niż do tej pory. W przypadku projektów na Androida zawierających aplikację z zależnościami bibliotek zalecamy ustawienie checkDependencies na true, jak pokazano poniżej, i uruchomienie lintowania za pomocą narzędzia ./gradlew :app:lint, które przeanalizuje wszystkie moduły zależności równolegle i wygeneruje jeden raport zawierający problemy z aplikacji i wszystkie jej zależności.

Odlotowe

// build.gradle
android {
  ...
  lintOptions {
    checkDependencies true
  }
}

Kotlin

// build.gradle.kts
android {
  ...
  lint {
    isCheckDependencies = true
  }
}

Zadania Lint mogą być teraz AKTUALIZOWANE

Jeśli źródła i zasoby modułu nie uległy zmianie, zadanie analizy lint dla modułu nie musi być uruchamiane ponownie. W takim przypadku wykonanie zadania będzie oznaczone w danych wyjściowych Gradle jako „UP-TO-DATE”. Dzięki tej zmianie podczas uruchamiania lint w module aplikacji za pomocą funkcji checkDependencies = true analizę trzeba wykonać tylko w zmienionych modułach. Dzięki temu platforma Lint działa jeszcze szybciej.

Zadanie raportu Lint nie musi też być uruchamiane, jeśli jego dane wejściowe nie uległy zmianie. Powiązany znany problem polega na tym, że gdy zadanie lintowania ma stan AKTYWNY (problem nr 191897708), gdy zadanie lintowania nie jest wyświetlane jako stdout, dane wyjściowe tekstu lintowania są niedostępne.

Uruchamianie lintowania w modułach funkcji dynamicznych

AGP nie obsługuje już uruchamiania lint z modułów funkcji dynamicznych. Uruchomienie lint z odpowiedniego modułu aplikacji spowoduje uruchomienie lintowania na modułach funkcji dynamicznych i uwzględnienie wszystkich problemów w raporcie aplikacji. Powiązany znany problem polega na tym, że podczas uruchamiania lintowania za pomocą checkDependencies = true z modułu aplikacji zależności biblioteki funkcji dynamicznych nie są sprawdzane, chyba że są to jednocześnie zależności aplikacji (problem nr 191977888).

Linter uruchomiony tylko w wariancie domyślnym

Użycie polecenia ./gradlew :app:lint powoduje teraz uruchomienie narzędzia Lint tylko dla domyślnego wariantu. W poprzednich wersjach pakietu AGP uruchamiał on lint dla wszystkich wariantów.

Brak ostrzeżeń dotyczących klas w ograniczaniu R8

R8 dokładniej i konsekwentnie obsługuje brakujące klasy oraz opcję -dontwarn. Dlatego zacznij oceniać ostrzeżenia o brakujących klasach wysyłane przez R8.

Gdy R8 napotka odwołanie do klasy, które nie jest zdefiniowane w aplikacji lub jednej z jej zależności, wyświetli ostrzeżenie w danych wyjściowych kompilacji. Na przykład:

R8: Missing class: java.lang.instrument.ClassFileTransformer

To ostrzeżenie oznacza, że podczas analizowania kodu aplikacji nie udało się znaleźć definicji klasy java.lang.instrument.ClassFileTransformer. Zwykle oznacza to, że wystąpił błąd, ale możesz ignorować to ostrzeżenie. Oto 2 najczęstsze powody zignorowania ostrzeżenia:

  1. Biblioteki kierowane na JVM i brakującą klasę są typu biblioteki JVM (jak w przykładzie powyżej).

  2. Jedna z zależności używa interfejsu API tylko podczas kompilacji.

Możesz zignorować ostrzeżenie o brakujących klasach, dodając do pliku proguard-rules.pro regułę -dontwarn. Na przykład:

-dontwarn java.lang.instrument.ClassFileTransformer

Dla wygody AGP wygeneruje plik zawierający wszystkie potencjalnie brakujące reguły i zapisze je w ścieżce pliku, na przykład: app/build/outputs/mapping/release/missing_rules.txt. Aby ignorować ostrzeżenia, dodaj reguły do pliku proguard-rules.pro.

W interfejsie AGP 7.0 brakujące komunikaty klas będą wyświetlane jako ostrzeżenia. Możesz je przekształcić w błędy, ustawiając android.r8.failOnMissingClasses = true w zasadzie gradle.properties. W AGP 8.0 te ostrzeżenia są błędami, które zakłócają kompilację. Możesz zachować zachowanie AGP 7.0, dodając opcję -ignorewarnings do pliku proguard-rules.pro, ale nie jest to zalecane.

Usunięto pamięć podręczną kompilacji wtyczki Androida do obsługi Gradle

Pamięć podręczna kompilacji AGP została usunięta w AGP 4.1. Wprowadzoną wcześniej w AGP 2.3 pamięć podręczną kompilacji Gradle została w niej całkowicie zastąpiona przez pamięć podręczną kompilacji Gradle w wersji 4.1. Ta zmiana nie wpływa na czas kompilacji.

W wersji AGP 7.0 usunęliśmy właściwość android.enableBuildCache, android.buildCacheDir i zadanie cleanBuildCache.

Użyj w projekcie kodu źródłowego Java 11

Teraz w projekcie aplikacji możesz skompilować kod źródłowy Java 11, co pozwoli Ci korzystać z nowszych funkcji językowych, takich jak prywatne metody interfejsu, operator diamentowy na potrzeby klas anonimowych i składnia zmiennych lokalnych w przypadku parametrów lambda.

Aby włączyć tę funkcję, ustaw compileOptions na wybraną wersję Javy, a compileSdkVersion na wartość 30 lub wyższą:

// build.gradle
android {
  compileSdkVersion 30
  compileOptions {
    sourceCompatibility JavaVersion.VERSION_11
    targetCompatibility JavaVersion.VERSION_11
  }
  // For Kotlin projects
  kotlinOptions {
    jvmTarget = "11"
  }
}
// build.gradle.kts
android {
  compileSdkVersion(30)
  compileOptions {
    sourceCompatibility(JavaVersion.VERSION_11)
    targetCompatibility(JavaVersion.VERSION_11)
  }
  kotlinOptions {
    jvmTarget = "11"
  }
}

Konfiguracje zależności zostały usunięte

W AGP 7.0 usunęliśmy te konfiguracje (lub zakresy zależności):

  • compile
    W zależności od przypadku użycia ta funkcja została zastąpiona przez api lub implementation.
    Dotyczy również wariantów typu *Kompiluj, np.: debugCompile.
  • provided
    Zastąpiła je funkcja compileOnly.
    Dotyczy też wersji *dostarczonych, np. releaseProvided.
  • apk
    Zastąpiła je funkcja runtimeOnly.
  • publish
    Zastąpiła je funkcja runtimeOnly.

W większości przypadków Asystent uaktualniania AGP automatycznie przeniesie projekt do nowych konfiguracji.

Zmiana Classpath podczas kompilacji z wtyczką Androida Gradle

Jeśli kompilujesz ją za pomocą wtyczki do obsługi Gradle Androida, ścieżka klasy kompilacji może ulec zmianie. Ponieważ AGP używa teraz wewnętrznie konfiguracji api/implementation, niektóre artefakty mogą zostać usunięte ze ścieżki klasy kompilacji. Jeśli polegasz na zależności AGP w czasie kompilacji, pamiętaj, by dodać ją jako zależność jawną.

Dodanie bibliotek natywnych do folderu zasobów Javy nie jest obsługiwane

Wcześniej można było dodać bibliotekę natywną do folderu zasobów Javy i zarejestrować folder przy użyciu polecenia android.sourceSets.main.resources.srcDirs , co umożliwi rozpakowanie biblioteki natywnej i dodanie jej do ostatecznego pliku APK. Od wersji AGP 7.0 ta funkcja nie jest obsługiwana, a biblioteki natywne w folderze zasobów Javy są ignorowane. Zamiast tego użyj metody DSL przeznaczonej dla bibliotek natywnych (android.sourceSets.main.jniLibs.srcDirs). Więcej informacji znajdziesz w artykule o konfigurowaniu zbiorów źródłowych.

Znane problemy

W tej sekcji opisaliśmy znane problemy, które występują we wtyczce Androida do obsługi Gradle w wersji 7.0.0.

Niezgodność z wtyczką wieloplatformową Kotlin 1.4.x

Wtyczka Android do obsługi Gradle w wersji 7.0.0 jest zgodna z wtyczką wieloplatformową Kotlin w wersji 1.5.0 lub nowszej. Aby używać wtyczki Androida do obsługi Gradle w wersji 7.0.0, projekty korzystające z pomocy wieloplatformowej Kotlin muszą zostać zaktualizowane do wersji Kotlin 1.5.0. Aby obejść ten problem, możesz przywrócić wtyczkę Androida do obsługi Gradle do wersji 4.2.x, ale nie jest to zalecane.

Więcej informacji znajdziesz w artykule KT-43944.

Brak danych wyjściowych lint

Gdy zadanie lintowania jest aktualne, nie ma danych wyjściowych lintout dla wersji stdout (problem nr 191897708). Więcej informacji znajdziesz w artykule o zmianach działania lintowania. Ten problem zostanie rozwiązany we wtyczce Androida do obsługi Gradle w wersji 7.1.

Nie wszystkie zależności biblioteki funkcji dynamicznych są sprawdzane

Podczas uruchamiania lintowania z użyciem funkcji checkDependencies = true z modułu aplikacji zależności biblioteki funkcji dynamicznych nie są sprawdzane, chyba że są to również zależności aplikacji (problem nr 191977888). Aby obejść ten problem, w tych bibliotekach można uruchomić zadanie lintowania. Więcej informacji znajdziesz w artykule Zmiany w działaniu lintowania.