Fix Capgo Default Channel Not Updating Devices

Cambiare il Cloud Default in Capgo i dispositivi nuovi vengono configurati immediatamente. Gli installi esistenti possono rimanere sul loro vecchio canale fino a quando non si connettono nuovamente, il che spiega molti casi in cui un Capgo cloud default channel non aggiorna dispositivi.

Controlla i controlli in ordine. Conferma l'assegnazione del dispositivo per primo, poi verifica la build dell'app, lo stato di sincronizzazione, le regole di distribuzione, i log e le impostazioni di rollback.

Indice dei contenuti

• Passo 1: Conferma che il dispositivo è assegnato al canale predefinito
• Passo 2: Controlla l'app, il runtime nativo e la compatibilità degli aggiornamenti
• Passo 3: Verifica se la distribuzione è effettivamente arrivata al canale predefinito
• Passo 4: Forza una sincronizzazione fresca e ispeziona i log del dispositivo
• Passo 5: Revisiona le regole di distribuzione, le porte di versione e il rollback automatico
• Passo 6: Utilizza le analisi in tempo reale per trovare il punto di fallimento esatto
• Passo 7: Preveni il canale predefinito dall'essere obsoleto
• FAQ
• Conclusioni

Passo 1: Conferma che il dispositivo è assegnato al canale predefinito

L'obiettivo è trovare quale regola decide attualmente il canale del dispositivo. Un Cloud Default si applica solo quando una assegnazione più forte non ha già reclamato il dispositivo.

Apre il Capgo dashboard e ispeziona il dispositivo interessato. Controlla il suo canale attuale, ID dell'app, versione e ultima data di accesso. Confronta questi valori con un dispositivo che ha ricevuto l'aggiornamento previsto. Questa comparazione mostra spesso il problema velocemente.

Il canale selezionato segue un ordine. Una forzatura del canale ha priorità prima. Un dispositivo dashboard o API viene successivamente. Un canale locale impostato dall'app segue quello. Poi Capgo controlladefaultChannelnei configurazioni dell'app nativa. Il Cloud Default è il fallback.

Quella configurazione significa che un dispositivo può ignorare un Cloud Default modificato senza alcun errore del pannello di controllo. Ad esempio, un build di test può ancora avere un canale locale da un test precedente. L'app continua ad utilizzare quel valore locale fino a quando non lo cancellate.

Usa il guida di debug del Capgo updater quando il canale risolto è vuoto o imprevisto. Copre il caso in cui l'app non ha un default utilizzabile e il dispositivo non ha un sovrascrittura.

Prossimamente, controlla la tua Capacitor configurazione. Una configurazione tipica può includere un canale come questo:

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

Questo campo è facoltativo. Se lo lasci fuori, il dispositivo può ereditare il Cloud Default. Ciò può funzionare bene per i build di produzione perché la routing del canale rimane nel Capgo Cloud. Se lo includi, assicurati che il valore corrisponda al canale che effettivamente distribuisci.

Ora cerca le sovrascritture locali nell'applicazione code. Una chiamata asetChannel()modifica il cache locale. Non crea una sovrascrittura del dispositivo backend. Il pannello di controllo può quindi mostrare nessuna sovrascrittura anche se l'app continua ad utilizzare il canale locale.

Cancella quel valore locale quando il dispositivo dovrebbe tornare alla routing normale. Utilizza il metodo del plugin che elimina l'assegnazione del canale del dispositivo, o elimina il code che imposta il canale e reinstalla l'app per un test pulito.

Chiave di apprendimento: Un Cloud Default modificato non può sostituire un'assegnazione di canale più forte del dispositivo, dell'app o locale.

Passo 2: Controlla l'app, il runtime nativo e la compatibilità dell'aggiornamento

L'obiettivo è dimostrare che l'applicazione installata può accettare il pacchetto che hai caricato. Un canale corretto non può ancora distribuire un aggiornamento a un runtime nativo incompatibile.

Inizia con l'ID dell'app. L'app installata sul dispositivo deve utilizzare la stessa identità dell'app come il progetto in cui hai caricato il pacchetto. Una disallineazione può sembrare un problema di canale perché il dispositivo controlla la Capgo app sbagliata.

Poi confronta la versione del runtime nativo con le regole di compatibilità del pacchetto. Le Capgo aggiornamenti live possono modificare JavaScript, CSS e asset web. Non possono aggiungere un plugin nativo o modificare il progetto code nativo dopo che l'app è stata distribuita. Le modifiche native richiedono ancora una nuova costruzione del negozio.

Considera il runtime nativo come il frame che circonda il web code. Se il nuovo pacchetto aspetta un API nativo che l'app installata non ha, Capgo non dovrebbe applicarlo. Costruisci e carica una versione nativa compatibile prima di testare quel pacchetto.

Ispeziona la versione e la piattaforma dell'app installata. Testa un pacchetto Android su Android per primo. Testa un pacchetto iOS su iOS. Inoltre, conferma che il pacchetto si concentri sulla versione dell'app giusta quando il tuo canale utilizza porte di versione.

Dopo aver modificatodefaultChannelEseguisci il comando di sincronizzazione dal root del progetto:

npx cap sync

Questo passaggio copia la configurazione aggiornata nei progetti nativi. L'editingcapacitor.configsenza sincronizzare lascia l'app nativa sul suo vecchio impostazione del canale. Una nuova costruzione da quel progetto nativo vecchio continuerà a riprodurre lo stesso risultato.

Per un test pulito, costruisci una nuova app dopo aver sincronizzato. Non affidarti a un vecchio binario installato sul tuo telefono. Disinstallalo quando hai bisogno di rimuovere lo stato di canale locale memorizzato, quindi installa la nuova build e controlla il canale di nuovo.

La Capgo update behavior documentation spiega quando l'aggiornatore controlla un pacchetto. Utilizza quel timing quando ti testi. Avvia l'app o spostala nuovamente in primo piano, quindi consenti al controllo di completarsi prima di decidere che l'aggiornamento ha fallito.

Controlla anche la versione di gate nativa del pacchetto. Un pacchetto può esistere nel canale corretto eppure rimanere inaccessibile perché la sua versione minima di app non corrisponde al dispositivo. Leggi i dettagli della rilascio nella dashboard anziché presumere che l'upload più recente si applichi a ogni installazione.

Se l'app supera questi controlli, hai ridotto la colpa. La prossima domanda è se la rilascio è arrivata al canale inteso.

Passo 3: Verifica se la distribuzione ha raggiunto effettivamente il canale predefinito

contesto: Pagina/Area: Pagina di Capgo. Ruolo: Etichetta UI. Visibile in: pagina about.astro. Chiave del messaggio `about_how_step_label` (Etichetta del passo di About How).

Open the channel in Capgo Cloud. Check the active bundle, its version, and its deployment state. Compare the channel name with the value returned by the app. Watch for small differences such asproductionversusprodIl nome del canale deve corrispondere esattamente.

Se hai distribuito attraverso CI/CD, controlla l'output del comando proveniente dallo stesso job che ha caricato il bundle. Conferma l'ID dell'app e il canale passati al CLI. Una pipeline può concludersi con un upload riuscito mentre si sta mirando per errore a un canale di staging.

Controlla lo stato del bundle. Una bozza o una versione inattiva potrebbe essere visibile nel dashboard ma non disponibile per i dispositivi. Se il canale ha un rollout programmato, il dispositivo interessato potrebbe non soddisfare la sua regola di rollout.

Utilizza un dispositivo di test noto. Assegna un ruolo chiaro. Ad esempio, fissare un dispositivo a un canale di test e lasciare un altro dispositivo sul Cloud Default. Carica un cambiamento innocuo, quindi confronta i loro registri di check-in. Ciò elimina la congettura dal test.

Il motore OTA live di Capgo è progettato per le modifiche al layer web. Può spostare un aggiornamento del bundle JavaScript, CSS o di un asset senza attendere una nuova revisione del negozio. Quella velocità dipende dalla versione attiva nel canale esatto che il dispositivo controlla.

Se hai modificato il Cloud Default poco fa, ricorda il timing del dispositivo. Le nuove installazioni utilizzano la nuova rotta subito. I dispositivi esistenti solitamente passano quando eseguono il loro prossimo controllo di aggiornamento. Chiudere e riaprire l'app può aiutare a scatenare quel controllo, ma non può sovrascrivere un canale fissato.

Verifica ora il risultato all'interno dell'app. ChiamaregetChannel()dopo che l'aggiornatore inizia. Registra il canale restituito accanto alla versione dell'app e alla versione del bundle. Ciò è più utile del controllare solo il dashboard perché mostra cosa il dispositivo crede.

Attendere un ritardo se l'app controlla solo al lancio o in primo piano. Non testare aprendendo una schermata che non avvia mai l'aggiornatore. Colloca il controllo in un percorso di avvio noto per un breve build di test, quindi elimina la registrazione aggiuntiva prima della release.

Se il canale restituito è corretto ma non arriva il pacchetto, passa alle regole di compatibilità e di distribuzione. Se il canale restituito è sbagliato, torna al passo 1 e cancella l'assegnazione che prevale su quello di Cloud Default.

Passo 4: Forza un sincronizzazione fresca e ispeziona i log del dispositivo

Lo scopo è separare uno stato locale obsoleto da un problema di consegna server-side. Un controllo rinnovato ti dà nuove prove.

Prima, assicurati che il dispositivo abbia accesso a rete. Una sessione di app riuscita non prova che l'aggiornatore possa raggiungere il suo endpoint. I filtri aziendali, le regole VPN, i portali di cattura o una sessione scaduta possono bloccare la richiesta di aggiornamento.

Successivamente, porta l'app in primo piano. Aspetta che il controllo dell'aggiornatore si completi. Se la tua app esporre un evento di stato di aggiornamento, registra quell'evento con il canale corrente. Evita di registrare solo “aggiornamento iniziato.” Hai bisogno di sapere se l'app ha trovato un pacchetto, lo ha scaricato, lo ha verificato, l'ha installato o l'ha rifiutato.

Utilizza i log del dispositivo di Capgo per trovare la prima fase fallita. La prima errore è spesso più utile del messaggio finale “aggiornamento fallito.” Per esempio, una mancanza di canale indica la routing. Una rifiutazione di compatibilità indica il runtime nativo o la porta di versione. Un errore di download indica l'accesso a rete o la richiesta di pacchetto.

Un reinstall è un test utile, ma cambia le prove. Il reinstall può cancellare lo stato del canale locale. Utilizzalo dopo aver catturato il canale corrente e i log, non prima.

Per un controllo ripetibile, registra questi valori in una riga di log:

• ID dell'app e versione nativa dell'app
• Canale risolto dagetChannel()
• Ultimo tempo di controllo dell'aggiornatore
• Versione del pacchetto trovata dal server
• Risultato dell'installazione o rifiuto

Quel piccolo registro aiuta quando il dispositivo appartiene a un tester che non può riprodurre il problema su richiesta. Inoltre, fornisce al tuo team di CI un segnale chiaro per test di fumo automatizzati.

Utilizza il repository di origine ufficiale Capgo Capacitor Updater quando hai bisogno di esaminare il comportamento del plugin API. In particolare, attenzione alla differenza tra un cambio di canale locale e un'assegnazione di dispositivo nel dashboard.

Prova utile: Cattura il canale risolto prima di eliminarlo. Altrimenti, potresti fissare lo stato e perdere la pista che ha spiegato il fallimento.

Passo 5: Revisiona le regole di distribuzione, le porte di versione e il rollback automatico

La meta è controllare se Capgo ha intenzionalmente trattenuto o invertito il bundle. Una mancata aggiornamento è a volte una regola di sicurezza che funziona come progettato.

Apre le impostazioni del canale e revisiona ogni regola legata alla release. Cerca versioni minime dell'app, impostazioni di percentuale di distribuzione, filtri di dispositivo e condizioni legate alla release. Un dispositivo fuori dalla regola rimarrà sul suo bundle corrente anche quando il canale è corretto.

Controlla anche il formato della versione. Capgo utilizza la versione semantica per confrontare le release. Una porta di versione che sembra giusta a una persona può comportarsi diversamente se l'app o il bundle utilizza un formato inaspettato. Mantieni il formato coerente tra build nativi e rilasci OTA.

Rivista quindi il comportamento di rollback. Un rollback automatico può spostare un dispositivo su un bundle precedente dopo un controllo di salute fallito. La dashboard può mostrare il vecchio code attivo mentre la versione di rilascio che si aspetta rimane presente ma non disponibile.

Non cancellare un bundle sospetto prima di esaminare i suoi eventi. La cancellazione elimina prove utili. Prima registra la versione del bundle, il canale, lo stato di distribuzione e la ragione di rollback. Poi decidi se sospendere il rilascio o pubblicare una versione nota.

Utilizza un canale di stadio per cambiamenti rischiosi. Invia il bundle a un piccolo gruppo di test. Guarda l'adozione e i segnali di errore. Una volta che il rilascio si comporta come previsto, sposta avanti la distribuzione. Ciò mantiene un cambiamento di layer web cattivo da raggiungere ogni dispositivo attivo contemporaneamente.

Il rollback ripara solo i code che OTA può modificare. Se il fallimento proviene da un plugin nativo mancante o da un plugin nativo incompatibile API, hai bisogno di una nuova build dello store. Invia un bundle JavaScript più vecchio non aggiungerà la parte nativa che l'app manca.

Quando ispezioni una regola, chiediti tre domande:

• Questo dispositivo soddisfa la condizione di versione dell'app?
• Il dispositivo è all'interno del gruppo di distribuzione?
• Un controllo di salute o un'azione manuale lo ha riportato a un bundle più vecchio?

Il Capgo è utile qui perché lo stesso modello di canale può trasportare un rilascio di stadio, supportare un rollback e mostrare l'attività di aggiornamento in un flusso di lavoro.

Se hai bisogno di API-based checks, consulta il documento pubblico API di Capgo descrive le risorse per dispositivi, canali e bundle. Utilizzalo per confrontare la vista del server con quanto riporta l'app. Quella comparazione può rivelare un filtro del dashboard datato o un'assegnazione di dispositivo creata da un'automazione.

Un rollback è un guardrail, non un sostituto per i test. Mantieni sempre disponibile un bundle noto buono in ogni canale di produzione.

Passo 6: Utilizza gli Analisi in Tempo Reale per Trovare il Punto di Fallimento Preciso

Lo scopo è fermarsi a trattare “non aggiornato” come un solo fallimento. Gli Analytics possono mostrare se il dispositivo non ha mai effettuato il check-in, non ha trovato un bundle idoneo, ha fallito durante il download o ha fatto rollback in seguito.

Inizia con il gruppo di dispositivi interessati. Filtra per versione dell'app, piattaforma, canale e versione del bundle. Cerca un pattern. Se solo una vecchia versione dell'app fallisce, il problema potrebbe essere un gate di compatibilità nativa. Se tutti i dispositivi di un canale falliscono, ispeziona il canale o la distribuzione.

Confronta l'adozione nel tempo. Una linea piatta dopo la rilascio suggerisce problemi di routing o di eleggibilità. Un aumento seguito da una caduta suggerisce errori di installazione o rollback. Un aumento lento può semplicemente significare che i dispositivi non hanno ancora aperto l'app.

Utilizza i timestamp con cura. L'ora del dashboard degli eventi può differire dall'ora locale dell'utente. Corrispondi l'evento di aggiornamento con l'ultimo check-in del dispositivo. Ciò aiuta quando un tester dice che l'aggiornamento ha fallito prima che l'app avesse effettivamente effettuato il check-in.

Analisi aiuta anche a testare un cambio di canale in modo sicuro. Cambia una variabile alla volta. Mantieni costante il pacchetto mentre testi la routing. Poi mantieni la routing costante mentre testi un nuovo pacchetto. Se cambi entrambi, i dati non possono dirti quale cambio ha risolto il problema.

Per un incidente, salva un piccolo set di prove:

• Identificatore del dispositivo o etichetta di test interna
• Canale risolto
• Versione dell'app nativa
• Pacchetto atteso e pacchetto installato
• Ultimo tempo di controllo
• Evento di rollback o rifiuto

La vista in tempo reale di Capgo è più utile quando il processo di rilascio invia aggiornamenti attraverso CI/CD. Un lavoro di distribuzione può caricare un pacchetto, mentre un passaggio di monitoraggio controlla che i dispositivi di test riportino il canale e il pacchetto previsti. Ciò trasforma una lamentela manuale in un gate di rilascio.

Leggi i dati di analisi ai dati di rilascio. Scrivi la referenza di commit o build nelle note di distribuzione. Quando due pacchetti hanno etichette di versione simili, la referenza di build ti dice quale code ha effettivamente spostato.

Se solo i dispositivi esistenti falliscono dopo un cambio di Cloud Default, attendi il loro prossimo controllo prima di cambiare altri impostazioni. Un nuovo install è un control utile. Ti dice se il percorso predefinito funziona per i dispositivi che non hanno stato locale vecchio.

Passo 7: Prevenire il Canale Predefinito da Diventare Stale

L'obiettivo è rendere visibile il drift del canale prima che influisca sugli utenti. Un piccolo elenco di rilascio può prevenire la maggior parte dei casi di ripetizione.

Scegli un modello di routing per ogni ambiente di app. Per la produzione, puoi ometteredefaultChanneland let Capgo Cloud control the default. For a test build, you may set an explicit channel. The dangerous setup is a mix of old local overrides, stale native config, and a new Cloud Default that nobody verifies.

Inseriscinpx cap syncnel percorso di costruzione dopo le modifiche di configurazione. Fai fallire la costruzione se il passo di sincronizzazione fallisce. Il comando è semplice, ma saltarlo può far congelare il canale di ieri nel binario nativo di oggi.

Aggiungi un test di fumo dopo la distribuzione. Il dispositivo di test dovrebbe avviare l'app, chiamaregetChannel(), verificare il bundle previsto e registrare il risultato. La verifica è spesso il passo mancante nelle workflow OTA. Un caricamento solo non dimostra molto.

Tieni il canale locale code dietro una bandiera di feature chiara. Se un helper di test chiamasetChannel(), assicurati che i costruzioni di produzione non includano accidentalmente il codice. Ricorda che la cache locale non appare come sovrapposizione del dashboard, quindi l'interfaccia utente non può catturare ogni problema.

Utilizza un elenco di rilascio come questo:

1. Conferma l'ID dell'app e la versione nativa.
2. Scegli il canale di destinazione.
3. Carica il bundle in quel canale.
4. Conferma che il bundle è attivo.
5. Esegui il test di fumo del dispositivo.
6. Controlla il canale restituito congetChannel().
7. Guarda l'adozione prima di allargare il rollout.

Mantieni la protezione del rollback attiva per le rilasci di produzione. Un comune schema di fallimento è quello di distribuire senza un canale chiaro o un piano di rollback. Ciò lascia il team con meno modi sicuri per fermare un bundle dannoso.

Capgo utilizza una sottoscrizione per organizzazione, con un periodo di prova gratuito di 14 giorni. Trattalo come un'occasione per testare il flusso di rilascio sui reali build dell'app, non solo per ispezionare un dashboard. Prova un deployment in fase di staging, un test di rollback e un controllo del canale automatizzato.

La sicurezza appartiene alla stessa checklist. Proteggi i token CI/CD. Limita chi può modificare il Cloud Default. Mantieni le credenziali di deployment di produzione fuori dai script locali. Un cambio di canale non autorizzato può sembrare un dispositivo obsoleto fino a quando non si esamina la traccia degli accessi.

Per gli squadre che distribuiscono spesso, mantieni il processo noioso. Un comando per distribuire. Un dispositivo di test noto. Una regola di canale chiara. Traccia, adotta, rollback.

Chiave di apprendimento: Preveni la routing obsoleta sincronizzando la configurazione, evitando gli override locali nascosti, testando il canale risolto e mantenendo pronto il rollback.

FAQ

Why è il Capgo cloud predefinito non aggiorna dispositivi esistenti?

Gli dispositivi esistenti possono mantenere il loro canale vecchio fino alla loro prossima verifica di aggiornamento. Un canale locale, un sovrapposizione del dashboard o un'assegnazione forzata possono anche avere la priorità sul Cloud Default. Conferma il canale risolto del dispositivo congetChannel(), elimina eventuali assegnazioni più forti, quindi porta l'applicazione in primo piano.

La modifica del Capgo Cloud Default cambia ogni applicazione installata?

No, la modifica del Cloud Default non scrive immediatamente ogni canale installato dell'applicazione. I nuovi dispositivi possono utilizzare il nuovo default subito. Le installazioni esistenti devono verificarsi prima di poter passare, e non passeranno comunque se una regola di canale più forte o un sovrapposizione locale si applica.

Cosa fa npx cap sync per una modifica del canale Capgo?

npx cap synccopia la configurazione aggiornata Capacitor nei progetti nativi. Se si cambiadefaultChannelma si salta la sincronizzazione, la prossima costruzione nativa potrebbe ancora contenere la impostazione del canale vecchio. Eseguire il comando dalla radice del progetto, quindi costruire e installare un binario di test fresco.

La funzione setChannel crea un sovrapposizione di dispositivo nel Capgo?

No,setChannel()modifica il canale memorizzato localmente dall'applicazione. Non crea un sovrapposizione di dispositivo backend, quindi il dashboard Capgo potrebbe non mostrare il dispositivo come sovrapposto. Eliminare l'assegnazione locale quando il dispositivo dovrebbe tornare alla routing predefinita, quindi verificare il risultato congetChannel().

Possono Capgo aggiornare i code nativi attraverso un bundle 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.

Conclusione

Inizia con il canale risolto, non con quello predefinito del dashboard. Controlla le assegnazioni, eseguinpx cap sync, verifica il pacchetto contro il runtime nativo e ispeziona i log del dispositivo prima di modificare le regole di distribuzione. Aggiungi poi un piccolo test di post-deploy in Capgo che chiamagetChannel()e conferma il pacchetto previsto.