Häufige Updateprobleme

Wenn eine Aktualisierungsprüfung fehlschlägt, Capgo gibt normalerweise einen error code und eine message in der /updates Antwort. 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 und kein Fehler.
• Viele “aktualisierung gefunden, aber nicht angewendet”-Berichte sind Ablehnungen der Richtlinie/Konfiguration anstatt Cache-Lag, insbesondere wenn die Antwort eine explizite enthält error code.
• Verwenden Sie 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 Blockieren Sie 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 sicherzustellen, dass Traffic, der vom Provider stammt, nicht als Geräte-Traffic behandelt wird.

Fix

• Reproduzieren Sie die Aktualisierung von einem physischen Gerät auf einem normalen Benutzer-Netzwerk.
• Verwenden Sie während dieser Schutzfunktion weder Cloud-Hosted-Proben noch Provider-Datencenter-Runner für Updater, Statistiken oder Channel-Self-Überprüfungen.
• Wenn diese Verkehrabsicht ist, öffnen Sie die App-Informationen Registerkarte und schalten Sie " Blockieren Sie Anfragen an die Provider-Infrastruktur . Wiederherstellen Sie es, 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

erhalten die Verträge des Updater-Antwort und geben HTTP

• /updates zurück. Sein Körper enthält 200__CAPGO_KEEP_0__ error, message, kind: "blocked"und provider ("google" oder "apple").
• /stats und /channel_self HTTP zurückgeben 429 mit dem gleichen Fehler code. Dies wird als absichtliche Richtlinienblockierung und nicht als vorübergehende Wiederholungsbedingung behandelt.

disable_auto_update_to_major

Ursache

Ihr Kanal blockiert größere Updates (disable_auto_update = major) und die Zielbundle-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 meldet 0.0.0Major Upgrades werden abgelehnt.

Wie man es interpretieren soll

Der Backend vergleicht die Hauptversionen mithilfe der Gerätebasislinie old und Ziel version.

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

Option A zum Fixen (empfohlen): Gerätebasislinie-Hauptversion anpassen

Setzen plugins.CapacitorUpdater.version in capacitor.config.* so its MAJOR entspricht der Bundle MAJOR, den Sie bereitstellen möchten (z.B. 1.0.0 für 1.0.1, 10.0.0 für 10.0.1).

Anschließend wenden Sie diese Konfiguration auf die installierte App an:

1. Ausführen npx cap sync.
2. Rebuild und erneut installieren Sie die native App.

Option B: Entspannen Sie die Kanalrichtlinie

Zulassen Sie die automatische Aktualisierung über verschiedene MAJOR in den Kanal-Einstellungen (nur wenn diese Rollout-Strategie beabsichtigt ist).

Zugehörige Dokumentation:

• Zielversion: 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

Der Kanal hat eine striktere Richtlinie (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_build). Beispiel: 1.2.3 -> 1.3.0 ist blockiert.
• patch blockiert jede Änderung der Haupt-, Minor- oder Patch-Nummer von version_build. Nur Suffix-Änderungen sind erlaubt. MAJOR.MINOR.PATCH bleibt identisch, wie 1.0.0-beta.1 -> 1.0.0-beta.2 oder 1.0.0+build.1 -> 1.0.0+build.2.

Fix

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

Zugehörige Dokumentation:

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

disable_auto_update_to_metadata

Ursache

Der Kanal verwendet eine Zielgruppenzuerkennung auf der Grundlage von Metadaten (version_number) und das Gerätebasisniveau liegt unter dem erforderlichen min_update_version.

Fix

• Gerät-Baseline (CapacitorUpdater.version) mit der installierten nativen App-Version ausrichten oder
• anpassen min_update_version / Kanalstrategie.

Zugehörige Dokumentation:

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

disable_auto_update_under_native

Ursache

Der Kanal verhindert Downgrades unter der nativen Basislinie.

Lösung

• Ein Bundle-Version hochladen, die der nativen Basislinie mindestens entspricht, oder
• die 'unter nativ' Downgrade-Schutzfunktion für diesen Kanal deaktivieren.

Verwandte Dokumente:

• Version-Zielsetzung: Verhindern von Auto-Downgrade

cannot_update_via_private_channel

Ursache

Ausgewählter/Standardkanal erlaubt keine Gerätezuteilung.

Lösung

• Verwenden Sie einen anderen Kanal mit aktivierter Gerätezuteilung oder
• machen Sie den Kanal öffentlich / aktivieren Sie die Gerätezuteilung.

Verwandte Dokumente:

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

unknown_version_build / semver_error

Ursache

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

Fix

• Setzen Sie plugins.CapacitorUpdater.version auf einen gültigen semver wie 1.2.3.
• Synchronisieren und native App neu erstellen.

Zugehörige Dokumentation:

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

unsupported_plugin_version

Ursache

Der Updater-Plugin-Version entspricht nicht den 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-Toggle auf dem Kanal.

disable_prod_build / disable_dev_build / disable_device / disable_emulator

Ursache

Der Kanal verhindert die aktuelle Buildart oder das Ziel der Laufzeitumgebung.

Lösung

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

key_id_mismatch

Ursache

Die Schlüssel für die App-Bundle-Verschlüsselung und die 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.

Beheben

• Setze einen Cloud-Standardkanal oder
• in Testbuilds, oder defaultChannel zuweisen Sie einen Kanal-Überschreibung für das Gerät.
• Zugehörige Dokumentation:

Kanäle

• Abschnitt mit dem Titel “on_premise_app”

on_premise_app

Der Backend-Server gab HTTP 429 zurück mit

Related docs: __CAPGO_KEEP_0__ on_premise_app. Dies tritt in drei Situationen auf:

1. Die App-ID existiert nicht in Capgo — der app_id durch das Gerät gesendete Wert ist nicht registriert, daher hat der Backend keine Aufzeichnung davon.
2. Die App ist als On-Premise-App gekennzeichnet — die App existiert, aber ist für selbst gehostete Updates konfiguriert, daher lehnt der Capgo-Cloud-Endpunkt den Zugriff ab.
3. Die Organisationseinheit 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 in der Capgo-Dashboard registrierten App-ID. Das Backend kann nicht zwischen „unknow App“ und „On-Premise App“ unterscheiden, daher gibt es den gleichen Fehler code.

Fix

• Überprüfen Sie, ob sich die App genau so verhält wie in der __CAPGO_KEEP_0__-Oberfläche dargestellt (fallweise). app_id matches exactly what is shown in the Capgo dashboard (case-sensitive).
• Wenn die App absichtlich auf einem lokalen Server läuft, setzen Sie npx @capgo/cli@latest app add.
• anstatt der __CAPGO_KEEP_0__-Cloud-URL. plugins.CapacitorUpdater.updateUrl to your self-hosted update endpoint instead of the Capgo cloud URL.
• Schnelldiagnose-Checkliste

Abschnitt mit dem Titel “Schnelldiagnose-Checkliste”

1. Bestätigen
2. stimmt mit der installierten nativen App-Version überein. CapacitorUpdater.version matches installed native app version.
3. Bestätige Kanalrichtlinie (disable_auto_update) entspricht der beabsichtigten Rollout.
4. Bestätige Plattform/Zieldarstellung-Toggle, die diese Geräte zulassen.
5. Ausführen npx @capgo/cli@latest app debug und Fehler im Backend lesen code.

Brauchen Sie mehr Hilfe?

• Fehlersuche
• Wie erhalten Sie Unterstützung

Bleiben Sie bei den häufigen Updateproblemen

Wenn Sie Gemeinsame Aktualisierungsprobleme 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 Ionic Enterprise Plugin Alternativen für den Produktworkflow in Ionic Enterprise Plugin Alternativen.