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