Firebase Crashlytics — co to jest, crashe i diagnostyka awarii

Co to jest Firebase Crashlytics

Firebase Crashlytics — to bezpłatna usługa Google do monitorowania stabilności aplikacji mobilnych, przejęta przez Google w 2017 roku wraz z firmą Fabric. Crashlytics automatycznie zbiera informacje o każdej awarii aplikacji, grupuje identyczne crashe według sygnatury stosu i wyświetla je w konsoli Firebase z priorytetyzacją według liczby dotkniętych użytkowników.

Historia i ewolucja

Crashlytics został uruchomiony w 2011 roku jako część platformy Fabric i szybko stał się standardem de facto w raportowaniu crashy w iOS. Po przejęciu przez Google w 2017 roku za szacowane 2 miliardy dolarów (cały Fabric) Crashlytics został zintegrowany z Firebase SDK. Wersja 18.0.0 (2021) dodała obsługę Kotlin Multiplatform, a wersja 19.0.0 (2024) — automatyczne zbieranie ANR na Androidzie bez dodatkowej konfiguracji. Według danych Google (2026), Crashlytics przetwarza ponad 10 miliardów crashy miesięcznie.

Bezpłatne limity Crashlytics

Crashlytics jest dostępny bezpłatnie z limitem 500 tysięcy sesji dziennie na jeden projekt Firebase. Dla większości aplikacji to wystarczy — według danych Google (2026), 95% projektów nie przekracza limitu. W przypadku przekroczenia zbieranie danych nie zostaje przerwane, ale raporty przestają się aktualizować do następnego dnia. Dla projektów o wysokim obciążeniu dostępne są taryfy Spark i Blaze Firebase — Crashlytics pozostaje bezpłatny na obu taryfach, a limit sesji jest liczony oddzielnie.

Jak Crashlytics wykrywa i zbiera awarie

Mechanizm zbierania Crashlytics opiera się na przechwytywaniu wyjątków na poziomie platformy i środowiska wykonawczego. Na Androidzie SDK implementuje UncaughtExceptionHandler, przechwytujący wszystkie nieobsłużone wyjątki Kotlin i Java. W iOS Crashlytics używa NSSetUncaughtExceptionHandler dla Objective-C/Swift i własnego handlera wyjątków Mach dla crashy kodu natywnego.

Rodzaje przechwytywanych awarii

Crashlytics rozróżnia pięć typów awarii: fatal (śmiertelne crashe), non-fatal (nieśmiertelne wyjątki przekazane ręcznie), ANR (Android — aplikacja nie odpowiada), signal (sygnały OS — SIGSEGV, SIGABRT) i OOM (brak pamięci w iOS). Każdy typ jest obsługiwany przez oddzielny mechanizm i wyświetlany w konsoli z odpowiednią etykietą.

Format raportu o awarii

Każdy raport Crashlytics zawiera wyczerpujące informacje: pełny tracement stosu z nazwami klas i numerami linii, wersję aplikacji (versionName + versionCode), model urządzenia, wersję OS, ilość wolnej pamięci, orientację ekranu i czas od uruchomienia. Jeśli podłączony jest Firebase Analytics, raport zawiera również ścieżkę ostatnich 50 zdarzeń użytkownika przed awarią — to krytycznie ważne dla odtworzenia crasha.

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

Integracja Crashlytics w projekcie Android

Podłączenie Crashlytics do aplikacji Android wymaga dodania dwóch zależności w build.gradle i konfiguracji wtyczki Google Services. SDK automatycznie uruchamia raportowanie crashy przy inicjalizacji Firebase bez dodatkowego kodu. Do prawidłowego działania wymagana jest również wtyczka google-services i plik google-services.json z konsoli Firebase.

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

Konfiguracja wtyczki Crashlytics

Wtyczka com.google.firebase.crashlytics wykonuje dwa zadania: generuje unikalny identyfikator kompilacji (build ID) do mapowania zaciemnionych stosów i automatycznie tworzy zasoby dla Crashlytics SDK. Bez wtyczki crashe będą oznaczane jako "unmapped" — zobaczysz tylko zaciemnione nazwy klas (a.b.c) bez możliwości znalezienia kodu źródłowego. Wtyczkę dodaje się do głównego build.gradle i do build.gradle modułu aplikacji.

Sprawdzenie integracji

Do testowania integracji Crashlytics używa się specjalnej metody forceCrash(), która generuje testowy wyjątek. W kompilacjach produkcyjnych ta metoda jest niedostępna. Po uruchomieniu testowego crasha raport pojawia się w konsoli Firebase w ciągu 1-5 minut. Jeśli raport się nie wyświetla — sprawdź, czy google-services.json odpowiada pakietowi aplikacji i czy w AndroidManifest nie ma flag wyłączających zbieranie danych.

Analiza crashy i grupowanie raportów

Konsola Crashlytics zapewnia dwa poziomy przeglądania: listę wszystkich crashy (Issues) z grupowaniem według typu awarii oraz szczegółowy raport dla każdego Issue z tracementem, statystykami i danymi użytkownika. Każdy Issue łączy wszystkie crashe z tą samą sygnaturą — tym samym typem wyjątku i pasującym tracementem stosu.

Issues i grupowanie

Grupowanie crashy — kluczowa cecha Crashlytics. Zamiast pokazywać tysiące pojedynczych crashy, usługa łączy je w Issues na podstawie fingerprint — sumy kontrolnej tracementu stosu. Jeden Issue może zawierać od 1 do kilku milionów crashy. Dla każdego Issue wyświetlane są: liczba śmiertelnych przypadków, liczba unikalnych użytkowników, wersja aplikacji, w której pojawił się crash, oraz procent użytkowników, którzy napotkali problem.

Według danych Google (2026), średnio 20% Issues stanowi 80% wszystkich śmiertelnych crashy aplikacji (zasada Pareto). Crashlytics automatycznie sortuje Issues według severity — im więcej użytkowników dotkniętych, tym wyższy priorytet. Pozwala to programiście w pierwszej kolejności naprawiać najbardziej masowe problemy.

Statystyki według wersji

Crashlytics śledzi stabilność każdej wersji aplikacji oddzielnie. Wykres crash-free users pokazuje procent użytkowników, którzy nie napotkali śmiertelnego crasha w danej wersji. Jeśli przy aktualizacji procent spadnie poniżej progu (domyślnie 99%), Crashlytics wysyła powiadomienie e-mailem i w Firebase Console. Pozwala to szybko wycofać problematyczną wersję lub wydać hotfix.

Klucze użytkownika, logi i Breadcrumbs

Crashlytics zapewnia trzy mechanizmy wzbogacania raportów kontekstem: klucze użytkownika (keys) dla danych strukturalnych, logi (logs) dla tracementu tekstowego i Breadcrumbs z Analytics dla ścieżki użytkownika. Wszystkie trzy typy danych są dołączane do raportu o awarii i widoczne w jego szczegółowej karcie.

Klucze użytkownika

Custom Keys — to pary "klucz-wartość", które są przekazywane wraz z każdym crashem. Maksymalnie 64 kluczy na aplikację, każdy klucz — ciąg znaków o długości do 1024 znaków. Klucze są wygodne do oznaczania stanu aplikacji: poziom subskrypcji, status autoryzacji, ostatni ekran, czy VPN jest włączony. Wartości nadpisują się — nowy klucz o tej samej nazwie zastępuje stary.

Logowanie zdarzeń

Custom Logs — to wiadomości tekstowe, które Crashlytics przechowuje w buforze cyklicznym o rozmiarze 64 KB. Logi są automatycznie dołączane do następnego crasha. Jeśli crash nie wystąpi — logi nie są przesyłane na serwer (nie zużywają transferu). Logowanie służy do zapisywania kroków użytkownika przed awarią: "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 z Analytics

Jeśli w projekcie podłączony jest Firebase Analytics, Crashlytics automatycznie otrzymuje Breadcrumbs — ostatnie 50 zdarzeń analitycznych przed crashem. Każdy breadcrumb zawiera nazwę zdarzenia i jego parametry. Pozwala to odtworzyć dokładną sekwencję działań, które doprowadziły do awarii: użytkownik otworzył ekran → dodał produkt → przeszedł do płatności → wystąpił crash. Breadcrumbs są wyświetlane w karcie Issue na osobnej zakładce "Logs".

Najlepsze praktyki pracy z awariami

Crashlytics jest najbardziej efektywny przy prawidłowej konfiguracji kontekstu i procesu obsługi Issues. Praktyka pokazuje, że zespoły, które wdrożyły regulamin pracy z crashemi, skracają czas naprawy krytycznych błędów o 60% (dane Google, 2026).

Priorytetyzacja Issues

Nie wszystkie crashe są równie ważne. Priorytetyzacja według liczby użytkowników i częstotliwości występowania pomaga skupić się na najbardziej krytycznych problemach. Zasada: naprawiać Issues dotykające więcej niż 0.1% użytkowników w ciągu 24 godzin. Issues z pojedynczymi wystąpieniami (< 0.01%) można odłożyć do następnego planowego wydania. Crashlytics automatycznie oznacza regresje — Issues, które zostały naprawione, ale pojawiły się ponownie w nowej wersji.

Integracja z CI/CD

Crashlytics API umożliwia integrację raportów o awariach z pipeline CI/CD przez REST API lub Firebase CLI. Przy każdym nowym wydaniu można automatycznie sprawdzać, czy procent crash-free users nie przekracza wartości progowej. Jeśli próg zostanie przekroczony — CI/CD blokuje wdrożenie i wysyła powiadomienie zespołowi. Firebase CLI obsługuje komendę firebase crashlytics:builds:upload do przesyłania plików mapowania ProGuard/R8 — bez nich stosy będą nieczytelne.

Według danych Google (2026), aplikacje używające automatycznego sprawdzania progów crash-free w CI/CD wypuszczają o 40% mniej regresji do produkcji. Zalecany próg: crash-free users >= 99.5% dla krytycznych wydań i >= 99.0% dla zwykłych.