Плагин Android Gradle 7.0.0 (июль 2021 г.)

Плагин Android Gradle 7.0.0 – это крупный выпуск, который включает множество новых функций и улучшений.

Совместимость

Для запуска AGP 7.0 требуется JDK 11

Если вы используете плагин Android Gradle 7.0 для сборки приложения, то для запуска Gradle потребуется JDK 11. В 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 в устаревшем пакете SDK Tools не работают с JDK 11. Чтобы продолжить использовать SDK Manager и Менеджер AVD с AGP 7.0 и более поздними версиями, необходимо перейти на новые версии инструментов в текущем пакете инструментов командной строки Android SDK.

Стабильная версия Variant API

Новый Variant API теперь стабилен. Новые интерфейсы можно найти в пакете com.android.build.api.variant, а примеры – в проекте gradle-recipes на GitHub. В рамках нового Variant API мы сделали доступными ряд промежуточных файлов, называемых артефактами, через интерфейс Artifacts. Эти артефакты, например объединенный манифест, можно безопасно получать и настраивать с помощью сторонних плагинов и кода.

Мы продолжим расширять Variant API, добавляя новые функции и увеличивая количество промежуточных артефактов, доступных для настройки.

Изменения в поведении Lint

В этом разделе описываются изменения в поведении Lint в плагине Android Gradle версии 7.0.0.

Улучшенный инструмент Lint для зависимостей библиотек

Проверка кода с помощью checkDependencies = true теперь выполняется быстрее. В проектах для Android, состоящих из приложения с зависимостями библиотек, рекомендуется задать для checkDependencies значение true, как показано в примере ниже, и запустить инструмент анализа кода с помощью ./gradlew :app:lint. Это позволит параллельно проанализировать все модули зависимостей и создать единый отчет, включающий проблемы из приложения и всех его зависимостей.

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

// build.gradle.kts
android {
  ...
  lint {
    isCheckDependencies = true
  }
}

Задачи Lint теперь могут иметь статус UP-TO-DATE.

Если источники и ресурсы модуля не изменились, задачу анализа lint для модуля не нужно запускать снова. В этом случае в выходных данных Gradle для задачи будет указано UP-TO-DATE. Теперь при запуске lint в модуле приложения с помощью checkDependencies = true анализ будет выполняться только для измененных модулей. В результате Lint может работать ещё быстрее.

Задача отчета Lint также не должна выполняться, если ее входные данные не изменились. Связанная известная проблема заключается в том, что в stdout не выводится текст lint, когда задача lint имеет статус UP-TO-DATE (проблема 191897708).

Запуск lint в модулях динамических функций

AGP больше не поддерживает запуск lint из модулей динамических функций. Если запустить Lint из соответствующего модуля приложения, то будут проверены и модули динамических функций, а все проблемы будут включены в отчет Lint для приложения. Существует известная проблема: при запуске lint с checkDependencies = true из модуля приложения зависимости библиотеки динамических функций не проверяются, если они не являются зависимостями приложения (ошибка 191977888).

Проверка lint выполняется только для варианта по умолчанию.

Теперь при запуске ./gradlew :app:lint lint выполняется только для варианта по умолчанию. В предыдущих версиях AGP lint запускался для всех вариантов.

Предупреждения об отсутствующих классах в инструменте сжатия R8

R8 точнее и стабильнее обрабатывает отсутствующие классы и параметр -dontwarn. Поэтому вам следует начать оценивать предупреждения об отсутствующих классах, выдаваемые R8.

Если R8 обнаружит ссылку на класс, который не определен в приложении или одной из его зависимостей, то выдаст предупреждение, которое появится в выходных данных сборки. Пример:

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

Это предупреждение означает, что при анализе кода приложения не удалось найти определение класса java.lang.instrument.ClassFileTransformer. Обычно это означает, что произошла ошибка, но в некоторых случаях предупреждение можно проигнорировать. Вот две распространенные причины, по которым можно игнорировать предупреждение:

1. Библиотеки, предназначенные для JVM, и отсутствующий класс относятся к типу библиотек JVM (как в примере выше).

2. Одна из зависимостей использует 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 был удален в AGP 4.1. Кеш сборки AGP, который был представлен в AGP 2.3 в качестве дополнения к кешу сборки Gradle, был полностью заменен кешем сборки Gradle в AGP 4.1. Это изменение не влияет на время сборки.

В AGP 7.0 удалены свойство android.enableBuildCache, свойство android.buildCacheDir и задача cleanBuildCache.

Как использовать исходный код Java 11 в проекте

Теперь вы можете компилировать исходный код до Java 11 в проекте приложения, что позволяет использовать более новые функции языка, такие как методы частного интерфейса, оператор diamond для анонимных классов и синтаксис локальных переменных для параметров лямбда-выражений.

Чтобы включить эту функцию, задайте для 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 автоматически перенесет ваш проект в новые конфигурации.

Изменение пути к классам при компиляции с помощью плагина Android Gradle

Если вы компилируете код с помощью плагина Android Gradle, путь к классам компиляции может измениться. Поскольку плагин Android для Gradle теперь использует конфигурации api/implementation, некоторые артефакты могут быть удалены из пути к классам компиляции. Если вы используете зависимость AGP во время компиляции, обязательно добавьте ее как явную зависимость.

Добавление библиотек JNI в папку ресурсов Java не поддерживается.

Раньше вы могли добавить библиотеку JNI в папку ресурсов Java и зарегистрировать ее с помощью android.sourceSets.main.resources.srcDirs , чтобы библиотека JNI была извлечена и добавлена в конечный APK-файл. Начиная с AGP 7.0, это не поддерживается, и библиотеки JNI в папке ресурсов Java игнорируются. Вместо этого используйте метод DSL, предназначенный для библиотек JNI, – 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

Если задача lint актуальна, в stdout не выводится текст lint (проблема 191897708). Подробнее об изменениях в работе Lint… Эта проблема будет устранена в плагине Android Gradle версии 7.1.

Не все зависимости библиотеки динамических функций проверяются с помощью lint

При запуске lint с checkDependencies = true из модуля приложения зависимости библиотеки динамических функций не проверяются, если они не являются зависимостями приложения (проблема 191977888). В качестве обходного решения можно запустить задачу lint для этих библиотек. Подробнее об изменениях в работе Lint…