Firebase Crashlytics
Ship crash reports and non-fatal events to your Firebase project, with runtime opt-in / opt-out from your web app.
Die Firebase-Crashlytics-Integration sendet anonyme Crash-Reports und Non-Fatal-Events an Ihr Firebase-Projekt, damit Sie Stabilitätsprobleme im Live-Betrieb erkennen.
So aktivieren Sie die Funktion:
- Richten Sie Firebase für Ihre App ein und legen Sie die
google-services.jsonunterAndroidStudioSourceCode/app/ab. - Aktivieren Sie Tracking in Config.java:
public static final boolean TRACKING_EVENT = true;
TRACKING_EVENT = false deaktiviert alle Tracking-Features (inklusive Crashlytics-Event-Logging und der Trigger starttracking:// / endtracking://).
Opt-in / Opt-out zur Laufzeit aus der Web-App:
WebViewGold respektiert ein pro-Nutzer Tracking-Flag, das auf dem Gerät gespeichert wird. Verwenden Sie die Standard-Tracking-Trigger, um es zur Laufzeit zu ändern:
<a href="starttracking://">Enable analytics & crash reports</a> <a href="endtracking://">Disable analytics & crash reports</a>
Ist der Nutzer opted-out, wird die Crashlytics-Erfassung deaktiviert – es wird nichts hochgeladen.
Was gemeldet wird:
- Nicht abgefangene Abstürze (Stack-Traces, Gerätemodell, OS-Version).
- Non-Fatal-Exceptions, die intern von der App-Hülle geloggt werden.
- Standardmäßig werden keine personenbezogenen Nutzerdaten angehängt.
Wo die Reports zu sehen sind: Öffnen Sie Ihre Firebase Console → Crashlytics. Reports erscheinen in der Regel wenige Minuten nach einem Crash.
Hinweise: Die Crashlytics-Initialisierung ist Best-Effort – bei falscher Firebase-Konfiguration läuft die App weiterhin. Erwägen Sie einen Consent-Screen (DSGVO / CCPA), bevor Sie starttracking:// erstmals aufrufen.
Implementierungshinweise im SDK-Stil
Betrachten Sie diese Funktion als native Fähigkeit, die Ihrer Web-Ebene bereitgestellt wird: Behalten Sie Ihre Produktivwebsite oder PWA als zentrale Quelle bei und nutzen Sie anschließend die dokumentierten WebViewGold-Konfigurationsflags, URL-Befehle und JavaScript-Bridge-Aufrufe, um natives Android-Verhalten nur dort zu aktivieren, wo es einen Mehrwert bietet. So bleibt Ihre Codebasis wartbar, da dieselbe Webanwendung mit minimaler Fallunterscheidung Browser, WebViewGold für Android und die übrigen WebViewGold-Plattformen bedienen kann.
Für zuverlässige Ergebnisse empfehlen sich HTTPS-Endpunkte, stabile Routennamen, explizite Erfolgs-/Fehlerzustände in Ihrer UI sowie kleine JavaScript-Hilfsfunktionen, die native Aufrufe kapseln. Beispielsweise kann eine mit jQuery Mobile, Lovable, Base44, Bolt, WordPress, Bubble, einem eigenen React-/Vue-/Angular-Stack oder statischem HTML erstellte Web-App eine einzelne Schaltfläche oder einen Event-Handler bereitstellen, der die native WebViewGold-API auslöst und dennoch einen sauberen Browser-Fallback zeigt.
- Empfohlenes Integrationsmuster: Erkennen Sie den App-Kontext, rufen Sie die WebViewGold-API auf und aktualisieren Sie anschließend Ihre Web-UI nach dem nativen Callback oder Routenwechsel.
- Test-Checkliste: Prüfen Sie die Funktion auf einem echten Gerät oder in einem paketierten Build, überprüfen Sie Berechtigungen und Store-Prüftexte und stellen Sie sicher, dass reine Browser-Nutzer weiterhin einen sinnvollen Fallback erhalten.
- SEO-Vorteil: Halten Sie Feature-Seiten, Routentitel und strukturierte Inhalte auf Ihrer Website indexierbar, während WebViewGold die native App-Hülle für Android-Nutzer bereitstellt.