FAQ

Si vous avez des questions non répondues ici, veuillez demander ! Les deux, ouvrir un problème ou demander sur Discord le travail.

Qu'est-ce que « code push » ?

Code push, également appelé « mises à jour en ligne » (OTA), est un service cloud qui permet aux développeurs de Capacitor de déployer des mises à jour de leurs applications en production. Capgo fonctionne actuellement sur Android, iOS et Electron.

« Code Push » fait référence au nom d'une fonction de déploiement utilisée par la communauté React Native depuis Microsoft et context : Page/zone : Site web de marketing Capgo. Rôle : Étiquette de navigation ou élément de navigation court. Vu dans : page trust.astro. Clé de message `et` (Et)., neither of which support Capacitor.

Do Capgo CLI majors need to match my plugin or Capacitor version?

Section intitulée « Les développeurs de Capgo CLI doivent-ils correspondre à la version de mon plugin ou de __CAPGO_KEEP_2__ ? »npx @capgo/cli@latest). The CLI and Capgo Console follow their own versioning and stay compatible with any supported updater plugin major. Capgo plugins follow Capacitor majors; see ). Le Capgo et le __CAPGO_KEEP_1__ Console suivent leur propre versionnage et restent compatibles avec tout plugin de mise à jour majeur pris en charge. Les plugins __CAPGO_KEEP_2__ suivent les majeures __CAPGO_KEEP_3__ ; voir la page sur la versionnage de Capgo. pour les balises LTS telles que @lts-v7.

Quelle est la différence entre un bundle et une mise à jour ?

Nous utilisons le terme « mise à jour » pour désigner la préparation d'un fichier binaire pour les magasins d'applications. Pour générer ensuite un bundle Capgo, il faut que Capgo sache le fichier binaire exact qui a été envoyé aux magasins d'applications.

Nous utilisons le terme « bundle » pour désigner une mise à jour qui peut être appliquée à une mise à jour pour la mettre à jour vers de nouvelles code. Le npx @capgo/cli@latest bundle upload La commande est utilisée pour générer un bundle à partir de votre nouveau code local qui est ensuite envoyé à vos utilisateurs.

Y a-t-il des limitations de chemins de fichiers pour les mises à jour Delta ?

Oui :

• Fichiers de taille zéro : Les CLI journaux Ignoring empty file... et exclut les fichiers vides du manifeste Delta. Il ne fait pas fail l'envoi, donc un fichier vide peut modifier le paquet résultant sans arrêter votre déploiement. N'incluez pas les fichiers de zéro octets dans les chemins de paquet Delta.
• Les chemins avec des espaces : Les Delta uploads échouent tôt avec un erreur claire lorsqu'un chemin de paquet contient un espace. Renommez les fichiers ou les dossiers pour supprimer les espaces avant d'envoyer une mise à jour Delta.

Voir les mises à jour Delta context : Page/zone : Page de produit/prix d'entreprise. Rôle : Étiquette de navigation ou élément de menu court. Vu dans : page enterprise.astro. Clé de message `enterprise_delta_updates` (Mises à jour Delta d'entreprise).

pour les détails de configuration.

Section intitulée « Quel est le plan de route ? » https://github.com/orgs/Cap-go/projects

Notre équipe travaille également dans le public, vous pouvez donc voir ce que nous travaillons en tout temps. Nous sommes heureux de répondre à toutes vos questions sur notre feuille de route ou nos priorités via les Github problèmes ou Discord.

Puis-je utiliser Capgo avec mon équipe ?

Oui ! Tous les plans supportent des développeurs illimités. Nous ne limitons que les métriques d'application (MAU, stockage et bande passante) à chaque organisation.

Voir Équipes pour plus d'informations.

Le Capgo stocke-t-il mon code source code ?

No. Capgo serveurs ne voient jamais votre source code. Lorsque vous exécutez npx @capgo/cli@latest bundle upload, Capgo stocke un fichier zip du code minifié/compilé - le même code qu'un navigateur recevrait, et non votre source code.

Pour une sécurité supplémentaire, vous avez deux options :

• Chiffrement de bout en bout : Chiffrez votre bundle avant de l'envoyer pour le protéger en stockage et en transit et empêcher les tiers de générer des mises à jour chiffrées valides sans votre clé privée. Cela ne rend pas les actifs web embarqués impossibles à décompiler car la clé publique est présente dans l'application distribuée.
• Téléchargement de l'URL externe : Stockez le bundle sur votre propre serveur et fournissez uniquement à Capgo le lien de téléchargement avec l'option --external <url>

Voir également notre politique de confidentialité : https://capgo.app/privacy

Sont les fichiers de bundle des données privées ?

No. Les fichiers de bundle sont des actifs web publics destinés à être téléchargés par vos utilisateurs. N'importe qui qui connaît l'URL du bundle peut récupérer ces fichiers, et Capgo informe les utilisateurs de cela lors de la configuration et dans la documentation.

L'accès aux fichiers de bundle n'est pas considéré comme une violation de données. N'insérez pas de secrets, de données d'identification, de données personnelles ou de données réglementées dans votre bundle d'application. Si vous avez besoin d'une confidentialité plus forte pour des cas d'utilisation à haut niveau de sécurité, utilisez l'encryption de bout en bout, mais traitez toujours les applications code et les actifs embarqués comme publics du point de vue de la sécurité.

Est-ce que je peux utiliser Capgo à partir de mon système CI ?

Oui. Capgo est destiné à être utilisé à partir de systèmes CI. Nous avons publié une guide pour Android et Github Actions et iOS, et pour GitLab. D'autres systèmes CI devraient être similaires.

Ne vous hésitez pas à nous contacter sur GitHub ou Discord si vous rencontrez des problèmes.

Comment cela se rapporte-t-il à Firebase Remote Config ou Launch Darkly ?

Le Code push permet d'ajouter de nouveaux code / de remplacer code sur le dispositif. Firebase Remote Config et Launch Darkly sont tous deux des systèmes de configuration. Ils vous permettent de modifier la configuration de votre application sans avoir à envoyer une nouvelle version. Ils ne sont pas destinés à remplacer code.

Quel est l'impact sur la taille de la dépendance ?

Je n'ai pas mesuré récemment, mais je suppose que la bibliothèque de push code ajoutera moins d'un mégaoctet aux applications Capacitor. Nous connaissons des moyens de la rendre plus petite lorsque cela devient une priorité. Si la taille constitue un obstacle pour vous, veuillez nous en informer !

Le Capgo fonctionne-t-il sur le simulateur iOS 18.4 ?

No. En raison d'un problème upstream affectant le simulateur iOS 18.4, Capgo ne fonctionne pas de manière fiable là-bas. Veuillez tester sur un appareil réel ou utiliser une version différente du simulateur iOS.

Voir les détails dans l'incident React Native : facebook/react-native#50510

Le code push fonctionne-t-il avec de grandes applications ?

Oui. Il n'y a pas de limite de taille pour l'application qui peut être mise à jour avec le code push. Comme indiqué ci-dessous, le Capgo peut modifier n'importe quel code JS dans votre application, quel que soit la taille.

À noter : une taille plus grande rend-il plus difficile aux utilisateurs de télécharger des mises à jour. Nous recommandons de garder votre application aussi petite que possible.

Qu'est-ce que je peux utiliser le Capgo code push pour ?

Nous avons vu diverses utilisations, notamment :

• Les corrections d’urgence pour les applications en production.
• La livraison de correctifs de bogues aux utilisateurs sur des versions plus anciennes de votre application.
• La livraison constante (par exemple, toutes les heures).

Notez que la plupart des magasins d’applications interdisent la livraison de code qui modifie le comportement de l’application d’une manière significative. Veuillez consulter ci-dessous pour plus d’informations.

Qu’est-ce qui compte comme un « MUA » pour Capgo ?

Un MUA est un appareil actif mensuel. Un appareil distinct qui contient Capgo au cours d’une période de 30 jours roulante compte comme un MUA pour cette ID d’application native. Le même appareil physique utilisé avec deux ID d’application native distincts compte une fois pour chaque ID d’application ; il n’est pas dédupliqué entre eux.

If vos saveurs diffèrent uniquement par leur couche web ou la mise à jour de routage, utilisez une ID d'application native unique avec canaux. Cela garde les saveurs sous une seule application Capgo et simplifie les publications. Utilisez des ID d'application natives séparés lorsque une saveur nécessite un ID de bundle distinct, une identité de signature, un ensemble d'entitlements ou une liste de magasin.

Sur iOS, v7.25.0+ garde l'ID de dispositif aléatoire, scoping de l'application, à travers les réinstallations normales en utilisant Keychain. Sur Android, utilisez v7.50.1+ ou v5.50.1+ et v6.50.1+ sur ces lignes de version); l'ID est restauré uniquement lorsque Android Backup/Restore retient les préférences de l'application. Désactiver la sauvegarde, exclure ces préférences ou effacer les données de l'application génère un nouvel ID de dispositif. Mettre à jour l'application ne crée pas un nouvel ID de dispositif.

Pour les builds de test et de développement, désactivez la livraison de builds de développement et d'émulateurs sur les canaux de production. Cela contrôle la livraison, pas le MAU : un appareil peut toujours compter lorsqu'il contacte Capgo. Pour l'empêcher d'être utilisé en production, désactivez les mises à jour en direct et ne pas appeler les points de terminaison de production Capgo. Testez les builds natifs sans mises à jour en direct. Pour lesquels ne pouvons-nous pas utiliser __CAPGO_KEEP_0__ __CAPGO_KEEP_1__ push ?

Lien direct vers Pour lesquels ne pouvons-nous pas utiliser Capgo code push ?

Capgo cannot change native code such as Java, Kotlin, Objective-C, Swift, native plugins, or native configuration. Those changes require a new native app release. For store-review scope, see Peut-on mettre à jour __CAPGO_KEEP_0__.config.ts via __CAPGO_KEEP_1__ ?.

Lien direct vers Peut-on mettre à jour capacitor.config.ts via Capgo ?

Les changements à Capgo.config.ts ne peuvent pas être mis à jour via __CAPGO_KEEP_1__ car ils nécessitent une nouvelle mise à jour de l'application native. capacitor.config.tsconfiguration native plugin, installation ou mise à jour de package native, et tout ce qui doit mettre à jour le projet iOS ou Android par l'intermédiaire de npx cap sync ou npx cap copy ou bien

The Capacitor configuration file is read at native build time and compiled into the native app binary. If you need to change your Capacitor configuration, you must:

1. Le fichier de configuration __CAPGO_KEEP_0__ est lu à temps de build natif et compilé dans le fichier binaire de l'application native. Si vous avez besoin de modifier votre __CAPGO_KEEP_1__ configuration, vous devez : capacitor.config.ts Mettre à jour
2. localementnpx cap sync Rebuilder votre application native (
3. suivi d'une build native)

Does Capgo submit to the stores for me?

Capgo Construire peut compiler et signer un projet natif iOS ou Android préparé et, lorsqu'il est configuré, soumettre le résultat signé à App Store Connect ou Google Play. Vous pouvez conserver votre CI existant pour les dépendances privées, les builds web, Capacitor synchronisation, et la préparation native personnalisée ; Capgo reçoit le projet natif préparé pour l'étape de build natif.

Voir Capgo Construire et la référence de configuration de build pour les options de flux de travail et de soumission de magasin.

Qu'est-ce que Capgo stocke sur le disque dur et où ?

Le mises à jour de Capgo (inclus dans votre application lorsque vous construisez votre application) cache le dernier bundle téléchargé dans le seul répertoire qui capacitor autorise à charger code. Sur Android, cela se trouve dans /data/user/0/com.example.app/code_cache/capgo_updater bien que la base de ce chemin soit fournie par le système Android et peut changer dynamiquement en temps de exécution. Sur les appareils iOS, les données sont stockées sous Library/Application Support/capgo.

Les outils de ligne de commande Capgo (par exemple, npx @capgo/cli@latest bundle uploadLes fichiers sont stockés sur le disque en caches npm, vos identifiants de connexion sont stockés dans votre répertoire personnel en ~/.capgo.

Comment cela se rapporte-t-il à la mise à jour instantanée Capacitor ?

La mise à jour instantanée de Capacitor est une fonctionnalité réservée au développement. La mise à jour Code est pour la production.

La mise à jour instantanée est une fonctionnalité de Capacitor qui vous permet de modifier code sur le périphérique pendant le développement. Cela nécessite la construction de l'application Capacitor avec un proxy pour se connecter à votre machine locale.

La mise à jour Code est une fonctionnalité qui vous permet de modifier code sur le périphérique en production. Nous utiliserons différentes techniques pour rendre cela possible en fonction de la plateforme.

Quels types de modifications la mise à jour Capgo code supporte-t-elle ?

Capgo peut modifier n'importe quel code JS dans votre application. Cela inclut les code de l'application et les code générés. Vous pouvez également mettre à jour les dépendances dans package.json à condition qu'elles ne nécessitent pas de modifications natives code.

Nous n'avons pas de plans pour soutenir la modification de code native (par exemple Java/Kotlin sur Android ou Objective-C/Swift sur iOS), et l'outil vous avertira si il détecte que vous avez modifié code native car il ne sera pas inclus dans le bundle.

Le support Web est-il disponible ?

Code push n'est pas nécessaire pour le Web car le Web fonctionne déjà de cette manière. Lorsqu'un utilisateur ouvre une application Web, il télécharge la dernière version du serveur si nécessaire.

Si vous avez un cas d'utilisation pour code push avec le Web, nous aimerions en savoir plus !

Ce produit fonctionnera-t-il sur iOS, Android, Mac, Windows, Linux, etc.?

Oui.

Jusqu'à présent, nous nous sommes concentrés sur le support Android, iOS et Electron, et code push est prêt à la production sur les trois.

Quels versions d'OS est Capgo compatible ?

Capgo prend en charge les mêmes versions d'Android que Capacitor.

Capacitor prend actuellement en charge Android API niveau 22+ et iOS 13.0+ : https://capacitorjs.com/docs/main/reference/support-policy

Quelles versions de Capacitor supporte Capgo ?

Capgo prend actuellement en charge uniquement les dernières versions stables de Capacitor. Nous pourrions prendre en charge des versions plus anciennes de Capacitor également, nous n'avons toutefois pas encore mis en place l'infrastructure nécessaire pour maintenir de telles versions à long terme. Nous comptons prendre en charge davantage de versions de Capacitor à l'avenir, y compris toute version pour nos clients entreprises. https://github.com/Cap-go/capgo/issues/1100

Capgo suit les versions stables de Capacitor et met à jour généralement dans les quelques heures qui suivent toute nouvelle version stable. Notre système pour effectuer ces mises à jour est automatisé et prend quelques minutes à exécuter. Nous effectuons ensuite une vérification manuelle supplémentaire avant de publier sur nos serveurs.

Comment cela se rapporte-t-il au processus ou aux politiques de revue de l'App/Play Store ?

Capgo ne transmet que des modifications au Capacitor layer web : le HTML, le CSS, le JavaScript et les actifs déjà exécutés dans la vue WebView de l'application. Il ne modifie pas le code natif, les plugins natifs, les permissions, les droits, la signature ou les métadonnées de la boutique.

Utilisez une mise à jour native pour chaque changement natif et pour les modifications matérielles qui pourraient affecter la finalité ou la fonctionnalité de l'application soumise et divulguée aux utilisateurs.

Le Capgo garantit-il une approbation de la boutique App Store ou Google Play ?

Non. Apple et Google examinent chaque application et la publient en fonction de leurs propres faits, et le Capgo ne peut pas garantir un résultat d'approbation ou de revue individuel. Votre équipe reste responsable du contenu, des déclarations, de la portée des mises à jour et de la conformité aux politiques actuelles de la boutique.

Pour la planification de la revue et de la mise en ligne, lisez les politiques officielles directement : Politiques de revue de la boutique App Store Apple et Politique de Google Play sur l'abus de dispositif et de réseau.

Puis-je utiliser Capgo dans mon pays?

Nous n'avons pas tenté de restreindre l'accès à Capgo à partir de tout pays.

Nous reconnaissons que certains pays ont des restrictions sur les URLs que l'on peut accéder à partir du pays. Capgo utilise actuellement Cloudflare Cloud pour l'hébergement, y compris R2 Storage et les travailleurs Cloudflare.

Les URLs suivantes sont utilisées par Capgo:

• https://api.capgo.app — utilisé par les outils de ligne de commande pour interagir avec les serveurs __CAPGO_KEEP_0__ ainsi que l'actualiseur __CAPGO_KEEP_1__ sur les appareils des utilisateurs pour vérifier les mises à jour. npx @capgo/cli command line tools to interact with the Capgo servers as well as the Capgo updater on users’ devices to check for updates.
• — utilisé par l'outil de ligne de commande pour télécharger et télécharger des bundles — utilisé par l'outil de ligne de commande pour télécharger et télécharger des bundles npx @capgo/cli — utilisé par l'outil de ligne de commande pour télécharger et télécharger des bundles

Si toutes ces adresses URL sont accessibles depuis votre pays, alors Capgo devrait fonctionner.

Si votre région nécessite de bloquer l'accès à l'une de ces adresses URL, veuillez nous le faire savoir et nous pouvons travailler avec vous pour trouver une solution. Les serveurs proxy sont une option.

Est-ce que je peux héberger moi-même Capgo?

Oui. Enterprise prend en charge les déploiements auto-hébergés de Capgo sous licence lorsque vous devez exécuter l'arrière-plan de mise à jour dans votre propre infrastructure. Voir Mise à jour auto-hébergée pour le modèle de déploiement et les points de terminaison.

Le code push nécessite-t-il l'internet pour fonctionner?

Oui. On pourrait imaginer exécuter un serveur pour distribuer les mises à jour séparément du réseau internet général, mais une certaine connectivité réseau est requise pour transporter les mises à jour vers les appareils.

Comment Capgo est-il affecté par l'absence de connectivité réseau ?

Le correcteur de Capgo (inclus dans votre application lorsque vous construisez votre application avec Capgo) est conçu pour être résistant aux problèmes de connectivité réseau.

Dans le comportement d'actualisation par défaut, lorsque l'application est lancée, elle alerte le correcteur de Capgo, qui démarre un thread séparé pour effectuer une requête réseau vers les serveurs de Capgo et demander une mise à jour. Nous utilisons intentionnellement un thread séparé pour éviter d'affecter tout autre processus que l'application pourrait être en train de faire. Si la requête réseau échoue ou expire, le correcteur tentera simplement de vérifier à nouveau la prochaine fois que l'application est lancée.

Les outils de ligne de commande de Capgo (par exemple, Capgo) nécessitent une connectivité réseau pour fonctionner. Si vous utilisez Capgo pour distribuer votre application, vous devriez vous assurer que votre système CI dispose d'une connectivité réseau. npx @capgo/cli@latest bundle upload) require network connectivity to function. If you are using Capgo to distribute your app, you should ensure that your CI system has network connectivity.

Liens direct vers Quel est le cas si un utilisateur ne met pas à jour pendant une longue période et manque une mise à jour ?

__CAPGO_KEEP_0__ est conçu pour être résistant aux problèmes de connectivité réseau.

Le serveur d'actualisation pourrait être modifié pour répondre avec soit la version incrémentale suivante, soit la version la plus récente, en fonction de vos besoins d'application. Veuillez nous faire savoir si les comportements d'actualisation alternatifs sont importants pour vous.

Comment Capgo se rapporte-t-il à Capacitor?

Capgo est un plugin pour Capacitor qui ajoute un code push. Capgo n'est pas une remplacement pour Capacitor. Vous pouvez continuer à utiliser les outils Capacitor que vous connaissez et aimez.

Nous suivons la dernière version stable de Capacitor et mettons à jour notre plugin de push code pour qu'il fonctionne avec elle.

Quand se produisent les mises à jour?

Par défaut, l'actualiseur Capgo vérifie les mises à jour au lancement de l'application. Il fonctionne sur un thread de fond et ne bloque pas le thread de l'interface utilisateur. Les mises à jour seront installées pendant que l'utilisateur utilise l'application et seront appliquées la prochaine fois que l'application sera redémarrée.

C'est également possible de lancer l'actualiseur Capgo manuellement à l'aide du @capgo/capacitor-updater package, à travers lequel il est possible de déclencher des mises à jour à tout moment, y compris via une notification de push.

Le Capgo metteur à jour est conçu de telle sorte que lorsque le réseau n'est pas disponible, ou que le serveur est en panne ou inaccessible, l'application continuera à fonctionner normalement. Si vous supprimez un jour une mise à jour de nos serveurs, tous vos clients continueront à fonctionner normalement.

Nous avons ajouté la possibilité de revenir sur des correctifs. La chose la plus simple est de simplement attacher un bundle précédent à votre canal pour annuler.

Faut-il conserver mon secret d'application ?

Non. Le app_id est inclus dans votre application et est en sécurité pour être public. Vous pouvez le vérifier dans le contrôle de version (même publiquement) et ne vous soucier de rien si quelqu'un d'autre l'accède.

Quelqu'un qui a votre app_id peut récupérer la dernière version de votre application à partir des serveurs de Capgo, mais ils ne peuvent pas envoyer de mises à jour à votre application ou accéder à tout autre aspect de votre compte Capgo.

Quelle information est envoyée aux serveurs de Capgo ?

La liste complète des données, le comportement des points de terminaison et les contrôles de confidentialité sont documentés dans Conformité.

Réglage statsUrl: '' pour désactiver les rapports de statistiques de mise à jour explicites. Vous pouvez également envoyer statsUrl à un proxy ou un point de terminaison que vous contrôlez ; voir gestion des statistiques dans l'infrastructure auto-hébergée. Les vérifications de mise à jour nécessitent toujours un identifiant de dispositif scoping d'application afin que Capgo puisse sélectionner la mise à jour correcte et mesurer les appareils actifs par mois.

La liste des sous-traitants est notre source de vérité publique à jour pour les fournisseurs, les emplacements de traitement, les mécanismes de transfert et l'historique des modifications.

Peut-on utiliser Capgo pour des applications sensibles à la HIPAA ?

Oui, mais votre propriétaire de conformité doit choisir le bon modèle de déploiement. Capgo Cloud n'est pas actuellement présenté comme un processeur de statistiques hébergé conforme à HIPAA. Par défaut, les données de mise à jour sont scoping appareil et ne sont pas liées à un utilisateur de l'application connu, et beaucoup d'équipes utilisent ce modèl’avec succès.

Pour des examens plus stricts, vous pouvez géolocaliser le trafic des plugins, désactiver les statistiques en définissant statsUrl à une chaîne vide, héberger uniquement l'endpoint de statistiques, ou utiliser un hébergement autonome sous licence. N'appellez pas CapacitorUpdater.setCustomId(...) avec un adresse e-mail, un ID utilisateur, un ID patient, un ID employé ou toute valeur qui remap les données de télémétrie de mise à jour vers une personne.

Voir Conformité HIPAA pour la configuration technique complète et les compromis d'observabilité lorsque les statistiques sont désactivées.

Puis-je conserver les données de mise à jour Capgo en Europe ?

Oui. Les applications qui nécessitent une résidence des données de l'UE pour le trafic des plugins Capgo Cloud peuvent définir les endpoints de mise à jour sur l'hôte de l'UE :

• updateUrl: https://plugin.eu.capgo.app/updates
• statsUrl: https://plugin.eu.capgo.app/stats
• channelUrl: https://plugin.eu.capgo.app/channel_self

Utilisez les trois URL de l'UE ensemble afin que les vérifications de mise à jour, les statistiques et l'attribution automatique du canal utilisent la même voie de données régionale. Puisque ces valeurs vivent dans capacitor.config.tsles applications mobiles de production nécessitent une mise en production native avant que les installations existantes utilisent les nouveaux points de terminaison.

Voir Emplacement des données pour des exemples exacts de Capacitor et Electron.

Quels plateformes supporte Capgo ?

Actuellement, Capgo prend en charge Android, iOS et Electron. Toutes sont prêtes pour la production.

L'utilisation de Capgo pour iOS, Android ou Electron peut être indépendante. Vous pouvez définir votre stratégie de canal pour Android et une IPA construite pour l'App Store, ou les canaux Electron, selon vos besoins.

Capgo peut (relativement facilement) être adapté pour prendre en charge les cibles bureau ou embarquées. Si cela est important pour vous, veuillez nous en informer.

Comment Capgo interagit-il avec les pistes de test Play ou Apple TestFlight ?

Chaque magasin d'applications a ses propres mécanismes pour distribuer des applications à des groupes d'utilisateurs limités (par exemple, « test interne », « bêta fermée », etc.). Ces mécanismes sont tous destinés à segmenter vos utilisateurs en groupes et à distribuer des versions spécifiques de vos applications à chaque groupe.

Malheureusement, ces mécanismes ne permettent pas à tous les tiers de détecter quand des applications sont installées dans une piste de test spécifique ou via TestFlight. Ainsi, nous n'avons pas de visibilité fiable sur la composition de ces groupes, et nous ne pouvons pas nous fier pour gérer l'accès aux correctifs de Capgo en fonction de ces groupes. https://stackoverflow.com/questions/53291007/can-an-android-application-identify-the-test-track-within-google-play https://stackoverflow.com/questions/26081543/how-to-tell-at-runtime-whether-an-ios-app-is-running-through-a-testflight-beta-i

Si vous souhaitez segmenter la disponibilité du bundle Capgo, il existe 4 options potentielles :

1. Utilisez un canal séparé pour chaque groupe. Cette approche est la plus simple, mais nécessite de gérer plusieurs canaux. Vous pouvez déjà avoir des canaux de développement et de production avec des disponibilités différentes. Vous pouvez ainsi mettre à jour vos canaux de développement, les vérifier et mettre ensuite à jour séparément vos canaux de production. Nous recommandons d'utiliser des branches / des étiquettes dans votre contrôle de version pour aider à suivre les sources associées à chaque version.
2. Suivez votre propre ensemble d'utilisateurs qui ont opté pour participer, désactivez les mises à jour automatiques et déclenchez les mises à jour uniquement pour certains utilisateurs via le @capgo/capacitor-updater Ce fonctionne aujourd'hui, mais nécessite que vous gériesz votre propre liste d'opt-in.
3. Capgo permet de créer son propre mécanisme d'opt-in sur une base par appareil (de même que les pistes de test ou TestFlight, mais sans dépendance de plateforme). Cela permet à votre équipe de test de s'abonner à un bundle avant qu'il ne soit promu au public général.
4. Utilisez les lancements progressifs pour livrer un candidat bundle à un sous-ensemble aléatoire et collant d'un canal. Définissez un lancement de 0 à 100 %, ou utilisez --rollout-percentage-bps pour des increments de 0,01 % ; configurez la durée de cache de 60 secondes à 365 jours et une politique d'arrêt automatique facultative. Cela ne sélectionne pas un groupe de dispositifs nommé.

Facturation

Sous-section intitulée « Facturation »

Vous pouvez mettre à niveau ou dégrader votre plan à tout moment dans votre tableau de bord : https://console.capgo.app/settings/organization/plans

Quand se réinitialise mon période de facturation ?

Les périodes de facturation sont réinitialisées automatiquement chaque mois le mois où vous avez souscrit à Capgo. Par exemple, si vous avez souscrit le 15 du mois, votre période de facturation sera réinitialisée le 15 de chaque mois.

Comment je peux annuler mon abonnement ?

Vous pouvez annuler votre abonnement à tout moment dans votre tableau de bord : https://console.capgo.app/settings/organization/plans

Peut-on payer pour un an à l'avance?

Oui. Vous pouvez choisir la facturation annuelle dans vos paramètres de plan d'organisation.

Qu'est-ce qui compte envers le stockage, et pouvons-nous modifier la rétention ?

Le stockage comprend les versions historiques retenues et leurs actifs Delta à travers vos canaux. Vous contrôlez la rétention des versions non utilisées pour chaque application dans les paramètres d'application. Les versions liées à un canal actif ou à une mise en production restent protégées, ce qui signifie qu'elles restent disponibles pour la livraison et le retrait.

La réplication régionale multiplie le stockage ou la bande passante ?

No. Un paquet est compté une seule fois pour le stockage, quel que soit les régions qui le servent. Capgo la bande passante est basée sur les téléchargements de périphériques qui ne sont pas servis à partir du cache de bord ; les livraisons servis à partir du cache ne comptent pas contre la bande passante Capgo.

Qu'est-ce que l'Enterprise SLA inclut ?

L'Enterprise inclut un engagement mensuel de disponibilité de 99,9 % pour la plateforme de production. Si cet engagement est manqué, le calendrier de crédit de service est de 10 % à 30 % en fonction de la disponibilité mensuelle. Les objectifs initiaux de réponse au support sont P1 : une heure, 24/7/365 ; P2 : deux heures de travail ; P3 : un jour de travail ; et P4 : deux jours de travail. Lisez le L'Enterprise SLA pour les termes complets.

Statistiques et analyses

Les statistiques de votre tableau de bord sont mises à jour chaque minuit UTC. Les statistiques sont calculées à partir de MAU distincts. MAUs pendant la période de 30 jours en cours.

Comment est généré l'ID de l'appareil.

L'ID de l'appareil est généré sur l'appareil lors de la première exécution, et est utilisé pour éviter les doublons d'installation par appareil et nous permettre de facturer en fonction des utilisateurs installés (par exemple, utilisateurs actifs mensuels), plutôt que le nombre total de correctifs ou le nombre total d'installations de correctifs.

MAU is a better solution than number of installs to price Capgo, as it is more accurate and reflects the actual cost of Capgo per device.

Persistance de l'ID de l'appareil :

• iOS: À partir de la version 7.25.0+, l'ID de l'appareil est stocké dans Keychain et persiste lors des réinstallations normales.
• Android: Utilisez la version 7.50.1+ (ou 5.50.1+/6.50.1+ sur ces lignes de version). L'ID de l'appareil est restauré uniquement lorsque Android Backup/Restore conserve les préférences de l'application.
• Electron: Le numéro de l'appareil est stocké dans un stockage sécurisé.
• Alerte Android: Désactiver la sauvegarde, exclure les préférences pertinentes ou effacer les données de l'application génère un nouveau numéro de l'appareil. Les versions Android de v7.25.0 à v7.50.0 peuvent générer un nouveau numéro de l'appareil après un réinstallé même lorsque la sauvegarde est activée.

Le numéro de l'appareil est scoping d'application et prend en charge la livraison en temps réel et la déduplication de MAU ; il ne s'agit pas d'un identifiant de publicité ou de suivi entre applications.

Les numéros d'appareil sont listés après que l'application se connecte à Capgo via les points de terminaison de mise à jour ou de statistiques. Un appareil n'a pas besoin d'installer une mise à jour avant de pouvoir apparaître dans la liste des appareils.

Pourquoi mon numéro d'appareil est différent de mon MAU ?

La liste des appareils et les MAU sont basés sur des signaux différents.

La liste des appareils affiche les métadonnées les plus récentes connues pour chaque appareil, telles que le numéro de l'appareil, la plateforme, la version du plugin, la version du système d'exploitation, la version native, le canal, le bundle installé et le pays de demande lorsque disponible. Le pays de demande est le dernier code à deux lettres code valide reçu d'une Cloudflare-traitée pour cet appareil, et non la position GPS ou la localisation fournie par l'application. Les demandes sans un pays valide ne suppriment pas la dernière valeur valide. Capgo met à jour ces métadonnées lors de la connexion de l'application, mais les connexions répétées qui signalent les mêmes métadonnées peuvent ne pas modifier la ligne ou sa date de mise à jour la plus récente.

Le nombre de MAU compte les appareils actifs distincts pendant la fenêtre de facturation. Cette activité peut augmenter même lorsque les métadonnées de l'appareil restent les mêmes, donc le nombre d'appareils et le MAU peuvent être différents.

Comment avoir des mises à jour différentes par plateforme?

Vous pouvez créer un canal pour chaque plateforme et désactiver les mises à jour spécifiques à la plateforme dans chaque canal.

Sur le canal iOS, désactiver les mises à jour Android et sur le canal Android, désactiver les mises à jour iOS.

Ensuite, télécharger un bundle pour chaque canal afin d'avoir des mises à jour différentes pour chaque plateforme.

Si vous avez besoin d'avoir la même mise à jour pour les deux plateformes, vous pouvez lier un bundle à plusieurs canaux. Pas besoin de dupliquer le bundle.

Continuez de la page FAQ.

Si vous utilisez FAQ Misez sur la livraison d'actualisations en direct en la connectant à Capgo Mises à jour en direct Misez sur le flux de travail du produit dans Capgo Mises à jour en direct, Vue d'ensemble Misez sur les détails d'implémentation dans Vue d'ensemble, Fonctionnalités Misez sur les détails d'implémentation dans Fonctionnalités, Comportement de mise à jour Misez sur les détails d'implémentation dans Comportement de mise à jour, et Types de mise à jour Misez sur les détails d'implémentation dans Types de mise à jour.