La mejor plataforma de CI/CD para apps Android suele ser la que ya usas, porque los builds de Android solo necesitan Linux, Java, el SDK de Android y Gradle. Las diferencias entre plataformas aparecen en el build: cómo guardan tu keystore, cómo hacen el upload a los tracks de Google Play, cuánto acelera el caché de Gradle los builds repetidos y si la misma plataforma también gestiona iOS. Esta comparativa cubre GitHub Actions, GitLab CI, Bitrise, Codemagic, Appcircle, CircleCI, Azure DevOps y Capgo Build.
El flujo de release de Android en 2026
Todos los pipelines de Android hacen más o menos lo mismo:
- Instalar un JDK y el SDK de Android (o usar una imagen que ya los incluya).
- Ejecuta
./gradlew bundleRelease. - Firmar el AAB con tu subir clave.
- Subirlo a un track de Play Console (interno, cerrado, abierto o producción) mediante la API de Google Play Developer.
- Opcionalmente, desplegarlo a un porcentaje de usuarios.
Reglas que todas las plataformas deben respetar:
- El AAB es obligatorio para apps nuevas en Google Play, y Google vuelve a firmar los APK entregados con la clave de firma de la app que posee (Play App Signing).
- El nivel objetivo de API sube cada año. Google aumenta el mínimo
targetSdkVersionpara actualizaciones cada agosto. Capacitor 8 ya apunta a API 36. - tamaños de página de 16 KB. Los dispositivos más nuevos usan páginas de memoria de 16 KB, y Play exige que las librerías nativas en apps actualizadas las soporten. Ver Páginas de 16 KB en Android para plugins de Capacitor.
- JDK 21 es la base para proyectos de Capacitor 7 y 8 y versiones recientes de Android Gradle Plugin.
Matriz de funciones
| Plataforma | Runners | Almacenamiento de keystore | Subida a Play | Caché de Gradle | iOS también | Modelo de precios |
|---|---|---|---|---|---|---|
| Acciones de GitHub | Linux alojado, autoalojado | Secretos cifrados | fastlane, Gradle Play Publisher o acciones de la comunidad | gradle/actions/setup-gradle |
Sí, runners de macOS | Por minuto, Linux es el más barato; gratis para repos públicos |
| GitLab CI | Linux alojado, autogestionado | Variables CI/CD, archivos seguros | fastlane, integración con Google Play | cache: claves |
Sí, macOS beta | Minutos de cómputo por plan |
| Bitrise | Stacks de Linux alojados | Archivos de firma de code gestionados | Paso de despliegue en Google Play | Pasos de caché integrados | Sí | Créditos por minuto de build |
| Codemagic | Linux y Mac alojados | Referencias de keystore con nombre | Integrado, tracks y fracción de rollout | Integrado | Sí | Planes por minuto o anuales |
| Appcircle | Servidor alojado o self-hosted | Almacén de identidades de firma | Módulo de publicación | Integrado | Sí | Niveles de plan, enterprise self-hosted |
| CircleCI | Linux alojado (cimg/android), autoalojado |
Contextos y variables de entorno | fastlane o scripts | save_cache/restore_cache |
Sí | Créditos por minuto |
| Azure DevOps | Alojado por Microsoft, autoalojado | Archivos seguros | Tarea de la extensión de Google Play | Cache@2 |
Sí | Jobs en paralelo |
| Build de Capgo | Gestionado por Capgo, invocado desde cualquier CI | Enviado desde los secrets de tu CI en cada build | Integrado, flags de track y status | Caché de build por app | Sí | Minutos de build, ver precios |
Xcode Cloud no está en la tabla porque solo compila para plataformas Apple. Capgo Build solo hace build de apps Capacitor; el resto de plataformas de aquí también compilan proyectos nativos en Kotlin y Java.
Plataforma por plataforma
Acciones de GitHub
Runners de Linux con Java y el SDK de Android preinstalado en ubuntu-latest, así que ./gradlew bundleRelease funciona tras actions/setup-java. gradle/actions/setup-gradle gestiona bien el caché de Gradle. Los tests de emulador corren en runners de Linux con KVM mediante community actions como reactivecircus/android-emulator-runner.
Firmar implica decodificar el keystore desde un secreto y pasar las contraseñas mediante propiedades de Gradle. El upload utiliza fastlane supply, el plugin Gradle Play Publisher o una community action. No se gestiona nada, pero tampoco hay nada oculto, y los minutos de Linux son los más baratos que encontrarás. Guía: Build automático de Capacitor Android con GitHub Actions.
GitLab CI
Lo mismo en GitLab: cualquier imagen Docker con el SDK de Android funciona en runners de Linux compartidos. Las funciones de Mobile DevOps de GitLab incluyen secure files para keystores y una integración con Google Play que expone la service account a los jobs, lo que elimina parte del boilerplate en las configuraciones de fastlane. Guía: Build automático de Capacitor para Android en GitLab.
Bitrise
El soporte de Android en Bitrise se centra en steps: Android Build, Android Sign, Google Play Deploy, además de steps de test y emulador. Los keystores se suben una vez en los settings de signing de code de la app. El step de Google Play Deploy soporta tracks y fracciones de staged rollout. Pagas con créditos, así que los builds de Android son más baratos que iOS pero más caros que un runner de Linux puro. Ideal para equipos mobile que buscan un editor de workflow basado en UI.
Codemagic
Codemagic almacena los keystores como referencias con nombre que codemagic.yaml apuntan a ellos, así que el archivo nunca aparece en tu repo ni en logs. El google_play bloque de publicación define el track, el porcentaje de rollout y si se envía como borrador. Compila Android nativo, Flutter, React Native, Ionic y Capacitor. La facturación es por minuto de build o plan anual fijo.
Appcircle
Appcircle almacena los keystores en su módulo de identidades de firma y publica en Google Play a través de su flujo de publicación, junto con la distribución a testers y una app store empresarial. La opción de Appcircle Server autoalojado es la principal razón por la que los equipos regulados lo eligen: code y las claves nunca salen de su red.
CircleCI
CircleCI publica cimg/android imágenes Docker con el SDK instalado, además de un orb de Android con helpers para pruebas de emulador y caché. La firma y la subida son scripts o fastlane. La facturación usa créditos, y los ejecutores Docker de Linux son las clases de recursos más baratas. Una opción razonable cuando CircleCI ya ejecuta el resto de tu stack.
Azure DevOps
Azure Pipelines tiene tareas de primera parte para cada paso: Gradle@3 para compilar, AndroidSigning@3 para firmar y zipalign, proteger los archivos para el keystore y la tarea de release de la extensión de Google Play para subidas a tracks y rollouts escalonados. El precio es por job en paralelo. Es el lugar natural para equipos que usaban los builds de Android de App Center.
Build de Capgo
Build de Capgo es un servicio de build para apps Capacitor al que llama tu CI. El job se ejecuta bun run build y bunx cap sync android, luego:
bunx @capgo/cli@latest build request com.example.app \
--platform android \
--build-mode release \
--android-track internalCapgo ejecuta Gradle en sus máquinas de build, firma con tu keystore, lee la versión más alta versionCode de Google Play, la incrementa y sube el AAB al track que elegiste. --android-release-status, --android-flavor, y --submit-to-store-review controlan el resto. Para builds de APK fuera de Google Play (dispositivos kiosk, MDM), --no-playstore-upload --output-upload devuelve un link de descarga en su lugar.
La configuración es guiada: bunx @capgo/cli@latest build init --platform android crea o importa el keystore, y puede provisionar la cuenta de servicio de Google Cloud y la invitación de Play Console con el inicio de sesión de Google, el paso en el que la mayoría de los equipos se equivoca al hacerlo a mano.
Para ser justos: Android es la plataforma donde Capgo Build ahorra menos, porque los runners de Linux son baratos en todas partes. Su valor en Android es la consistencia con el pipeline de iOS, los códigos de versión automáticos, sin mantenimiento de SDK de Android ni del JDK en CI, y el mismo CLI de envío actualizaciones en vivo para cambios solo de web. Una sola build tiene un límite de 10 minutos.
Problemas en Android y cómo los maneja cada plataforma
Pérdida de keystore
Antes, perder el keystore significaba que nunca más podrías actualizar la app. Con Play App Signing, el keystore que tienes es solo la clave de carga, y el soporte de Play Console puede registrar una nueva clave de carga. Aun así, mantén una copia de seguridad offline. Todas las plataformas de arriba guardan el keystore cifrado; el riesgo suele ser la copia en el portátil de un desarrollador. Si necesitas uno nuevo, el Generador de keystore para Android lo crea en el navegador.
Colisiones de versión code
Play rechaza una subida cuyo versionCode ya se había usado. Opciones: derivarlo del número de ejecución de CI (GitHub, GitLab, CircleCI), usar la variable de número de build de la plataforma (Bitrise, Codemagic, Appcircle) o dejar que Capgo Build lea el valor más reciente de Play y lo incremente.
Builds de Gradle lentos
Una Capacitor Android build desde cero descarga cientos de megabytes de dependencias. El caching ~/.gradle/caches y ~/.gradle/wrapper hace que los builds repetidos sean mucho más rápidos. Dale suficiente memoria a Gradle en gradle.properties (org.gradle.jvmargs=-Xmx4g) en runners alojados, y compila iOS y Android en jobs en paralelo en lugar de uno tras otro.
Actualizaciones de plugins y AGP
Las nuevas versiones de Android Gradle Plugin rompen plugins antiguos. Fija la versión de AGP en tu proyecto y actualiza en una rama. Los fixes específicos están en Corrige errores de build del plugin Capacitor con AGP 9 y Cómo resolver errores de build de Android en Capacitor.
Permisos de la service account de Play
“The caller does not have permission” es el error de upload más común. La service account debe estar invitada en Play Console en Usuarios y permisos con permisos de release para la app, y la API de Google Play Android Developer debe estar habilitada en su proyecto de Google Cloud. Las nuevas service accounts pueden tardar un poco antes de que la API las acepte.
Cómo elegir
| Tu situación | Ideal para ti |
|---|---|
| Solo Android, ya en GitHub o GitLab | GitHub Actions o GitLab CI |
| Equipo nativo de Android que busca un editor visual de workflows | Bitrise |
| Equipo multiplataforma que quiere keystores gestionados y publicación en Play mediante YAML | Codemagic |
| Debe autoalojar todo | Servidor de Appcircle o runners autoalojados |
| Proveniente de App Center, stack de Microsoft | Azure DevOps |
| Tu app Capacitor, quieres Android e iOS con un solo CLI desde cualquier CI | Build de Capgo |
Para la misma decisión en iOS, lee Comparativa de plataformas CI/CD para apps de iOS. Para apps Capacitor en concreto, incluidas las live updates, consulta Comparativa de plataformas CI/CD para apps Capacitor.
Checklist rápido antes de migrar
- Confirma que tienes el archivo keystore de upload y las dos contraseñas, y que el alias coincide.
- Revisa en Play Console qué certificado está registrado como upload key y compara su SHA-1 con
keytool -list -v -keystore release.jks. - Crea una service account dedicada para el nuevo CI en lugar de reutilizar una personal.
- Asegúrate de que la nueva plataforma compile con JDK 21 para los proyectos Capacitor 8.
- Sube una vez al track interno antes de cambiar los releases de producción.
