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

ข้อบกพร่องเป็นสิ่งที่เกิดขึ้นได้ในการพัฒนาทุกประเภท และรายงานข้อบกพร่องเป็นสิ่งสำคัญอย่างยิ่งในการระบุและแก้ปัญหา 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: แก้ไขข้อบกพร่อง
  • I: ข้อมูล
  • W: คำเตือน
  • E: ข้อผิดพลาด

 

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

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

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

ระบุแอปที่ไม่ตอบสนอง

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

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

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

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

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

ค้นหาภาวะหยุดชะงัก

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

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

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

กิจกรรม

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

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

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

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

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

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

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

หน่วยความจำ

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

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

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

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

ดูตัวบ่งชี้ในอดีต

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

ดูตัวบ่งชี้การสลับ

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

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

ดูสแนปชอตความทรงจำ

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

ออกอากาศ

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

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

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

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

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

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

<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 คือการดำเนินการ Keyguard เสร็จสิ้น

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

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

หากต้องการความช่วยเหลือเพิ่มเติมในการแสดงภาพสถานะแบตเตอรี่ ให้ใช้ Battery Historian ซึ่งเป็น เครื่องมือโอเพนซอร์สของ Google สำหรับวิเคราะห์ผู้ใช้แบตเตอรี่โดยใช้ไฟล์ bugreport ของ 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) และการสแกนบลูทูธ