Pemecahan masalah dan FAQ Crashlytics

Melihat format yang berbeda (dan terkadang "varian") untuk beberapa masalah dalam tabel Issues

Anda mungkin melihat dua format berbeda untuk masalah yang tercantum dalam tabel Issues di Firebase console. Anda mungkin juga melihat fitur yang disebut "varian" dalam beberapa masalah. Berikut adalah alasannya.

Pada awal 2023, kami meluncurkan mesin analisis yang telah ditingkatkan untuk mengelompokkan peristiwa serta desain yang diperbarui dan beberapa fitur lanjutan untuk masalah baru (seperti varian). Lihat postingan blog terbaru kami untuk semua detailnya, tetapi Anda dapat membaca penjelasannya di bawah.

Crashlytics menganalisis semua peristiwa dari aplikasi Anda (seperti error, non-fatal, dan ANR) dan membuat kelompok peristiwa yang disebut masalah — semua peristiwa dalam masalah memiliki titik kegagalan yang sama.

Untuk mengelompokkan peristiwa ke dalam masalah ini, mesin analisis yang telah ditingkatkan kini melihat banyak aspek peristiwa, termasuk frame dalam stack trace, pesan pengecualian, kode error, dan karakteristik platform atau jenis error lainnya.

Namun, dalam kelompok peristiwa ini, stack trace yang mengarah ke kegagalan mungkin berbeda. Stack trace yang berbeda dapat berarti penyebab utama yang berbeda. Untuk merepresentasikan kemungkinan perbedaan ini dalam masalah, kami sekarang membuat varian dalam masalah - setiap varian adalah subgrup peristiwa dalam masalah yang memiliki titik kegagalan yang sama dan stack trace yang serupa. Dengan varian, Anda dapat men-debug stack trace yang paling umum dalam suatu masalah dan menentukan apakah penyebab utama yang berbeda menyebabkan kegagalan tersebut.

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.

• Proses debug yang lebih mudah untuk masalah yang kompleks dengan penyebab utama berbeda
  Gunakan varian untuk men-debug stack trace yang paling umum dalam suatu masalah.

• 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.

Tidak melihat log breadcrumb

Jika Anda tidak melihat log breadcrumb (iOS+ | Android | Flutter | Unity), sebaiknya periksa konfigurasi aplikasi Anda untuk Google Analytics. Pastikan Anda memenuhi persyaratan berikut:

• Anda telah mengaktifkan Google Analytics di project Firebase Anda.

• Anda telah mengaktifkan Berbagi data untuk Google Analytics. Pelajari setelan ini lebih lanjut di artikel Mengelola setelan berbagi data Analytics

• Anda telah menambahkan Firebase SDK untuk Google Analytics ke aplikasi: iOS+ | Android | Flutter | Unity.
  Selain Crashlytics SDK, Firebase SDK harus ditambahkan.

• Anda menggunakan versi Firebase SDK terbaru untuk semua produk yang Anda gunakan di aplikasi Anda (iOS+ | Android | Flutter | Unity).

  Terutama untuk aplikasi Android dan platform Apple, pastikan Anda menggunakan setidaknya versi Firebase SDK berikut untuk Google Analytics: iOS+ — v6.3.1+ (v8.9.0+ untuk macOS dan tvOS) | Android — v17.2.3+ (BoM v24.7.1+).

Tidak melihat notifikasi kecepatan

Jika Anda tidak melihat notifikasi kecepatan, pastikan Anda menggunakan

Tidak melihat metrik bebas error (atau melihat metrik yang tidak dapat diandalkan)

Jika Anda tidak melihat metrik bebas error (seperti pengguna dan sesi bebas error) atau melihat metrik yang tidak dapat diandalkan, periksa hal berikut:

• Pastikan Anda menggunakan

• Pastikan setelan pengumpulan data Anda tidak memengaruhi kualitas metrik bebas error:

  • Jika Anda mengaktifkan pelaporan keikutsertaan dengan menonaktifkan pelaporan error otomatis, informasi error hanya dapat dikirim ke Crashlytics dari pengguna yang secara eksplisit memilih ikut serta dalam pengumpulan data. Dengan demikian, akurasi metrik bebas error akan terpengaruh karena Crashlytics hanya memiliki informasi error dari pengguna yang ikut serta (bukan semua pengguna Anda). Artinya, metrik bebas error Anda mungkin kurang andal dan kurang mencerminkan stabilitas aplikasi secara keseluruhan.

  • Jika pengumpulan data otomatis dinonaktifkan, Anda dapat menggunakan sendUnsentReports untuk mengirim laporan yang di-cache di perangkat ke Crashlytics. Penggunaan metode ini akan mengirim data error ke Crashlytics, tetapi tidak mengirim data sesi yang menyebabkan diagram konsol menampilkan nilai rendah atau nol untuk metrik bebas error.

Bagaimana cara penghitungan pengguna bebas error?

Lihat bagian Memahami metrik bebas 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

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:

1. Untuk pertama kalinya, Crashlytics mendapatkan laporan error terkait Error "A". Crashlytics akan membuka masalah terkait untuk error tersebut (Masalah "A").
2. Anda dapat memperbaiki bug ini dengan cepat, menutup Masalah "A", lalu merilis versi baru aplikasi.
3. 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, jangan tutup masalah, cukup "nonaktifkan" saja.

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.

Hal 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, laporan error tersebut akan memicu masalah yang mengalami regresi.

Jika Anda tidak ingin masalah dibuka kembali karena algoritma regresi kami, jangan tutup masalah, cukup "nonaktifkan" saja.

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 akan otomatis berlokasi di Amerika Serikat, terlepas dari lokasi project Firebase Anda.

dSYM tidak ada/tidak diupload

Untuk mengupload dSYM project Anda dan mendapatkan output panjang, periksa hal-hal berikut:

1. Pastikan fase build project Anda berisi skrip eksekusi Crashlytics, yang memungkinkan Xcode mengupload dSYM project Anda saat waktu build (baca Menginisialisasi Crashlytics untuk mendapatkan petunjuk tentang cara menambahkan skrip). Setelah memperbarui project, paksa kemunculan error dan pastikan error tersebut muncul di dasbor Crashlytics.

2. Jika Anda melihat pemberitahuan "Missing dSYM" di Firebase console, periksa Xcode guna memastikannya membuat dSYM dengan benar untuk build terkait.

3. Jika Xcode menghasilkan dSYM dengan benar namun dSYM masih tidak ada, kemungkinan alat eksekusi skrip macet saat mengupload dSYM. Dalam kasus ini, coba setiap hal berikut:

   • Pastikan Anda menggunakan Crashlytics versi terbaru.

   • Upload file dSYM yang tidak ada secara manual:

     • Opsi 1: Gunakan opsi "Tarik lalu Lepas" berbasis konsol di tab dSYMs untuk mengupload file zip yang berisi file dSYM yang tidak ada.
     • Opsi 2: Gunakan skrip upload-symbols untuk mengupload file dSYM yang tidak ada, untuk UUID yang disediakan di tab dSYMs.

4. Jika Anda terus melihat bahwa dSYM tidak ada, atau upload masih gagal, hubungi Dukungan Firebase dan pastikan untuk menyertakan log Anda.

Error tidak disimbolkan dengan baik

Jika pelacakan tumpukan tampaknya tidak disimbolkan dengan baik, periksa hal-hal berikut:

• Jika frame dari library aplikasi Anda tidak memiliki referensi ke kode aplikasi, pastikan -fomit-frame-pointer tidak ditetapkan sebagai flag kompilasi.

• Jika Anda melihat beberapa frame (Missing) untuk library aplikasi Anda, periksa apakah ada dSYM opsional yang tercantum sebagai tidak ada (untuk versi aplikasi yang terpengaruh) di tab dSYMs Crashlytics di Firebase console. Jika ya, ikuti langkah pemecahan masalah "Pemberitahuan dSYM yang tidak ada" di FAQ terkait dSYM tidak ada/tidak diupload di halaman ini. Perlu diperhatikan bahwa mengupload dSYM ini tidak akan menyimbolkan error yang sudah terjadi, tetapi tindakan ini akan membantu memastikan simbolisasi untuk error mendatang.

Dapatkah saya menggunakan Crashlytics untuk macOS atau tvOS?

Ya, Anda dapat menerapkan Crashlytics dalam project macOS dan tvOS. Pastikan untuk menyertakan v8.9.0+ dari Firebase SDK untuk Google Analytics, sehingga error akan memiliki akses ke metrik yang dikumpulkan oleh Google Analytics (pengguna bebas error, rilis terbaru, pemberitahuan kecepatan, dan log breadcrumb).

Dapatkah saya menggunakan Crashlytics dalam project Firebase dengan beberapa aplikasi di berbagai platform Apple?

Kini Anda dapat melaporkan error untuk beberapa aplikasi dalam satu project Firebase, bahkan ketika aplikasi dibangun untuk platform Apple yang berbeda-beda (misalnya, iOS, tvOS, dan Mac Catalyst). Sebelumnya, setiap aplikasi harus memiliki project Firebase masing-masing jika berisi ID paket yang sama.

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

Mengapa beberapa ANR tidak memiliki BuildId?

Jika beberapa ANR Anda tidak memiliki BuildId, pecahkan masalah sebagai berikut:

• Pastikan Anda menggunakan Android SDK Crashlytics dan versi plugin Gradle Crashlytics yang terbaru.

  Jika BuildId untuk Android 11 dan beberapa ANR Android 12 tidak ada, mungkin Anda menggunakan SDK, plugin Gradle, atau keduanya yang sudah usang. Agar dapat mengumpulkan BuildId untuk ANR ini dengan benar, Anda harus menggunakan versi berikut:

  • Crashlytics Android SDK v18.3.5+ (Firebase BoM v31.2.2+)
  • Plugin Gradle Crashlytics v2.9.4+

• Periksa apakah Anda menggunakan lokasi non-standar untuk library bersama.

  Jika hanya BuildId yang hilang untuk library bersama aplikasi Anda, kemungkinan Anda tidak menggunakan lokasi default standar untuk library bersama. Jika ini yang terjadi, Crashlytics mungkin tidak dapat menemukan BuildId terkait. Sebaiknya pertimbangkan untuk menggunakan lokasi standar untuk library bersama.

• Pastikan Anda tidak menghapus BuildId selama proses build.

  Perhatikan bahwa tips pemecahan masalah berikut berlaku untuk ANR dan masalah pada native code.

  • Periksa apakah BuildId ada dengan menjalankan readelf -n pada biner Anda. Jika BuildId tidak ada, tambahkan -Wl,--build-id ke flag untuk sistem build Anda.

  • Pastikan Anda tidak menghapus BuildId secara tidak sengaja sebagai upaya untuk mengurangi ukuran APK.

  • Jika Anda mempertahankan versi library yang telah dihapus dan dihapus garisnya, pastikan untuk mengarah ke versi yang benar dalam kode Anda.

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.

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.

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:

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

2. 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

Perbedaan antara stack trace 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 lld dari toolchain LLVM, tambahkan:

  -Wl,--no-rosegment

• Jika menggunakan penaut ld.gold dari 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 program biner generator file simbol Breakpad saya sendiri untuk NDK?

Plugin Crashlytics menyertakan generator file simbol Breakpad yang disesuaikan. Jika lebih suka menggunakan program 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 program biner generator file simbol Breakpad dengan salah satu dari dua cara berikut:

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

  Tambahkan blok berikut ini ke file build.gradle.kts level aplikasi Anda:

  Plugin Gradle v3.0.0+

  android {
    buildTypes {
      release {
        configure<CrashlyticsExtension> {
          nativeSymbolUploadEnabled = true
          // Add these optional fields to specify the path to the executable
          symbolGeneratorType = "breakpad"
          breakpadBinary = file("/PATH/TO/BREAKPAD/DUMP_SYMS")
        }
      }
    }
  }

  versi plugin yang lebih rendah

  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.breakpadBinary untuk 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.breakpadBinary=/PATH/TO/BREAKPAD/DUMP_SYMS \
    app:assembleRelease app:uploadCrashlyticsSymbolFileRelease
  

Apakah Crashlytics mendukung armeabi?

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

Melihat stack trace yang tidak disimbolkan untuk aplikasi Android di dasbor Crashlytics

Jika Anda menggunakan IL2CPP Unity dan melihat stack trace yang tidak tersimbolisasi, coba lakukan hal berikut:

1. Pastikan Anda menggunakan Crashlytics Unity SDK v8.6.1 atau versi yang lebih tinggi.

2. Pastikan Anda sudah siap dan menjalankan perintah crashlytics:symbols:upload Firebase CLI untuk membuat dan mengupload file simbol.

   Anda harus menjalankan perintah CLI ini setiap kali membuat build rilis atau build apa pun yang ingin Anda lihat pelacakan tumpukan tersimbolisasinya di Firebase console. Pelajari lebih lanjut di Mendapatkan laporan error yang dapat dibaca.

Dapatkah Crashlytics digunakan dengan aplikasi yang menggunakan IL2CPP?

Ya, Crashlytics dapat menampilkan pelacakan tumpukan tersimbolisasi untuk aplikasi Anda yang menggunakan IL2CPP. Kemampuan ini tersedia untuk aplikasi yang dirilis di platform Apple atau Android. Berikut ini hal yang perlu Anda lakukan:

1. Pastikan Anda menggunakan Crashlytics Unity SDK v8.6.0 atau versi yang lebih tinggi.

2. Selesaikan tugas yang diperlukan untuk platform Anda:

   • Untuk aplikasi platform Apple: Anda tidak perlu melakukan tindakan khusus. Untuk aplikasi platform Apple, plugin Firebase Unity Editor otomatis mengonfigurasi project Xcode untuk mengupload simbol.

   • Untuk aplikasi Android: Pastikan Anda sudah siap dan menjalankan perintah crashlytics:symbols:upload Firebase CLI untuk membuat dan mengupload file simbol.

     Anda harus menjalankan perintah CLI ini setiap kali membuat build rilis atau build apa pun yang ingin Anda lihat pelacakan tumpukan tersimbolisasinya di Firebase console. Pelajari lebih lanjut di Mendapatkan laporan error yang dapat dibaca.

Mengapa aplikasi harus melaporkan pengecualian yang tidak tertangkap sebagai fatal?

Dengan melaporkan pengecualian yang tidak tertangkap sebagai fatal, Anda mendapatkan indikasi yang lebih realistis tentang pengecualian yang dapat menyebabkan game tidak dapat dimainkan, meskipun aplikasi terus berjalan.

Perhatikan bahwa jika Anda mulai melaporkan fatal, persentase pengguna bebas error (CFU) kemungkinan akan menurun, tetapi metrik CFU akan lebih mewakili pengalaman pengguna akhir dengan aplikasi Anda.

Pengecualian mana yang akan dilaporkan sebagai fatal?

Agar Crashlytics dapat melaporkan pengecualian yang tidak tertangkap sebagai fatal, kedua kondisi berikut harus terpenuhi:

• Selama inisialisasi di aplikasi Anda, properti ReportUncaughtExceptionsAsFatal harus ditetapkan ke true.

• Aplikasi Anda (atau library yang disertakan) menampilkan pengecualian yang tidak tertangkap. Pengecualian yang dibuat, tetapi tidak ditampilkan, tidak dianggap tidak tertangkap.

Setelah mengaktifkan pelaporan pengecualian yang tidak tertangkap sebagai fatal, sekarang saya memiliki banyak item fatal baru. Bagaimana cara menangani pengecualian ini dengan benar?

Jika Anda mulai mendapatkan laporan pengecualian yang tidak tertangkap sebagai fatal, berikut adalah beberapa opsi untuk menangani pengecualian yang tidak tertangkap ini:

• Pertimbangkan cara untuk mulai menangkap dan menangani pengecualian yang tidak tertangkap ini.
• Pertimbangkan berbagai opsi untuk mencatat pengecualian ke dalam log di konsol debug Unity dan di Crashlytics.

Menangkap dan menangani pengecualian yang ditampilkan

Pengecualian dibuat dan ditampilkan untuk menunjukkan status yang tidak terduga atau luar biasa. Untuk menyelesaikan masalah yang ditunjukkan dari pengecualian yang ditampilkan, Anda harus mengembalikan program ke status yang diketahui (proses ini disebut penanganan pengecualian).

Praktik terbaiknya adalah menangkap dan menangani semua pengecualian yang diperkirakan kecuali jika program tidak dapat dikembalikan ke status yang diketahui.

Untuk mengontrol jenis pengecualian yang ditangkap dan ditangani dengan suatu kode, gabungkan kode yang mungkin menghasilkan pengecualian dalam blok try-catch. Pastikan kondisi dalam pernyataan catch sudah sespesifik mungkin untuk menangani pengecualian spesifik dengan tepat.

Mencatat pengecualian ke dalam log di Unity atau Crashlytics

Ada beberapa cara untuk mencatat pengecualian ke dalam log di Unity atau Crashlytics untuk membantu men-debug masalah.

Saat menggunakan Crashlytics, berikut ini adalah dua opsi yang paling umum dan direkomendasikan:

• Opsi 1: Cetak di konsol Unity, tetapi jangan laporkan ke Crashlytics, selama pengembangan atau pemecahan masalah

  • Cetak di konsol Unity menggunakan Debug.Log(exception), Debug.LogWarning(exception), dan Debug.LogError(exception) yang mencetak konten pengecualian di konsol Unity dan tidak menampilkan ulang pengecualian.

• Opsi 2: Upload ke Crashlytics untuk pelaporan gabungan di dasbor Crashlytics untuk situasi berikut:

  • Jika ada pengecualian yang patut dicatat ke dalam log untuk men-debug kemungkinan peristiwa Crashlytics berikutnya, gunakan Crashlytics.Log(exception.ToString()).
  • Jika pengecualian tetap harus dilaporkan ke Crashlytics meskipun ditangkap dan ditangani, gunakan Crashlytics.LogException(exception) untuk mencatatnya ke dalam log sebagai peristiwa nonfatal.

Namun, jika ingin melaporkan peristiwa fatal ke Unity Cloud Diagnostik secara manual, Anda dapat menggunakan Debug.LogException. Opsi ini akan mencetak pengecualian di konsol Unity seperti Opsi 1, tetapi juga menampilkan pengecualian (terlepas dari apakah telah ditampilkan atau belum ditangkap). Error ini akan ditampilkan secara nonlokal. Ini berarti bahwa bahkan Debug.LogException(exception) di sekitarnya dengan blok try-catch tetap menghasilkan pengecualian yang tidak tertangkap.

Oleh karena itu, panggil Debug.LogException jika dan hanya jika Anda ingin melakukan semua hal berikut:

• Untuk mencetak pengecualian di konsol Unity.
• Untuk mengupload pengecualian ke Crashlytics sebagai peristiwa fatal.
• Untuk menampilkan pengecualian, biarkan pengecualian tersebut diperlakukan sebagai pengecualian yang tidak tertangkap, dan laporkan ke Diagnostik Unity Cloud.

Perhatikan bahwa jika Anda ingin mencetak pengecualian yang tertangkap di konsol Unity dan mengupload ke Crashlytics sebagai peristiwa nonfatal, lakukan hal berikut:

try
{
    methodThatThrowsMyCustomExceptionType();
}
catch(MyCustomExceptionType exception)
{
    // Print the exception to the Unity console at the error level.
    Debug.LogError(exception);
    // Upload the exception to Crashlytics as a non-fatal event.
    Crashlytics.LogException(exception); // not Debug.LogException
    //
    // Code that handles the exception
    //
}