Los staged rollouts de Google Play lanzan un nuevo Android App Bundle a un porcentaje de usuarios en una vía antes de alcanzar el 100%. Úsalos en Producción, Testing abierto, y Pruebas cerradas para limitar el radio de impacto mientras vigilas crashes y valoraciones. Pruebas internas es para pruebas rápidas con hasta 100 testers y no es lo mismo que un rollout porcentual de producción. Para Capacitor apps, combina los rollouts de la tienda con canales de Capgo y rollouts progresivos cuando necesites entregas porcentuales de actualizaciones web en vivo entre releases de la tienda.
Tracks de Play Console en 2026
Google documenta cuatro superficies de release:
| Track en Play Console | Quién recibe los builds | Porcentaje de rollout gradual |
|---|---|---|
| Pruebas internas | Hasta 100 testers invitados | Sin rollout gradual por porcentaje (entrega completa del track a los testers) |
| Pruebas cerradas | Listas de email o Google Groups que elijas | Sí |
| Testing abierto | Cualquiera que se una desde tu ficha de la tienda | Sí |
| Producción | Usuarios elegibles en países seleccionados | Sí (segmentación por país disponible en producción) |
Fuente: Preparar y lanzar una versión y Configurar una prueba abierta, cerrada o interna.
Flujo típico: Pruebas internas para smoke tests, Pruebas cerradas para grupos beta de confianza, Testing abierto para obtener más feedback, y luego Producción con un porcentaje escalonado.
Cómo funciona un staged rollout en Play
El Lanza actualizaciones de apps con staged rollouts guía describe el ciclo:
- Abrir Producción, Testing abierto, o Pruebas cerradas en Play Console.
- Crea o edita una versión y sube un Android App Bundle cuyo
versionCodees superior a la versión ya disponible en ese canal. Play entrega la versión más compatible másversionCodeen cada track para el que el usuario sea elegible, de modo que un build de Production más reciente pueda sobrescribir uno de un track de testing inferior para ese mismo usuario. - Configura un porcentaje de rollout (entre el 1% y el 100%).
- Inicia el rollout.
- Monitorea Android vitals, crashes y reseñas.
- Aumentar el porcentaje, detener, o reanudar el rollout desde la pestaña Releases (Gestionar rollout).
- Promociona al 100% cuando las métricas se vean bien.
Restricciones importantes de la documentación de Google:
- Google elige a los usuarios del rollout; no puedes seleccionar individuos manualmente desde la consola.
- Finaliza o descarta las releases en borrador en conflicto en un track antes de iniciar otro rollout; Google documenta la creación de un nuevo staged rollout antes de que la release anterior llegue al 100%.
- No puedes forzar la instalación inmediata; los usuarios actualizan cuando Play entrega la release.
- Los staged rollouts de producción pueden dirigirse a países o regiones específicos; los canales de prueba siguen las reglas de testers del canal.
El Consola de Google Play Developer API mapea los IDs de las pistas (production, beta para pruebas abiertas, qa para pruebas internas, además de pistas cerradas con nombre) si automatizas los lanzamientos.
Qué vigilar durante el rollout
| Señal | Dónde buscar |
|---|---|
| Tasa de crashes (tras la instalación) | Android vitals de Play Console |
| ANRs (tras la instalación) | Android vitals de Play Console |
| Checks previos (antes del despliegue masivo) | Reporte de pre-lanzamiento en Play Console |
| Reseñas de usuarios | Feedback de la ficha de la tienda |
| Errores de backend | Tus dashboards de API con headers de versión |
Espera suficiente entre saltos de porcentaje para obtener datos. Google sugiere monitorear antes de expandir; muchos equipos esperan al menos un día en los primeros porcentajes.
Si se despliega un bug nativo, detener detén el rollout de Play y publica un bundle corregido con un versionCode. Play no hace rollback automático de los binarios.
canales de Capgo y rollouts por porcentaje (live updates)
Los rollouts de la Store cambian el shell nativo que los usuarios descargan de Play. Capgo gestiona actualizaciones en vivo de bundles web dentro de una app Capacitor ya instalada.
- Canales mapear dispositivos a flujos de actualización (
production,beta, nombres personalizados). Puedes forzar IDs de dispositivo específicos a un canal al depurar. - Despliegues progresivos mantener un versión estable de fallback bundle en el canal mientras un objetivo de rollout alcanza un configurado porcentaje configurado de dispositivos. Aumenta, disminuye, pausa, completa o revierte sin lanzar un nuevo build de Play para arreglos en la capa web.
Usa los staged rollouts de Play cuando cambies code nativo, permisos o targetSdkVersionUsa rollouts de Capgo % cuando el fix esté en HTML, CSS o JavaScript y tu revisión de cumplimiento permita la entrega vía OTA.
Estrategia combinada sugerida
- Lanza cambios nativos mediante Pruebas internas, luego Cerrado o Testing abierto, luego un Producción lanzamiento gradual.
- Apunta los dispositivos de producción a un canal Capgo estable para correcciones web diarias.
- Ejecuta un lanzamiento progresivo en un canal cuando quieras bundles web canary con un fallback estable automático.
- Detén el rollout de Play si los vitals empeoran; revierte el rollout progresivo de Capgo si las métricas web caen.
Recordatorio de reglas y requisitos
- Cada nuevo bundle necesita un número mayor
versionCodeque las builds que los usuarios ya pueden recibir en cualquier track superpuesto. - Las apps que usan Play App Signing deben subir AABs firmados según Firma de aplicaciones de Google Play.
- Completa los lanzamientos escalonados pendientes o descarta borradores antes de iniciar lanzamientos en conflicto en el mismo track (Prepara y lanza una versión).
FAQ
¿El testing interno usa porcentajes?
No. El testing interno distribuye la versión a tu lista de testers (hasta 100 personas). Usa Closed, Open o Production para rollouts escalonados por porcentaje.
¿Cómo instalan los testers las builds de Internal o Closed?
Las pruebas internas usan una lista de correos (hasta 100 testers). Las pruebas cerradas admiten listas de correos, Google Groups o la gestión de organizaciones de Play Console. Las pruebas abiertas son el único canal que ofrece un programa de registro público en tu ficha de la tienda. Los testers en canales internos o cerrados suelen necesitar la URL de Play Store que compartas; no encontrarán el build mediante una búsqueda a menos que uses pruebas abiertas o producción.
¿Cuándo deberían los equipos de Capacitor usar Capgo en lugar de lanzar el rollout de Play?
Cuando el cambio se limite a assets web y cumpla con tu checklist de cumplimiento de la tienda. Las actualizaciones de plugins nativos, cambios en el manifest y cambios de permisos siguen requiriendo un nuevo release en Play.
Continuar con Google Play Staged Rollouts: Cómo funciona
Si estás usando Implementaciones por fases de Google Play: Cómo funciona para planificar la aprobación y distribución en la tienda, conéctalo con @capgo/capacitor-in-app-review para el detalle de implementación en @capgo/capacitor-in-app-review, Usando @capgo/capacitor-in-app-review para la capacidad nativa en «Usando @capgo/capacitor-in-app-review», @capgo/capacitor-native-market para los detalles de implementación en @capgo/capacitor-native-market, Usando @capgo/capacitor-native-market para la capacidad nativa en Uso de @capgo/capacitor-native-market, y Capacitor OTA Updates: Guía de aprobación de la App Store para el contexto práctico en Capacitor OTA Updates: Guía de aprobación de la App Store.
