Risoluzione Capgo Canale predefinito non aggiorna dispositivi

__CAPGO_KEEP_0__ Capgo le dispositivi nuovi vengono configurati immediatamente. Gli installi esistenti possono rimanere sul loro canale vecchio fino a quando non si connettono nuovamente, il che spiega molti casi in cui il canale cloud predefinito di Capgo non aggiorna i dispositivi.

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

Tavola 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 sia effettivamente arrivata al canale predefinito.
• Passo 4: Forza una sincronizzazione fresca e ispeziona i log del dispositivo.
• Passo 5: Recensisci 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 da diventare obsoleto.
• Domande frequenti
• Conclusioni

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

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

Apre il Capgo dashboard e ispeziona il dispositivo interessato. Controlla il suo canale corrente, ID app, versione e ultima data di accesso. Confronta 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 obbligatorio ha priorità prima. Un dispositivo dashboard o API viene successivamente. Un canale locale impostato dall'app segue quello. Poi Capgo controlladefaultChannelle impostazioni native dell'app. Il Cloud Default è il fallback.

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

Utilizza 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 override.

Successivamente, controlla la tua configurazione Capacitor. Una configurazione tipica può includere un canale di questo tipo:

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 Cloud Capgo. Se lo includi, assicurati che il valore corrisponda al canale che effettivamente distribuisci.

Now cerca le sovrapposizioni locali nell'applicazione code. Una chiamata asetChannel()modifica il cache locale. Non crea un dispositivo di sovrapposizione backend. Il dashboard potrebbe quindi non mostrare alcuna sovrapposizione anche se l'app continua a 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'applicazione per un test pulito.

Chiave di apprendimento: Un Cloud Default modificato non può sostituire un'impostazione 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 caricato. Un canale corretto non può ancora consegnare 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 disallineamento può sembrare un problema di canale perché il dispositivo controlla l'app Capgo sbagliata.

Poi confronta la versione del runtime nativo con le regole di compatibilità del pacchetto. I Capgo live updates 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 build del negozio.

Ripensi alla runtime nativa come il frame attorno al web code. Se il nuovo pacchetto aspetta una API nativa che l'app installata non ha, Capgo non dovrebbe applicarla. 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 punti alla versione dell'app corretta quando il tuo canale utilizza porte di versione.

Dopo aver cambiatodefaultChannelEseguisci 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. Un nuovo build da quel progetto nativo invecchiato continuerà a riprodurre lo stesso risultato.

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

La Capgo documentazione del comportamento di aggiornamento spiega quando il rilevatore di aggiornamenti controlla un pacchetto. Utilizza quel timing quando testi. Lancia l'app o spostala nuovamente in primo piano, quindi consenti al controllo di completarsi prima di decidere che l'aggiornamento è fallito.

Inoltre, controlla la porta di versione nativa del pacchetto. Un pacchetto può esistere nel canale corretto eppure rimanere inaccessibile perché la sua versione minima non corrisponde al dispositivo. Leggi i dettagli della rilascio nella dashboard anziché presumere che l'ultimo caricamento si applichi a ogni installazione.

Se l'app supera questi controlli, hai ridotto la portata del difetto. La prossima domanda è se la versione raggiungesse il canale destinato in alcun modo.

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

L'obiettivo è confermare che il pacchetto esista nel canale risolto dal dispositivo. Caricare un pacchetto in un canale non lo rende disponibile in tutti i canali.

Aprite il canale in Capgo Cloud. Controllate il pacchetto attivo, la sua versione e lo stato di distribuzione. Confrontate il nome del canale con il valore restituito dall'app. Tenete d'occhio piccole differenze comeproductionversusprod. I nomi dei canali devono corrispondere esattamente.

Se distribuite attraverso CI/CD, ispezionate l'output del comando proveniente dallo stesso job che ha caricato il pacchetto. Confermate l'ID dell'app e il canale passati a CLI. Un flusso di lavoro può concludersi con un upload riuscito mentre si mira a un canale di staging per errore.

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

Usate un dispositivo di test noto. Assegnategli un ruolo chiaro. Ad esempio, fissate un dispositivo a un canale di test e lasciate un altro dispositivo sul Cloud Default. Caricate una modifica innocua, quindi confrontate i loro registri di check-in. Ciò elimina la congettura dal test.

l'Capgo's motore OTA in tempo reale è 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 in rilascio attiva nel canale esatto che il dispositivo controlla.

Se hai modificato i momenti di default Cloud poco fa, ricorda il tempo del dispositivo. Le nuove installazioni utilizzano la nuova rotta subito. I dispositivi esistenti cambiano di solito 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 pannello di controllo perché mostra cosa il dispositivo crede.

Spera in un ritardo se l'app controlla solo al lancio 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 sui momenti di default Cloud.

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

Il tuo obiettivo è separare uno stato locale invecchiato da un problema di consegna dal server. Un controllo fresco ti dà nuove prove.

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

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 lo ha rifiutato.

Utilizza i registri del dispositivo di Capgo per trovare la prima fase fallita. Il primo errore è spesso più utile del messaggio finale “aggiornamento fallito.” Ad 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 del 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 controllo del tempo di aggiornamento
• Versione del pacchetto trovata dal server
• Risultato di installazione o rifiuto

Quel piccolo record 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.

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

Pro Tip: Cattura il canale risolto prima di cancellarlo. 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

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

Apri le impostazioni del canale e revisiona ogni regola legata alla versione. Cerca versioni minime dell'app, impostazioni di percentuale di distribuzione, filtri di dispositivo e condizioni legate alla versione. 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 rilasci. Una porta di versione che sembra corretta per una persona può comportarsi in modo diverso se l'app o il pacchetto utilizza un formato inaspettato. Mantieni il formato coerente tra le costruzioni native e i rilasci OTA.

Poi verifica il comportamento di rollback. Un rollback automatico può spostare un dispositivo indietro a un pacchetto precedente dopo un controllo di salute fallito. La dashboard può mostrare il vecchio pacchetto attivo code mentre il rilascio che si aspetta rimane presente ma non disponibile.

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

Utilizza un canale a fasi per le modifiche rischiose. Invia il pacchetto a un piccolo gruppo di test. Guarda l'adozione e i segnali di errore. Una volta che il rilascio si comporta come previsto, procedi con la distribuzione. Ciò evita che una cattiva modifica del layer web raggiunga ogni dispositivo attivo contemporaneamente.

Riprista solo i code che OTA può modificare. Se il fallimento proviene da un plugin nativo mancante o da un API nativo incompatibile, è necessario un nuovo build dello store. Invio 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 spostato a un pacchetto più vecchio?

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

Se hai bisogno di controlli basati su API- Capgo la documentazione pubblica API descrive le risorse per dispositivi, canali e bundle. Utilizzala per confrontare la vista del server con ciò che il'app segnala. Quel confronto può rivelare un filtro del dashboard obsoleto o un'assegnazione di dispositivo creata da un'automazione. Le regole di distribuzione OTA versionano le porte di sicurezza e il flusso di lavoro di rollback automatico

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

L'obiettivo è smettere di trattare “non aggiornato” come un unico fallimento. 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 fatto un rollback successivo.

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

Confronta l'adozione nel tempo. Una linea piatta dopo il 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.

__CAPGO_KEEP_1__

Usa i timestamp con cura. L'orario degli eventi del pannello di controllo potrebbe differire dall'orario locale dell'utente. Assicurati di sincronizzare l'evento di aggiornamento con l'ultimo controllo del dispositivo. Ciò è utile quando un tester dice che l'aggiornamento è fallito prima che l'applicazione avesse effettivamente controllato.

Gli analytics ti aiutano a testare un cambio di canale in modo sicuro. Cambia una variabile alla volta. Mantieni costante il bundle mentre testi la routing. Poi mantieni costante la routing mentre testi un nuovo bundle. Se cambi entrambi, i dati non potranno dirti quale cambio ha risolto il problema.

In caso di incidente, salva un piccolo set di prove:

• L'identificatore del dispositivo o il marchio di test interno
• Canale risolto
• Versione dell'app nativa
• Bundle previsto e bundle installato
• Ultimo controllo del dispositivo
• Evento di rollback o di rifiuto

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

Leggi i dati degli analytics ai record di rilascio. Scrivi la referenza di commit o di build nelle note di deployment. 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 il loro prossimo controllo prima di cambiare altre impostazioni. Un nuovo install è un control utile. Ti dice se il percorso predefinito funziona per i dispositivi che non hanno stato locale vecchio.

Step 7: Prevenire il Canale Predefinito da Diventare Obsoleto

Lo scopo è rendere visibile la deriva del canale prima che influisca sugli utenti. Un piccolo elenco di rilascio può prevenire la maggior parte dei casi di ripetizione.

Scegliere un modello di routing per ogni ambiente di app. Per la produzione, puoi ometteredefaultChannele lasciare che Capgo Cloud controlli il canale predefinito. Per un build di test, puoi impostare un canale esplicito. La configurazione pericolosa è una miscela di vecchie sovrapposizioni locali, di una configurazione nativa obsoleta e di un nuovo Cloud Default che nessuno verifica.

Inserirenpx 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 cuocere il canale di ieri nel binario nativo di oggi.

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

Tenere 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. Ricorda che la cache locale non appare come sovrapposizione del dashboard, quindi l'interfaccia utente non può catturare ogni problema.

Utilizzare un elenco di rilascio come questo:

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

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 pacchetto 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 costrutti di app reali, non solo per esaminare un dashboard. Prova un'unica distribuzione in fase di staging, un unico test di rollback e un unico controllo del canale automatizzato.

La sicurezza appartiene alla stessa checklist. Proteggi i token di CI/CD. Limita chi può modificare il Cloud Default. Tieni i 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 i team 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: Prevenire la navigazione obsoleta sincronizzando la configurazione, evitando sovrascritture locali nascoste, testando il canale risolto e mantenendo pronto il rollback.

Domande frequenti

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

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

La modifica del canale Cloud Default di Capgo cambia ogni applicazione installata?

No, la modifica del Cloud Default non scrive immediatamente il canale di ogni installazione di applicazioni. 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 le configurazioni aggiornate Capacitor nei progetti nativi. Se cambidefaultChannelma salti la sincronizzazione, la prossima costruzione nativa potrebbe ancora contenere la impostazione del canale vecchia. Esegui il comando dalla radice del progetto, quindi costruisci e installa un binario di test fresco.

La funzione setChannel crea un sovrapposizione del dispositivo in Capgo?

No,setChannel()modifica il canale memorizzato localmente dall'applicazione. Non crea un sovrapposizione del dispositivo backend, quindi il pannello di controllo Capgo potrebbe non mostrare il dispositivo come sovrapposto. Cancella l'assegnazione locale quando il dispositivo dovrebbe tornare alla routing predefinito, quindi verifica il risultato congetChannel().

Può Capgo aggiornare i componenti nativi code tramite un bundle OTA?

No, gli aggiornamenti OTA di Capgo si applicano ai layer web code come JavaScript, CSS e risorse. Un plugin nativo, una autorizzazione o un cambio di API nativo richiede una nuova costruzione dello store. Se il bundle aspetta code nativi che l'app installata non possiede, l'aggiornamento potrebbe essere rifiutato anche quando il canale è corretto.

Conclusioni

Inizia con il canale risolto, non con quello predefinito della dashboard. Controlla le assegnazioni, esegui npx cap sync, verifica il bundle 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 chiama getChannel()e conferma il bundle previsto.