下圖展示了 Android 感測器堆疊。每個組件僅與其正上方和正下方的組件通信，但某些感測器可以繞過感測器集線器（當存在感測器集線器時）。控制從應用程式流向感測器，數據從感測器流向應用程式。
圖 1. Android 感測器堆疊的各層及其各自的所有者
軟體開發工具包
應用程式透過感測器 SDK（軟體開發工具包）API存取感測器。 SDK 包含列出可用感測器和註冊感測器的功能。
註冊到感測器時，應用程式指定其首選取樣頻率及其延遲要求。
- 例如，應用程式可能會註冊到預設加速計，以 100Hz 請求事件，並允許以 1 秒延遲報告事件。
- 應用程式將以至少 100Hz 的速率接收來自加速度計的事件，並且可能延遲最多 1 秒。
有關 SDK 的更多信息，請參閱開發人員文件。
框架
該框架負責將多個應用程式連結到HAL 。 HAL 本身就是單一客戶端。如果沒有在框架層級發生這種多路復用，則在任何給定時間只有一個應用程式可以存取每個感測器。
- 當第一個應用程式註冊到感測器時，框架會向 HAL 發送請求以啟動感測器。
- 當其他應用程式註冊到相同感測器時，框架會考慮每個應用程式的要求，並將更新的請求參數發送到 HAL。
- 當註冊到一個感測器的最後一個應用程式從該感測器取消註冊時，框架會向 HAL 發送請求以停用感測器，這樣就不會不必要地消耗電量。
多路復用的影響
框架中對復用層的需求解釋了一些設計決策。
- 當應用程式請求特定的取樣頻率時，無法保證事件不會以更快的速率到達。如果另一個應用程式以更快的速率請求相同的感測器，第一個應用程式也將以更快的速率接收它們。
- 同樣缺乏保證也適用於請求的最大報告延遲：應用程式接收事件的延遲可能比其請求的延遲少得多。
- 除了取樣頻率和最大報告延遲之外，應用程式無法配置感測器參數。
- 例如，想像一個可以在“高精度”和“低功耗”模式下工作的實體感測器。
- Android 裝置上只能使用這兩種模式中的一種，否則應用程式可能會要求高精度模式，而另一種則要求低功耗模式；該框架無法滿足這兩種應用程式。該框架必須始終能夠滿足其所有客戶，因此這不是一個選擇。
- 沒有機制將資料從應用程式發送到感測器或其驅動程式。這可確保一個應用程式無法修改感測器的行為，從而破壞其他應用程式。
感測器融合
Android 框架為某些複合感測器提供了預設實作。當裝置上存在陀螺儀、加速度計和磁力計，但不存在旋轉向量、重力和線性加速度感測器時，框架會實現這些感測器，以便應用程式仍然可以使用它們。
預設實作無法存取其他實作可以存取的所有數據，而且它必須在 SoC 上運行，因此它不像其他實作那樣準確或節能。設備製造商應盡可能定義自己的融合感測器（旋轉向量、重力和線性加速度，以及更新的複合感測器，例如遊戲旋轉向量），而不是依賴此預設實現。設備製造商也可以要求感測器晶片供應商為其提供實施方案。
預設感測器融合實現未維護，可能會導致依賴它的設備無法通過 CTS。
在引擎蓋下
本節是為維護 Android 開源專案 (AOSP) 框架程式碼的人員提供的背景資訊。它與硬體製造商無關。
JNI
此框架使用與android.hardware關聯的 Java 本機介面 (JNI)，位於frameworks/base/core/jni/目錄中。此程式碼會呼叫較低層級的本機程式碼來取得對感測器硬體的存取權限。
原生框架
本機框架在frameworks/native/中定義，並提供與android.hardware套件相當的本機。本機框架呼叫 Binder IPC 代理程式來取得對特定於感測器的服務的存取權限。
賓德工控機
Binder IPC 代理有助於跨進程邊界的通訊。
哈爾
感測器硬體抽象層 (HAL) API 是硬體驅動程式和 Android 框架之間的介面。它由一個 HAL 介面sensors.h 和一個我們稱為sensors.cpp 的HAL 實作組成。
此介面由 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 有兩條中斷線：一條用於喚醒中斷（用於喚醒感測器），另一條用於非喚醒中斷（對於非喚醒感測器） 。
感應器
這些是進行測量的實體 MEM 晶片。在許多情況下，同一晶片上存在多個實體感測器。例如，一些晶片包括加速計、陀螺儀和磁力計。 （此類晶片通常稱為 9 軸晶片，因為每個感測器提供 3 個軸上的資料。）
其中一些晶片還包含一些執行常用計算的邏輯，例如運動檢測、步數檢測和 9 軸感測器融合。
儘管 CDD 功率和精度要求和建議針對 Android 感測器而不是實體感測器，但這些要求會影響實體感測器的選擇。例如，遊戲旋轉向量的精確度要求會影響物理陀螺儀所需的精確度。由設備製造商決定實體感測器的要求。