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

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

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

Logcat

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

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

กิจกรรม

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

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

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

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

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

ตรวจสอบว่าอุปกรณ์กำลังเล่นข้ามเวอร์ชันหรือไม่

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

หน่วยความจำ

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

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

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

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

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

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

ดูตัวบ่งชี้การการแสดงโฆษณา

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

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

ดูสแนปชอตหน่วยความจำ

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

ออกอากาศ

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

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

การออกอากาศที่ผ่านมาคือการออกอากาศที่ส่งมาแล้ว โดยแสดงอยู่ในรายการ ย้อนลำดับเวลา

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

<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 ซึ่งเป็นกลไกที่ นักพัฒนาแอปพลิเคชันเพื่อระบุว่าแอปพลิเคชันจำเป็นต้องมีอุปกรณ์ ต่อไป (โปรดดูรายละเอียดเกี่ยวกับ Wake Lock ได้ที่ PowerManager.WakeLock และ Keep CPU เปิดอยู่)

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

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

แพ็กเกจ

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

กระบวนการ

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

ระบุรันไทม์ของกระบวนการ

ส่วน 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) และการสแกนหาบลูทูธ