Pemecahan masalah Crashlytics dan FAQ

Tidak melihat pengguna bebas error, log remah roti, dan/atau peringatan kecepatan

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+) .

Mengapa ANR hanya dilaporkan untuk Android 11+?

Crashlytics mendukung pelaporan ANR untuk aplikasi Android dari perangkat yang menjalankan Android 11 dan yang lebih tinggi. API dasar yang kami gunakan untuk mengumpulkan ANR ( getHistoricalProcessExitReasons ) lebih andal daripada pendekatan berbasis SIGQUIT atau pengawas. API ini hanya tersedia di perangkat Android 11+.

Perbedaan antara laporan ANR di dasbor Crashlytics dan Konsol Google Play

Mungkin ada ketidakcocokan antara jumlah ANR antara Google Play dan Crashlytics. Hal ini diduga karena adanya perbedaan mekanisme pengumpulan dan pelaporan data ANR. Crashlytics melaporkan ANR saat aplikasi berikutnya dimulai, sedangkan Android Vitals mengirimkan data ANR setelah ANR terjadi.

Selain itu, Crashlytics hanya menampilkan ANR yang terjadi pada perangkat yang menjalankan Android 11+, dibandingkan dengan Google Play yang menampilkan ANR dari perangkat dengan layanan Google Play dan persetujuan pengumpulan data diterima.

Perbedaan antara pelacakan tumpukan NDK di dasbor Crashlytics dan logcat

Toolchain LLVM dan GNU memiliki default dan perlakuan yang berbeda untuk segmen hanya-baca dari biner aplikasi Anda, yang dapat menghasilkan pelacakan tumpukan yang tidak konsisten di Firebase console. Untuk menguranginya, tambahkan flag linker berikut ke proses build Anda:

• Jika Anda menggunakan lld linker dari LLVM toolchain, tambahkan:

  -Wl,--no-rosegment
  

• Jika Anda menggunakan ld.gold linker dari toolchain GNU, tambahkan:

  -Wl,--rosegment
  

Jika Anda masih melihat inkonsistensi pelacakan tumpukan (atau jika tidak ada tanda yang terkait dengan rantai alat Anda), coba tambahkan yang berikut ini ke proses pembangunan Anda:

-fno-omit-frame-pointer

Bagaimana cara menggunakan biner pembuat file simbol Breakpad saya sendiri untuk NDK?

Plugin Crashlytics menggabungkan generator file simbol Breakpad yang disesuaikan . Jika Anda lebih suka menggunakan biner Anda sendiri untuk menghasilkan file simbol Breakpad (misalnya, jika Anda lebih suka membangun semua executable asli dalam rantai build Anda dari sumber), gunakan properti ekstensi symbolGeneratorBinary opsional untuk menentukan jalur ke executable.

Anda dapat menentukan jalur ke biner pembuat file simbol Breakpad dengan salah satu dari dua cara:

• Opsi 1 : Tentukan jalur melalui ekstensi firebaseCrashlytics di file build.gradle Anda

  Tambahkan yang berikut ini ke file build.gradle tingkat 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 : Tentukan jalur melalui baris properti di file properti Gradle Anda

  Anda dapat menggunakan properti com.google.firebase.crashlytics.symbolGeneratorBinary untuk menentukan jalur ke file yang dapat dieksekusi.

  Anda dapat memperbarui file properti Gradle secara manual atau memperbarui file melalui baris perintah. Misalnya, untuk menentukan jalur melalui baris perintah, 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 mengalami crash dengan Dexguard

Jika Anda 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 membuat aplikasi Anda mogok, tetapi mencegahnya mengirim laporan kerusakan. Untuk memperbaiki ini:

1. Pastikan Anda menggunakan rilis DexGuard 8.x terbaru. Versi terbaru berisi aturan yang diperlukan oleh Firebase Crashlytics SDK.

2. Jika Anda tidak ingin mengubah versi DexGuard Anda, coba tambahkan baris berikut ke aturan obfuscation Anda (dalam file konfigurasi DexGuard Anda):

   -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 menghasilkan setiap masalah dengan ekstensi file .java secara default.

Agar Crashlytics dapat menghasilkan masalah dengan ekstensi file yang benar, pastikan aplikasi Anda menggunakan penyiapan berikut:

• Menggunakan Android Gradle 4.2.0 atau lebih tinggi
• Menggunakan R8 dengan kebingungan dihidupkan. Untuk memperbarui aplikasi Anda ke R8, ikuti dokumentasi ini .

Perhatikan bahwa setelah memperbarui ke penyiapan yang dijelaskan di atas, Anda mungkin mulai melihat masalah .kt baru yang merupakan duplikat dari masalah .java yang ada. Lihat FAQ untuk mempelajari lebih lanjut tentang keadaan itu.

Mengapa saya melihat masalah .kt yang merupakan duplikat dari masalah .java yang ada?

Mulai pertengahan Desember 2021, Crashlytics meningkatkan dukungan untuk aplikasi yang menggunakan Kotlin.

Sampai saat ini, obfuscator yang tersedia tidak mengekspos ekstensi file, jadi Crashlytics membuat setiap masalah dengan ekstensi file .java secara default. Namun, pada Android Gradle 4.2.0, R8 mendukung ekstensi file.

Dengan pembaruan ini, Crashlytics sekarang dapat menentukan apakah setiap kelas yang digunakan dalam aplikasi ditulis di Kotlin dan menyertakan nama file yang benar dalam tanda tangan masalah. Error sekarang diatribusikan dengan benar ke file .kt (sebagaimana sesuai) jika aplikasi Anda memiliki penyiapan berikut:

• Aplikasi Anda menggunakan Android Gradle 4.2.0 atau lebih tinggi.
• Aplikasi Anda menggunakan R8 dengan obfuscation diaktifkan.

Karena kerusakan baru sekarang menyertakan ekstensi file yang benar dalam tanda tangan masalah mereka, Anda mungkin melihat masalah .kt baru yang sebenarnya hanya duplikat dari masalah berlabel .java yang ada. Di Firebase console, kami mencoba mengidentifikasi dan berkomunikasi dengan Anda jika masalah .kt baru kemungkinan merupakan duplikat dari masalah berlabel .java yang ada.

Bagaimana cara menghitung pengguna bebas error?

Nilai bebas error menunjukkan persentase pengguna yang berinteraksi dengan aplikasi Anda tetapi tidak mengalami error selama jangka waktu tertentu. Anda memilih jangka waktu ini dari menu tarik-turun 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; kami akan menyebutnya Pengguna A, Pengguna B, dan Pengguna C. Tabel berikut menunjukkan pengguna mana yang terlibat dengan aplikasi Anda setiap hari dan pengguna mana yang mengalami error pada hari itu:

• 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 terlibat dengan aplikasi Anda selama tiga hari terakhir, tetapi tidak ada dari mereka yang tidak mengalami error.

Jika diperlukan, berikut adalah input dan formula khusus untuk penghitungan persentase pengguna bebas error:

1 - ( IMPACTED_USERS / ALL_USERS )

Tempat IMPACTED_USERS dan ALL_USERS dikumpulkan oleh Google Analytics dan tersedia melalui dasbor Analytics.

Aplikasi juga menggunakan SDK Iklan Seluler Google tetapi tidak mogok

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 .

Di mana set data BigQuery saya berada?

Setelah Anda menautkan Crashlytics ke BigQuery, set data baru yang Anda buat akan otomatis berada di Amerika Serikat, terlepas dari lokasi project Firebase Anda.

Apakah Crashlytics mendukung armeabi?

Firebase Crashlytics NDK tidak mendukung ARMv5 (armeabi). Dukungan untuk ABI ini telah dihapus pada NDK r17.

Apa itu masalah kemunduran?

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:

1. Untuk pertama kalinya, Crashlytics mendapatkan laporan kerusakan tentang Kerusakan "A". Crashlytics membuka masalah terkait untuk kerusakan tersebut (Masalah "A").
2. Anda memperbaiki bug ini dengan cepat, tutup Masalah "A", lalu rilis versi baru aplikasi Anda.
3. 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.

Mengapa saya melihat masalah kemunduran untuk versi aplikasi yang lebih lama?

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.