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

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

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

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

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

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

Типы сборки

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

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

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

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

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

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

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

Записи манифеста

Вы можете указать значения для некоторых свойств файла манифеста в конфигурации варианта сборки. Эти значения сборки переопределяют существующие значения в файле манифеста. Это полезно, если вы хотите создать несколько вариантов вашего приложения с другим именем приложения, минимальной версией 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 или Groovy, чтобы начать настраивать сборку, поскольку плагин Android Gradle представляет большинство элементов DSL, которые вам нужны. Чтобы узнать больше о плагине Android Gradle DSL, прочтите справочную документацию 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.10.0" apply false
    id("com.android.library") version "8.10.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.10.0' apply false
    id 'com.android.library' version '8.10.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 manifest или скрипте сборки верхнего уровня.

Настройки 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 предоставляет подмножество API Java для использования в вашем приложении. Таблица в разделе Какие API Java можно использовать в исходном коде Java или Kotlin показывает, какой уровень API Java доступен в зависимости от версии Android SDK. Более новые API Java поддерживаются в более ранних версиях Android через desugaring , который должен быть включен в вашей сборке.

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 .

Примечание: Значения 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. Для получения дополнительной информации см. Build Environment .

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/ исходный набор внутри модуля. 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 Wrapper

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

Котлин

Круто

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

Котлин

Круто

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

Настройки Android SDK

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

Котлин

Круто

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

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

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

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

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

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

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