下圖代表 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 相關聯的 Java Native Interface (JNI)，並位於 frameworks/base/core/jni/ 目錄中。這段程式碼會呼叫較低層級的原生程式碼，取得感應器硬體的存取權。
原生架構
原生架構是在 frameworks/native/ 中定義，並提供與 android.hardware 套件相等的原生項目。原生架構會呼叫 Binder IPC 代理程式，取得特定感應器服務的存取權。
Binder IPC
Binder IPC 代理程式可協助處理序間通訊。
HAL
Sensors Hardware Abstraction Layer (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 之間有兩條中斷線：一個用於喚醒中斷 (喚醒感應器)，另一個用於非喚醒中斷 (非喚醒感應器)。
感應器
這些是用於測量的精密機械式晶片。在許多情況下，同一晶片上會出現多個實體感應器。舉例來說，有些晶片包含加速計、陀螺儀和磁力計。(這類晶片通常稱為 9 軸晶片，因為每個感應器都會提供 3 個軸線的資料)。
其中部分晶片還包含一些邏輯，可執行常見的運算，例如動作偵測、步數偵測和 9 軸感應器融合。
雖然 CDD 的效能和準確度規定和建議適用於 Android 感應器，而非實體感應器，但這些規定會影響實體感應器的選擇。舉例來說，遊戲旋轉向量的精確度要求會影響實體陀螺儀的必要精確度。裝置製造商必須自行推斷實體感應器的相關需求。