Firebase Crashlytics
Ship crash reports and non-fatal events to your Firebase project, with runtime opt-in / opt-out from your web app.
L'intégration de Firebase Crashlytics envoie des rapports de plantage anonymes et des évènements non fatals à votre projet Firebase, afin que vous puissiez repérer les problèmes de stabilité en production.
Comment l'activer :
- Configurez Firebase pour votre application et placez le fichier
google-services.jsondansAndroidStudioSourceCode/app/. - Dans Config.java, activez le suivi :
public static final boolean TRACKING_EVENT = true;
TRACKING_EVENT = false désactive toutes les fonctionnalités liées au suivi, y compris la journalisation des évènements Crashlytics et les déclencheurs starttracking:// / endtracking://.
Opt-in / Opt-out à l'exécution depuis votre application web :
WebViewGold respecte un indicateur de suivi par utilisateur qui est persisté sur l'appareil. Utilisez les déclencheurs de suivi standard pour le modifier à l'exécution :
<a href="starttracking://">Enable analytics & crash reports</a> <a href="endtracking://">Disable analytics & crash reports</a>
Lorsque l'utilisateur a refusé, la collecte Crashlytics est désactivée — rien n'est envoyé.
Ce qui est signalé :
- Les plantages non gérés (traces d'appels, modèle d'appareil, version du système d'exploitation).
- Les exceptions non fatales enregistrées en interne par la coque de l'application.
- Aucune donnée personnelle de l'utilisateur n'est jointe par défaut.
Où consulter les rapports : Ouvrez votre tableau de bord Firebase Console → Crashlytics. Les rapports apparaissent généralement quelques minutes après un plantage.
Remarques : L'initialisation de Crashlytics fonctionne au mieux — si Firebase est mal configuré, l'application continue de fonctionner normalement. Envisagez d'ajouter un écran de consentement (RGPD / CCPA) avant d'appeler starttracking:// pour la première fois.
Notes d’implémentation façon SDK
Considérez cette fonctionnalité comme une capacité native exposée à votre couche web : conservez votre site web de production ou votre PWA comme source de vérité, puis utilisez les indicateurs de configuration WebViewGold documentés, les commandes URL et les appels du pont JavaScript pour activer le comportement natif Android uniquement là où il apporte de la valeur. Cette approche garde votre base de code maintenable, car la même application web peut servir les navigateurs, WebViewGold pour Android et les autres plateformes WebViewGold avec un minimum de logique conditionnelle.
Pour des résultats fiables, privilégiez les points de terminaison HTTPS, des noms de routes stables, des états de succès/erreur explicites dans votre interface et de petites fonctions JavaScript qui encapsulent les appels natifs. Par exemple, une application web créée avec jQuery Mobile, Lovable, Base44, Bolt, WordPress, Bubble, une pile React/Vue/Angular personnalisée ou du HTML statique peut exposer un seul bouton ou gestionnaire d’événement qui déclenche l’API native WebViewGold tout en affichant une solution de repli élégante dans le navigateur.
- Modèle d’intégration recommandé : détectez le contexte de l’application, appelez l’API WebViewGold, puis mettez à jour votre interface web après le rappel natif ou le changement de route.
- Liste de vérification des tests : validez la fonctionnalité sur un appareil réel ou une build empaquetée, vérifiez les autorisations et le texte de revue du store, et confirmez que les utilisateurs navigateur uniquement reçoivent toujours une solution de repli utile.
- Avantage SEO : gardez les pages de fonctionnalités, les titres de routes et le contenu structuré indexables sur votre site web pendant que WebViewGold fournit l’enveloppe d’application native pour les utilisateurs Android.