Эта страница переведена с помощью Cloud Translation API.

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

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

7.0.1 (август 2021 г.)

Это незначительное обновление включает в себя различные исправления ошибок. Чтобы просмотреть список заметных исправлений ошибок, прочитайте соответствующую публикацию в блоге Release Updates .

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

	Минимальная версия	Версия по умолчанию	Примечания
Градл	7.0.2	7.0.2	Чтобы узнать больше, см. обновление Gradle .
Инструменты сборки SDK	30.0.2	30.0.2	Установите или настройте инструменты сборки SDK.
НДК	Н/Д	21.4.7075529	Установите или настройте другую версию NDK.
ЯДК	11	11	Дополнительные сведения см. в разделе Настройка версии JDK .

JDK 11 необходим для запуска AGP 7.0.

При использовании плагина 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 .

Стабильный вариант API

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

Мы продолжим расширять Variant 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
  }
}

Задачи Lint теперь могут быть АКТУАЛЬНЫМИ

Если источники и ресурсы модуля не изменились, задачу анализа ворса для модуля не нужно запускать повторно. Когда это происходит, выполнение задачи отображается как «АКТУАЛЬНОЕ» в выходных данных Gradle. Благодаря этому изменению при запуске lint в модуле приложения с checkDependencies = true анализ нужно будет выполнять только изменившимся модулям. В результате Lint может работать еще быстрее.

Задачу отчета Lint также не нужно запускать, если ее входные данные не изменились. Связанная с этим известная проблема заключается в том, что текстовый вывод lint не выводится на стандартный вывод, когда задача lint ОБНОВЛЕНА ( проблема № 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 не удалось найти при анализе кода вашего приложения. Хотя обычно это означает, что произошла ошибка, возможно, вы захотите проигнорировать это предупреждение. Две распространенные причины игнорировать предупреждение:

Библиотеки, ориентированные на 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 был удален в AGP 4.1. Ранее представленный в 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 автоматически перенесет ваш проект в новые конфигурации.

Изменение пути к классам при компиляции с плагином 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 не выводится на стандартный вывод, если задача lint обновлена ( проблема № 191897708 ). Дополнительную информацию см. в разделе Изменения поведения для lint . Эта проблема будет исправлена в плагине Android Gradle 7.1.

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

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