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 remah roti, dan/atau lansiran 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 konsol Firebase. 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 Firebase SDK ( iOS+ | Android ).
Terutama pastikan Anda menggunakan versi Firebase SDK untuk Google Analytics berikut ini: 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 masukannya disediakan oleh Google Analytics.
CRASH_FREE_USERS_PERCENTAGE = 1 - ( CRASHED_USERS / ALL_USERS ) x 100
Saat terjadi kerusakan, Google Analytics mengirimkan jenis peristiwa
app_exception, dan CRASHED_USERS mewakili jumlah pengguna yang terkait dengan jenis peristiwa tersebut.ALL_USERS menunjukkan jumlah total pengguna yang berinteraksi dengan aplikasi Anda selama jangka waktu yang telah Anda pilih dari menu tarik-turun di kanan atas dasbor Crashlytics.
Persentase pengguna bebas crash adalah agregasi dari waktu ke waktu , bukan rata-rata.
Misalnya, bayangkan aplikasi Anda memiliki tiga pengguna; kita 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 berinteraksi 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 dari 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 yang mengalami error.
Catatan memungkinkan anggota proyek mengomentari masalah tertentu dengan pertanyaan, pembaruan status, dll.
Saat anggota proyek memposting catatan, itu diberi label dengan email akun Google mereka. Alamat email ini dapat dilihat, beserta catatannya, oleh semua anggota proyek yang memiliki akses untuk melihat catatan tersebut.
Berikut ini menjelaskan akses yang diperlukan untuk melihat, menulis, dan menghapus catatan:
Anggota proyek dengan salah satu peran berikut dapat melihat dan menghapus catatan yang ada dan menulis catatan baru tentang suatu masalah.
- Pemilik atau Editor Proyek , Admin Firebase , Admin Kualitas , atau Admin Crashlytics
Anggota proyek dengan salah satu peran berikut dapat melihat catatan yang diposting pada suatu masalah, tetapi mereka tidak dapat menghapus atau menulis catatan.
Integrasi
Jika proyek Anda menggunakan Crashlytics bersama Google Mobile Ads SDK, kemungkinan pelapor 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 secara otomatis berlokasi di Amerika Serikat, di mana pun lokasi project Firebase Anda.
Dukungan platform
Masalah regresi
Sebuah masalah mengalami regresi ketika Anda sebelumnya telah menutup masalah tersebut, tetapi Crashlytics mendapatkan laporan baru bahwa masalah tersebut telah terjadi kembali. Crashlytics secara otomatis membuka kembali masalah yang muncul kembali ini sehingga Anda dapat mengatasinya sebagaimana mestinya untuk aplikasi Anda.
Berikut adalah contoh skenario yang menjelaskan cara Crashlytics mengkategorikan 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, menutup Masalah "A", lalu merilis versi baru aplikasi Anda.
- Crashlytics mendapatkan laporan lain tentang Masalah "A" setelah Anda menutup masalah tersebut.
- Jika laporan berasal dari versi aplikasi yang diketahui Crashlytics saat Anda menutup masalah (artinya versi tersebut telah mengirimkan laporan kerusakan untuk setiap kerusakan), maka Crashlytics tidak akan menganggap masalah tersebut mundur. Masalah ini akan tetap tertutup.
- Jika laporan berasal dari versi aplikasi yang tidak diketahui Crashlytics saat Anda menutup masalah (artinya versi tersebut tidak pernah mengirimkan laporan kerusakan apa pun untuk kerusakan apa pun), maka Crashlytics menganggap masalah tersebut mundur dan akan membuka kembali masalah tersebut .
Saat masalah mengalami kemunduran, kami mengirimkan peringatan deteksi regresi dan menambahkan sinyal regresi ke masalah tersebut untuk memberi tahu Anda bahwa Crashlytics telah membuka kembali masalah tersebut. Jika Anda tidak ingin masalah dibuka kembali karena algoritme regresi kami, "bisukan" masalah tersebut alih-alih menutupnya.
Jika laporan berasal dari versi aplikasi lama yang sama sekali tidak pernah mengirim laporan kerusakan apa pun saat Anda menutup masalah, Crashlytics akan menganggap masalah tersebut mundur 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 mengirimkan 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 dibuka kembali karena algoritme regresi kami, "bisukan" masalah tersebut alih-alih menutupnya.