การอ่านรายงานข้อผิดพลาด

ข้อบกพร่องเกิดขึ้นได้จริงในการพัฒนาทุกประเภท และรายงานข้อผิดพลาดมีความสำคัญต่อการระบุและแก้ไขปัญหา Android ทุกรุ่นรองรับการรายงานข้อผิดพลาดด้วย Android Debug Bridge (adb) ; Android เวอร์ชัน 4.2 ขึ้นไปรองรับ ตัวเลือกสำหรับนักพัฒนาซอฟต์แวร์ สำหรับการรายงานจุดบกพร่องและการแชร์ผ่านอีเมล ไดรฟ์ ฯลฯ

รายงานข้อบกพร่องของ Android ประกอบด้วยข้อมูล dumpsys , dumpstate และ logcat ในรูปแบบข้อความ (.txt) ทำให้คุณสามารถค้นหาเนื้อหาเฉพาะได้อย่างง่ายดาย ส่วนต่อไปนี้ให้รายละเอียดส่วนประกอบรายงานจุดบกพร่อง อธิบายปัญหาทั่วไป และให้คำแนะนำที่เป็นประโยชน์และคำสั่ง grep สำหรับการค้นหาบันทึกที่เกี่ยวข้องกับจุดบกพร่องเหล่านั้น ส่วนใหญ่ยังมีตัวอย่างสำหรับคำสั่ง grep และเอาต์พุต และ/หรือเอาต์พุต dumpsys

Logcat

บันทึก logcat เป็นดัมพ์แบบอิงสตริงของข้อมูล logcat ทั้งหมด ส่วน ของระบบ สงวนไว้สำหรับเฟรมเวิร์กและมีประวัติยาวนานกว่า ส่วนหลัก ซึ่งมีทุกอย่างอื่น โดยทั่วไป แต่ละบรรทัดจะเริ่มต้นด้วย timestamp UID PID TID log-level แม้ว่า UID อาจไม่อยู่ใน Android เวอร์ชันเก่าก็ตาม

กำลังดูบันทึกเหตุการณ์

บันทึกนี้มีการแสดงสตริงของข้อความบันทึกรูปแบบไบนารี มันมีเสียงดังน้อยกว่าบันทึก logcat แต่ยังอ่านยากขึ้นเล็กน้อย เมื่อดูบันทึกเหตุการณ์ คุณสามารถค้นหารหัสกระบวนการเฉพาะ (PID) ในส่วนนี้เพื่อดูว่ามีกระบวนการใดบ้าง รูปแบบพื้นฐานคือ: การ timestamp PID TID log-level log-tag tag-values

ระดับการบันทึกรวมถึงสิ่งต่อไปนี้:

  • V: ละเอียด
  • D: ดีบัก
  • ฉัน: ข้อมูล
  • W: คำเตือน
  • E: ผิดพลาด

สำหรับแท็กบันทึกเหตุการณ์ที่เป็นประโยชน์อื่นๆ โปรดดูที่ /services/core/java/com/android/server/EventLogTags.logtags

ANR และการหยุดชะงัก

รายงานข้อบกพร่องสามารถช่วยระบุสาเหตุของข้อผิดพลาด Application Not Responding (ANR) และเหตุการณ์การหยุดชะงักได้

การระบุแอพที่ไม่ตอบสนอง

เมื่อแอปพลิเคชันไม่ตอบสนองภายในระยะเวลาหนึ่ง ซึ่งมักจะเกิดจากเธรดหลักที่ถูกบล็อกหรือไม่ว่าง ระบบจะฆ่ากระบวนการและทิ้งสแต็กไปที่ /data/anr หากต้องการค้นหาผู้กระทำผิดที่อยู่เบื้องหลัง ANR ให้ grep สำหรับ am_anr ในบันทึกเหตุการณ์ไบนารี

คุณยังสามารถ grep สำหรับ ANR in บันทึก logcat ซึ่งมีข้อมูลเพิ่มเติมเกี่ยวกับสิ่งที่ใช้ CPU ในขณะที่ ANR

การค้นหาสแต็กเทรซ

คุณมักจะพบสแต็กเทรซที่สอดคล้องกับ ANR ตรวจสอบให้แน่ใจว่าการประทับเวลาและ PID บนการติดตาม VM ตรงกับ ANR ที่คุณกำลังตรวจสอบ จากนั้นตรวจสอบเธรดหลักของกระบวนการ โปรดจำไว้ว่า:

  • เธรดหลักจะบอกคุณเฉพาะสิ่งที่เธรดกำลังทำในขณะที่ ANR ซึ่งอาจหรือไม่สอดคล้องกับสาเหตุที่แท้จริงของ ANR (กองซ้อนในรายงานข้อบกพร่องอาจไร้เดียงสา อย่างอื่นอาจติดอยู่เป็นเวลานาน—แต่ไม่นานพอสำหรับ ANR—ก่อนที่จะคลายการติด)
  • อาจมีสแต็กเทรซมากกว่าหนึ่งชุด ( VM TRACES JUST NOW และ VM TRACES AT LAST ANR ) ตรวจสอบให้แน่ใจว่าคุณกำลังดูส่วนที่ถูกต้อง

หาทางตัน

การหยุดชะงักมักจะปรากฏเป็น ANR เนื่องจากเธรดติดขัด หากการชะงักงันเกิดขึ้นกับเซิร์ฟเวอร์ของระบบ ในที่สุด watchdog ก็จะฆ่ามัน นำไปสู่รายการในบันทึกที่คล้ายกับ: WATCHDOG KILLING SYSTEM PROCESS จากมุมมองของผู้ใช้ อุปกรณ์จะรีบูต แม้ว่าในทางเทคนิคแล้ว นี่คือการรีสตาร์ทแบบรันไทม์แทนที่จะเป็นการรีบูตที่แท้จริง

  • ในการรีสตาร์ท รันไทม์ เซิร์ฟเวอร์ระบบจะหยุดทำงานและรีสตาร์ท ผู้ใช้เห็นอุปกรณ์กลับไปที่แอนิเมชั่นการบูต
  • ในการ รีบูต เคอร์เนลขัดข้อง ผู้ใช้เห็นอุปกรณ์กลับไปที่โลโก้บูตของ Google

หากต้องการค้นหาการชะงักงัน ให้ตรวจสอบส่วนการติดตาม VM เพื่อดูรูปแบบของเธรด A ที่รอบางสิ่งที่ยึดโดยเธรด B ซึ่งจะรอบางสิ่งที่เธรด A ยึดไว้

กิจกรรม

กิจกรรม คือองค์ประกอบแอปพลิเคชันที่ให้หน้าจอที่ผู้ใช้โต้ตอบเพื่อทำบางสิ่ง เช่น กดหมายเลข ถ่ายรูป ส่งอีเมล ฯลฯ จากมุมมองของรายงานข้อบกพร่อง กิจกรรม เป็นสิ่งเดียวที่เน้นที่ผู้ใช้สามารถทำได้ ซึ่งทำให้การระบุตำแหน่งกิจกรรมที่อยู่ในโฟกัสระหว่างการชนมีความสำคัญมาก กิจกรรม (ผ่าน ActivityManager) เรียกใช้กระบวนการ ดังนั้นการระบุตำแหน่งกระบวนการทั้งหมดจะหยุดและเริ่มต้นสำหรับกิจกรรมที่กำหนดสามารถช่วยแก้ไขปัญหาได้เช่นกัน

การดูกิจกรรมที่เน้น

หากต้องการดูประวัติของกิจกรรมที่เน้น ให้ค้นหา am_focused_activity

เริ่มกระบวนการดู

หากต้องการดูประวัติการเริ่มต้นกระบวนการ ให้ค้นหา Start proc

เครื่องกระตุกหรือไม่?

ในการตรวจสอบว่าอุปกรณ์กำลัง am_proc_died และ am_proc_start ในช่วงเวลาสั้นๆ

หน่วยความจำ

เนื่องจากอุปกรณ์ Android มักมีหน่วยความจำกายภาพที่มีข้อจำกัด การจัดการหน่วยความจำเข้าถึงโดยสุ่ม (RAM) จึงเป็นสิ่งสำคัญ รายงานข้อบกพร่องประกอบด้วยตัวบ่งชี้หลายตัวของหน่วยความจำเหลือน้อย เช่นเดียวกับสถานะการถ่ายโอนข้อมูลที่มีสแน็ปช็อตหน่วยความจำ

การระบุหน่วยความจำต่ำ

หน่วยความจำเหลือน้อยอาจทำให้ระบบหยุดทำงาน เนื่องจากจะฆ่าบางกระบวนการเพื่อเพิ่มหน่วยความจำ แต่ยังคงเริ่มกระบวนการอื่นต่อไป หากต้องการดูหลักฐานยืนยันหน่วยความจำเหลือน้อย ให้ตรวจสอบความเข้มข้นของรายการ am_proc_died และ am_proc_start ในบันทึกเหตุการณ์ไบนารี

หน่วยความจำเหลือน้อยยังทำให้การสลับงานช้าลงและขัดขวางความพยายามในการส่งคืน (เพราะงานที่ผู้ใช้พยายามกลับไปนั้นถูกฆ่าตาย) หากตัวเรียกใช้งานถูกฆ่า ตัวเรียกใช้งานจะเริ่มต้นใหม่เมื่อผู้ใช้แตะปุ่มโฮม และบันทึกจะแสดงตัวเรียกใช้งานรีโหลดเนื้อหา

กำลังดูตัวชี้วัดทางประวัติศาสตร์

รายการ am_low_memory ในบันทึกเหตุการณ์ไบนารีบ่งชี้ว่ากระบวนการที่แคชล่าสุดเสียชีวิต หลังจากนี้ระบบจะเริ่มให้บริการฆ่า

กำลังดูตัวบ่งชี้การฟาดฟัน

ตัวชี้วัดอื่น ๆ ของการทำลายระบบ (การเพจ การเรียกคืนโดยตรง ฯลฯ) ได้แก่ kswapd , kworker และ mmcqd รอบการบริโภค (โปรดทราบว่าการรวบรวมรายงานข้อผิดพลาดสามารถส่งผลต่อตัวบ่งชี้การฟาดฟันได้)

บันทึก ANR สามารถจัดเตรียมสแนปชอตหน่วยความจำที่คล้ายกันได้

กำลังรับสแนปชอตหน่วยความจำ

สแน็ปช็อตหน่วยความจำเป็นสถานะดัมพ์ที่แสดงรายการรัน Java และกระบวนการดั้งเดิม (สำหรับรายละเอียด โปรดดูที่ Viewing Overall Memory Allocations ) โปรดทราบว่าสแน็ปช็อตจะให้เฉพาะสถานะในช่วงเวลาที่กำหนดเท่านั้น ระบบอาจอยู่ในสภาพที่ดีขึ้น (หรือแย่กว่านั้น) ก่อนสแนปชอต

ออกอากาศ

แอปพลิเคชันสร้างการออกอากาศเพื่อส่งกิจกรรมภายในแอปพลิเคชันปัจจุบันหรือไปยังแอปพลิเคชันอื่น ผู้รับการออกอากาศสมัครรับข้อความเฉพาะ (ผ่านตัวกรอง) ทำให้สามารถฟังและตอบสนองต่อการออกอากาศได้ รายงานข้อบกพร่องประกอบด้วยข้อมูลเกี่ยวกับการออกอากาศที่ส่งและการออกอากาศที่ยังไม่ได้ส่ง ตลอดจนดัมพ์ซิสของผู้รับทั้งหมดที่ฟังการออกอากาศเฉพาะ

กำลังดูการออกอากาศทางประวัติศาสตร์

รายการย้อนหลังคือรายการที่ส่งไปแล้ว โดยเรียงตามลำดับเวลาย้อนหลัง

ส่วน สรุป คือภาพรวมของการออกอากาศเบื้องหน้า 300 รายการล่าสุดและการออกอากาศเบื้องหลัง 300 รายการล่าสุด

ส่วน รายละเอียด ประกอบด้วยข้อมูลที่สมบูรณ์สำหรับการออกอากาศเบื้องหน้า 50 รายการล่าสุดและการออกอากาศพื้นหลัง 50 รายการล่าสุด รวมถึงผู้รับสำหรับการออกอากาศแต่ละรายการ ผู้รับที่มี:

  • รายการ BroadcastFilter ได้รับการลงทะเบียนขณะใช้งานจริงและจะส่งไปยังกระบวนการที่กำลังทำงานอยู่แล้วเท่านั้น
  • รายการ ResolveInfo ลงทะเบียนผ่านรายการรายการ ActivityManager เริ่มกระบวนการสำหรับ ResolveInfo แต่ละรายการ ถ้ายังไม่ได้รันอยู่

กำลังดูการออกอากาศที่ใช้งานอยู่

การออกอากาศที่ใช้งานอยู่คือสิ่งที่ยังไม่ได้ส่ง คิวจำนวนมากหมายความว่าระบบไม่สามารถจัดส่งได้เร็วพอที่จะตามทัน

กำลังดูผู้ฟังออกอากาศ

หากต้องการดูรายชื่อผู้รับที่รับฟังการออกอากาศ ให้ตรวจสอบตารางตัวแก้ไขตัวรับในการ dumpsys activity broadcasts ตัวอย่างต่อไปนี้แสดงเครื่องรับทั้งหมดที่รับฟังสำหรับ USER_PRESENT

ตรวจสอบความขัดแย้ง

การบันทึกการโต้แย้งการตรวจสอบในบางครั้งสามารถบ่งบอกถึงความขัดแย้งของจอภาพที่เกิดขึ้นจริง แต่ส่วนใหญ่มักจะบ่งชี้ว่าระบบโหลดมากจนทุกอย่างช้าลง คุณอาจเห็นกิจกรรมการตรวจสอบที่ยาวนานที่บันทึกโดย ART ในระบบหรือบันทึกเหตุการณ์

ในบันทึกของระบบ:

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

ในบันทึกเหตุการณ์:

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]

การรวบรวมพื้นหลัง

การรวบรวมอาจมีราคาแพงและโหลดอุปกรณ์

การคอมไพล์อาจเกิดขึ้นในพื้นหลังเมื่อมีการดาวน์โหลดการอัปเดตของร้านค้า Google Play ในกรณีนี้ ข้อความจากแอป Google Play สโตร์ ( finsky ) และติดตั้งจะปรากฏก่อน dex2oat installd

การคอมไพล์อาจเกิดขึ้นในพื้นหลังเมื่อแอปพลิเคชันกำลังโหลดไฟล์ dex ที่ยังไม่ได้คอมไพล์ ในกรณีนี้ คุณจะไม่เห็นการ finsky หรือการ installd ตั้ง

คำบรรยาย

การเล่าเรื่องเกี่ยวกับปัญหา (เริ่มต้นอย่างไร เกิดอะไรขึ้น ระบบตอบสนองอย่างไร) จำเป็นต้องมีไทม์ไลน์ของเหตุการณ์ที่ชัดเจน คุณสามารถใช้ข้อมูลในรายงานข้อบกพร่องเพื่อซิงค์ไทม์ไลน์ในบันทึกหลายรายการ และกำหนดเวลาประทับที่แน่นอนของรายงานข้อบกพร่อง

กำลังซิงค์ไทม์ไลน์

รายงานข้อบกพร่องแสดงไทม์ไลน์คู่ขนานหลายรายการ: บันทึกระบบ บันทึกเหตุการณ์ บันทึกเคอร์เนล และไทม์ไลน์เฉพาะหลายรายการสำหรับการออกอากาศ สถิติแบตเตอรี่ ฯลฯ น่าเสียดายที่ไทม์ไลน์มักถูกรายงานโดยใช้ฐานเวลาที่แตกต่างกัน

การประทับเวลาของระบบและบันทึกเหตุการณ์อยู่ในเขตเวลาเดียวกับผู้ใช้ (เช่นเดียวกับการประทับเวลาอื่นๆ ส่วนใหญ่) ตัวอย่างเช่น เมื่อผู้ใช้แตะปุ่มโฮม บันทึกของระบบจะรายงาน:

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

สำหรับการดำเนินการเดียวกัน บันทึกเหตุการณ์จะรายงาน:

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

บันทึกเคอร์เนล ( dmesg ) ใช้ฐานเวลาที่แตกต่างกัน การติดแท็กรายการบันทึกด้วยวินาทีตั้งแต่ bootloader เสร็จสิ้น หากต้องการลงทะเบียนไทม์สเกลนี้กับสเกลเวลาอื่นๆ ให้ค้นหา suspend exit และ ระงับข้อความรายการ :

<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

เนื่องจากบันทึกของเคอร์เนลอาจไม่รวมเวลาในขณะที่อยู่ในการระงับ คุณควรลงทะเบียนบันทึกทีละน้อยระหว่างข้อความรายการระงับและข้อความออก นอกจากนี้ บันทึกเคอร์เนลยังใช้เขตเวลา UTC และต้องปรับให้เข้ากับเขตเวลาของผู้ใช้

ระบุเวลารายงานข้อบกพร่อง

ในการตรวจสอบว่ารายงานจุดบกพร่องเกิดขึ้นเมื่อใด ก่อนอื่นให้ตรวจสอบบันทึกของระบบ (Logcat) สำหรับสถานะ dumpstate: begin :

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

ถัดไป ตรวจสอบบันทึกเวลาของบันทึกเคอร์เนล ( dmesg ) สำหรับข้อความ Starting service 'bugreport' :

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

ย้อนกลับเพื่อสร้างความสัมพันธ์ระหว่างสองเหตุการณ์ โดยคำนึงถึงคำเตือนที่กล่าวถึงใน ไทม์ไลน์การซิงค์ แม้ว่าจะมีอะไรเกิดขึ้นมากมายหลังจากเริ่มรายงานจุดบกพร่องแล้ว แต่กิจกรรมส่วนใหญ่ไม่ได้มีประโยชน์มากนักเนื่องจากการรายงานจุดบกพร่องทำให้ระบบโหลดขึ้นอย่างมาก

พลัง

บันทึกเหตุการณ์ประกอบด้วยสถานะการเปิด/ปิดหน้าจอ โดยที่ 0 คือหน้าจอปิด 1 คือเปิดหน้าจอ และ 2 รายการสำหรับคีย์การ์ดเสร็จสิ้น

รายงานข้อบกพร่องยังมีสถิติเกี่ยวกับการล็อกการปลุก ซึ่งเป็นกลไกที่นักพัฒนาแอปพลิเคชันใช้เพื่อระบุว่าแอปพลิเคชันของตนต้องการให้อุปกรณ์ทำงานต่อไป (สำหรับรายละเอียดเกี่ยวกับการล็อกการปลุก โปรดดูที่ PowerManager.WakeLock และ เปิด CPU ไว้ )

สถิติรวมระยะเวลาล็อกการล็อกจะติดตาม เฉพาะ เวลาที่ล็อกการล็อกมีหน้าที่ในการทำให้อุปกรณ์ตื่นอยู่เสมอและ ไม่ รวมเวลาที่หน้าจอเปิดอยู่เท่านั้น นอกจากนี้ หากมี Wake Lock หลายอันพร้อมกัน เวลา Wake Lock จะถูกกระจายไปทั่ว Wake Lock เหล่านั้น

หากต้องการความช่วยเหลือเพิ่มเติมในการแสดงสถานะพลังงาน ให้ใช้ Battery Historian ซึ่งเป็นเครื่องมือโอเพนซอร์สของ Google เพื่อวิเคราะห์ผู้ใช้แบตเตอรี่โดยใช้ไฟล์รายงานข้อบกพร่องของ Android

แพ็คเกจ

ส่วน DUMP OF SERVICE package ประกอบด้วยเวอร์ชันแอปพลิเคชัน (และข้อมูลที่เป็นประโยชน์อื่นๆ)

กระบวนการ

รายงานข้อบกพร่องประกอบด้วยข้อมูลจำนวนมากสำหรับกระบวนการ ซึ่งรวมถึงเวลาเริ่มต้นและหยุด ระยะเวลารันไทม์ บริการที่เกี่ยวข้อง คะแนน oom_adj เป็นต้น สำหรับรายละเอียดเกี่ยวกับวิธีที่ Android จัดการกระบวนการ โปรดดูที่ กระบวนการและเธรด

การกำหนดรันไทม์ของกระบวนการ

ส่วน procstats มีสถิติที่สมบูรณ์เกี่ยวกับระยะเวลาที่กระบวนการและบริการที่เกี่ยวข้องทำงานอยู่ สำหรับการสรุปที่รวดเร็วและมนุษย์สามารถอ่านได้ ให้ค้นหา AGGREGATED OVER เพื่อดูข้อมูลจากสามหรือ 24 ชั่วโมงที่ผ่านมา จากนั้นค้นหา Summary: เพื่อดูรายการกระบวนการ ระยะเวลาที่กระบวนการเหล่านั้นทำงานในลำดับความสำคัญต่างๆ และ RAM ของกระบวนการ รูปแบบการใช้งานเป็น min-average-max PSS/min-average-max USS

ทำไมกระบวนการทำงาน?

ส่วน dumpsys activity processes แสดงรายการกระบวนการที่กำลังทำงานอยู่ทั้งหมดโดยเรียงลำดับตามคะแนน oom_adj (Android ระบุถึงความสำคัญของกระบวนการโดยการกำหนดค่า oom_adj ให้กับกระบวนการ ซึ่งสามารถอัปเดตแบบไดนามิกโดย ActivityManager) เอาต์พุตจะคล้ายกับส แน็ปช็อตหน่วยความจำ แต่มีข้อมูลเพิ่มเติมเกี่ยวกับสิ่งที่ทำให้กระบวนการทำงาน ในตัวอย่างด้านล่าง รายการที่เป็นตัวหนาระบุว่ากระบวนการ gms.persistent กำลังทำงานอยู่ที่ระดับความสำคัญที่มองเห็นได้ (มองเห็นได้) เนื่องจากกระบวนการของระบบเชื่อม NetworkLocationService กับ vis

สแกน

ใช้ขั้นตอนต่อไปนี้เพื่อระบุแอปพลิเคชันที่ทำการสแกน Bluetooth Low Energy (BLE) มากเกินไป:

  • ค้นหาข้อความบันทึกสำหรับ BluetoothLeScanner :
    $ grep 'BluetoothLeScanner' ~/downloads/bugreport.txt
    07-28 15:55:19.090 24840 24851 D BluetoothLeScanner: onClientRegistered() - status=0 clientIf=5
    
  • ค้นหา PID ในข้อความบันทึก ในตัวอย่างนี้ "24840" และ "24851" คือ PID (ID กระบวนการ) และ TID (ID ของเธรด)
  • ค้นหาแอปพลิเคชันที่เกี่ยวข้องกับ PID:
    PID #24840: ProcessRecord{4fe996a 24840:com.badapp/u0a105}
    

    ในตัวอย่างนี้ ชื่อแพ็กเกจคือ com.badapp

  • ค้นหาชื่อแพ็กเกจบน Google Play เพื่อระบุแอปพลิเคชันที่รับผิดชอบ: https://play.google.com/store/apps/details?id=com.badapp

หมายเหตุ : สำหรับอุปกรณ์ที่ใช้ Android 7.0 ระบบจะรวบรวมข้อมูลสำหรับการสแกน BLE และเชื่อมโยงกิจกรรมเหล่านี้กับแอปพลิเคชันที่เริ่มต้น สำหรับรายละเอียด โปรดดูที่ การสแกนพลังงานต่ำ (LE) และบลูทูธ