Настройка сборки

Система сборки Android компилирует ресурсы и исходный код приложения и упаковывает их в APK-файлы или наборы Android App Bundle, которые можно тестировать, развертывать, подписывать и распространять.

В статьях Обзор сборки Gradle и Структура сборки Android мы обсудили концепции сборки и структуру приложения Android. Теперь пришло время настроить сборку.

Глоссарий по сборкам Android

Gradle и плагин Android Gradle позволяют настраивать следующие аспекты сборки:

Типы сборки

Типы сборки определяют некоторые свойства, которые Gradle использует при сборке и упаковке приложения. Обычно типы сборки настраиваются для разных этапов жизненного цикла разработки.

Например, отладочная сборка позволяет использовать параметры отладки и подписывать приложение ключом отладки, а конечная сборка может сжимать и обфусцировать приложение, а также подписывать его ключом выпуска для распространения.

Чтобы создать приложение, необходимо определить хотя бы один тип сборки. По умолчанию Android Studio создает типы сборки debug и release. Чтобы начать настройку параметров упаковки для приложения, узнайте, как настроить типы сборки.

Версии продукта
Версии продукта – это разные версии приложения, которые вы можете выпускать для пользователей, например бесплатная и платная. Вы можете настроить версии продукта так, чтобы в них использовались разные коды и ресурсы, а также общие для всех версий приложения части. Версии продукта необязательны, и их нужно создавать вручную. Чтобы начать создавать разные версии приложения, узнайте, как настроить версии продукта.
Варианты сборки
Вариант сборки – это декартово произведение типа сборки и версии продукта, а также конфигурация, которую Gradle использует для сборки приложения. С помощью вариантов сборки вы можете создавать отладочные версии продуктов во время разработки и подписанные конечные версии для распространения. Хотя вы не настраиваете варианты сборки напрямую, вы настраиваете типы сборки и версии продукта, которые их формируют. При создании дополнительных типов сборки или версий продукта также создаются дополнительные варианты сборки. Подробнее о том, как создавать варианты сборки и управлять ими…
Записи манифеста
Вы можете указать значения для некоторых свойств файла манифеста в конфигурации варианта сборки. Эти значения переопределяют существующие значения в файле манифеста. Это удобно, если вы хотите создать несколько вариантов приложения с разными названиями, минимальными или целевыми версиями SDK. Если файлов манифеста несколько, инструмент объединения объединяет их настройки.
Зависимости
Система сборки управляет зависимостями проекта из локальной файловой системы и из удаленных репозиториев. Это означает, что вам не нужно вручную искать, скачивать и копировать двоичные пакеты зависимостей в каталог проекта. Подробнее о том, как добавить зависимости сборки…
Подписание
Система сборки позволяет указать настройки подписи в конфигурации сборки и может автоматически подписывать приложение в процессе сборки. Система сборки подписывает отладочную версию ключом и сертификатом по умолчанию, используя известные учетные данные, чтобы избежать запроса пароля во время сборки. Система сборки не подписывает конечную версию, если вы не задали конфигурацию подписи для этой сборки. Если у вас нет ключа выпуска, вы можете сгенерировать его, как описано в разделе Подписание приложения. Подписанные конечные сборки необходимы для распространения приложений через большинство магазинов приложений.
Удаление неиспользуемого кода и ресурсов
Система сборки позволяет указать отдельный файл правил ProGuard для каждого варианта сборки. При создании приложения система сборки применяет соответствующий набор правил, чтобы уменьшить размер кода и ресурсов с помощью встроенных инструментов, таких как R8. Чтобы уменьшить размер APK-файла или набора App Bundle, сократите код и ресурсы.
Поддержка нескольких APK-файлов
Система сборки позволяет автоматически создавать разные APK-файлы, каждый из которых содержит только код и ресурсы, необходимые для определенной плотности экрана или двоичного интерфейса приложений (ABI). Подробнее о том, как создать несколько APK-файлов… Однако мы рекомендуем выпускать один набор AAB, поскольку он позволяет разделять ресурсы не только по плотности пикселей и ABI, но и по языку. Кроме того, вам не придется загружать в Google Play несколько объектов. Все новые приложения, отправленные после августа 2021 года, должны использовать AAB.

Версии Java в сборках Android

Независимо от того, написан ли ваш исходный код на Java, Kotlin или на обоих языках, есть несколько мест, где вы должны выбрать версию JDK или языка Java для своей сборки. Подробную информацию можно найти в статье Версии Java в сборках Android.

Файлы конфигурации сборки

Чтобы создать собственную конфигурацию сборки, необходимо внести изменения в один или несколько файлов конфигурации сборки. В этих файлах обычного текста используется предметно-ориентированный язык (DSL) для описания логики сборки и управления ею с помощью скрипта Kotlin, который является вариантом языка Kotlin. Для настройки сборок также можно использовать Groovy – динамический язык для виртуальной машины Java (JVM).

Чтобы настроить сборку, не нужно знать Kotlin или Groovy, поскольку плагин Android Gradle содержит большинство необходимых элементов DSL. Подробные сведения о DSL плагина Android Gradle можно найти в справочной документации по DSL. Скрипт Kotlin также зависит от базового Gradle Kotlin DSL.

При создании нового проекта Android Studio автоматически создает некоторые из этих файлов и заполняет их значениями по умолчанию. Обзор созданных файлов приведен в разделе Структура сборки Android.

Файл Gradle Wrapper

Оболочка Gradle (gradlew) – это небольшое приложение, включенное в исходный код, которое скачивает и запускает Gradle. Это обеспечивает более стабильное выполнение сборки. Разработчики скачивают исходный код приложения и запускают gradlew. Будет скачан необходимый дистрибутив Gradle, а затем запустится сборка приложения.

Файл gradle/wrapper/gradle-wrapper.properties содержит свойство distributionUrl, которое описывает, какая версия Gradle используется для запуска сборки.

distributionBase=GRADLE_USER_HOME
distributionPath=wrapper/dists
distributionUrl=https\://services.gradle.org/distributions/gradle-8.0-bin.zip
zipStoreBase=GRADLE_USER_HOME
zipStorePath=wrapper/dists

Файл настроек Gradle

Файл settings.gradle.kts (для Kotlin DSL) или settings.gradle (для Groovy DSL) находится в корневом каталоге проекта. В этом файле определяются настройки хранилища на уровне проекта и указывается, какие модули Gradle должен включить при сборке приложения. В многомодульных проектах необходимо указать каждый модуль, который должен войти в окончательную сборку.

Для большинства проектов файл по умолчанию выглядит следующим образом:

Kotlin

pluginManagement {

    /**
      * The pluginManagement.repositories block configures the
      * repositories Gradle uses to search or download the Gradle plugins and
      * their transitive dependencies. Gradle pre-configures support for remote
      * repositories such as JCenter, Maven Central, and Ivy. You can also use
      * local repositories or define your own remote repositories. Here we
      * define the Gradle Plugin Portal, Google's Maven repository,
      * and the Maven Central Repository as the repositories Gradle should use to look for its
      * dependencies.
      */

    repositories {
        gradlePluginPortal()
        google()
        mavenCentral()
    }
}
dependencyResolutionManagement {

    /**
      * The dependencyResolutionManagement.repositories
      * block is where you configure the repositories and dependencies used by
      * all modules in your project, such as libraries that you are using to
      * create your application. However, you should configure module-specific
      * dependencies in each module-level build.gradle file. For new projects,
      * Android Studio includes Google's Maven repository and the Maven Central
      * Repository by default, but it does not configure any dependencies (unless
      * you select a template that requires some).
      */

  repositoriesMode.set(RepositoriesMode.FAIL_ON_PROJECT_REPOS)
  repositories {
      google()
      mavenCentral()
  }
}
rootProject.name = "My Application"
include(":app")

Яркий

pluginManagement {

    /**
      * The pluginManagement.repositories block configures the
      * repositories Gradle uses to search or download the Gradle plugins and
      * their transitive dependencies. Gradle pre-configures support for remote
      * repositories such as JCenter, Maven Central, and Ivy. You can also use
      * local repositories or define your own remote repositories. Here we
      * define the Gradle Plugin Portal, Google's Maven repository,
      * and the Maven Central Repository as the repositories Gradle should use to look for its
      * dependencies.
      */

    repositories {
        gradlePluginPortal()
        google()
        mavenCentral()
    }
}
dependencyResolutionManagement {

    /**
      * The dependencyResolutionManagement.repositories
      * block is where you configure the repositories and dependencies used by
      * all modules in your project, such as libraries that you are using to
      * create your application. However, you should configure module-specific
      * dependencies in each module-level build.gradle file. For new projects,
      * Android Studio includes Google's Maven repository and the Maven Central
      * Repository by default, but it does not configure any dependencies (unless
      * you select a template that requires some).
      */

    repositoriesMode.set(RepositoriesMode.FAIL_ON_PROJECT_REPOS)
    repositories {
        google()
        mavenCentral()
    }
}
rootProject.name = "My Application"
include ':app'

Файл сборки верхнего уровня

Файл build.gradle.kts (для Kotlin DSL) или build.gradle (для Groovy DSL) верхнего уровня находится в корневом каталоге проекта. Обычно в нем определяются общие версии плагинов, используемых модулями в проекте.

В следующем примере кода показаны настройки по умолчанию и элементы DSL в скрипте сборки верхнего уровня после создания нового проекта:

Kotlin

plugins {

    /**
     * Use `apply false` in the top-level build.gradle file to add a Gradle
     * plugin as a build dependency but not apply it to the current (root)
     * project. Don't use `apply false` in sub-projects. For more information,
     * see Applying external plugins with same version to subprojects.
     */

    id("com.android.application") version "9.4.0" apply false
    id("com.android.library") version "9.4.0" apply false
    id("org.jetbrains.kotlin.android") version "2.4.10" apply false
}

Яркий

plugins {

    /**
     * Use `apply false` in the top-level build.gradle file to add a Gradle
     * plugin as a build dependency but not apply it to the current (root)
     * project. Don't use `apply false` in sub-projects. For more information,
     * see Applying external plugins with same version to subprojects.
     */

    id 'com.android.application' version '9.4.0' apply false
    id 'com.android.library' version '9.4.0' apply false
    id 'org.jetbrains.kotlin.android' version '2.4.10' apply false
}