下圖代表 Android 感應器堆疊。每個元件 只能與位於其上方和下方的元件通訊 如果有感應器中樞,感應器就會略過該感應器中樞。透過 向下流至感應器,而資料從感應器流到前方 應用程式。
![Android 感應器堆疊的層和擁有者](https://source.android.google.cn/static/docs/core/interaction/sensors/images/ape_fwk_sensors.png?authuser=19&hl=zh-tw)
圖 1. Android 感應器堆疊的層及其各自擁有者
SDK
應用程式可透過 Sensors SDK (軟體開發套件) API 存取感應器。SDK 包含用來列出可用感應器及註冊至 感應器。
註冊感應器時,應用程式會指定偏好的取樣 頻率和延遲時間需求
- 舉例來說,應用程式可能會註冊預設加速計 以 100Hz 要求的事件要求事件,並允許 1 秒記錄事件 適合延遲時間僅毫秒的 即時高處理量應用程式
- 應用程式會以下列速率接收加速計的事件 100Hz 以上,且可能會延遲最多 1 秒。
如要進一步瞭解 SDK,請參閱開發人員說明文件。
架構
此架構負責將多個應用程式連結至 HAL。HAL 本身為單一用戶端。如未在 因此只有單一應用程式可以存取任何感應器 時間。
- 第一個應用程式註冊至感應器時,架構會傳送一個要求 轉到 HAL 啟動感應器
- 當其他應用程式註冊到相同的感應器時,架構就會 以符合每個應用程式的需求 設為 HAL
- 當最後一個應用程式註冊到其中一個感應器時, 框架會傳送要求給 HAL 以停用感應器,這樣就不會有電源 過度消耗
多工處理的影響
這個架構中必須運用多工處理層進行說明 讓人們瞭解 AI 系統如何做出決策
- 當應用程式要求特定取樣頻率時,系統不會 確保事件不會較快發生。如果其他應用程式 已要求更快速地要求同一個感應器,但第一個應用程式也會 快速接收
- 所要求的報表延遲時間上限也同樣適用: 應用程式接收事件的延遲時間,可能會比要求的延遲時間短。
- 除了取樣頻率和最大報表延遲時間之外,應用程式
設定感應器參數。
- 舉例來說,假設實體感應器可在「高溫」與 準確度」和「低耗電」模式
- 兩種模式只能擇一在 Android 裝置上使用,因為 否則應用程式可以要求高精確度模式 低耗電模式;這個架構就無法同時滿足 應用程式。架構必須一律能滿足所有客戶的需求, 但這就不是選項
- 沒有機制將資料從應用程式傳送到感應器,或 驅動程式。這可確保一個應用程式無法修改 或破壞其他應用程式。
感應器融合
Android 架構為部分複合型提供預設實作方式 感應器。當裝置上有陀螺儀和加速計和磁力儀,但沒有旋轉向量、重力和線性加速感應器時,架構會實作這些感應器,讓應用程式得以順利進行 仍可繼續使用
預設的導入方式無法存取 以及必須在 SoC 上執行,所以不是 準確度也不同於其他實作方式盡可能 因此,裝置製造商應自行定義整合式感應器 (旋轉) 向量、重力和線性加速度,以及多種新型的複合感應器 遊戲旋轉向量),而不要採用這個預設的實作方式。裝置製造商可 也要求感應器晶片供應商實作相關功能。
系統不會維護預設的感應器融合實作,且 可能會導致仰賴此音訊的裝置無法執行 CTS。
深入解析
本節提供的是資訊,提供給維護 Android 開放原始碼計畫 (AOSP) 架構程式碼。與下列項目無關 硬體製造商
JNI
此架構使用與 android.hardware 相關聯且位於 frameworks/base/core/jni/
目錄中的 Java Native Interface (JNI)。這個程式碼會呼叫
取得感應器硬體的存取權
原生架構
原生架構是在 frameworks/native/
中定義,且可提供原生架構
相當於 android.hardware 套件。原生架構會呼叫 Binder IPC Proxy,藉此取得
感應器專屬服務
繫結機制處理序間通訊
Binder IPC Proxy 可協助處理程序邊界的通訊。
HAL
Sensors Hardware 抽象層 (HAL) API 是 硬體驅動程式和 Android 架構由一個 HAL 介面構成 sensor.h 和一種 HAL 實作,我們稱之為 sensor.cpp。
介面由 Android 和 Android 開放原始碼計畫貢獻者定義, 是由裝置製造商提供
感應器 HAL 介面位於 hardware/libhardware/include/hardware
。
詳情請參閱 sensors.h
瞭解詳情。
發布週期
HAL 實作會指定 HAL 介面的版本
實作方式為設定 your_poll_device.common.version
現有 HAL
介面版本是在 sensor.h 中定義,而功能則與那些介面版本
版本。
Android 架構目前支援 1.0 版和 1.3 版,但 1.0 版 即將停止支援。本文件說明瞭版本行為 1.3 套用至所有裝置。進一步瞭解如何升級至 1.3,請參閱 HAL 版本淘汰。
核心驅動程式
感應器驅動程式會與實體裝置互動。在某些情況下,HAL 相同的軟體實體有些情況下 硬體整合商要求感應器晶片製造商 負責撰寫 HAL 實作項目的元件
在所有情況下,HAL 實作項目和核心驅動程式負責 ,Android 並未針對硬體製造商提供建議的方法 寫入。
感應器中樞
裝置的感應器堆疊可視需要加入感應器中樞, 以低功耗執行一些低階運算,而 SoC 可能位於 暫停模式比如,步數計算或感應器融合 這些方塊此外,實作感應器批次作業也很適合 偵測感應器事件的硬體 FIFO詳情請參閱批次處理一文。
注意:如要開發新的 ContextHub 功能, 使用新的感應器或 LED 燈,你也可以使用 Neonkey SensorHub 已連線至 Hikey 或 Hikey960 開發板。
感應器中心的具體化方式取決於架構。有時候 而且有時會隨附於 SoC 搭載的晶片重要事項 感應器中樞應具備足夠的記憶體 因此用不到的能量就能實現 內建 Android 感應器部分感應器中樞內含通用的微控制器 和硬體加速器實現低功耗運算和硬體加速器 低功率感應器
感應器中樞的架構,以及感應器與感應器通訊的方式 和 SoC (I2C 公車、SPI 公車...) 並非由 Android 指定,但應該鎖定 盡可能減少整體耗電量
其中一個似乎對導入作業產生重大影響 簡單來說,從感應器中樞到 SoC 有兩個中斷線: 一項用於喚醒幹擾 (用於喚醒感應器),另一種則用於未喚醒 中斷 (針對非喚醒狀態感應器)。
感應器
這些是進行評估的實際媒體效益評估晶片。在許多情況下 同一個晶片上裝有數個實體感應器例如某些方塊 包括加速計、陀螺儀和磁力儀。(這類晶片通常 稱為 9 軸晶片,每個感應器提供超過 3 軸的資料)。
其中部分方塊還包含一些邏輯,用於執行一般運算,例如 像是動作偵測、步數偵測和 9 軸感應器融合功能
雖然 CDD 電力和準確率需求和建議鎖定的是 這些規定會影響 Android 感應器,而非實體感應器 或選擇實體感應器例如遊戲對於準確性要求 旋轉向量會影響實體行蹤所需的準確率 陀螺儀。裝置製造商的 實體感應器