下圖表示 Android 傳感器堆棧。每個組件僅與直接位於其上方和下方的組件進行通信，儘管某些傳感器在存在傳感器集線器時可以繞過它。控制從應用程序流向傳感器，數據從傳感器流向應用程序。
圖 1. Android 傳感器堆棧的各層及其各自的所有者
SDK
應用程序通過Sensors SDK（軟件開發工具包）API訪問傳感器。 SDK 包含列出可用傳感器和註冊到傳感器的功能。
註冊到傳感器時，應用程序會指定其首選的採樣頻率和延遲要求。
- 例如，應用程序可能會註冊到默認加速度計，以 100Hz 的頻率請求事件，並允許以 1 秒的延遲報告事件。
- 應用程序將以至少 100Hz 的速率從加速度計接收事件，並且可能延遲最多 1 秒。
有關 SDK 的更多信息，請參閱開發人員文檔。
框架
該框架負責將多個應用程序鏈接到HAL 。 HAL 本身是單客戶端。如果沒有在框架級別發生這種多路復用，那麼在任何給定時間只有一個應用程序可以訪問每個傳感器。
- 當第一個應用程序註冊到傳感器時，框架向 HAL 發送請求以激活傳感器。
- 當其他應用程序註冊到同一個傳感器時，框架會考慮每個應用程序的要求，並將更新後的請求參數發送到 HAL。
- 當最後一個註冊到一個傳感器的應用程序從其中註銷時，框架會向 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 傳感器而不是物理傳感器，但這些要求會影響物理傳感器的選擇。例如，遊戲旋轉矢量的精度要求會影響物理陀螺儀所需的精度。由設備製造商決定對物理傳感器的要求。