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 wiele nowych funkcje i ulepszenia.

Zgodność

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, JDK 11 jest teraz wymagane do uruchomienia Gradle. Android Studio Arctic Fox zawiera pakiety JDK 11 i konfiguruje Gradle tak, aby używała go domyślnie, co oznacza, że większość narzędzi Android Studio użytkownicy nie muszą wprowadzać żadnych zmian w konfiguracji swoich projektów.

Jeśli musisz ręcznie ustawić wersji JDK używanej przez pakiet AGP w Android Studio, użyj pakietu JDK 11. lub wyższą.

Jeśli używasz AGP niezależnego od Android Studio, uaktualnij JDK do ustawianie zmiennej środowiskowej JAVA_HOME, lub -Dorg.gradle.java.home opcji wiersza poleceń do katalogu instalacyjnego JDK 11.

Pamiętaj, że SDK Manager i AVD Manager w wycofanym pakiecie SDK Tools nie działają w przypadku pakietu JDK 11. Aby nadal korzystać z SDK Manager i AVD Manager jeśli korzystasz ze standardu AGP 7.0 lub nowszego, musisz przełączyć się na nowe wersje narzędzi bieżącego Narzędzia wiersza poleceń pakietu Android SDK .

Wersja stabilna interfejsu API

Nowy interfejs API wariantu jest teraz stabilny. Poznaj nowe interfejsy w com.android.build.api.variant oraz przykłady w projektu GitHub gradle-recipes. W ramach nowej API wariantu, udostępniliśmy kilka plików pośrednich o nazwie artefaktów, w ramach Artefakty za pomocą prostego interfejsu online. Te artefakty, np. scalony plik manifestu, można bezpiecznie uzyskać i dostosowywać go za pomocą wtyczek i kodów innych firm.

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

Zmiany w działaniu Lint

W tej sekcji opisano wiele zmian w działaniu Lint w systemie Android Gradle wtyczka 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, które obejmują aplikację z biblioteką zależności, zalecamy ustawienie atrybutu checkDependencies na true, jak pokazano poniżej, i uruchomić lint za pomocą ./gradlew :app:lint, która przeanalizuje wszystkie zależności modułów równolegle i wygenerować jeden raport zawierający problemy z i wszystkich zależnościach od niej.

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

// 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, analiza lintowania dla modułu nie trzeba uruchamiać ponownie. W takim przypadku tag wykonanie zadania ma stan „UP-TO-DATE” w Gradle dane wyjściowe. Dzięki tej zmianie podczas uruchamiania lint w module aplikacji z funkcją checkDependencies = true tylko zmodyfikowane moduły przeprowadzić analizę. Dzięki temu platforma Lint działa jeszcze szybciej.

Zadanie raportu Lint nie musi być uruchamiane, jeśli jego dane wejściowe nie została zmieniona. Powiązany znany problem to brak lintowania dane wyjściowe tekstowe są drukowane jako standardowe, gdy zadanie lint jest ustawione na czas UP-TO-DATE (numer problemu 191897708).

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 modułów funkcji dynamicznych i uwzględnić wszystkie problemy w lincie aplikacji. raport. Powiązany znany problem polega na tym, że podczas uruchamiania lintowania z checkDependencies = true w module aplikacji, zależności biblioteki funkcji dynamicznych nie są sprawdzane, chyba że dotyczą aplikacji. zależności (problem #191977888).

Linter uruchomiony tylko w wariancie domyślnym

Uruchomienie polecenia ./gradlew :app:lint pozwala teraz uruchamiać lint tylko dla wariant domyślny. W poprzednich wersjach interfejsu AGP wykonywał on lint na wszystkich wersji.

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

R8. stale obsługuje brakujące klasy oraz opcję -dontwarn. Dlatego należy zacząć oceniać wysyłane ostrzeżenia o brakujących klasach R8.

Gdy R8 napotyka odwołanie do klasy, które nie jest zdefiniowane w aplikacji lub jedną z jego zależności, wyświetli ostrzeżenie w kompilacji dane wyjściowe. Na przykład:

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

To ostrzeżenie oznacza, że definicja klasy Nie można znaleźć adresu java.lang.instrument.ClassFileTransformer przy analizowaniu kodu aplikacji. Zwykle oznacza to błąd, możesz zignorować to ostrzeżenie. Dwie najczęstsze przyczyny do zignorowania ostrzeżenia:

1. Biblioteki kierowane na JVM i brakującą klasę są zapisane w 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 zajęciach, dodając -dontwarn do pliku proguard-rules.pro. Na przykład:

-dontwarn java.lang.instrument.ClassFileTransformer

Dla wygody AGP generuje plik zawierający potencjalnie wszystkie reguł, zapisując je w ścieżce pliku, na przykład: app/build/outputs/mapping/release/missing_rules.txt Dodaj parametr reguły ignorowania ostrzeżeń.proguard-rules.pro

W AGP 7.0 brakujące wiadomości dotyczące zajęć są wyświetlane jako ostrzeżenia. Możesz zmienić je w błędy, ustawiając android.r8.failOnMissingClasses = true in gradle.properties W AGP 8.0 te ostrzeżenia będą: które zakłócają kompilację. Działanie AGP 7.0 można zachować przez: dodaję opcję -ignorewarnings do 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. Poprzednio wprowadzone w AGP Aby uzupełnić pamięć podręczną kompilacji Gradle, pamięć podręczna kompilacji AGP została zastąpiona wyłącznie z pamięci podręcznej kompilacji Gradle w AGP 4.1. Ta zmiana nie ma wpływu czas kompilacji.

W pakiecie AGP 7.0 za pomocą właściwości android.enableBuildCache właściwości android.buildCacheDir oraz Usunięto cleanBuildCache zadanie.

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

Możesz teraz skompilować w projekcie swojej aplikacji kod źródłowy Java 11 do wersji 11, korzystać z nowszych funkcji językowych, takich jak prywatne metody interfejsu, na potrzeby klas anonimowych i składni zmiennych lokalnych dla parametrów lambda.

Aby włączyć tę funkcję, ustaw compileOptions na żądaną wersji Javy i ustaw compileSdkVersion na 30 lub nowszą:

// 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 zostały wprowadzone następujące konfiguracje (lub zakresy zależności) usunięto:

• compile
  W zależności od przypadku użycia zastąpiliśmy ją tekstem api. lub implementation.
  Dotyczy to też wariantów typu *Kompiluj, np. debugCompile.
• provided
  Zastąpiła ich treść: compileOnly.
  Dotyczy to też wersji *dostarczonych, na przykład: releaseProvided
• apk
  Zastąpiła ich treść: runtimeOnly.
• publish
  Zastąpiła ich treść: runtimeOnly.

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

Zmiana klasy Classpath podczas kompilowania danych na Androidzie Wtyczka Gradle

Jeśli kompilujesz dane za pomocą wtyczki Androida do obsługi Gradle, ścieżka klasy może się zmienić. Ponieważ AGP używa teraz api/implementation wewnętrznych konfiguracji, niektóre artefakty mogą zostać usunięte z kompilacji classpath. Jeśli podczas kompilowania polegasz na zależności AGP, dodaj ją jako zależność jawną.

Dodanie bibliotek natywnych do zasobów Javy folder nie jest obsługiwany

Wcześniej można było dodać bibliotekę natywną w folderze zasobów Java. zarejestruj folder za pomocą funkcji android.sourceSets.main.resources.srcDirs , aby wyodrębnić bibliotekę natywną i dodać ją do ostatecznej plik APK. Nie jest ono obsługiwane od wersji AGP 7.0, a biblioteki natywne Folder zasobów Java jest ignorowany. Zamiast tego użyj metody DSL przeznaczonej do biblioteki natywne, android.sourceSets.main.jniLibs.srcDirs. Dla: więcej informacji znajdziesz w jak skonfigurować .

Znane problemy

W tej sekcji opisano znane problemy występujące we wtyczce Androida do obsługi Gradle 7.0.0

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

Wtyczka Androida do obsługi Gradle w wersji 7.0.0 jest zgodna z Kotlin Wtyczka wieloplatformowa w wersji 1.5.0 lub nowszej. Projekty wykorzystujące Kotlin Aby używać Gradle Androida, należy zaktualizować obsługę wieloplatformową do wersji Kotlin 1.5.0 Wtyczka 7.0.0 Aby obejść ten problem, możesz zmienić wersję wtyczki Androida do obsługi Gradle na starszą do wersji 4.2.x, ale nie jest to zalecane.

Więcej informacji: KT-43944,

Brak danych wyjściowych lint

Gdy zadanie lint jest aktualne (numer problemu 191897708). Więcej informacji znajdziesz tutaj: Zmiany działania linta. Ten numer zostanie poprawiony we wtyczce Androida do obsługi Gradle w wersji 7.1.

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

Podczas uruchamiania lintowania za pomocą narzędzia checkDependencies = true ze modułu aplikacji, zależności biblioteki funkcji dynamicznych nie są sprawdzane, to również zależności aplikacji (numer problemu 191977888). Aby obejść ten problem, w tych bibliotekach można uruchomić zadanie lintowania. Aby uzyskać więcej informacji, Więcej informacji: Zmiany w działaniu linta.