สแต็คเซ็นเซอร์

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

เลเยอร์และเจ้าของสแต็กเซ็นเซอร์ Android

รูปที่ 1 เลเยอร์ของสแต็กเซ็นเซอร์ Android และเจ้าของตามลำดับ

SDK

แอปพลิเคชันเข้าถึงเซ็นเซอร์ผ่าน Sensors SDK (Software Development Kit) API SDK มีฟังก์ชันสำหรับแสดงรายการเซ็นเซอร์ที่มีอยู่และลงทะเบียนกับเซ็นเซอร์

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

  • ตัวอย่างเช่น แอปพลิเคชันอาจลงทะเบียนกับมาตรความเร่งเริ่มต้น โดยร้องขอเหตุการณ์ที่ 100Hz และอนุญาตให้รายงานเหตุการณ์ด้วยเวลาแฝง 1 วินาที
  • แอปพลิเคชันจะได้รับเหตุการณ์จากมาตรความเร่งในอัตราอย่างน้อย 100Hz และอาจล่าช้าได้ถึง 1 วินาที

ดู เอกสารสำหรับนักพัฒนา สำหรับข้อมูลเพิ่มเติมเกี่ยวกับ SDK

กรอบ

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

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

ผลกระทบของมัลติเพล็กซ์

ความต้องการเลเยอร์มัลติเพล็กซ์ในเฟรมเวิร์กนี้อธิบายการตัดสินใจในการออกแบบบางอย่าง

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

เซ็นเซอร์ฟิวชั่น

กรอบงาน Android จัดให้มีการใช้งานเริ่มต้นสำหรับเซ็นเซอร์คอมโพสิตบางตัว เมื่อมี ไจโรสโคป มาตร วัดความเร่ง และ แมกนีโตมิเตอร์ ปรากฏบนอุปกรณ์ แต่ไม่มีเซ็นเซอร์ เวกเตอร์การหมุน แรงโน้มถ่วง และ ความเร่งเชิงเส้น กรอบงานจะใช้เซ็นเซอร์เหล่านั้นเพื่อให้แอปพลิเคชันยังคงสามารถใช้งานได้

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

การใช้งานฟิวชั่นเซ็นเซอร์เริ่มต้นไม่ได้รับการบำรุงรักษา และอาจทำให้อุปกรณ์ที่ใช้เซ็นเซอร์ล้มเหลว CTS

ภายใต้ประทุน

ส่วนนี้จัดทำขึ้นเป็นข้อมูลพื้นฐานสำหรับผู้ที่ดูแลรักษาโค้ดเฟรมเวิร์ก Android Open Source Project (AOSP) ไม่เกี่ยวข้องกับผู้ผลิตฮาร์ดแวร์

เจเอ็นไอ

เฟรมเวิร์กใช้ Java Native Interface (JNI) ที่เกี่ยวข้องกับ android.hardware และอยู่ในไดเร็กทอรี frameworks/base/core/jni/ รหัสนี้เรียกรหัสเนทิฟระดับล่างเพื่อเข้าถึงฮาร์ดแวร์เซ็นเซอร์

กรอบงานเนทิฟ

เฟรมเวิร์กเนทิฟถูกกำหนดไว้ใน frameworks/native/ และจัดเตรียมเนทีฟที่เทียบเท่ากับแพ็คเกจ android.hardware เฟรมเวิร์กดั้งเดิมเรียกพร็อกซี Binder IPC เพื่อเข้าถึงบริการเฉพาะเซ็นเซอร์

เครื่องผูกไอพีซี

พร็อกซี Binder IPC อำนวยความสะดวกในการสื่อสารเกินขอบเขตกระบวนการ

ฮาล

API ของ Sensors Hardware Abstraction Layer (HAL) คืออินเทอร์เฟซระหว่างไดรเวอร์ฮาร์ดแวร์และเฟรมเวิร์ก Android ประกอบด้วยหนึ่งอินเทอร์เฟซ HAL sensors.h และการใช้งาน HAL หนึ่งรายการที่เราเรียกว่า sensors.cpp

อินเทอร์เฟซถูกกำหนดโดยผู้ร่วมให้ข้อมูล Android และ AOSP และการนำไปใช้งานจัดทำโดยผู้ผลิตอุปกรณ์

อินเทอร์เฟซเซ็นเซอร์ HAL อยู่ใน hardware/libhardware/include/hardware ดู sensor.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 ไม่ได้จัดเตรียมแนวทางที่ต้องการในการเขียน

ศูนย์กลางเซ็นเซอร์

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

หมายเหตุ: หากต้องการพัฒนาคุณสมบัติ ContextHub ใหม่ที่ใช้เซ็นเซอร์หรือ LED ใหม่ คุณยังสามารถใช้ Neonkey SensorHub ที่เชื่อมต่อกับบอร์ดพัฒนา Hikey หรือ Hikey960 ได้อีกด้วย

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

วิธีสถาปัตยกรรมฮับเซ็นเซอร์และวิธีการสื่อสารกับเซ็นเซอร์และ SoC (บัส I2C, บัส SPI, …) ไม่ได้ระบุไว้ใน Android แต่ควรมุ่งเป้าไปที่การลดการใช้พลังงานโดยรวมให้เหลือน้อยที่สุด

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

เซนเซอร์

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

ชิปบางตัวยังมีตรรกะในการคำนวณตามปกติ เช่น การตรวจจับการเคลื่อนไหว การตรวจจับขั้นตอน และการรวมเซ็นเซอร์ 9 แกน

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