Actualiza las versiones de las dependencias

Si actualizas tus dependencias, obtendrás acceso a sus funciones más recientes, correcciones de errores y mejoras. Para actualizar tus dependencias, debes comprender cómo Gradle resuelve las versiones que solicitas, los riesgos que implican y los pasos que puedes seguir para mitigarlos.

Nota: Las buenas pruebas de apps son clave para garantizar que las actualizaciones no dañen tu compilación o app de formas inesperadas.

Considera tu estrategia de actualización

El paso más importante de cualquier actualización es el análisis de riesgos. Determina cuán cómodo te sientes con cada dependencia que actualizas. Existen muchas consideraciones que debes tener en cuenta cuando definas tu estrategia de actualización, como las siguientes:

Cómo compilar una biblioteca	¿Estás compilando una aplicación que los usuarios descargan y ejecutan en un dispositivo? ¿O estás compilando una biblioteca para ayudar a otros desarrolladores a compilar sus aplicaciones? Si estás compilando una aplicación, concéntrate en mantenerla actualizada y estable. Si compilas una biblioteca, tu enfoque debe estar en las aplicaciones de otros desarrolladores. Las actualizaciones afectan a tus consumidores. Si actualizas una de tus dependencias, esa versión se convierte en candidata para la resolución de dependencias de Gradle, lo que podría interrumpir el uso de esa dependencia por parte de la aplicación. Primero, minimiza las dependencias de tu biblioteca siempre que sea posible. Cuanta menos dependencias tengas, menor será el impacto en la resolución de dependencias de tu consumidor. Asegúrate de seguir el control de versiones semánticas para indicar los tipos de cambios que realizas. Por ejemplo, AndroidX sigue el control de versiones semántico y agrega un esquema de control de versiones previo al lanzamiento. Intenta evitar las actualizaciones de versión major para no dañar a tus consumidores. Considera crear una versión candidata (RC) de tu biblioteca para que los usuarios la prueben antes. Consulta los lineamientos de retrocompatibilidad para autores de bibliotecas para obtener detalles sobre cómo mantener la compatibilidad de la interfaz binaria de aplicación (ABI) de tu biblioteca. Usa pruebas de integración y herramientas como el validador de compatibilidad binaria para asegurarte de que los cambios de ABI coincidan con el cambio de versión previsto. Si lanzas correcciones en una patch para versiones anteriores de tu biblioteca, los consumidores no tendrán que actualizarla a la próxima versión de major o minor, a menos que quieran nuevas funciones. Evita actualizar las dependencias transitivas en estas actualizaciones. Si la actualización de tu biblioteca requiere cambios drásticos que pueden ser particularmente difíciles para tus consumidores, considera lanzarlos como un artefacto nuevo para que las versiones anteriores y nuevas puedan coexistir y permitir un lanzamiento más gradual. Nota: Si la actualización de una de tus dependencias contiene un cambio importante en la API, te recomendamos que la actualices en una versión major o minor y que realices los cambios necesarios. Si no lo haces, los usuarios de tu biblioteca podrían hacerlo, lo que provocaría incompatibilidades entre tu biblioteca y esa dependencia. Esto puede aplicarse incluso si no hay cambios en tu biblioteca. Puedes lanzar una versión nueva solo para actualizar esa dependencia.
Ciclo de lanzamiento	¿Con qué frecuencia lanzas tu aplicación o biblioteca? Ciclos de desarrollo y lanzamiento más cortos El proceso de actualización tiene menos tiempo. Puedes quedarte atrás rápidamente. Las actualizaciones pequeñas y frecuentes pueden facilitar la carga de trabajo. Si una actualización de biblioteca se vuelve problemática, puedes revertirla más rápido. Las herramientas como Dependabot y Renovate reducen la carga de trabajo, pero asegúrate de analizar los resultados para detectar riesgos. Ciclos de desarrollo y lanzamiento más largos Hay más tiempo para realizar y probar las actualizaciones. Es más probable que las versiones más nuevas de las dependencias se publiquen durante tu ciclo. La reversión de las actualizaciones y el lanzamiento de tu aplicación o biblioteca tardan más tiempo.
Mantente al tanto de las funciones más recientes	¿Prefieres usar las funciones y las APIs más recientes disponibles, o solo actualizar cuando necesites una función o una solución de errores? Considera las ventajas y desventajas de las actualizaciones frecuentes. Las actualizaciones futuras son más fáciles (menos cambios para integrar), pero asumes riesgos de actualización con más frecuencia. Probar las actualizaciones a versiones previas al lanzamiento (alfa, beta o versión candidata) de las bibliotecas puede ayudar a prepararte cuando haya versiones estables disponibles.
Nueva dependencia	Si agregas una dependencia nueva, considera realizar un proceso de revisión sólido que examine esa biblioteca en busca de todos los criterios de riesgo para garantizar que se hayan evaluado correctamente. No permitas que se agreguen dependencias nuevas sin revisión.
Equipo dedicado	¿Tienes un equipo de compilación dedicado? ¿Los ingenieros de software mantienen la construcción? Un equipo dedicado a menudo puede dedicar más tiempo a analizar los riesgos de actualización y probar versiones nuevas para garantizar que la compilación funcione correctamente antes de que los ingenieros las usen.
Tipo de actualización	Algunas actualizaciones son más importantes que otras. Piensa en cuáles son los más importantes para ti. Las actualizaciones de herramientas de compilación, como Gradle y sus complementos, suelen tener un impacto menor en los usuarios, y gran parte del riesgo es interno de la compilación. La compilación en sí ayuda a validar estos cambios. Las actualizaciones de bibliotecas y SDKs son más difíciles de validar y presentan un mayor riesgo para los usuarios. Complemento de Android para Gradle (AGP): Son las herramientas que se usan para compilar tu aplicación o biblioteca para Android. Esta es la actualización más importante que puedes realizar, ya que a menudo incluye o habilita mejoras de rendimiento, correcciones de errores, nuevas reglas de lint y compatibilidad con nuevas versiones de la plataforma de Android. Gradle: A menudo, deberás actualizar Gradle cuando actualices AGP o algún otro complemento de Gradle. Otros complementos de Gradle: A veces, cambia la API del complemento de Gradle. Cuando actualices Gradle, busca actualizaciones de los complementos que usas. Kotlin y Java: Algunas bibliotecas y complementos requieren versiones mínimas de Kotlin o Java, o bien quieres aprovechar nuevas funciones del lenguaje, APIs o mejoras de rendimiento. Plataforma de Android: Play Store requiere actualizaciones regulares del SDK de Android. Debes probar las versiones nuevas del SDK de Android lo antes posible. Algunas actualizaciones de SDK requieren cambios en tu aplicación, como nuevos permisos o el uso de APIs nuevas. Bibliotecas: ¿Quieres priorizar las bibliotecas en función de su cercanía a tu arquitectura general? Las bibliotecas relacionadas con la plataforma y la arquitectura, como AndroidX, suelen cambiar para aprovechar nuevas funciones o ayudar a abstraer los cambios en la plataforma. Actualiza estas bibliotecas al menos cada vez que actualices la plataforma de Android o alguna otra biblioteca relacionada con la arquitectura. Otras actualizaciones de bibliotecas se pueden distribuir o retrasar, a menos que necesites una función nueva o correcciones de errores específicas. Android Studio: Mantener Android Studio actualizado te brinda acceso a las funciones y correcciones de errores más recientes de la plataforma y las herramientas subyacentes de IntelliJ IDEA para trabajar con los SDK de Android más recientes.
Herramientas disponibles	Hay muchas herramientas y complementos disponibles para ayudarte con las actualizaciones. Las herramientas como Dependabot y Renovate actualizan automáticamente las versiones de las bibliotecas en tu compilación, pero asegúrate de analizar los resultados para comprobar si hay riesgos.

Estrategias para tipos específicos de actualizaciones

La actualización de algunos tipos de dependencias puede tener un efecto en cascada, lo que requiere que se actualicen otros tipos de dependencias. Analizamos las relaciones entre los elementos de compilación en Interdependencias entre herramientas y bibliotecas.

Figura 1: Establece relaciones.

Cuando actualices cada tipo de componente, ten en cuenta cómo la actualización afecta a otros componentes de la compilación.

Complemento de Android para Gradle (AGP)	Android Studio incluye un asistente de actualización del AGP que puede ayudarte con estas tareas. Si usas el Asistente o realizas la actualización de forma manual, ten en cuenta lo siguiente: Consulta las notas de la versión de AGP. Actualiza Gradle al menos a la versión que se indica. Actualiza Android Studio a una versión que admita la versión de AGP elegida. Usa versiones de Android Studio y AGP que admitan el SDK de Android que deseas usar. Verifica la compatibilidad con las herramientas de compilación del SDK, el NDK y el JDK. Si desarrollas un complemento de Gradle (para uso interno o público) que extienda o use datos del AGP, verifica si necesitas actualizar el complemento. A veces, AGP da de baja y, luego, quita las APIs, lo que genera incompatibilidades con complementos anteriores.
Compilador, lenguaje y entorno de ejecución de Kotlin	Consulta las notas de la versión de Kotlin para conocer los problemas y las incompatibilidades conocidos. Si usas Jetpack Compose, haz lo siguiente: Si la nueva versión de Kotlin es anterior a 2.0.0, haz lo siguiente: Busca el complemento del compilador de Compose compatible. Actualiza kotlinCompilerExtensionVersion en el build.gradle.kts de los módulos en los que aparezca. Si la nueva versión de Kotin es 2.0.0 o posterior: Configura el complemento de Gradle para el compilador de Compose con la misma versión que el compilador de Kotlin. Si usas el procesamiento de símbolos de Kotlin (KSP), consulta la Guía de inicio rápido de KSP para conocer la configuración y las versiones de KSP disponibles. Ten en cuenta que debes usar una versión de KSP que coincida con la versión de Kotlin. Por ejemplo, si usas Kotlin 2.0.21, puedes usar cualquier versión del complemento KSP que comience con 2.0.21, como 2.0.21-1.0.25. Por lo general, no necesitarás actualizar los procesadores KSP (como el compilador Room, que aparece como una dependencia ksp en tus archivos de compilación); el complemento KSP abstrae gran parte de la API del compilador, y la API de KSP que usan los procesadores es estable. Actualiza todos los demás complementos del compilador de Kotlin que uses. La API del complemento del compilador de Kotlin suele cambiar entre las versiones, y los complementos deben usar una API compatible. Si el complemento aparece en Complementos del compilador, debes usar la misma versión que el compilador de Kotlin. Para cualquier otro complemento de compilación, consulta su documentación para encontrar la asignación adecuada. Ten en cuenta que los complementos del compilador que no se mantienen junto con el compilador de Kotlin suelen experimentar demoras en el lanzamiento mientras esperan que se estabilice la API del complemento del compilador. Antes de actualizar Kotlin, verifica que todos los complementos del compilador que uses tengan actualizaciones coincidentes disponibles. Por último, en algunas ocasiones, el lenguaje Kotlin cambia, lo que requiere que actualices tu código. Esto suele ocurrir si pruebas funciones experimentales. Si tu código no se compila correctamente después de actualizar el compilador de Kotlin, comprueba si hay cambios de lenguaje o fallas de la biblioteca del entorno de ejecución en las notas de la versión de Kotlin.
Complementos del compilador de Kotlin	Si necesitas actualizar un complemento del compilador de Kotlin, actualízalo a la versión de Kotlin que se está usando. La mayoría de los complementos del compilador de Kotlin usan la misma versión que el compilador de Kotlin o comienzan con la versión requerida del compilador de Kotlin. Por ejemplo, si la versión del complemento es 2.0.21-1.0.25, debes usar la versión 2.0.21 del compilador de Kotlin. Cambiar la versión del compilador de Kotlin a veces requiere otros cambios.
Bibliotecas	Las bibliotecas son la dependencia que se actualiza con más frecuencia en tu compilación. Verás las actualizaciones disponibles en el editor de Android Studio o si usas algunos complementos y herramientas de dependencia. Algunas bibliotecas especifican un compileSdk o minSdk mínimo necesario para usarlas. Si no usas al menos el compileSdk especificado, tus compilaciones fallarán. Sin embargo, el minSdk de tu aplicación se establece automáticamente en el máximo de todos los valores minSdk especificados en las dependencias de tu biblioteca y los archivos de compilación. Algunas bibliotecas también especifican una versión mínima de Kotlin para su uso. Actualiza la versión de Kotlin en tus archivos de compilación para que sea al menos la versión especificada.
Gradle	A veces, las versiones nuevas de Gradle dan de baja las APIs existentes y las quitan en una versión futura. Si desarrollas un complemento de Gradle, actualízalo lo antes posible, en especial si es público. Algunas actualizaciones de Gradle requieren la ubicación de versiones nuevas de los complementos que usas. Ten en cuenta que estos complementos pueden retrasarse en su desarrollo a medida que se actualizan para que coincidan con las APIs de complementos de Gradle más recientes. Para actualizar Gradle, haz lo siguiente: Lee las notas de la versión de la versión que deseas usar. Actualiza la versión de Gradle en gradle/wrapper/gradle-wrapper.properties. Ejecuta ./gradlew wrapper --gradle-version latest para actualizar el archivo JAR y las secuencias de comandos del wrapper de Gradle. Actualiza tus complementos de Gradle. Actualiza el JDK que se usa para ejecutar Gradle.
Complementos de Gradle	Los complementos de Gradle actualizados a veces usan APIs de Gradle nuevas o modificadas, que a su vez requieren una actualización de Gradle o, posiblemente, cambios en su configuración en los archivos de compilación. En cualquier caso, verás advertencias o errores de compilación para indicar la incompatibilidad. Cuando actualices complementos, actualiza Gradle.
SDK de Android	Android Studio incluye un asistente de actualización del SDK de Android que puede ayudarte con estas tareas. Si usas el asistente o realizas la actualización de forma manual, ten en cuenta lo siguiente: Cada versión del SDK de Android contiene funciones y APIs nuevas, correcciones de errores y cambios de comportamiento. Play Store requiere que actualices tu targetSdk, pero te recomendamos que lo hagas antes de las fechas límite para tener más tiempo para realizar los cambios necesarios.targetSdk Antes de actualizar el SDK de Android, lee atentamente las notas de la versión. Presta mucha atención a la sección de cambios de comportamiento, que incluye lo siguiente: Son permisos nuevos que deberás solicitar durante la instalación o el tiempo de ejecución. APIs obsoletas y sus reemplazos Cambios rotundos en las APIs o el comportamiento Nuevas APIs de Kotlin o Java, que pueden afectar tu código. La sección de cambios de comportamiento puede ser bastante larga, pero presta mucha atención, ya que suele contener cambios críticos que debes realizar en tu aplicación. Debes actualizar targetSdk para cumplir con los requisitos de Play Store. Actualizar compileSdk es opcional, por lo que podrás acceder a APIs nuevas. Ten en cuenta que algunas bibliotecas, como AndroidX, incluyen un requisito mínimo de compileSdk. Para aprovechar las nuevas funciones del SDK durante el desarrollo y garantizar la compatibilidad durante la compilación, actualiza el complemento de Android para Gradle (AGP) y Android Studio. Estas incluyen herramientas nuevas y mejoradas para los nuevos SDKs. Consulta Versiones mínimas de herramientas para el nivel de API de Android. Cuando actualices el SDK de Android, actualiza las bibliotecas de AndroidX que uses. AndroidX suele usar APIs nuevas y actualizadas para mejorar la compatibilidad y el rendimiento en todas las versiones del SDK de Android.
Android Studio	Por lo general, puedes actualizar Android Studio en cualquier momento. Es posible que veas mensajes que te soliciten actualizar AGP o actualizar el SDK de Android. Estas actualizaciones son muy recomendables, pero no obligatorias. Si más adelante quieres usar Android Studio para actualizar AGP o el SDK de Android, puedes encontrar estas opciones en el menú Tools: Asistente de actualización del AGP… Asistente de actualización del SDK de Android…
Java	Si tienes código fuente Java en tu aplicación para Android, puedes aprovechar las API de Java más nuevas. Cada versión del SDK de Android admite un subconjunto de APIs de Java y funciones de lenguaje. AGP proporciona compatibilidad con versiones anteriores del SDK de Android mediante un proceso llamado expansión de sintaxis. En las notas de la versión del SDK de Android, se especifica qué nivel de Java es compatible y los posibles problemas. Algunos de estos problemas también pueden afectar al código fuente de Kotlin, ya que este lenguaje tiene acceso a las mismas APIs de Java. Asegúrate de prestar mucha atención a las secciones de la API de JDK que aparecen en la sección de cambios de comportamiento de las notas de la versión, incluso si no tienes código fuente Java. El uso de JDK se especifica en varios lugares de tus secuencias de comandos de compilación. Para obtener más información, consulta Versiones de Java en la compilación de Android.

Actualizar análisis

La actualización de una dependencia puede generar riesgos en forma de cambios de API y de comportamiento, nuevos requisitos de uso, nuevos problemas de seguridad o incluso cambios de licencia. Por ejemplo, ¿necesitas hacer lo siguiente?

• ¿Quieres cambiar el código para los cambios en la API?
• ¿Agregar nuevas verificaciones de permisos?
• ¿Crear pruebas adicionales o modificar las existentes para ver los cambios de comportamiento?

Ten en cuenta que la dependencia que actualizaste actualizó las versiones de sus dependencias. Esto puede convertirse rápidamente en un conjunto masivo de cambios.

Si usas una herramienta como Renovate o Dependabot para automatizar las actualizaciones, ten en cuenta que no realizan ningún análisis por ti, sino que actualizan a las versiones más recientes de la biblioteca. No asumas que todo funcionará correctamente después de estos tipos de actualizaciones automáticas.

La clave para realizar actualizaciones exitosas es el análisis de actualizaciones:

1. Determina las diferencias de dependencia antes y después de las actualizaciones.
2. Examina cada cambio y determina los riesgos involucrados.
3. Mitigar los riesgos o aceptar o rechazar los cambios

Determina las diferencias de dependencia

El primer paso en el análisis de actualización es determinar cómo cambian tus dependencias. Aprovecha el control de versiones (VCS, como Git) y el complemento Dependency Guard para ver los cambios rápidamente. Tu objetivo es crear una instantánea del antes y el después y compararlas.

Configura y crea tu primer modelo de referencia

Antes de comenzar la actualización, asegúrate de que tu proyecto se compile correctamente.

Lo ideal es resolver la mayor cantidad posible de advertencias o crear modelos de referencia para hacer un seguimiento de las advertencias que ya viste.

• Lint: Examina tus advertencias de lint existentes y crea un modelo de referencia de lint para Android.
• Compilador de Kotlin:
  • Habilita -Werror para que trate todas las advertencias como errores. Consulta Cómo definir opciones.
  • Considera usar complementos como Kotlin Warning Baseline o Kotlin Warnings Baseline Generator.
• Otras herramientas: Si usas otras herramientas de análisis estático (como Detekt) que admiten el seguimiento del modelo de referencia, configura sus modelos de referencia.

Estos modelos de referencia de advertencias facilitan la visualización de las advertencias nuevas que se introducen a medida que actualizas tus dependencias.

Para crear un modelo de referencia de dependencias, configura y ejecuta Dependency Guard. En el catálogo de versiones gradle/libs.versions.toml, agrega lo siguiente:

[versions]
dependencyGuard = "0.5.0"

[plugins]
dependency-guard = { id = "com.dropbox.dependency-guard", version.ref = "dependencyGuard" }

Agrega lo siguiente al archivo de compilación de tu app:

Kotlin

plugins {
    alias(libs.plugins.dependency.guard)
}

dependencyGuard {
    configuration("releaseRuntimeClasspath")
}

Groovy

plugins {
    alias(libs.plugins.dependency.guard)
}

dependencyGuard {
    configuration('releaseRuntimeClasspath')
}

La configuración de releaseRuntimeClasspath es un objetivo probable, pero si quieres usar una configuración diferente, ejecuta ./gradlew dependencyGuard sin una configuración enumerada en tu archivo de compilación para ver todas las configuraciones disponibles.

Después de la configuración, ejecuta ./gradlew dependencyGuard para generar un informe en app/dependencies/releaseRuntimeClasspath.txt. Este es tu informe de referencia. Confirma esta acción en tu sistema de control de versiones (VCS) para guardarla.

Ten en cuenta que Dependency Guard solo captura la lista de dependencias de bibliotecas. Hay otras dependencias en tus archivos de compilación, como las versiones del SDK de Android y de JDK. Confirmar los cambios en tu VCS antes de que cambie la dependencia permite que la diferencia del VCS también destaque esos cambios.

Actualiza y compara con tu modelo de referencia

Una vez que tengas un modelo de referencia, actualiza las dependencias y otros cambios en la compilación que querías probar. No actualices tu código fuente ni tus recursos en este momento.

Ejecuta ./gradlew lint para ver las nuevas advertencias o errores de lint. Soluciona los problemas importantes y, luego, ejecuta ./gradlew lint -Dlint.baselines.continue=true para actualizar el modelo de referencia de advertencias. Si usaste otras herramientas para capturar modelos de referencia de advertencias, como Kotlin Warning Baseline o Kotlin Warnings Baseline Generator, aborda las advertencias nuevas y actualiza sus modelos de referencia también.

Ejecuta ./gradlew dependencyGuard para actualizar tu informe de referencia. Luego, ejecuta la comparación de tu CVS para ver los cambios que no son de la biblioteca. Es probable que incluya muchas más actualizaciones de bibliotecas que las que crees.

Analiza los riesgos

Una vez que sepas qué cambió, considera los riesgos posibles de cada biblioteca actualizada. Esto ayuda a enfocar las pruebas o a investigar los cambios de forma más profunda. Define un conjunto de riesgos para analizar en tu proyecto y garantizar un análisis coherente.

Algunas consideraciones:

Actualizaciones de versión principal	¿Cambió el número de versión principal? En el control de versiones semánticas, el primer número se conoce como la versión principal. Por ejemplo, si la versión de una biblioteca se actualizó de 1.2.3 a 2.0.1, significa que la versión principal cambiará. Por lo general, esto indica que el desarrollador de la biblioteca realizó cambios incompatibles entre las versiones, como quitar o cambiar partes de la API. Cuando veas esto, presta especial atención a las bibliotecas afectadas cuando consideres cualquiera de las siguientes opciones. Si tu código usa alguna API experimental (que a menudo requiere que habilites el uso con anotaciones o especificaciones de archivos de compilación), incluso los cambios menores o de versión de parche, como actualizar de la versión 1.2.3 a la 1.3.1 o de la 1.2.3 a la 1.2.5, pueden presentar riesgos adicionales.
API no estable	Algunas versiones de bibliotecas pueden incluir APIs no estables. Por lo general, son APIs que están en proceso o dependen de otra API inestable. Si bien, por lo general, se limitan a versiones preliminares, como versiones alfa, de desarrollo o experimentales, algunas bibliotecas incluyen APIs marcadas como experimentales o inestables. Si es posible, evita esas APIs. Si necesitas usarlos, asegúrate de registrar el uso y estar atento a los cambios o las eliminaciones en las versiones posteriores.
Comportamiento dinámico	Algunas bibliotecas se comportan de manera diferente según factores externos. Por ejemplo, una biblioteca que se comunica con un servidor depende de los cambios que se realizan en ese servidor. ¿La biblioteca debe coincidir con una determinada versión del servidor? ¿La biblioteca puede conectarse a diferentes versiones de un servidor? ¿Algún otro factor externo afecta el comportamiento adecuado de la biblioteca?
Combinación de manifiestos	Las bibliotecas publicadas como archivos Android Archives (AAR) pueden contener recursos y manifiestos que se combinan en tu aplicación. Estos pueden agregar permisos y componentes de Android nuevos, como actividades o receptores de emisión, que se ejecutan de forma indirecta.
Actualizaciones del entorno de ejecución	Algunas bibliotecas usan funciones que se pueden actualizar fuera del control de tu aplicación. Una biblioteca podría usar los Servicios de Play, que se actualizan independientemente del SDK de Android. Otras bibliotecas pueden vincularse a servicios en aplicaciones externas actualizadas de forma independiente (a menudo, con AIDL).
¿Cuántas versiones omitirás?	Cuanto más esperes para actualizar una biblioteca, mayores serán los riesgos potenciales. Si ves que una versión cambia de forma significativa, como de 1.2.3 a 1.34.5, presta especial atención a esta biblioteca.
Guías de migración	Verifica si la biblioteca tiene una guía de migración. Esto puede reducir significativamente tu análisis de riesgos y la planificación de mitigación. Ten en cuenta que la presencia de una guía de este tipo es un buen indicador de que el desarrollador se centró en la compatibilidad y consideró la mitigación de actualizaciones.
Notas de la versión	Consulta las notas de la versión (si se proporcionan) de cada biblioteca modificada. Busca indicaciones de cambios rotundos o requisitos nuevos, como permisos agregados.
Instrucciones	Algunos archivos readme de una biblioteca indican posibles riesgos, en especial, si la biblioteca no proporciona notas de la versión. Busca _problemas conocidos_, en especial, problemas de seguridad.
Cómo verificar vulnerabilidades conocidas	El Índice SDK de Play realiza un seguimiento de las vulnerabilidades de muchos SDKs populares. Play Console informa si usas uno de los SDKs enumerados con vulnerabilidades conocidas. Cuando editas archivos de compilación en Android Studio, el IDE verifica el índice del SDK y marca el uso de versiones de bibliotecas vulnerables. El Instituto Nacional de Estándares y Tecnología (NIST) mantiene una gran Base de datos nacional sobre vulnerabilidades (NVD). El complemento de Gradle Dependency Check verifica las dependencias que usas en función del NVD. Para usar Dependency Check, solicita una clave de API de NVD, configura el complemento de Gradle y ejecuta ./gradlew dependencyCheckAnalyze. Ten en cuenta que esto puede tardar mucho tiempo en ejecutarse.
Conflictos de versiones	¿Las versiones se resuelven como se espera? Busca conflictos, en especial diferencias entre versiones principales. Consulta Resolución de dependencias de Gradle para obtener detalles sobre cómo buscar conflictos. En particular, busca -> en el informe ./gradlew app:dependencies. Cuando sea posible, trabaja con los autores de una dependencia para eliminar los conflictos de sus dependencias. Si tu empresa lo permite, realiza cambios en la biblioteca (transferencia ascendente) para mejorar su compatibilidad.
Cómo verificar las licencias	Busca cambios en las licencias cuando actualices una biblioteca. La biblioteca en sí podría cambiar a una licencia que ya no sea compatible con tu aplicación o biblioteca. Las nuevas dependencias transitivas también podrían introducir licencias incompatibles. Consulta Cómo validar licencias para obtener detalles sobre cómo verificar el conjunto actual de licencias en tus dependencias.
Riesgos de calidad y mantenimiento	Para bibliotecas con repositorios públicos: ¿Cuántos colaboradores mantienen la biblioteca? ¿Cuándo fue la última actualización y con qué frecuencia cambia la biblioteca? ¿Cómo se ve la lista de problemas pendientes (si está disponible)? Léelos para tener una idea de los posibles problemas y las deudas técnicas de la biblioteca. ¿Qué tan bien cubren la biblioteca las pruebas de unidades? ¿Hay antipatrones conocidos en la base de código? ¿La biblioteca está bien documentada? ¿Hay muchos comentarios _fixme_ en la base de código?
Código abierto versus código cerrado	Si una biblioteca es de código abierto, será más fácil depurar los problemas que con el código cerrado, ya sea que los problemas estén en tu código o en el código de la biblioteca. Minimiza las dependencias de código cerrado y aplica un escrutinio adicional durante su evaluación. ¿Hay buenas alternativas que se ajusten a tu caso de uso? ¿Qué acuerdos de nivel de servicio están disponibles para las bibliotecas de código cerrado? Si decides usar una dependencia de código cerrado, prepárate para escribir casos de prueba adicionales para ayudar a limitar los riesgos.

Ejecuta una compilación

Compila tu proyecto. Busca nuevos errores o advertencias. Si puedes identificar qué biblioteca los causa, ten en cuenta que es un riesgo actualizarla.

Si ves advertencias de depreciación nuevas, agrégalas como riesgos específicos para la biblioteca que las produce. Se pueden quitar en versiones posteriores. Si deseas seguir usando esa biblioteca, dedica tiempo a realizar la conversión del uso de las APIs obsoletas a sus reemplazos, o bien toma nota de las bajas para tener en cuenta esas funciones y si se quitan más adelante.

Cómo usar lint para detectar problemas de API

Android lint puede detectar muchos problemas en tu aplicación, incluidos algunos que son producto del cambio de versiones de dependencias o del SDK de Android. Por ejemplo, si actualizas tu compileSdk y usas sus APIs nuevas, lint informa aquellas que no están disponibles en versiones anteriores del SDK.

Lint se ejecuta en el editor de Android Studio e informa problemas a medida que realizas cambios. Sin embargo, por lo general, no se ejecuta como parte de tu compilación en Studio ni cuando ejecutas una compilación de línea de comandos, a menos que uses los destinos build o lint.

Si usas integración continua (CI), ejecuta gradlew build o gradlew lint durante las compilaciones de CI (o al menos en las compilaciones nocturnas) para detectar estos tipos de errores.

Si no usas CI, asegúrate de ejecutar gradlew lint al menos ocasionalmente.

Nota: Las reglas de lint generales y a nivel del SDK de Android se entregan con AGP, y las reglas específicas de la biblioteca se empaquetan con sus bibliotecas. Mantén AGP y las dependencias de tu biblioteca lo más actualizadas posible para asegurarte de que se apliquen las reglas de lint más recientes a tu código. Esto es especialmente importante para las nuevas reglas de lint que se agregaron o actualizaron para una nueva versión del SDK de Android.

Presta especial atención a los errores y las advertencias de lint. Algunas bibliotecas se envían con sus propias verificaciones de lint, lo que ayuda a garantizar el uso adecuado de su API. Algunas versiones nuevas de una biblioteca incluyen advertencias y errores de lint nuevos, lo que genera informes nuevos cuando compilas.

Mitiga los riesgos

Después de determinar los riesgos de la actualización, decide cómo quieres mitigarlos:

• Acepta algunos riesgos tal como están. Algunos riesgos son lo suficientemente bajos como para ser aceptables, sobre todo cuando el tiempo y los recursos de actualización son limitados.
• Rechaza algunos riesgos de forma definitiva. Algunas actualizaciones pueden parecer demasiado riesgosas, en especial si tienes un tiempo o recursos limitados para mitigarlas en este punto. Si necesitas priorizar, enfócate en las actualizaciones que sean necesarias para los errores que encontraste o las funciones nuevas que necesites.
• Mitiga los riesgos restantes
  • Considera agrupar las actualizaciones en conjuntos de cambios más pequeños e independientes. Esto reduce el riesgo general y permite la reversión parcial.
  • Investiga los cambios en detalle.
  • Prueba tu app para verificar si hay cambios inesperados. Agrega pruebas nuevas cuando sea necesario para generar confianza en la actualización.
  • Consulta la fuente (si está disponible) cuando encuentres algo dudoso.
  • Realiza los cambios necesarios en tu fuente o compilación.

Documenta tus decisiones. Si los riesgos de una actualización se convierten en problemas cuando se ejecuta la aplicación, la documentación del análisis de riesgos puede reducir el análisis de errores necesario.

Valida las licencias

Los desarrolladores de bibliotecas obtienen las licencias de las bibliotecas para su uso. Debes cumplir con las condiciones de la licencia o no podrás usar la biblioteca. Algunas licencias son muy permisivas y, a menudo, solo requieren la atribución de la biblioteca y muestran el texto de su licencia a los usuarios finales. Algunas se consideran virales. Si usas esas bibliotecas, debes aplicar la misma licencia a tu aplicación o biblioteca.

Las licencias pueden cambiar con cualquier versión. Cada vez que realices la actualización, deberás verificar que las dependencias que usas tengan una licencia compatible con tu aplicación o biblioteca.

Si una licencia no es compatible (o cambió para dejar de serlo), no puedes usar esa versión de la biblioteca. Puedes hacer lo siguiente:

• Comunícate con el propietario de la biblioteca y solicita la continuación de la licencia existente o la licencia doble para seguir permitiendo la licencia anterior.
• Trabaja con tu equipo legal para determinar si puedes cambiar tu licencia para que sea compatible.
• Busca otra biblioteca con una licencia compatible y modifica tu aplicación según sea necesario.
• Crea una bifurcación de la última versión compatible de la biblioteca (si esa licencia permite derivados y los cambios no son retroactivos) y realiza tus propios cambios.