อ่านรายงานข้อบกพร่อง

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

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

Logcat

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

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

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

ระดับบันทึกมีดังนี้

  • V: แสดงรายละเอียด
  • D: debug
  • I: ข้อมูล
  • W: คำเตือน
  • E: ข้อผิดพลาด

 

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

ANR และ Deadlock

รายงานข้อบกพร่องจะช่วยคุณระบุสาเหตุที่ทำให้เกิดข้อผิดพลาดแอปพลิเคชันไม่ตอบสนอง (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) มากกว่า 1 ชุด ตรวจสอบว่าคุณกําลังดูส่วน

ค้นหาการล็อกตาย

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

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

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

กิจกรรม

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

ดูกิจกรรมที่โฟกัส

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

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

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

ตรวจสอบว่าอุปกรณ์ทำงานหนักเกินไปหรือไม่

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

หน่วยความจำ

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

ระบุหน่วยความจําเหลือน้อย

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

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

ดูตัวบ่งชี้ที่ผ่านมา

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

ดูตัวบ่งชี้การทํางานหนัก

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

บันทึก ANR สามารถแสดงภาพรวมหน่วยความจำที่คล้ายกันได้

ดูภาพความทรงจำ

สแนปชอตหน่วยความจําคือสถานะการถ่ายโอนข้อมูลแสดงรายการกระบวนการ Java และระบบที่ทํางานอยู่ (ดูรายละเอียดที่หัวข้อการดูการกําหนดหน่วยความจําโดยรวม) โปรดทราบว่าภาพรวมจะแสดงเฉพาะสถานะ ณ ช่วงเวลาหนึ่งๆ ระบบอาจทำงานได้ดีขึ้น (หรือแย่ลง) ก่อนการจับภาพ

ออกอากาศ

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

ดูการออกอากาศที่ผ่านมา

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

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

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

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

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

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

ดูผู้ฟังการออกอากาศ

หากต้องการดูรายการเครื่องรับที่รับการออกอากาศ ให้ดูตารางเครื่องรับ Resolver ใน 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 Store ในกรณีนี้ ข้อความจากแอป Google Play Store (finsky) และ installd จะปรากฏก่อนข้อความ dex2oat

การคอมไพล์อาจเกิดขึ้นในเบื้องหลังด้วยเมื่อแอปพลิเคชันกำลังโหลดไฟล์ 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) ใช้ฐานเวลาอื่น โดยติดแท็กรายการบันทึกด้วยวินาทีนับตั้งแต่บูตโหลดเดอร์ทำงานเสร็จ หากต้องการลงทะเบียนลำดับเวลานี้กับลำดับเวลาอื่นๆ ให้ค้นหาข้อความหยุดออกและหยุดเข้า

<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'...

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

พาวเวอร์

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

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

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

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

แพ็กเกจ

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

กระบวนการ

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

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

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

สาเหตุที่กระบวนการทํางานอยู่

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

การสแกน

ใช้ขั้นตอนต่อไปนี้เพื่อระบุแอปพลิเคชันที่ทำการสแกนบลูทูธพลังงานต่ำ (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 (รหัสกระบวนการ) และ TID (รหัสเธรด)
  • ค้นหาแอปพลิเคชันที่เชื่อมโยงกับ 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) และการสแกนบลูทูธ