Firebase Crashlytics
Ship crash reports and non-fatal events to your Firebase project, with runtime opt-in / opt-out from your web app.
Firebase Crashlytics integration sends anonymous crash reports and non-fatal events to your Firebase project, so you can spot stability issues in production.
How to Enable:
- Set up Firebase for your app and drop
google-services.jsonintoAndroidStudioSourceCode/app/. - In Config.java, turn tracking on:
public static final boolean TRACKING_EVENT = true;
TRACKING_EVENT = false disables all tracking-related features, including Crashlytics event logging and the starttracking:// / endtracking:// triggers.
Runtime Opt-In / Opt-Out from Your Web App:
WebViewGold respects a per-user tracking flag that is persisted on the device. Use the standard tracking triggers to change it at runtime:
<a href="starttracking://">Enable analytics & crash reports</a> <a href="endtracking://">Disable analytics & crash reports</a>
When the user is opted out, Crashlytics collection is turned off — nothing is uploaded.
What Is Reported:
- Unhandled crashes (stack traces, device model, OS version).
- Non-fatal exceptions logged internally by the app shell.
- No personal user data is attached by default.
Where to View the Reports: Open your Firebase Console → Crashlytics dashboard. Reports usually appear within a few minutes of a crash.
Notes: Crashlytics initialization is best-effort — if Firebase is misconfigured, the app still runs normally. Consider adding a consent screen (GDPR / CCPA) before calling starttracking:// for the first time.
SDK-style implementation notes
Treat this feature as a native capability exposed to your web layer: keep your production website or PWA as the source of truth, then use the documented WebViewGold configuration flags, URL commands, and JavaScript bridge calls to opt in to native Android behavior only where it adds value. This approach keeps your codebase maintainable because the same web application can serve browsers, WebViewGold for Android, and the other WebViewGold platforms with minimal conditional logic.
For reliable results, prefer HTTPS endpoints, stable route names, explicit success/error states in your UI, and small JavaScript helper functions that wrap native calls. For example, a web app built with jQuery Mobile, Lovable, Base44, Bolt, WordPress, Bubble, a custom React/Vue/Angular stack, or static HTML can expose a single button or event handler that triggers the native WebViewGold API while still showing a graceful browser fallback.
- Recommended integration pattern: detect the app context, call the WebViewGold API, then update your web UI after the native callback or route change.
- Testing checklist: validate the feature on a real device or packaged build, verify permissions and store review text, and confirm that browser-only users still receive a useful fallback.
- SEO benefit: keep feature pages, route titles, and structured content indexable on your website while WebViewGold delivers the native app shell for Android users.