Gemeinsame Update Probleme

Wenn eine Aktualisierungsprüfung fehlschlägt, Capgo gibt normalerweise eine error code und eine message im /updates Antwort. Diese Seite beschreibt die häufigsten Fehler und die schnellsten Lösungen.

Lesen Sie das zuerst

• no_new_version_available ist ein normaler Zustand und kein Fehler.
• Viele Meldungen über "aktualisierungen gefunden, aber nicht angewendet" sind Politik-/Konfigurationsverweigerungen anstatt Cache-Lag, insbesondere wenn die Antwort eine explizite error code.
• Verwende npx @capgo/cli@latest app debug während du das Problem nachbildest, um die Anfrage/Antwort-Details zu sehen.

Gemeinsame Fehlercodes

provider_infrastructure_request_blocked

Ursache

Die App hat Blockiere Anfragen an die Infrastruktur des Providers aktiviert und die Anfrage stammt aus einem bekannten Google- oder Apple-Datacenter-IP-Bereich. Capgo blockiert diese Anfragen auf /updates, /stats, und /channel_self um Verkehr, der vom Anbieter stammt, als Geräteverkehr zu behandeln.

Fix

• Wiederholen Sie die Aktualisierung von einem physischen Gerät auf einem normalen Benutzer-Netzwerk.
• Verwenden Sie keine cloudbasierten Proben oder Anbieter-Datencenter-Runner für Updater, Statistiken oder Channel-Self-Überprüfungen, während diese Schutzfunktion aktiviert ist.
• Wenn das Traffic absichtlich ist, öffnen Sie Ihre App's Informationen Schalten Sie "Block provider infrastructure requests" aus. Block-Anbieter-Infrastruktur-Anfragen. Aktiviere es erneut, wenn das Test ist abgeschlossen.

Neue Apps haben diese Schutzfunktion standardmäßig aktiviert. Apps, die vor der Einführung dieser Funktion erstellt wurden, haben sie deaktiviert, bis du sie aktivierst.

Antwortdetails

• /updates erhält die Updater-Antwort-Verträglichkeit und gibt HTTP zurück 200. Seine Körper enthält error, message, kind: "blocked", und provider ("google" oder "apple").
• /stats oder /channel_self return HTTP 429 mit dem gleichen Fehler code. Behandeln Sie dies als eine geplante Politikblockierung und nicht als eine vorübergehende Wiederholungsbedingung.

disable_auto_update_to_major

Cause

Ihr Kanal blockiert größere Updates ("disable_auto_update = major) und die Zielbundle-Major-Version liegt über der Geräte-Baselinenversion.

Häufiges Symptom

version: 1.0.8 und old: 0.0.0 bedeutet, dass das Gerät die Basislinie meldet 0.0.0daher werden große Upgrades abgelehnt.

Wie interpretiert man das?

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

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

Fixmöglichkeit A (empfohlen): Geräte-Baselinesynchronisierung auf Hauptversion

Setze plugins.CapacitorUpdater.version in capacitor.config.* so dass es MAJOR dem Bundle-MAJOR entspricht, das du liefern möchtest (z.B. 1.0.0 für 1.0.1, 10.0.0 für 10.0.1).

Dann wende diese Konfiguration auf die installierte App an:

1. Erneuere npx cap sync.
2. Die native App neu erstellen und installieren.

Fix Option B: lockere Kanalrichtlinie

Erlaube automatische Updates über Kanäle (nur, wenn diese Rollout-Strategie beabsichtigt ist).

Verwandte Dokumente:

• Versionziel: Deaktivieren Sie die automatische Aktualisierung über große Versionen
• Kanäle: Deaktivieren Sie die Auto-Update-Strategien

disable_auto_update_to_minor / disable_auto_update_to_patch

Ursache

Der Kanalrichtlinien sind strenger (minor oder patchals gegenüber dem angebotenen Update.

• minor Die Aktualisierung blockiert, wenn das Zielbundle eine andere Haupt- oder Minor-Version als die native Basisversion des Geräts hat ("version_build). Example: 1.2.3 -> 1.3.0 Beispiel:
• patch blockiert jede Haupt-, Minor- oder Patch-Nummer-Änderung von version_build. Nur Suffixänderungen sind während MAJOR.MINOR.PATCH bleibt identisch, wie z.B. 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 hoch, das mit der aktuellen Richtlinie kompatibel ist, oder
• change channel policy in dashboard/CLI.

den Kanalrichtlinien im Dashboard ändern.

• Kanäle: Automatische Updates deaktivieren

disable_auto_update_to_metadata

Ursache

Der Kanal verwendet metadata-basierte Zielgruppen (version_numberund das Gerätebasislevel liegt unter dem erforderlichen min_update_version.

Löschen

• Gerätebasis ausrichten ("CapacitorUpdater.version) mit installierter native App-Version, oder
• anpassen min_update_version / Kanalstrategie.

Zugehörige Dokumentation:

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

disable_auto_update_under_native

Ursache

Kanal verhindert Downgrade unter der nativen Basislinie.

Löschen

• Laden Sie eine Bundle-Version hoch, die der nativen Basislinie mindestens entspricht oder
• Deaktivieren Sie die "unter native"-Abstufungsschutzfunktion für diesen Kanal.

Zugehörige Dokumente:

• Version-Zielsetzung: Verhinderung automatischer Abstufung

cannot_update_via_private_channel

Ursache

Der ausgewählte/Standardkanal erlaubt keine Gerätezuteilung durch das Gerät selbst.

Lösung

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

Zugehörige Dokumente:

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

unknown_version_build / semver_error

Ursache

Geräte-Basiseintragsversion fehlt (unknown) oder ist nicht gültige semver.

Behebung

• Setzen plugins.CapacitorUpdater.version context nicht gültige semver zum 1.2.3.
• Synchronisiere und baue die native App neu auf.

Verwandte Dokumente:

• Zugehörige Dokumentationen:
• 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.
• Wiederherstellen und erneut installieren.

disabled_platform_ios / disabled_platform_android

Ursache

Der Kanal hat für diese Plattform Updates deaktiviert.

Lösung

• Plattform-Toggle auf dem Kanal aktivieren.

disable_prod_build / disable_dev_build / disable_device / disable_emulator

Ursache

Der Kanal verhindert die aktuelle Build-Art oder das Ziel der Laufzeitumgebung.

Lösung

• Passen Sie die Kanaloptionen (allow_prod, allow_dev, allow_device, allow_emulator) an Ihre Testziele an.

key_id_mismatch

Ursache

Bundle encryption key and device key differ.

Lösung

• Use the same encryption key/public key across app config and bundle encryption workflow.

no_channel / null_channel_data

Ursache

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

Lösung

• Einen Cloud-Standardkanal festlegen oder
• setzen defaultChannel in Testversionen oder
• einen Kanal-Übertrag für das Gerät zuweisen.

Zugehörige Dokumente:

• Kanäle

on_premise_app

Ursache

Der Backend-Server gab HTTP 429 zurück mit on_premise_appDies tritt in drei Situationen auf:

1. Die App-ID existiert nicht in Capgo — die app_id Der von dem Gerät gesendete Wert ist nicht registriert, daher hat der Backend keinen Eintrag darüber.
2. Die App wird als On-Premises-Anwendung gekennzeichnet. — Die App existiert, ist aber für Selbstverwaltung von Updates konfiguriert, daher lehnt der Capgo-Cloud-Endpunkt es ab, es zu bedienen.
3. Kundentarif wurde gekündigt Die Anwendung ist nicht mehr mit einem aktiven Abonnement verbunden.

Häufiger Fehler

Häufiger Fehler plugins.CapacitorUpdater.appId (in capacitor.config.ts) or a mismatch with the app ID registered in the Capgo dashboard. The backend cannot distinguish “unknown app” from “on-premise app”, so it returns the same error code.

Fix

• Überprüfe app_id stellt genau das dar, 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 On-Premise ist, setze plugins.CapacitorUpdater.updateUrl Stattdessen verwenden Sie Ihren selbst gehosteten Update-Endpunkt anstatt der Capgo-Cloud-URL.
• Wenn das Organisation-Plan abgelaufen ist, stelle den Plan neu oder upgradet ihn.

Schnelldiagnosecheckliste

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

und lesen Sie den Backend-Fehler __CAPGO_KEEP_0__.

• Troubleshooting
• Schrittweise Fehlersuche

Weiter von Gemeinsamen Aktualisierungsproblemen

Wenn Sie native Plugin-Arbeit planen Häufige Probleme bei der Aktualisierung um native Plugin-Arbeit zu planen, verbinden Sie es mit Verwenden Sie @capgo/capacitor-aktualisierer für die native Fähigkeit in Verwenden Sie @capgo/capacitor-aktualisierer Capgo Plugin-Verzeichnis für den Produktworkflow in Capgo Plugin-Verzeichnis Capacitor Plugins von Capgo für die Implementierungsdetails in Capacitor Plugins von Capgo Hinzufügen oder Aktualisieren von Plugins für die Implementierungsdetails in Hinzufügen oder Aktualisieren von Plugins, und Ionic Enterprise-Plugin-Alternativen für das Produktworkflow in Ionic Enterprise Plugin Alternativen.