รูปภาพด้านล่างแสดงกองเซ็นเซอร์ Android คอมโพเนนต์แต่ละชิ้นจะสื่อสารกับคอมโพเนนต์ที่อยู่เหนือและใต้โดยตรงเท่านั้น แต่เซ็นเซอร์บางตัวอาจข้ามฮับเซ็นเซอร์ได้หากมี การควบคุมจะไหลจากแอปพลิเคชันไปยังเซ็นเซอร์ และข้อมูลจะไหลจากเซ็นเซอร์ไปยังแอปพลิเคชัน
รูปที่ 1 เลเยอร์ของกองเซ็นเซอร์ Android และเจ้าของที่เกี่ยวข้อง
SDK
แอปพลิเคชันเข้าถึงเซ็นเซอร์ผ่าน Sensors SDK (Software Development Kit) API SDK มีฟังก์ชันสำหรับแสดงรายการเซ็นเซอร์ที่ใช้ได้และลงทะเบียนกับเซ็นเซอร์
เมื่อลงทะเบียนกับเซ็นเซอร์ แอปพลิเคชันจะระบุความถี่ในการสุ่มตัวอย่างที่ต้องการและข้อกำหนดเวลาในการตอบสนอง
- ตัวอย่างเช่น แอปพลิเคชันอาจลงทะเบียนกับเครื่องวัดความเร่งเริ่มต้น ขอเหตุการณ์ที่ 100 Hz และอนุญาตให้รายงานเหตุการณ์โดยมีความล่าช้า 1 วินาที
- แอปพลิเคชันจะรับเหตุการณ์จากเครื่องวัดความเร่งในอัตราอย่างน้อย 100 Hz และอาจมีความล่าช้าสูงสุด 1 วินาที
ดูข้อมูลเพิ่มเติมเกี่ยวกับ SDK ได้ในเอกสารประกอบสําหรับนักพัฒนาซอฟต์แวร์
เฟรมเวิร์ก
เฟรมเวิร์กมีหน้าที่เชื่อมโยงแอปพลิเคชันต่างๆ กับ HAL HAL เองเป็นแบบไคลเอ็นต์เดียว หากไม่มีมัลติเพล็กซิตติ้งนี้เกิดขึ้นที่ระดับเฟรมเวิร์ก จะมีเพียงแอปพลิเคชันเดียวเท่านั้นที่เข้าถึงเซ็นเซอร์แต่ละตัวได้ในเวลาหนึ่งๆ
- เมื่อแอปพลิเคชันแรกลงทะเบียนกับเซ็นเซอร์ เฟรมเวิร์กจะส่งคำขอไปยัง HAL เพื่อเปิดใช้งานเซ็นเซอร์
- เมื่อแอปพลิเคชันเพิ่มเติมลงทะเบียนกับเซ็นเซอร์เดียวกัน เฟรมเวิร์กจะพิจารณาข้อกำหนดจากแต่ละแอปพลิเคชันและส่งพารามิเตอร์ที่ขอซึ่งอัปเดตแล้วไปยัง HAL
- ความถี่การสุ่มตัวอย่างจะเป็นความถี่การสุ่มตัวอย่างสูงสุดที่ขอ ซึ่งหมายความว่าแอปพลิเคชันบางรายการจะได้รับเหตุการณ์ด้วยความถี่สูงกว่าที่ขอ
- เวลาในการตอบสนองสูงสุดในการรายงานจะเป็นค่าต่ำสุดของเวลาในการตอบสนองที่ขอ หากแอปพลิเคชัน 1 แอปพลิเคชันขอเซ็นเซอร์ 1 ตัวที่มีความล่าช้าในการรายงานสูงสุด 0 แอปพลิเคชันทั้งหมดจะได้รับเหตุการณ์จากเซ็นเซอร์นี้ในโหมดต่อเนื่อง แม้ว่าบางแอปพลิเคชันจะขอเซ็นเซอร์ที่มีความล่าช้าในการรายงานสูงสุดที่ไม่ใช่ 0 ก็ตาม ดูรายละเอียดเพิ่มเติมเกี่ยวกับการรวม
- เมื่อแอปพลิเคชันล่าสุดที่ลงทะเบียนกับเซ็นเซอร์หนึ่งยกเลิกการลงทะเบียน เฟรมเวิร์กจะส่งคำขอไปยัง HAL เพื่อปิดใช้งานเซ็นเซอร์เพื่อไม่ให้สิ้นเปลืองพลังงานโดยไม่จำเป็น
ผลกระทบของการมัลติเพล็กซ์
ความจำเป็นในการใช้เลเยอร์มัลติเพล็กซิตติ้งในเฟรมเวิร์กนี้อธิบายถึงการตัดสินใจด้านการออกแบบบางอย่าง
- เมื่อแอปพลิเคชันขอความถี่การสุ่มตัวอย่างที่เฉพาะเจาะจง ไม่มีการรับประกันว่าเหตุการณ์จะไม่เกิดขึ้นในอัตราที่เร็วขึ้น หากแอปพลิเคชันอื่นขอเซ็นเซอร์เดียวกันในอัตราที่เร็วขึ้น แอปพลิเคชันแรกก็จะรับเซ็นเซอร์ในอัตราที่เร็วขึ้นด้วย
- ไม่มีการรับประกันเดียวกันนี้สำหรับเวลาในการตอบสนองสูงสุดในการรายงานที่ขอ ซึ่งแอปพลิเคชันอาจได้รับเหตุการณ์ที่มีเวลาในการตอบสนองน้อยกว่าที่ขอไว้มาก
- นอกจากความถี่ในการสุ่มตัวอย่างและเวลาในการตอบสนองสูงสุดของการรายงานแล้ว แอปพลิเคชันจะกำหนดค่าพารามิเตอร์เซ็นเซอร์ไม่ได้
- ตัวอย่างเช่น ลองจินตนาการถึงเซ็นเซอร์ทางกายภาพที่ทำงานได้ทั้งในโหมด "ความแม่นยำสูง" และ "พลังงานต่ำ"
- อุปกรณ์ Android ใช้ได้เพียงโหมดใดโหมดหนึ่งเท่านั้น เนื่องจากแอปพลิเคชันหนึ่งอาจขอโหมดความแม่นยำสูง แต่อีกแอปพลิเคชันหนึ่งขอโหมดพลังงานต่ำ เฟรมเวิร์กจึงไม่สามารถตอบสนองความต้องการของทั้ง 2 แอปพลิเคชันได้ เฟรมเวิร์กต้องตอบสนองความต้องการของลูกค้าทั้งหมดได้เสมอ ดังนั้นตัวเลือกนี้จึงใช้ไม่ได้
- ไม่มีกลไกในการส่งข้อมูลจากแอปพลิเคชันไปยังเซ็นเซอร์หรือไดรเวอร์ของเซ็นเซอร์ วิธีนี้ช่วยให้มั่นใจได้ว่าแอปพลิเคชันหนึ่งๆ จะไม่สามารถแก้ไขลักษณะการทำงานของเซ็นเซอร์ ซึ่งจะทำให้แอปพลิเคชันอื่นๆ ทำงานผิดพลาด
การรวมเซ็นเซอร์
เฟรมเวิร์ก Android มีการใช้งานเริ่มต้นสำหรับเซ็นเซอร์คอมโพสิตบางรายการ เมื่ออุปกรณ์มีเครื่องวัดการหมุน มาตรวัดความเร่ง และแม่เหล็กไฟฟ้า แต่ไม่มีเซ็นเซอร์เวกเตอร์การหมุน แรงโน้มถ่วง และการเร่งความเร็วเชิงเส้น เฟรมเวิร์กจะใช้เซ็นเซอร์เหล่านั้นเพื่อให้แอปพลิเคชันยังคงใช้งานได้
การติดตั้งใช้งานเริ่มต้นจะไม่มีสิทธิ์เข้าถึงข้อมูลทั้งหมดที่การติดตั้งใช้งานอื่นๆ มีสิทธิ์เข้าถึง และจะต้องทำงานบน SoC จึงจะไม่ถูกต้องและประหยัดพลังงานเท่ากับการติดตั้งใช้งานอื่นๆ ผู้ผลิตอุปกรณ์ควรกำหนดเซ็นเซอร์แบบรวมของตนเอง (เวกเตอร์การหมุน แรงโน้มถ่วง และอัตราเร่งเชิงเส้น รวมถึงเซ็นเซอร์คอมโพสิตรุ่นใหม่ๆ เช่น เวกเตอร์การหมุนของเกม) แทนที่จะใช้การใช้งานเริ่มต้นนี้ นอกจากนี้ ผู้ผลิตอุปกรณ์ยังขอผู้ให้บริการชิปเซ็นเซอร์ให้ดำเนินการติดตั้งใช้งานได้ด้วย
ไม่มีการบำรุงรักษาการใช้งานฟิวชันเซ็นเซอร์เริ่มต้น และอาจทำให้อุปกรณ์ที่อาศัยฟิวชันเซ็นเซอร์ไม่ผ่าน CTS
กลไกภายใน
ส่วนนี้มีไว้เพื่อเป็นข้อมูลเบื้องต้นสำหรับผู้ที่ดูแลรักษาโค้ดเฟรมเวิร์กโครงการโอเพนซอร์ส Android (AOSP) และไม่เกี่ยวข้องกับผู้ผลิตฮาร์ดแวร์
JNI
เฟรมเวิร์กใช้ Java Native Interface (JNI) ที่เชื่อมโยงกับ android.hardware และอยู่ในไดเรกทอรี frameworks/base/core/jni/ รหัสนี้จะเรียกใช้โค้ดเนทีฟระดับล่างเพื่อให้เข้าถึงฮาร์ดแวร์เซ็นเซอร์
เฟรมเวิร์กเนทีฟ
เฟรมเวิร์กเนทีฟจะกำหนดไว้ใน frameworks/native/ และให้เนทีฟที่เทียบเท่ากับแพ็กเกจ android.hardware เฟรมเวิร์กเนทีฟจะเรียกใช้พร็อกซี Binder IPC เพื่อรับสิทธิ์เข้าถึงบริการเฉพาะเซ็นเซอร์
Binder IPC
พร็อกซี Binder IPC ช่วยให้การสื่อสารข้ามขอบเขตโปรเซสง่ายขึ้น
HAL
Sensors Hardware Abstraction Layer (HAL) API คืออินเทอร์เฟซระหว่างไดรเวอร์ฮาร์ดแวร์กับเฟรมเวิร์ก Android ประกอบด้วยอินเทอร์เฟซ HAL 1 รายการ นั่นคือ sensors.h และการใช้งาน HAL 1 รายการที่เราเรียกว่า sensors.cpp
อินเทอร์เฟซนี้กำหนดโดยผู้มีส่วนร่วมของ Android และ AOSP ส่วนการใช้งานจะมาจากผู้ผลิตอุปกรณ์
อินเทอร์เฟซ HAL ของเซ็นเซอร์อยู่ใน hardware/libhardware/include/hardware
ดูรายละเอียดเพิ่มเติมได้ที่ sensors.h
ช่วงปล่อยเพลง
การใช้งาน HAL จะระบุเวอร์ชันของอินเทอร์เฟซ HAL ที่ใช้โดยการตั้งค่า your_poll_device.common.version เวอร์ชันอินเทอร์เฟซ HAL ที่มีอยู่จะกำหนดไว้ใน sensors.h และฟังก์ชันการทำงานจะเชื่อมโยงกับเวอร์ชันเหล่านั้น
ปัจจุบันเฟรมเวิร์ก Android รองรับเวอร์ชัน 1.0 และ 1.3 แต่ระบบจะไม่รองรับเวอร์ชัน 1.0 อีกต่อไปในเร็วๆ นี้ เอกสารประกอบนี้อธิบายลักษณะการทํางานของเวอร์ชัน 1.3 ซึ่งอุปกรณ์ทุกเครื่องควรอัปเกรด โปรดดูรายละเอียดเกี่ยวกับวิธีอัปเกรดเป็น 1.3 ที่หัวข้อการเลิกใช้งานเวอร์ชัน HAL
ไดรเวอร์เคอร์เนล
ไดรเวอร์เซ็นเซอร์จะโต้ตอบกับอุปกรณ์จริง ในบางกรณี การใช้งาน HAL และไดรเวอร์จะเป็นเอนทิตีซอฟต์แวร์เดียวกัน ในกรณีอื่นๆ ผู้ผสานรวมฮาร์ดแวร์จะขอให้ผู้ผลิตชิปเซ็นเซอร์จัดหาไดรเวอร์ แต่ผู้ผสานรวมจะเป็นผู้เขียนการใช้งาน HAL
ไม่ว่าในกรณีใด การใช้งาน HAL และไดรเวอร์เคอร์เนลถือเป็นความรับผิดชอบของผู้ผลิตฮาร์ดแวร์ และ Android ไม่ได้ระบุแนวทางที่แนะนำในการเขียน HAL และไดรเวอร์เคอร์เนล
ฮับเซ็นเซอร์
กองเซ็นเซอร์ของอุปกรณ์อาจรวมฮับเซ็นเซอร์ไว้ด้วยก็ได้ ซึ่งมีประโยชน์ในการทําการคํานวณระดับล่างด้วยพลังงานต่ำขณะที่ SoC อยู่ในโหมดระงับ เช่น การนับก้าวหรือการรวมเซ็นเซอร์จะดำเนินการได้ในชิปเหล่านั้น นอกจากนี้ยังเป็นตําแหน่งที่ดีในการใช้การแยกกลุ่มเซ็นเซอร์ การเพิ่ม FIFO ของฮาร์ดแวร์สําหรับเหตุการณ์ของเซ็นเซอร์ ดูข้อมูลเพิ่มเติมได้ที่การรวม
หมายเหตุ: หากต้องการพัฒนาฟีเจอร์ ContextHub ใหม่ที่ใช้เซ็นเซอร์หรือ LED ใหม่ คุณสามารถใช้ Neonkey SensorHub ที่เชื่อมต่อกับบอร์ดพัฒนา Hike หรือ Hikey960 ได้ด้วย
วิธีที่ฮับเซ็นเซอร์แสดงผลจะขึ้นอยู่กับสถาปัตยกรรม บางครั้งฮับเซ็นเซอร์จะเป็นชิปแยกต่างหาก และบางครั้งก็รวมอยู่ในชิปเดียวกับ SoC ลักษณะที่สำคัญของฮับเซ็นเซอร์คือควรมีหน่วยความจำเพียงพอสำหรับการจัดกลุ่มและใช้พลังงานเพียงเล็กน้อยเพื่อให้ติดตั้งใช้งานเซ็นเซอร์ Android ที่ใช้พลังงานต่ำได้ ฮับเซ็นเซอร์บางรุ่นมีไมโครคอนโทรลเลอร์สําหรับการคํานวณทั่วไป และตัวเร่งฮาร์ดแวร์เพื่อให้สามารถประมวลผลโดยใช้พลังงานต่ำมากสําหรับเซ็นเซอร์พลังงานต่ำ
Android ไม่ได้ระบุโครงสร้างฮับเซ็นเซอร์และวิธีสื่อสารกับเซ็นเซอร์และ SoC (บัส I2C, บัส SPI …) แต่ควรมุ่งเน้นที่การลดการใช้พลังงานโดยรวม
ตัวเลือกหนึ่งที่ดูเหมือนว่าจะมีผลกระทบอย่างมากต่อความเรียบง่ายในการใช้งานคือการใช้สายอินเตอร์รัปต์ 2 เส้นจากฮับเซ็นเซอร์ไปยัง SoC โดยสายหนึ่งสำหรับอินเตอร์รัปต์การปลุก (สำหรับเซ็นเซอร์การปลุก) และอีกสายหนึ่งสำหรับอินเตอร์รัปต์ที่ไม่ปลุก (สำหรับเซ็นเซอร์ที่ไม่ปลุก)
เซ็นเซอร์
นั่นคือชิป MEMs จริงที่ทำการวัด ในหลายกรณี จะมีเซ็นเซอร์ทางกายภาพหลายตัวอยู่ในชิปเดียวกัน เช่น ชิปบางตัวมีตัวตรวจวัดความเร่ง เครื่องวัดการหมุน และแม่เหล็กไฟฟ้า (ชิปดังกล่าวมักเรียกว่าชิป 9 แกน เนื่องจากเซ็นเซอร์แต่ละตัวให้ข้อมูลมากกว่า 3 แกน)
ชิปบางตัวยังมีตรรกะในการทําการคํานวณตามปกติ เช่น การตรวจจับการเคลื่อนไหว การตรวจจับการก้าว และฟิวชันเซ็นเซอร์ 9 แกน
แม้ว่าข้อกำหนดและคำแนะนำเกี่ยวกับกำลังและความแม่นยำของ CDD จะกำหนดเป้าหมายไปที่เซ็นเซอร์ Android ไม่ใช่เซ็นเซอร์ที่จับภาพ แต่ข้อกำหนดเหล่านั้นก็ส่งผลต่อการเลือกเซ็นเซอร์ที่จับภาพ ตัวอย่างเช่น ข้อกำหนดด้านความแม่นยำของเวกเตอร์การหมุนของเกมส่งผลต่อความแม่นยำที่จำเป็นสำหรับไจโรสโคปจริง ผู้ผลิตอุปกรณ์เป็นผู้กำหนดข้อกำหนดสำหรับเซ็นเซอร์ที่จับการเคลื่อนไหว