Actualiza las versiones de las dependencias

Nota: Antes de actualizar tus dependencias, considera habilitar la verificación de dependencias para verificar las dependencias que descargas y que incluyes en tu proyecto.

La actualización de las dependencias te brinda acceso a sus funciones, correcciones de errores y mejoras más recientes. 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 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 a 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 compilas una aplicación, tu objetivo debe ser mantenerla actualizada y estable. Si compilas una biblioteca, tu enfoque debe estar en las aplicaciones de otros desarrolladores. Tus 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 previas 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, tus consumidores no necesitan actualizarla a la siguiente versión de major o minor, a menos que quieran funciones nuevas. 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 una actualización de una de tus dependencias contiene un cambio importante en la API, es probable que quieras actualizarla en una versión major o minor y hacer 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 Hay menos tiempo para actualizar. 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. Si usas complementos o herramientas que ayudan a automatizar las actualizaciones de dependencias, 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 se lancen versiones más recientes de las dependencias 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 correcció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? ¿Tus ingenieros de software mantienen la compilació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 en 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): Es la herramienta que se usa 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, la API del complemento de Gradle cambia. 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 periódicas 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	Si usas complementos o herramientas que ayudan a automatizar las actualizaciones de dependencias, asegúrate de analizar los resultados para detectar 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: Entabla 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 de 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 de SDK, el NDK y el JDK. Si desarrollas un complemento de Gradle (para uso interno o público) que extiende o usa datos de AGP, verifica si necesitas actualizarlo. 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, haz lo siguiente: Configura el complemento de Gradle del 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 de KSP (como el compilador de Room, que aparece como una dependencia ksp en tus archivos de compilación). El complemento de 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 obtener 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, verifica si hay cambios de lenguaje o fallas en 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. A veces, cambiar la versión del compilador de Kotlin 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. 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 de minSdk especificados en las dependencias de tu biblioteca y en 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 que encuentres 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. Cada vez que actualices los 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 especial 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 a menudo contiene cambios importantes que debes realizar en tu aplicación. Debes actualizar targetSdk para cumplir con los requisitos de Play Store. La actualización de compileSdk es opcional y te brinda acceso a nuevas APIs. 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. Esto incluye herramientas nuevas y mejoradas para los SDKs nuevos. 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 de Java en tu aplicación para Android, te recomendamos que aproveches las APIs de Java más recientes. Cada versión del SDK de Android admite un subconjunto de APIs de Java y funciones del lenguaje. AGP proporciona compatibilidad con versiones anteriores del SDK de Android mediante un proceso llamado expansion 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 de Java. El uso de JDK se especifica en varios lugares de tus secuencias de comandos de compilación. Consulta Versiones de Java en compilaciones de Android para obtener más información.

Análisis de actualización

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?

• ¿Debo cambiar el código para los cambios de 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 complementos o herramientas que ayudan a automatizar las actualizaciones de dependencias, 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 des por sentado 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 antes y después y compararlas.

Precaución: Dependency Guard es un complemento de Gradle de terceros. Es posible que los agentes maliciosos comprometan complementos externos con ataques de intermediario o a través de un servidor de desarrollo hackeado. Te recomendamos que habilites la verificación de dependencias para verificar las dependencias que descargas y, luego, incluyes en tu proyecto.

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

  • Para tratar las advertencias como errores, agrega

  android {
      // ...
      lint {
          warningsAsErrors = true
      }
  }
  

  a tu build.gradle.kts en cada módulo.

  • O bien, si tienes muchas advertencias existentes, crea un modelo de referencia de lint de Android. Con el tiempo, asegúrate de limpiar las advertencias existentes (o suprimir las que no te interesan).

• Compilador de Kotlin: Habilita -Werror para que trate todas las advertencias como errores. Consulta Cómo definir opciones.

• Otras herramientas: Si usas otras herramientas de análisis estático que admiten el seguimiento de los modelos de referencia, configura sus modelos de referencia.

Los modelos de referencia de advertencias facilitan la visualización de las advertencias nuevas que se introducen a medida que actualizas tus dependencias. Puedes ver los cambios en las dependencias y sus versiones con 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 del 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 los modelos de referencia de advertencia, 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 posibles riesgos 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, la versión principal cambió. 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	Es posible que algunas versiones de bibliotecas incluyan 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 alfa, de desarrollo o experimentales, algunas bibliotecas incluyen APIs marcadas como experimentales o inestables. Si es posible, evita esas APIs. Si necesitas usarlas, asegúrate de registrar tu uso y de detectar cambios o eliminaciones en versiones posteriores.
Comportamiento dinámico	Algunas bibliotecas se comportan de forma diferente según factores externos. Por ejemplo, una biblioteca que se comunica con un servidor depende de los cambios en ese servidor. ¿La biblioteca debe coincidir con una versión específica 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 puede 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	Comprueba si la biblioteca tiene una guía de migración. Esto puede reducir significativamente tu análisis de riesgos y 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 enfocó en la compatibilidad y consideró tu mitigación de actualización.
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.
Archivos readme	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 de la lista 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 este proceso puede tardar mucho tiempo en ejecutarse. Precaución: Dependency Check es un complemento de Gradle de terceros. Es posible que los actores maliciosos comprometan los complementos externos con ataques de intermediario o a través de un servidor de desarrollo hackeado. Te recomendamos que habilites la verificación de dependencias para verificar las dependencias que descargas y que incluyes en tu proyecto.
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 resolver sus conflictos. 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 incluir 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)? Revísala para tener una idea de los posibles problemas y la deuda técnica 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 frente a 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 errores o advertencias nuevos. 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 quieres 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.

Usa lint para detectar problemas de API

Android lint puede detectar muchos problemas en tu aplicación, incluidos algunos que son el resultado de cambiar las versiones de las dependencias o el 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 y, a medida que realizas cambios, informa los problemas. 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, de vez en cuando.

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 nuevas advertencias y errores de lint, lo que genera informes nuevos cuando realizas la compilación.

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 recursos o tiempo limitados para mitigarlas en este momento. Si necesitas hacer una clasificación, enfócate en las actualizaciones necesarias para los errores que encontraste o las funciones nuevas que necesitas.
• 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 la 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 las bibliotecas otorgan licencias para que las uses. 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 la visualización del texto de su licencia para 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 una actualización, debes 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 podrás 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.