Mejores plataformas CI/CD para apps Android en 2026, comparadas

La mejor plataforma de CI/CD para apps de 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 torno al build: cómo guardan tu keystore, cómo suben a los tracks de Google Play, cuánto acelera el caché de Gradle los builds repetidos y si la misma plataforma también se encarga de 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:

1. Instalar un JDK y el SDK de Android (o usar una imagen que ya los incluya).
2. Ejecutar ./gradlew bundleRelease.
3. Firmar el AAB con tu clave de upload.
4. Subirlo a un track de Play Console (interno, cerrado, abierto o producción) mediante la API de Google Play Developer.
5. Opcionalmente, lanzarlo 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 app signing key que posee (Play App Signing).
• El nivel objetivo de API sube cada año. Google sube el mínimo targetSdkVersion para 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 Tamaño de página 16 KB en Android para plugins de Capacitor.
• JDK 21 es la base para proyectos Capacitor 7 y 8 y versiones recientes de Android Gradle Plugin.

Matriz de funciones

Xcode Cloud no está en la tabla porque solo compila para Apple. Capgo Build solo compila apps Capacitor; el resto de plataformas 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 con 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 se oculta nada, 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 archivos seguros para keystores e integración con Google Play que expone la service account a los jobs, eliminando boilerplate en las configuraciones de fastlane. Guía: Build automático de Capacitor 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 la app code. El step de Google Play Deploy soporta tracks y staged rollouts. 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 apunta, por lo que el archivo nunca aparece en tu repositorio ni en los logs. El google_play bloque de publicación define el track, el porcentaje de rollout y si se envía como borrador. Compila apps nativas de Android, Flutter, React Native, Ionic y Capacitor. La facturación es por minuto de build o con un plan anual fijo.

Appcircle

Appcircle almacena los keystores en su módulo de signing identities y publica en Google Play mediante su flujo de publicación, además de distribución para testers y una enterprise app store. La opción self-hosted de Appcircle Server es la razón principal por la que los equipos regulados lo eligen: code y las keys nunca salen de su red.

CircleCI

CircleCI publica cimg/android imágenes de Docker con SDK instalado, además de un Android orb con helpers para tests en emuladores y caching. El signing y el upload se hacen con 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 si CircleCI ya ejecuta el resto de tu stack.

Azure DevOps

Azure Pipelines incluye tareas propias para cada paso: Gradle@3 para el build, AndroidSigning@3 para firmar y zipalign, asegurar archivos del keystore y la tarea de release de la extensión de Google Play para subidas a tracks y rollouts progresivos. El precio es por job paralelo. Es la opción ideal 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 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 internal

Capgo ejecuta Gradle en sus máquinas de build, firma con tu keystore y lee la versión más alta versionCode de Google Play para incrementarla y sube el AAB al track que elegiste. --android-release-status, --android-flavor, y --submit-to-store-review controlas 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 aprovisionar la cuenta de servicio de Google Cloud y la invitación de Play Console mediante Google sign-in, que es el paso que la mayoría de los equipos suele hacer mal manualmente.

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, códigos de versión automáticos, sin mantenimiento de Android SDK o JDK en CI, y el mismo CLI para el envío live updates para cambios solo web. Un solo build está limitado a 10 minutos.

Puntos críticos en Android y cómo los gestiona cada plataforma

Pérdida del Keystore

Perder el keystore solía significar que nunca más podrías actualizar la app. Con Play App Signing, el keystore que posees es solo la upload key, y el soporte de Play Console puede registrar una nueva. Aun así, mantén un backup offline. Todas las plataformas anteriores guardan el keystore cifrado; el riesgo suele ser la copia en el laptop de un desarrollador. Si necesitas uno nuevo, el generador de Android keystore lo crea en el navegador.

Colisiones de versión code

Play rechaza un upload cuyo versionCode ya fue utilizado. Opciones: derivarlo del número de ejecución de CI (GitHub, GitLab, CircleCI), usar la variable de build number de la plataforma (Bitrise, Codemagic, Appcircle), o dejar que Capgo Build lea el último valor de Play y lo incremente.

Builds lentos de Gradle

Una Capacitor Android Native 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 a Gradle suficiente memoria 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 el AGP en tu proyecto y actualiza en una rama. Los fixes específicos están en Corrige los 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 publicación para la app, y la Google Play Android Developer API debe estar habilitada en su proyecto de Google Cloud. Las nuevas service accounts pueden tardar un poco antes de que API las acepte.

Cómo elegir

Para la parte de iOS de la misma decisión, lee Comparativa de plataformas CI/CD para apps de iOS. Para apps Capacitor específicamente, incluyendo 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 ambas 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 haga build con JDK 21 para proyectos Capacitor 8.
• Realiza un upload al track interno antes de pasar a producción.