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 ważna wersja, która zawiera wiele nowych funkcji i ulepszeń.

Zgodność

Do uruchomienia wtyczki Androida do obsługi Gradle 7.0 wymagany jest pakiet JDK 11

Jeśli do kompilacji 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 JDK 11 i domyślnie konfiguruje Gradle do używania. Oznacza to, że większość użytkowników Androida Studio nie musi wprowadzać żadnych zmian w konfiguracji swoich projektów.

Jeśli trzeba ręcznie ustawić wersję JDK używaną przez wtyczkę Androida do obsługi Gradle w Android Studio, musisz zastosować JDK 11 lub nowszy.

Jeśli używasz wtyczki Androida do obsługi Gradle niezależnie od Androida Studio, zaktualizuj wersję JDK, ustawiając zmienną środowiskową JAVA_HOME lub -Dorg.gradle.java.home opcję wiersza poleceń na katalog instalacyjny JDK 11.

Pamiętaj, że SDK Manager i AVD Manager w wycofanym pakiecie SDK Tools nie działają z JDK 11. Aby nadal korzystać z komponentu SDK Manager i narzędzia AVD Manager we wtyczce Androida do obsługi Gradle 7.0 i nowszych wersjach, musisz przejść na nowe wersje narzędzi w bieżącym pakiecie narzędzi wiersza poleceń Android SDK.

Stabilna wersja interfejsu API wariantów

Nowy interfejs Variant API jest już stabilny. Zobacz nowe interfejsy w pakiecie com.android.build.api.variant i przykłady w projekcie gradle-recipes na GitHubie. W ramach nowego interfejsu Variant API udostępniliśmy szereg plików pośrednich, zwanych artefaktami, za pomocą interfejsu Artifacts. Te artefakty, takie jak scalony plik manifestu, można bezpiecznie pobierać i dostosowywać za pomocą wtyczek i kodu innych firm.

Będziemy dalej rozwijać interfejs Variant API, dodając nowe funkcje i zwiększając liczbę artefaktów pośrednich, które udostępniamy do dostosowywania.

Zmiany w działaniu narzędzia Lint

W tej sekcji opisujemy kilka zmian w działaniu narzędzia Lint we wtyczce Androida do obsługi Gradle w wersji 7.0.0.

Ulepszone lintowanie zależności dotyczących bibliotek

Lintowanie kodu za pomocą checkDependencies = true przebiega teraz szybciej. W przypadku projektów aplikacji na Androida składających się z aplikacji z zależnościami dotyczącymi bibliotek zalecamy ustawienie wartości checkDependencies na true, jak pokazano poniżej, i uruchomienie lintera za pomocą polecenia ./gradlew :app:lint. Spowoduje to równoległe lintowanie wszystkich modułów zależności i wygenerowanie jednego raportu zawierającego problemy z aplikacją i wszystkimi jej zależnościami.

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

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

Zadania Lint mogą być teraz aktualne

Jeśli źródła i zasoby modułu nie uległy zmianie, zadanie analizy lintowania dla tego modułu nie musi być uruchamiane ponownie. W takim przypadku wykonanie zadania będzie w danych wyjściowych Gradle oznaczone jako „UP-TO-DATE”. Po wprowadzeniu tej zmiany podczas uruchamiania lintowania w module aplikacji z checkDependencies = true analizę będą musiały przeprowadzić tylko moduły, które uległy zmianie. Dzięki temu Lint może działać jeszcze szybciej.

Zadanie raportu Lint nie musi być też uruchamiane, jeśli jego dane wejściowe nie uległy zmianie. Powiązany znany problem polega na tym, że gdy zadanie lintowania jest aktualne, tekstowe dane wyjściowe lintowania nie są wyświetlane w strumieniu stdout (problem nr 191897708).

Lintowanie w modułach funkcji dynamicznych

Wtyczka Androida do obsługi Gradle nie obsługuje już uruchamiania lintera w modułach funkcji dynamicznych. Uruchomienie lintera z odpowiedniego modułu aplikacji spowoduje uruchomienie go w modułach funkcji dynamicznych i uwzględnienie wszystkich problemów w raporcie lintowania aplikacji. Powiązany znany problem polega na tym, że podczas uruchamiania lintera z parametrem checkDependencies = true w module aplikacji zależności dotyczących biblioteki funkcji dynamicznych nie są sprawdzane, chyba że są też zależnościami aplikacji (problem nr 191977888).

Uruchamianie lintera tylko w przypadku domyślnego wariantu

Polecenie ./gradlew :app:lint uruchamia teraz lintera tylko dla wariantu domyślnego. W poprzednich wersjach wtyczki Androida do obsługi Gradle linter był uruchamiany dla wszystkich wariantów.

Ostrzeżenia o brakujących klasach w kompresorze R8

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

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

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

Ten komunikat ostrzegawczy oznacza, że podczas analizowania kodu aplikacji nie można było znaleźć definicji klasy java.lang.instrument.ClassFileTransformer. Zwykle oznacza to błąd, ale możesz zignorować to ostrzeżenie. Dwa najczęstsze powody, dla których można zignorować ostrzeżenie:

1. Biblioteki, które są kierowane na JVM i w których brakuje klasy, mają typ biblioteki JVM (jak w przykładzie powyżej).

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

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

-dontwarn java.lang.instrument.ClassFileTransformer

Aby ułatwić Ci pracę, wtyczka Androida do obsługi Gradle wygeneruje plik zawierający wszystkie potencjalnie brakujące reguły i zapisze je w ścieżce pliku, np. app/build/outputs/mapping/release/missing_rules.txt. Dodaj reguły do pliku proguard-rules.pro, aby ignorować ostrzeżenia.

We wtyczce Androida do obsługi Gradle 7.0 komunikaty o brakujących klasach będą wyświetlane jako ostrzeżenia. Możesz je przekształcić w błędy, ustawiając android.r8.failOnMissingClasses = true w gradle.properties. We wtyczce Androida do obsługi Gradle 8.0 te ostrzeżenia staną się błędami, które spowodują przerwanie kompilacji. Możesz zachować działanie wtyczki Androida do obsługi Gradle 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 wtyczki Androida do obsługi Gradle została usunięta we wtyczce Androida do obsługi Gradle 4.1. Wprowadzona wcześniej we wtyczce Androida do obsługi Gradle 2.3 jako uzupełnienie pamięci podręcznej kompilacji Gradle, pamięć podręczna kompilacji wtyczki Androida do obsługi Gradle została we wtyczce Androida do obsługi Gradle 4.1 całkowicie zastąpiona przez pamięć podręczną kompilacji Gradle. Ta zmiana nie wpływa na czas kompilacji.

We wtyczce Androida do obsługi Gradle 7.0 usunięto właściwość android.enableBuildCache, właściwość android.buildCacheDir i zadanie cleanBuildCache.

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

W projekcie aplikacji możesz teraz kompilować kod źródłowy w wersji do Java 11, co umożliwia korzystanie z nowszych funkcji języka, takich jak prywatne metody interfejsu, operator diamentowy dla klas anonimowych i składnia zmiennych lokalnych dla parametrów lambda.

Aby włączyć tę funkcję, ustaw compileOptions na wybraną wersję Javy i compileSdkVersion na 30 lub więcej:

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

Usunięto konfiguracje zależności

We wtyczce Androida do obsługi Gradle 7.0 usunięto te konfiguracje (lub zakresy zależności):

• compile
  W zależności od przypadku użycia zostało to zastąpione przez api lub implementation.
  Dotyczy to również wariantów *Compile, np. debugCompile.
• provided
  Zostało ono zastąpione przez compileOnly.
  Dotyczy to również wariantów *Provided, np.: releaseProvided
• apk
  Zostało ono zastąpione przez runtimeOnly.
• publish
  Zostało ono zastąpione przez runtimeOnly.

W większości przypadków Asystent aktualizacji przy użyciu wtyczki Androida do obsługi Gradle automatycznie przeniesie projekt do nowych konfiguracji.

Zmiana ścieżki klas podczas kompilacji za pomocą wtyczki Androida do obsługi Gradle

Jeśli kompilujesz za pomocą wtyczki Androida do obsługi Gradle, ścieżka kompilacji może się zmienić. Ponieważ wtyczka Androida do obsługi Gradle używa teraz wewnętrznie konfiguracji api/implementation, niektóre artefakty mogą zostać usunięte ze ścieżki klas kompilacji. Jeśli w czasie kompilacji zależy Ci na zależności wtyczki Androida do obsługi Gradle, dodaj ją jako jawną zależność.

Dodawanie bibliotek natywnych w folderze zasobów Java nie jest obsługiwane

Wcześniej można było dodać bibliotekę natywną w folderze zasobów Javy i zarejestrować folder za pomocą android.sourceSets.main.resources.srcDirs , aby biblioteka natywna została wyodrębniona i dodana do końcowego pliku APK. Od wtyczki Androida do obsługi Gradle 7.0 ta funkcja nie jest obsługiwana, a biblioteki natywne w folderze zasobów Java 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 zestawów źródeł.

Znane problemy

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

Niezgodność z wtyczką Kotlin Multiplatform w wersji 1.4.x

Wtyczka Androida do obsługi Gradle w wersji 7.0.0 jest zgodna z wtyczką Kotlin Multiplatform w wersji 1.5.0 lub nowszej. Projekty korzystające z Kotlin Multiplatform muszą zostać zaktualizowane do Kotlin 1.5.0, aby można było używać wtyczki Androida do obsługi Gradle w wersji 7.0.0. Możesz cofnąć wersję wtyczki 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 lintera

Gdy zadanie lintowania jest aktualne, tekstowe dane wyjściowe lintowania nie są wyświetlane w strumieniu stdout (problem nr 191897708). Więcej informacji znajdziesz w artykule na temat zmian w działaniu lintera. Ten problem zostanie rozwiązany w wtyczce Androida do obsługi Gradle w wersji 7.1.

Nie wszystkie zależności dotyczące biblioteki funkcji dynamicznych są lintowane

Podczas uruchamiania lintera z checkDependencies = true w module aplikacji zależności dotyczących bibliotek modułów funkcji dynamicznych nie są sprawdzane, chyba że są też zależnościami aplikacji (problem 191977888). Możesz jednak uruchomić zadanie lintowania w przypadku tych bibliotek. Więcej informacji znajdziesz w artykule na temat zmian w działaniu lintera.