Häufige Updateprobleme

Wenn eine Aktualisierungskontrolle fehlschlägt, Capgo gibt normalerweise einen error code und ein message in der /updates Antwort zurück. Diese Seite erklärt die häufigsten Fehler und die schnellsten Lösungen.

Lesen Sie das zuerst

• no_new_version_available ist ein normales Zustand, kein Fehler.
• Viele „Update gefunden, aber nicht angewendet“-Berichte sind Politik/Konfigurationsverweigerungen anstatt Cache-Lag, insbesondere wenn die Antwort einen expliziten error code.
• Verwenden npx @capgo/cli@latest app debug während Sie das Problem nachahmen, um Anforderungs/Antwortdetails zu sehen.

Häufige Fehlercodes

provider_infrastructure_request_blocked

Ursache

Die App hat Blocken Sie Anfragen auf Infrastruktur des Anbieters aktiviert und die Anfrage stammt aus einem bekannten IP-Range von Google oder Apple Datenzentren. Capgo blockiert diese Anfragen auf /updates, /stats, und /channel_self um sicherzustellen, dass Traffic vom Anbieter nicht als Geräte-Traffic behandelt wird.

Fixieren

• Wiederholen Sie die Aktualisierung von einem physischen Gerät auf einem normalen Benutzer-Netzwerk.
• Verwenden Sie während dieser Schutzfunktion nicht cloud-gesteuerte Proben oder Anbieter-Datenzentrum-Runner für Updater, Statistiken oder Channel-Self-Überprüfungen.
• Wenn dieser Traffic absichtlich ist, öffnen Sie das Informationen Fenster und schalten Sie Blocken Sie Anfragen auf Infrastruktur des Anbieterswieder ein, wenn der Test abgeschlossen ist.

Neue Apps haben diese Schutzfunktion standardmäßig aktiviert. Apps, die vor der Einführung der Einstellung erstellt wurden, haben sie deaktiviert, bis Sie sie aktivieren.

Antwortdetails

• /updates erhält die Aktualisierungsantwortkontrakt und gibt HTTP 200Sein Körper umfasst error, message, kind: "blocked"oder provider ("google" und "apple").
• /stats gibt HTTP /channel_self mit dem gleichen Fehler __CAPGO_KEEP_0__. Behandeln Sie dies als eine absichtliche Richtlinienblockierung und nicht als eine vorübergehende Wiederholungsbedingung. 429 with the same error code. Treat this as an intentional policy block, not a transient retry condition.

disable_auto_update_to_major

Ihr Kanal blockiert Major-Updates (

Ihr Kanal blockiert Major-Updates (disable_auto_update = majorund die Ziel-Bundle-Major-Version liegt über der Geräte-Baseline-Version.

Typisches Symptom

version: 1.0.8 mit old: 0.0.0 bedeutet, dass das Gerät die Baseline 0.0.0, also werden Major-Upgrades abgelehnt.

Wie interpretiert man das?

Der Backend vergleicht die Major-Versionen mithilfe der Geräte-Baseline old und Ziel version.

• Wenn Ziel ist 1.0.1, muss die Baseline-Major-Version 1 (z.B. 1.0.0).
• Wenn Ziel ist 10.0.1Grundlinie Hauptversion muss sein 10 (zum Beispiel 10.0.0).

Option A (empfohlen): Ausrichten der Gerätegrundlinie Hauptversion

Setzen plugins.CapacitorUpdater.version in capacitor.config.* so dass MAJOR der Bundle-MAJOR entspricht, den Sie liefern möchten (zum Beispiel 1.0.0 für 1.0.1, 10.0.0 für 10.0.1).

Dann wenden Sie diese Konfiguration auf die installierte App an:

1. Laufen npx cap sync.
2. Rebuild und die native App neu installieren.

Option B: Entspannen Sie die Kanalrichtlinie

Kreuz-maßstabs-automatische Aktualisierungen in den Kanal-Einstellungen erlauben (nur, wenn diese Rollout-Strategie absichtlich ist).

Zugehörige Dokumentation:

• Zielversion: Automatische Aktualisierung auf höhere Versionen deaktivieren
• Kanäle: Automatische Aktualisierungsstrategien deaktivieren

disable_auto_update_to_minor / disable_auto_update_to_patch

Ursache

Der Kanalrichtlinie ist strenger (minor oder patch) als die angebotene Aktualisierung.

• minor blockiert, wenn das Zielpaket eine andere Haupt- oder Minor-Version als die native Basisversion des Geräts hat (version_buildBeispiel: 1.2.3 -> 1.3.0 ist blockiert.
• patch blockiert jede wichtige, kleinere oder Patches-Nummer-Änderung von version_buildNur Suffix-Änderungen sind während MAJOR.MINOR.PATCH identisch bleibt, wie 1.0.0-beta.1 -> 1.0.0-beta.2 oder 1.0.0+build.1 -> 1.0.0+build.2.

Fix

• Laden Sie ein Bundle, das mit der aktuellen Politik kompatibel ist, oder
• ändern Sie die Kanal-Politik im Dashboard/CLI.

Zugehörige Dokumentation:

• Kanäle: Deaktivieren Sie die Auto-Update-Strategien

disable_auto_update_to_metadata

Ursache

Der Kanal verwendet eine Zielgruppen-basierte Ausrichtung (version_number) und die Geräte-Baseline liegt unter der erforderlichen min_update_version.

Behebung

• Passen Sie die Geräte-Baseline (CapacitorUpdater.version) mit der installierten nativen App-Version an oder
• anpassen Sie min_update_version / Kanalstrategie.

Zugehörige Dokumentationen:

• Kanäle: Deaktivieren Sie die Auto-Update-Strategien

disable_auto_update_under_native

Ursache

Kanal verhindert Downgrades unterhalb der nativen Basis.

Fix

• Laden Sie eine Bundle-Version hoch, die der nativen Basis mindestens entspricht, oder
• die Schutzfunktion gegen Downgrades unterhalb der nativen Basis für diesen Kanal deaktivieren.

Zugehörige Dokumentation:

• Version-Zielsetzung: Auto-Downgrade-Verhinderung

cannot_update_via_private_channel

Ursache

Ausgewählter/Standardkanal erlaubt keine Geräte-Selbstzuweisung.

Fix

• Verwenden Sie einen anderen Kanal mit Selbstzuweisung aktiviert oder
• machen Sie den Kanal öffentlich / aktivieren Sie die Selbstzuweisung.

Verwandte Dokumente:

• Kanäle: Verwendung von setChannel() aus Ihrer App

unknown_version_build / semver_error

Ursache

Geräte-Baselinenversion fehlt (unknown) oder ist nicht ein gültiger semver.

Behebung

• Setzen Sie plugins.CapacitorUpdater.version auf einen gültigen semver wie z.B. 1.2.3.
• Synchronisiere und baue die native App neu auf.

Verwandte Dokumente:

• Kanäle: Bundle-Versionierung und Kanäle
• Fehlersuche: Updates werden nicht angewendet

unsupported_plugin_version

Ursache

Der Updater-Plugin-Version ist zu alt für die aktuellen Backend-Anforderungen.

Lösung

• Aktualisieren @capgo/capacitor-updater.
• Ausführen npx cap sync.
• Rebuild und native App neu installieren.

disabled_platform_ios / disabled_platform_android

Ursache

Der Kanal hat für diese Plattform die Aktualisierungen deaktiviert.

Fix

• Schalten Sie die Plattform-Taste auf dem Kanal ein.

disable_prod_build / disable_dev_build / disable_device / disable_emulator

Ursache

Der Kanal verbietet die aktuelle Buildart oder das Ziel für die Laufzeit.

Fix

• Passen Sie die Kanaloptionen (allow_prod, allow_dev, allow_device, allow_emulator) mit Ihrem Testziel an.

key_id_mismatch

Ursache: Der Kanal hat Updates für diese Plattform deaktiviert. Fix: Aktivieren Sie die Plattform-Taste auf dem Kanal. Abschnitt mit dem Titel „disable_prod_build / disable_dev_build / disable_device / disable_emulator“: Ursache: Der Kanal verbietet die aktuelle Buildart oder das Ziel für die Laufzeit. Fix: Passen Sie die Kanaloptionen (”,”) mit Ihrem Testziel an. Abschnitt mit dem Titel „key_id_mismatch“

Schlüssel für die Verbindung und Geräteschlüssel unterscheiden sich.

Fix

• Verwende den gleichen Verschlüsselungs-Schlüssel/öffentlichen Schlüssel in der App-Konfiguration und im Workflow zur Verschlüsselung des Pakets.

no_channel / null_channel_data

Ursache

Kein gültiger Kanal wurde für das Gerät gelöst.

Fix

• Setze einen Cloud-Standardkanal, oder
• in Testversionen, oder defaultChannel zuweise einen Kanal-Übertrag für das Gerät.
• Verwandte Dokumente:

Capgo

• Kanäle

on_premise_app

Ursache

Der Backend-Server hat HTTP 429 zurückgegeben mit on_premise_app Dies tritt in drei Situationen auf:

1. Die App-ID existiert nicht in Capgo — der app_id Die vom Gerät gesendete ID ist nicht registriert, daher hat der Backend-Server keine Aufzeichnungen darüber.
2. Die App ist als on-premise markiert — die App existiert, aber ist für selbst gehostete Updates konfiguriert, daher lehnt der Capgo-Cloud-Endpunkt den Zugriff ab.
3. Die Organisation ist abbestellt — die App-Organisation hat keine aktive Abonnement mehr.

Häufiger Fehler

Ein Tippfehler in plugins.CapacitorUpdater.appId (in capacitor.config.ts) oder eine Mismatch mit der im Capgo-Dashboard registrierten App-ID. Der Backend kann "unbekannte App" nicht von "on-premise App" unterscheiden, daher wird der gleiche Fehler code zurückgegeben.

Beheben

• Überprüfe, app_id entspricht genau dem, was im Capgo-Dashboard angezeigt wird (fallschärfer).
• Wenn die App noch nicht registriert ist, führe npx @capgo/cli@latest app add.
• Wenn die App absichtlich auf-premise ist, setze plugins.CapacitorUpdater.updateUrl anstatt der Capgo-Cloud-URL an deinen selbst gehosteten Update-Endpoint.
• Wenn das Unternehmenstarif abgelaufen ist, erneuere oder stufe das Tarif auf.

Schnelldiagnose-Checkliste

1. Bestätigen Sie, dass die App-ID und der Kanal für die Build korrekt sind.
2. Bestätigen CapacitorUpdater.version entspricht der installierten nativen App-Version.
3. Bestätigen Sie, dass die Kanalrichtlinie (disable_auto_update) der beabsichtigten Rollout entspricht.
4. Bestätigen Sie, dass die Plattform-/Build-Zieltasten diese Geräte zulassen.
5. Laufen npx @capgo/cli@latest app debug und Fehler im Backend lesen code.

Brauchen Sie mehr Hilfe?

• Problembehandlung
• How erhalten Sie Unterstützung

Fortsetzen von häufigen Updateproblemen

Wenn Sie native Plugins verwenden häufige Updateprobleme um native Plugin-Arbeit zu planen, verbinden Sie es mit Mit @capgo/capacitor-Updater Für die native Fähigkeit in Mit @capgo/capacitor-Updater, Capgo Plugin-Verzeichnis Für den Produktworkflow in Capgo Plugin-Verzeichnis, Capacitor Plugins von Capgo Für die Implementierungsdetails in Capacitor Plugins von Capgo Plugins hinzufügen oder aktualisieren für die Implementierungsdetails in Plugins hinzufügen oder aktualisieren, und Alternativen zu Ionic Enterprise Plugins für den Produktworkflow in Alternativen zu Ionic Enterprise Plugins.