感應器堆疊

下圖代表 Android 感應器堆疊。每個元件 只能與位於其上方和下方的元件通訊 如果有感應器中樞,感應器就會略過該感應器中樞。透過 向下流至感應器,而資料從感應器流到前方 應用程式。

Android 感應器堆疊的層和擁有者

圖 1. Android 感應器堆疊的層及其各自擁有者

SDK

應用程式可透過 Sensors SDK (軟體開發套件) API 存取感應器。SDK 包含用來列出可用感應器及註冊至 感應器。

註冊感應器時,應用程式會指定偏好的取樣 頻率和延遲時間需求

  • 舉例來說,應用程式可能會註冊預設加速計 以 100Hz 要求的事件要求事件,並允許 1 秒記錄事件 適合延遲時間僅毫秒的 即時高處理量應用程式
  • 應用程式會以下列速率接收加速計的事件 100Hz 以上,且可能會延遲最多 1 秒。

如要進一步瞭解 SDK,請參閱開發人員說明文件

架構

此架構負責將多個應用程式連結至 HAL。HAL 本身為單一用戶端。如未在 因此只有單一應用程式可以存取任何感應器 時間。

  • 第一個應用程式註冊至感應器時,架構會傳送一個要求 轉到 HAL 啟動感應器
  • 當其他應用程式註冊到相同的感應器時,架構就會 以符合每個應用程式的需求 設為 HAL
    • 取樣頻率會是要求的取樣頻率上限,也就是 應用程式收到事件的頻率,會比其接收頻率高 。
    • 報表延遲時間最長為最低門檻。如果有應用程式要求存取 回報延遲時間最長為 0 的感應器,那麼所有應用程式都會收到 這個感應器在連續模式下發出的事件 (即使有人要求存取感應器) 且報表延遲時間最長為零。詳情請參閱批次處理一文。
  • 當最後一個應用程式註冊到其中一個感應器時, 框架會傳送要求給 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 感應器,而非實體感應器 或選擇實體感應器例如遊戲對於準確性要求 旋轉向量會影響實體行蹤所需的準確率 陀螺儀。裝置製造商的 實體感應器