Baca laporan bug

Bug adalah sebuah kenyataan dalam semua jenis pengembangan—dan laporan bug sangat penting untuk mengidentifikasi dan memecahkan masalah. Semua versi Android mendukung pengambilan 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 data dumpsys , dumpstate , dan logcat dalam format teks (.txt), sehingga Anda dapat dengan mudah mencari konten tertentu. Bagian berikut merinci 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 grep dan keluaran dan/atau keluaran dumpsys .

catatan log

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

Lihat log peristiwa

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

Level log mencakup hal berikut:

  • V: bertele-tele
  • D: men-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 penyebab kesalahan Aplikasi Tidak Merespons (ANR) dan kejadian kebuntuan.

Identifikasi aplikasi yang tidak responsif

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

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

Temukan jejak tumpukan

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

  • Thread utama hanya memberi tahu Anda apa yang dilakukan thread pada saat ANR, yang mungkin sesuai atau tidak dengan penyebab sebenarnya dari ANR. (Tumpukan dalam laporan bug mungkin tidak berbahaya; ada hal lain yang mungkin telah tertahan dalam waktu lama—namun tidak cukup lama untuk ANR—sebelum terlepas.)
  • Lebih dari satu set pelacakan tumpukan ( VM TRACES JUST NOW dan VM TRACES AT LAST ANR ) mungkin ada. Pastikan Anda melihat bagian yang benar.

Temukan kebuntuan

Kebuntuan sering kali pertama kali muncul sebagai ANR karena rangkaian pesan macet. Jika kebuntuan terjadi pada server sistem, pengawas pada akhirnya akan mematikannya, sehingga menghasilkan entri dalam log yang mirip dengan: WATCHDOG KILLING SYSTEM PROCESS . Dari sudut pandang pengguna, perangkat akan melakukan boot ulang, meskipun secara teknis ini adalah proses restart dan bukan reboot yang sebenarnya.

  • Saat runtime dimulai ulang, server sistem mati dan dimulai ulang; pengguna melihat perangkat kembali ke animasi boot.
  • Saat reboot , kernel mengalami crash; pengguna melihat perangkat kembali ke logo boot Google.

Untuk menemukan kebuntuan, periksa bagian jejak VM untuk mengetahui pola thread A menunggu sesuatu yang dipegang oleh thread B, yang pada gilirannya menunggu sesuatu yang dipegang oleh thread A.

Kegiatan

Aktivitas adalah komponen aplikasi yang menyediakan layar tempat pengguna berinteraksi untuk melakukan sesuatu seperti memanggil nomor, mengambil foto, mengirim email, dll. Dari perspektif laporan bug, aktivitas adalah satu hal terfokus yang dapat dilakukan pengguna , sehingga menemukan aktivitas yang menjadi fokus saat terjadi kecelakaan menjadi sangat penting. Aktivitas (melalui ActivityManager) menjalankan proses, sehingga menemukan semua proses berhenti dan dimulai untuk aktivitas tertentu juga dapat membantu pemecahan masalah.

Lihat aktivitas terfokus

Untuk melihat riwayat aktivitas terfokus, telusuri am_focused_activity .

Proses tampilan dimulai

Untuk melihat riwayat proses dimulai, cari Start proc .

Tentukan apakah perangkat sedang meronta-ronta

Untuk menentukan apakah perangkat sedang 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 kali memiliki memori fisik yang terbatas, pengelolaan memori akses acak (RAM) sangatlah penting. Laporan bug berisi beberapa indikator memori rendah serta dumpstate yang menyediakan snapshot memori.

Identifikasi memori rendah

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

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

Lihat indikator historis

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

Lihat indikator meronta-ronta

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

Log ANR dapat memberikan snapshot memori serupa.

Dapatkan cuplikan memori

Snapshot memori adalah dumpstate yang mencantumkan proses Java dan proses asli yang berjalan (untuk detailnya, lihat Melihat Alokasi Memori Keseluruhan ). Ingatlah bahwa snapshot hanya memberikan keadaan pada saat tertentu; sistem mungkin berada 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), memungkinkan mereka mendengarkan dan merespons siaran. Laporan bug berisi informasi tentang siaran yang terkirim dan siaran yang belum terkirim, serta dumpsys semua penerima yang mendengarkan siaran tertentu.

Lihat siaran sejarah

Siaran historis adalah siaran yang sudah terkirim, dicantumkan 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 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.

Lihat siaran aktif

Siaran aktif adalah siaran yang belum terkirim. Jumlah antrian yang besar berarti sistem tidak dapat mengirimkan siaran dengan cukup cepat untuk mengimbanginya.

Lihat 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 perselisihan

Pencatatan log pertentangan monitor kadang-kadang dapat menunjukkan pertikaian monitor yang sebenarnya, namun paling sering menunjukkan sistem dimuat sedemikian rupa sehingga semuanya melambat. Anda mungkin melihat peristiwa monitor panjang yang dicatat oleh ART di sistem atau log 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 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 installd logging.

Cerita

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

Sinkronkan 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 kali 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, saat 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 tangguhkan keluar dan tangguhkan 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 kernel mungkin tidak menyertakan waktu saat ditangguhkan, Anda harus mendaftarkan log sedikit demi sedikit di antara pesan masuk dan keluar penangguhan. Selain itu, log kernel menggunakan zona waktu UTC dan harus disesuaikan dengan zona waktu pengguna.

Identifikasi 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 Starting service 'bugreport' :

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

Bekerja mundur untuk menghubungkan kedua peristiwa tersebut, dengan mengingat peringatan yang disebutkan dalam Garis waktu sinkronisasi . Meskipun ada banyak hal yang terjadi setelah laporan bug dimulai, sebagian besar aktivitas tidak terlalu berguna karena tindakan mengambil laporan bug akan membebani sistem secara signifikan.

Kekuatan

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

Laporan bug juga berisi statistik tentang penguncian layar saat aktif, yaitu mekanisme yang digunakan oleh pengembang aplikasi untuk menunjukkan bahwa aplikasi mereka harus tetap mengaktifkan perangkat. (Untuk detail tentang penguncian layar saat aktif, lihat PowerManager.WakeLock dan Tetap nyalakan CPU .)

Statistik durasi penguncian layar saat aktif yang dikumpulkan hanya melacak waktu penguncian layar saat aktif sebenarnya bertanggung jawab untuk menjaga perangkat tetap aktif dan tidak menyertakan waktu saat layar menyala. Selain itu, jika beberapa penguncian layar aktif ditahan secara bersamaan, waktu durasi penguncian layar aktif akan didistribusikan ke seluruh penguncian layar 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 Thread .

Tentukan waktu proses

Bagian procstats berisi statistik lengkap tentang berapa lama proses dan layanan terkait telah berjalan. Untuk ringkasan yang cepat dan 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 telah berjalan pada berbagai prioritas, dan RAM-nya penggunaan diformat sebagai min-average-max PSS/min-average-max USS.

Alasan suatu proses sedang 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 mencakup 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 pada NetworkLocationService -nya.

Pemindaian

Gunakan langkah-langkah berikut untuk mengidentifikasi aplikasi yang melakukan pemindaian Bluetooth Low Energy (BLE) secara 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 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 detailnya, lihat Pemindaian Energi Rendah (LE) dan Bluetooth .