Firebase Crashlytics — apa itu, crash dan diagnosis kegagalan

Apa itu Firebase Crashlytics

Firebase Crashlytics adalah layanan gratis Google untuk memantau stabilitas aplikasi mobile, diakuisisi oleh Google pada tahun 2017 bersama dengan perusahaan Fabric. Crashlytics secara otomatis mengumpulkan informasi tentang setiap kegagalan aplikasi, mengelompokkan crash identik berdasarkan tanda tangan stack, dan menampilkannya di konsol Firebase dengan prioritas berdasarkan jumlah pengguna yang terkena dampak.

Sejarah dan evolusi

Crashlytics diluncurkan pada tahun 2011 sebagai bagian dari platform Fabric dan dengan cepat menjadi standar de facto untuk pelaporan crash di iOS. Setelah diakuisisi oleh Google pada tahun 2017 senilai perkiraan 2 miliar dolar (seluruh Fabric), Crashlytics diintegrasikan ke dalam Firebase SDK. Versi 18.0.0 (2021) menambahkan dukungan untuk Kotlin Multiplatform, dan versi 19.0.0 (2024) — pengumpulan ANR otomatis di Android tanpa konfigurasi tambahan. Menurut data Google (2026), Crashlytics memproses lebih dari 10 miliar crash setiap bulan.

Batas gratis Crashlytics

Crashlytics diberikan gratis dengan batas 500 ribu sesi per hari per proyek Firebase. Untuk sebagian besar aplikasi ini sudah cukup — menurut data Google (2026), 95% proyek tidak melebihi batas. Saat melebihi batas, pengumpulan data tidak berhenti, tetapi laporan berhenti diperbarui hingga hari berikutnya. Untuk proyek dengan beban tinggi, tersedia tarif Spark dan Blaze Firebase — Crashlytics tetap gratis di kedua tarif, dan batas sesi dihitung secara terpisah.

Bagaimana Crashlytics mendeteksi dan mengumpulkan kegagalan

Mekanisme pengumpulan Crashlytics didasarkan pada intersepsi pengecualian di tingkat platform dan runtime. Di Android, SDK mengimplementasikan UncaughtExceptionHandler yang menangkap semua pengecualian Kotlin dan Java yang tidak tertangani. Di iOS, Crashlytics menggunakan NSSetUncaughtExceptionHandler untuk Objective-C/Swift dan penangan pengecualian Mach sendiri untuk crash kode native.

Jenis kegagalan yang ditangkap

Crashlytics membedakan lima jenis kegagalan: fatal (crash fatal), non-fatal (pengecualian non-fatal yang dikirimkan secara manual), ANR (Android — aplikasi tidak merespons), signal (sinyal OS — SIGSEGV, SIGABRT) dan OOM (kehabisan memori di iOS). Setiap jenis diproses oleh mekanisme terpisah dan ditampilkan di konsol dengan label yang sesuai.

Format laporan kegagalan

Setiap laporan Crashlytics berisi informasi lengkap: pelacakan stack penuh dengan nama kelas dan nomor baris, versi aplikasi (versionName + versionCode), model perangkat, versi OS, jumlah memori bebas, orientasi layar, dan waktu sejak startup. Jika Firebase Analytics terhubung, laporan juga menyertakan jalur dari 50 peristiwa terakhir pengguna sebelum kegagalan — ini sangat penting untuk mereproduksi 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")
    }
}

Integrasi Crashlytics ke proyek Android

Menghubungkan Crashlytics ke aplikasi Android memerlukan penambahan dua dependensi di build.gradle dan konfigurasi plugin Google Services. SDK secara otomatis mengaktifkan pelaporan crash saat inisialisasi Firebase tanpa kode tambahan. Untuk pengoperasian yang benar, plugin google-services dan file google-services.json dari konsol Firebase juga diperlukan.

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

Konfigurasi plugin Crashlytics

Plugin com.google.firebase.crashlytics melakukan dua tugas: menghasilkan pengidentifikasi build unik (build ID) untuk pemetaan stack yang diobfusikasi dan secara otomatis membuat sumber daya untuk Crashlytics SDK. Tanpa plugin, crash akan ditandai sebagai "unmapped" — Anda hanya akan melihat nama kelas yang diobfusikasi (a.b.c) tanpa kemampuan menemukan kode sumber. Plugin ditambahkan ke build.gradle root dan ke build.gradle modul aplikasi.

Memeriksa integrasi

Untuk menguji integrasi Crashlytics, gunakan metode khusus forceCrash() yang menghasilkan pengecualian uji. Dalam build produksi, metode ini tidak tersedia. Setelah menjalankan crash uji, laporan muncul di konsol Firebase dalam 1-5 menit. Jika laporan tidak ditampilkan — periksa apakah google-services.json sesuai dengan paket aplikasi dan tidak ada flag di AndroidManifest yang menonaktifkan pengumpulan data.

Analisis crash dan pengelompokan laporan

Konsol Crashlytics menyediakan dua tingkat tampilan: daftar semua crash (Issues) yang dikelompokkan berdasarkan jenis kegagalan, dan laporan terperinci untuk setiap Issue dengan pelacakan, statistik, dan data pengguna. Setiap Issue menggabungkan semua crash dengan tanda tangan yang sama — jenis pengecualian yang sama dan pelacakan stack yang cocok.

Issues dan pengelompokan

Pengelompokan crash — fitur utama Crashlytics. Alih-alih menampilkan ribuan crash individual, layanan menggabungkannya ke dalam Issues berdasarkan fingerprint — checksum dari pelacakan stack. Satu Issue dapat berisi 1 hingga beberapa juta crash. Untuk setiap Issue ditampilkan: jumlah kasus fatal, jumlah pengguna unik, versi aplikasi tempat crash muncul, dan persentase pengguna yang mengalami masalah.

Menurut data Google (2026), rata-rata 20% Issues menyebabkan 80% dari semua crash fatal aplikasi (prinsip Pareto). Crashlytics secara otomatis mengurutkan Issues berdasarkan tingkat keparahan — semakin banyak pengguna yang terkena dampak, semakin tinggi prioritasnya. Ini memungkinkan pengembang untuk memperbaiki masalah paling masif terlebih dahulu.

Statistik per versi

Crashlytics melacak stabilitas setiap versi aplikasi secara terpisah. Grafik crash-free users menunjukkan persentase pengguna yang tidak mengalami crash fatal di setiap versi. Jika saat pembaruan persentase turun di bawah ambang batas (default 99%), Crashlytics mengirimkan notifikasi melalui email dan di Firebase Console. Ini memungkinkan penarikan cepat versi bermasalah atau merilis hotfix.

Kunci khusus, log, dan Breadcrumbs

Crashlytics menyediakan tiga mekanisme untuk memperkaya laporan dengan konteks: kunci khusus (keys) untuk data terstruktur, log (logs) untuk pelacakan teks, dan Breadcrumbs dari Analytics untuk jalur pengguna. Ketiga jenis data dilampirkan ke laporan crash dan terlihat di kartu detailnya.

Kunci khusus

Custom Keys — adalah pasangan "kunci-nilai" yang dikirim bersama setiap crash. Maksimum 64 kunci per aplikasi, setiap kunci — string dengan panjang hingga 1024 karakter. Kunci berguna untuk menandai status aplikasi: tingkat langganan, status otorisasi, layar terakhir, apakah VPN diaktifkan. Nilai ditimpa — kunci baru dengan nama yang sama menggantikan yang lama.

Logging peristiwa

Custom Logs — adalah pesan teks yang disimpan Crashlytics dalam buffer melingkar berukuran 64 KB. Log secara otomatis dilampirkan ke crash berikutnya. Jika tidak ada crash yang terjadi — log tidak dikirim ke server (tidak menghabiskan lalu lintas). Logging digunakan untuk mencatat langkah-langkah pengguna sebelum kegagalan: "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 dari Analytics

Jika Firebase Analytics terhubung di proyek, Crashlytics secara otomatis menerima Breadcrumbs — 50 peristiwa analitik terakhir sebelum crash. Setiap breadcrumb berisi nama peristiwa dan parameternya. Ini memungkinkan rekonstruksi urutan tindakan yang tepat yang menyebabkan kegagalan: pengguna membuka layar → menambahkan produk → melanjutkan ke pembayaran → terjadi crash. Breadcrumbs ditampilkan di kartu Issue pada tab terpisah "Logs".

Praktik terbaik bekerja dengan kegagalan

Crashlytics paling efektif dengan konfigurasi konteks yang tepat dan proses penanganan Issues. Praktik menunjukkan bahwa tim yang menerapkan aturan kerja dengan crash mengurangi waktu perbaikan bug kritis sebesar 60% (data Google, 2026).

Prioritisasi Issues

Tidak semua crash sama pentingnya. Prioritisasi berdasarkan jumlah pengguna dan frekuensi kemunculan membantu fokus pada masalah paling kritis. Aturan: perbaiki Issues yang memengaruhi lebih dari 0.1% pengguna dalam waktu 24 jam. Issues dengan kemunculan tunggal (< 0.01%) dapat ditunda hingga rilis terjadwal berikutnya. Crashlytics secara otomatis menandai regresi — Issues yang telah diperbaiki tetapi muncul kembali di versi baru.

Integrasi dengan CI/CD

Crashlytics API memungkinkan integrasi laporan kegagalan ke dalam pipeline CI/CD melalui REST API atau Firebase CLI. Pada setiap rilis baru, Anda dapat secara otomatis memeriksa apakah persentase crash-free users tidak melebihi ambang batas. Jika ambang batas terlampaui — CI/CD memblokir penyebaran dan mengirim notifikasi ke tim. Firebase CLI mendukung perintah firebase crashlytics:builds:upload untuk mengunggah file pemetaan ProGuard/R8 — tanpanya, stack tidak akan terbaca.

Menurut data Google (2026), aplikasi yang menggunakan pemeriksaan otomatis ambang batas crash-free di CI/CD menghasilkan 40% lebih sedikit regresi ke produksi. Ambang batas yang direkomendasikan: crash-free users >= 99.5% untuk rilis kritis dan >= 99.0% untuk rilis biasa.