Fix Capgo Standardkanal nicht aktualisiert Geräte

Ändern Sie die Cloud-Standard in 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.

Überprüfen Sie die Schritte in der Reihenfolge. Bestätigen Sie zunächst die Gerätezuweisung, dann die App-Build, den Synchronisierungsstatus, die Rollout-Regeln, die Protokolle und die Rollover-Einstellungen.

Inhaltsverzeichnis

• Schritt 1: Bestätige, dass das Gerät der Standardkanal zugeordnet ist
• Schritt 2: Überprüfen Sie die App, Native Runtime und Update-Kompatibilität
• Schritt 1: Bestätigen Sie, dass das Gerät der Standardkanal zugewiesen ist
• Schritt 4: Zwangsvollständigung und Überprüfung der Geräte-Protokolle
• Schritt 3: Bestätigen Sie, dass die Bereitstellung tatsächlich den Standardkanal erreicht hat
• Schritt 6: Verwenden Sie Echtzeit-Analysen, um den genauen Fehlerpunkt zu finden
• Schritt 7: Verhindere, dass der Standardkanal veraltet wird
• FAQ
• Zusammenfassung

Schritt 1: Bestätige, dass das Gerät dem Standardkanal zugewiesen ist

Das Ziel besteht darin zu ermitteln, welcher Regelwert derzeit den Gerätekanal bestimmt. Ein Cloud-Standard gilt nur, wenn eine stärkere Zuweisung das Gerät bereits beansprucht hat.

Öffnen Sie das Capgo-Dashboard und überprüfen Sie das betroffene Gerät. Prüfen Sie seinen aktuellen Kanal, App-ID, Version und letzten Anmeldezeitpunkt. Vergleichen Sie diese Werte mit einem Gerät, das die erwartete Aktualisierung erhalten hat. Diese Vergleich zeigt oft schnell den Fehler auf.

Channel selection follows an order. A forced channel has priority first. A dashboard or API device override comes next. A local channel set by the app follows that. Then Capgo checksdefaultChannelim native App-Konfiguration. Der Cloud-Standard ist der Ausfallmechanismus.

That order means a device can ignore a changed Cloud Default without any dashboard error. For example, a test build may still have a local channel from an earlier test. The app keeps using that local value until you clear it.

Verwenden Sie Capgo-Capgo-Updater-Debugging-Anleitung when the resolved channel is blank or unexpected. It covers the case where the app has no usable default and the device has no override.

Überprüfen Sie als Nächstes Ihre Capacitor-Konfiguration. Eine typische Einrichtung kann eine solche Kanal wie folgt umfassen:

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

Der Feldwert ist optional. Wenn Sie ihn auslassen, kann das Gerät die Cloud-Standardwerte übernehmen. Das kann für Produktionsbuilds gut funktionieren, da die Kanalroutung in der Capgo-Cloud bleibt. Wenn Sie ihn jedoch einfügen, stellen Sie sicher, dass der Wert dem tatsächlich bereitgestellten Kanal entspricht.

Suchen Sie nun nach lokalen Überschreibungen in der Anwendung code. Ein Aufruf zu setChannel()ändert den lokalen Cache. Er erstellt jedoch keinen Backend-Übertrag. Daher kann die Oberfläche möglicherweise keine Überschreibung anzeigt, obwohl die App weiterhin den lokalen Kanal verwendet.

Entfernen Sie diesen lokalen Wert, wenn das Gerät wieder auf normale Routing zurückkehren soll. Verwenden Sie den Plugin-Mechanismus, der die Geräte-Kanal-Zuweisung entfernt, oder entfernen Sie die code, die den Kanal festlegt, und installieren Sie die App neu, um einen sauberen Test durchzuführen.

Hauptschlussfolgerung: Ein geänderter Cloud-Standard kann eine stärkere Geräte-, App- oder lokale Kanalzuweisung nicht ersetzen.

Schritt 2: Überprüfen Sie die App, Native Runtime und Update-Kompatibilität

Ziel ist es, zu beweisen, dass die installierte App den bereitgestellten Bundle akzeptieren kann. Ein korrekter Kanal kann jedoch keine Aktualisierung an ein inkompatibles Native Runtime liefern.

Beginnen Sie mit der App-ID. Die auf dem Gerät installierte App muss die gleiche App-Identität wie das Projekt verwenden, in dem Sie den Bundle hochgeladen haben. Ein Missmatch kann wie ein Kanalproblem aussehen, weil das Gerät den falschen Capgo-App überprüft.

Vergleichen Sie dann die native Runtime-Version mit den Kompatibilitätsregeln des Bundles. Capgo Live-Updates können JavaScript, CSS und Web-Assets ändern. Sie können jedoch keine native Plugin hinzufügen oder die native Projektstruktur code nach dem Versand der App ändern. Native Änderungen benötigen immer noch eine neue Store-Build.

Denken Sie an die native Runtime als Rahmen um die Web-code. Wenn das neue Bundle eine native API erwartet, die die installierte App nicht hat, sollte Capgo es nicht anwenden. Erstellen und hochladen Sie eine kompatible native Version, bevor Sie das Bundle testen.

Überprüfen Sie die Version und die Plattform der installierten App. Testen Sie zunächst ein Android-Bundle auf Android. Testen Sie ein iOS-Bundle auf iOS. Bestätigen Sie auch, dass das Bundle die richtige App-Version ansteuert, wenn Ihr Kanal Versionssperren verwendet.

Nachdem Sie geändert habendefaultChannelFühren Sie den Synchronisierungsbefehl vom Projektroot aus:

npx cap sync

Dieser Schritt kopiert die aktualisierte Konfiguration in die native Projekte. Die Bearbeitungcapacitor.configohne Synchronisierung lässt die native App auf ihrem alten Kanal-Setting. Ein frischer Build aus diesem veralteten native Projekt wird immer noch das gleiche Ergebnis reproduzieren.

For a clean test, build a new app after syncing. Do not rely on an old binary installed on your phone. Uninstall it when you need to remove cached local channel state, then install the new build and check the channel again.

Die Capgo Aktualisierungsverhaltensdokumentation erklärt, wann der Updater nach einem Bundle sucht. Verwenden Sie diese Zeitung, wenn Sie testen. Starten Sie die App oder bewegen Sie sie wieder in den Vordergrund, dann lassen Sie den Check ablaufen, bevor Sie entscheiden, dass die Aktualisierung fehlgeschlagen ist.

Außerdem überprüfen Sie die native Versionsgrenze des Bundles. Ein Bundle kann sich im richtigen Kanal befinden und trotzdem nicht verfügbar sein, weil seine Mindestanwendungsversion nicht mit der Geräteversion übereinstimmt. Lesen Sie die Release-Details im Dashboard anstatt anzunehmen, dass die neueste Upload-Anwendung auf jeden Installationsprozess angewendet wird.

Wenn die Anwendung diese Prüfungen besteht, haben Sie den Fehler bereits eingedämmt. Die nächste Frage ist, ob die Veröffentlichung überhaupt in den gewünschten Kanal gelangt ist.

Schritt 3: Bestätigen Sie, dass die Bereitstellung tatsächlich in den Standardkanal gelangt ist

Ziel ist es, zu bestätigen, dass das Bundle im Kanal existiert, den das Gerät auflöst. Ein Upload eines Bundles in einen Kanal macht es nicht verfügbar in jedem Kanal.

Öffnen Sie den Kanal in Capgo Cloud. Überprüfen Sie die aktive Bundle, seine Version und seinen Bereitstellungszustand. Vergleichen Sie den Kanalnamen mit dem Wert, der von der Anwendung zurückgegeben wird. Achten Sie auf kleine Unterschiede wieproductiongegenüberprod. Die Kanalnamen müssen genau übereinstimmen.

Wenn Sie über CI/CD bereitstellen, überprüfen Sie die Ausgabe der Befehlsausgabe aus demselben Job, der das Bundle hochgeladen hat. Bestätigen Sie die Anwendung-ID und den Kanal, der an CLI übergeben wurde. Ein Pipeline kann mit einem erfolgreichen Upload abschließen, während sie versehentlich einen Staging-Kanal ansteuert.

Überprüfen Sie den Status des Bundles. Ein Entwurf oder eine inaktive Veröffentlichung kann im Dashboard sichtbar sein, aber für Geräte nicht verfügbar sein. Wenn der Kanal eine rollende Veröffentlichung hat, kann das betroffene Gerät möglicherweise nicht die Rollout-Regel erfüllen.

Verwenden Sie ein bekanntes Testgerät. Geben Sie ihm eine klare Rolle. Zum Beispiel, pinnen Sie ein Gerät an einem Testkanal und lassen Sie ein anderes Gerät auf dem Cloud-Standard. Laden Sie eine harmlose Änderung hoch, dann vergleichen Sie ihre Eincheck-Records. Dies entfernt das Rätselraten aus der Testung.

Capgo’s Live-OTA-Motor ist für Änderungen auf der Web-Schicht konzipiert. Es kann eine JavaScript-Bundle, CSS oder Asset-Update ohne Warten auf eine neue Store-Überprüfung bewegen. Diese Geschwindigkeit hängt von der Aktivität der Veröffentlichung in dem genauen Kanal ab, den das Gerät überprüft.

Wenn Sie den Cloud-Standard vor Kurzem geändert haben, beachten Sie die Geräte-Zeit. Neue Installationen verwenden den neuen Routen sofort. Bestehende Geräte wechseln normalerweise, wenn sie ihre nächste Update-Überprüfung durchführen. Das Schließen und Wiederöffnen der App kann dabei helfen, diesen Check auszulösen, kann aber einen gepinnten Kanal nicht überschreiben.

Nun überprüfen Sie das Ergebnis innerhalb der App. Rufen SiegetChannel()nachdem der Updater gestartet ist. Loggen Sie die zurückgegebene Kanal neben der App-Version und der Bundle-Version. Dies ist nützzer als nur die Überprüfung der Dashboard, da es zeigt, was das Gerät glaubt.

Erwarten Sie eine Verzögerung, wenn die App nur auf dem Start oder im Vordergrund überprüft. Testen Sie nicht, indem Sie eine Seite öffnen, die nie den Updater startet. Platzieren Sie den Check in einem bekannten Startpfad für einen kurzen Testbuild, dann entfernen Sie das extra Logging vor der Veröffentlichung.

Wenn der zurückgegebene Kanal richtig ist, aber keine Bundle ankommt, gehen Sie zu Kompatibilität und Rollout-Regeln über. Wenn der zurückgegebene Kanal falsch ist, gehen Sie zurück zu Schritt 1 und löschen Sie die Zuweisung, die über den Cloud-Standard gewinnt.

Schritt 4: Zwangsvollständigung und Überprüfung der Geräte-Protokolle

Das Ziel ist es, einen veralteten lokalen Zustand von einem serverseitigen Lieferungsproblem zu trennen. Ein frischer Check-in gibt Ihnen neue Beweise.

Zuerst stellen Sie sicher, dass das Gerät Zugriff auf das Netzwerk hat. Ein erfolgreicher App-Session beweist nicht, dass der Updater seinen Endpunkt erreichen kann. Unternehmensfilter, VPN-Regeln, Captive-Portale oder ein abgelaufenes Sitzung kann die Aktualisierungsanfrage blockieren.

Nächstens bringen Sie die App in den Vordergrund. Warten Sie, bis der Updater-Check abgeschlossen ist. Wenn Ihre App ein Aktualisierungsstatusereignis ausgibt, loggen Sie dieses Ereignis mit dem aktuellen Kanal. Vermeiden Sie es, nur “Aktualisierung gestartet” zu loggen. Sie müssen wissen, ob die App eine Pakete gefunden, heruntergeladen, überprüft, installiert oder abgelehnt hat.

Verwenden Sie Capgo’s Geräteprotokolle, um die erste fehlgeschlagene Stufe zu finden. Die erste Fehlermeldung ist meist nützlicher als die endgültige “Aktualisierung fehlgeschlagen”-Meldung. Zum Beispiel weist ein fehlender Kanal auf Routing hin. Eine Kompatibilitätsablehnung weist auf das native Runtime oder die Versionskontrolle hin. Ein Downloadfehler weist auf Netzwerkzugriff oder die Paketanfrage hin.

Ein erneutes Installieren ist ein nützliches Test, aber es ändert die Beweise. Durch erneutes Installieren kann der lokale Kanalzustand gelöscht werden. Verwenden Sie es nachdem Sie den aktuellen Kanal und die Protokolle erfasst haben, nicht vorher.

Für eine wiederholte Überprüfung, notieren Sie diese Werte in einer Logzeile auf:

• App-ID und native App-Version
• Abgeleiteter Kanal vongetChannel()
• Letzte Überprüfung durch den Updater
• Bundle-Version, die vom Server gefunden wurde
• Installations- oder Ablehnungsresultat

Dieses kleine Protokoll hilft, wenn das Gerät einem Tester gehört, der das Problem nicht auf Anfrage reproduzieren kann. Es gibt auch Ihrem CI-Team einen klaren Signal für automatisierte Rauchtests.

Verwenden Sie den offiziellen Capgo Capacitor Updater-Quellcode-Repository, wenn Sie das Plugin API-Verhalten untersuchen müssen. Insbesondere achten Sie auf die Differenz zwischen einer lokalen Kanaländerung und einer Dashboard-Gerätezuweisung.

Pro-Tipp: Erteilen Sie dem aufgelösten Kanal vor dem Löschen Priorität. Ansonsten verlieren Sie die Klarstellung, die das Versagen erklärt hat.

Schritt 5: Überprüfen Sie die Rollout-Regeln, die Versionsgitter und die automatische Rückschaltung

Das Ziel ist es, zu überprüfen, ob Capgo absichtlich die Verpackung zurückgehalten oder umgekehrt hat. Ein fehlender Update ist manchmal eine Sicherheitsregel, die wie geplant funktioniert.

Öffnen Sie die Kanal-Einstellungen und überprüfen Sie jede Regel, die der Veröffentlichung zugewiesen ist. Suchen Sie nach Mindestanforderungen an die App-Version, Prozentsatz-Einstellungen für die Ausrollung, Gerätefiltern und Bedingungen, die der Veröffentlichung zugeordnet sind. Ein Gerät außerhalb der Regel bleibt bei seiner aktuellen Paketeinstellung, selbst wenn der Kanal korrekt ist.

Überprüfen Sie auch die Versionsformatierung. Capgo verwendet semantische Versionsierung, um Veröffentlichungen zu vergleichen. Eine Versionsgrenze, die einem Menschen richtig aussieht, kann sich anders verhalten, wenn die App oder das Paket eine unerwartete Formatierung verwendet. Halten Sie die Formatierung konsistent zwischen native Builds und OTA-Veröffentlichungen.

Dann überprüfen Sie das Rollback-Verhalten. Ein automatisches Rollback kann ein Gerät zurück auf eine vorherige Paketeinstellung versetzen, nachdem eine gescheiterte Gesundheitsprüfung erfolgt ist. Das Dashboard kann die ältere aktive code anzeigen, während die Veröffentlichung, die Sie erwarten, zwar anwesend, aber nicht verfügbar ist.

Löschen Sie ein verdächtiges Paket nicht, bevor Sie seine Ereignisse überprüft haben. Die Löschung entfernt wertvolle Beweise. Zuerst notieren Sie die Paketeinstellung, den Kanal, den Ausrollungsstatus und den Rollback-Grund. Dann entscheiden Sie, ob Sie die Veröffentlichung aussetzen oder eine bekannte gute Version veröffentlichen.

Verwenden Sie einen gestaffelten Kanal für riskante Änderungen. Senden Sie das Paket an einen kleinen Testgruppe zuerst. Beobachten Sie die Adoption und die Fehlermeldungen. Sobald die Veröffentlichung wie erwartet verhält, können Sie die Ausrollung vorwärts bewegen. Dies verhindert, dass eine schlechte Web-Schicht-Änderung auf einmal an alle aktiven Geräte gelangt.

Rücksetzung repariert nur code die OTA ändern kann. Wenn das Problem von einem fehlenden nativen Plugin oder einem inkompatiblen nativen API kommt, benötigen Sie einen neuen Store-Build. Ein älterer JavaScript-Bundle sendet nicht die nativen Teile, die das App fehlt.

Wenn Sie eine Regel untersuchen, stellen Sie drei Fragen:

• Erfüllt das Gerät die Anforderungen an die App-Version?
• Findet sich das Gerät in der Rollout-Gruppe?
• Hat eine Gesundheitsprüfung oder eine manuelle Aktion es auf eine ältere Bundle zurückgesetzt?

Capgo ist hier nützlich, weil der gleiche Kanalmodell eine gestufte Veröffentlichung, eine Rückschaltung und Aktivitäten zur Aktualisierung in einem Workflow unterstützen kann. Halten Sie die Regelmenge klein. Ein kurzer Richtlinienkatalog ist einfacher zu überprüfen als eine Stapel von Ausnahmen, die während eines Vorfalls erstellt wurden.

Wenn Sie API-basierte Überprüfungen benötigen, Capgo öffentliche API Dokumentation beschreibt Ressourcen für Geräte, Kanäle und Bundles. Verwenden Sie sie, um den Serverblick mit dem Bericht des Apps zu vergleichen. Diese Vergleich kann einen veralteten Dashboard-Filter oder eine von der Automatisierung erstellte Gerätezuweisung offenlegen.

Rückschaltung ist ein Schutzzaun, kein Ersatz für Tests. Halten Sie eine bekannte-gute-Bundle in jedem Produktionskanal bereit.

Schritt 6: Verwenden Sie Real-Time-Analytics, um den genauen Ausfallpunkt zu finden

Das Ziel ist es, "nicht aktualisiert" nicht als ein einzelnes Versagen zu behandeln. Die Analytics können anzeigen, ob das Gerät nie angemeldet wurde, keine geeignete Bundle gefunden hat, während des Downloads gescheitert ist oder später zurückgerollt wurde.

Beginnen Sie mit der betroffenen Gerätegruppe. Filtern Sie nach App-Version, Plattform, Kanal und Bundle-Version. Suchen Sie nach einem Muster. Wenn nur ein alter App-Build scheitert, könnte das Problem ein nativ kompatibilitätsrelevanter Gate sein. Wenn alle Geräte in einem Kanal scheitern, überprüfen Sie den Kanal oder die Bereitstellung.

Vergleichen Sie die Adoption im Laufe der Zeit. Ein flaches Line nach der Veröffentlichung deutet auf Routing- oder Zulassungsprobleme hin. Ein Anstieg gefolgt von einem Rückgang deutet auf Installationsfehler oder Rollbacks hin. Ein langsamer Anstieg könnte einfach bedeuten, dass die Geräte das App noch nicht geöffnet haben.

Verwenden Sie Zeitstempel sorgfältig. Die Zeit des Dashboard-Ereignisses kann sich von der lokalen Uhrzeit des Benutzers unterscheiden. Passen Sie das Update-Ereignis mit der letzten Anmeldung des Geräts ab. Dies hilft, wenn ein Tester sagt, das Update habe vor der tatsächlichen Anmeldung gescheitert.

Die Analytics hilft Ihnen auch dabei, einen Kanalwechsel sicher zu testen. Ändern Sie eine Variable nach der anderen. Halten Sie die Bundle konstant, während Sie das Routing testen. Dann halten Sie das Routing konstant, während Sie eine neue Bundle testen. Wenn Sie beide ändern, kann die Daten nicht sagen, welche Änderung das Problem gelöst hat.

Für ein Incident speichern Sie ein kleines Beweisset:

• Das Geräte-Identifikator oder der interne Test-Label
• Der gelöste Kanal
• Die native App-Version
• Die erwartete Bundle und die installierte Bundle
• Die letzte Anmeldung
• Der Rollback- oder Rejektions-Ereignis

Capgo’s Echtzeit-Ansicht ist am nützlichsten, wenn Ihr Release-Prozess Updates über CI/CD sendet. Ein Bereitstellungsjob kann ein Bundle hochladen, während ein Überwachungsschritt überprüft, ob Testgeräte den beabsichtigten Kanal und Bundle melden. Das verwandelt einen manuellen Beschwerde in eine Release-Sperre.

Bleiben Sie die Analytics-Daten an den Release-Records gebunden. Schreiben Sie den Commit- oder Build-Bezug in Ihren Bereitstellungsnotizen. Wenn zwei Bundles ähnliche Versionsetiketten haben, sagt der Build-Bezug Ihnen, welches code tatsächlich aktualisiert wurde.

Wenn nur bestehende Geräte nach einer Änderung des Cloud-Defaults fehlschlagen, warten Sie auf ihren nächsten Check-in, bevor Sie weitere Einstellungen ändern. Ein neuer Installationsprozess ist ein nützlicher Kontrollpunkt. Er sagt Ihnen, ob die Standardroute für Geräte mit keinem alten lokalen Zustand funktioniert.

Schritt 7: Verhindern, dass der Standardkanal veraltet wird

Das Ziel ist es, den Kanalverschiebung sichtbar zu machen, bevor sie die Benutzer beeinträchtigen. Ein kleiner Release-Checklist kann die meisten Wiederholungsfälle verhindern.

Wählen Sie für jede App-Umgebung ein Routing-Modell. Für die Produktion können Sie es überspringendefaultChanneland 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 syncFügen Sie nach der Bereitstellung einen Rauchtest hinzu. Das Testgerät sollte die Anwendung starten, die Anwendung aufrufen und die Ergebnisse überprüfen.

Fügen Sie nach der Bereitstellung einen Rauchtest hinzu. Das Testgerät sollte die App starten und aufrufen.getChannel()Überprüfen Sie das erwartete Bundle und dokumentieren Sie das Ergebnis. Die Verifizierung ist oft der fehlende Schritt in OTA-Workflows. Ein Upload allein beweist sehr wenig.

Halten Sie die lokale Kanal code hinter einem klaren Feature-Flag zurück. Wenn ein Test-Helfer aufruftsetChannel()Stellen Sie sicher, dass Produktionsbuilds versehentlich nicht enthalten sind. Beachten Sie, dass der lokale Cache möglicherweise nicht als Dashboard-Übernahme erscheint, sodass die Benutzeroberfläche nicht jeden Fehler erkennen kann.

Verwenden Sie einen Release-Checkliste wie folgt:

1. Bestätigen Sie die App-ID und die native Version.
2. Wählen Sie den Zielkanal.
3. Uploaden Sie das Bundle in den Zielkanal.
4. Bestätigen Sie, dass das Bundle aktiv ist.
5. Laufen Sie den Gerätesmoke-Test.
6. Überprüfen Sie die zurückgegebene Kanal mitgetChannel().
7. Beobachten Sie die Adoption, bevor Sie die Rollout erweitern.

Halten Sie die Rollback-Schutzfunktion für Produktionsfreisetzungen aktiv. Ein häufiges Fehlermuster ist, ohne klaren Kanal oder Rollback-Plan zu deployen. Das lässt dem Team weniger sichere Möglichkeiten, einen schlechten Bundle zu stoppen.

Capgo verwendet eine Abonnement pro Organisation, mit einer 14-tägigen kostenlosen Testphase. Behandeln Sie die Testphase als Chance, Ihren Release-Flow auf echten App-Builds zu testen, nicht nur, um eine Dashboard-Ansicht zu überprüfen. Versuchen Sie einen aufgeteilten Bereitstellungsprozess, einen Rollback-Test und eine automatisierte Kanalprüfung.

Die Sicherheit gehört in das gleiche Kontrollkästchen. Schützen Sie die CI/CD-Tokens. Limitieren Sie, wer den Cloud-Standard ändern kann. Halten Sie die Produktionsbereitstellungskredenziale aus lokalen Skripten heraus. Ein unautorisiertes Kanalwechsel kann wie ein veralteter Gerät aussehen, bis Sie die Audit-Trail überprüfen.

Für Teams, die oft liefern, halten Sie den Prozess langweilig. Eine Befehlszeile zum Bereitstellen. Ein bekanntes Testgerät. Eine klare Kanalregel. Verfolgen, annehmen, zurückrollen.

Hauptnachricht: Verhindern Sie veraltete Routen, indem Sie die Konfiguration synchronisieren, lokale, versteckte Überlagerungen vermeiden, den aufgelösten Kanal testen und einen Rollback bereitstellen.

FAQ

Warum wird der Capgo-Cloud-Standardkanal nicht auf bestehende Geräte aktualisiert?

Existing devices may keep their old channel until their next update check. A local channel, dashboard override, or forced assignment can also take priority over the Cloud Default. Confirm the device’s resolved channel withgetChannel(), löschen Sie alle stärkeren Zuweisungen, dann bringen Sie die App in den Vordergrund.

Ändert sich der Capgo Cloud Standard bei jeder installierten App?

Nein, das Ändern des Cloud-Standards ändert den Channel der installierten Apps nicht sofort. Neue Geräte können den neuen Standard sofort verwenden. Bestehende Installationen müssen sich vorher anmelden, bevor sie umschalten können, und sie werden auch nicht umschalten, wenn eine stärkere Channel-Regel oder eine lokale Überschreibung gilt.

Was tut npx cap sync bei einem Capgo-Channel-Wechsel?

npx cap synckopiert aktualisierte Capacitor-Konfigurationen in die native Projekte. Wenn Sie den Channel änderndefaultChannelWenn Sie den Sync auslassen, kann die nächste native Build noch den alten Channel-Einstellung enthalten. Führen Sie den Befehl vom Projekt-Root aus, dann bauen und installieren Sie ein frisches Test-Programm.

Erstellt setChannel einen Geräte-Überschreibung in Capgo?

NeinsetChannel()ändert den Channel, der lokal vom App gespeichert ist. Es erstellt keine Backend-Geräte-Überschreibung, daher kann der Capgo-Dashboard die Geräte nicht als überschrieben anzeigen. Löschen Sie die lokale Zuweisung, wenn das Gerät wieder auf die Standardrouting zurückkehren soll, dann überprüfen Sie das Ergebnis mitgetChannel().

Kann Capgo native code über eine OTA-Bundle aktualisieren?

Nein, Capgo-OTA-Updates gelten nur für die web-schicht code wie JavaScript, CSS und Assets. Ein native Plugin, eine Berechtigung oder eine native API-Änderung benötigt einen neuen Store-Build. Wenn die Bundle native code erwartet, die die installierte App nicht hat, kann die Aktualisierung auch dann abgelehnt werden, wenn der Channel korrekt ist.

Zusammenfassung

Starte mit dem aufgelösten Kanal, nicht mit dem Dashboard-Standard. Überprüfe Zuweisungen, führenpx cap sync, überprüfen Sie die Bundle gegen die native Ausführungsumgebung und inspizieren Sie die Geräte-Protokolle, bevor Sie die Ausrollungsregeln ändern. Dann fügen Sie einen kleinen Post-Deploy-Test in Capgo hinzu, dergetChannel()und bestätigt die erwartete Pakete.