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

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

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

ล็อกแคท

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

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

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

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

  • V: ละเอียด
  • D: แก้ปัญหา
  • ฉัน: ข้อมูล
  • ว: คำเตือน
  • จ: ผิดพลาด

สำหรับแท็กบันทึกเหตุการณ์ที่เป็นประโยชน์อื่นๆ โปรดดูที่ /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—ก่อนที่จะไม่ติดขัด)
  • การติดตามสแต็กมากกว่าหนึ่งชุด ( VM TRACES JUST NOW และ VM TRACES AT LAST ANR ) อาจมีอยู่ ตรวจสอบให้แน่ใจว่าคุณกำลังดูส่วนที่ถูกต้อง

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

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

การออกอากาศ

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

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

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

ส่วน สรุป คือภาพรวมของการออกอากาศเบื้องหน้า 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 Store ในกรณีนี้ ข้อความจากแอป Google Play สโตร์ ( 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]

บันทึก Kernel ( dmesg ) ใช้ฐานเวลาที่แตกต่างกัน โดยแท็กรายการบันทึกเป็นวินาทีนับตั้งแต่ bootloader เสร็จสิ้น หากต้องการลงทะเบียนมาตราส่วนเวลานี้เป็นมาตราส่วนเวลาอื่น ให้ค้นหาข้อความ Suspend Exit และ Suspend Entry Message:

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

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

แพ็คเกจ

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

กระบวนการ

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

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

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

เหตุผลที่กระบวนการกำลังทำงานอยู่

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

สแกน

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