Passer au contenu

Problèmes connus

  • Lorsque vous développez, si vous utilisez la fonctionnalité de rechargement en direct Ionic de CLI, elle remplacera le plugin, vous ne verrez donc jamais votre mise à jour.
  • Il utilise le même système que Ionic sous le capot, vous ne verrez donc pas vos mises à jour.
  • Cela se produit généralement lorsque des mises à jour volumineuses (> 20 Mo) sont publiées, un grand pourcentage d’utilisateurs n’obtiendront pas la dernière version.
    Dans le passé, les utilisateurs devaient garder l’application ouverte jusqu’à ce que le téléchargement soit terminé. Nous utilisons désormais le téléchargement en arrière-plan, mais il est toujours limité à quelques secondes.

Nous avons constaté des problèmes avec les appareils en Inde et avons appelé les utilisateurs, leur avons fait essayer différents serveurs DNS, et cela a fonctionné.

Donc, si vous rencontrez le problème, essayez d’utiliser un autre serveur DNS comme Cloudflare ou Google DNS.

Cloudflare : 1.1.1.1 et 1.0.0.1

Google DNS : 8.8.8.8 et 8.8.4.4 ou dns.google

Lorsque vous diffusez une mise à jour auto-hébergée, n’oubliez pas que vous ne pouvez pas utiliser le point de terminaison “HTTP” car cela va à l’encontre des politiques de sécurité des applications Android. Si vous souhaitez toujours le faire, suivez ce guide :

Problème de décompression : les entrées DEFLATED peuvent avoir un descripteur EXT

Si vous avez compressé votre bundle avec quelque chose de différent du CLI, le format ou votre zip pourrait être incorrect, veuillez utiliser la commande CLI npx @capgo/cli zip BUNDLE_FOLDER.

Il s’agit d’un problème connu de Java :

  • Si vous rencontrez des problèmes avecusesCleartextTraffic, c’est que le plugin suit les bonnes pratiques recommandées par sonar cloud, dans 90% des cas cela fonctionnera très bien, mais avec certains plugins cela pose des problèmes.

Pour résoudre ce problème, ajoutez android/app/src/main/AndroidManifest.xml dans la clé <application> :

tools:replace="android:usesCleartextTraffic"
xmlns:tools="http://schemas.android.com/tools"

##IOS

Ajoutez la clé de dictionnaire NSPrivacyAccessedAPICategoryUserDefaults à votre Manifeste de confidentialité (généralement ios/App/PrivacyInfo.xcprivacy) :

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
<key>NSPrivacyAccessedAPITypes</key>
<array>
<!-- Add this dict entry to the array if the file already exists. -->
<dict>
<key>NSPrivacyAccessedAPIType</key>
<string>NSPrivacyAccessedAPICategoryUserDefaults</string>
<key>NSPrivacyAccessedAPITypeReasons</key>
<array>
<string>CA92.1</string>
</array>
</dict>
</array>
</dict>
</plist>

Nous vous recommandons de déclarer CA92.1 comme motif d’accès au UserDefaults API.

Lorsque vous utilisez un serveur local pour tester la mise à jour, l’application demandera l’autorisation du réseau, c’est un comportement normal, ce n’est pas le cas lorsque vous utilisez un serveur distant.

Lorsque vous effectuez des mises à jour en mode manuel, certains événements ne sont pas faciles à détecter, par exemple l’échec de la mise à jour se déclenche juste avant le rechargement de votre code JS, vous ne pourrez donc pas l’attraper.

Une alternative consiste à répertorier les bundles et à vérifier les statistiques d’erreur pour savoir si la mise à jour échoue.

Nous devons trouver une meilleure façon de gérer cela à l’avenir, mais ce n’est pas une priorité, puisque le mode automatique est la méthode recommandée pour effectuer la mise à jour.

Les PR sont les bienvenus pour nous aider à améliorer cela.

si votre CLI a du mal à faire quoi que ce soit,

Vérifiez si appId et appName sont présents dans votre capacitor.config.ts

Suivez le guide de la doc officielle :