傳感器堆棧

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

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

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

SDK

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

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

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

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

框架

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

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

多路復用的影響

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

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

傳感器融合

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

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

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

引擎蓋下

本部分作為背景信息提供給那些維護 Android 開源項目 (AOSP) 框架代碼的人員。它與硬件製造商無關。

JNI

該框架使用與android.hardware關聯並位於frameworks/base/core/jni/目錄中的 Java Native Interface (JNI)。此代碼調用較低級別的本機代碼以獲取對傳感器硬件的訪問權限。

原生框架

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

粘合劑工控機

Binder IPC 代理促進跨進程邊界的通信。

哈爾

Sensors 硬件抽象層 (HAL) API 是硬件驅動程序和 Android 框架之間的接口。它由一個 HAL 接口sensors.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 功能,您還可以使用連接到Hikey或 Hikey960 開發板的 Neonkey SensorHub。

傳感器集線器的具體實現方式取決於架構。它有時是一個單獨的芯片,有時包含在與 SoC 相同的芯片上。傳感器集線器的重要特徵是它應該包含足夠的內存用於批處理,並且消耗很少的功率來實現低功耗 Android 傳感器。一些傳感器集線器包含用於通用計算的微控制器和硬件加速器,可為低功耗傳感器啟用極低功耗計算。

Android 未指定傳感器集線器的架構以及它如何與傳感器和 SoC(I2C 總線、SPI 總線等)通信,但它應該旨在最大限度地減少整體功耗。

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

傳感器

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

其中一些芯片還包含一些邏輯來執行常見的計算,例如運動檢測、步數檢測和 9 軸傳感器融合。

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