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 AGP 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 jego używania, co oznacza, że większość użytkowników Androida Studio nie musi wprowadzać żadnych zmian w konfiguracji projektów.

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

Jeśli używasz AGP niezależnie od Androida Studio, uaktualnij 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 SDK i Menedżer AVD w wycofanym pakiecie narzędzi SDK nie działają z JDK 11. Aby nadal korzystać z Menedżera SDK i Menedżera AVD w AGP 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 sprawdzanie zależności biblioteki

Sprawdzanie kodu za pomocą checkDependencies = true jest teraz szybsze niż wcześniej. W przypadku projektów na Androida składających się z aplikacji z zależnościami bibliotecznymi zalecamy ustawienie wartości checkDependencies na true, jak pokazano poniżej, i uruchomienie narzędzia lint za pomocą polecenia ./gradlew :app:lint. Spowoduje to równoległe przeanalizowanie 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 lint dla tego modułu nie musi być ponownie uruchamiane. W takim przypadku wykonanie zadania będzie w danych wyjściowych Gradle oznaczone jako „UP-TO-DATE”. Po wprowadzeniu tej zmiany podczas uruchamiania narzędzia lint w module aplikacji z checkDependencies = true analizę będą musiały przeprowadzić tylko zmienione moduły. 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 lint jest aktualne, nie ma danych wyjściowych tekstu lint drukowanych na standardowym wyjściu (problem nr 191897708).

Uruchamianie narzędzia lint w modułach funkcji dynamicznych

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

Uruchamianie narzędzia lint tylko w przypadku domyślnego wariantu

Polecenie ./gradlew :app:lint uruchamia teraz lint tylko dla wariantu domyślnego. W poprzednich wersjach AGP narzędzie lint było uruchamiane 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, które pojawi się 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 dostępnego 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ę, AGP 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.

W AGP 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. W AGP 8.0 te ostrzeżenia staną się błędami, które spowodują przerwanie kompilacji. Możesz zachować działanie 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. Wprowadzona wcześniej w AGP 2.3 jako uzupełnienie pamięci podręcznej kompilacji Gradle, pamięć podręczna kompilacji AGP została całkowicie zastąpiona przez pamięć podręczną kompilacji Gradle w AGP 4.1. Ta zmiana nie ma wpływu na czas kompilacji.

W AGP 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 ustaw 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

W AGP 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 to zastąpione przez compileOnly.
  Dotyczy to również wariantów *Provided, np.: releaseProvided
• apk
  Zostało to zastąpione przez runtimeOnly.
• publish
  Zostało to zastąpione przez runtimeOnly.

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

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

Jeśli kompilujesz za pomocą wtyczki Androida do Gradle, ścieżka kompilacji może się zmienić. Ponieważ AGP 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 AGP, 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 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 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, które korzystają z obsługi 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 KT-43944.

Brak danych wyjściowych narzędzia lint

Gdy zadanie lint jest aktualne, na standardowe wyjście nie jest drukowany żaden tekst (problem nr 191897708). Więcej informacji znajdziesz w artykule Zmiany w działaniu narzędzia lint. Ten problem zostanie rozwiązany w wtyczce Androida do obsługi Gradle w wersji 7.1.

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

Podczas uruchamiania narzędzia lint z parametrem checkDependencies = true w module aplikacji zależności bibliotek funkcji dynamicznych nie są sprawdzane, chyba że są też zależnościami aplikacji (problem 191977888). Możesz jednak uruchomić zadanie lint w przypadku tych bibliotek. Więcej informacji znajdziesz w artykule Zmiany w działaniu narzędzia lint.