El sistema de compilación de Android compila recursos y código fuente de la app, y los empaqueta en APKs o Android App Bundles que puedes probar, implementar, firmar y distribuir.
Android Studio usa Gradle, un paquete de herramientas de compilación avanzadas, para automatizar y administrar el proceso de compilación y, al mismo tiempo, definir configuraciones de compilación personalizadas y flexibles. Cada configuración de compilación puede definir su propio conjunto de código y recursos, y reutilizar las partes comunes a todas las versiones de tu app. El complemento de Android para Gradle funciona con el paquete de herramientas de compilación a fin de proporcionar procesos y ajustes configurables específicos para la compilación y prueba de apps para Android.
Gradle y el complemento de Android para Gradle se ejecutan independientemente de Android Studio. Por lo tanto, puedes compilar tus apps para Android desde Android Studio, la línea de comandos en tu máquina o en máquinas en las que no esté instalado Android Studio (como servidores de integración continua).
Si no usas Android Studio, puedes aprender a compilar y ejecutar tu app desde la línea de comandos. El resultado de la compilación es el mismo si compilas un proyecto desde la línea de comandos, en una máquina remota o con Android Studio.
Nota: Como Gradle y el complemento de Android para Gradle se ejecutan independientemente de Android Studio, debes actualizar las herramientas de compilación por separado. Lee las notas de la versión para descubrir cómo actualizar Gradle y el complemento de Android para Gradle.
La flexibilidad del sistema de compilación de Android te permite crear configuraciones de compilación personalizadas sin modificar los archivos de origen principales de tu app. Esta página te ayuda a comprender la manera en que funciona el sistema de compilación de Android y cómo puede ayudarte a personalizar y automatizar varias configuraciones de compilación. Si quieres obtener más información sobre cómo implementar tu app, consulta Cómo crear y ejecutar tu app. Para comenzar a crear configuraciones de compilación personalizadas de inmediato con Android Studio, consulta Cómo configurar variantes de compilación.
Proceso de compilación
En el proceso de compilación, se incluyen muchas herramientas y procesos que convierten tu proyecto en un paquete de aplicación para Android (APK) o un Android App Bundle (AAB).
El complemento de Android para Gradle realiza gran parte del proceso de compilación por ti, pero puede resultar útil comprender ciertos aspectos del proceso de compilación para que puedas ajustar la compilación de manera que cumpla con tus requisitos.
Los diferentes proyectos pueden tener diferentes objetivos de compilación. Por ejemplo, la compilación para una biblioteca de terceros produce bibliotecas AAR o JAR. Sin embargo, una app es el tipo de proyecto más común, y la compilación para un proyecto de app produce un AAB o APK de depuración o lanzamiento de tu app que puedes implementar, probar o lanzar para usuarios externos.
Esta página se enfoca en el desarrollo de apps, pero muchos de los pasos y conceptos de compilación son comunes en la mayoría de los tipos de compilación.
Glosario de compilación de Android
Gradle y el complemento de Android para Gradle te ayudan a configurar los siguientes aspectos de tu compilación:
- Tipos de compilación
-
Los tipos de compilación definen determinadas propiedades que Gradle usa cuando compila y empaqueta tu app, y por lo general están configurados para diferentes etapas de tu ciclo de vida de desarrollo.
Por ejemplo, el tipo de compilación de depuración habilita opciones de depuración y firma la app con la clave de depuración, mientras que el tipo de compilación de lanzamiento puede reducir, ofuscar y firmar tu app con una clave de lanzamiento para la distribución.
Debes definir al menos un tipo de compilación para poder compilar tu app; Android Studio crea los tipos de compilación de depuración y lanzamiento de forma predeterminada. Para comenzar a personalizar configuraciones de empaquetado para tu app, obtén información sobre cómo configurar tipos de compilaciones.
- Variantes de productos
- Las variantes de productos representan diferentes versiones de tu app que puedes lanzar para los usuarios, como las versiones gratuita y pagada. Puedes personalizar las variantes de productos para usar código y recursos diferentes mientras compartes y reutilizas las partes comunes en todas las versiones de tu app. Las variantes de productos son opcionales y debes crearlas de forma manual. Para comenzar a crear diferentes versiones de tu app, obtén información sobre cómo configurar variantes de productos.
- Variantes de compilación
- Una variante de compilación es un producto cruzado de un tipo de compilación y una variante de producto, y es la configuración que Gradle usa para compilar tu app. Con variantes de compilación, puedes compilar la versión de depuración de tus variantes de productos durante el desarrollo, o versiones de actualización firmadas de tus variantes de productos para distribución. Aunque no configuras variantes de compilación directamente, sí configuras los tipos de compilación y las variantes de productos que las forman. Cuando creas tipos de compilación o variantes de productos adicionales, también se crean variantes de compilación adicionales. Lee la descripción general Cómo configurar variantes de compilación para obtener información sobre cómo crearlas y administrarlas.
- Entradas del manifiesto
- Puedes especificar valores para algunas propiedades del archivo de manifiesto en la configuración de la variante de compilación. Estos valores de compilación anulan los valores existentes en el archivo de manifiesto, lo que resulta útil si deseas generar múltiples variantes de la app con un nombre de aplicación diferente, una versión de SDK mínima o una versión de SDK de destino. Cuando hay varios manifiestos, la herramienta de combinación de manifiestos combina la configuración de los manifiestos.
- Dependencias
- El sistema de compilación administra dependencias del proyecto desde tu sistema de archivos local y desde repositorios remotos. Esto significa que no tienes que buscar, descargar ni copiar manualmente paquetes binarios de tus dependencias en el directorio de tu proyecto. Para obtener más información, consulta Cómo agregar dependencias de compilación.
- Firma
- El sistema de compilación te permite especificar configuraciones de firma en la configuración de la compilación y puede firmar automáticamente tu app durante el proceso de compilación. El sistema de compilación firma la versión de depuración con una clave y un certificado predeterminados usando credenciales conocidas para evitar la solicitud de una contraseña durante el tiempo de compilación. El sistema de compilación no firma la versión de lanzamiento, a menos que definas explícitamente una configuración de firma para esta compilación. Si no tienes una clave de lanzamiento, puedes generar una como se describe en Cómo firmar tu app. Las compilaciones de lanzamiento firmadas son necesarias para distribuir apps a través de la mayoría de las tiendas de aplicaciones.
- Cómo reducir códigos y recursos
- El sistema de compilación te permite especificar un archivo de reglas ProGuard diferente para cada variante de compilación. Cuando compilas tu app, el sistema de compilación aplica el conjunto apropiado de reglas para reducir tu código y tus recursos usando las herramientas de reducción incorporadas, como R8. Reducir tu código y tus recursos puede ayudar a reducir el tamaño de tu APK o AAB.
- Compatibilidad con varios APKs
- El sistema de compilación te permite compilar automáticamente diferentes APKs que contengan solo el código y los recursos necesarios para una densidad de pantalla o una interfaz binaria de la aplicación (ABI) específica. Para obtener más información, consulta Cómo compilar varios APKs. Sin embargo, se recomienda lanzar un solo AAB, ya que ofrece la división por lenguaje, además de la densidad de la pantalla y la ABI, y evita la necesidad de subir varios artefactos a Google Play. Todas las apps nuevas que se envíen después de agosto de 2021 deberán usar los AAB.
Archivos de configuración de la compilación
Para crear configuraciones de compilación personalizadas, debes realizar cambios en uno o más archivos de configuración de la compilación, o en los archivos build.gradle. Estos archivos de texto sin formato usan lenguaje específico de dominio (DSL) para describir y manipular la lógica de compilación mediante Groovy, un lenguaje dinámico para la máquina virtual Java (JVM), o una secuencia de comandos de Kotlin, que es una variante del lenguaje Kotlin.
No necesitas conocer la secuencia de comandos de Groovy o Kotlin para comenzar a configurar tu compilación, ya que el complemento de Android para Gradle introduce la mayoría de los elementos de DSL que necesitas. Para obtener más información sobre el DSL del complemento de Android para Gradle, consulta la documentación de referencia de DSL para Groovy. La secuencia de comandos de Kotlin también se basa en el DSL subyacente de Kotlin para Gradle.
Al comenzar un nuevo proyecto, Android Studio crea automáticamente algunos de esos archivos, como se muestra en la figura 1, y los completa según valores predeterminados confidenciales.
Hay algunos archivos de configuración de compilación de Gradle que forman parte de la estructura estándar del proyecto para una app para Android. Para comenzar a configurar tu compilación, es importante que comprendas el alcance y el objetivo de cada uno de esos archivos, y los elementos de DSL básicos que deben definir.
Archivo de configuración de Gradle
El archivo settings.gradle (para Groovy) o el archivo settings.gradle.kts
(para la secuencia de comandos de Kotlin) se encuentra en el directorio raíz del proyecto. Este archivo de configuración define la configuración del repositorio a nivel del proyecto y le informa a Gradle qué módulos debe incluir al compilar tu app. Los proyectos con varios módulos deben especificar cada módulo que formará parte de la compilación final.
En la mayoría de los proyectos, el archivo tiene el siguiente aspecto predeterminado:
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. 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’
Kotlin
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")
Archivo de compilación de nivel superior
El archivo build.gradle de nivel superior (para Groovy) o el archivo build.gradle.kts (para la secuencia de comandos de Kotlin) se encuentra en el directorio raíz del proyecto. Define las dependencias que se aplican a todos los módulos de tu proyecto. De forma predeterminada, el archivo de compilación de nivel superior usa el bloque plugins para definir las dependencias de Gradle comunes en todos los módulos del proyecto. Además, el archivo de compilación de nivel superior contiene código para limpiar el directorio de compilación.
En la siguiente muestra de código, se describe la configuración predeterminada y los elementos de DSL en el archivo build.gradle de nivel superior después de crear un proyecto nuevo:
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 '7.4.1' apply false
id 'com.android.library' version '7.4.1' apply false
id 'org.jetbrains.kotlin.android' version '1.8.10' apply false
}
Kotlin
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 "7.4.1" apply false
id("com.android.library") version "7.4.1" apply false
id("org.jetbrains.kotlin.android") version "1.8.10" apply false
}
Configura propiedades de todo un proyecto con propiedades adicionales (obsoleto)
En el caso de los proyectos de Android que incluyen varios módulos, puede ser útil definir propiedades en el nivel de proyecto y compartirlas en todos los módulos. Puedes hacerlo si agregas propiedades adicionales al bloque ext en el archivo build.gradle de nivel superior (para Groovy) o el archivo build.gradle.kts (para la secuencia de comandos de Kotlin):
Groovy
// This block encapsulates custom properties and makes them available to all
// modules in the project. The following are only a few examples of the types
// of properties you can define.
ext {
sdkVersion = 33
// You can also create properties to specify versions for dependencies.
// Having consistent versions between modules can avoid conflicts with behavior.
appcompatVersion = "1.6.1"
...
}
...
Kotlin
// This block encapsulates custom properties and makes them available to all
// modules in the project. The following are only a few examples of the types
// of properties you can define.
ext {
extra["sdkVersion"] = 33
// You can also create properties to specify versions for dependencies.
// Having consistent versions between modules can avoid conflicts with behavior.
extra["appcompatVersion"] = "1.6.1"
...
}
...
Para acceder a esas propiedades desde un módulo del mismo proyecto, usa la siguiente sintaxis en el archivo build.gradle del módulo.
Groovy
android {
// Use the following syntax to access properties you defined at the project level:
// rootProject.ext.property_name
compileSdk rootProject.ext.sdkVersion
...
}
...
dependencies {
implementation "androidx.appcompat:appcompat:${rootProject.ext.appcompatVersion}"
...
}
Kotlin
android {
// Use the following syntax to access properties you defined at the project level:
// rootProject.extra["property_name"]
compileSdk = rootProject.extra["sdkVersion"]
// Alternatively, you can access properties using a type safe delegate:
val sdkVersion: Int by rootProject.extra
...
compileSdk = sdkVersion
}
...
dependencies {
implementation("androidx.appcompat:appcompat:${rootProject.ext.appcompatVersion}")
...
}
Archivo de compilación de nivel de módulo
El archivo build.gradle de nivel de módulo (para Groovy) o build.gradle.kts (para la secuencia de comandos de Kotlin) se encuentra en cada directorio project/module/. Te permite configurar ajustes de compilación para el módulo específico en el que se encuentra. La configuración de esos ajustes de compilación te permite proporcionar opciones de empaquetado personalizadas, como tipos de compilación y variantes de productos adicionales, y anular las configuraciones en el manifiesto main/ de la app, en build.gradle de nivel superior o en el archivo build.gradle.kts.
En este ejemplo de archivo build.gradle del módulo de app para Android, se indican algunos de los elementos y ajustes de DSL básicos:
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'
}
/**
* 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'
}
}
}
/**
* 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.6.1'
implementation fileTree(dir: 'libs', include: ['*.jar'])
}
Kotlin
/**
* 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")
}
/**
* 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"
}
}
}
/**
* 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.6.1")
implementation(fileTree(mapOf("dir" to "libs", "include" to listOf("*.jar"))))
}
Archivos de propiedades de Gradle
Gradle también incluye dos archivos de propiedades, ubicados en el directorio raíz de tu proyecto, que puedes usar para especificar ajustes en el paquete de herramientas de compilación de Gradle:
-
gradle.properties - Aquí puedes configurar ajustes de Gradle para todo el proyecto, como el tamaño máximo del montón de daemon de Gradle. Para obtener más información, consulta Entorno de compilación.
-
local.properties -
Configura las propiedades del entorno local para el sistema de compilación, incluidas las siguientes:
ndk.dir: Ruta de acceso al NDK. Esta propiedad dejó de estar disponible. Las versiones descargadas del NDK se instalan en el directoriondk, dentro del directorio del SDK de Android.sdk.dir: Ruta de acceso al SDK.cmake.dir: Ruta de acceso a CMake.ndk.symlinkdir: En Android Studio 3.5 y versiones posteriores, crea un symlink al NDK que puede ser más corto que la ruta del NDK instalado.
Reasigna el NDK a una ruta más corta (solo para Windows)
En Windows, las herramientas de la carpeta del NDK instalado, como ld.exe, terminan con rutas de acceso extensas. Las herramientas no admiten rutas largas.
Para crear una ruta más corta, en local.properties, configura la propiedad ndk.symlinkdir para solicitar que el complemento de Android para Gradle cree un symlink para el NDK. La ruta de ese symlink puede ser más corta que la de la carpeta del NDK existente.
Por ejemplo, ndk.symlinkdir = C:\ tendrá como resultado el siguiente symlink:
C:\ndk\19.0.5232133
Sincroniza el proyecto con archivos de Gradle
Cuando realizas cambios en los archivos de configuración de la compilación de tu proyecto, Android Studio exige que sincronices los archivos de tu proyecto para poder importar tus cambios a la configuración de la compilación y ejecutar algunas comprobaciones para controlar que tu configuración no genere errores de compilación.
Para sincronizar los archivos de tu proyecto, haz clic en Sync Now en la barra de notificaciones que aparece cuando realizas un cambio, como se muestra en la figura 2, o haz clic en Sync Project 
en la barra de menú. Si Android Studio encuentra errores en tu configuración (por ejemplo, tu código fuente usa funciones de API que solo están disponibles en un nivel de API superior al de tu compileSdkVersion), la ventana Messages describe el problema.
Conjuntos de orígenes
Android Studio agrupa de forma lógica código fuente y recursos para cada módulo en conjuntos de orígenes. Cuando creas un nuevo módulo, Android Studio crea un conjunto de orígenes main/ dentro del módulo. El conjunto de orígenes main/ del módulo incluye el código y los recursos que usan todas sus variantes de compilación.
Los directorios adicionales del conjunto de orígenes son opcionales, y Android Studio no los crea automáticamente cuando configuras nuevas variantes de compilación. No obstante, crear conjuntos de orígenes (caso similar al de main/) te ayuda a organizar archivos y recursos que Gradle solo debe usar cuando se compilan ciertas versiones de tu app:
-
src/main/ - Este conjunto de orígenes incluye el código y los recursos comunes en todas las variantes de compilación.
-
src/buildType/ - Crea este conjunto de fuentes a fin de incluir código y recursos solo para un tipo de compilación específico.
-
src/productFlavor/ - Crea este conjunto de orígenes para incluir código y recursos solo para una variante de producto específica.
Nota: Si configuras tu compilación para que combine diversas variantes de productos, puedes crear directorios para conjuntos de orígenes de cada combinación de variantes de producto entre las siguientes dimensiones:
src/productFlavor1ProductFlavor2/. -
src/productFlavorBuildType/ - Crea este conjunto de orígenes para incluir código y recursos solo para una variante de compilación específica.
Por ejemplo, para generar la versión "fullDebug" de tu app, el sistema de compilación fusiona código, configuraciones y recursos de los siguientes conjuntos de orígenes:
-
src/fullDebug/(conjunto de fuentes de la variante de compilación) src/debug/(conjunto de fuentes del tipo de compilación)src/full/(conjunto de fuentes de la variante de producto)-
src/main/(conjunto de orígenes principal)
Nota: Cuando crees un archivo o directorio nuevo en Android Studio, usa las opciones del menú File > New para crearlo para un conjunto de orígenes específico. Los conjuntos de orígenes entre los que puedes elegir se basan en tus configuraciones de compilación, y Android Studio crea automáticamente los directorios necesarios, en caso de que no existan.
Si diferentes conjuntos de orígenes contienen distintas versiones del mismo archivo, Gradle usa el siguiente orden de prioridad para determinar el archivo que se usará. Los conjuntos de orígenes de la izquierda anulan los archivos y las configuraciones de los conjuntos de orígenes de la derecha:
build variant > build type > product flavor > main source set > library dependencies
De esta manera, Gradle puede usar archivos específicos para la variante de compilación que intentas compilar y, al mismo tiempo, reutilizar las actividades, la lógica de aplicación y los recursos comunes a otras versiones de tu app.
Cuando se combinan varios manifiestos, Gradle usa el mismo orden de prioridad, de modo que cada variante de compilación puede definir diferentes componentes o permisos en el manifiesto final. Para obtener más información sobre cómo crear conjuntos de orígenes personalizados, lee Cómo crear conjuntos de orígenes.
Otros sistemas de compilación
Es posible compilar apps para Android con Bazel, pero no es compatible oficialmente. Android Studio no admite proyectos de Bazel.
Para comprender mejor las limitaciones actuales de la compilación con Bazel, consulta los problemas conocidos.