Baca laporan bug

{i>Bug<i} adalah kenyataan dalam semua jenis pengembangan—dan laporan {i>bug<i} sangat penting untuk mengidentifikasi dan memecahkan masalah. Semua versi dukungan Android mengambil laporan bug dengan Android Debug Bridge (adb); Android versi 4.2 dan yang lebih baru mendukung Pengembang Opsi untuk mengambil laporan bug dan membagikannya melalui email, Drive, dll.

Laporan bug Android berisi dumpsys, dumpstate, dan Data logcat dalam format teks (.txt), memungkinkan Anda dengan mudah mencari untuk konten tertentu. Bagian berikut menjelaskan komponen laporan {i>bug<i}, jelaskan masalah umum, serta berikan tips dan perintah grep yang bermanfaat untuk menemukan log yang terkait dengan {i>bug<i} tersebut. Sebagian besar bagian menyertakan contoh untuk perintah grep dan output dan/atau output dumpsys.

Logcat

Log logcat adalah dump berbasis string dari semua logcat tidak akurat atau tidak sesuai. Bagian sistem dicadangkan untuk framework dan memiliki histori yang lebih panjang daripada main yang berisi semua hal lain. Setiap baris biasanya diawali dengan timestamp UID PID TID log-level, meskipun UID mungkin tidak tercantum dalam versi Android yang lebih lama.

Melihat log aktivitas

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

Level log meliputi:

  • V: panjang
  • D: {i>debug<i}
  • I: informasi
  • W: peringatan
  • E: {i>error<i}

 

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

ANR dan deadlock

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

Mengidentifikasi aplikasi yang tidak responsif

Ketika aplikasi tidak merespons dalam waktu tertentu, biasanya karena thread utama yang diblokir atau sibuk, sistem menghentikan proses dan membuang {i>stack<i} ke /data/anr. Untuk menemukan penyebab di balik ANR, {i>grep<i} untuk am_anr dalam 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.

Menemukan stack trace

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

  • Thread utama hanya memberi tahu Anda apa yang dilakukan thread pada saat ANR, yang mungkin sesuai atau tidak sesuai dengan penyebab sebenarnya dari ANR. (Tumpukan di laporan {i>bug<i} mungkin tidak bersalah; sesuatu yang lain mungkin telah macet untuk waktu yang lama waktu—tapi tidak cukup lama untuk ANR—sebelum menjadi tidak macet.)
  • Lebih dari satu kumpulan stack trace (VM TRACES JUST NOW dan VM TRACES AT LAST ANR) mungkin ada. Pastikan Anda melihat bagian yang benar.

Menemukan deadlock

Deadlock sering kali muncul sebagai ANR karena thread bermasalah. Jika {i>deadlock<i} menyerang server sistem, {i> watchdog<i} akhirnya akan mematikannya, yang mengarah ke entri dalam log yang mirip dengan: WATCHDOG KILLING SYSTEM PROCESS. Dari sudut pandang pengguna, memulai ulang perangkat, meskipun secara teknis ini adalah {i>restart<i} runtime, bukan {i>reboot<i} yang sebenarnya.

  • Saat runtime dimulai ulang, server sistem akan mati dan dimulai ulang; pengguna melihat perangkat kembali ke animasi {i>boot<i}.
  • Saat memulai ulang, kernel mengalami error; pengguna melihat perangkat kembali ke logo booting Google.

Untuk menemukan deadlock, periksa pola thread A di bagian rekaman aktivitas VM menunggu sesuatu yang dipegang oleh utas B, yang pada gilirannya sedang menunggu sesuatu yang dipegang oleh utas 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 bug perspektif laporan, aktivitas adalah satu hal yang terfokus yang dapat dilakukan pengguna, yang membuat lokasi aktivitas sangat penting saat terjadi tabrakan. Aktivitas (melalui ActivityManager) menjalankan proses, sehingga menemukan semua proses berhenti dan dimulai untuk aktivitas tertentu bisa membantu memecahkan masalah.

Lihat aktivitas yang difokuskan

Untuk melihat histori aktivitas terfokus, telusuri am_focused_activity.

Lihat proses dimulai

Untuk melihat histori proses dimulai, telusuri Start proc.

Menentukan apakah perangkat melakukan 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 memiliki memori fisik yang terbatas, {i>random-access memory<i} (RAM) adalah memori yang sangat penting. Laporan bug berisi beberapa indikator memori rendah serta dumpstate yang memberikan snapshot memori.

Mengidentifikasi memori rendah

Kekurangan memori dapat menyebabkan sistem memusnahkan hal itu mematikan beberapa proses untuk membebaskan memori tetapi tetap memulai proses yang lain. Untuk melihat bukti pendukung dari memori rendah, periksa konsentrasi am_proc_died dan am_proc_start entri dalam log aktivitas biner.

Rendahnya memori juga dapat memperlambat pengalihan tugas dan menggagalkan upaya pengembalian (karena tugas yang hendak dikembalikan pengguna telah dimatikan). Jika peluncur sebelumnya dimatikan, komputer akan dimulai ulang ketika pengguna menyentuh tombol {i>home<i} dan log menampilkan peluncur akan memuat ulang kontennya.

Lihat indikator historis

Entri am_low_memory dalam log aktivitas biner menunjukkan proses {i>cache<i} terakhir telah dihentikan. Setelah ini, sistem mulai mengakhiri layanan.

Lihat indikator thrashing

Indikator lain dari thrashing sistem (paging, perolehan langsung, dll.) termasuk kswapd, kworker, dan mmcqd menggunakan siklus hidupnya. (Perlu diingat bahwa laporan bug yang dikumpulkan dapat memengaruhi thrashing indikator.)

Log ANR dapat memberikan snapshot memori yang serupa.

Dapatkan snapshot memori

Snapshot memori adalah dumpstate yang berisi daftar yang menjalankan Java dan native proses (untuk detailnya, lihat Melihat Alokasi Memori Keseluruhan). Perlu diingat bahwa snapshot hanya memberikan status pada waktu tertentu; sistem mungkin lebih baik (atau lebih buruk) sebelum {i>snapshot <i}itu.

Siaran

Aplikasi menghasilkan siaran untuk mengirim peristiwa dalam aplikasi atau ke aplikasi lain. Penerima siaran berlangganan ke pesan (melalui filter), sehingga memungkinkan mereka mendengarkan dan merespons siaran. Laporan bug berisi informasi tentang siaran yang dikirim dan siaran yang tidak terkirim, sebagai serta {i>dumpsys<i} dari semua penerima yang mendengarkan siaran tertentu.

Melihat siaran historis

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

Bagian ringkasan adalah ringkasan dari 300 bagian terakhir siaran latar depan 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:

  • BroadcastFilter entri didaftarkan pada runtime dan dikirim hanya untuk proses yang sudah berjalan.
  • Entri ResolveInfo didaftarkan melalui entri manifes. Tujuan ActivityManager memulai proses untuk setiap ResolveInfo jika belum berjalan.

Melihat siaran aktif

Siaran aktif adalah siaran yang belum dikirim. Terdapat angka yang besar di antrean berarti sistem tidak bisa mengirim siaran dengan cepat untuk mengikutinya.

Melihat pemroses siaran

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

Memantau pertentangan

Pencatatan log pertentangan monitor terkadang dapat menunjukkan pertentangan monitor yang sebenarnya, tetapi yang paling sering mengindikasikan bahwa sistem dimuat sehingga semuanya melambat. Anda mungkin melihat peristiwa pemantauan yang lama dicatat 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 bisa menjadi mahal dan memuat perangkat.

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

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

Narasi

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

Linimasa sinkronisasi

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

Stempel waktu log sistem dan aktivitas berada dalam zona waktu yang sama dengan pengguna (seperti sebagian besar adalah stempel waktu lainnya). Misalnya, ketika pengguna mengetuk tombol {i>home<i}, laporan log sistem:

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, dengan memberi tag pada item log dalam hitungan detik sejak {i>bootloader<i} selesai. Untuk mendaftarkan skala waktu ini ke skala waktu, menelusuri pesan penangguhan keluar, dan menangguhkan entri:

<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 {i>kernel<i} mungkin tidak menyertakan waktu saat ditangguhkan, Anda harus bitwise mendaftarkan log antara entri dan pesan keluar yang ditangguhkan. Selain itu, log kernel menggunakan zona waktu UTC dan harus disesuaikan dengan pengguna zona waktu.

Mengidentifikasi waktu laporan bug

Untuk menentukan kapan laporan bug diambil, periksa log sistem (Logcat) terlebih dahulu 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'...

Upayakan mundur untuk menghubungkan kedua peristiwa tersebut, dengan memperhatikan catatannya yang disebutkan dalam Linimasa sinkronisasi. Meskipun ada banyak terjadi setelah laporan {i>bug<i} dimulai, sebagian besar aktivitas tidak terlalu berguna seperti tindakan mengambil laporan {i>bug<i} akan memuat sistem secara substansial.

Daya

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

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

Statistik durasi penguncian layar saat aktif gabungan hanya melacak waktu penguncian layar saat aktif sebenarnya bertanggung jawab untuk menjaga perangkat tetap aktif dan jangan sertakan waktu dengan layar aktif. Selain itu, jika beberapa penguncian layar saat aktif ditahan secara bersamaan, waktu durasi penguncian layar saat aktif adalah yang 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 laporan bug Android .

Paket

Bagian DUMP OF SERVICE package berisi versi aplikasi (dan berbagai kegunaan tertentu).

Proses

Laporan {i>bug<i} berisi sejumlah besar data untuk proses, termasuk data memulai dan waktu perhentian, durasi runtime, layanan terkait, skor oom_adj, dll. Untuk detail tentang cara Android mengelola proses, lihat Proses dan Threads.

Menentukan runtime proses

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

Alasan proses sedang berjalan

Bagian dumpsys activity processes mencantumkan semua yang saat ini proses yang sedang berjalan yang diurutkan berdasarkan skor oom_adj (Android menunjukkan tingkat kepentingan proses dengan menetapkan nilai oom_adj untuk proses, dapat diperbarui secara dinamis oleh ActivityManager). Outputnya mirip dengan snapshot memori informasi tentang apa yang menyebabkan proses berjalan. Dalam contoh di bawah ini, entri yang dicetak tebal menunjukkan proses gms.persistent sedang berjalan pada prioritas vis (terlihat) karena proses sistem terikat ke NetworkLocationService-nya.

Pemindaian

Gunakan langkah-langkah berikut untuk mengidentifikasi aplikasi yang berperforma Pemindaian Bluetooth Hemat Energi (BLE):

  • Menemukan 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 di pesan log. Dalam contoh ini, "24840" dan "24.851" 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 pihak yang bertanggung jawab aplikasi: 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 prosesnya. Untuk mengetahui detailnya, lihat Energi Rendah (LE) dan pemindaian Bluetooth.