Risolvi Capgo il Canale Predefinito non Aggiorna i Dispositivi

Cambiare il Cloud Default in Capgo indirizza i dispositivi nuovi di marca subito. Le installazioni esistenti possono rimanere sul loro vecchio canale fino a quando non controllano nuovamente, il che spiega molti casi in cui un canale predefinito cloud Capgo non aggiorna i 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à dell'aggiornamento
• Passo 3: Verifica che la distribuzione abbia effettivamente raggiunto il 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 gli analisi in tempo reale per trovare il punto di fallimento esatto
• Passo 7: Prevenire il Canale Predefinito da Diventare Obsoleto
• FAQ
• Conclusioni

Passo 1: Confermare che il Dispositivo è Assegnato al Canale Predefinito

Lo scopo è trovare quale regola decide attualmente il canale del dispositivo. Un Canale Predefinito Cloud si applica solo quando una assegnazione più forte non ha già reclamato il dispositivo.

Aprite il dashboard Capgo e ispezionate il dispositivo interessato. Controllate il suo canale attuale, ID applicazione, versione e ultima data di accesso. Confrontate questi valori con un dispositivo che ha ricevuto l'aggiornamento previsto. Questa comparazione mostra spesso velocemente il problema.

La selezione del canale segue un ordine. Un canale forzato ha priorità prima. Un dispositivo o un API dispositivo di dashboard viene successivamente. Un canale locale impostato dall'app segue quello. Poi Capgo controlladefaultChannelnel config dell'app nativa. Il Canale Predefinito Cloud è il fallback.

Questo ordine significa che un dispositivo può ignorare un Canale Predefinito Cloud modificato senza alcun errore di dashboard. Ad esempio, un build di test può ancora avere un canale locale da un test precedente. L'app continua a utilizzare quel valore locale fino a quando non lo cancellate.

Usate il guida di debug del Capgo aggiornatore quando il canale risolto è vuoto o inaspettato. Copre il caso in cui l'app non ha un default utilizzabile e il dispositivo non ha un override.

Controlla poi la tua configurazione di Capacitor. Una configurazione tipica potrebbe includere un canale come questo:

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.

Ora cerca gli override locali nell'applicazione code. Una chiamata asetChannel()modifica il cache locale. Non crea un override dispositivo backend. Il dashboard potrebbe quindi non mostrare alcun override 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

The goal is to prove that the installed app can accept the bundle you uploaded. A correct channel still cannot deliver an update to an incompatible native runtime.

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.

Quindi 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 nativo code dopo che l'app è stata distribuita. Le modifiche native richiedono ancora una nuova build del store.

Pensate al runtime nativo come al frame che circonda il web code. Se il nuovo pacchetto richiede 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 rivolga alla versione corretta dell'app quando il tuo canale utilizza porte di versione.

Dopo aver modificatodefaultChannelEsegui il comando di sincronizzazione dalla radice del progetto:

npx cap sync

Questo passaggio copia la configurazione aggiornata nei progetti nativi. L'editingcapacitor.configsenza sincronizzazione lascia l'app nativa con la sua impostazione di canale vecchia. Una nuova build da quel progetto nativo invecchiato continuerà a riprodurre lo stesso risultato.

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

Il Capgo comportamento di aggiornamento documentazione spiega quando il rilevatore controlla un pacchetto. Utilizza quel timing quando testi. Lanciare l'app o spostarla in primo piano, quindi consentire al controllo di completarsi prima di decidere che l'aggiornamento ha fallito.

Controlla anche la versione nativa del bundle. Un bundle può esistere nel canale corretto eppure rimanere inaccessibile a causa della versione minima dell'app che non corrisponde al dispositivo. Leggi i dettagli della versione nel dashboard anziché presumere che l'ultimo upload si applichi a ogni installazione.

Se l'app supera questi controlli, hai ridotto la portata dell'errore. La prossima domanda è se la versione sia stata raggiunta dal canale intenzionato.

Passo 3: Verifica se la distribuzione abbia raggiunto il canale predefinito

La meta è confermare che il bundle esista nel canale risolto dal dispositivo. Caricare un bundle in un canale non lo rende disponibile in ogni canale.

Apre il canale in Capgo Cloud. Controlla il bundle attivo, la sua versione e lo stato di distribuzione. Confronta il nome del canale con il valore restituito dall'app. Guarda per piccole differenze comeproductionversusprodIl nome del canale deve corrispondere esattamente.

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

Controlla lo stato del bundle. Una bozza o una versione inattiva può essere visibile nel dashboard ma inaccessibile ai dispositivi. Se il canale ha una distribuzione in fase di test, il dispositivo interessato potrebbe non soddisfare la sua regola di distribuzione.

Usa 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.

Capgo's motore OTA in tempo reale è progettato per cambiamenti di layer web. Può spostare un bundle JavaScript, CSS o di un aggiornamento di asset senza attendere una nuova revisione del negozio. Quella velocità dipende dalla versione di rilascio attiva nel canale esatto in cui il dispositivo controlla.

Se hai cambiato il Cloud Default pochi momenti 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 scattare 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 controllo solo del dashboard perché mostra cosa il dispositivo crede.

Spera un ritardo se l'app controlla solo all'avvio o in primo piano. Non testare aprendo una schermata che non inizia 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 rilascio.

Se il canale restituito è corretto ma non arriva il bundle, passa alla compatibilità e alle regole di distribuzione. Se il canale restituito è sbagliato, torna al Passo 1 e cancella l'assegnazione che vince sul Cloud Default.

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

Lo scopo è separare uno stato locale invecchiato da un problema di consegna server-side. Una verifica fresca ti dà nuove prove.

Prima di tutto assicurati che il dispositivo abbia accesso a Internet. Una sessione di app riuscita non prova che l'aggiornatore possa raggiungere il suo endpoint. Filtri aziendali, regole VPN, porte captive 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 espone un evento di stato di aggiornamento, registra quell'evento con il canale corrente. Evita di registrare solo “aggiornamento iniziato.” Devi 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. Il primo 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 Internet o la richiesta del pacchetto.

Un reinstall è un test utile, ma cambia le prove. Il reinstall può eliminare 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 sola riga di log:

• ID dell'app e versione nativa dell'app
• Canale risolto dagetChannel()
• Ultimo controllo del tempo di aggiornamento
• Versione del pacchetto trovata dal server
• Risultato di 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 del dispositivo alla dashboard.

Prova utile: Cattura il canale risolto prima di cancellarlo. Altrimenti, potresti risolvere 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

L'obiettivo è verificare se Capgo ha intenzionalmente trattenuto o annullato il pacchetto. Un aggiornamento mancante è a volte una regola di sicurezza che funziona come progettato.

Apri le impostazioni del canale e revisiona ogni regola associata alla versione. Cerca le versioni minime dell'app, le impostazioni di percentuale di distribuzione, i filtri per dispositivi e le condizioni legate alla versione. Un dispositivo fuori dalla regola rimarrà sul suo bundle corrente anche se il canale è corretto.

Controlla anche il formato della versione. Capgo utilizza la versione semantica per confrontare le versioni. 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 costruzioni native e rilasci OTA.

Poi revisiona 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 la versione attiva precedente code mentre la versione che si aspetta rimane presente ma non disponibile.

Non cancellare un bundle sospetto prima di revisionare 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 le modifiche rischiose. 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, avanza la distribuzione. Ciò tiene una cattiva modifica del layer web lontana da ogni dispositivo attivo contemporaneamente.

Ripristina solo le code che OTA può modificare. Se il problema deriva da un plugin nativo mancante o da un plugin nativo API incompatibile, è necessario un nuovo build dello store. Invio di 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?
• Una verifica di salute o un'azione manuale l'ha riportato a un bundle più vecchio?

Capgo è utile qui perché lo stesso modello di canale può trasportare una rilascio in fase di staging, supportare un rollback e mostrare l'attività di aggiornamento in un flusso di lavoro. Mantieni il set di regole piccolo. Una politica breve è più facile da auditare di una pila di eccezioni create durante un incidente.

Se hai bisogno di API-based check, il La documentazione pubblica Capgo API descrive le risorse per dispositivi, canali e bundle. Utilizzalo per confrontare la vista del server con ciò che l'app segnala. Quel confronto può rivelare un filtro dashboard obsoleto o un'assegnazione di dispositivo creata da un'automazione.

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

Passo 6: Utilizza le Analisi in Tempo Reale per Trovare il Punto di Fallimento Esatto

Lo scopo è fermare di considerare 'non aggiornato' come un fallimento solo. Le analisi 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 annullato l'aggiornamento 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 una porta 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 pubblicazione suggerisce problemi di routing o di eleggibilità. Un aumento seguito da una caduta suggerisce errori di installazione o annullamento. Un aumento lento può semplicemente significare che i dispositivi non hanno ancora aperto l'app.

Usa i timestamp con attenzione. L'orario del dashboard degli eventi può differire dall'orario 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.

Le analisi possono anche aiutarti a testare un cambio di canale in modo sicuro. Cambia una variabile alla volta. Tieni il bundle costante mentre testi il routing. Poi tieni il routing costante mentre testi un nuovo bundle. 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
• Bundle previsto e bundle installato
• Ora del check-in finale
• Evento di annullamento 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 bundle, mentre un passaggio di monitoraggio controlla che i dispositivi di test riportino il canale e il bundle previsti. Ciò trasforma una lamentela manuale in un gate di rilascio.

Conserva i dati di analisi legati ai registri di rilascio. Scrivi la referenza di commit o build nelle note di distribuzione. Quando due bundle 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 la loro prossima verifica prima di modificare 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 che il Canale Predefinito si Invecchi

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.

Putnpx cap syncin the build path after configuration changes. Make the build fail if the sync step fails. The command is simple, but skipping it can bake yesterday’s channel into today’s native binary.

Aggiungi un test di fumo dopo la distribuzione. Il dispositivo di test dovrebbe avviare l'app e chiamaregetChannel()Controlla l'attesa bundle e registra il risultato. La verifica è spesso il passaggio mancante nei flussi di lavoro OTA. Un upload da solo non dimostra molto.

Conserva il canale locale code dietro una bandiera di feature chiara. Se un helper di test chiamasetChannel()Assicurati che le costruzioni di produzione non includano accidentalmente questo elemento. Ricorda che la cache locale non appare come sovrascrittura del dashboard, quindi l'interfaccia utente non può catturare ogni problema.

Usa un elenco di controllo di rilascio come questo:

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

Conserva la protezione del rollback per i rilasci di produzione. Un comune schema di fallimento è quello di distribuire senza un canale o un piano di rollback chiaro. Ciò lascia il team con meno vie sicure per fermare un bundle dannoso.

Capgo utilizza una sottoscrizione per organizzazione, con un periodo di prova di 14 giorni. Considera il periodo di prova come un'occasione per testare il flusso di rilascio su costruzioni di app reali, non solo per esaminare un dashboard. Prova una distribuzione in fase di staging, un test di rollback e un controllo automatico del canale.

La sicurezza appartiene allo stesso elenco di controllo. Proteggi i token CI/CD. Limita chi può modificare il Cloud Default. Tieni le credenziali di distribuzione di produzione fuori dai script locali. Un cambio di canale non autorizzato può sembrare un dispositivo obsoleto fino a quando non hai esaminato la traccia di audit.

Per le squadre che inviano spesso, mantieni il processo noioso. Un comando per distribuire. Un dispositivo di test noto. Una regola di canale chiara. Traccia, adotta, torna indietro.

Chiave di apprendimento: Prevenire la routing obsoleta sincronizzando la configurazione, evitando sovrascritture locali nascoste, testando il canale risolto e tenendo pronto il rollback.

FAQ

Perché il canale di default di Capgo cloud non aggiorna i dispositivi esistenti?

I dispositivi esistenti possono mantenere il loro vecchio canale fino al loro prossimo controllo di aggiornamento. Un canale locale, un sovrascrittura 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'app in primo piano.

Modificare il Cloud Default di Capgo cambia ogni app installata?

No, cambiare il Cloud Default non scrive immediatamente ogni installazione di app con il nuovo canale. 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 sovrascrittura locale si applica.

Cosa fa npx cap sync per un cambio di canale Capgo?

npx cap synccopia la configurazione aggiornata Capacitor nei progetti nativi. Se cambiatedefaultChannelma saltate la sincronizzazione, la prossima costruzione nativa potrebbe ancora contenere la impostazione del canale vecchia. Eseguite il comando dalla radice del progetto, quindi costruite e installate un binario di test fresco.

Does setChannel create a device override in 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().

Può Capgo aggiornare le code native tramite 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.

Conclusion

Inizia con il canale risolto, non quello impostato di default nel dashboard. Controlla le assegnazioni, eseguinpx 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()e conferma l'aspettativa di bundle.