Se usó la API de Cloud Translation para traducir esta página.

Cómo agregar dependencias de compilación

El sistema de compilación de Gradle en Android Studio te permite incluir binarios y otros módulos de biblioteca a tu compilación como dependencias. Las dependencias pueden ubicarse en tu máquina o en un repositorio remoto, y cualquier dependencia transitiva que estas declaren se incluirá automáticamente. En esta página, se describe cómo usar dependencias con tu proyecto de Android, lo que incluye son los detalles sobre los comportamientos y las configuraciones que son el complemento de Android para Gradle (AGP). A fin de obtener una guía conceptual más detallada sobre las dependencias de Gradle, también deberías consultar la Guía de Gradle para la administración de dependencias. Sin embargo, recuerda que tu proyecto de Android solo debe usar los parámetros de configuración de dependencias que se definen en esta página.

Cómo agregar una dependencia de biblioteca o complemento

La mejor manera de agregar y administrar dependencias de compilación es usar catálogos de versiones, el método que usan los nuevos proyectos de forma predeterminada. En esta sección, se abarcan los temas más comunes tipos de configuraciones que se usan para proyectos de Android consulta la Documentación de Gradle para conocer más opciones. Para ver un ejemplo de una app que usa catálogos de versiones, consulta Ahora en Android. Si ya configuraste dependencias de compilación sin catálogos de versiones y con un proyecto de varios módulos, te recomendamos Migración.

Para obtener orientación sobre cómo agregar y administrar dependencias nativas (no común), consulta Dependencias nativas.

En el siguiente ejemplo, agregamos un objeto binario remoto dependencia (el componente de Jetpack Macrobenchmark biblioteca), módulo de biblioteca local dependencia (myLibrary) y un complemento (el complemento de Android para Gradle) a nuestro proyecto. Estas son las preguntas pasos para agregar estas dependencias a tu proyecto:

Agrega un alias para la versión de la dependencia que quieres en el Sección [versions] del archivo de catálogo de versiones, llamada libs.versions.toml (en el directorio gradle de vista Project o secuencias de comandos de Gradle en la vista Android):
```
[versions]
agp = "8.3.0"
androidx-macro-benchmark = "1.2.2"
my-library = "1.4"

[libraries]
...

[plugins]
...
```
Los alias pueden incluir guiones o guiones bajos. Estos alias generan valores anidados al que puedes hacer referencia en las secuencias de comandos de compilación. Las referencias comienzan con el nombre del catálogo, la parte libs de libs.versions.toml. Cuándo con un catálogo de versiones único, te recomendamos que mantengas el valor predeterminado de "libs".
Agrega un alias para la dependencia en [libraries] (para binarios remotos o módulos de bibliotecas locales) o [plugins] (para (complementos) del archivo libs.versions.toml.
```
[versions]
...

[libraries]
androidx-benchmark-macro = { group = "androidx.benchmark", name = "benchmark-macro-junit4", version.ref = "androidx-macro-benchmark" }
my-library = { group = "com.myapplication", name = "mylibrary", version.ref = "my-library" }

[plugins]
androidApplication = { id = "com.android.application", version.ref = "agp" }
```
Algunas bibliotecas están disponibles en una lista de materiales (BoM) publicada que grupos de familias de bibliotecas y sus versiones. Puedes incluir una BoM en tu catálogo de versiones y archivos de compilación, y dejar que administre esas versiones por ti. Consulta Cómo usar la lista de materiales para obtener más detalles.
Agrega una referencia al alias de dependencia a la secuencia de comandos de compilación del módulos que requieren la dependencia. Convertir el alias guiones bajos y guiones en puntos cuando haces referencia a ellos desde una secuencia de comandos de compilación. Nuestra secuencia de comandos de compilación a nivel de módulo se vería así:
Kotlin
plugins { alias(libs.plugins.androidApplication) } dependencies { implementation(libs.androidx.benchmark.macro) implementation(libs.my.library) }
Groovy
plugins { alias 'libs.plugins.androidApplication' } dependencies { implementation libs.androidx.benchmark.macro implementation libs.my.library }
Las referencias de complementos incluyen plugins después del nombre del catálogo. las referencias de la versión incluyen versions después del nombre del catálogo (versión las referencias son poco comunes; consulta Dependencias con los mismos números de versión para ver ejemplos de referencias de versiones). Biblioteca las referencias no incluyen un calificador libraries, por lo que no puedes usar versions o plugins al comienzo de una biblioteca alias.

Configurar dependencias

Dentro del bloque dependencies, puedes declarar una dependencia de biblioteca con uno de varios parámetros de configuración de dependencias diferentes (como implementation anteriormente). La configuración de cada dependencia le proporciona a Gradle diferentes instrucciones para usarla. En la siguiente tabla, se describe cada una de las configuraciones que puedes usar para una dependencia en tu proyecto de Android.

Configuración	Comportamiento
`implementation`	Gradle agrega la dependencia a la ruta de clase de la compilación y la empaqueta en el resultado de la compilación. Cuando el configura una dependencia `implementation`, es indicando a Gradle que no quieres que el módulo filtre el dependencia a otros módulos en el tiempo de compilación. Es decir, la dependencia no está disponible para otros módulos que dependen del módulo. usar esta configuración de dependencia en lugar de `api` puede generar mejoras significativas en el tiempo de compilación ya que reduce la cantidad de módulos que necesita el sistema de compilación volver a compilar. Por ejemplo, si un elemento `implementation` cambia su API, Gradle solo vuelve a compilar esa dependencia y los módulos que dependen directamente de él. La mayoría de las apps y pruebas módulos deben usar esta configuración.
`api`	Gradle agrega la dependencia a la ruta de clase y al resultado de la compilación. Cuando un módulo incluye una dependencia `api`, es para informar a Gradle que el módulo quiere exportar de forma transitiva esa dependencia a otros módulos, de modo que estén disponibles para ellos en el tiempo de ejecución y el tiempo de compilación. Usa esta configuración con precaución y solo con dependencias que necesita exportar transitivamente a otros consumidores ascendentes. Si un La dependencia `api` cambia su API externa, Gradle. vuelve a compilar todos los módulos que tienen acceso a esa dependencia en la compilación. tiempo. Tener una gran cantidad de dependencias `api` puede y aumentar de manera significativa el tiempo de compilación. A menos que quieras exponer un la API de la dependencia a un módulo separado, los módulos de biblioteca deberían, en su lugar, usar dependencias `implementation`
`compileOnly`	Gradle solo agrega la dependencia a la ruta de clase de la compilación. (es decir, que no se agrega al resultado de la compilación). lo que resulta útil cuando creas un módulo de Android y necesitas la dependencia durante la compilación. Sin embargo, tenerla presente durante el tiempo de ejecución es opcional. Para Por ejemplo, si dependes de una biblioteca que solo incluye anotaciones de tiempo de compilación (que por lo general se usa para generar código, pero a menudo no se incluye en el resultado de la compilación), podrías marcar esa biblioteca como `compileOnly`. Si usas esta configuración, entonces tu módulo de biblioteca debe incluir una condición de tiempo de ejecución para comprobar si la dependencia está disponible y, luego, cambiar de manera fluida su comportamiento a fin de que pueda funcionar en caso de que esta no se proporcione. De este modo, se reduce el tamaño de la app final, ya que no se agregan dependencias transitivas que no sean fundamentales. Nota: No puedes usar el `compileOnly` configuración con dependencias de Android Archive (AAR).
`runtimeOnly`	Gradle solo agrega la dependencia al resultado de la compilación para usar durante el tiempo de ejecución. Es decir, esta no se agrega a la ruta de clase de la compilación. No se usa mucho en Android, pero se suele usar en servidores aplicaciones para proporcionar implementaciones de registro. Por ejemplo, un biblioteca podría usar una API de Logging que no incluya un para implementarlos. Los usuarios de esa biblioteca podrían agregarla como `implementation` y, además, incluye un Dependencia `runtimeOnly` para el registro real implementación.
`ksp kapt annotationProcessor`	Estos parámetros de configuración proporcionan bibliotecas que procesan anotaciones y otros símbolos en tu código antes de compilarlo. Por lo general, validar tu código o generar código adicional, lo que reduce el código que tener que escribir. Para agregar esta dependencia, debes hacerlo a la ruta de clase del procesador de anotaciones mediante las configuraciones `ksp`, `kapt` o `annotationProcessor`. Usar estas mejora el rendimiento de la compilación, ya que separa la compilación de la ruta de clase del procesador de anotaciones. Si Gradle encuentra de anotaciones en la ruta de clase de la compilación, desactiva Elusión de compilación, que afecta negativamente el tiempo de compilación (Gradle Las versiones 5.0 y posteriores ignoran los procesadores de anotaciones que se encuentran en la compilación. la ruta de clase). El complemento de Android para Gradle entiende que una dependencia es un procesador de anotaciones si su archivo JAR contiene el siguiente archivo: `META-INF/services/javax.annotation.processing.Processor` Si el complemento detecta un procesador de anotaciones que está en la ruta de clase de la compilación, se producirá un error de compilación. `ksp` es un procesador de símbolos de Kotlin y lo ejecuta el Compilador de Kotlin. `kapt` y `apt` son herramientas independientes que de procesos antes de que se ejecuten los compiladores de Kotlin o Java. Cuando decidas qué configuración usar, ten en cuenta lo siguiente: Si un procesador está disponible como procesador de símbolos de Kotlin, usa como una dependencia `ksp`. Consulta Cómo migrar de kapt a ksp. para obtener información detallada sobre el uso de procesadores de símbolos de Kotlin. Si el procesador no está disponible como procesador de símbolos de Kotlin, haz lo siguiente: Si tu proyecto incluye código fuente de Kotlin (pero también puedes incluir código fuente Java), usa `kapt` para incluirlo. Si tu proyecto solo usa código fuente Java, usa `annotationProcessor` para incluirlo. Para obtener más información sobre el uso de procesadores de anotaciones, consulta Cómo agregar procesadores de anotaciones
`lintChecks`	Usa esta configuración para incluir una biblioteca que contenga lint comprobaciones que quieres que ejecute Gradle al compilar tu app para Android en un proyecto final. Ten en cuenta que los AAR que contienen un archivo `lint.jar` ejecutar automáticamente las comprobaciones definidas en ese archivo `lint.jar` No necesitas agregar una dependencia `lintChecks` explícita. Esto te permite definir bibliotecas y comprobaciones de lint asociadas en un solo dependencia, lo que garantiza que las verificaciones se ejecuten cuando los consumidores usen tu biblioteca.
`lintPublish`	Utiliza esta configuración en los proyectos de la biblioteca de Android para incluir comprobaciones de Lint que quieras que Gradle compile en un archivo `lint.jar` y empaquete en tu AAR. De esa forma, los proyectos que consumen tu AAR también aplican esas comprobaciones de Lint. Si anteriormente usabas la configuración de dependencia `lintChecks` para incluir comprobaciones de lint en el AAR publicado, deberás migrar esas dependencias a fin de usar la configuración `lintPublish`. Kotlin dependencies { // Executes lint checks from the ":checks" project at build time. lintChecks(project(":checks")) // Compiles lint checks from the ":checks-to-publish" into a // lint.jar file and publishes it to your Android library. lintPublish(project(":checks-to-publish")) } Groovy dependencies { // Executes lint checks from the ':checks' project at build time. lintChecks project(':checks') // Compiles lint checks from the ':checks-to-publish' into a // lint.jar file and publishes it to your Android library. lintPublish project(':checks-to-publish') }

Cómo configurar dependencias para una variante de compilación específica

Todas las configuraciones anteriores aplican dependencias a todas las variantes de compilación. Si sino que declaras una dependencia solo para una compilación específica de origen de la variante o de una fuente de prueba set, debes escribir en mayúscula la configuración y agrégale un prefijo con el nombre de la variante de compilación o el conjunto de orígenes de prueba.

Por ejemplo, para agregar una dependencia binaria remota solo a tu app "free" producto variante con la configuración implementation, usa lo siguiente:

Kotlin

dependencies {
    freeImplementation("com.google.firebase:firebase-ads:21.5.1")
}

Groovy

dependencies {
    freeImplementation 'com.google.firebase:firebase-ads:21.5.1'
}

Sin embargo, si deseas agregar una dependencia para una variante que combina un producto y un tipo de compilación, debes inicializar el nombre de la configuración:

Kotlin

// Initializes a placeholder for the freeDebugImplementation dependency configuration.
val freeDebugImplementation by configurations.creating

dependencies {
    freeDebugImplementation(project(":free-support"))
}

Groovy

configurations {
    // Initializes a placeholder for the freeDebugImplementation dependency configuration.
    freeDebugImplementation {}
}

dependencies {
    freeDebugImplementation project(":free-support")
}

Las dependencias implementation que agregues en las pruebas instrumentadas y las locales tendrán el siguiente aspecto:

Kotlin

dependencies {
    // Adds a remote binary dependency only for local tests.
    testImplementation("junit:junit:4.12")

    // Adds a remote binary dependency only for the instrumented test APK.
    androidTestImplementation("androidx.test.espresso:espresso-core:3.5.1")
}

Groovy

dependencies {
    // Adds a remote binary dependency only for local tests.
    testImplementation 'junit:junit:4.12'

    // Adds a remote binary dependency only for the instrumented test APK.
    androidTestImplementation 'androidx.test.espresso:espresso-core:3.5.1'
}

Sin embargo, algunas opciones de configuración no son útiles en esta situación. Por ejemplo, como otros módulos no pueden depender de androidTest, verás la siguiente advertencia si usas la configuración androidTestApi:

WARNING: Configuration 'androidTestApi' is obsolete and has been replaced with
'androidTestImplementation'.

Orden de las dependencias

El orden en el que enumeras tus dependencias indica la prioridad de cada una: la primera biblioteca tendrá mayor prioridad que la segunda, la segunda tendrá mayor prioridad que la tercera, y así sucesivamente. Este orden es importante en el caso de que se combinen los recursos o se combinen los elementos del manifiesto en tu app desde las bibliotecas.

Por ejemplo, si en tu proyecto se declara lo siguiente:

Hay una dependencia en LIB_A y LIB_B (en ese orden).
Además, LIB_A depende de LIB_C y LIB_D (en ese orden).
LIB_B también depende de LIB_C.

Luego, el orden de la dependencia única será el siguiente:

LIB_A
LIB_D
LIB_B
LIB_C

De esta manera, se garantiza que tanto LIB_A como LIB_B puedan anular a LIB_C; además, LIB_D sigue teniendo mayor prioridad que LIB_B porque LIB_A (que depende de esta) tiene mayor prioridad que LIB_B.

Para descubrir cómo se fusionan los manifiestos de diferentes fuentes o dependencias de proyectos, consulta Cómo fusionar varios archivos de manifiestos.

Información de la dependencia de Play Console

Cuando compilas tu app, AGP incluye metadatos que describen la biblioteca las dependencias que se compilan en tu app. Cuando subes tu app, el ícono de Play La consola inspecciona estos metadatos para brindar alertas sobre problemas conocidos con SDKs las dependencias que usa tu app y, en algunos casos, proporcionar comentarios prácticos para resolver esos problemas.

Los datos se comprimen, encriptan con una clave de firma de Google Play y se almacenan en el bloque de firma de tu app de lanzamiento. Recomendamos mantener estas dependencias para garantizar una experiencia del usuario segura y positiva. Para inhabilitarlo, incluye siguiendo dependenciesInfo bloque en el archivo build.gradle.kts de tu módulo.

android {
    dependenciesInfo {
        // Disables dependency metadata when building APKs.
        includeInApk = false
        // Disables dependency metadata when building Android App Bundles.
        includeInBundle = false
    }
}

Para obtener más información sobre nuestras políticas y posibles problemas con las dependencias, consulta nuestra página de asistencia para usar los SDK de terceros en tu app.

Estadísticas del SDK

Android Studio muestra advertencias de lint en el archivo de catálogo de versiones y en la sección Project Structure Dialog para SDKs públicos en el Índice SDK de Google Play cuando se apliquen los siguientes problemas:

Los autores marcan los SDKs como desactualizados.
Los SDKs incumplen las políticas de Play.

Las advertencias indican que debes actualizar esas dependencias usar versiones desactualizadas podría impedir que publiques contenido en Google Play de Cloud en el futuro.

Cómo agregar dependencias de compilación sin catálogos de versiones

Recomendamos usar catálogos de versiones para agregar y administrar dependencias, es posible que los proyectos no los necesiten. Este es un ejemplo de un archivo de compilación que no usa Catálogos de versiones:

Kotlin

plugins {
    id("com.android.application")
}

android { ... }

dependencies {
    // Dependency on a remote binary
    implementation("com.example.android:app-magic:12.3")
    // Dependency on a local library module
    implementation(project(":mylibrary"))
}

Groovy

plugins {
    id 'com.android.application'
}

android { ... }

dependencies {
    // Dependency on a remote binary
    implementation 'com.example.android:app-magic:12.3'
    // Dependency on a local library module
    implementation project(':mylibrary')
}

Este archivo de compilación declara una dependencia en la versión 12.3 de la función "app-magic" dentro de "com.example.android" un grupo de espacios de nombres. El objeto binario remoto La declaración de dependencia es una abreviatura de lo siguiente:

Kotlin

implementation(group = "com.example.android", name = "app-magic", version = "12.3")

Groovy

implementation group: 'com.example.android', name: 'app-magic', version: '12.3'

El archivo de compilación también declara una dependencia en un módulo de biblioteca de Android denominado “mibiblioteca”; este nombre debe coincidir con el nombre de la biblioteca definido con un include: en tu archivo settings.gradle.kts. Cuando compilas tu app, el sistema de compilación compila el módulo de biblioteca y empaqueta el contenido compilado resultante en el .

El archivo de compilación también declara una dependencia en el complemento de Android para Gradle. (com.application.android). Si tienes varios módulos que usan la misma solo puedes tener una versión única del complemento en la ruta de clase de la compilación en todos los módulos. En lugar de especificar la versión en cada módulo las secuencias de comandos de compilación, debes incluir la dependencia del complemento en la secuencia de comandos de compilación raíz. con la versión e indica que no la apliques. Agregar apply false le indica Gradle tome nota de la versión del complemento, pero no la use en la compilación raíz. Por lo general, la secuencia de comandos de compilación raíz está vacía, excepto este bloque plugins.

Kotlin

plugins {
    id("org.jetbrains.kotlin.android") version "1.9.0" apply false
}

Groovy

plugins {
    id ‘com.android.application’ version ‘8.3.0-rc02’ apply false
}

Si tienes un proyecto de un solo módulo, puedes especificar la versión explícitamente en la secuencia de comandos de compilación a nivel de módulo y deja vacía esta secuencia:

Kotlin

plugins {
    id("com.android.application") version "8.3.0"
}

Groovy

plugins {
    id 'com.android.application' version '8.3.0-rc02'
}