Membaca Laporan Bug

Bug adalah kenyataan dalam semua jenis pengembangan—dan laporan bug sangat penting untuk mengidentifikasi dan memecahkan masalah. Semua versi dukungan Android menangkap laporan bug dengan Android Debug Bridge (adb) ; Android versi 4.2 dan lebih tinggi mendukung Opsi Pengembang untuk mengambil laporan bug dan berbagi melalui email, Drive, dll.

Laporan bug Android berisi dumpsys , dumpstate , dan logcat dalam format teks (.txt), memungkinkan Anda mencari konten tertentu dengan mudah. Bagian berikut merinci komponen laporan bug, menjelaskan masalah umum, dan memberikan tip bermanfaat dan perintah grep untuk menemukan log yang terkait dengan bug tersebut. Sebagian besar bagian juga menyertakan contoh untuk perintah dan keluaran grep dan/atau keluaran dumpsys .

Logcat

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

Melihat log peristiwa

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

Level log meliputi:

  • V: bertele-tele
  • D: debug
  • saya: informasi
  • W: peringatan
  • E: kesalahan

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

ANR dan kebuntuan

Laporan bug dapat membantu Anda mengidentifikasi apa yang menyebabkan kesalahan Aplikasi Tidak Merespons (ANR) dan peristiwa kebuntuan.

Mengidentifikasi aplikasi yang tidak responsif

Ketika aplikasi tidak merespons dalam waktu tertentu, biasanya karena utas utama yang diblokir atau sibuk, sistem mematikan proses dan membuang tumpukan ke /data/anr . Untuk menemukan penyebab di balik ANR, am_anr di log peristiwa biner.

Anda juga dapat menerima ANR in log logcat , yang berisi lebih banyak informasi tentang apa yang menggunakan CPU pada saat ANR.

Menemukan jejak tumpukan

Anda sering dapat menemukan pelacakan tumpukan yang sesuai dengan ANR. Pastikan stempel waktu dan PID pada pelacakan VM cocok dengan ANR yang Anda selidiki, lalu periksa utas utama proses tersebut. Mengingat:

  • Utas utama hanya memberi tahu Anda apa yang dilakukan utas pada saat ANR, yang mungkin atau mungkin tidak sesuai dengan penyebab sebenarnya dari ANR. (Tumpukan dalam laporan bug mungkin tidak bermasalah; sesuatu yang lain mungkin telah macet untuk waktu yang lama—tetapi tidak cukup lama untuk ANR—sebelum menjadi macet.)
  • Lebih dari satu kumpulan pelacakan tumpukan ( VM TRACES JUST NOW dan VM TRACES AT LAST ANR ) mungkin ada. Pastikan Anda melihat bagian yang benar.

Menemukan kebuntuan

Kebuntuan sering kali pertama kali muncul sebagai ANR karena utas macet. Jika kebuntuan mengenai server sistem, pengawas pada akhirnya akan mematikannya, yang mengarah ke entri di log yang mirip dengan: WATCHDOG KILLING SYSTEM PROCESS . Dari sudut pandang pengguna, perangkat melakukan reboot, meskipun secara teknis ini adalah runtime restart daripada reboot yang sebenarnya.

  • Dalam runtime restart, server sistem mati dan dimulai ulang; pengguna melihat perangkat kembali ke animasi boot.
  • Dalam reboot , kernel mogok; pengguna melihat perangkat kembali ke logo boot Google.

Untuk menemukan kebuntuan, periksa bagian pelacakan VM untuk pola utas A yang menunggu sesuatu yang dipegang oleh utas B, yang pada gilirannya sedang menunggu sesuatu yang dipegang oleh utas A.

Kegiatan

Aktivitas adalah komponen aplikasi yang menyediakan layar yang berinteraksi dengan pengguna untuk melakukan sesuatu seperti memutar nomor, mengambil foto, mengirim email, dll. Dari perspektif laporan bug, aktivitas adalah satu hal yang terfokus yang dapat dilakukan pengguna , yang menjadikan lokasi aktivitas yang menjadi fokus selama crash menjadi sangat penting. Aktivitas (melalui ActivityManager) menjalankan proses, jadi menemukan semua proses berhenti dan mulai untuk aktivitas tertentu juga dapat membantu pemecahan masalah.

Melihat aktivitas terfokus

Untuk melihat riwayat aktivitas yang difokuskan, telusuri am_focused_activity .

Proses melihat dimulai

Untuk melihat riwayat proses dimulai, cari Start proc .

Apakah perangkat meronta-ronta?

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

Penyimpanan

Karena perangkat Android sering memiliki memori fisik yang terbatas, mengelola memori akses acak (RAM) sangat penting. Laporan bug berisi beberapa indikator memori rendah serta dumpstate yang menyediakan snapshot memori.

Mengidentifikasi memori rendah

Memori rendah dapat menyebabkan sistem mogok karena mematikan beberapa proses untuk mengosongkan memori tetapi terus memulai proses lainnya. Untuk melihat bukti yang menguatkan tentang memori rendah, periksa konsentrasi entri am_proc_died dan am_proc_start di log peristiwa biner.

Memori rendah juga dapat memperlambat peralihan tugas dan menggagalkan upaya pengembalian (karena tugas yang coba dikembalikan oleh pengguna terbunuh). Jika peluncur dimatikan, peluncur akan dimulai ulang saat pengguna menyentuh tombol beranda dan log menunjukkan peluncur memuat ulang kontennya.

Melihat indikator historis

Entri am_low_memory di log peristiwa biner menunjukkan proses cache terakhir telah mati. Setelah ini, sistem mulai mematikan layanan.

Melihat indikator meronta-ronta

Indikator lain dari penghancuran sistem (paging, pengambilan langsung, dll.) termasuk siklus konsumsi kswapd , kworker , dan mmcqd . (Perlu diingat bahwa laporan bug yang dikumpulkan dapat memengaruhi indikator yang meronta-ronta.)

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 detailnya, lihat Melihat Alokasi Memori Keseluruhan ). Ingatlah bahwa snapshot hanya memberikan status pada saat tertentu; sistem mungkin dalam kondisi yang lebih baik (atau lebih buruk) sebelum snapshot.

Siaran

Aplikasi menghasilkan siaran untuk mengirim acara dalam aplikasi saat ini atau ke aplikasi lain. Penerima siaran berlangganan pesan tertentu (melalui filter), memungkinkan mereka untuk mendengarkan dan menanggapi siaran. Laporan bug berisi informasi tentang siaran terkirim dan siaran yang tidak terkirim, serta dumpsys dari semua penerima yang mendengarkan siaran tertentu.

Melihat siaran sejarah

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

Bagian ringkasan adalah ikhtisar 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 terdaftar 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 antrian berarti sistem tidak dapat mengirimkan siaran dengan cukup cepat untuk mengikutinya.

Melihat pendengar siaran

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

Pantau pertengkaran

Pencatatan perebutan monitor terkadang dapat menunjukkan pertikaian monitor yang sebenarnya, tetapi paling sering menunjukkan bahwa sistem dimuat sedemikian rupa sehingga semuanya melambat. Anda mungkin melihat peristiwa monitor panjang yang dicatat oleh ART di sistem atau log peristiwa.

Dalam catatan 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

Dalam catatan 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 bisa mahal dan memuat perangkat.

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

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

Cerita

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

Menyinkronkan garis waktu

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

Stempel waktu sistem dan log peristiwa berada di zona waktu yang sama dengan pengguna (seperti kebanyakan stempel waktu lainnya). Misalnya, ketika pengguna mengetuk tombol beranda, 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, cari pesan tunda keluar dan tunda masuk :

<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 penangguhan, Anda harus mendaftarkan log secara bertahap di antara pesan masuk dan keluar yang 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, pertama-tama periksa 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 'laporan Starting service 'bugreport' :

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

Bekerja mundur untuk menghubungkan dua peristiwa, dengan mengingat peringatan yang disebutkan dalam Menyinkronkan garis waktu . 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.

Kekuatan

Log peristiwa berisi status daya layar, di mana 0 adalah layar mati, 1 layar aktif, dan 2 untuk keyguard selesai.

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

Statistik durasi penguncian layar teragregasi hanya melacak waktu penguncian layar sebenarnya bertanggung jawab untuk menjaga perangkat tetap terjaga dan tidak menyertakan waktu dengan layar menyala. Selain itu, jika beberapa penguncian layar saat aktif ditahan secara bersamaan, waktu durasi penguncian layar saat aktif didistribusikan ke seluruh penguncian layar saat aktif tersebut.

Untuk bantuan lebih lanjut dalam memvisualisasikan status daya, gunakan Battery Historian , alat sumber terbuka Google untuk menganalisis konsumen baterai menggunakan file laporan bug 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 waktu proses, layanan terkait, skor oom_adj , dll. Untuk detail tentang cara Android mengelola proses, lihat Proses dan Utas .

Menentukan runtime proses

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

Mengapa suatu 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 pada proses, yang dapat diperbarui secara dinamis oleh ActivityManager). Outputnya mirip dengan snapshot memori tetapi menyertakan informasi tambahan tentang apa yang menyebabkan proses berjalan. Pada contoh di bawah, entri yang dicetak tebal menunjukkan proses gms.persistent berjalan pada prioritas vis (terlihat) karena proses sistem terikat ke NetworkLocationService .

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 di pesan log. Dalam contoh ini, "24840" dan "24851" adalah PID (ID proses) dan TID (ID utas).
  • 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 detailnya, lihat Pemindaian Hemat Energi (LE) dan Bluetooth .