Lanzamientos escalonados de Google Play liberan un nuevo paquete de aplicaciones Android a un porcentaje de usuarios en un track antes de alcanzar el 100%. Utilícelos en Producción, Pruebas abiertas, y Pruebas cerradas para limitar el radio de impacto mientras observa los errores y las calificaciones. Pruebas internas es para pruebas rápidas con hasta 100 probadores y no es lo mismo que una implementación porcentual de producción. Para Capacitor aplicaciones, pair las implementaciones de tiendas con Capgo canales y implementaciones progresivas cuando necesitas entrega porcentual de actualizaciones web en vivo entre lanzamientos de tiendas.
Seguimiento en la Consola de Play en 2026
Google documenta cuatro superficies de lanzamiento:
| Seguimiento en la Consola de Play | Quién recibe construcciones | Porcentaje de lanzamiento escalonado |
|---|---|---|
| Pruebas internas | Hasta 100 invitados | No hay porcentaje de lanzamiento escalonado (entrega completa a los probadores) |
| Pruebas cerradas | Listas de correo electrónico o grupos de Google que elijas | Sí |
| Pruebas abiertas | Quienes se unan desde tu lista de productos | Sí |
| Producción | Usuarios elegibles en países seleccionados | Sí (disponible la configuración de país en producción) |
Fuente: Preparar y lanzar una versión y Configurar una prueba interna, cerrada o abierta.
Flujo típico: Pruebas internas para pruebas de humo, Pruebas cerradas para grupos de beta confiables, Pruebas abiertas para comentarios más amplios, luego Producción con un porcentaje de etapa.
Cómo funciona una implementación de etapa de Play
de Google Release app updates with staged rollouts La guía de Google describe el ciclo:
- Abrir Producción, Pruebas abiertaso Pruebas cerradas en la consola de Play.
- Crear o editar una versión y subir un Android App Bundle cuyo
versionCodees mayor que la versión ya disponible en ese canal. Play sirve la versión compatible más altaversionCodeen cada pista a la que un usuario está elegible, por lo que una nueva compilación de Producción puede superar a una compilación de prueba de menor pista para el mismo usuario. - Establecer un porcentaje de lanzamiento (entre 1% y 100%).
- Iniciar el lanzamiento.
- Monitorear Android vitales, errores y reseñas.
- Incrementar el porcentaje, detener, o reanudar la implementación desde la pestaña Releases ("Administrar distribución).
- Promocionar a 100% cuando los métricas parezcan saludables.
Restricciones importantes de la documentación de Google:
- Rollout users are chosen by Google; you cannot hand-pick individuals in the console UI.
- Finalice o descarte las versiones de prueba conflictivas en una pista antes de iniciar otra distribución; Google documenta la creación de una nueva distribución etapa antes de que la versión anterior alcance el 100%.
- No se puede forzar a los usuarios a instalar de inmediato; actualizan cuando Play entrega la versión.
- Production staged rollouts can target países o regiones específicosseguirán las reglas de prueba del track.
The Google Play Developer API los IDs de seguimiento (production, beta para pruebas abiertas, qa para pruebas internas, más tracks cerrados con nombre) si automatizas las liberaciones.
Qué observar durante la implementación
| Señal | Dónde buscar |
|---|---|
| Tasa de errores (después de la instalación) | Play Console Android vitales |
| ANRs (después de que los usuarios instalen) | Consola de Play Android vitales |
| Verificaciones previas (antes de un lanzamiento amplio) | Play Console pre-launch report on test devices |
| Revisión de usuarios | Comentarios de la lista de tienda para la versión |
| Errores en el backend | Su API tableros correlacionados con encabezados de versión |
Espera lo suficiente entre saltos de porcentaje para recopilar señal. El centro de ayuda de Google sugiere monitorear antes de expandir; muchas equipos mantienen al menos un día en porcentajes tempranos para producción.
Si un error nativo se envía Detener el despliegue en Play y publicar un paquete fijo con un valor más alto versionCodeGoogle Play no realiza rollback automático de binarios para usted.
Capgo canales y rollouts porcentuales (actualizaciones en vivo)
Los rollouts de la tienda cambian el shell nativo los usuarios descargan desde Play. Capgo gestiona actualizaciones de paquetes web en vivo dentro de una aplicación ya instalada Capacitor.
- Channels dispositivos a flujos de actualización ("
production,betaPuedes forzar IDs de dispositivo específicos a un canal cuando se está depurando. - Despliegues progresivos mantenga un fallback estable paquete en el canal mientras un objetivo de lanzamiento llega a un porcentaje configurado percentage Aumente, disminuya, pause, complete o regrese sin enviar una nueva versión de Play para correcciones en la capa web.
Utilice los despliegues de etapas de Play cuando cambie nativo code, permisos o targetSdkVersionUtilice Capgo rollouts porcentuales cuando la corrección se encuentra en HTML, CSS o JavaScript y su revisión de cumplimiento permite la entrega OTA.
Envíe cambios nativos a través de
- Envíe cambios nativos a través Pruebas internasEntonces cerrado o Pruebas abiertasEntonces, a Producción Despliegue escalonado.
- Punte a dispositivos de producción a un canal estable Capgo para arreglos web diarios.
- Ejecutar un despliegue progresivo en un canal cuando desee paquetes web canario con un fallback estable automático.
- Detener la actualización de Play si los indicadores regresan; revertir la actualización progresiva Capgo si los métricas web regresan.
Recordatorio de reglas y requisitos
- Cada nuevo paquete necesita un valor
versionCodeusuarios pueden ya recibir actualizaciones en cualquier pista que se superponga. - Las aplicaciones que utilizan Play App Signing deben subir AABs firmados por Firma de Aplicación de Google Play.
- Completa las liberaciones programadas pendientes o descarta los borradores antes de iniciar liberaciones conflictivas en el mismo canal.Prepárate y distribuye una liberación).
FAQ
¿Usa pruebas internas porcentajes?
No. La prueba interna distribuye la versión a tu lista de probadores (hasta 100 personas). Utiliza Cerrado, Abierto o Producción para rollouts de etapas porcentuales.
¿Cómo instalan los probadores las versiones internas o cerradas?
Internal testing uses an email list (up to 100 testers). Closed testing supports email lists, Google Groups, or Play Console organization management. Open testing is the only track that surfaces a public opt-in program on your store listing. Testers on internal or closed tracks usually need the Play Store URL you share; they will not find the build by searching unless you use open testing or production.
When should Capacitor teams use Capgo en lugar de elevar la actualización de Play?
When the change is confined to web assets and passes your store compliance checklist. Native plugin upgrades, manifest changes, and permission changes still need a new Play release.
Continúa leyendo de Google Play Staged Rollouts: Cómo funciona
Si estás utilizando Google Play Staged Rollouts: Cómo funciona para planificar la aprobación y distribución de la tienda, conecta con @capgo/capacitor-revisión-en-aplicación para la implementación detallada en @capgo/capacitor-revisión-en-aplicación Usando @capgo/capacitor-revisión-en-aplicación para la capacidad nativa en Usando @capgo/capacitor-revisión-en-aplicación @capgo/capacitor-mercado-nativo para la implementación detallada en @capgo/capacitor-mercado-nativo Usando @capgo/capacitor-nativo-mercado para la capacidad nativa en Usando @capgo/capacitor-nativo-mercado, y Capacitor OTA Updates: App Store Approval Guide para el contexto práctico en Capacitor Actualizaciones OTA: Guía de Aprobación de la Tienda de Aplicaciones.
