Halaman ini memberikan bantuan pemecahan masalah dan jawaban atas pertanyaan umum tentang penggunaan Crashlytics. Jika Anda tidak dapat menemukan yang Anda cari atau memerlukan bantuan tambahan, hubungi dukungan Firebase .
Pemecahan masalah umum/FAQ
Jika Anda tidak melihat pengguna bebas error, log breadcrumb, dan/atau peringatan kecepatan, sebaiknya periksa konfigurasi aplikasi Anda untuk Google Analytics.
Pastikan Anda telah mengaktifkan Google Analytics di proyek Firebase Anda.
Pastikan Berbagi data diaktifkan untuk Google Analytics di halaman Integrasi > Google Analytics di Firebase console. Perhatikan bahwa setelan Berbagi data ditampilkan di konsol Firebase tetapi dikelola di konsol Google Analytics.
Selain Firebase Crashlytics SDK, pastikan Anda telah menambahkan Firebase SDK untuk Google Analytics ke aplikasi Anda ( iOS+ | Android ).
Pastikan Anda menggunakan versi terbaru untuk semua SDK Firebase Anda ( iOS+ | Android ).
Terutama periksa apakah Anda menggunakan minimal versi Firebase SDK untuk Google Analytics berikut: iOS+ — v6.3.1+ (v8.9.0+ untuk macOS dan tvOS) | Android — v17.2.3+(BoM v24.7.1+) .
Nilai bebas error menunjukkan persentase pengguna yang berinteraksi dengan aplikasi Anda tetapi tidak mengalami error selama jangka waktu tertentu.
Berikut adalah rumus untuk menghitung persentase pengguna bebas crash. Nilai inputnya disediakan oleh Google Analytics.
1 - ( CRASHED_USERS / ALL_USERS )
Saat terjadi error, Google Analytics mengirimkan jenis peristiwa
app_exception, dan CRASHED_USERS mewakili jumlah pengguna yang terkait dengan jenis peristiwa tersebut.ALL_USERS mewakili jumlah total pengguna yang terlibat dengan aplikasi Anda selama jangka waktu yang Anda pilih dari menu tarik-turun di kanan atas dasbor Crashlytics.
Anda dapat melihat jumlah peristiwa app_exception untuk aplikasi Anda di dasbor Analytics. Perhatikan bahwa karena perbedaan kecil dalam cara error diproses, jumlah app_exception yang ditampilkan di dasbor Analytics terkadang berbeda dari jumlah yang digunakan dalam penghitungan pengguna bebas error.
Persentase pengguna bebas error adalah agregasi dari waktu ke waktu , bukan rata-rata.
Misalnya, bayangkan aplikasi Anda memiliki tiga pengguna; kami akan menyebutnya Pengguna A, Pengguna B, dan Pengguna C. Tabel berikut menunjukkan pengguna mana yang berinteraksi dengan aplikasi Anda setiap hari dan pengguna mana yang mengalami error pada hari itu:
| Senin | Selasa | Rabu | |
|---|---|---|---|
| Pengguna yang terlibat dengan aplikasi Anda | A, B, C | A, B, C | A, B |
| Pengguna yang mengalami crash | C | B | SEBUAH |
Pada hari Rabu, persentase pengguna bebas error Anda adalah 50% (1 dari 2 pengguna bebas error).
Dua pengguna Anda berinteraksi dengan aplikasi Anda pada hari Rabu, tetapi hanya satu dari mereka (Pengguna B) yang tidak mengalami error.Selama 2 hari terakhir, persentase pengguna bebas error Anda adalah 33,3% (1 dari 3 pengguna bebas error).
Tiga pengguna Anda berinteraksi dengan aplikasi Anda selama dua hari terakhir, tetapi hanya satu dari mereka (Pengguna C) yang tidak mengalami error.Selama 3 hari terakhir, persentase pengguna bebas error Anda adalah 0% (0 dari 3 pengguna bebas error).
Tiga dari pengguna Anda berinteraksi dengan aplikasi Anda selama tiga hari terakhir, tetapi tidak ada dari mereka yang tidak mengalami error.
Integrasi
Jika proyek Anda menggunakan Crashlytics bersama SDK Iklan Seluler Google, kemungkinan reporter kerusakan mengganggu saat mendaftarkan penangan pengecualian. Untuk memperbaiki masalah ini, nonaktifkan pelaporan kerusakan di Mobile Ads SDK dengan memanggil disableSDKCrashReporting .
Setelah Anda menautkan Crashlytics ke BigQuery, set data baru yang Anda buat akan otomatis berada di Amerika Serikat, terlepas dari lokasi project Firebase Anda.
Dukungan platform
Masalah yang mundur
Masalah mengalami regresi ketika Anda sebelumnya telah menutup masalah, tetapi Crashlytics mendapat laporan baru bahwa masalah telah terjadi kembali. Crashlytics secara otomatis membuka kembali masalah yang muncul kembali ini sehingga Anda dapat mengatasinya sesuai kebutuhan untuk aplikasi Anda.
Berikut adalah contoh skenario yang menjelaskan cara Crashlytics mengategorikan masalah sebagai regresi:
- Untuk pertama kalinya, Crashlytics mendapatkan laporan kerusakan tentang Kerusakan "A". Crashlytics membuka masalah terkait untuk kerusakan tersebut (Masalah "A").
- Anda memperbaiki bug ini dengan cepat, tutup Masalah "A", lalu rilis versi baru aplikasi Anda.
- Crashlytics mendapatkan laporan lain tentang Masalah "A" setelah Anda menyelesaikan masalah.
- Jika laporan berasal dari versi aplikasi yang diketahui Crashlytics saat Anda menutup masalah (artinya versi tersebut telah mengirimkan laporan kerusakan untuk kerusakan apa pun ), maka Crashlytics tidak akan menganggap masalah sebagai kemunduran. Masalah akan tetap tertutup.
- Jika laporan berasal dari versi aplikasi yang tidak diketahui Crashlytics saat Anda menutup masalah (artinya versi tersebut tidak pernah mengirim laporan kerusakan apa pun untuk kerusakan apa pun), maka Crashlytics menganggap masalah tersebut telah diperbaiki dan akan membuka kembali masalah tersebut .
Saat masalah muncul kembali, kami mengirimkan peringatan deteksi regresi dan menambahkan sinyal regresi ke masalah untuk memberi tahu Anda bahwa Crashlytics telah membuka kembali masalah tersebut. Jika Anda tidak ingin masalah terbuka kembali karena algoritme regresi kami, "bisukan" masalah alih-alih menutupnya.
Jika laporan berasal dari versi aplikasi lama yang tidak pernah mengirimkan laporan kerusakan sama sekali saat Anda menutup masalah, Crashlytics menganggap masalah tersebut sebagai kemunduran dan akan membuka kembali masalah tersebut.
Situasi ini dapat terjadi dalam situasi berikut: Anda telah memperbaiki bug dan merilis versi baru aplikasi, tetapi Anda masih memiliki pengguna di versi lama tanpa perbaikan bug. Jika, secara kebetulan, salah satu versi lama tersebut tidak pernah mengirim laporan kerusakan sama sekali saat Anda menutup masalah, dan pengguna tersebut mulai menemukan bug, maka laporan kerusakan tersebut akan memicu masalah yang muncul kembali.
Jika Anda tidak ingin masalah terbuka kembali karena algoritme regresi kami, "bisukan" masalah alih-alih menutupnya.