Common Update Problems

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

Lese das zuerst

• no_new_version_available ist ein normaler Zustand und kein Fehler.
• Viele „Update gefunden, aber nicht angewendet“-Berichte sind Ablehnungen durch Richtlinien/Konfigurationen und nicht Cache-Lag, insbesondere wenn die Antwort einen expliziten error code
• Verwende npx @capgo/cli@latest app debug während du das Problem nachbildest, um Anfrage/Antwort-Details zu sehen.

Häufige Fehlercodes

provider_infrastructure_request_blocked

Ursache

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

Behebung

• Wiederholen Sie die Aktualisierung von einem physischen Gerät auf einem normalen Benutzer-Netzwerk.
• Verwenden Sie keine cloud-gestellten Proben oder Anbieter-Datacenter-Runner für Updater, Statistiken oder Channel-Self-Überprüfungen, während diese Schutzfunktion aktiv ist.
• Wenn dieser Traffic absichtlich ist, öffnen Sie das Informationen Registerkarte und schalten Sie es aus Blockanbieter-Infrastrukturanfragen. Aktivieren Sie es erneut, wenn der Test abgeschlossen ist.

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

Ausführliche Antwortdetails

• /updates erhält die Updater-Antwortvereinbarung und gibt HTTP 200. Sein Körper enthält error, message, kind: "blocked", und provider ("google" oder "apple").
• /stats oder /channel_self und 429 mit dem gleichen Fehler code. Behandeln Sie dies als eine absichtliche Richtlinienblockierung und nicht als eine vorübergehende Wiederholungsbedingung.

disable_auto_update_to_major

Ursache

Ihr Kanal blockiert große Aktualisierungen (disable_auto_update = major) und die Zielbundle-Major-Version ist über der Geräte-Basisversion.

Typisches Symptom

version: 1.0.8 mit old: 0.0.0 bedeutet, dass das Gerät die Basisversion 0.0.0meldet, sodass große Aktualisierungen abgelehnt werden.

Wie interpretiert man es?

Der Backend vergleicht die Hauptversionen mithilfe der Geräte-Basisversion old und Ziel version.

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

Fix-Option A (empfohlen): Passen Sie die Geräte-Basis-Major-Version an

Setzen Sie plugins.CapacitorUpdater.version in capacitor.config.* so dass ihr 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. Ausführen npx cap sync.
2. Rebuild und die native App neu installieren.

Option B: Entspannen Sie die Kanalrichtlinie

Zulassen Sie automatische Updates über Kanal-Ebenen in den Kanal-Einstellungen (nur, wenn diese Rollout-Strategie absichtlich ist).

Verwandte Dokumente:

• Versionziel: Deaktivieren Sie die automatische Aktualisierung über Hauptversionen
• Kanäle: Deaktivieren Sie die Auto-Update-Strategien

disable_auto_update_to_minor / disable_auto_update_to_patch

Ursache

Die Kanalrichtlinie ist strenger (minor oder patchWenn die angebotene Aktualisierung größer ist als die auf dem Gerät installierte Version.

• minor blockiert, wenn das Zielbundle eine andere Haupt- oder Minorversion als die Geräte-Standardbasis hat (version_buildBeispiel: 1.2.3 -> 1.3.0 ist blockiert.
• patch blockiert jede Änderung der Haupt-, Minor- oder Patchversion von version_buildErstellt nur Suffix-Änderungen, während MAJOR.MINOR.PATCH identisch bleibt, wie z.B. 1.0.0-beta.1 -> 1.0.0-beta.2 oder 1.0.0+build.1 -> 1.0.0+build.2.

context

• Alternativen finden Sie unter
• change channel policy in dashboard/CLI.

Ein Bundle hochladen, das mit der aktuellen Richtlinie kompatibel ist, oder die Kanalrichtlinie im Dashboard ändern.

• Kanäle: Auto-Update-Strategien deaktivieren

disable_auto_update_to_metadata

Ursache

Der Kanal verwendet eine Zielgruppenzuerkennung auf Basis von Metadaten (“)version_numberund die Gerätebasis ist unter der erforderlichen min_update_version.

Lösung

• Passen Sie die Gerätebasis (“) an, um die Version der installierten nativen App anzuzeigen, oderCapacitorUpdater.versionanpassen
• den Kanal-Strategie. min_update_version Zugehörige Dokumentation:

Kanäle: Auto-Update-Strategien deaktivieren

• Kanäle: Auto-Update-Strategien deaktivieren

disable_auto_update_under_native

Ursache

Der Kanal verhindert Abstufungen unter der nativen Basis.

Lösung

• Einen Bundle-Version hochladen, die größer oder gleich der nativen Basis ist, oder
• den ‘unter nativ’-Abstufungsschutz für diesen Kanal deaktivieren.

Zugehörige Dokumentation:

• Zielversionierung: Auto-Abstufungsvorbeugung

cannot_update_via_private_channel

Ursache

Der ausgewählte/Standardkanal erlaubt keine Geräte-Selbstzuweisung.

Lösung

• 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 (unknownoder ist nicht gültige semver.

Lösung

• Setzen Sie plugins.CapacitorUpdater.version auf ein gültige Semver-Version wie 1.2.3.
• Synchronisiere und baue die native App neu.

Verwandte Dokumente:

• Kanäle: Versionsverwaltung und Kanäle
• Fehlerbehebung: 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 Updates deaktiviert.

Lösung

• Aktivieren Sie die Plattform-Schaltfläche im Kanal.

disable_prod_build / disable_dev_build / disable_device / disable_emulator

Ursache

Der Kanal verbietet die aktuelle Build-Art oder die Zielplattform.

Lösung

• Passen Sie die Kanaloptionen an Ihre Testziele an.allow_prod, allow_dev, allow_device, allow_emulatorAbschnitt mit dem Titel „disable_prod_build / disable_dev_build / disable_device / disable_emulator“

key_id_mismatch

Ursache

Die Verschlüsselungsschlüssel für das Bundle und den Geräteschlüssel stimmen nicht überein.

Lösung

• Verwenden Sie denselben Verschlüsselungsschlüssel/öffentlichen Schlüssel in der App-Konfiguration und im Bundle-Verschlüsselungsworkflow.

no_channel / null_channel_data

Ursache

Für das Gerät wurde keine gültige Kanalinstanz gefunden.

Lösung

• Setzen Sie einen Cloud-Standardkanal, oder
• Setzen Sie defaultChannel in Testbuilds, oder
• Kanalüberschreibung für Gerät zuweisen.

Zugehörige Dokumente:

• Kanäle

on_premise_app

Sektion mit dem Titel „on_premise_app“

Ursache on_premise_appDer Backend-Server gab HTTP 429 zurück mit

1. App ID does not exist in Capgo Die App-ID existiert nicht in __CAPGO_KEEP_0__ app_id — der
2. von dem Gerät gesendete — the app exists but is configured for self-hosted updates, so the Capgo cloud endpoint refuses to serve it.
3. Die Organisation hat ihren Tarif abbestellt — die Organisation der App hat keinen aktiven Abonnement mehr.

Ein 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 nicht zwischen einer unbekannten App und einer On-Premise-App unterscheiden, daher gibt es den gleichen Fehler code.

Behebung

• Überprüfe, dass app_id genau dem entspricht, was im Capgo Dashboard angezeigt wird (kasseempfindlich).
• Wenn die App noch nicht registriert ist, führe npx @capgo/cli@latest app add.
• Wenn die App absichtlich On-Premise ist, setze plugins.CapacitorUpdater.updateUrl deine eigene self-hosted Update-Endpunkt anstatt der Capgo Cloud-URL.
• Wenn das Organisationen-Abonnement abgelaufen ist, erneuern oder aktualisieren Sie das Abonnement.

Rapiddiagnose-Checkliste

1. Bestätigen Sie, dass die App-ID und der Kanal für die Build korrekt sind.
2. Bestätigen CapacitorUpdater.version stimmt 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-Zieltaste diese Geräte zulässt.
5. Ausführen npx @capgo/cli@latest app debug und lesen Sie den Backend-Fehler code.

Brauchen Sie mehr Hilfe?

• Schadensanalyse
• Unterstützung erhalten

Fortsetzung aus Gemeinsamen Aktualisierungsproblemen

Wenn Sie native Plugin-Arbeit planen, verbinden Sie es mit Verwendung von @__CAPGO_KEEP_0__/__CAPGO_KEEP_1__-aktualisierer Für die native Fähigkeit in Verwendung von @__CAPGO_KEEP_0__/__CAPGO_KEEP_1__-aktualisierer, Using @capgo/capacitor-updater for the native capability in Using @capgo/capacitor-updater, Capgo Plugin Directory for the product workflow in Capgo Plugin Directory, Capacitor Plugins von Capgo zur Implementierungsdetail in Capacitor Plugins von Capgo Plugins hinzufügen oder aktualisieren zur Implementierungsdetail in Plugins hinzufügen oder aktualisieren, und Ionische Unternehmensplugin-Alternativen zur Produktworkflow in Ionische Unternehmensplugin-Alternativen.