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

Wtyczka Androida do obsługi Gradle w wersji 7.0.0 to duża wersja, która zawiera wiele nowych funkcji i udoskonaleń.

Zgodność

Kod JDK 11 wymagany do korzystania z AGP 7.0

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

Jeśli musisz 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 pakietu AGP niezależnie od Android Studio, uaktualnij JDK, ustawiając zmienną środowiskową JAVA_HOME lub opcję wiersza poleceń -Dorg.gradle.java.home 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 używać SDK Manager i AVD Manager z AGP 7.0 lub nowszym, musisz przejść na nowe wersje narzędzi w obecnym pakiecie narzędzi wiersza poleceń Android SDK.

Stabilny interfejs API

Nowy interfejs Variant API jest teraz stabilna. Zobacz nowe interfejsy w pakiecie com.android.build.api.variant oraz przykłady w projekcie GitHub gradle-Recipes. W ramach nowego interfejsu VERSION API udostępniliśmy w interfejsie Artifacts kilka plików pośrednich, zwanych artefaktami. Te artefakty, takie jak scalony plik manifestu, można bezpiecznie uzyskać i dostosować przy użyciu wtyczek i kodu innych firm.

Będziemy dalej rozszerzać 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 Lint

W tej sekcji opisano liczne zmiany działania Lint we wtyczce Androida Gradle w wersji 7.0.0.

Ulepszone lintowanie zależności między bibliotekami

Uruchamianie linta za pomocą checkDependencies = true jest teraz szybsze niż wcześniej. W projektach na Androida składających się z aplikacji zawierającej zależności bibliotek zalecamy ustawienie checkDependencies na true, jak pokazano poniżej, i uruchomienie linta za pomocą usługi ./gradlew :app:lint, która przeanalizuje wszystkie moduły zależności równolegle i wygeneruje jeden raport uwzględniający problemy z aplikacji i wszystkie jej zależności.

// 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 ulegną zmianie, nie trzeba ponownie uruchamiać zadania analizy lintowania modułu. W takim przypadku wykonanie zadania będzie wyświetlane w danych wyjściowych Gradle jako „AKTUALNE”. Dzięki tej zmianie po uruchomieniu lint w module aplikacji z checkDependencies = true, analizy będą musiały być wykonywane tylko w zmienionych modułach. W rezultacie Lint może działać jeszcze szybciej.

Zadanie raportu Lint nie musi być uruchamiane, jeśli jego dane wejściowe nie uległy zmianie. Pokrewnym znanym problemem jest to, że zadanie lintowania nie jest drukowane na potrzeby wersji stdout (numer problemu 191897708).

Uruchamianie lint na modułach funkcji dynamicznych

AGP nie obsługuje już uruchamiania lint z modułów funkcji dynamicznych. Uruchomienie usługi lint z odpowiedniego modułu aplikacji spowoduje uruchomienie jej w modułach funkcji dynamicznych i uwzględni wszystkie problemy w raporcie dotyczącym lintowania aplikacji. Pokrewnym znanym problemem jest to, że podczas uruchamiania lint za pomocą checkDependencies = true z modułu aplikacji zależności biblioteki funkcji dynamicznych nie są sprawdzane, chyba że są one też zależnościami aplikacji (numer problemu: 191977888).

Uruchamianie lintowania tylko na wariancie domyślnym

Uruchomienie typu ./gradlew :app:lint uruchamia teraz lint tylko w przypadku domyślnego wariantu. W poprzednich wersjach AGP system lintował w przypadku wszystkich wariantów.

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

R8 bardziej precyzyjnie i konsekwentnie obsługuje brakujące klasy i opcję -dontwarn. Dlatego zacznij oceniać brakujące ostrzeżenia dotyczące klas generowane przez R8.

Gdy R8 napotka odwołanie do klasy, które nie jest zdefiniowane w aplikacji lub jedną z jej zależności, wygeneruje ostrzeżenie, które pojawi się w wynikach 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 błąd, ale możesz zignorować to ostrzeżenie. 2 najczęstsze przyczyny ignorowania 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 korzysta z interfejsu API przeznaczonego tylko do kompilacji.

Możesz zignorować ostrzeżenie o brakującej klasie, 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 podobnej do tej: app/build/outputs/mapping/release/missing_rules.txt. Dodaj reguły do pliku proguard-rules.pro, aby ignorować ostrzeżenia.

W AGP 7.0 brakujące wiadomości dotyczące zajęć będą wyświetlane jako ostrzeżenia i możesz zmienić je w błędy, ustawiając android.r8.failOnMissingClasses = true w gradle.properties. W AGP 8.0 ostrzeżenia te staną się błędami, które spowodują uszkodzenie kompilacji. Możesz zachować działanie AGP 7.0, dodając do pliku proguard-rules.pro opcję -ignorewarnings, 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. Wprowadzona w AGP 2.3, aby uzupełnić pamięć podręczną kompilacji Gradle, pamięć podręczna kompilacji AGP została w pełni zastąpiona w AGP 4.1. Ta zmiana nie wpływa na czas kompilacji.

W AGP w wersji 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

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

Aby włączyć tę funkcję, ustaw compileOptions na odpowiednią wersję Javy, a 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"
  }
}

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 ten parametr został zastąpiony przez api lub implementation.
  Dotyczy również *kompilacji wariantów, np. debugCompile.
• provided
  Ta funkcja została zastąpiona przez compileOnly.
  Dotyczy to również wersji *Dostarczone, np. releaseProvided.
• apk
  Ta funkcja została zastąpiona przez runtimeOnly.
• publish
  Ta funkcja została zastąpiona przez runtimeOnly.

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

Zmiana ścieżki klasy podczas kompilacji z wtyczką Androida Gradle

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

Dodawanie 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 za pomocą polecenia android.sourceSets.main.resources.srcDirs , aby biblioteka natywna została wyodrębniona i dodana do końcowego pliku APK. Od AGP 7.0 nie jest to obsługiwane, 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 opisujemy znane problemy, które występują we wtyczce Androida do obsługi Gradle w wersji 7.0.0.

Brak zgodności z wtyczką wieloplatformową Kotlin 1.4.x

Wtyczka Androida do obsługi Gradle w wersji 7.0.0 jest zgodna z wtyczką wieloplatformową Kotlin w wersji 1.5.0 lub nowszej. Aby korzystać z wtyczki Androida do obsługi Gradle w wersji 7.0.0 w projektach, które korzystają z obsługi wieloplatformowej Kotlin, należy zaktualizować Kotlin do wersji 1.5.0. Aby obejść ten problem, możesz obniżyć wersję wtyczki Androida do obsługi Gradle do wersji 4.2.x, choć nie jest to zalecane.

Więcej informacji znajdziesz w artykule o KT-43944.

Brak danych wyjściowych lint

Jeśli zadanie lint jest aktualne, nie będzie drukowany stdout (numer problemu 191897708). Więcej informacji znajdziesz w artykule o zmianach w działaniu linta. 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 pod kątem lintowania

Gdy uruchamiasz lint z użyciem funkcji checkDependencies = true z modułu aplikacji, zależności biblioteki funkcji dynamicznych nie są sprawdzane, chyba że są też zależnościami aplikacji (numer problemu 191977888). Aby obejść ten problem, zadanie lintowania można uruchomić w tych bibliotekach. Więcej informacji znajdziesz w artykule Zmiany w działaniu linta.