AppInitDev Academy · Android avanzado · Nivel intermedio

CI para Android con Gradle y GitHub Actions

Automatiza compilación y pruebas mientras proteges secretos y firma de producción.

← Ver todos los temas

Guía formativa completa · Actualizada el 9 de noviembre de 2026

Esta unidad comprende cuatro subtemas, un ejemplo, notas de implementación, una práctica y referencias oficiales. Los ejemplos son demostraciones pedagógicas, no implementaciones auditadas de AppInitDev.

Nota editorial. Este material distingue hechos documentados, un ejemplo elaborado para aprender y recomendaciones de implementación. Las referencias numeradas llevan a las fuentes primarias; los escenarios con dominios ficticios y datos simulados no representan una auditoría en producción. Comprueba versiones, políticas, permisos y respuestas reales antes de aplicar cambios.

1. Pipeline mínimo de calidad

Un flujo CI compila el proyecto tras cada cambio y ejecuta tests que no necesiten dispositivo. Bloquea la integración cuando la compilación falla, pero no confundas build correcto con calidad de producto. Versiona el wrapper de Gradle y mantén reproducibles las dependencias. Usa un entorno sin credenciales de producción para solicitudes de terceros no confiables. [1]

Ejemplo contextualizado: Una petición de cambios ejecuta verificación de formato, tests unitarios y ensamblado debug.

Nota de estudio: antes de pasar al siguiente apartado, formula en una frase cuál es el problema que este mecanismo resuelve y en qué situación no deberías aplicarlo. Si no puedes explicarlo, contrasta el caso con la documentación enlazada.

2. Cache y reproducibilidad

Una caché acelera compilaciones, pero una clave inadecuada puede reutilizar artefactos obsoletos. Comprueba versiones de JDK, Gradle, Android Gradle Plugin y SDK. Evita descargas silenciosas en scripts de terceros. Si un fallo solo ocurre en CI, registra el entorno antes de modificar código para forzarlo a pasar. [1]

Ejemplo contextualizado: La compilación local y CI usan el mismo wrapper, con JDK y variantes documentadas.

Nota de estudio: antes de pasar al siguiente apartado, formula en una frase cuál es el problema que este mecanismo resuelve y en qué situación no deberías aplicarlo. Si no puedes explicarlo, contrasta el caso con la documentación enlazada.

3. Manejo de secretos

No escribas claves de firma en el repositorio ni las imprimas en logs. Separa permisos de lectura, compilación y publicación. Cuando una acción necesite credenciales, limita su alcance y considera aprobaciones antes del despliegue. Revisa las dependencias de acciones y fija versiones o referencias verificables. [2]

Ejemplo contextualizado: El workflow de PR no dispone de credenciales para publicar una app en producción.

Nota de estudio: antes de pasar al siguiente apartado, formula en una frase cuál es el problema que este mecanismo resuelve y en qué situación no deberías aplicarlo. Si no puedes explicarlo, contrasta el caso con la documentación enlazada.

4. Evidencias y artefactos

Guarda resultados de tests y paquetes de depuración por tiempo limitado. Añade una explicación de cómo reproducir un fallo. Antes de subir a Play, realiza controles manuales y de cumplimiento que CI no puede automatizar completamente. Documenta cómo se revierte un cambio de dependencia o configuración. [2]

Ejemplo contextualizado: El resumen de ejecución presenta casos aprobados, fallidos y cambios de versión relevante.

Nota de estudio: antes de pasar al siguiente apartado, formula en una frase cuál es el problema que este mecanismo resuelve y en qué situación no deberías aplicarlo. Si no puedes explicarlo, contrasta el caso con la documentación enlazada.

Ejemplo técnico comentado

Este fragmento resume el concepto de la unidad. Utilízalo solo como punto de partida: comprueba dependencias, sintaxis contextual y seguridad antes de incorporarlo a un proyecto real.

steps:
  - uses: actions/checkout@v4
  # Agregar setup-java y ./gradlew test conforme a la guía oficial

Laboratorio guiado y evidencias

  1. Preparar: elige una pantalla, archivo o proyecto pequeño que no contenga datos reales; anota requisitos y versión del entorno.
  2. Implementar: reproduce el ejemplo central del tema y registra cada decisión que tomaste.
  3. Probar: ejecuta un caso correcto, uno erróneo y otro límite; compara lo esperado con lo observado.
  4. Contrastar: revisa las dos fuentes numeradas y anota al menos una condición que el ejemplo simplificado omite.
  5. Entregar: genera una tabla con las entradas, capturas o logs sin datos personales, hallazgos y siguientes acciones.

Rúbrica: 25 % explicación del concepto, 25 % reproducción del caso, 25 % pruebas y límites, 25 % evidencia y referencias. Es una rúbrica educativa, no una certificación.

Preguntas para comprobar el aprendizaje

¿Por qué no basta con copiar el ejemplo y ver que funciona una vez?

Porque faltan casos de error, verificación de entorno y pruebas de los límites documentados. Una sola ejecución no demuestra compatibilidad general.

¿Cómo decidir entre dos estrategias posibles en este tema?

Explica el objetivo, compara riesgos y recursos, consulta las fuentes primarias y conserva los resultados de una prueba repetible.

Fuentes y citas numeradas

Las citas [1] y [2] apuntan a documentación primaria; los ejemplos y actividades son elaboración educativa original de Academy, no citas textuales. Consultadas el 9 de noviembre de 2026.

  1. GitHub Docs. Compilación y pruebas con Gradle en GitHub Actions. Fuente primaria ↗. Consultada: 9 de noviembre de 2026.
  2. Android Developers. Firma y publicación de apps. Fuente primaria ↗. Consultada: 9 de noviembre de 2026.

Tu progreso y notas

El progreso se guarda solo en este navegador. No introduzcas datos sensibles.

Progreso pendiente de guardar.

Continúa aprendiendo

Herramientas locales · Rutas de aprendizaje · Biblioteca de fuentes