Firebase Crashlytics — wat is het, crashes en diagnostiek van storingen

Wat is Firebase Crashlytics

Firebase Crashlytics is een gratis Google-service voor het monitoren van de stabiliteit van mobiele applicaties, overgenomen door Google in 2017 samen met het bedrijf Fabric. Crashlytics verzamelt automatisch informatie over elke applicatiestoring, groepeert identieke crashes op stacksignatuur en toont ze in de Firebase-console met prioritering op basis van het aantal getroffen gebruikers.

Geschiedenis en evolutie

Crashlytics werd gelanceerd in 2011 als onderdeel van het Fabric-platform en werd snel de de facto standaard voor crashrapportage in iOS. Na de overname door Google in 2017 voor een geschatte 2 miljard dollar (geheel Fabric), werd Crashlytics geïntegreerd in de Firebase SDK. Versie 18.0.0 (2021) voegde ondersteuning toe voor Kotlin Multiplatform, en versie 19.0.0 (2024) — automatische ANR-verzameling op Android zonder extra configuratie. Volgens gegevens van Google (2026) verwerkt Crashlytics maandelijks meer dan 10 miljard crashes.

Gratis limieten van Crashlytics

Crashlytics wordt gratis aangeboden met een limiet van 500 duizend sessies per dag per Firebase-project. Voor de meeste applicaties is dit voldoende — volgens gegevens van Google (2026) overschrijdt 95% van de projecten de limiet niet. Bij overschrijding stopt het verzamelen van gegevens niet, maar worden rapporten niet meer bijgewerkt tot de volgende dag. Voor projecten met hoge belasting zijn de Spark- en Blaze-tarieven van Firebase beschikbaar — Crashlytics blijft gratis op beide tarieven en de sessielimiet wordt apart berekend.

Hoe Crashlytics storingen detecteert en verzamelt

Het verzamelmechanisme van Crashlytics is gebaseerd op het onderscheppen van uitzonderingen op platform- en runtimeniveau. Op Android implementeert de SDK een UncaughtExceptionHandler die alle onverwerkte Kotlin- en Java-uitzonderingen onderschept. Op iOS gebruikt Crashlytics NSSetUncaughtExceptionHandler voor Objective-C/Swift en een eigen Mach-uitzonderingshandler voor crashes van native code.

Soorten onderschepte storingen

Crashlytics onderscheidt vijf soorten storingen: fatal (fatale crashes), non-fatal (niet-fatale uitzonderingen handmatig doorgegeven), ANR (Android — applicatie reageert niet), signal (OS-signalen — SIGSEGV, SIGABRT) en OOM (geheugengebrek op iOS). Elk type wordt door een apart mechanisme verwerkt en in de console getoond met een bijbehorend label.

Formaat van het storingsrapport

Elk Crashlytics-rapport bevat uitgebreide informatie: volledige stacktrace met klassenamen en regelnummers, app-versie (versionName + versionCode), apparaatmodel, OS-versie, hoeveelheid vrij geheugen, schermoriëntatie en tijd sinds opstarten. Als Firebase Analytics is aangesloten, bevat het rapport ook het pad van de laatste 50 gebruikersgebeurtenissen voor de storing — dit is cruciaal voor het reproduceren van de crash.

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")
    }
}

Crashlytics integreren in een Android-project

Crashlytics aansluiten op een Android-app vereist het toevoegen van twee afhankelijkheden in build.gradle en het configureren van de Google Services-plugin. De SDK activeert automatisch crashrapportage bij het initialiseren van Firebase zonder extra code. Voor correcte werking zijn ook de google-services-plugin en het bestand google-services.json uit de Firebase-console vereist.

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

// build.gradle (app-level)
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")
}

Configuratie van de Crashlytics-plugin

De plugin com.google.firebase.crashlytics voert twee taken uit: genereert een unieke build-ID voor het mappen van geobfusceerde stacks en maakt automatisch resources aan voor de Crashlytics SDK. Zonder de plugin worden crashes gemarkeerd als "unmapped" — u ziet alleen geobfusceerde klassennamen (a.b.c) zonder de mogelijkheid om de broncode te vinden. De plugin wordt toegevoegd aan de root build.gradle en aan de build.gradle van de app-module.

Integratie controleren

Voor het testen van de Crashlytics-integratie wordt de speciale methode forceCrash() gebruikt, die een testuitzondering genereert. In productie-builds is deze methode niet beschikbaar. Na het uitvoeren van de testcrash verschijnt het rapport binnen 1-5 minuten in de Firebase-console. Als het rapport niet wordt weergegeven — controleer of google-services.json overeenkomt met het app-pakket en of er in AndroidManifest geen vlaggen zijn die het verzamelen van gegevens uitschakelen.

Crashes analyseren en rapporten groeperen

De Crashlytics-console biedt twee weergaveniveaus: een lijst van alle crashes (Issues) gegroepeerd op storingssoort en een gedetailleerd rapport voor elke Issue met stacktrace, statistieken en gebruikersgegevens. Elke Issue combineert alle crashes met dezelfde signatuur — hetzelfde uitzonderingstype en overeenkomende stacktrace.

Issues en groepering

Het groeperen van crashes is de belangrijkste functie van Crashlytics. In plaats van duizenden afzonderlijke crashes weer te geven, combineert de service ze in Issues op basis van een fingerprint — de controlesom van de stacktrace. Een enkele Issue kan 1 tot enkele miljoenen crashes bevatten. Voor elke Issue wordt weergegeven: het aantal fatale gevallen, het aantal unieke gebruikers, de app-versie waarin de crash verscheen en het percentage gebruikers dat het probleem tegenkwam.

Volgens gegevens van Google (2026) veroorzaakt gemiddeld 20% van de Issues 80% van alle fatale crashes van de app (Paretoprincipe). Crashlytics sorteert Issues automatisch op severity — hoe meer gebruikers zijn getroffen, hoe hoger de prioriteit. Dit stelt de ontwikkelaar in staat eerst de meest massale problemen op te lossen.

Statistieken per versie

Crashlytics volgt de stabiliteit van elke app-versie afzonderlijk. De grafiek crash-free users toont het percentage gebruikers dat geen fatale crash heeft ervaren in elke versie. Als bij een update het percentage onder de drempel zakt (standaard 99%), stuurt Crashlytics een melding per e-mail en in de Firebase Console. Dit maakt het mogelijk de problematische versie snel terug te draaien of een hotfix uit te brengen.

Aangepaste sleutels, logs en Breadcrumbs

Crashlytics biedt drie mechanismen om rapporten te verrijken met context: aangepaste sleutels (keys) voor gestructureerde gegevens, logs voor tekstuele tracing en Breadcrumbs uit Analytics voor het gebruikerspad. Alle drie de gegevenstypen worden aan het crashrapport gekoppeld en zijn zichtbaar in de detailkaart.

Aangepaste sleutels

Custom Keys zijn sleutel-waardeparen die met elke crash worden meegestuurd. Maximaal 64 sleutels per app, elke sleutel is een tekenreeks van maximaal 1024 tekens. Sleutels zijn handig voor het markeren van de app-status: abonnementsniveau, authenticatiestatus, laatste scherm, of VPN is ingeschakeld. Waarden worden overschreven — een nieuwe sleutel met dezelfde naam vervangt de oude.

Gebeurtenissen loggen

Custom Logs zijn tekstberichten die Crashlytics opslaat in een circulaire buffer van 64 KB. Logs worden automatisch aan de volgende crash gekoppeld. Als er geen crash plaatsvindt, worden de logs niet naar de server verzonden (geen dataverbruik). Loggen wordt gebruikt om de stappen van de gebruiker voor de storing vast te leggen: "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 uit Analytics

Als Firebase Analytics in het project is aangesloten, ontvangt Crashlytics automatisch Breadcrumbs — de laatste 50 analytische gebeurtenissen voor de crash. Elke breadcrumb bevat de gebeurtenisnaam en de bijbehorende parameters. Dit maakt het mogelijk de exacte volgorde van acties die tot de storing hebben geleid te reconstrueren: gebruiker opende scherm → voegde product toe → ging naar betaling → crash vond plaats. Breadcrumbs worden weergegeven in de Issue-kaart op een apart tabblad "Logs".

Beste praktijken voor het werken met storingen

Crashlytics is het meest effectief bij een correcte configuratie van context en het Issues-verwerkingsproces. De praktijk leert dat teams die een protocol voor het werken met crashes hebben ingevoerd, de tijd voor het oplossen van kritieke bugs met 60% verkorten (gegevens Google, 2026).

Prioritering van Issues

Niet alle crashes zijn even belangrijk. Prioritering op basis van het aantal gebruikers en frequentie helpt om zich te concentreren op de meest kritieke problemen. Regel: los Issues die meer dan 0.1% van de gebruikers treffen binnen 24 uur op. Issues met eenmalige voorvallen (< 0.01%) kunnen worden uitgesteld tot de volgende geplande release. Crashlytics markeert automatisch regressies — Issues die zijn opgelost maar opnieuw zijn verschenen in een nieuwe versie.

Integratie met CI/CD

De Crashlytics API maakt integratie van storingsrapporten in de CI/CD-pipeline mogelijk via REST API of Firebase CLI. Bij elke nieuwe release kan automatisch worden gecontroleerd of het percentage crash-free users de drempelwaarde niet overschrijdt. Als de drempel wordt overschreden, blokkeert CI/CD de uitrol en stuurt een melding naar het team. Firebase CLI ondersteunt het commando firebase crashlytics:builds:upload voor het uploaden van ProGuard/R8-mappingbestanden — zonder deze zijn stacks onleesbaar.

Volgens gegevens van Google (2026) brengen apps die automatische controle van crash-free-drempels in CI/CD gebruiken 40% minder regressies in productie. Aanbevolen drempel: crash-free users >= 99.5% voor kritieke releases en >= 99.0% voor normale releases.