Apa Saja yang Mungkin Termuat dalam Laporan Kerusakan Aplikasi Buku Harian?
Laporan kerusakan (crash report) aplikasi buku harian dapat mencakup rincian teknis seperti crash stack trace, versi perangkat dan aplikasi, stempel waktu, serta peristiwa diagnostik di sekitarnya. Bergantung pada sistem operasi, layanan pelaporan, dan konfigurasi aplikasi, laporan tersebut mungkin juga menyertakan log, lampiran, atau data pemutaran ulang sesi (session replay) yang mengekspos konten yang dimasukkan atau ditampilkan dalam aplikasi. Suatu laporan tidak selalu secara otomatis memuat entri buku harian dalam setiap kasus, namun tidak aman juga untuk menganggap bahwa laporan tersebut tidak akan pernah memuatnya. Periksa laporan spesifik tersebut dan bagaimana aplikasi dikonfigurasi sebelum membagikannya.
Apa yang ditampilkan dalam laporan kerusakan standar?
Stack trace mencantumkan panggilan fungsi yang terkait dengan kerusakan tersebut. Ini membantu pengembang menemukan jalur kode yang terlibat, namun biasanya tidak dengan sendirinya menjelaskan keadaan lengkap atau membuktikan apa yang sedang dilakukan pengguna. Laporan juga dapat mengidentifikasi versi aplikasi dan sistem operasi, model perangkat, waktu kerusakan, serta rincian lingkungan lainnya. Apple menjelaskan laporan kerusakan sebagai catatan status aplikasi pada saat terjadi kerusakan dan merekomendasikan untuk menganalisis laporan sistem operasi yang lengkap; panduannya mengidentifikasi bidang-bidang seperti informasi perangkat, aplikasi, dan OS. Lihat [panduan analisis laporan kerusakan](https://developer.apple.com/documentation/xcode/analyzing-a-crash-report) dari Apple.
Format laporan bergantung pada sumbernya. Laporan kerusakan Apple yang dikumpulkan melalui Xcode dan laporan bug Android adalah artefak yang berbeda. Panduan resmi Android menyatakan bahwa laporan bug dapat berisi log perangkat, stack trace, output diagnostik dari layanan sistem, log kesalahan, dan pesan sistem dari aplikasi yang menggunakan kelas `Log` Android. Cakupan tersebut lebih luas daripada rekaman kerusakan saja. Konten dari suatu laporan individual tetap bergantung pada apa yang dikumpulkan dan disertakan. Lihat [panduan Android untuk merekam dan membaca laporan bug](https://developer.android.com/studio/debug/bug-report).
Bisakah laporan tersebut menyertakan teks buku harian?
Laporan bisa saja menyertakannya di bawah beberapa konfigurasi tertentu, tetapi keberadaan laporan kerusakan saja tidak serta-merta membuktikan bahwa laporan tersebut memuat teks entri. Pertanyaan kuncinya adalah apa yang dicatat aplikasi bersamaan dengan kerusakan tersebut dan apa yang ditangkap oleh format laporan.
Sebagai contoh, pengembang aplikasi dapat menambahkan pesan log diagnostik atau peristiwa kustom. Jika pesan-pesan tersebut menyertakan entri buku harian, judul, istilah pencarian, atau teks yang disalin dari editor, informasi tersebut dapat ikut terkirim bersama peristiwa tersebut. Sentry mendeskripsikan breadcrumbs sebagai jejak peristiwa sebelum terjadinya masalah; masing-masing dapat memiliki pesan dan data terstruktur arbitrer. Breadcrumbs dapat dikumpulkan secara otomatis melalui integrasi yang diaktifkan atau ditambahkan oleh aplikasi. Lihat [dokumentasi breadcrumb Sentry](https://docs.sentry.io/product/issues/issue-details/breadcrumbs/). Laporan bug Android juga mencakup log pesan sistem, yang mungkin berisi pesan yang ditulis oleh aplikasi. Kedua fakta tersebut tidak berarti bahwa setiap aplikasi mencatat teks pribadi: hal itu bergantung pada implementasi dan konfigurasi aplikasi.
Apa itu log, breadcrumbs, lampiran, dan replay?
Istilah-istilah ini mengacu pada jenis data diagnostik yang berbeda. Log adalah pesan yang direkam oleh aplikasi atau sistem. Breadcrumbs adalah urutan peristiwa terpilih menjelang terjadinya kesalahan, yang berpotensi mencakup stempel waktu, kategori, pesan, dan data nilai kunci (key-value). Keduanya dapat mengungkap lebih banyak konteks daripada sekadar stack trace, bergantung pada apa yang dicatat oleh aplikasi.
Lampiran adalah berkas yang dikirim bersama suatu peristiwa, seperti berkas log, tangkapan layar, atau crash dump. Sentry mencatat bahwa minidump bawaan (native) dapat berisi materi sensitif seperti variabel lingkungan, jalur lokal, atau representasi kolom input di dalam memori. Dokumentasinya menyebutkan bahwa minidump digunakan untuk membuat peristiwa dan dibuang secara default, tetapi dapat disimpan sebagai lampiran jika pengaturan tersebut diaktifkan; dokumentasi itu juga menyatakan bahwa lampiran tidak dicakup oleh pembersihan data (data scrubbing) Sentry. Lihat dokumentasi Sentry tentang [data kerusakan](https://docs.sentry.io/platforms/native/guides/crashpad/data-management/data-collected/) dan [lampiran](https://docs.sentry.io/platforms/native/guides/crashpad/enriching-events/attachments/).
Pemutaran ulang sesi (session replay) adalah fitur terpisah yang bersifat opsional, bukan komponen standar dari setiap laporan kerusakan. Dokumentasi JavaScript replay Sentry mendeskripsikan rekonstruksi aktivitas peramban yang menyerupai video, termasuk status DOM dan interaksi. Disebutkan bahwa SDK menyamarkan teks DOM, gambar, dan input pengguna secara default, sembari tetap menawarkan opsi konfigurasi. Pengaturan penyamaran dan platform yang didukung sangatlah berpengaruh: jangan berasumsi bahwa konten buku harian terlihat atau terlindungi tanpa memeriksa pengaturan penyedia dan konfigurasi privasi yang sebenarnya. Lihat [panduan JavaScript Session Replay Sentry](https://docs.sentry.io/platforms/javascript/session-replay/).
Apa yang harus Anda tinjau sebelum membagikan laporan?
Gunakan daftar periksa ini pada berkas atau pratinjau laporan yang sebenarnya, dan periksa dokumentasi privasi aplikasi atau penyedia jika isi laporan tidak jelas:
Daftar periksa ini merupakan panduan editorial praktis bagi pengguna buku harian yang memeriksa laporan sebelum mengirimkannya. Panduan ini terpisah dari instruksi pembuat aplikasi: pengembang mengontrol pengaturan pencatatan log, pemutaran ulang, dan lampiran mereka sendiri, serta harus mendokumentasikan apa yang dikumpulkan oleh fitur-fitur tersebut dan meninjau apakah bidang diagnostik dapat berisi konten yang dimasukkan pengguna.
Mengapa laporan dapat berbeda antaraplikasi dan antarperangkat?
Sistem operasi menghasilkan format laporan dan jalur pengumpulan yang berbeda; pengembang juga dapat menggunakan SDK pihak ketiga dengan konfigurasi kustom. Apple menyatakan bahwa laporan kerusakan App Store dan TestFlight tersedia melalui Xcode, sementara log diagnostik lainnya mungkin perlu ditransfer langsung dari perangkat. Android membedakan laporan bug lengkap dari laporan kerusakan yang disediakan melalui layanan seperti Google Play atau Firebase. Pengaturan penyedia layanan lebih lanjut dapat menentukan peristiwa, breadcrumbs, lampiran, atau data pemutaran ulang mana yang ditangkap dan disimpan. Jadikan pemberitahuan privasi aplikasi dan laporan yang sebenarnya sebagai panduan untuk kasus tertentu, alih-alih berasumsi bahwa setiap layanan mengirimkan bidang data yang sama.