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

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

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

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

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

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

Типы сборки

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

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

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

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

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

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

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

При запуске нового проекта 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 "8.7.0" apply false
    id("com.android.library") version "8.7.0" apply false
    id("org.jetbrains.kotlin.android") version "2.0.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.7.0' apply false
    id 'com.android.library' version '8.7.0' apply false
    id 'org.jetbrains.kotlin.android' version '2.0.20' apply false
}

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

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

Настройки Android SDK

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

Обзор спецификаций SDK в сборке Gradle

compileSdk

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

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

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

Примечание. Значения 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.0")
    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.0'
    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 требует, чтобы вы синхронизировали файлы проекта, чтобы она могла импортировать изменения конфигурации сборки, и выполнить некоторые проверки, чтобы убедиться, что ваша конфигурация не создает ошибок сборки.

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

**Рисунок 1.** Синхронизируйте проект с файлами конфигурации сборки в 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

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

Типы сборки

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

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

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

Зависимости

Подписание

Сокращение кода и ресурсов

Поддержка нескольких APK

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

Сборка файлов конфигурации

Файл оболочки 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

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

Котлин

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'

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

Котлин

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

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

Настройки Android SDK

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

Обзор спецификаций SDK в сборке Gradle

compileSdk

minSdk

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

targetSdk

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

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

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

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.0")
    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.0'
    implementation fileTree(dir: 'libs', include: ['*.jar'])
}

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

gradle.properties

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)

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

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

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

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

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

Вариант сборки> Тип сборки> Фронат продукта> Основной набор источников> Библиотечные зависимости

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

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

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

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

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

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

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

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

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

Android строить глоссарий

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

Типы сборки

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

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

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

Продукт ароматы

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

Построить варианты

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

Manifest записи

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

Зависимости

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

Подписание

Система сборки позволяет указать настройки подписания в конфигурации сборки, и она может автоматически подписывать ваше приложение во время процесса сборки. Система сборки подписывает версию отладки с ключом по умолчанию и сертификатом, используя известные учетные данные, чтобы избежать приглашения пароля в время сборки. Система сборки не подписывает версию выпуска, если вы явно не определите конфигурацию подписания для этой сборки. Если у вас нет ключа выпуска, вы можете генерировать один, как описано в Sign Your App . Подписанные сборки выпуска требуются для распределения приложений через большинство магазинов приложений.

Сосадка кода и ресурсов

Система сборки позволяет указать различный файл правил прогноза для каждого варианта сборки. При создании вашего приложения система сборки применяет соответствующий набор правил для сокращения вашего кода и ресурсов, используя встроенные инструменты сокращения, такие как R8. Сокращение вашего кода и ресурсов может помочь уменьшить размер APK или AAB.

Многочисленная поддержка APK

Система сборки позволяет вам автоматически создавать различные APK, каждый из которых содержит только код и ресурсы, необходимые для конкретного двоичного интерфейса плотности экрана или приложения (ABI). Для получения дополнительной информации см. Постройте несколько APK . Тем не менее, выпуск одного AAB является рекомендуемым подходом, поскольку он предлагает расщепление по языку в дополнение к плотности экрана и ABI, избегая при этом необходимости загружать несколько артефактов в Google Play. Все новые приложения, представленные после августа 2021 года, необходимы для использования AAB.

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

Независимо от того, написан ли ваш исходный код в Java, Kotlin или оба, есть несколько мест, которые вы должны выбрать для вашей сборки JDK или Java Language. Смотрите версии Java в Android Builds для деталей.

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

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

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

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

Файл обертки Gradle

Gradle Wrapper ( 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) или File settings.gradle (для Groovy DSL) находится в каталоге Project Root. Этот файл настроек определяет настройки репозитория на уровне проекта и информирует 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")

Groovy

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) расположен в каталоге Root Project. Обычно он определяет общие версии плагинов, используемых модулями в вашем проекте.

В следующем примере кода описывается настройки по умолчанию и элементы 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.7.0" apply false
    id("com.android.library") version "8.7.0" apply false
    id("org.jetbrains.kotlin.android") version "2.0.20" apply false
}

Groovy

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.7.0' apply false
    id 'com.android.library' version '8.7.0' apply false
    id 'org.jetbrains.kotlin.android' version '2.0.20' apply false
}

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

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

Настройки Android SDK

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

Обзор спецификаций SDK в сборке Gradle

compileSdk

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

Некоторые API 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 служит двум целям:

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

Если вы работаете на устройстве, которое использует более высокую версию Android, чем ваш targetSdk , Android запускает ваше приложение в режиме совместимости, который ведет себя аналогично нижней версии, указанной в вашем targetSdk . Например, когда API 23 представил модель разрешений на выполнение, не все приложения были готовы немедленно принять ее. Установив targetSdk на 22, эти приложения могут работать на устройствах API 23 без использования разрешений во время выполнения, и могут использовать функции, включенные в последнюю версию compileSdk . Политика Google Play Distribution обеспечивает дополнительные политики на целевом уровне 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.0")
    implementation(fileTree(mapOf("dir" to "libs", "include" to listOf("*.jar"))))
}

Groovy

/**
 * 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.0'
    implementation fileTree(dir: 'libs', include: ['*.jar'])
}

Файлы свойств градл

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

gradle.properties

Именно здесь вы можете настроить настройки градл в целом, такие как максимальный размер кучи демона Градл. Для получения дополнительной информации см. Среда сборки .

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 Путь этой символики может быть короче существующей папки NDK. Например, ndk.symlinkdir = C:\ Результаты в следующей символике: C:\ndk\19.0.5232133

Sync Project с Gradle Files

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

Чтобы синхронизировать файлы проекта, нажмите Sync Now в панели уведомлений, которая появляется при изменении, как показано на рисунке 1, или нажмите Sync Project из бара меню. Если Android Studio находит какие -либо ошибки с вашей конфигурацией - например, ваш исходный код использует функции API, которые доступны только на уровне API выше, чем в вашем compileSdkVersion , - в окне сообщений описывается проблема.

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

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

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

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

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

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

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

Вариант сборки> Тип сборки> Фронат продукта> Основной набор источников> Библиотечные зависимости

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

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

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

Android строить глоссарий

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

Типы сборки

Продукт ароматы

Построить варианты

Manifest записи

Зависимости

Подписание

Сосадка кода и ресурсов

Многочисленная поддержка APK

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

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

Файл обертки 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

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

Котлин

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")

Groovy

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'

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

Котлин

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.7.0" apply false
    id("com.android.library") version "8.7.0" apply false
    id("org.jetbrains.kotlin.android") version "2.0.20" apply false
}

Groovy

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.7.0' apply false
    id 'com.android.library' version '8.7.0' apply false
    id 'org.jetbrains.kotlin.android' version '2.0.20' apply false
}

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

Настройки Android SDK

Обзор спецификаций SDK в сборке Gradle

compileSdk

minSdk

targetSdk

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

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

Значение 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.0")
    implementation(fileTree(mapOf("dir" to "libs", "include" to listOf("*.jar"))))
}

Groovy

/**
 * 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.0'
    implementation fileTree(dir: 'libs', include: ['*.jar'])
}

Файлы свойств градл

gradle.properties

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)

Sync Project с Gradle Files

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

Дополнительные каталоги наборов источников являются необязательными, и Android Studio не создает их для вас, когда вы настраиваете новые варианты сборки. However, creating source sets, similar to main/ , helps organize files and resources that Gradle should only use when building certain versions of your app:

src/main/: This source set includes code and resources common to all build variants.
src/ buildType /: Create this source set to include code and resources only for a specific build type.
src/ productFlavor /: Create this source set to include code and resources only for a specific product flavor.
Note: If you configure your build to combine multiple product flavors , you can create source set directories for each combination of product flavors between the flavor dimensions: src/ productFlavor1 ProductFlavor2 / .
src/ productFlavorBuildType /: Create this source set to include code and resources only for a specific build variant.

For example, to generate the "fullDebug" version of your app, the build system merges code, settings, and resources from following source sets:

src/fullDebug/ (the build variant source set)
src/debug/ (the build type source set)
src/full/ (the product flavor source set)
src/main/ (the main source set)

Note: When you create a new file or directory in Android Studio, use the File > New menu options to create it for a specific source set. The source sets you can choose from are based on your build configurations, and Android Studio automatically creates the required directories if they don't already exist.

If different source sets contain different versions of the same file, Gradle uses the following priority order when deciding which file to use. Source sets on the left override the files and settings of source sets to the right:

build variant > build type > product flavor > main source set > library dependencies

This allows Gradle to use files that are specific to the build variant you are trying to build while reusing activities, application logic, and resources that are common to other versions of your app.

When merging multiple manifests , Gradle uses the same priority order so each build variant can define different components or permissions in the final manifest. To learn more about creating custom source sets, read Create source sets .

Version catalogs

If your build contains multiple modules with common dependencies, or you have multiple independent projects with common dependencies, we recommend that you use a version catalog or bill of materials (BOM) to specify the common versions.

Other build systems

Building Android apps with Bazel is possible but not officially supported. Android Studio does not officially support Bazel projects.

To better understand the current limitations of building with Bazel, see the known issues .