Solución: Capgo No actualiza el canal predeterminado de dispositivos

Cambiar el canal predeterminado en Capgo rutas dispositivos nuevos de inmediato. Los instalaciones existentes pueden permanecer en su canal antiguo hasta que vuelvan a verificar, lo que explica muchos casos en los que un canal predeterminado de Capgo en la nube no actualiza dispositivos.

Revisa los controles en orden. Confirma la asignación del dispositivo primero, luego inspecciona la compilación de la aplicación, el estado de sincronización, las reglas de despliegue, los registros y los ajustes de rollback.

Contenido de la Tabla

• Confirmar que el dispositivo está asignado al canal predeterminado
• Verificar la aplicación, el tiempo de ejecución nativo y la compatibilidad de actualizaciones
• Verificar que la implementación realmente llegó al canal predeterminado
• Paso 4: Forzar una Sincronización Fresca e Inspeccionar Registros del Dispositivo
• Revisar las reglas de lanzamiento, las barreras de versión y el retroceso automático
• Utilizar análisis en tiempo real para encontrar el punto exacto de falla
• Step 7: Evita que el Canal Predeterminado se vuelva Obsoleto
• FAQ
• Conclusión

Step 1: Confirma que el Dispositivo está Asignado al Canal Predeterminado

El objetivo es encontrar cuál es la regla que decide actualmente el canal del dispositivo. Un Canal Predeterminado solo se aplica cuando una asignación más fuerte no ha reclamado ya el dispositivo.

Abre la consola Capgo y inspecciona el dispositivo afectado. Verifica su canal actual, ID de la aplicación, versión y última fecha de sincronización. Compara esos valores con un dispositivo que recibió la actualización esperada. Esta comparación muestra a menudo el problema rápidamente.

La selección del canal sigue un orden. Un canal forzado tiene prioridad primero. Una configuración de canal o dispositivo API viene a continuación. Un canal local establecido por la aplicación sigue después. Luego Capgo verificadefaultChannelen la configuración de la aplicación nativa. El Canal Predeterminado es el fallback.

Este orden significa que un dispositivo puede ignorar un Canal Predeterminado cambiado sin ningún error de la consola. Por ejemplo, una compilación de prueba puede seguir teniendo un canal local de una prueba anterior. La aplicación sigue utilizando ese valor local hasta que lo elimines.

Utiliza el Guía de depuración del actualizador Capgo cuando el canal resuelto está en blanco o inesperado. Cubre el caso en el que la aplicación no tiene un valor predeterminado usable y el dispositivo no tiene una sobrescritura.

Próximo, revisa tu configuración de Capacitor. Una configuración típica puede incluir un canal como este:

const config = { plugins: { CapacitorUpdater: { defaultChannel: 'production' } }
}

The field is optional. If you leave it out, the device can inherit the Cloud Default. That can work well for production builds because channel routing stays in Capgo Cloud. If you include it, make sure the value matches the channel you actually deploy to.

Ahora busca sobrescripciones locales en la aplicación code. Una llamada asetChannel()modifica el caché local. No crea una sobrescripción de dispositivo en el servidor. Por lo tanto, el panel de control puede mostrar ninguna sobrescripción aunque la aplicación siga utilizando el canal local.

Borra ese valor local cuando el dispositivo deba regresar a la ruta normal. Utiliza el método de plugin que elimina la asignación de canal del dispositivo, o elimina el code que establece el canal y reinstala la aplicación para una prueba limpia.

Resumen clave: Un canal de dispositivo, aplicación o local más fuerte no puede ser reemplazado por un canal de Cloud Default modificado.

Paso 2: Verifica la Aplicación, el Entorno Nativo y la Compatibilidad de Actualizaciones

contexto: Página/área: Página de Capgo. Rol: Etiqueta de interfaz de usuario. Visto en: página sobre .astro. Clave de mensaje `about_how_step_label` (Etiqueta de paso de cómo sobre)

Start with the app ID. The app installed on the device must use the same app identity as the project where you uploaded the bundle. A mismatch can look like a channel problem because the device checks the wrong Capgo app.

Luego compara la versión nativa del tiempo de ejecución con las reglas de compatibilidad del paquete. Los Capgo actualizaciones en vivo pueden cambiar JavaScript, CSS y activos web. No pueden agregar un plugin nativo o cambiar el proyecto nativo code después de que la aplicación se haya enviado. Los cambios nativos todavía requieren una nueva compilación de tienda.

Piense en el tiempo de ejecución nativo como el marco alrededor de la web code. Si el nuevo paquete espera un API nativo que la aplicación instalada no tiene, Capgo no debe aplicarlo. Crea y sube una versión nativa compatible antes de probar ese paquete.

Inspeccione la versión y la plataforma de la aplicación instalada. Pruebe un paquete de Android en Android primero. Pruebe un paquete de iOS en iOS. También confirme que el paquete se dirige a la versión de la aplicación correcta cuando su canal utiliza puertas de versión.

Después de cambiardefaultChannelEjecuta el comando de sincronización desde la raíz del proyecto:

npx cap sync

Este paso copia la configuración actualizada en los proyectos nativos. Editarcapacitor.configsin sincronizar deja la aplicación nativa en su configuración de canal antigua. Una compilación fresca de ese proyecto nativo estancado seguirá reproduciendo el mismo resultado.

Para una prueba limpia, construye una nueva aplicación después de sincronizar. No confíes en un binario antiguo instalado en tu teléfono. Desinstálalo cuando necesites eliminar el estado de canal local almacenado en caché, luego instálalo nuevamente y verifica el canal de nuevo.

El Capgo comportamiento de actualización documentado explica cuándo el actualizador verifica un paquete. Utilice ese momento cuando pruebe. Inicia la aplicación o muevete a la aplicación de fondo, luego permite que el control termine antes de decidir que la actualización falló.

Verifica también la versión nativa de la caja. Una caja puede existir en el canal correcto pero permanecer inaccesible porque su versión de aplicación mínima no coincide con el dispositivo. Lee los detalles de la versión en la consola en lugar de suponer que la última carga se aplica a cada instalación.

Si la aplicación supera estos controles, has reducido el error. La siguiente pregunta es si la versión se llegó al canal deseado en absoluto.

Step 3: Verificar que la implementación llegó realmente al canal predeterminado

El objetivo es confirmar que la caja existe en el canal que resuelve el dispositivo. Subir una caja a un canal no la hace disponible en todos los canales.

Abre el canal en Capgo Cloud. Verifica la caja activa, su versión y su estado de implementación. Compara el nombre del canal con el valor devuelto por la aplicación. Busca diferencias pequeñas comoproductionversusprod. Channel names must match exactly.

Si se despliega mediante CI/CD, inspecciona la salida del comando del mismo trabajo que subió la caja. Confirma el ID de la aplicación y el canal pasado a CLI. Una canalización puede terminar con una carga exitosa mientras se dirige a un canal de pruebas por error.

Verifica el estado de la caja a continuación. Una versión borrador o inactiva puede estar visible en la consola pero inaccesible para los dispositivos. Si el canal tiene un despliegue de lanzamiento, el dispositivo afectado puede no cumplir con su regla de lanzamiento.

Utilice un dispositivo de prueba conocido. Asigne un papel claro. Por ejemplo, fije un dispositivo a un canal de prueba y deje otro dispositivo en el Cloud Default. Suba un cambio inocuo, luego compare sus registros de check-in. Esto elimina la adivinanza de la prueba.

El motor de actualizaciones OTA de Capgo está diseñado para cambios en la capa web. Puede mover una actualización de paquete de JavaScript, CSS o activos sin esperar a una nueva revisión de la tienda. Esa velocidad depende de que la versión esté activa en el canal exacto en el que el dispositivo verifica.

Si cambió el Cloud Default hace momentos, recuerde el tiempo del dispositivo. Las instalaciones nuevas utilizan la nueva ruta de inmediato. Los dispositivos existentes suelen cambiar cuando realizan su próxima verificación de actualización. Cerrar y volver a abrir la aplicación puede ayudar a desencadenar esa verificación, pero no puede superar un canal fijado.

Verifique ahora el resultado dentro de la aplicación. LlamegetChannel()después de que comience el actualizador. Registre el canal devuelto junto con la versión de la aplicación y la versión del paquete. Esto es más útil que verificar solo la consola porque muestra qué cree el dispositivo.

Esperar un retraso si la aplicación solo verifica en lanzamiento o en primer plano. No pruebe abriendo una pantalla que nunca inicia el actualizador. Coloque la verificación en un camino de inicio conocido para un breve ensayo, luego elimine el registro adicional antes de la liberación.

Si el canal devuelto es correcto pero no llega el paquete, pase a la compatibilidad y las reglas de lanzamiento. Si el canal devuelto es incorrecto, regrese a la Paso 1 y elimine la asignación que gana sobre el Cloud Default.

Paso 4: Forzar un Sincronización Fresca e Inspeccionar Registros del Dispositivo

El objetivo es separar un estado local estancado de un problema de entrega desde el servidor. Una nueva verificación te da nueva evidencia.

Primero, asegúrate de que el dispositivo tenga acceso a la red. Una sesión de la aplicación exitosa no prueba que el actualizador pueda llegar a su punto de destino. Los filtros corporativos, las reglas de VPN, los portales de captura o una sesión expirada pueden bloquear la solicitud de actualización.

A continuación, lleva la aplicación al primer plano. Espera a que termine la verificación del actualizador. Si tu aplicación expone un evento de estado de actualización, registra ese evento con el canal actual. Evita registrar solo “actualización iniciada.” Necesitas saber si la aplicación encontró un paquete, lo descargó, lo verificó, lo instaló o lo rechazó.

Utiliza los registros del dispositivo de Capgo para encontrar la primera etapa fallida. El primer error es usualmente más útil que el mensaje final “actualización fallida.” Por ejemplo, un canal faltante apunta a la ruta. Una rechaza de compatibilidad apunta al tiempo de ejecución nativo o a la puerta de versión. Un error de descarga apunta al acceso a la red o a la solicitud del paquete.

Una reinstalación es una prueba útil, pero cambia la evidencia. Reinstalar puede eliminar el estado del canal local. Utilícela después de capturar el canal actual y los registros, no antes.

Para un chequeo repetible, registre estos valores en una sola línea de registro:

• ID de la aplicación y versión nativa de la aplicación
• Canal resuelto desdegetChannel()
• Última hora de verificación del actualizador
• Versión de paquete encontrada por el servidor
• Resultado de instalación o rechazo

Este pequeño registro ayuda cuando el dispositivo pertenece a un tester que no puede reproducir el problema a demanda. También da a su equipo de CI una señal clara para pruebas de humo automatizadas.

Utilice el repositorio de fuentes de actualización oficial Capgo Capacitor cuando necesite inspeccionar el comportamiento del plugin API. En particular, preste atención a la diferencia entre un cambio de canal local y una asignación de dispositivo en la consola.

Consejo Pro: Capturar el canal resuelto antes de eliminarlo. De lo contrario, puede fijar el estado y perder la pista que explicó el fracaso.

Paso 5: Revisar Reglas de Lanzamiento, Puertas de Versión y Retroceso Automático

El objetivo es verificar si Capgo retenía o revertía intencionalmente el paquete. Una actualización faltante a veces es una regla de seguridad que funciona como diseñada.

Abra las configuraciones del canal y revise cada regla asociada a la versión. Busque versiones mínimas de la aplicación, ajustes de rollout porcentual, filtros de dispositivos y condiciones relacionadas con la versión. Un dispositivo fuera de la regla permanecerá en su paquete actual incluso cuando el canal esté correcto.

Verifique también el formato de la versión. Capgo utiliza la versión semántica para comparar versiones. Una puerta de versión que parece correcta para una persona puede comportarse de manera diferente si la aplicación o el paquete utiliza un formato inesperado. Mantenga el formato consistente entre compilaciones nativas y actualizaciones OTA.

Luego revise el comportamiento de rollback. Un rollback automático puede mover un dispositivo a un paquete anterior después de una verificación de salud fallida. La consola puede mostrar la versión activa anterior de code mientras que la versión que se espera permanece presente pero inaccesible.

No elimine un paquete sospechoso antes de revisar sus eventos. La eliminación elimina pruebas útiles. Primero registre la versión del paquete, el canal, el estado de rollout y la razón de rollback. Luego decida si pausar la versión o publicar una versión conocida.

Utilice un canal de etapa para cambios riesgosos. Envíe el paquete a un pequeño grupo de prueba primero. Mire la adopción y los señales de error. Una vez que la versión se comporte como se espera, avance la versión. Esto mantiene un cambio de capa web malo de alcanzar todos los dispositivos activos al mismo tiempo.

Revertir solo arregla code que OTA puede cambiar. Si el error proviene de una falta de plugin nativo o una incompatibilidad de un plugin nativo API, necesitas una nueva compilación de tienda.

Cuando inspeccionas una regla, haz tres preguntas:

• ¿Este dispositivo cumple con la condición de versión de la aplicación?
• ¿El dispositivo está dentro del grupo de lanzamiento?
• ¿Un chequeo de salud o una acción manual lo devolvió a una versión anterior?

Capgo es útil aquí porque el mismo modelo de canal puede llevar un lanzamiento estagado, apoyar un revertir y mostrar actividad de actualización en un flujo de trabajo. Mantén el conjunto de reglas pequeño. Una política corta es más fácil de auditar que una pila de excepciones creadas durante un incidente.

Si necesitas API-basadas de verificaciones, el Capgo documento público de API describe recursos para dispositivos, canales y paquetes. Utilízalo para comparar la vista del servidor con lo que la aplicación informa. Esa comparación puede revelar un filtro de la consola desactualizado o una asignación de dispositivo creada por automatización.

Un rollback es un guardrail, no un sustituto de pruebas. Mantén una versión conocida buena disponible en cada canal de producción.

Paso 6: Utiliza Análisis en Tiempo Real para encontrar el punto de falla exacto

El objetivo es dejar de considerar a los dispositivos ‘no actualizados’ como un solo fracaso. Las métricas pueden mostrar si el dispositivo nunca se conectó, no encontró un paquete elegible, falló durante la descarga o volvió a un estado anterior.

Comience con el grupo de dispositivos afectados. Filtre por versión de la aplicación, plataforma, canal y versión del paquete. Busque un patrón. Si solo una versión antigua de la aplicación falla, el problema puede ser una puerta de compatibilidad nativa. Si todos los dispositivos de un canal fallan, inspeccione el canal o la implementación.

Comparez la adopción con el tiempo. Una línea plana después de la liberación sugiere problemas de enrutamiento o elegibilidad. Un aumento seguido de una disminución sugiere errores de instalación o rollback. Un aumento lento puede significar simplemente que los dispositivos aún no han abierto la aplicación.

Utilice los tiempos de marcaje con cuidado. El tiempo de evento de la consola puede diferir del tiempo local del usuario. Coincidir el evento de actualización con el último check-in del dispositivo. Esto ayuda cuando un tester dice que la actualización falló antes de que la aplicación hubiera actualizado realmente.

Las métricas también ayudan a probar un cambio de canal de manera segura. Cambie una variable a la vez. Mantenga el paquete constante mientras pruebe el enrutamiento. Luego mantenga el enrutamiento constante mientras pruebe un nuevo paquete. Si cambia ambos, los datos no pueden decirle qué cambio resolvió el problema.

Para un incidente, guarde un conjunto de evidencia pequeño:

• El identificador del dispositivo o la etiqueta de prueba interna
• El canal resuelto
• La versión nativa de la aplicación
• El paquete esperado y el paquete instalado
• El tiempo de último check-in
• El evento de rollback o rechazo

La vista en tiempo real de Capgo es más útil cuando tu proceso de liberación envía actualizaciones a través de CI/CD. Un trabajo de despliegue puede subir un paquete, mientras que un paso de monitoreo verifica que los dispositivos de prueba informen el canal y el paquete previstos. Eso convierte una queja manual en una puerta de liberación.

Conserva los datos de análisis vinculados a los registros de liberación. Escribe la referencia de commit o build en tus notas de despliegue. Cuando dos paquetes tienen etiquetas de versión similares, la referencia de build te dice cuál code se movió realmente.

Si solo los dispositivos existentes fallan después de un cambio en el canal por defecto de Cloud, espera a su próxima verificación antes de cambiar más configuraciones. Una instalación nueva es una buena opción de control. Te dice si la ruta por defecto funciona para dispositivos que no tienen estado local antiguo.

7. Evita que el Canal por Defecto se vuelva Obsoleto

El objetivo es hacer visible el desfase de canal antes de que afecte a los usuarios. Un pequeño checklist de lanzamiento puede prevenir la mayoría de los casos repetidos.

Elige un modelo de enrutamiento para cada entorno de aplicación. Para producción, puedes omitirdefaultChannely dejar que Capgo Cloud controle el canal por defecto. Para una construcción de prueba, puedes establecer un canal explícito. La configuración peligrosa es una mezcla de sobrescrituras locales antiguas, una configuración nativa obsoleta y un nuevo canal por defecto de Cloud que nadie verifica.

Colocanpx cap syncen el camino de construcción después de los cambios de configuración. Haz que la construcción fracase si el paso de sincronización falla. La orden es simple, pero saltarla puede hornear el canal de ayer en el binario nativo de hoy.

Agrega una prueba de humo después de la despliegue. El dispositivo de prueba debe lanzar la aplicación, llamargetChannel()Verifique el paquete esperado y registre el resultado. La verificación a menudo es el paso faltante en los flujos de trabajo OTA. Una carga sola prueba muy poco.

Mantén el canal local code detrás de una bandera de característica clara.setChannel() Asegúrese de que los compilados de producción no incluyan accidentalmente. Recuerde que la caché local no puede aparecer como un override del panel de control, por lo que la interfaz no puede capturar todos los problemas.

Utilice un checklist de lanzamiento como este:

1. Confirme el ID de la aplicación y la versión nativa.
2. Elija el canal objetivo.
3. Cargue el paquete en ese canal.
4. Confirme que el paquete está activo.
5. Ejecute el test de humo del dispositivo.
6. Verifique el canal devuelto congetChannel().
7. Mire la adopción antes de ampliar el lanzamiento.

Mantenga la protección de rollback activa para los lanzamientos de producción. Un patrón de falla común es desplegar sin un canal claro o un plan de rollback. Eso deja al equipo con menos formas seguras de detener un paquete malo.

Capgo utiliza una suscripción por organización, con una prueba gratuita de 14 días. Trate la prueba como una oportunidad para probar el flujo de liberación en aplicaciones de construcción real, no solo para inspeccionar una consola. Intente un despliegue estadiado, un test de retroceso y un control automático de canal.

La seguridad pertenece a la misma lista de verificación. Proteja los tokens de CI/CD. Limitar a quién puede cambiar el canal predeterminado de la nube. Mantenga las credenciales de despliegue de producción fuera de los scripts locales. Un cambio de canal no autorizado puede parecer un dispositivo estancado hasta que revise el registro de auditoría.

Para los equipos que envían con frecuencia, mantenga el proceso aburrido. Un comando para desplegar. Un dispositivo de prueba conocido. Una regla de canal clara. Seguir, adoptar, retroceder.

Tomar nota clave: Prevenir la navegación estancada sincronizando la configuración, evitando sobrescripciones locales ocultas, probando el canal resuelto y manteniendo el retroceso listo.

FAQ

¿Por qué el canal de nube predeterminado de Capgo no actualiza dispositivos existentes?

Los dispositivos existentes pueden mantener su canal antiguo hasta su próxima verificación de actualización. Un canal local, una sobrescripción de la consola o una asignación forzada también pueden tener prioridad sobre el Canal Predeterminado de la Nube. Confirme el canal resuelto del dispositivo congetChannel(), elimine cualquier asignación más fuerte, y luego traiga la aplicación a primer plano.

¿Cambia el Canal Predeterminado de la nube de Capgo cada aplicación instalada?

No, cambiar el valor predeterminado de Cloud no reescribe instantáneamente el canal de cada aplicación instalada. Los nuevos dispositivos pueden usar el nuevo valor predeterminado de inmediato. Los instalados existentes necesitan verificar antes de poder cambiar, y aún no cambiarán si una regla de canal más fuerte o una sobrescritura local se aplica.

¿Qué hace npx cap sync en un cambio de canal Capgo?

npx cap synccopiar la configuración actualizada Capacitor en los proyectos nativos. Si cambiadefaultChannelpero omita la sincronización, la próxima compilación nativa puede contener todavía la configuración de canal antigua. Ejecute el comando desde la raíz del proyecto, luego compile y instale una prueba binaria fresca.

¿Establece setChannel un override de dispositivo en Capgo?

No,setChannel()changes the channel stored locally by the app. It does not create a backend Device Override, so the Capgo dashboard may not show the device as overridden. Clear the local assignment when the device should return to default routing, then verify the result withgetChannel().

¿Puede Capgo actualizar nativos code mediante un paquete OTA?

No, Capgo OTA updates apply to web-layer code such as JavaScript, CSS, and assets. A native plugin, permission, or native API change needs a new store build. If the bundle expects native code that the installed app lacks, the update may be rejected even when the channel is correct.

Conclusion

¿Qué hace npx cap sync en un cambio de canal __CAPGO_KEEP_0__?npx cap sync, verify the bundle against the native runtime, and inspect the device logs before changing rollout rules. Then add a small post-deploy test in Capgo that callsgetChannel()y confirma la caja de contenido esperada.