Android Gradle Plugin 7.0.0 (июль 2021 г.)
Android Gradle plugin 7.0.0 — это крупный релиз, включающий множество новых функций и улучшений.
7.0.1 (август 2021 г.)
Это небольшое обновление включает в себя исправление различных ошибок. Чтобы ознакомиться со списком наиболее важных исправлений, прочитайте соответствующую статью в блоге «Обновления релизов» .
Совместимость
| Минимальная версия | Версия по умолчанию | Примечания | |
|---|---|---|---|
| Грэдл | 7.0.2 | 7.0.2 | Для получения более подробной информации см. раздел «Обновление Gradle» . |
| Инструменты сборки SDK | 30.0.2 | 30.0.2 | Установите или настройте инструменты сборки SDK. |
| НДК | Н/Д | 21.4.7075529 | Установите или настройте другую версию NDK. |
| JDK | 11 | 11 | Для получения более подробной информации см. раздел «Настройка версии JDK» . |
Для работы AGP 7.0 требуется JDK 11.
При использовании плагина Android Gradle 7.0 для сборки приложения теперь требуется JDK 11 для запуска Gradle. Android Studio Arctic Fox включает JDK 11 и настраивает Gradle на его использование по умолчанию, что означает, что большинству пользователей Android Studio не нужно вносить никаких изменений в конфигурацию своих проектов.
Если вам необходимо вручную установить версию JDK, используемую AGP, в Android Studio, вам потребуется использовать JDK 11 или выше.
При использовании AGP вне Android Studio обновите версию JDK, установив переменную среды JAVA_HOME или параметр командной строки -Dorg.gradle.java.home на каталог установки JDK 11.
Обратите внимание, что SDK Manager и AVD Manager из устаревшего пакета SDK Tools не работают с JDK 11. Чтобы продолжить использовать SDK Manager и AVD Manager с AGP 7.0 и выше, необходимо перейти на новые версии инструментов из текущего пакета Android SDK Command-Line Tools .
Вариант API стабилен
Новый API для работы с вариантами теперь стабилен. Ознакомьтесь с новыми интерфейсами в пакете com.android.build.api.variant и примерами в проекте gradle-recipes на GitHub. В рамках нового API для работы с вариантами мы предоставили ряд промежуточных файлов, называемых артефактами, через интерфейс Artifacts . Эти артефакты, как и объединенный манифест, можно безопасно получить и настроить с помощью сторонних плагинов и кода.
Мы продолжим расширять API вариантов, добавляя новые функции и увеличивая количество промежуточных артефактов, доступных для настройки.
Изменения в поведении Lint
В этом разделе описаны многочисленные изменения в поведении Lint в плагине Android Gradle версии 7.0.0.
Улучшена проверка зависимостей библиотек с помощью линтера.
Теперь запуск lint с checkDependencies = true стал быстрее, чем раньше. Для Android-проектов, состоящих из приложения с библиотечными зависимостями, рекомендуется установить checkDependencies в true , как показано ниже, и запускать lint через ./gradlew :app:lint , который проанализирует все модули зависимостей параллельно и создаст единый отчет, включающий проблемы из приложения и всех его зависимостей.
Классный
// build.gradle
android {
...
lintOptions {
checkDependencies true
}
}Котлин
// build.gradle.kts
android {
...
lint {
isCheckDependencies = true
}
}Теперь задачи проверки синтаксиса могут быть актуальными.
Если исходные файлы и ресурсы модуля не изменились, задача анализа кода для этого модуля не требует повторного запуска. В этом случае выполнение задачи отображается как "UP-TO-DATE" в выводе Gradle. Благодаря этому изменению, при запуске анализа кода для модуля приложения с checkDependencies = true , анализ потребуется только для тех модулей, которые изменились. В результате Lint может работать еще быстрее.
Задача проверки кода также не требует запуска, если ее входные данные не изменились. Известная проблема, связанная с этим, заключается в том, что текст проверки кода не выводится в стандартный поток вывода, когда задача проверки кода находится в состоянии UP-TO-DATE ( проблема #191897708 ).
Проверка синтаксиса динамических модулей
AGP больше не поддерживает запуск проверки кода из динамических модулей. Запуск проверки кода из соответствующего модуля приложения будет проверять его динамические модули и включать все ошибки в отчет проверки кода приложения. Известная проблема заключается в том, что при запуске проверки кода с checkDependencies = true из модуля приложения зависимости динамических библиотек не проверяются, если они не являются зависимостями самого приложения ( проблема #191977888 ).
Проверка синтаксиса выполняется только для варианта по умолчанию.
Теперь команда ./gradlew :app:lint проверяет только вариант по умолчанию. В предыдущих версиях AGP проверка выполнялась для всех вариантов.
Отсутствуют предупреждения о классах в R8 shrinker
В R8 обработка отсутствующих классов и опции -dontwarn осуществляется более точно и последовательно. Поэтому следует начать оценивать предупреждения об отсутствующих классах, выдаваемые R8.
Когда R8 обнаруживает ссылку на класс, который не определен в вашем приложении или одной из его зависимостей, он выдает предупреждение, которое отображается в выводе сборки. Например:
R8: Missing class: java.lang.instrument.ClassFileTransformer Это предупреждение означает, что определение класса java.lang.instrument.ClassFileTransformer не было найдено при анализе кода вашего приложения. Хотя это обычно означает ошибку, возможно, вы захотите проигнорировать это предупреждение. Две распространенные причины игнорировать предупреждение:
Библиотеки, ориентированные на JVM, и отсутствующий класс относятся к типу библиотек JVM (как в приведенном выше примере).
Одна из ваших зависимостей использует API, доступный только на этапе компиляции.
Вы можете игнорировать предупреждение об отсутствии класса, добавив правило -dontwarn в файл proguard-rules.pro . Например:
-dontwarn java.lang.instrument.ClassFileTransformer Для удобства AGP сгенерирует файл, содержащий все потенциально отсутствующие правила, и запишет их в файл по следующему пути: app/build/outputs/mapping/release/missing_rules.txt . Добавьте эти правила в файл proguard-rules.pro , чтобы игнорировать предупреждения.
В AGP 7.0 сообщения об отсутствии классов будут отображаться как предупреждения, и вы можете преобразовать их в ошибки, установив параметр android.r8.failOnMissingClasses = true в файле gradle.properties . В AGP 8.0 эти предупреждения превратятся в ошибки, которые нарушат сборку. Можно сохранить поведение AGP 7.0, добавив параметр -ignorewarnings в файл proguard-rules.pro , но это не рекомендуется.
Кэш сборки плагина Android Gradle удален
В AGP 4.1 кэш сборки AGP был удален. Ранее введенный в AGP 2.3 в дополнение к кэшу сборки Gradle, кэш сборки AGP был полностью заменен кэшем сборки Gradle в AGP 4.1. Это изменение не влияет на время сборки.
В AGP 7.0 были удалены свойства android.enableBuildCache , android.buildCacheDir и задача cleanBuildCache .
Используйте исходный код Java 11 в своем проекте.
Теперь вы можете компилировать исходный код Java 11 в проекте своего приложения, что позволяет использовать новые языковые возможности, такие как приватные методы интерфейса, оператор "ромб" для анонимных классов и синтаксис локальных переменных для параметров лямбда-выражений.
Чтобы включить эту функцию, установите compileOptions на желаемую версию Java и параметр compileSdkVersion на значение 30 или выше:
// 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"
}
}Конфигурации зависимостей удалены.
В AGP 7.0 были удалены следующие конфигурации (или области зависимостей):
-
compile
В зависимости от сценария использования, это было заменено либоapi, либоimplementation.
Это также относится к вариантам *Compile , например:debugCompile. -
provided
Этот параметр был заменен наcompileOnly.
Это также относится к вариантам *Provided , например:releaseProvided. -
apk
Этот параметр заменен наruntimeOnly. -
publish
Этот параметр заменен наruntimeOnly.
В большинстве случаев AGP Upgrade Assistant автоматически перенесет ваш проект на новые конфигурации.
Изменение пути к классам при компиляции с использованием плагина Android Gradle
Если вы компилируете с использованием плагина Android Gradle, ваш путь к классам для компиляции может измениться. Поскольку AGP теперь использует внутренние конфигурации api/implementation , некоторые артефакты могут быть удалены из вашего пути к классам для компиляции. Если вы зависите от зависимости AGP во время компиляции, обязательно добавьте её в качестве явной зависимости.
Добавление нативных библиотек в папку ресурсов Java не поддерживается.
Ранее можно было добавить нативную библиотеку в папку ресурсов Java и зарегистрировать эту папку с помощью android.sourceSets.main.resources.srcDirs , чтобы нативная библиотека была извлечена и добавлена в итоговый APK-файл. Начиная с AGP 7.0, это больше не поддерживается, и нативные библиотеки в папке ресурсов Java игнорируются. Вместо этого используйте метод DSL, предназначенный для нативных библиотек, android.sourceSets.main.jniLibs.srcDirs . Для получения дополнительной информации см. раздел «Настройка наборов источников» .
Известные проблемы
В этом разделе описаны известные проблемы, существующие в плагине Android Gradle версии 7.0.0.
Несовместимость с плагином Kotlin Multiplatform версии 1.4.x.
Плагин Android Gradle 7.0.0 совместим с плагином Kotlin Multiplatform 1.5.0 и выше. Проектам, использующим поддержку Kotlin Multiplatform, необходимо обновить Kotlin до версии 1.5.0, чтобы использовать плагин Android Gradle 7.0.0. В качестве обходного пути можно понизить версию плагина Android Gradle до 4.2.x, хотя это не рекомендуется.
Для получения более подробной информации см. KT-43944 .
Отсутствует вывод команды lint.
Когда задача проверки кода обновлена, текст проверки кода не выводится в стандартный поток вывода ( проблема #191897708 ). Для получения дополнительной информации см. раздел «Изменения в поведении проверки кода» . Эта проблема будет исправлена в плагине Android Gradle версии 7.1.
Не все зависимости библиотек с динамическими функциями проходят проверку синтаксиса.
При запуске lint с checkDependencies = true из модуля приложения зависимости динамических библиотек не проверяются, если они не являются зависимостями самого приложения ( проблема #191977888 ). В качестве обходного пути задачу lint можно запустить для этих библиотек. Для получения дополнительной информации см. раздел «Изменения в поведении lint» .