Membaca laporan bug

Bug adalah hal yang wajar dalam jenis pengembangan apa pun—dan laporan bug sangat penting untuk mengidentifikasi dan menyelesaikan masalah. Semua versi Android mendukung pembuatan laporan bug dengan Android Debug Bridge (adb); Android versi 4.2 dan yang lebih tinggi mendukung Opsi Developer untuk mengambil laporan bug dan membagikannya melalui email, Drive, dll.

Laporan bug Android berisi data dumpsys, dumpstate, dan logcat dalam format teks (.txt), sehingga Anda dapat menelusuri konten tertentu dengan mudah. Bagian berikut menjelaskan komponen laporan bug, menjelaskan masalah umum, dan memberikan tips bermanfaat serta perintah grep untuk menemukan log yang terkait dengan bug tersebut. Sebagian besar bagian juga menyertakan contoh untuk perintah dan output grep dan/atau output dumpsys.

Logcat

Log logcat adalah dump berbasis string dari semua informasi logcat. Bagian system dicadangkan untuk framework dan memiliki histori yang lebih panjang daripada main yang berisi semua hal lainnya. Setiap baris biasanya dimulai dengan timestamp UID PID TID log-level, meskipun UID mungkin tidak tercantum di Android versi lama.

Melihat log aktivitas

Log ini berisi representasi string dari pesan log berformat biner. Log ini kurang berisik daripada log logcat, tetapi juga sedikit lebih sulit dibaca. Saat melihat log peristiwa, Anda dapat menelusuri bagian ini untuk menemukan ID proses (PID) tertentu untuk melihat tindakan yang telah dilakukan proses. Format dasarnya adalah: timestamp PID TID log-level log-tag tag-values.

Level log mencakup:

  • V: panjang
  • D: debug
  • I: informasi
  • W: peringatan
  • E: error

 

Untuk tag log peristiwa lainnya yang berguna, lihat /services/core/java/com/android/server/EventLogTags.logtags.

ANR dan deadlock

Bugreport dapat membantu Anda mengidentifikasi penyebab error Aplikasi Tidak Merespons (ANR) dan peristiwa deadlock.

Mengidentifikasi aplikasi yang tidak responsif

Jika aplikasi tidak merespons dalam waktu tertentu, biasanya karena thread utama yang diblokir atau sibuk, sistem akan menghentikan proses dan membuang stack ke /data/anr. Untuk menemukan pelaku di balik ANR, grep untuk am_anr dalam log peristiwa biner.

Anda juga dapat menggunakan grep untuk mencari ANR in dalam log logcat, yang berisi informasi selengkapnya tentang apa yang menggunakan CPU pada saat ANR.

Menemukan stack trace

Anda sering kali dapat menemukan pelacakan tumpukan yang sesuai dengan ANR. Pastikan stempel waktu dan PID pada rekaman aktivitas VM cocok dengan ANR yang Anda selidiki, lalu periksa thread utama proses. Perhatikan:

  • Thread utama hanya memberi tahu Anda apa yang dilakukan thread pada saat ANR, yang mungkin atau mungkin tidak sesuai dengan penyebab sebenarnya dari ANR. (Stack dalam laporan bug mungkin tidak bersalah; ada hal lain yang mungkin macet selama waktu yang lama—tetapi tidak cukup lama untuk ANR—sebelum berhenti macet.)
  • Mungkin ada lebih dari satu set pelacakan tumpukan (VM TRACES JUST NOW dan VM TRACES AT LAST ANR). Pastikan Anda melihat bagian yang benar.

Menemukan deadlock

Deadlock sering kali muncul pertama kali sebagai ANR karena thread macet. Jika deadlock terjadi di server sistem, watchdog pada akhirnya akan menghentikannya, sehingga menyebabkan entri dalam log yang mirip dengan: WATCHDOG KILLING SYSTEM PROCESS. Dari perspektif pengguna, perangkat dimulai ulang, meskipun secara teknis ini adalah mulai ulang runtime, bukan mulai ulang yang sebenarnya.

  • Saat memulai ulang runtime, server sistem akan mati dan dimulai ulang; pengguna akan melihat perangkat kembali ke animasi booting.
  • Dalam reboot, kernel telah error; pengguna melihat perangkat kembali ke logo booting Google.

Untuk menemukan deadlock, periksa bagian rekaman aktivitas VM untuk menemukan pola thread A yang menunggu sesuatu yang dipegang oleh thread B, yang pada gilirannya menunggu sesuatu yang dipegang oleh thread A.

Aktivitas

Aktivitas adalah komponen aplikasi yang menyediakan layar yang berinteraksi dengan pengguna untuk melakukan sesuatu seperti menghubungi nomor, mengambil foto, mengirim email, dll. Dari perspektif laporan bug, aktivitas adalah satu hal yang terfokus yang dapat dilakukan pengguna, sehingga menemukan aktivitas yang difokuskan selama error sangatlah penting. Aktivitas (melalui ActivityManager) menjalankan proses, sehingga menemukan semua proses yang berhenti dan dimulai untuk aktivitas tertentu juga dapat membantu pemecahan masalah.

Melihat aktivitas yang difokuskan

Untuk melihat histori aktivitas yang difokuskan, telusuri am_focused_activity.

Proses tampilan dimulai

Untuk melihat histori awal proses, telusuri Start proc.

Menentukan apakah perangkat mengalami thrashing

Untuk menentukan apakah perangkat thrashing, periksa peningkatan aktivitas yang tidak normal di sekitar am_proc_died dan am_proc_start dalam waktu singkat.

Memori

Karena perangkat Android sering kali memiliki memori fisik yang terbatas, pengelolaan random access memory (RAM) sangat penting. Laporan bug berisi beberapa indikator memori rendah serta dumpstate yang memberikan snapshot memori.

Mengidentifikasi memori rendah

Memori yang rendah dapat menyebabkan sistem mengalami thrashing karena menghentikan beberapa proses untuk membebaskan memori, tetapi terus memulai proses lain. Untuk melihat bukti pendukung memori rendah, periksa konsentrasi entri am_proc_died dan am_proc_start dalam log peristiwa biner.

Memori yang rendah juga dapat memperlambat pengalihan tugas dan menggagalkan upaya kembali (karena tugas yang ingin dikembalikan pengguna telah dihentikan). Jika dihentikan, peluncur akan dimulai ulang saat pengguna menyentuh tombol layar utama dan log menunjukkan peluncur memuat ulang kontennya.

Melihat indikator historis

Entri am_low_memory dalam log peristiwa biner menunjukkan proses terakhir yang di-cache telah berhenti. Setelah itu, sistem akan mulai menghentikan layanan.

Melihat indikator thrashing

Indikator lain dari thrashing sistem (paging, pengambil alihan langsung, dll.) mencakup siklus konsumsi kswapd, kworker, dan mmcqd. (Perlu diingat bahwa bugreport yang dikumpulkan dapat memengaruhi indikator thrashing.)

Log ANR dapat memberikan snapshot memori yang serupa.

Mendapatkan snapshot memori

Snapshot memori adalah dumpstate yang mencantumkan proses Java dan native yang sedang berjalan (untuk mengetahui detailnya, lihat Melihat Alokasi Memori Secara Keseluruhan). Perlu diingat bahwa snapshot hanya memberikan status pada waktu tertentu; sistem mungkin dalam kondisi yang lebih baik (atau lebih buruk) sebelum snapshot.

Siaran

Aplikasi menghasilkan siaran untuk mengirim peristiwa dalam aplikasi saat ini atau ke aplikasi lain. Penerima siaran berlangganan pesan tertentu (melalui filter), sehingga mereka dapat memproses dan merespons siaran. Laporan bug berisi informasi tentang siaran yang dikirim dan siaran yang tidak dikirim, serta dumpsys dari semua penerima yang memproses siaran tertentu.

Melihat siaran historis

Siaran historis adalah siaran yang telah dikirim, yang tercantum dalam urutan kronologis terbalik.

Bagian ringkasan adalah ringkasan dari 300 siaran latar depan terakhir dan 300 siaran latar belakang terakhir.

Bagian detail berisi informasi lengkap untuk 50 siaran latar depan terakhir dan 50 siaran latar belakang terakhir, serta penerima untuk setiap siaran. Penerima yang memiliki:

  • Entri BroadcastFilter didaftarkan saat runtime dan hanya dikirim ke proses yang sudah berjalan.
  • Entri ResolveInfo terdaftar melalui entri manifes. ActivityManager akan memulai proses untuk setiap ResolveInfo jika belum berjalan.

Melihat siaran aktif

Siaran aktif adalah siaran yang belum dikirim. Jumlah yang besar dalam antrean berarti sistem tidak dapat mengirim siaran dengan cukup cepat untuk mengimbangi.

Melihat pemroses siaran

Untuk melihat daftar penerima yang memproses siaran, periksa Tabel Pemecah Masalah Penerima di dumpsys activity broadcasts. Contoh berikut menampilkan semua penerima yang memproses USER_PRESENT.

Memantau pertentangan

Logging pertentangan monitor terkadang dapat menunjukkan pertentangan monitor yang sebenarnya, tetapi paling sering menunjukkan bahwa sistem sangat berat sehingga semuanya melambat. Anda mungkin melihat peristiwa pemantauan panjang yang dicatat ke dalam log oleh ART di log sistem atau peristiwa.

Di log sistem:

10-01 18:12:44.343 29761 29914 W art     : Long monitor contention event with owner method=void android.database.sqlite.SQLiteClosable.acquireReference() from SQLiteClosable.java:52 waiters=0 for 3.914s

Di log aktivitas:

10-01 18:12:44.364 29761 29914 I dvm_lock_sample: [com.google.android.youtube,0,pool-3-thread-9,3914,ScheduledTaskMaster.java,138,SQLiteClosable.java,52,100]

Kompilasi latar belakang

Kompilasi dapat mahal dan memuat perangkat.

Kompilasi mungkin terjadi di latar belakang saat update Google Play Store didownload. Dalam hal ini, pesan dari aplikasi Google Play Store (finsky) dan installd akan muncul sebelum pesan dex2oat.

Kompilasi juga dapat terjadi di latar belakang saat aplikasi memuat file dex yang belum dikompilasi. Dalam hal ini, Anda tidak akan melihat logging finsky atau installd.

Narasi

Menetapkan narasi masalah (bagaimana masalah dimulai, apa yang terjadi, bagaimana sistem bereaksi) memerlukan linimasa peristiwa yang solid. Anda dapat menggunakan informasi dalam laporan bug untuk menyinkronkan linimasa di beberapa log dan menentukan stempel waktu yang tepat dari laporan bug.

Menyinkronkan linimasa

Bugreport mencerminkan beberapa linimasa paralel: log sistem, log peristiwa, log kernel, dan beberapa linimasa khusus untuk siaran, statistik baterai, dll. Sayangnya, linimasa sering dilaporkan menggunakan dasar waktu yang berbeda.

Stempel waktu sistem dan log peristiwa berada di zona waktu yang sama dengan pengguna (seperti sebagian besar stempel waktu lainnya). Misalnya, saat pengguna mengetuk tombol layar utama, log sistem akan melaporkan:

10-03 17:19:52.939  1963  2071 I ActivityManager: START u0 {act=android.intent.action.MAIN cat=[android.intent.category.HOME] flg=0x10200000 cmp=com.google.android.googlequicksearchbox/com.google.android.launcher.GEL (has extras)} from uid 1000 on display 0

Untuk tindakan yang sama, log peristiwa melaporkan:

10-03 17:19:54.279  1963  2071 I am_focused_activity: [0,com.google.android.googlequicksearchbox/com.google.android.launcher.GEL]

Log kernel (dmesg) menggunakan dasar waktu yang berbeda, yang memberi tag pada item log dengan detik sejak bootloader selesai. Untuk mendaftarkan rentang waktu ini ke rentang waktu lain, telusuri pesan suspend exit dan suspend entry:

<6>[201640.779997] PM: suspend exit 2015-10-03 19:11:06.646094058 UTC
…
<6>[201644.854315] PM: suspend entry 2015-10-03 19:11:10.720416452 UTC

Karena log kernel mungkin tidak menyertakan waktu saat dalam mode penangguhan, Anda harus mendaftarkan log secara terpisah antara pesan entri dan keluar penangguhan. Selain itu, log kernel menggunakan zona waktu UTC dan harus disesuaikan dengan zona waktu pengguna.

Mengidentifikasi waktu bugreport

Untuk menentukan kapan laporan bug diambil, periksa log sistem (Logcat) untuk dumpstate: begin terlebih dahulu:

10-03 17:19:54.322 19398 19398 I dumpstate: begin

Selanjutnya, periksa stempel waktu log kernel (dmesg) untuk pesan Starting service 'bugreport':

<5>[207064.285315] init: Starting service 'bugreport'...

Lakukan secara terbalik untuk mengaitkan kedua peristiwa tersebut, dengan mempertimbangkan pengecualian yang disebutkan dalam Menyinkronkan linimasa. Meskipun ada banyak hal yang terjadi setelah laporan bug dimulai, sebagian besar aktivitas tidak terlalu berguna karena tindakan mengambil laporan bug memuat sistem secara substansial.

Daya

Log peristiwa berisi status daya layar, dengan 0 adalah layar nonaktif, 1 adalah layar aktif, dan 2 adalah untuk kunci layar selesai.

Laporan bug juga berisi statistik tentang wake lock, mekanisme yang digunakan oleh developer aplikasi untuk menunjukkan bahwa aplikasi mereka perlu membuat perangkat tetap aktif. (Untuk mengetahui detail tentang kunci layar saat aktif, lihat PowerManager.WakeLock dan Membuat CPU tetap aktif.)

Statistik durasi penguncian layar saat aktif gabungan hanya melacak waktu penguncian layar saat aktif yang benar-benar bertanggung jawab untuk menjaga perangkat tetap aktif dan tidak menyertakan waktu saat layar aktif. Selain itu, jika beberapa penguncian layar saat aktif ditahan secara bersamaan, waktu durasi penguncian layar saat aktif akan didistribusikan di seluruh penguncian layar saat aktif tersebut.

Untuk bantuan lebih lanjut dalam memvisualisasikan status daya, gunakan Battery Historian, alat open source Google untuk menganalisis pengguna baterai menggunakan file bugreport Android.

Paket

Bagian DUMP OF SERVICE package berisi versi aplikasi (dan info berguna lainnya).

Proses

Laporan bug berisi data dalam jumlah besar untuk proses, termasuk waktu mulai dan berhenti, durasi runtime, layanan terkait, skor oom_adj, dll. Untuk mengetahui detail tentang cara Android mengelola proses, lihat Proses dan Thread.

Menentukan runtime proses

Bagian procstats berisi statistik lengkap tentang berapa lama proses dan layanan terkait telah berjalan. Untuk ringkasan cepat yang dapat dibaca manusia, telusuri AGGREGATED OVER untuk melihat data dari tiga atau 24 jam terakhir, lalu telusuri Summary: untuk melihat daftar proses, berapa lama proses tersebut berjalan dengan berbagai prioritas, dan penggunaan RAM-nya yang diformat sebagai PSS min-rata-maks/USS min-rata-maks.

Alasan proses berjalan

Bagian dumpsys activity processes mencantumkan semua proses yang sedang berjalan yang diurutkan berdasarkan skor oom_adj (Android menunjukkan pentingnya proses dengan menetapkan nilai oom_adj ke proses, yang dapat diperbarui secara dinamis oleh ActivityManager). Outputnya mirip dengan snapshot memori, tetapi menyertakan informasi tambahan tentang penyebab proses berjalan. Pada contoh di bawah, entri yang dicetak tebal menunjukkan proses gms.persistent berjalan dengan prioritas vis (terlihat) karena proses sistem terikat dengan NetworkLocationService-nya.

Pemindaian

Gunakan langkah-langkah berikut untuk mengidentifikasi aplikasi yang melakukan pemindaian Bluetooth Hemat Energi (BLE) yang berlebihan:

  • Temukan pesan log untuk BluetoothLeScanner: 
    $ grep 'BluetoothLeScanner' ~/downloads/bugreport.txt
07-28 15:55:19.090 24840 24851 D BluetoothLeScanner: onClientRegistered() - status=0 clientIf=5
  • Temukan PID dalam pesan log. Dalam contoh ini, "24840" dan "24851" adalah PID (ID proses) dan TID (ID thread).
  • Temukan aplikasi yang terkait dengan PID: 
    PID #24840: ProcessRecord{4fe996a 24840:com.badapp/u0a105}

    Dalam contoh ini, nama paketnya adalah com.badapp.

  • Cari nama paket di Google Play untuk mengidentifikasi aplikasi yang bertanggung jawab: https://play.google.com/store/apps/details?id=com.badapp.

Catatan: Untuk perangkat yang menjalankan Android 7.0, sistem mengumpulkan data untuk pemindaian BLE dan mengaitkan aktivitas ini dengan aplikasi yang memulai. Untuk mengetahui detailnya, lihat Pemindaian Bluetooth dan Hemat Energi (LE).