Problèmes d'actualisation courants

Lorsqu'une vérification de mise à jour échoue, Capgo retourne généralement un error code et un message dans la /updates réponse. Cette page explique les échecs les plus courants et les corrections les plus rapides.

Lisez ceci en premier

• no_new_version_available est un état normal, pas un échec.
• Beaucoup de rapports « mise à jour trouvée mais non appliquée » sont des refus de politique/configurations plutôt que des retards de cache, surtout lorsque la réponse inclut une mise à jour explicite error code.
• Utilisez npx @capgo/cli@latest app debug pour voir les détails de la requête/réponse tout en reproduisant le problème.

Codes d'erreur courants

provider_infrastructure_request_blocked

Cause

L'application a Bloquez les requêtes d'infrastructure du fournisseur activé et la requête est originaire d'une plage d'adresses IP de centre de données Google ou Apple connue. Capgo bloque ces requêtes sur /updates, /statset /channel_self pour empêcher le trafic provenant du fournisseur d'être traité comme du trafic de périphérique.

Réparation

• Réproduisez l'actualisation à partir d'un appareil physique sur un réseau utilisateur normal.
• N'utilisez pas les sondes hébergées par le cloud ou les exécutants de centre de données fournisseur pour les mises à jour, les statistiques ou les vérifications de canal-self pendant que cette protection est activée.
• Si ce trafic est intentionnel, ouvrez la fenêtre d'informations de votre application et désactivez la fonctionnalité de blocage des infrastructures fournisseur. Informations Onglet et désactivez le Bloquer les requêtes d'infrastructure fournisseurRéactivez-le lorsque le test sera terminé.

Les nouvelles applications ont cette protection activée par défaut. Les applications créées avant que le paramètre ne soit introduit gardent cette fonctionnalité désactivée jusqu'à ce que vous l'activiez.

Détails de la réponse

• /updates préservent le contrat de réponse de mise à jour et renvoient HTTP. 200Son corps inclut error, message, kind: "blocked", et provider ("google" ou "apple").
• /stats et /channel_self renvoie HTTP 429 avec le même erreur code. Traitez cela comme une politique de blocage intentionnel, et non comme une condition de réessai transitoire.

disable_auto_update_to_major

Cause

Votre canal bloque les mises à jour majeures (disable_auto_update = major) et la version majeure du bundle cible est supérieure à la version de base du dispositif.

Symptôme typique

version: 1.0.8 avec old: 0.0.0 signifie que le dispositif signale la version de base 0.0.0, donc les mises à jour majeures sont rejetées.

Comment l'interpréter

Le backend compare les versions majeures en utilisant le point de départ de l'appareil et la cible old et version.

• Si la cible est 1.0.1, la version majeure du point de départ doit être 1 (par exemple 1.0.0).
• Si la cible est 10.0.1, la version majeure du point de départ doit être 10 (par exemple 10.0.0).

Option de correction A (recommandée) : aligner la version majeure du point de départ de l'appareil

Fixer plugins.CapacitorUpdater.version dans capacitor.config.* donc c'est MAJOR correspond à la version MAJOR du bundle que vous souhaitez déployer (par exemple 1.0.0 pour 1.0.1, 10.0.0 pour 10.0.1).

Ensuite, appliquez cette configuration à l'application installée une fois :

1. Exécutez npx cap sync.
2. Rebâtissez et réinstallez l'application native.

Option de correction B : assouplir la politique de canal

Autoriser les mises à jour automatiques inter-maquettes dans les paramètres du canal (seulement si cette stratégie de déploiement est intentionnelle).

Documents connexes :

• Version Ciblage : Désactiver la mise à jour automatique entre les versions majeures
• Canaux : Désactiver les stratégies de mise à jour automatique

disable_auto_update_to_minor / disable_auto_update_to_patch

Cause

La politique du canal est plus stricte (minor ou patch) que la mise à jour proposée.

• minor empêche le bundle cible ayant un numéro majeur ou mineur différent du niveau de base natif du dispositif (version_build). Exemple : 1.2.3 -> 1.3.0 est bloqué.
• patch empêche toute modification du numéro majeur, mineur ou de patch de « version_build. Seules les modifications de suffixe sont autorisées pendant « MAJOR.MINOR.PATCH reste identique, comme 1.0.0-beta.1 -> 1.0.0-beta.2 ou 1.0.0+build.1 -> 1.0.0+build.2.

Fixer

• Télécharger un bundle compatible avec la politique actuelle, ou
• changer la politique de canal dans le tableau de bord/CLI.

Documents liés :

• Canaux : Désactiver les stratégies d'actualisation automatique

disable_auto_update_to_metadata

Cause

Le canal utilise une ciblage basé sur les métadonnées (version_number) et le niveau de base du dispositif est inférieur à celui requis min_update_version.

Fixer

• Aligner la base de ligne du dispositif (CapacitorUpdater.version) avec la version de l'application native installée, ou
• ajuster min_update_version / stratégie de canal.

Documents liés :

• Canaux : Désactiver les stratégies d'actualisation automatique

disable_auto_update_under_native

Cause

Le canal empêche les descentes de version en dessous de la base de ligne native.

Solution

• Télécharger une version de bundle supérieure ou égale à la base de ligne native, ou
• désactiver la protection contre les descentes de version sous native pour ce canal.

Documents liés :

• Ciblage de version : Prévention de la désactivation automatique

cannot_update_via_private_channel

Cause

Le canal sélectionné/par défaut ne permet pas l'auto-assignation du dispositif.

Résoudre

• Utilisez un canal différent avec l'auto-assignation activée, ou
• rendez le canal public / activez l'auto-assignation.

Documents liés :

• Canaux : Utilisation de setChannel() à partir de votre application

unknown_version_build / semver_error

Cause

La version de référence du dispositif est manquante (unknown) ou non valide semver.

Corriger

• Définir plugins.CapacitorUpdater.version sur un valide semver comme 1.2.3.
• Synchroniser et reconstruire l'application native.

Documentation liée :

• Canaux : Versionnement de Bundle et Canaux
• Diagnostics : Mises à jour non appliquées

unsupported_plugin_version

Cause

La version du plugin de mise à jour est trop ancienne pour les exigences actuelles du serveur.

Fix

• Mettre à jour @capgo/capacitor-updater.
• Exécuter npx cap sync.
• Rebuilder et réinstaller l'application native.

disabled_platform_ios / disabled_platform_android

Cause

Le canal a désactivé les mises à jour pour cette plateforme.

Fix

• Activer l'interrupteur de la plateforme sur le canal.

disable_prod_build / disable_dev_build / disable_device / disable_emulator

Cause

Le canal interdit le type de construction actuel ou l'objectif de runtime.

Fix

• Alignez les options de canal (allow_prod, allow_dev, allow_device, allow_emulator) avec votre cible de test.

key_id_mismatch

Cause

La clé de chiffrement du bundle et la clé du dispositif diffèrent.

Fix

• Utilisez la même clé de chiffrement/clé publique dans la configuration de l'application et le flux de chiffrement du bundle.

no_channel / null_channel_data

Cause

Aucun canal valide n'a été résolu pour le dispositif.

Fix

• Définir un canal par défaut dans le cloud, ou
• dans les builds de test, ou defaultChannel attribuer un surcroît de canal pour le dispositif.
• Documents liés :

Canaux

• Section intitulée “on_premise_app”

on_premise_app

Le serveur backend a retourné HTTP 429 avec

Related docs: __CAPGO_KEEP_0__ on_premise_app. Cela se produit dans trois situations :

1. L'ID de l'application n'existe pas dans Capgo — le app_id l'envoi de l'appareil n'est pas enregistré, donc le serveur n'a pas de dossier sur cela.
2. L'application est signalée comme étant sur site — l'application existe mais est configurée pour les mises à jour auto-hébergées, donc le point de terminaison cloud de Capgo refuse de le servir.
3. Le plan de l'organisation est annulé — l'application de l'organisation n'a plus d'abonnement actif.

Erreur commune

Une faute d'orthographe dans plugins.CapacitorUpdater.appId (en capacitor.config.ts) ou un désaccord avec l'ID de l'application enregistré dans le tableau de bord de Capgo. Le serveur ne peut pas distinguer « application inconnue » de « application sur site », donc il retourne le même erreur code.

Réparez

• Vérifiez que ce correspond exactement à ce qui est affiché dans le tableau de bord __CAPGO_KEEP_0__ (sensibilité à la casse). app_id matches exactly what is shown in the Capgo dashboard (case-sensitive).
• Si l'application est délibérément hébergée sur site, définissez npx @capgo/cli@latest app add.
• sur votre point de terminaison d'actualisation auto-hébergé au lieu de l'URL Cloud de __CAPGO_KEEP_0__. plugins.CapacitorUpdater.updateUrl to your self-hosted update endpoint instead of the Capgo cloud URL.
• Liste de vérification rapide

Section intitulée “Liste de vérification rapide”

1. Confirmez
2. correspond à la version de l'application native installée. CapacitorUpdater.version matches installed native app version.
3. Confirmer la politique de canal (disable_auto_update) correspond à la mise en œuvre prévue.
4. Confirmer que les paramètres de cible de plateforme/édition autorisent cet appareil.
5. Exécuter npx @capgo/cli@latest app debug et lire les erreurs de backend code.

Besoin d'aide supplémentaire ?

• Dépannage
• Comment obtenir de l'aide

Continuez d'ici les problèmes d'actualisation courants

Si vous utilisez Problèmes de mise à jour courants pour planifier le travail de plugin natif, connectez-le à En utilisant @capgo/capacitor-mises-à-jour pour la capacité native dans En utilisant @capgo/capacitor-mises-à-jours, Capgo Répertoire de plugin pour le flux de travail du produit dans Capgo Répertoire de plugin, Capacitor Plugins par Capgo pour le détail d'implémentation dans Capacitor Plugins par Capgo, Ajouter ou Mettre à jour les plugins pour le détail d'implémentation dans Ajouter ou Mettre à jour les plugins, et Alternatives de plugins d'entreprise Ionic pour le flux de travail du produit dans Alternatives de plugins d'entreprise Ionic.