Halaman ini memberikan bantuan pemecahan masalah dan jawaban atas pertanyaan umum (FAQ) tentang penggunaan Crashlytics. Jika tidak dapat menemukan hal yang Anda cari atau membutuhkan bantuan lainnya, hubungi dukungan Firebase.
FAQ/pemecahan masalah umum
Tidak melihat pengguna bebas error, log breadcrumb, dan/atau pemberitahuan kecepatan
Jika tidak melihat pengguna bebas error, log breadcrumb, dan/atau pemberitahuan kecepatan, sebaiknya periksa konfigurasi Google Analytics untuk aplikasi Anda.
Pastikan Anda telah mengaktifkan Google Analytics di project Firebase Anda.
Pastikan Data sharing telah diaktifkan untuk Google Analytics di halaman Integrations > Google Analytics pada Firebase console. Perhatikan bahwa setelan Data sharing ditampilkan di Firebase console, 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 setidaknya 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+)
Melihat dua format yang berbeda dalam tabel Issues
Anda mungkin melihat dua format berbeda untuk masalah yang tercantum dalam tabel Issues di Firebase console. Berikut adalah alasannya.
Crashlytics menganalisis semua peristiwa dari aplikasi Anda — error, non-fatal, dan ANR — serta mengelompokkan peristiwa serupa ke dalam masalah terpisah. Pada bulan Januari 2023, kami meluncurkan mesin analisis yang telah ditingkatkan untuk mengelompokkan peristiwa berdasarkan kode aplikasi Anda dan desain yang diperbarui untuk menampilkan masalah baru.
Berikut adalah hal yang akan Anda temukan dengan peningkatan ini:
Metadata yang diperbarui ditampilkan dalam baris Issue
Kini lebih mudah untuk memahami dan menanggulangi masalah di aplikasi Anda.Lebih sedikit masalah duplikat
Perubahan nomor baris tidak menyebabkan masalah baru.Peringatan dan sinyal yang lebih bermakna
Masalah baru benar-benar mewakili bug baru.Penelusuran yang lebih canggih
Setiap masalah berisi metadata yang lebih mudah ditelusuri, seperti jenis pengecualian dan nama paket.
Berikut adalah peningkatan yang diluncurkan:
Saat mendapatkan peristiwa baru dari aplikasi Anda, kami akan memeriksa apakah peristiwa tersebut cocok dengan masalah yang ada.
Jika tidak ada kecocokan, kami akan otomatis menerapkan algoritme pengelompokan peristiwa yang lebih cerdas ke peristiwa tersebut dan membuat masalah baru dengan desain metadata yang diubah.
Ini adalah update besar pertama yang kami buat pada pengelompokan peristiwa. Jika Anda memiliki masukan atau mengalami masalah, beri tahu kami dengan mengirimkan laporan.
Mengapa ANR hanya dilaporkan untuk Android 11+?
Crashlytics mendukung pelaporan ANR untuk aplikasi Android dari perangkat yang menjalankan Android 11 dan versi yang lebih tinggi. API yang mendasari yang kami gunakan untuk mengumpulkan ANR (getHistoricalProcessExitReasons) lebih andal dibandingkan pendekatan berbasis SIGQUIT atau watchdog. API ini hanya tersedia di perangkat Android 11+.
Perbedaan antara laporan ANR di dasbor Crashlytics dan Konsol Google Play
Kemungkinan ada ketidakcocokan pada jumlah ANR antara Google Play dan Crashlytics. Hal ini wajar karena adanya perbedaan mekanisme pengumpulan dan pelaporan data ANR. Crashlytics melaporkan ANR saat aplikasi dimulai kembali, sedangkan Android Vitals mengirimkan data ANR setelah ANR terjadi.
Selain itu, Crashlytics hanya menampilkan ANR yang terjadi di perangkat yang menjalankan Android 11+, dibandingkan dengan Google Play yang menampilkan ANR dari perangkat yang menerima izin pengumpulan data dan layanan Google Play.
Perbedaan antara pelacakan tumpukan NDK di dasbor Crashlytics dan logcat
Toolchain LLVM dan GNU memiliki default dan penanganan yang berbeda untuk segmen hanya baca pada biner aplikasi, yang dapat menghasilkan pelacakan tumpukan yang tidak konsisten di Firebase console. Untuk mengatasi ini, tambahkan flag penaut berikut ke proses build Anda:
Jika menggunakan penaut
llddari toolchain LLVM, tambahkan:-Wl,--no-rosegmentJika menggunakan penaut
ld.golddari toolchain GNU, tambahkan:-Wl,--rosegment
Jika masih melihat inkonsistensi pelacakan tumpukan (atau jika tidak satu pun flag tersebut relevan dengan toolchain Anda), coba tambahkan flag penaut berikut ke proses build:
-fno-omit-frame-pointer
Bagaimana cara menggunakan biner generator file simbol Breakpad saya sendiri untuk NDK?
Plugin Crashlytics menyertakan generator file simbol Breakpad yang disesuaikan.
Jika lebih suka menggunakan biner sendiri untuk membuat file simbol Breakpad (misalnya, jika Anda lebih memilih untuk mem-build semua file native yang dapat dieksekusi dalam rantai build dari sumber), gunakan properti ekstensi symbolGeneratorBinary opsional untuk menentukan jalur ke file yang dapat dieksekusi tersebut.
Anda dapat menentukan jalur ke biner generator file simbol Breakpad dengan salah satu dari dua cara berikut:
Opsi 1: Menentukan jalur melalui ekstensi
firebaseCrashlyticsdi filebuild.gradleAndaTambahkan blok berikut ini ke file
build.gradlelevel aplikasi Anda:android { // ... buildTypes { // ... release { // ... firebaseCrashlytics { // existing; required for either symbol file generator nativeSymbolUploadEnabled true // Add this optional new block to specify the path to the executable symbolGenerator { breakpad { binary file("/PATH/TO/BREAKPAD/DUMP_SYMS") } } } } }Opsi 2: Menentukan jalur melalui baris properti di file properti Gradle Anda
Anda dapat menggunakan properti
com.google.firebase.crashlytics.symbolGeneratorBinaryuntuk menentukan jalur ke file yang dapat dieksekusi.Anda dapat memperbarui file properti Gradle secara manual atau melalui command line. Misalnya, untuk menentukan jalur melalui command line, gunakan perintah seperti berikut:
./gradlew -Pcom.google.firebase.crashlytics.symbolGenerator=breakpad \ -Pcom.google.firebase.crashlytics.symbolGeneratorBinary=/PATH/TO/BREAKPAD/DUMP_SYMS \ app:assembleRelease app:uploadCrashlyticsSymbolFileRelease
Tidak ada error dengan DexGuard
Jika melihat pengecualian berikut, kemungkinan Anda menggunakan versi DexGuard yang tidak kompatibel dengan Firebase Crashlytics SDK:
java.lang.IllegalArgumentException: Transport backend 'cct' is not registered
Pengecualian ini tidak menyebabkan aplikasi Anda error, tetapi mencegahnya mengirim laporan error. Untuk memperbaikinya:
Gunakan rilis DexGuard 8.x terbaru. Versi terbaru berisi aturan yang diperlukan oleh Firebase Crashlytics SDK.
Jika tidak ingin mengubah versi DexGuard, coba tambahkan baris berikut ke aturan obfuscation (di file konfigurasi DexGuard):
-keepresourcexmlelements manifest/application/service/meta-data@value=cct
Mengapa saya melihat error dari file .kt yang diberi label sebagai masalah .java?
Saat aplikasi menggunakan obfuscator yang tidak mengekspos ekstensi file, Crashlytics membuat setiap masalah dengan ekstensi file .java secara default.
Agar Crashlytics dapat membuat masalah dengan ekstensi file yang benar, pastikan aplikasi Anda menggunakan penyiapan berikut:
- Menggunakan Android Gradle 4.2.0 atau versi yang lebih tinggi
- Menggunakan R8 dengan obfuscation diaktifkan. Untuk mengupdate aplikasi ke R8, ikuti dokumentasi ini.
Perlu diperhatikan bahwa setelah memperbarui penyiapan sesuai dengan yang dijelaskan di atas, Anda mungkin akan mulai melihat masalah .kt baru yang merupakan duplikat dari masalah .java yang sudah ada. Lihat FAQ untuk mempelajari situasi tersebut lebih lanjut.
Mengapa saya melihat masalah .kt yang merupakan duplikat dari masalah .java yang sudah ada?
Mulai pertengahan Desember 2021, Crashlytics meningkatkan dukungan untuk aplikasi yang menggunakan Kotlin.
Hingga baru-baru ini, obfuscator yang tersedia tidak mengekspos ekstensi file, sehingga Crashlytics membuat setiap masalah dengan ekstensi file .java secara default.
Namun, pada Android Gradle 4.2.0, R8 mendukung ekstensi file.
Dengan update ini, Crashlytics kini dapat menentukan apakah setiap class yang digunakan dalam aplikasi ditulis dengan Kotlin dan menyertakan nama file yang benar dalam tanda tangan masalah. Error kini diatribusikan dengan benar ke file .kt (yang sesuai) jika aplikasi Anda memiliki penyiapan berikut:
- Aplikasi Anda menggunakan Android Gradle 4.2.0 atau versi yang lebih tinggi.
- Aplikasi Anda menggunakan R8 dengan obfuscation diaktifkan.
Karena error baru kini menyertakan ekstensi file yang benar dalam tanda tangan masalahnya, Anda mungkin melihat masalah .kt baru yang sebenarnya hanya merupakan duplikat dari masalah berlabel .java yang sudah ada. Di Firebase console, kami mencoba mengidentifikasi dan memberi tahu Anda jika masalah .kt baru merupakan kemungkinan duplikat dari masalah berlabel .java yang sudah ada.
Bagaimana cara penghitungan pengguna bebas error?
Nilai bebas error merepresentasikan persentase pengguna yang berinteraksi dengan aplikasi Anda, tetapi tidak mengalami error selama jangka waktu tertentu.
Berikut adalah rumus untuk menghitung persentase pengguna bebas error. Nilai inputnya diberikan oleh Google Analytics.
CRASH_FREE_USERS_PERCENTAGE = 1 - (CRASHED_USERS / ALL_USERS) x 100
Saat terjadi error, Google Analytics akan mengirimkan jenis peristiwa
app_exception, dan CRASHED_USERS menunjukkan jumlah pengguna yang terkait dengan jenis peristiwa tersebut.ALL_USERS adalah jumlah total pengguna yang berinteraksi dengan aplikasi Anda selama jangka waktu yang dipilih dari menu drop-down di kanan atas dasbor Crashlytics.
Persentase pengguna bebas error adalah agregasi dari waktu ke waktu, bukan rata-rata.
Misalnya, bayangkan aplikasi Anda memiliki tiga pengguna; sebut saja Pengguna A, Pengguna B, dan Pengguna C. Tabel berikut menunjukkan pengguna yang berinteraksi dengan aplikasi Anda setiap hari dan pengguna yang mengalami error di hari tersebut:
| Senin | Selasa | Rabu | |
|---|---|---|---|
| Pengguna yang berinteraksi dengan aplikasi Anda | A, B, C | A, B, C | A, B |
| Pengguna yang mengalami error | C | B | A |
Pada hari Rabu, persentase pengguna bebas error Anda adalah 50% (1 dari 2 pengguna tidak mengalami error).
Dua pengguna berinteraksi dengan aplikasi Anda pada hari Rabu, tetapi hanya salah satu pengguna (Pengguna B) yang tidak mengalami error.Selama 2 hari terakhir, persentase pengguna bebas error Anda adalah 33,3% (1 dari 3 pengguna tidak mengalami error).
Tiga pengguna berinteraksi dengan aplikasi Anda selama dua hari terakhir, tetapi hanya salah satu dari mereka (Pengguna C) yang tidak mengalami error.Selama 3 hari terakhir, persentase pengguna bebas error adalah 0% (0 dari 3 pengguna tidak mengalami error).
Tiga pengguna berinteraksi dengan aplikasi Anda selama tiga hari terakhir, tetapi tidak satu pun dari mereka yang tidak mengalami error.
Siapa yang dapat melihat, menulis, dan menghapus catatan tentang masalah?
Catatan memungkinkan anggota project untuk mengomentari masalah tertentu dengan pertanyaan, update status, dll.
Saat anggota project memposting catatan, catatan tersebut akan diberi label dengan email akun Google-nya. Alamat email ini akan terlihat bersama dengan catatan oleh semua anggota project yang memiliki akses untuk melihat catatan tersebut.
Berikut ini akan dijelaskan tentang akses yang diperlukan untuk melihat, menulis, dan menghapus catatan:
Anggota project dengan salah satu peran berikut dapat melihat dan menghapus catatan yang ada dan menulis catatan baru tentang suatu masalah.
- Pemilik atau Editor Project, Firebase Admin, Quality Admin, atau Crashlytics Admin
Anggota project dengan salah satu peran berikut dapat melihat catatan yang diposting tentang masalah, tetapi mereka tidak dapat menghapus atau menulis catatan.
- Project Viewer, Firebase Viewer, Quality Viewer, atau Crashlytics Viewer
Integrasi
Aplikasi juga menggunakan Google Mobile Ads SDK tetapi tidak mengalami error
Jika project Anda menggunakan Crashlytics bersama dengan Google Mobile Ads SDK, mungkin terjadi gangguan dari pelapor error saat pengendali pengecualian didaftarkan. Untuk memperbaiki masalah ini, nonaktifkan pelaporan error di Mobile Ads SDK dengan memanggil disableSDKCrashReporting.
Di mana lokasi set data BigQuery saya?
Setelah Anda menautkan Crashlytics ke BigQuery, set data baru yang Anda buat secara otomatis berada di Amerika Serikat, terlepas dari lokasi project Firebase Anda.
Dukungan platform
Apakah Crashlytics mendukung armeabi?
Firebase Crashlytics NDK tidak mendukung ARMv5 (armeabi). Dukungan untuk ABI ini telah dihapus sejak NDK r17.
Masalah yang mengalami regresi
Apa yang dimaksud dengan masalah yang mengalami regresi?
Sebuah masalah mengalami regresi saat sebelumnya Anda telah menutupnya, tetapi Crashlytics mendapatkan laporan baru bahwa masalah tersebut muncul kembali. Crashlytics otomatis akan membuka kembali masalah yang mengalami regresi ini agar Anda dapat mengatasinya sebagaimana mestinya untuk aplikasi Anda.
Berikut contoh skenario yang menjelaskan cara Crashlytics mengategorikan masalah sebagai regresi:
- Untuk pertama kalinya, Crashlytics mendapatkan laporan error terkait Error "A". Crashlytics akan membuka masalah terkait untuk error tersebut (Masalah "A").
- Anda dapat memperbaiki bug ini dengan cepat, menutup Masalah "A", lalu merilis versi baru aplikasi.
- Crashlytics akan menerima laporan lain tentang Masalah "A" setelah Anda menutup masalah.
- Jika laporan berasal dari versi aplikasi yang diketahui Crashlytics saat Anda menutup masalah (artinya versi tersebut telah mengirimkan laporan error untuk error apa pun), Crashlytics tidak akan menganggap masalah tersebut sebagai regresi. Masalah akan tetap ditutup.
- Jika laporan berasal dari versi aplikasi yang tidak diketahui Crashlytics saat Anda menutup masalah (artinya versi sama sekali tidak pernah mengirim laporan error untuk error apa pun), Crashlytics akan menganggap masalah mengalami regresi dan akan membuka kembali masalah tersebut.
Saat masalah mengalami regresi, kami mengirimkan pemberitahuan deteksi regresi dan menambahkan sinyal regresi ke masalah tersebut untuk memberi tahu Anda bahwa Crashlytics telah membuka kembali masalah ini. Jika Anda tidak ingin masalah dibuka kembali karena algoritma regresi kami, "nonaktifkan" masalah, bukan menutupnya.
Mengapa saya melihat masalah yang mengalami regresi untuk versi aplikasi yang lebih lama?
Jika laporan berasal dari versi aplikasi lama yang belum pernah mengirim laporan error apa pun saat Anda menutup masalah, maka Crashlytics akan mempertimbangkan masalah yang mengalami regresi dan 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, kebetulan, salah satu versi lama tersebut tidak pernah mengirim laporan error sama sekali saat Anda menutup masalah, dan pengguna tersebut mulai menemukan bug, maka laporan error tersebut akan memicu masalah yang mengalami regresi.
Jika Anda tidak ingin masalah dibuka kembali karena algoritma regresi kami, "nonaktifkan" masalah, bukan menutupnya.