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 de una una biblioteca de terceros produce Android Archive (AAR) o Java Archive (JAR). bibliotecas. 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.
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 un lenguaje Java o JDK. para tu compilación. Consulta Versiones de Java en compilaciones de Android para conocer los 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 compilación. Estos los archivos de texto sin formato usan lenguaje específico de dominio (DSL) para describir y manipular la lógica de compilación mediante Secuencia de comandos de Kotlin, que es una variante del lenguaje Kotlin. También puedes usar Groovy, que es un lenguaje dinámico para la máquina virtual Java (JVM) con el objetivo de configurar tus compilaciones.
No necesitas conocer la secuencia de comandos de Kotlin ni Groovy para comenzar a configurar tu 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 el Documentación de referencia de DSL La secuencia de comandos de Kotlin también se basa subyacentes DSL de Kotlin para Gradle.
Al comenzar un nuevo proyecto, Android Studio crea automáticamente algunos de estos archivos por ti y los completa según valores predeterminados confidenciales. El proyecto de archivos tiene el siguiente diseño:
└── 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
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.
El archivo de wrapper de Gradle
El wrapper de Gradle (gradlew
) es una aplicación pequeña que se incluye en tu
código fuente que descarga e inicia Gradle.
Esto crea una ejecución de compilación más coherente. Los desarrolladores descargan el
fuente de la aplicación y ejecuta gradlew
. De esta manera, se descargan los objetos
distribución y, luego, inicia Gradle para compilar tu app.
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)
settings.gradle
(para el DSL de Groovy) se encuentra en la raíz
del proyecto. Este archivo de configuración define el repositorio
e informa a Gradle qué módulos debe incluir al compilar tu
. Los proyectos con varios módulos deben especificar cada módulo que formará parte del
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. 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")
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'
Archivo de compilación de nivel superior
El archivo build.gradle.kts
de nivel superior (para el DSL de Kotlin) o
build.gradle
(para el DSL de Groovy) se encuentra en la raíz
del proyecto. Por lo general, define las versiones comunes de los complementos que se usan
por módulos en 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.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 }
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.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 }
Archivo de compilación de nivel de módulo
Es el build.gradle.kts
de nivel de módulo (para el DSL de Kotlin) o
archivo build.gradle
(para el DSL de Groovy) se encuentra en cada
project/module/
. Te permite configurar ajustes de compilación para el módulo específico en el que se encuentra. Configurando
estas configuraciones de compilación te permiten ofrecer opciones de empaquetado personalizadas, como
tipos de compilación y variantes de producto adicionales, y anula las configuraciones en el
Manifiesto de la app de main/
o secuencia de comandos de compilación de nivel superior.
Configuración del SDK de Android
El archivo de compilación de nivel de módulo para tu aplicación incluye configuraciones que indican Las versiones del SDK de Android que se usan durante la compilación, la selección de comportamientos de la plataforma y que especifica la versión mínima en la que se ejecuta tu aplicación.
-
compileSdk
-
El
compileSdk
determina qué APIs de Android y Java son disponibles cuando compilas tu código fuente. Para usar la versión más reciente de Android de Google Cloud, 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 condicionalmente el uso de funciones más nuevas o usar Las bibliotecas de compatibilidad de AndroidX para usar funciones más recientes con menor Niveles de API de Android.
Cada SDK de Android proporciona un subconjunto de APIs de Java para usar en tu aplicación. La mesa ubicada en ¿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 nuevas son compatibles con versiones anteriores de Android hasta desugaring, que debe ser habilitado en tu compilación.
Android Studio muestra advertencias si tu
compileSdk
entra en conflicto con la versión actual de Android Studio, AGP o la biblioteca de tu proyecto los requisitos de dependencia. -
minSdk
-
El
minSdk
especifica la versión más antigua de Android que que quieres que tu app admita. ConfigurarminSdk
restringe qué puedan instalar tu app.La compatibilidad con versiones anteriores de Android podría requerir más verificaciones condicionales en tu código o un mayor uso de las bibliotecas de compatibilidad de AndroidX. Deberías Sopesar el costo de mantenimiento de versiones anteriores y el porcentaje de usuarios que aún usan esas versiones anteriores. Consulta la gráfico de versiones en el asistente de proyectos nuevos de Android Studio para conocer los porcentajes de uso de la versión actual.
Cuando edites el código en Android Studio o ejecutes verificaciones durante tu compilación, lint advertirá sobre las APIs que usas que no están disponibles en el
minSdk
. Debes corregir estos errores hacer que las funciones nuevas sean condicionales o usarAppcompat
para brindar retrocompatibilidad. -
targetSdk
-
targetSdk
tiene dos propósitos:- Establece el comportamiento del tiempo de ejecución de tu aplicación.
- Este certifica la versión de Android con la que realizaste pruebas.
Si usas un dispositivo que usa una versión posterior de Android tu
targetSdk
, Android ejecuta tu app en modo de compatibilidad que se comporte de manera similar a la versión anterior que se indica en eltargetSdk
Por ejemplo, cuando la API 23 introdujo el entorno de de permisos, no todas las apps estaban listas para adoptarlo de inmediato. Si establecestargetSdk
en 22, esas apps podrían ejecutarse Dispositivos con nivel de API 23 sin usar permisos de tiempo de ejecución y que podrían usar funciones incluido en la última versión decompileSdk
. Google Play la política de distribución aplica políticas adicionales sobre el nivel de API objetivo.El valor de
targetSdk
debe ser menor o igual que al decompileSdk
.
Nota: Los valores de compileSdk
y targetSdk
no necesitan ser iguales. Ten en cuenta los siguientes principios básicos:
compileSdk
te otorga acceso a nuevas APIstargetSdk
establece el comportamiento del tiempo de ejecución de tu app.- El valor de
targetSdk
debe ser menor o igual quecompileSdk
Ejemplo de secuencia de comandos de compilación de módulos de la app
En este ejemplo de secuencia de comandos de compilación de un módulo de app para Android, se describen algunas de los elementos y ajustes 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
: 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:\
da 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 el
que aparece cuando realizas un cambio, como se muestra en
Figura 1, o haz clic en Sync Project
en la barra de menús. Si Android Studio encuentra errores en tu
configuración; por ejemplo, tu código fuente usa funciones de API que solo se
disponible en un nivel de API superior a tu
compileSdkVersion
— En la ventana Messages, se describe el problema.
![](https://developer.android.com/static/images/tools/as-gradlesync.png?authuser=6&hl=es-419)
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. La propiedad de un módulo
El conjunto de orígenes main/
incluye el código y los recursos que usan todos 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 varios proyectos independientes con dependencias en común, te recomendamos que usas un catálogo de versiones o lista de materiales (BoM) a especificar las versiones comunes.
Otros sistemas de compilaciones
La compilación de apps para Android con Bazel es posible, pero no oficialmente compatible. Android Studio no tiene admitir proyectos de Bazel.
Para comprender mejor las limitaciones actuales de la compilación con Bazel, consulta los problemas conocidos.