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

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

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

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

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

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

Типы постройки

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

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

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

Вкусы продуктов

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

Варианты сборки

Вариант сборки — это результат взаимодействия типа сборки и варианта продукта, и именно эту конфигурацию Gradle использует для сборки вашего приложения. Используя варианты сборки, вы можете собирать отладочную версию вариантов продукта во время разработки и подписанные релизные версии вариантов продукта для распространения. Хотя вы не настраиваете варианты сборки напрямую, вы настраиваете типы сборки и варианты продукта, которые их формируют. Создание дополнительных типов сборки или вариантов продукта также создает дополнительные варианты сборки. Чтобы узнать, как создавать и управлять вариантами сборки, ознакомьтесь с обзором «Настройка вариантов сборки» .

Манифестные записи

В конфигурации варианта сборки можно указать значения для некоторых свойств файла манифеста. Эти значения переопределяют существующие значения в файле манифеста. Это полезно, если вы хотите создать несколько вариантов вашего приложения с разным именем приложения, минимальной версией SDK или целевой версией 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 Script или Groovy, поскольку плагин Android Gradle предоставляет большинство необходимых элементов DSL. Чтобы узнать больше о DSL плагина Android Gradle, ознакомьтесь с документацией по DSL . Kotlin Script также использует базовый DSL Kotlin в Gradle.

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

Файл-оболочка Gradle

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

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

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

Настройки Android SDK

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

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

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 через десахаризацию , которую необходимо включить в сборке.

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

minSdk

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

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

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

targetSdk

targetSdk выполняет две функции:

Это определяет поведение вашего приложения во время выполнения.
Это подтверждает, с какой версией Android вы проводили тестирование.

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

Значение targetSdk не связано со значением compileSdk . Например, значение targetSdk может быть больше, равно или меньше, чем compileSdk .

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

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

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

В этом примере скрипта сборки модуля 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 = 36

    /**
     * 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 = 23

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

        // 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 36

    /**
     * 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 23

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

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

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

src/main/: Этот набор исходных файлов включает код и ресурсы, общие для всех вариантов сборки.
src/ buildType /: Создайте этот набор исходных файлов, чтобы включить код и ресурсы только для определенного типа сборки.
src/ productFlavor /: Создайте этот набор исходных файлов, чтобы включить код и ресурсы только для конкретной версии продукта.
Примечание: Если вы настроите сборку для объединения нескольких вариантов продукта , вы можете создать каталоги исходных файлов для каждой комбинации вариантов продукта в пределах параметров варианта: src/ productFlavor1 ProductFlavor2 / .
src/ productFlavorBuildType /: Создайте этот набор исходных файлов, чтобы включить код и ресурсы только для определенного варианта сборки.

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

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

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

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

Вариант сборки > Тип сборки > Вариант продукта > Основной набор исходных кодов > Зависимости библиотек

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

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

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

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

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

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

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

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

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

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

Соберите файлы конфигурации

Файл-оболочка Gradle

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

Котлин

Классный

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

Котлин

Классный

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

Настройки Android SDK

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

Котлин

Классный

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

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

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

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

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

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

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