傳感器堆棧

下圖表示Android傳感器堆棧。每個組件僅與其正上方和正下方的組件通信,儘管有些傳感器可以在存在傳感器集線器時繞過它。控制從應用程序一直流到傳感器,數據從傳感器一直流到應用程序。

Android傳感器堆棧的層和所有者

圖1. Android傳感器堆棧的各層及其各自的所有者

軟件開發工具包

應用程序通過Sensors SDK(軟件開發工具包)API訪問傳感器。 SDK包含列出可用傳感器並註冊到傳感器的功能。

在向傳感器註冊時,應用程序會指定其首選的採樣頻率及其延遲要求。

  • 例如,一個應用程序可能註冊到默認的加速度計,以100Hz的頻率請求事件,並允許以1秒的延遲報告事件。
  • 該應用程序將以至少100Hz的速率從加速度計接收事件,並可能延遲長達1秒。

有關SDK的更多信息,請參見開發人員文檔

框架

該框架負責將多個應用程序鏈接到HAL 。 HAL本身是單客戶端。如果在框架級別沒有發生這種多路復用,則只有一個應用程序可以在任何給定時間訪問每個傳感器。

  • 當第一個應用程序註冊到傳感器時,框架向HAL發送請求以激活傳感器。
  • 當其他應用程序註冊到同一傳感器時,框架會考慮每個應用程序的要求,並將更新後的請求參數發送到HAL。
    • 採樣頻率將是請求的採樣頻率的最大值,這意味著某些應用程序將以高於其請求頻率的頻率接收事件。
    • 最大報告延遲將是請求的最小值。如果一個應用程序請求一個傳感器的最大報告延遲為0,則所有應用程序都將以連續模式從該傳感器接收事件,即使某些應用程序請求該傳感器的最大報告延遲為非零。有關更多詳細信息,請參見批處理
  • 當向一個傳感器註冊的最後一個應用程序從其註銷時,框架將向HAL發送請求以停用傳感器,因此不會不必要地消耗功率。

多路傳輸的影響

框架中對多路復用層的需求解釋了一些設計決策。

  • 當應用程序請求特定的採樣頻率時,無法保證事件不會以更快的速度到達。如果另一個應用程序以更快的速率請求相同的傳感器,則第一個應用程序也將以更快的速率接收它們。
  • 同樣,缺乏保證也適用於請求的最大報告延遲:應用程序收到的事件可能比請求的延遲少得多。
  • 除了採樣頻率和最大報告延遲外,應用程序無法配置傳感器參數。
    • 例如,假設有一個物理傳感器可以同時在“高精度”和“低功耗”模式下工作。
    • 這兩種模式中只有一種可以在Android設備上使用,因為否則,應用程序可以請求高精度模式,而另一種則要求低功耗模式。該框架將無法同時滿足這兩個應用程序。該框架必須始終能夠滿足其所有客戶的需求,因此這不是一個選擇。
  • 沒有機制可以將數據從應用程序向下發送到傳感器或其驅動程序。這樣可確保一個應用程序無法修改傳感器的行為,從而破壞其他應用程序。

傳感器融合

Android框架為某些複合傳感器提供了默認實現。當設備上存在陀螺儀加速度計磁力計,但沒有旋轉矢量重力線性加速度傳感器時,該框架將實現這些傳感器,因此應用程序仍可以使用它們。

默認實現無法訪問其他實現可以訪問的所有數據,並且它必須在SoC上運行,因此它不像其他實現那樣準確且省電。設備製造商應盡可能定義自己的融合傳感器(旋轉矢量,重力和線性加速度,以及較新的複合傳感器,例如游戲旋轉矢量),而不要依賴此默認實現。設備製造商還可以要求傳感器芯片供應商為他們提供實施方案。

默認的傳感器融合實施未得到維護,並且可能導致依賴它的設備無法通過CTS。

引擎蓋下

本部分是為維護Android Open Source Project(AOSP)框架代碼的人員提供的背景信息。與硬件製造商無關。

傑尼

該框架使用與android.hardware相關聯的Java本機接口(JNI),位於Java frameworks/base/core/jni/目錄中。該代碼調用較低級別的本機代碼以獲得對傳感器硬件的訪問。

本機框架

本機框架在frameworks/native/定義,並提供與android.hardware包等效的本機。本機框架調用Binder IPC代理以獲取對特定於傳感器的服務的訪問。

活頁夾IPC

活頁夾IPC代理有助於跨過程邊界進行通信。

哈爾

傳感器硬件抽象層(HAL)API是硬件驅動程序和Android框架之間的接口。它由一個HAL接口sensor.h和一個HAL實現(我們稱為sensors.cpp)組成。

該接口由Android和AOSP貢獻者定義,實現由設備製造商提供。

傳感器HAL接口位於hardware/libhardware/include/hardware 。有關其他詳細信息,請參見sensors.h

發布週期

HAL實現通過設置your_poll_device.common.version指定要實現的HAL接口版本。現有的HAL接口版本在sensors.h中定義,並且功能與這些版本相關。

Android框架當前支持1.0和1.3版本,但很快將不再支持1.0。本文檔介紹了所有設備都應升級到的1.3版的行為。有關如何升級到1.3的詳細信息,請參見HAL版本棄用

內核驅動

傳感器驅動程序與物理設備進行交互。在某些情況下,HAL實現和驅動程序是同一軟件實體。在其他情況下,硬件集成商要求傳感器芯片製造商提供驅動程序,但它們是編寫HAL實現的驅動程序。

在任何情況下,HAL實現和內核驅動程序均由硬件製造商負責,Android並未提供編寫它們的首選方法。

傳感器集線器

設備的傳感器堆棧可以選擇包括傳感器集線器,可用於在SoC處於掛起模式時以低功耗執行一些低級計算。例如,可以在那些芯片上執行步數計數或傳感器融合。這也是實現傳感器批處理的好地方,為傳感器事件添加硬件FIFO。有關更多信息,請參見批處理

注意:要開發使用新的傳感器或LED新ContextHub功能,您還可以使用Neonkey SensorHub連接到Hikey或Hikey960開發板。

傳感器集線器的實現方式取決於體系結構。它有時是單獨的芯片,有時與SoC包含在同一芯片中。傳感器集線器的重要特徵在於,它應包含足夠的內存以進行批處理,並且僅消耗很少的電量以實現低功耗Android傳感器的實現。一些傳感器集線器包含一個用於通用計算的微控制器,以及一個硬件加速器,用於為低功耗傳感器實現非常低功耗的計算。

Android並未指定傳感器集線器的架構方式以及如何與傳感器和SoC通信(I2C總線,SPI總線等),但其目的是最大程度地減少總體功耗。

一個似乎對實現簡單性有重大影響的選項是有兩條中斷線從傳感器集線器到SoC:一條用於喚醒中斷(用於喚醒傳感器),另一條用於非喚醒中斷。 (用於非喚醒傳感器)。

感測器

這些是進行測量的物理MEMs芯片。在許多情況下,同一芯片上存在多個物理傳感器。例如,一些芯片包括加速度計,陀螺儀和磁力計。 (這種芯片通常稱為9軸芯片,因為每個傳感器都可在3軸上提供數據。)

這些芯片中的一些還包含一些用於執行常規計算的邏輯,例如運動檢測,步距檢測和9軸傳感器融合。

儘管CDD的功能和準確性要求和建議針對的是Android傳感器,而不是物理傳感器,但這些要求會影響物理傳感器的選擇。例如,對遊戲旋轉矢量的精度要求會影響物理陀螺儀的精度要求。由設備製造商來決定對物理傳感器的要求。