Solución Capgo No actualiza el canal predeterminado de dispositivos

Al cambiar el canal predeterminado en Capgo routes brand-new devices right away. Existing installs may stay on their old channel until they check in again, which explains many cases where a Capgo cloud default channel is not updating devices.

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

• Paso 1: Confirma que el dispositivo está asignado al canal por defecto.
• Paso 2: Verifica la aplicación, el tiempo de ejecución nativo y la compatibilidad de actualizaciones.
• Paso 3: Verifica que la implementación realmente llegó al canal por defecto.
• Paso 4: Forza una sincronización fresca e inspecciona los registros del lado del dispositivo.
• Paso 5: Revisa las reglas de despliegue, las barreras de versión y el rollback automático.
• Paso 6: Utiliza análisis en tiempo real para encontrar el punto de falla exacto.
• Paso 7: Evita que el canal por defecto se vuelva obsoleto.
• Preguntas Frecuentes
• Conclusión

Paso 1: Confirme que el dispositivo está asignado al canal predeterminado

El objetivo es determinar qué regla decide actualmente el canal del dispositivo. Un Cloud Default solo se aplica cuando una asignación más fuerte no ha reclamado ya el dispositivo.

Abra la consola de Capgo y inspeccione el dispositivo afectado. Verifique su canal actual, ID de la aplicación, versión y hora de último registro. Compare esos valores con un dispositivo que recibió la actualización esperada. Esta comparación a menudo muestra el problema rápidamente.

La selección del canal sigue un orden. Un canal forzado tiene prioridad primero. Una configuración de canal o API de la consola viene a continuación. Un canal local establecido por la aplicación sigue a continuación. Luego Capgo verifica en la configuración nativa de la aplicación. El Cloud Default es el fallback.defaultChannelEse orden significa que un dispositivo puede ignorar un Cloud Default cambiado sin ningún error de la consola. Por ejemplo, una versión de prueba puede seguir teniendo un canal local de una prueba anterior. La aplicación sigue utilizando ese valor local hasta que se elimina.

Use la guía de depuración del actualizador de __CAPGO_KEEP_0__

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. A continuación, verifique su configuración de Capgo. Una configuración típica puede incluir un canal como este: El campo es opcional. Si lo deja fuera, el dispositivo puede heredar el Cloud Default. Eso puede funcionar bien para versiones de producción porque la ruta de canal se mantiene en la nube de __CAPGO_KEEP_0__. Si lo incluye, asegúrese de que el valor coincida con el canal que realmente se despliega.

Next, check your Capacitor configuration. A typical setup may include a channel like this:

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.

Now busque por sobrescrituras locales en la aplicación code. Una llamada asetChannel()modifica el caché local. No crea un override de dispositivo en el servidor. Por lo tanto, el panel de control puede mostrar ningún override aunque la aplicación siga utilizando el canal local.

Elimine ese valor local cuando el dispositivo deba regresar a la ruta de navegación normal. Utilice el método de plugin que elimina la asignación de canal del dispositivo, o elimine code que establece el canal y vuelva a instalar la aplicación para una prueba limpia.

Resumen clave: Un cambio en el canal predeterminado de Cloud no puede reemplazar una asignación de canal más fuerte de dispositivo, aplicación o local.

Paso 2: Verifique la aplicación, el tiempo de ejecución nativo y la compatibilidad con actualizaciones

El objetivo es probar que la aplicación instalada puede aceptar el paquete que subiste. Un canal correcto todavía no puede entregar una actualización a un tiempo de ejecución nativo incompatible.

Comience con el ID de la aplicación. La aplicación instalada en el dispositivo debe utilizar la misma identidad de aplicación que el proyecto donde subiste el paquete. Un desacuerdo puede parecer un problema de canal porque el dispositivo verifica la aplicación equivocada Capgo.

Luego compare la versión del tiempo de ejecución nativo con las reglas de compatibilidad del paquete. Capgo las actualizaciones en vivo pueden cambiar JavaScript, CSS y activos web. No pueden agregar un plugin nativo o cambiar el proyecto code nativo 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 tiempo de ejecución nativo API que la aplicación instalada no tiene, Capgo no debe aplicarlo. Construya y suba una versión nativa compatible antes de probar ese paquete.

Inspeccione la versión y 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 cambiardefaultChannelEjecute 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. Un nuevo build desde ese proyecto nativo estancado seguirá reproduciendo el mismo resultado.

Para una prueba limpia, construya una nueva aplicación después de sincronizar. No confíe en un binario antiguo instalado en su teléfono. Desinstálelo cuando necesite eliminar el estado de canal local almacenado en caché, luego instale la nueva construcción y verifique el canal de nuevo.

El Capgo documento de comportamiento de actualización explica cuándo el actualizador verifica un paquete. Utilice ese momento cuando pruebe. Inicie la aplicación o muevala al primer plano, luego permita que la verificación termine antes de decidir que la actualización falló.

También verifique la puerta de versión nativa del paquete. Un paquete puede existir en el canal correcto pero permanecer inaccesible porque su versión de aplicación mínima no coincide con el dispositivo. Lea los detalles de la versión en la consola en lugar de asumir que la última carga se aplica a cada instalación.

Si la aplicación supera estas comprobaciones, ha reducido la falla. La siguiente pregunta es si la versión se llegó al canal deseado en absoluto.

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

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

Abra el canal en Capgo Cloud. Verifique el paquete activo, su versión y su estado de implementación. Compare el nombre del canal con el valor devuelto por la aplicación. Busque diferencias pequeñas comoproductionversusprodLos nombres de los canales deben coincidir exactamente.

Si se despliega a través de CI/CD, inspeccione la salida del comando del mismo trabajo que subió el paquete. Confirme el ID de la aplicación y el canal pasados a CLI. Una canalización puede terminar con un subida exitosa mientras se dirige a un canal de pruebas por error.

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

Utilice un dispositivo de prueba conocido. Dígale un papel claro. Por ejemplo, fíjese un dispositivo a un canal de prueba y deje otro dispositivo en el Cloud Default. Suba un cambio inocuo, luego compare sus registros de verificación. Esto elimina la adivinanza de la prueba.

El motor de OTA en vivo 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 la versión en activo en el canal exacto que el dispositivo verifica.

Si cambió la configuración de 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 actualizaciones. Cerrar y volver a abrir la aplicación puede ayudar a desencadenar esa verificación, pero no puede superar un canal bloqueado.

Verifique 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 al iniciar o en segundo plano. No pruebe abriendo una pantalla que nunca inicia el actualizador. Coloque la verificación en un camino de inicio conocido para una prueba de edición corta, 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 al paso 1 y elimine la asignación que gana sobre la configuración de Cloud Default.

Paso 4: Forzar un sincronización fresca e inspeccionar los registros del lado del dispositivo

El objetivo es separar un estado local estancado de un problema de entrega del lado del servidor. Una verificación fresca le da nueva evidencia.

Primero, asegúrese 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 final. Los filtros corporativos, las reglas de VPN, los portales captivos o una sesión expirada pueden bloquear la solicitud de actualización.

Segundo, traiga la aplicación a primer plano. Espere a que el controlador de actualizaciones termine. Si su aplicación expone un evento de estado de actualización, registre ese evento con el canal actual. Evite registrar solo “actualización iniciada.” Necesita saber si la aplicación encontró un paquete, lo descargó, lo verificó, lo instaló o lo rechazó.

Utilice 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 la puerta de versión. Un error de descarga apunta al acceso a la red o la solicitud del paquete.

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

Para un chequeo repetible, graba estos valores en una 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

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

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

Consejo práctico: Captura el canal resuelto antes de que lo elimines. De lo contrario, podrías corregir el estado y perder la pista que explicó el fallo.

Paso 5: Revisa las reglas de lanzamiento, las puertas de versión y el retroceso automático

El objetivo es comprobar si Capgo ha retenido o revertido intencionalmente el paquete. Una actualización faltante a veces es una regla de seguridad que funciona como diseñada.

Abre las configuraciones del canal y revisa cada regla asociada a la versión. Busca versiones mínimas de la aplicación, ajustes de porcentaje de lanzamiento, filtros de dispositivo 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 el formato de la versión también. Capgo utiliza la numeració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 en las compilaciones nativas y las actualizaciones OTA.

Revisar luego el comportamiento de retroceso. Un retroceso automático puede mover un dispositivo a una versión anterior del paquete después de un cheque de salud fallido. La consola puede mostrar la versión activa anterior de code mientras que la versión que se espera permanece presente pero no disponible.

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 lanzamiento y la razón de retroceso. Luego decida si pausar el lanzamiento o publicar una versión conocida y buena.

Utilice un canal de etapa para cambios arriesgados. 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 el lanzamiento se comporte como se espera, avance el lanzamiento. Esto mantiene un cambio de capa web malo de llegar a cada dispositivo activo al mismo tiempo.

Retroceda solo para reparar code que OTA puede cambiar. Si el fallo proviene de un plugin nativo faltante o un API nativo incompatible, necesita una nueva compilación de tienda. Enviar un bundle de JavaScript más antiguo no agregará la pieza nativa que la aplicación falta.

Cuando inspeccione una regla, haga tres preguntas:

• ¿Cumple con la condición de versión de la aplicación este dispositivo?
• ¿Está dentro del grupo de lanzamiento este dispositivo?
• ¿Un cheque de salud o una acción manual lo devolvió a una versión anterior del paquete?

Capgo es útil aquí porque el mismo modelo de canal puede llevar una liberación etapa, apoyar un rollback y mostrar la actividad de actualización en un flujo de trabajo. Mantenga 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 necesita comprobaciones basadas en API, el La documentación pública de Capgo en API describe recursos para dispositivos, canales y paquetes. Utilícelo para comparar la vista del servidor con lo que el aplicativo informa. Esa comparación puede revelar un filtro de la consola de control desactualizado o una asignación de dispositivo creada por automatización. Las reglas de lanzamiento OTA versionan y el flujo de trabajo de rollback automático

Paso 6: Utilice Analytics en Tiempo Real para encontrar el punto de falla exacto

El objetivo es dejar de tratar “no actualizado” como un solo fallo. Los Analytics pueden mostrar si el dispositivo nunca se conectó, no encontró un paquete elegible, falló durante la descarga o se deshizo más tarde.

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

Compare 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 caída sugiere errores de instalación o rollback. Un aumento lento puede significar simplemente que los dispositivos no han abierto la aplicación aún.

__CAPGO_KEEP_0__ es útil aquí porque el mismo modelo de canal puede llevar una liberación etapa, apoyar un rollback y mostrar la actividad de actualización en un flujo de trabajo. Mantenga 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.

Use los timestamps con cuidado. El tiempo de eventos en la consola puede diferir del tiempo local del usuario. Coincidir el evento de actualización con la última verificación del dispositivo. Esto ayuda cuando un tester dice que la actualización falló antes de que la aplicación hubiera actualizado realmente.

Las analytics también te ayudan a probar un cambio de canal de manera segura. Cambia una variable a la vez. Mantén la constante mientras pruebas la ruta. Luego mantén la ruta constante mientras pruebas un nuevo paquete. Si cambias ambos, los datos no pueden decirte qué cambio resolvió el problema.

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

• El identificador del dispositivo o etiqueta de prueba interna
• Canal resuelto
• Versión de la aplicación nativa
• Paquete esperado y paquete instalado
• Última hora de verificación
• 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.

Mantén los datos de analytics 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 qué code se movió realmente.

Si solo los dispositivos existentes fallan después de un cambio en el canal por defecto, espera a que su próxima verificación antes de cambiar más ajustes. Un nuevo instalación es un control útil. Te dice si la ruta por defecto funciona para dispositivos que no tienen estado local antiguo.

Step 7: Evita que el canal predeterminado se vuelva obsoleto

El objetivo es hacer visible el desplazamiento del canal antes de que afecte a los usuarios. Una pequeña lista de verificación 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 predeterminado. Para una compilació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 Cloud Default que nadie verifica.

Ponnpx cap syncen el camino de compilación después de los cambios de configuración. Haz que la compilación falla si el paso de sincronización falla. El comando es simple, pero saltarlo puede hornear el canal de ayer en el binario nativo de hoy.

Agrega una prueba de humo después de la implementación. El dispositivo de prueba debe lanzar la aplicación, llamargetChannel()comprueba el paquete esperado y registra el resultado. La verificación a menudo es el paso faltante en los flujos de trabajo OTA. Un subir solo prueba muy poco.

Mantén el canal local code detrás de una bandera de característica clara. Si un asistente de prueba llamasetChannel()asegúrate de que las compilaciones de producción no puedan incluirlo por error. Recuerda que la caché local no puede aparecer como una sobrescritura de la consola, por lo que la interfaz no puede capturar cada problema.

Utiliza una lista de verificación de lanzamiento como esta:

1. Confirma el ID de la aplicación y la versión nativa.
2. Elige el canal objetivo.
3. Sube el paquete a ese canal.
4. Confirma que el paquete está activo.
5. Ejecuta el test de humo del dispositivo.
6. Verifica el canal devuelto congetChannel().
7. Observa la adopción antes de ampliar el lanzamiento.

Mantén 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. Trata la prueba como una oportunidad para probar tu flujo de lanzamiento en aplicaciones reales, no solo para inspeccionar una consola. Intenta una despliegue estagiado, un test de rollback y un control automático del canal.

La seguridad pertenece al mismo checklist. Protege los tokens de CI/CD. Limita a quién puede cambiar el Cloud Default. Mantén las credenciales de despliegue de producción fuera de los scripts locales. Un cambio no autorizado del canal puede parecer un dispositivo estancado hasta que revises la traza de auditoría.

Para equipos que envían con frecuencia, mantén el proceso aburrido. Un comando para desplegar. Un dispositivo de prueba conocido. Una regla de canal clara. Sigue, adopta, vuelve a rodar.

Resumen clave: Prevén la navegación estancada sincronizando la configuración, evitando sobrescrituras locales ocultas, probando el canal resuelto y manteniendo el rollback listo.

Preguntas Frecuentes

¿Por qué el canal por defecto de la nube de Capgo no actualiza dispositivos existentes?

Los dispositivos existentes pueden mantener su canal antiguo hasta su próxima verificación de actualizaciones. Una canal local, una sobrescritura de la consola o una asignación forzada también pueden tener prioridad sobre el Canal por Defecto de la Nube. Confirme el canal resuelto del dispositivo congetChannel()borre cualquier asignación más fuerte, luego traiga la aplicación al primer plano.

Does changing the Capgo Cloud Default change every installed app?

¿Qué hace npx cap sync para un cambio de canal __CAPGO_KEEP_0__?

copiar la configuración actualizada Capgo a los proyectos nativos. Si cambia

npx cap synccopies updated Capacitor configuration into the native projects. If you changedefaultChannelNo,

cambia el canal almacenado localmente por la aplicación. No crea una sobrescritura de dispositivo en la nube, por lo que la consola de la nube Capgo puede no mostrar el dispositivo como sobrescrito. Borre la asignación local cuando el dispositivo deba regresar a la ruta por defecto, luego verifique el resultado con

¿Por qué el canal por defecto de la nube de __CAPGO_KEEP_0__ no actualiza dispositivos existentes?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 a través de un paquete OTA?

No, Capgo actualiza OTA se aplica a la capa web code como JavaScript, CSS y activos. Un plugin nativo, permiso o cambio de API nativo requiere una nueva construcción de tienda. Si el paquete espera code nativos que la aplicación instalada carece, la actualización puede ser rechazada incluso cuando el canal es correcto.

Conclusión

Comience con el canal resuelto, no el predeterminado de la consola. Verifique las asignaciones, ejecutenpx cap sync, verifique el paquete contra el tiempo de ejecución nativo y inspeccione los registros del dispositivo antes de cambiar las reglas de lanzamiento. Luego agregue una prueba de post-despliegue pequeña en Capgo que llamagetChannel()y confirma el paquete esperado.