Membaca laporan bug

Bug adalah hal yang wajar dalam setiap jenis pengembangan—dan laporan bug sangat penting untuk mengidentifikasi dan menyelesaikan masalah. Semua versi Android mendukung pengambilan 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 dengan mudah menelusuri konten tertentu. Bagian berikut menjelaskan komponen laporan bug, menguraikan 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 peristiwa

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

Tingkat log mencakup:

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

 

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

ANR dan kebuntuan

Laporan bug dapat membantu Anda mengidentifikasi penyebab error Aplikasi Tidak Merespons (ANR) dan peristiwa kebuntuan.

Mengidentifikasi aplikasi yang tidak responsif

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

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

Menemukan stack trace

Anda sering kali dapat menemukan stack trace yang sesuai dengan ANR. Pastikan stempel waktu dan PID pada rekaman aktivitas VM cocok dengan ANR yang sedang 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; sesuatu yang lain mungkin telah macet dalam waktu yang lama—tetapi tidak cukup lama untuk menyebabkan ANR—sebelum tidak macet.)
  • Mungkin ada lebih dari satu set rekaman aktivitas stack (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 kebuntuan mencapai server sistem, watchdog akan menghentikannya, sehingga menyebabkan entri dalam log yang mirip dengan: WATCHDOG KILLING SYSTEM PROCESS. Dari perspektif pengguna, perangkat akan dimulai ulang, meskipun secara teknis ini adalah mulai ulang runtime, bukan mulai ulang yang sebenarnya.

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

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

Aktivitas

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

Melihat aktivitas yang difokuskan

Untuk melihat histori aktivitas yang difokuskan, telusuri am_focused_activity.

Melihat proses dimulai

Untuk melihat histori mulai proses, telusuri Start proc.

Menentukan apakah perangkat mengalami thrashing

Untuk menentukan apakah perangkat mengalami 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 rendah dapat menyebabkan sistem berlebihan saat menghentikan beberapa proses untuk membebaskan memori, tetapi terus memulai proses lain. Untuk melihat bukti pendukung terkait memori rendah, periksa konsentrasi entri am_proc_died dan am_proc_start dalam log peristiwa biner.

Memori yang rendah juga dapat memperlambat peralihan tugas dan menggagalkan upaya kembali (karena tugas yang coba diakses pengguna telah dihentikan). Jika peluncur dihentikan, peluncur akan dimulai ulang saat pengguna menyentuh tombol beranda dan log menunjukkan bahwa peluncur memuat ulang kontennya.

Melihat indikator historis

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

Melihat indikator thrashing

Indikator lain dari thrashing sistem (paging, direct reclaim, dll.) mencakup kswapd, kworker, dan mmcqd yang menggunakan siklus. (Perlu diingat bahwa laporan bug yang dikumpulkan dapat memengaruhi indikator thrashing.)

Log ANR dapat memberikan snapshot memori serupa.

Mendapatkan cuplikan memori

Snapshot memori adalah dumpstate yang mencantumkan proses Java dan native yang sedang berjalan (untuk mengetahui detailnya, lihat Melihat Alokasi Memori 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 membuat 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 semua penerima yang memproses siaran tertentu.

Melihat siaran historis

Siaran historis adalah siaran yang telah dikirim, yang dicantumkan 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 dikirim hanya ke proses yang sudah berjalan.
  • Entri ResolveInfo didaftarkan melalui entri manifes. ActivityManager 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 mengirimkan siaran dengan cukup cepat untuk mengimbangi.

Melihat pemroses siaran

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

Memantau pertentangan

Pencatatan persaingan monitor terkadang dapat menunjukkan persaingan monitor yang sebenarnya, tetapi paling sering menunjukkan bahwa sistem sangat terbebani sehingga semuanya menjadi lambat. Anda mungkin melihat peristiwa pemantauan panjang yang dicatat oleh ART dalam 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 peristiwa:

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 memakan biaya besar dan membebani perangkat.

Kompilasi dapat terjadi di latar belakang saat update Google Play Store sedang didownload. Dalam hal ini, pesan dari aplikasi Google Play Store (finsky) dan installd 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 pencatatan finsky atau installd.

Narasi

Menetapkan narasi masalah (bagaimana masalah dimulai, apa yang terjadi, bagaimana reaksi sistem) 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

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

Stempel waktu log peristiwa dan sistem berada di zona waktu yang sama dengan pengguna (seperti kebanyakan stempel waktu lainnya). Misalnya, saat pengguna mengetuk tombol layar utama, log sistem 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 basis waktu yang berbeda, menandai item log dengan detik sejak bootloader selesai. Untuk mendaftarkan skala waktu ini ke skala 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 ditangguhkan, Anda harus mendaftarkan log secara bertahap antara pesan masuk dan keluar dari mode ditangguhkan. Selain itu, log kernel menggunakan zona waktu UTC dan harus disesuaikan dengan zona waktu pengguna.

Mengidentifikasi waktu laporan bug

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

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 analisis mundur untuk mengorelasikan kedua peristiwa tersebut, dengan mengingat peringatan yang disebutkan dalam Menyinkronkan linimasa. Meskipun banyak hal yang terjadi setelah laporan bug dimulai, sebagian besar aktivitas tidak terlalu berguna karena tindakan pengambilan 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 keyguard selesai.

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

Statistik durasi penguncian layar saat aktif yang digabungkan hanya melacak waktu saat penguncian layar saat aktif 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, durasi waktu penguncian layar saat aktif akan didistribusikan di seluruh penguncian layar saat aktif tersebut.

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

Paket

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

Proses

Laporan bug berisi sejumlah besar data 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 durasi proses dan layanan terkait telah berjalan. Untuk ringkasan cepat yang mudah dibaca, telusuri AGGREGATED OVER untuk melihat data dari tiga atau 24 jam terakhir, lalu telusuri Summary: untuk melihat daftar proses, durasi proses tersebut berjalan pada berbagai prioritas, dan penggunaan RAM-nya yang diformat sebagai PSS min-rata-rata-maks/USS min-rata-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 output snapshot memori, tetapi menyertakan informasi tambahan tentang penyebab proses berjalan. Dalam contoh di bawah, entri yang dicetak tebal menunjukkan bahwa proses gms.persistent berjalan pada prioritas vis (terlihat) karena proses sistem terikat ke NetworkLocationService-nya.

Pemindaian

Gunakan langkah-langkah berikut untuk mengidentifikasi aplikasi yang melakukan pemindaian Bluetooth Low Energy (BLE) 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).