下圖代表 Android 感應器堆疊。每個元件只會與直接位於其上方和下方的元件通訊，但部分感應器可以略過感應器中樞 (如有)。控制項會從應用程式向下流至感應器，資料則會從感應器向上流至應用程式。
圖 1. Android 感應器堆疊的各層及其各自擁有者
SDK
應用程式會透過 Sensors SDK (軟體開發套件) API 存取感應器。SDK 包含列出可用感應器及註冊感應器的函式。
向感應器註冊時，應用程式會指定偏好的取樣頻率和延遲時間需求。
- 舉例來說，應用程式可能會註冊預設加速計，以 100 Hz 的頻率要求事件，並允許以 1 秒的延遲時間回報事件。
- 應用程式會以至少 100 Hz 的速率接收來自加速度計的事件，且可能延遲最多 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 Proxy，取得感應器專屬服務的存取權。
繫結器 IPC
Binder IPC 代理程式可促進跨處理序界線的通訊。
HAL
感應器硬體抽象層 (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 有兩條中斷線：一條用於喚醒中斷 (適用於喚醒感應器)，另一條用於非喚醒中斷 (適用於非喚醒感應器)。
感應器
這些是進行測量的實體 MEMS 晶片。在許多情況下，同一晶片上會有多個實體感應器。舉例來說，有些晶片包含加速計、陀螺儀和磁力計。(這類晶片通常稱為 9 軸晶片，因為每個感應器都會提供 3 個軸的資料)。
其中一些晶片也包含一些邏輯，可執行一般運算，例如動作偵測、步數偵測和 9 軸感應器融合。
雖然 CDD 的電力和準確度規定與建議是針對 Android 感應器，而非實體感應器，但這些規定會影響實體感應器的選擇。舉例來說，遊戲旋轉向量的準確度需求會影響實體陀螺儀的準確度需求。裝置製造商有責任推導實體感應器的需求。