Плагин 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.

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

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

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

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

Задачи Lint теперь могут быть актуальными

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

Задача создания отчета Lint также не должна выполняться, если ее входные данные не изменились. Ещё одна известная проблема заключается в том, что при выполнении задачи lint в stdout не выводится текстовый результат, если задача уже выполнена (проблема № 191897708).

Как выполнять проверку кода в модулях динамических функций

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

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

При запуске ./gradlew :app: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. В AGP 4.1 кеш сборки AGP был полностью заменен кешем сборки Gradle. Это изменение не повлияет на время сборки.

В 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.
  Также относится к вариантам, предоставленным продавцом, например: releaseProvided.
• apk
  Этот параметр заменен на runtimeOnly.
• publish
  Этот параметр заменен на runtimeOnly.

В большинстве случаев помощник по обновлению AGP автоматически переносит проект в новую конфигурацию.

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

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

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

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