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

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

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

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

Если вы не используете Android Studio, вы можете узнать, как создавать и запускать приложение из командной строки . Результат сборки одинаков, независимо от того, создаете ли вы проект из командной строки, на удаленном компьютере или с помощью Android Studio.

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

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

Процесс сборки

Процесс сборки включает в себя множество инструментов и процессов, которые преобразуют ваш проект в пакет приложений Android (APK) или пакет приложений Android (AAB).

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

Разные проекты могут иметь разные цели сборки. Например, при сборке сторонней библиотеки создаются библиотеки Android Archive (AAR) или Java Archive (JAR). Однако приложение является наиболее распространенным типом проекта, и при сборке проекта приложения создается отладочный или выпуск APK-файла или AAB вашего приложения, который можно развернуть, протестировать или выпустить для внешних пользователей.

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

Глоссарий сборки 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 автоматически создает для вас некоторые из этих файлов и заполняет их на основе разумных значений по умолчанию. Файловая структура проекта имеет следующий вид:

└── MyApp/  # Project
    ├── gradle/
    │   └── wrapper/
    │       └── gradle-wrapper.properties
    ├── build.gradle(.kts)
    ├── settings.gradle(.kts)
    └── app/  # Module
    │   ├── build.gradle(.kts)
    │   ├── build/
    │   ├── libs/
    │   └── src/
    │        └── main/  # Source set
    │            ├── java/
    │            │   └── com.example.myapp
    │            ├── res/
    │            │   ├── drawable/
    │            │   ├── values/
    │            │   └── ...
    │            └── AndroidManifest.xml

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

Файл оболочки 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. The code below
      * defines 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. The code below
      * defines 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.5.0" apply false
    id("com.android.library") version "8.5.0" apply false
    id("org.jetbrains.kotlin.android") version "1.9.23" 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.5.0' apply false
    id 'com.android.library' version '8.5.0' apply false
    id 'org.jetbrains.kotlin.android' version '1.9.23' apply false
}

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

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

Настройки Android SDK

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

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 служит двум целям:

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

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

Значение 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 — в окне «Сообщения» описывается проблема.

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

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, ознакомьтесь с известными проблемами .