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.
En Descripción general de la compilación de Gradle y Estructura de compilación de Android, analizamos los conceptos de compilación y la estructura de una app para Android. Ahora es el momento de configurar la 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.
Versiones de Java en compilaciones de Android
Ya sea que tu código fuente esté escrito en Java, Kotlin o ambos, hay varios lugares en los que debes elegir una versión de JDK o Java para tu compilación. Consulta Versiones de Java en compilaciones de Android para obtener más detalles.
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. Estos archivos de texto sin formato usan un lenguaje específico de dominio (DSL) para describir y manipular la lógica de compilación mediante una secuencia de comandos de Kotlin, que es una variante del lenguaje Kotlin. También puedes usar Groovy, un lenguaje dinámico para la máquina virtual Java (JVM), para configurar tus compilaciones.
No necesitas conocer la secuencia de comandos de Kotlin o Groovy 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, lee la documentación de referencia de DSL. La secuencia de comandos de Kotlin también se basa en el DSL de Kotlin de Gradle subyacente.
Cuando comienzas un proyecto nuevo, Android Studio crea automáticamente algunos de esos archivos y los completa según valores predeterminados confidenciales. Para obtener una descripción general de los archivos creados, consulta Estructura de compilación de Android.
El archivo de wrapper de Gradle
El wrapper de Gradle (gradlew) es una pequeña aplicación incluida con tu código fuente que descarga y, luego, inicia Gradle.
Esto crea una ejecución de compilación más coherente. Los desarrolladores descargan el código fuente de la aplicación y ejecutan gradlew. Se descargará la distribución de Gradle requerida y se iniciará Gradle para compilar tu aplicación.
El archivo gradle/wrapper/gradle-wrapper.properties contiene una propiedad, distributionUrl, que describe qué versión de Gradle se usa para ejecutar tu compilación.
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
Archivo de configuración de Gradle
El archivo settings.gradle.kts (para el DSL de Kotlin) o el archivo settings.gradle (para el DSL de Groovy) 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:
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. 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'
Archivo de compilación de nivel superior
El archivo build.gradle.kts de nivel superior (para la DSL de Kotlin) o el archivo build.gradle (para la DSL de Groovy) se encuentra en el directorio raíz del proyecto. Por lo general, define las versiones comunes de los complementos que usan los módulos de tu proyecto.
En la siguiente muestra de código, se describen las configuraciones predeterminadas y los elementos de DSL en la secuencia de comandos de compilación de nivel superior después de crear un proyecto nuevo:
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 "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 }
Archivo de compilación de nivel de módulo
El archivo build.gradle.kts de nivel de módulo (para la DSL de Kotlin) o build.gradle (para la DSL de Groovy) 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 o en la secuencia de comandos de compilación de nivel superior.
Configuración del SDK de Android
El archivo de compilación a nivel de módulo para tu aplicación incluye opciones de configuración que indican las versiones del SDK de Android que se usan durante la compilación, la selección de comportamientos de la plataforma y la especificación de la versión mínima en la que se ejecuta tu aplicación.
-
compileSdk -
compileSdkdetermina qué APIs de Android y Java están disponibles cuando se compila el código fuente. Para usar las funciones más recientes de Android, usa el SDK de Android más reciente cuando compiles.Es posible que algunas APIs de la plataforma de Android no estén disponibles en niveles de API anteriores. Puedes proteger de forma condicional el uso de funciones más recientes o usar bibliotecas de compatibilidad de AndroidX para usar funciones más recientes con niveles de API de Android más bajos.
Cada SDK de Android proporciona un subconjunto de APIs de Java para usar en tu aplicación. En la tabla de ¿Qué APIs de Java puedo usar en mi código fuente de Java o Kotlin?, se muestra qué nivel de API de Java está disponible según la versión del SDK de Android. Las APIs de Java más recientes son compatibles con versiones anteriores de Android mediante la expansión de sintaxis, que debe estar habilitada en tu compilación.
Android Studio muestra advertencias si tu
compileSdkentra en conflicto con la versión actual de Android Studio, AGP o los requisitos de dependencia de la biblioteca de tu proyecto. -
minSdk -
minSdkespecifica la versión más antigua de Android que quieres que admita tu app. La configuración deminSdkrestringe los dispositivos que pueden instalar tu app.La compatibilidad con versiones anteriores de Android puede requerir más verificaciones condicionales en el código o un mayor uso de las bibliotecas de compatibilidad de AndroidX. Debes comparar el costo de mantenimiento de la compatibilidad con versiones anteriores en función del porcentaje de usuarios que aún las usan. Consulta el diagrama de versiones en el asistente de proyecto nuevo de Android Studio para ver los porcentajes de uso de versiones actuales.
Cuando edites tu código en Android Studio o ejecutes verificaciones durante la compilación, lint te advertirá sobre las APIs que usas y que no están disponibles en
minSdk. Para corregirlos, debes hacer que las funciones más recientes sean condicionales o usarAppcompatpara la retrocompatibilidad. -
targetSdk -
targetSdktiene dos propósitos:- Establece el comportamiento del entorno de ejecución de tu aplicación.
- Este certifica la versión de Android con la que realizaste pruebas.
Si ejecutas la app en un dispositivo que usa una versión de Android posterior a la de tu
targetSdk, Android ejecuta la app en un modo de compatibilidad que se comporta de manera similar a la versión inferior indicada en tutargetSdk. Por ejemplo, cuando el nivel de API 23 introdujo el modelo de permisos de tiempo de ejecución, no todas las apps estaban listas para adoptarlo de inmediato. Si se configuratargetSdken 22, esas apps podrían ejecutarse en dispositivos con el nivel de API 23 sin usar permisos de tiempo de ejecución y podrían usar las funciones incluidas en la versión más reciente decompileSdk. La política de distribución de Google Play aplica políticas adicionales en el nivel de API objetivo.El valor de
targetSdkdebe ser menor o igual que el decompileSdk.
Nota: No es necesario que los valores de compileSdk y targetSdk sean los mismos. Ten en cuenta los siguientes principios básicos:
compileSdkte brinda acceso a nuevas APIs.targetSdkestablece el comportamiento del entorno de ejecución de tu app.targetSdkdebe ser menor o igual quecompileSdk
Secuencia de comandos de compilación de módulo de app de ejemplo
En esta secuencia de comandos de compilación de ejemplo del módulo de app para Android, se indican algunos de los elementos y parámetros de configuración de DSL básicos:
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") } /** * 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']) }
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: Es la ruta de acceso al SDK de Android.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:\ genera 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.
Catálogos de versiones
Si tu compilación contiene varios módulos con dependencias comunes o tienes varios proyectos independientes con dependencias comunes, te recomendamos que uses un catálogo de versiones o una lista de materiales (BOM) para especificar las versiones comunes.
Otros sistemas de compilaciones
Es posible compilar apps para Android con Bazel, pero no es compatible oficialmente. Android Studio no admite oficialmente proyectos de Bazel.
Para comprender mejor las limitaciones actuales de la compilación con Bazel, consulta los problemas conocidos.