Настройте свою сборку

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

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

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

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

Типы сборки

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

Например, тип сборки «Отладка» включает параметры отладки и подписывает приложение ключом отладки, в то время как тип сборки «Выпуск» может сжимать, скрывать и подписывать ваше приложение ключом выпуска для распространения.

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

Вкусы продукта
Варианты продукта представляют собой различные версии вашего приложения, которые вы можете предоставить пользователям, например, бесплатные и платные. Вы можете настроить варианты продукта, используя разный код и ресурсы, а также совместно использовать компоненты, общие для всех версий вашего приложения. Варианты продукта необязательны, и их необходимо создавать вручную. Чтобы начать создавать различные версии приложения, узнайте, как настроить варианты продукта .
Варианты сборки
Вариант сборки — это кросс-продукт типа сборки и варианта продукта, представляющий собой конфигурацию, которую Gradle использует для сборки вашего приложения. Используя варианты сборки, вы можете собирать отладочные версии вариантов продукта во время разработки, а также подписанные релизные версии для распространения. Хотя варианты сборки не настраиваются напрямую, вы настраиваете типы сборки и варианты продукта, которые их формируют. Создание дополнительных типов сборки или вариантов продукта также создает дополнительные варианты сборки. Чтобы узнать, как создавать и управлять вариантами сборки, ознакомьтесь с обзором «Настройка вариантов сборки» .
Записи манифеста
Вы можете указать значения некоторых свойств файла манифеста в конфигурации варианта сборки. Эти значения переопределяют существующие значения в файле манифеста. Это полезно, если вы хотите создать несколько вариантов приложения с разными названиями, минимальной или целевой версией SDK. При наличии нескольких манифестов инструмент слияния манифестов объединяет настройки манифеста .
Зависимости
Система сборки управляет зависимостями проекта из локальной файловой системы и из удалённых репозиториев. Это означает, что вам не придётся вручную искать, загружать и копировать двоичные пакеты зависимостей в каталог проекта. Подробнее см. в разделе Добавление зависимостей сборки .
Подписание
Система сборки позволяет указать параметры подписи в конфигурации сборки и может автоматически подписывать ваше приложение во время сборки. Система сборки подписывает отладочную версию ключом и сертификатом по умолчанию, используя известные учётные данные, чтобы избежать запроса пароля во время сборки. Система сборки не подписывает релизную версию, если вы явно не укажете конфигурацию подписи для этой сборки. Если у вас нет релизного ключа, вы можете сгенерировать его, как описано в разделе «Подписание приложения» . Подписанные релизные сборки необходимы для распространения приложений через большинство магазинов приложений.
Сокращение кода и ресурсов
Система сборки позволяет указать отдельный файл правил ProGuard для каждого варианта сборки. При сборке приложения система сборки применяет соответствующий набор правил для сжатия кода и ресурсов , используя встроенные инструменты сжатия, такие как R8. Сжатие кода и ресурсов может помочь уменьшить размер APK или AAB-файла.
Поддержка нескольких 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 для сборки вашего приложения.

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

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

Котлин 

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 в скрипте сборки верхнего уровня после создания нового проекта:

Котлин 

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 "8.11.0" apply false
    id("com.android.library") version "8.11.0" apply false
    id("org.jetbrains.kotlin.android") version "2.1.20" 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 '8.11.0' apply false
    id 'com.android.library' version '8.11.0' apply false
    id 'org.jetbrains.kotlin.android' version '2.1.20' apply false
}

Файл сборки на уровне модуля

Файл build.gradle.kts (для Kotlin DSL) или build.gradle (для Groovy DSL) уровня модуля находится в каждом каталоге project / module / . Он позволяет настроить параметры сборки для конкретного модуля, в котором он находится. Настройка этих параметров сборки позволяет настроить пользовательские параметры упаковки, такие как дополнительные типы сборки и варианты продукта, а также переопределить параметры в манифесте main/ app или скрипте сборки верхнего уровня.

Настройки Android SDK

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

Обзор спецификаций SDK в сборке Gradle
Рисунок 1. Android SDK в сборке
compileSdk

compileSdk определяет, какие API Android и Java доступны при компиляции исходного кода. Чтобы использовать новейшие функции Android, используйте последнюю версию Android SDK при компиляции.

Некоторые API платформы Android могут быть недоступны на более старых уровнях API. Вы можете ограничить использование новых функций или использовать библиотеки совместимости AndroidX для использования новых функций на более низких уровнях API Android.

Каждый Android SDK предоставляет подмножество Java API для использования в вашем приложении. Таблица « Какие Java API можно использовать в исходном коде Java или Kotlin» показывает, какой уровень Java API доступен в зависимости от версии Android SDK. Поддержка новых Java API в более ранних версиях Android осуществляется посредством десахаринга (desugaring) , который необходимо включить в вашей сборке.

Android Studio отображает предупреждения, если ваш compileSdk конфликтует с текущей версией Android Studio, AGP или требованиями к зависимостям библиотеки вашего проекта.

minSdk

Параметр minSdk определяет минимальную версию Android, которую должно поддерживать ваше приложение. Настройка minSdk ограничивает устройства, на которые можно установить ваше приложение.

Поддержка более ранних версий Android может потребовать дополнительных условных проверок в коде или более активного использования библиотек совместимости с AndroidX. Необходимо сопоставить затраты на поддержку более ранних версий с долей пользователей, которые всё ещё используют эти версии. Текущие проценты использования версий см. в таблице версий в мастере создания нового проекта Android Studio.

При редактировании кода в Android Studio или запуске проверок во время сборки lint предупредит об используемых вами API, недоступных в minSdk . Для исправления этой проблемы сделайте новые функции условными или используйте Appcompat для обеспечения обратной совместимости.

targetSdk

targetSdk служит двум целям:

  1. Он устанавливает поведение вашего приложения во время выполнения.
  2. Он подтверждает, какую версию Android вы тестировали.

Если вы запускаете приложение на устройстве с версией Android, которая выше, чем указанная в targetSdk , Android запускает ваше приложение в режиме совместимости, который работает аналогично более низкой версии, указанной в targetSdk . Например, когда в API 23 была представлена модель разрешений времени выполнения, не все приложения были готовы к её немедленному внедрению. Если установить targetSdk в значение 22, эти приложения смогут работать на устройствах с API 23 без использования разрешений времени выполнения и использовать функции, включённые в последнюю версию compileSdk . Политика распространения Google Play применяет дополнительные политики на уровне целевого API .

Значение targetSdk должно быть меньше или равно значению compileSdk .

Примечание: значения compileSdk и targetSdk не обязательно должны совпадать. Помните о следующих основных принципах:

  • compileSdk предоставляет вам доступ к новым API
  • targetSdk устанавливает поведение вашего приложения во время выполнения
  • targetSdk должен быть меньше или равен compileSdk

Пример скрипта сборки модуля приложения

В этом примере скрипта сборки модуля приложения Android описываются некоторые основные элементы и настройки DSL:

Котлин 

/**
 * The first section in the build configuration applies the Android Gradle plugin
 * to this build and makes the android block available to specify
 * Android-specific build options.
 */

plugins {
    id("com.android.application")
}

/**
 * Locate (and possibly download) a JDK used to build your kotlin
 * source code. This also acts as a default for sourceCompatibility,
 * targetCompatibility and jvmTarget. Note that this does not affect which JDK
 * is used to run the Gradle build itself, and does not need to take into
 * account the JDK version required by Gradle plugins (such as the
 * Android Gradle Plugin)
 */
kotlin {
    jvmToolchain(11)
}

/**
 * The android block is where you configure all your Android-specific
 * build options.
 */

android {

    /**
     * The app's namespace. Used primarily to access app resources.
     */

    namespace = "com.example.myapp"

    /**
     * compileSdk specifies the Android API level Gradle should use to
     * compile your app. This means your app can use the API features included in
     * this API level and lower.
     */

    compileSdk = 33

    /**
     * The defaultConfig block encapsulates default settings and entries for all
     * build variants and can override some attributes in main/AndroidManifest.xml
     * dynamically from the build system. You can configure product flavors to override
     * these values for different versions of your app.
     */

    defaultConfig {

        // Uniquely identifies the package for publishing.
        applicationId = "com.example.myapp"

        // Defines the minimum API level required to run the app.
        minSdk = 21

        // Specifies the API level used to test the app.
        targetSdk = 33

        // Defines the version number of your app.
        versionCode = 1

        // Defines a user-friendly version name for your app.
        versionName = "1.0"
    }

    /**
     * The buildTypes block is where you can configure multiple build types.
     * By default, the build system defines two build types: debug and release. The
     * debug build type is not explicitly shown in the default build configuration,
     * but it includes debugging tools and is signed with the debug key. The release
     * build type applies ProGuard settings and is not signed by default.
     */

    buildTypes {

        /**
         * By default, Android Studio configures the release build type to enable code
         * shrinking, using minifyEnabled, and specifies the default ProGuard rules file.
         */

        getByName("release") {
            isMinifyEnabled = true // Enables code shrinking for the release build type.
            proguardFiles(
                getDefaultProguardFile("proguard-android.txt"),
                "proguard-rules.pro"
            )
        }
    }

    /**
     * The productFlavors block is where you can configure multiple product flavors.
     * This lets you create different versions of your app that can
     * override the defaultConfig block with their own settings. Product flavors
     * are optional, and the build system does not create them by default.
     *
     * This example creates a free and paid product flavor. Each product flavor
     * then specifies its own application ID, so that they can exist on the Google
     * Play Store or an Android device simultaneously.
     *
     * If you declare product flavors, you must also declare flavor dimensions
     * and assign each flavor to a flavor dimension.
     */

    flavorDimensions += "tier"
    productFlavors {
        create("free") {
            dimension = "tier"
            applicationId = "com.example.myapp.free"
        }

        create("paid") {
            dimension = "tier"
            applicationId = "com.example.myapp.paid"
        }
    }

    /**
     * To override source and target compatibility (if different from the
     * toolchain JDK version), add the following. All of these
     * default to the same value as kotlin.jvmToolchain. If you're using the
     * same version for these values and kotlin.jvmToolchain, you can
     * remove these blocks.
     */
    //compileOptions {
    //    sourceCompatibility = JavaVersion.VERSION_11
    //    targetCompatibility = JavaVersion.VERSION_11
    //}
    //kotlinOptions {
    //    jvmTarget = "11"
    //}
}

/**
 * The dependencies block in the module-level build configuration file
 * specifies dependencies required to build only the module itself.
 * To learn more, go to Add build dependencies.
 */

dependencies {
    implementation(project(":lib"))
    implementation("androidx.appcompat:appcompat:1.7.1")
    implementation(fileTree(mapOf("dir" to "libs", "include" to listOf("*.jar"))))
}

Круто 

/**
 * The first line in the build configuration applies the Android Gradle plugin
 * to this build and makes the android block available to specify
 * Android-specific build options.
 */

plugins {
    id 'com.android.application'
}

/**
 * Locate (and possibly download) a JDK used to build your kotlin
 * source code. This also acts as a default for sourceCompatibility,
 * targetCompatibility and jvmTarget. Note that this does not affect which JDK
 * is used to run the Gradle build itself, and does not need to take into
 * account the JDK version required by Gradle plugins (such as the
 * Android Gradle Plugin)
 */
kotlin {
    jvmToolchain 11
}

/**
 * The android block is where you configure all your Android-specific
 * build options.
 */

android {

    /**
     * The app's namespace. Used primarily to access app resources.
     */

    namespace 'com.example.myapp'

    /**
     * compileSdk specifies the Android API level Gradle should use to
     * compile your app. This means your app can use the API features included in
     * this API level and lower.
     */

    compileSdk 33

    /**
     * The defaultConfig block encapsulates default settings and entries for all
     * build variants and can override some attributes in main/AndroidManifest.xml
     * dynamically from the build system. You can configure product flavors to override
     * these values for different versions of your app.
     */

    defaultConfig {

        // Uniquely identifies the package for publishing.
        applicationId 'com.example.myapp'

        // Defines the minimum API level required to run the app.
        minSdk 21

        // Specifies the API level used to test the app.
        targetSdk 33

        // Defines the version number of your app.
        versionCode 1

        // Defines a user-friendly version name for your app.
        versionName "1.0"
    }

    /**
     * The buildTypes block is where you can configure multiple build types.
     * By default, the build system defines two build types: debug and release. The
     * debug build type is not explicitly shown in the default build configuration,
     * but it includes debugging tools and is signed with the debug key. The release
     * build type applies ProGuard settings and is not signed by default.
     */

    buildTypes {

        /**
         * By default, Android Studio configures the release build type to enable code
         * shrinking, using minifyEnabled, and specifies the default ProGuard rules file.
         */

        release {
              minifyEnabled true // Enables code shrinking for the release build type.
              proguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-rules.pro'
        }
    }

    /**
     * The productFlavors block is where you can configure multiple product flavors.
     * This lets you create different versions of your app that can
     * override the defaultConfig block with their own settings. Product flavors
     * are optional, and the build system does not create them by default.
     *
     * This example creates a free and paid product flavor. Each product flavor
     * then specifies its own application ID, so that they can exist on the Google
     * Play Store or an Android device simultaneously.
     *
     * If you declare product flavors, you must also declare flavor dimensions
     * and assign each flavor to a flavor dimension.
     */

    flavorDimensions "tier"
    productFlavors {
        free {
            dimension "tier"
            applicationId 'com.example.myapp.free'
        }

        paid {
            dimension "tier"
            applicationId 'com.example.myapp.paid'
        }
    }

    /**
     * To override source and target compatibility (if different from the
     * tool chain JDK version), add the following. All of these
     * default to the same value as kotlin.jvmToolchain. If you're using the
     * same version for these values and kotlin.jvmToolchain, you can
     * remove these blocks.
     */
    //compileOptions {
    //    sourceCompatibility JavaVersion.VERSION_11
    //    targetCompatibility JavaVersion.VERSION_11
    //}
    //kotlinOptions {
    //    jvmTarget = '11'
    //}
}

/**
 * The dependencies block in the module-level build configuration file
 * specifies dependencies required to build only the module itself.
 * To learn more, go to Add build dependencies.
 */

dependencies {
    implementation project(":lib")
    implementation 'androidx.appcompat:appcompat:1.7.1'
    implementation fileTree(dir: 'libs', include: ['*.jar'])
}

Файлы свойств Gradle

Gradle также включает два файла свойств, расположенных в корневом каталоге проекта, которые можно использовать для указания настроек самого инструментария сборки Gradle:

gradle.properties
Здесь можно настроить параметры Gradle для всего проекта, например, максимальный размер кучи демона Gradle. Подробнее см. в разделе «Среда сборки» .
local.properties
Настраивает свойства локальной среды для системы сборки, включая следующее:
  • ndk.dir — путь к NDK. Это свойство устарело. Все загруженные версии NDK устанавливаются в каталог ndk внутри каталога Android SDK.
  • sdk.dir — путь к Android SDK.
  • cmake.dir — Путь к CMake.
  • ndk.symlinkdir — в Android Studio 3.5 и выше создает символическую ссылку на NDK, которая может быть короче установленного пути NDK.

Переназначить NDK на более короткий путь (только для Windows)

В Windows инструменты в установленной папке NDK, такие как ld.exe , имеют длинные пути. Эти инструменты плохо поддерживают длинные пути.

Чтобы создать более короткий путь, в local.properties задайте свойство ndk.symlinkdir , чтобы плагин Android Gradle создавал символическую ссылку на NDK. Путь к этой символической ссылке может быть короче существующей папки NDK. Например, ndk.symlinkdir = C:\ создаст следующую символическую ссылку: C:\ndk\19.0.5232133

Синхронизировать проект с файлами Gradle

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

Чтобы синхронизировать файлы проекта, нажмите «Синхронизировать сейчас» на панели уведомлений, которая появляется при внесении изменений, как показано на рисунке 2, или нажмите «Синхронизировать проект». из строки меню. Если Android Studio обнаружит какие-либо ошибки в вашей конфигурации (например, ваш исходный код использует функции API, доступные только на уровне API выше compileSdkVersion ), в окне «Сообщения» будет описано, в чём проблема.

Рисунок 2. Синхронизация проекта с файлами конфигурации сборки в Android Studio.

Исходные наборы

Android Studio логически группирует исходный код и ресурсы каждого модуля в наборы исходных кодов . При создании нового модуля Android Studio создаёт набор main/ source внутри него. Набор main/ source модуля включает код и ресурсы, используемые всеми вариантами его сборки.

Дополнительные каталоги исходных наборов необязательны, и Android Studio не создаёт их автоматически при настройке новых вариантов сборки. Однако создание исходных наборов, аналогично main/ , помогает организовать файлы и ресурсы, которые Gradle должен использовать только при сборке определённых версий вашего приложения:

src/main/
Этот исходный набор включает код и ресурсы, общие для всех вариантов сборки.
src/ buildType /
Создайте этот исходный набор, чтобы включить код и ресурсы только для определенного типа сборки.
src/ productFlavor /
Создайте этот исходный набор, включающий код и ресурсы только для определенной разновидности продукта.

Примечание: если вы настраиваете сборку на объединение нескольких вариантов продукта , вы можете создать каталоги исходных наборов для каждой комбинации вариантов продукта между измерениями вариантов: src/ productFlavor1 ProductFlavor2 / .

src/ productFlavorBuildType /
Создайте этот исходный набор, чтобы включить код и ресурсы только для определенного варианта сборки.

Например, чтобы создать версию «fullDebug» вашего приложения, система сборки объединяет код, настройки и ресурсы из следующих исходных наборов:

  • src/fullDebug/ (исходный набор вариантов сборки)
  • src/debug/ (исходный набор типа сборки)
  • src/full/ (набор исходных данных о вкусах продукта)
  • src/main/ (основной исходный набор)

Примечание: При создании нового файла или каталога в Android Studio используйте пункт меню «Файл» > «Новый» , чтобы создать его для определённого исходного набора. Доступные исходные наборы основаны на ваших конфигурациях сборки, и Android Studio автоматически создаёт необходимые каталоги, если их ещё нет.

Если разные исходные наборы содержат разные версии одного и того же файла, Gradle использует следующий порядок приоритетов при выборе файла. Исходные наборы слева переопределяют файлы и настройки исходных наборов справа:

вариант сборки > тип сборки > разновидность продукта > основной исходный набор > зависимости библиотеки

Это позволяет Gradle использовать файлы, специфичные для варианта сборки, который вы пытаетесь собрать, при этом повторно используя действия, логику приложения и ресурсы, общие для других версий вашего приложения.

При объединении нескольких манифестов Gradle использует одинаковый порядок приоритетов, поэтому каждый вариант сборки может определять разные компоненты или разрешения в итоговом манифесте. Подробнее о создании пользовательских исходных наборов см. в статье Создание исходных наборов .

Каталоги версий

Если ваша сборка содержит несколько модулей с общими зависимостями или у вас есть несколько независимых проектов с общими зависимостями, мы рекомендуем вам использовать каталог версий или спецификацию материалов (BOM) для указания общих версий.

Другие системы сборки

Разработка приложений для Android с помощью Bazel возможна, но официально не поддерживается. Android Studio официально не поддерживает проекты Bazel.

Чтобы лучше понять текущие ограничения строительства с помощью Bazel, ознакомьтесь с известными проблемами .