Плагин Android Gradle 4.2.0 (март 2021 г.)

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

Новые функции

В этой версии плагина Android Gradle доступны следующие новые функции.

Java 8 по умолчанию

Начиная с версии 4.2, AGP по умолчанию будет использовать уровень языка Java 8. Java 8 предоставляет доступ к ряду новых функций языка, включая лямбда-выражения, ссылки на методы и статические методы интерфейса. Полный список поддерживаемых функций приведен в документации по Java 8.

Чтобы сохранить старое поведение, явно укажите Java 7 в файле build.gradle.kts или build.gradle на уровне модуля:

// build.gradle
android {
  ...
  compileOptions {
    sourceCompatibility JavaVersion.VERSION_1_7
    targetCompatibility JavaVersion.VERSION_1_7
  }
  // For Kotlin projects, compile to Java 6 instead of 7
  kotlinOptions {
    jvmTarget = "1.6"
  }
}

// build.gradle.kts
android {
  ...
  compileOptions {
    sourceCompatibility = JavaVersion.VERSION_1_7
    targetCompatibility = JavaVersion.VERSION_1_7
  }
  // For Kotlin projects, compile to Java 6 instead of 7
  kotlinOptions {
    jvmTarget = "1.6"
  }
}

Новый компилятор ресурсов JVM

Новый компилятор ресурсов JVM в плагине Android Gradle 4.2 заменяет некоторые части компилятора ресурсов AAPT2, что может повысить производительность сборки, особенно на компьютерах с Windows. Новый компилятор ресурсов JVM включен по умолчанию.

Теперь поддерживаются подписи версий 3 и 4

Плагин Android Gradle 4.2 теперь поддерживает форматы подписи APK v3 и APK v4. Чтобы включить один или оба формата в сборку, добавьте в файл build.gradle или build.gradle.kts на уровне модуля следующие свойства:

// build.gradle
android {
  ...
  signingConfigs {
    config {
        ...
        enableV3Signing true
        enableV4Signing true
    }
  }
}

// build.gradle.kts
android {
  ...
  signingConfigs {
      config {
          ...
          enableV3Signing = true
          enableV4Signing = true
      }
  }
}

Схема подписания APK версии 4 позволяет быстро развертывать большие APK-файлы с помощью пошаговой установки APK через ADB в Android 11. Этот новый флаг отвечает за подписание APK-файла в процессе развертывания.

Как настроить подписи приложений для каждого варианта

Теперь в плагине Android Gradle можно включать и отключать подписание приложений для каждого варианта.

В примере ниже показано, как настроить подпись приложения для каждого варианта с помощью метода onVariants() в Kotlin или Groovy.

androidComponents {
    onVariants(selector().withName("fooDebug")) {
        signingConfig {
            enableV1Signing false
            enableV2Signing true
        }
    }
}

Новое свойство Gradle: android.native.buildOutput

Чтобы уменьшить количество лишней информации в выходных данных сборки, AGP 4.2 фильтрует сообщения из сборок C/C++, использующих CMake и ndk-build, по умолчанию отображая только выходные данные компилятора C/C++. Раньше для каждого созданного файла генерировалась строка вывода, что приводило к большому количеству информационных сообщений.

Если вы хотите увидеть все выходные данные C/C++, задайте для нового свойства Gradle android.native.buildOutput значение verbose.

Это свойство можно задать в файле gradle.properties или в командной строке.

gradle.properties
android.native.buildOutput=verbose

Командная строка
-Pandroid.native.buildOutput=verbose

Значение по умолчанию – quiet.

Изменение поведения файлов gradle.properties

Начиная с AGP 4.2, больше нельзя переопределять свойства Gradle из подпроектов. Другими словами, если вы объявите свойство в файле gradle.properties в подпроекте, а не в корневом проекте, оно будет проигнорировано.

Например, в предыдущих выпусках AGP считывал значения из <var>projectDir</var>/gradle.properties, <var>projectDir</var>/app/gradle.properties, <var>projectDir</var>/library/gradle.properties и т. д. Если в модулях приложения одно и то же свойство Gradle присутствовало и в <var>projectDir</var>/gradle.properties, и в <var>projectDir</var>/app/gradle.properties, то приоритет отдавался значению из <var>projectDir</var>/app/gradle.properties.

В AGP 4.2 это поведение было изменено, и AGP не будет загружать значения из gradle.properties в подпроектах (например, <var>projectDir</var>/app/gradle.properties). Это изменение отражает новое поведение Gradle и поддерживает кеширование конфигурации.

Подробные сведения о том, как задавать значения в файлах gradle.properties, можно найти в документации по Gradle.

Изменения совместимости и конфигурации Gradle

При запуске в Android Studio инструмент сборки Gradle использует встроенный JDK. В предыдущих выпусках JDK 8 поставлялся в комплекте со Studio. Однако в версии 4.2 вместо него используется JDK 11. Если вы используете новый пакет JDK для запуска Gradle, это может привести к несовместимости или повлиять на производительность JVM из-за изменений в сборщике мусора. Эти проблемы описаны ниже.

Совместимость Android Studio с плагином Android Gradle (AGP)

В Android Studio 4.2 можно открывать проекты, в которых используется AGP 3.1 и более поздних версий, если AGP работает с Gradle 4.8.1 и более поздних версий. Подробнее о совместимости Gradle…

Оптимизация сборок Gradle для JDK 11

Обновление до JDK 11 влияет на конфигурацию по умолчанию сборщика мусора JVM, поскольку в JDK 8 используется параллельный сборщик мусора, а в JDK 11 – сборщик мусора G1.

Чтобы повысить производительность сборки, рекомендуем протестировать сборки Gradle с параллельным сборщиком мусора. В gradle.properties задайте следующие настройки:

org.gradle.jvmargs=-XX:+UseParallelGC

Если в этом поле уже есть другие варианты, добавьте новый:

org.gradle.jvmargs=-Xmx1536m -XX:+UseParallelGC

Чтобы измерить скорость сборки с разными конфигурациями, ознакомьтесь с разделом Профилирование сборки.

DEX-файлы не сжаты в APK, если minSdk равно 28 или выше.

Теперь AGP по умолчанию упаковывает DEX-файлы в APK без сжатия, если minSdk = 28 или выше. Это увеличивает размер APK, но уменьшает размер установки на устройстве, а размер скачивания остается примерно таким же.

Чтобы принудительно упаковать DEX-файлы в сжатом виде, добавьте в файл build.gradle следующий код:

android {
    packagingOptions {
        dex {
            useLegacyPackaging true
        }
    }
}

Как использовать DSL для упаковки сжатых библиотек C/C++

Мы рекомендуем упаковывать библиотеки C/C++ в несжатом виде, поскольку это уменьшает размер приложения при установке и скачивании, а также ускоряет его загрузку. Однако если вы хотите, чтобы плагин Android Gradle упаковывал сжатые библиотеки C/C++ при сборке приложения, установите для useLegacyPackaging значение true в файле build.gradle приложения:

android {
    packagingOptions {
        jniLibs {
            useLegacyPackaging true
        }
    }
}

Флаг useLegacyPackaging заменяет атрибут манифеста extractNativeLibs. Дополнительную информацию можно найти в примечаниях к выпуску Нативные библиотеки по умолчанию упаковываются без сжатия.