Firebase Crashlytics — was es ist, Abstürze und Fehlerdiagnose

Was ist Firebase Crashlytics

Firebase Crashlytics ist ein kostenloser Google-Dienst zur Überwachung der Stabilität mobiler Apps, den Google 2017 zusammen mit dem Unternehmen Fabric übernommen hat. Crashlytics sammelt automatisch Informationen über jeden App-Absturz, gruppiert identische Abstürze nach Stack-Signatur und zeigt sie in der Firebase-Konsole priorisiert nach der Anzahl der betroffenen Benutzer an.

Geschichte und Entwicklung

Crashlytics wurde 2011 als Teil der Fabric-Plattform gestartet und wurde schnell zum De-facto-Standard für Crash-Reporting unter iOS. Nach der Übernahme durch Google im Jahr 2017 für schätzungsweise 2 Milliarden US-Dollar (die gesamte Fabric) wurde Crashlytics in das Firebase SDK integriert. Version 18.0.0 (2021) führte Kotlin Multiplatform-Unterstützung ein, und Version 19.0.0 (2024) führte die automatische ANR-Erfassung auf Android ohne zusätzliche Konfiguration ein. Laut Google (2026) verarbeitet Crashlytics monatlich über 10 Milliarden Abstürze.

Kostenlose Grenzen von Crashlytics

Crashlytics wird kostenlos mit einem Limit von 500.000 Sitzungen pro Tag und Firebase-Projekt angeboten. Dies ist für die meisten Apps ausreichend — according to Google (2026), 95% of projects do not exceed the limit. Bei Überschreitung wird die Datenerfassung nicht gestoppt, aber die Berichte werden erst am nächsten Tag wieder aktualisiert. Für Projekte mit hohem Traffic stehen die Spark- und Blaze-Tarife von Firebase zur Verfügung — Crashlytics bleibt in beiden Tarifen kostenlos, und das Sitzungslimit wird separat gezählt.

Wie Crashlytics Abstürze erkennt und sammelt

Der Sammelmechanismus von Crashlytics basiert auf dem Abfangen von Ausnahmen auf Plattform- und Runtime-Ebene. Unter Android installiert das SDK einen UncaughtExceptionHandler, der alle unbehandelten Kotlin- und Java-Ausnahmen abfängt. Unter iOS verwendet Crashlytics NSSetUncaughtExceptionHandler für Objective-C/Swift und einen eigenen Mach-Ausnahmehandler für native Code-Abstürze.

Arten der abgefangenen Abstürze

Crashlytics unterscheidet fünf Arten von Abstürzen: fatal (fatale Abstürze), non-fatal (manuell übergebene nicht-fatale Ausnahmen), ANR (Android — App reagiert nicht), signal (OS-Signale — SIGSEGV, SIGABRT) und OOM (Speichermangel unter iOS). Each type is handled by a separate mechanism and displayed in the console with the corresponding label.

Format des Absturzberichts

Jeder Crashlytics-Bericht enthält umfassende Informationen: einen vollständigen Stack-Trace mit Klassennamen und Zeilennummern, die App-Version (versionName + versionCode), das Gerätemodell, die OS-Version, den freien Speicher, die Bildschirmausrichtung und die Zeit seit dem Start. Wenn Firebase Analytics verbunden ist, enthält der Bericht auch den Pfad der letzten 50 Benutzerereignisse vor dem Absturz — dies ist für die Reproduktion des Absturzes von entscheidender Bedeutung.

class CrashlyticsHelper {
    fun logNonFatal(error: Throwable) {
        FirebaseCrashlytics.getInstance()
            .log("Non-fatal: user action = payment_failed")
        FirebaseCrashlytics.getInstance()
            .recordException(error)
    }

    fun setUserContext(userId: String) {
        FirebaseCrashlytics.getInstance()
            .setUserId(userId)
        FirebaseCrashlytics.getInstance()
            .setCustomKey("subscription", "premium")
    }
}

Integration von Crashlytics in ein Android-Projekt

Crashlytics mit einer Android-App verbinden erfordert das Hinzufügen von zwei Abhängigkeiten in build.gradle und die Konfiguration des Google Services-Plugins. Das SDK aktiviert automatisch die Crash-Berichterstattung bei der Firebase-Initialisierung ohne zusätzlichen Code. Für den ordnungsgemäßen Betrieb werden auch das google-services-Plugin und die Datei google-services.json aus der Firebase-Konsole benötigt.

// build.gradle (Projektebene)
plugins {
    id "com.google.gms.google-services" version "4.4.0"
}

// build.gradle (App-Ebene)
plugins {
    id "com.google.firebase.crashlytics"
}

dependencies {
    implementation(platform("com.google.firebase:firebase-bom:33.1.0"))
    implementation("com.google.firebase:firebase-crashlytics-ktx")
    implementation("com.google.firebase:firebase-analytics-ktx")
}

Konfiguration des Crashlytics-Plugins

Das Plugin com.google.firebase.crashlytics führt zwei Aufgaben aus: es generiert eine eindeutige Build-ID für das Mapping obfuskierter Stacks und erstellt automatisch Ressourcen für das Crashlytics SDK. Without the plugin, crashes will be marked as "unmapped" — you will only see obfuscated class names (a.b.c) without being able to find the source code. Das Plugin wird zum Root-build.gradle und zum build.gradle des App-Moduls hinzugefügt.

Überprüfung der Integration

Zum Testen der Crashlytics-Integration wird die spezielle Methode forceCrash() verwendet, die eine Testausnahme generiert. Diese Methode ist in Produktions-Builds nicht verfügbar. Nach dem Ausführen eines Testabsturzes erscheint der Bericht innerhalb von 1–5 Minuten in der Firebase-Konsole. Wenn der Bericht nicht angezeigt wird, überprüfen Sie, ob google-services.json mit dem App-Paket übereinstimmt und ob in AndroidManifest keine Flags vorhanden sind, die die Datenerfassung deaktivieren.

Absturzanalyse und Berichtsgruppierung

Die Crashlytics-Konsole bietet zwei Ansichtsebenen: eine Liste aller Abstürze (Issues), gruppiert nach Absturztyp, und einen detaillierten Bericht für jedes Issue mit Trace, Statistiken und benutzerdefinierten Daten. Jedes Issue fasst alle Abstürze mit derselben Signatur zusammen — demselben Ausnahmetyp und übereinstimmendem Stack-Trace.

Issues und Gruppierung

Die Gruppierung von Abstürzen ist eine Hauptfunktion von Crashlytics. Anstatt Tausende einzelner Abstürze anzuzeigen, fasst der Dienst sie basierend auf einem Fingerabdruck (einer Prüfsumme des Stack-Trace) zu Issues zusammen. Ein Issue kann 1 bis mehrere Millionen Abstürze enthalten. Jedes Issue zeigt: die Anzahl der fatalen Vorfälle, die Anzahl der eindeutigen Benutzer, die App-Version, in der der Absturz auftrat, und den Prozentsatz der Benutzer, die auf das Problem gestoßen sind.

Laut Google (2026) machen durchschnittlich 20% der Issues 80% aller fatalen App-Abstürze aus (Pareto-Prinzip). Crashlytics sortiert Issues automatisch nach Schweregrad — je mehr Benutzer betroffen sind, desto höher die Priorität. Dadurch kann der Entwickler zuerst die am weitesten verbreiteten Probleme beheben.

Versionsstatistiken

Crashlytics verfolgt die Stabilität jeder App-Version separat. Das Diagramm der absturzfreien Benutzer zeigt den Prozentsatz der Benutzer, die in jeder Version keinen fatalen Absturz erlitten haben. Wenn der Prozentsatz bei einem Update unter einen Schwellenwert (Standard 99%) fällt, sendet Crashlytics eine Benachrichtigung per E-Mail und in der Firebase-Konsole. Dies ermöglicht ein schnelles Zurücksetzen einer problematischen Version oder die Veröffentlichung eines Hotfixes.

Benutzerdefinierte Schlüssel, Protokolle und Breadcrumbs

Crashlytics bietet drei Mechanismen zur Anreicherung von Berichten mit Kontext: benutzerdefinierte Schlüssel (Keys) für strukturierte Daten, Protokolle (Logs) für Text-Tracing und Breadcrumbs aus Analytics für den Benutzerpfad. Alle drei Datentypen werden dem Absturzbericht beigefügt und sind in seiner Detailkarte sichtbar.

Custom Keys

Custom Keys sind Schlüssel-Wert-Paare, die mit jedem Absturz gesendet werden. Maximal 64 Schlüssel pro App, jeder Schlüssel ist ein String mit bis zu 1024 Zeichen. Schlüssel sind nützlich, um den App-Status zu kennzeichnen: Abonnementstufe, Autorisierungsstatus, letzter Bildschirm, ob VPN aktiviert ist. Werte werden überschrieben — ein neuer Schlüssel mit demselben Namen ersetzt den alten.

Ereignisprotokollierung

Custom Logs sind Textnachrichten, die Crashlytics in einem 64-KB-Ringpuffer speichert. Protokolle werden automatisch dem nächsten Absturz angehängt. Tritt kein Absturz auf, werden die Protokolle nicht an den Server gesendet (sie verbrauchen kein Datenvolumen). Logging is used to record user steps before the crash: "payment_processing_started", "api_call_initiated", "response_received_200".

class PaymentViewModel {
    fun processPayment(amount: Double) {
        FirebaseCrashlytics.getInstance().log("Payment started: amount=$amount")

        FirebaseCrashlytics.getInstance().setCustomKey("last_screen", "payment_screen")
        FirebaseCrashlytics.getInstance().setCustomKey("subscription_tier", "basic")

        try {
            paymentGateway.charge(amount)
        } catch (e: NetworkException) {
            FirebaseCrashlytics.getInstance().recordException(e)
        }
    }
}

Breadcrumbs aus Analytics

Wenn Firebase Analytics mit dem Projekt verbunden ist, erhält Crashlytics automatisch Breadcrumbs — die letzten 50 Analytik-Ereignisse vor dem Absturz. Jeder Breadcrumb enthält den Ereignisnamen und seine Parameter. Dies ermöglicht die Rekonstruktion der genauen Abfolge von Aktionen, die zum Absturz führten: Benutzer öffnete Bildschirm → fügte Produkt hinzu → ging zur Zahlung → Absturz trat auf. Breadcrumbs are displayed in the Issue card on a separate "Logs" tab.

Bewährte Verfahren für die Arbeit mit Abstürzen

Crashlytics ist am effektivsten, wenn der Kontext und der Issue-Verarbeitungsprozess richtig konfiguriert sind. Die Praxis zeigt, dass Teams, die einen Workflow zur Absturzverwaltung implementiert haben, die Zeit zur Behebung kritischer Fehler um 60% reduzieren (Google-Daten, 2026).

Priorisierung von Issues

Nicht alle Abstürze sind gleich wichtig. Die Priorisierung nach Benutzeranzahl und Häufigkeit hilft, sich auf die kritischsten Probleme zu konzentrieren. Faustregel: Issues, die mehr als 0,1% der Benutzer betreffen, innerhalb von 24 Stunden beheben. Issues mit Einzelfällen (< 0,01%) können bis zum nächsten geplanten Release verschoben werden. Crashlytics markiert automatisch Regressionen — Issues, die behoben wurden, aber in einer neuen Version erneut aufgetreten sind.

CI/CD-Integration

Die Crashlytics-API ermöglicht die Integration von Absturzberichten in die CI/CD-Pipeline über die REST-API oder Firebase CLI. Bei jedem neuen Release können Sie automatisch überprüfen, ob der Prozentsatz absturzfreier Benutzer einen Schwellenwert überschreitet. Wird der Schwellenwert überschritten, blockiert CI/CD die Auslieferung und sendet eine Benachrichtigung an das Team. Die Firebase CLI unterstützt den Befehl firebase crashlytics:builds:upload zum Hochladen von ProGuard/R8-Mapping-Dateien — ohne sie sind Stacks nicht lesbar.

Laut Google (2026) veröffentlichen Apps, die automatische Schwellenwertprüfungen für absturzfreie Benutzer in CI/CD verwenden, 40% weniger Regressionen in der Produktion. Empfohlener Schwellenwert: absturzfreie Benutzer >= 99,5% für kritische Releases und >= 99,0% für normale Releases.