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

Wtyczka Androida do obsługi Gradle w wersji 7.0.0 to ważna aktualizacja, która zawiera wiele nowych funkcji i ulepszeń.

Zgodność

Do uruchamiania AGP 7.0 wymagana jest wersja JDK 11

Jeśli do kompilowania aplikacji używasz wtyczki Androida do obsługi Gradle w wersji 7.0, do uruchomienia Gradle wymagana jest teraz wersja JDK 11. Android Studio Arctic Fox zawiera pakiet JDK 11 i konfiguruje Gradle do użycia go domyślnie, co oznacza, ż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ę pakietu JDK używaną przez AGP w Android Studio, musisz użyć pakietu JDK 11 lub nowszego.

Jeśli używasz AGP niezależnie od Android 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 Menedżer pakietu SDK i Menedżer AVD w wycofanym pakiecie narzędzi SDK nie działają z JDK 11. Aby nadal korzystać z Menedżera pakietu SDK i Menedżera AVD w wersji AGP 7.0 lub nowszej, musisz przejść na nowe wersje narzędzi w bieżącym pakiecie Android SDK Command-Line Tools.

Stabilna wersja interfejsu Variant API

Nowy interfejs Variant API jest już stabilny. Nowe interfejsy znajdziesz w pakiecie com.android.build.api.variant, a przykłady – w projekcie gradle-recipes na GitHubie. W ramach nowego interfejsu Variant API udostępniliśmy kilka plików pośrednich, zwanych artefaktami, za pomocą interfejsu Artifacts. Te elementy, np. scalony plik manifestu, można bezpiecznie pobrać i spersonalizować za pomocą 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 udostępnianych do personalizacji.

Zmiany w działaniu Lint

W tym rozdziale opisaliśmy wiele zmian w zachowaniu Lint w nowej wersji wtyczki Androida do obsługi Gradle 7.0.0.

Ulepszona funkcja lint dla zależności bibliotek

Uruchamianie linta za pomocą checkDependencies = true jest teraz szybsze niż wcześniej. W przypadku projektów na Androida, które składają się z aplikacji z zależnościami bibliotek, zalecamy ustawienie wartości checkDependencies na true, jak pokazano poniżej, oraz uruchomienie lint za pomocą ./gradlew :app:lint. Spowoduje to równoległą analizę wszystkich modułów zależności i utworzenie jednego raportu z problemami dotyczącymi aplikacji i wszystkich 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 uległy zmianie, zadanie analizy lint dla modułu nie musi być ponownie wykonywane. W takim przypadku wykonanie zadania jest oznaczone w wyjściu Gradle jako „UP-TO-DATE”. Dzięki tej zmianie podczas uruchamiania lint w module aplikacji z opcją checkDependencies = true analizowane będą tylko te moduły, które uległy zmianie. Dzięki temu Lint może działać jeszcze szybciej.

Nie musisz też uruchamiać zadania raportu Lint, jeśli jego dane wejściowe się nie zmieniły. Powiązanym znanym problemem jest to, że gdy zadanie lint jest AKTUALNE, nie ma żadnego tekstu lint wydrukowanego na stdout (problem #191897708).

Uruchamianie narzędzia lint w przypadku modułów funkcji dynamicznych

AGP nie obsługuje już uruchamiania linta z modułów dynamicznych funkcji. Uruchomienie lint w odpowiednim module aplikacji spowoduje przeprowadzenie lint w modułach funkcji dynamicznych i uwzględni wszystkie problemy w raporcie lint aplikacji. Powiązanym znanym problemem jest to, że podczas uruchamiania lintcheckDependencies = true w module aplikacji zależności dynamicznych bibliotek funkcji nie są sprawdzane, chyba że są też zależnościami aplikacji (problem #191977888).

Uruchamianie lint tylko w przypadku wariantu domyślnego

Uruchomienie ./gradlew :app:lint powoduje teraz uruchomienie narzędzia lint tylko w przypadku wariantu domyślnego. W poprzednich wersjach AGP narzędzie to uruchamiano dla wszystkich wariantów.

Brak ostrzeżeń o klasach w R8 shrinker

R8 dokładniej i konsekwentniej obsługuje brakujące klasy oraz opcję -dontwarn. Dlatego zacznij sprawdzać 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 jednym z jej zależności, wygeneruje ostrzeżenie, które pojawi się w wyjściu 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 zignorować to ostrzeżenie. Oto 2 najczęstsze powody, dla których możesz zignorować ostrzeżenie:

1. Biblioteki kierowane na JVM i brakujące klasy są typu JVM library (jak w powyższym przykładzie).

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

Możesz zignorować ostrzeżenie o brakujących zajęciach, 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 takiej jak app/build/outputs/mapping/release/missing_rules.txt. Dodaj reguły do pliku proguard-rules.pro, aby ignorować ostrzeżenia.

W AGP 7.0 wiadomości o brakujących klasach będą wyświetlane jako ostrzeżenia. Możesz je zmienić na błędy, ustawiając wartośćandroid.r8.failOnMissingClasses = true w parametryzugradle.properties. W wersji AGP 8.0 te ostrzeżenia staną się błędami, które uniemożliwią kompilację. Aby zachować zachowanie AGP 7.0, możesz dodać 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 wersji 4.1. W wersji AGP 2.3 dodano pamięć podręczną kompilacji AGP, aby uzupełnić pamięć podręczną kompilacji Gradle. W wersji AGP 4.1 została ona całkowicie zastąpiona pamięcią podręczną kompilacji Gradle. Ta zmiana nie ma wpływu na czas kompilacji.

W wersji AGP 7.0 usunięto usługę android.enableBuildCache, usługę android.buildCacheDir i zadanie cleanBuildCache.

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

W projekcie aplikacji możesz teraz skompilować kod źródłowy do wersji Java 11, co umożliwi Ci korzystanie z nowszych funkcji języka, takich jak prywatne metody interfejsu, operator diamentu w przypadku klas anonimowych i składnika zmiennej lokalnej w przypadku parametrów lambda.

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

Usunięcie konfiguracji zależności

W AGP 7.0 usunięto te konfiguracje (czyli zakresy zależności):

• compile
  W zależności od przypadku użycia zastąpiono ją wartością api lub implementation.
  Dotyczy to również wariantów *Compile, np. debugCompile.
• provided
  Został zastąpiony przez compileOnly.
  Dotyczy to również wariantów *Dostarczone, na przykład:releaseProvided.
• apk
  Został zastąpiony przez runtimeOnly.
• publish
  Został zastąpiony przez runtimeOnly.

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

Zmiana ścieżki klas podczas kompilowania w ramach wtyczki Gradle dla Androida

Jeśli kompilujesz kod z użyciem wtyczki Gradle dla Androida, ścieżka kompilacji może się zmienić. AGP używa teraz konfiguracji api/implementation wewnętrznie, więc niektóre artefakty mogą zostać usunięte z ścieżki kompilacji. classpath. Jeśli w czasie kompilacji zależysz od zależności AGP, dodaj ją jako jawną zależność.

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

Wcześniej można było dodać bibliotekę natywną w folderze zasobów Javy i zarejestrować ten folder za pomocą android.sourceSets.main.resources.srcDirs , aby biblioteka natywna została wyekstrahowana i dodana do ostatecznego pliku APK. Od wersji AGP 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 do bibliotek natywnych, android.sourceSets.main.jniLibs.srcDirs. Więcej informacji znajdziesz w artykule Konfigurowanie zbiorów źródeł.

Znane problemy

W tej sekcji opisano znane problemy występujące w pliku wtyczki 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 7.0.0 jest zgodna z Kotliną i wtyczką wieloplatformową w wersji 1.5.0 lub nowszej. Projekty korzystające z obsługi Kotlina na wielu platformach muszą zostać zaktualizowane do wersji 1.5.0, aby można było używać wtyczki Androida Gradle w wersji 7.0.0. Aby obejść ten problem, możesz obniżyć wersję wtyczki Gradle dla Androida do 4.2.x, chociaż nie jest to zalecane.

Więcej informacji znajdziesz w KT-43944.

Brak danych wyjściowych lint

Gdy zadanie lint jest aktualne, nie jest wyświetlany żaden tekst lint na wyjściu stdout (problem #191897708). Więcej informacji znajdziesz w artykule Zmiany w zachowaniu funkcji lint. Ten problem zostanie rozwiązany w wersji 7.1 wtyczki Androida do obsługi Gradle.

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

Podczas uruchamiania lint z checkDependencies = true w module ue aplikacji zależności bibliotek dynamicznych funkcji nie są sprawdzane, chyba że są też zależnościami aplikacji (problem #191977888). Aby obejść ten problem, można uruchomić zadanie lint dla tych bibliotek. Więcej informacji znajdziesz w artykule Zmiany w zachowaniu funkcji lint.