智慧型手機內含多種處理器，每款手機都經過最佳化調整，能發揮最佳效能 不同的任務不過，Android 只會在單一處理器上運作，也就是應用程式 以及 AP。AP 為螢幕開啟功能帶來卓越效能 但由於遊戲體驗特別複雜 即使螢幕處於關閉狀態，還是需要頻繁迅速處理資料 已關閉。較小的處理器能更有效率地處理這些工作負載 在不影響電池續航力的情況下完成工作。不過， 這些低功耗處理器的軟體環境 較為有限， 差異極大，難以跨平台開發。
Context Hub Runtime Environment (CHRE) 提供通用的執行平台 搭載簡單標準化的 方便內嵌的 APICHRE 可讓裝置原始設備製造商 (OEM) 和值得信賴的裝置輕鬆使用 合作夥伴將 AP 的資料處理功能卸載，以節省電力， 提升使用者體驗和「持續待機」類別 內容感知功能，尤其是涉及應用程式 採用機器學習技術和環境感應
核心概念
CHRE 是小型原生應用程式的軟體環境，稱為
nanoapps 透過低功耗處理器執行，並與
透過通用 CHRE API 管理系統為了加速正確導入
CHRE API 已納入 CHRE 的跨平台參照實作
Android 開放原始碼計畫。參考實作包括
透過一系列的平台抽象層，建構基礎軟硬體
(PAL)。Nanoapp 幾乎會與執行中的一或多個用戶端應用程式
Android，可透過受限制的存取方式與 CHRE 和 nano 應用程式互動
ContextHubManager敬上
以及系統 API
整體來說，平行可分為 CHRE 和 CHRE 架構 全方位的 Android 手機不過，還是有一些重要的差異：
- CHRE 僅支援執行以原生程式碼 (C 或 C++)；不支援 Java。
- 基於資源限制和安全性限制，CHRE 未開啟 供任意第三方 Android 應用程式使用只有系統信任的應用程式 存取權。
另外，CHRE 的概念也有重要的差別 以及感應器中樞雖然以相同硬體執行 感應器中樞和 CHRE 引擎並未提供感應器功能 Android 感應器所需 HAL。CHRE 和 情境中樞 HAL，並做為裝置專屬感應器的用戶端 處理感應器資料，而不需要使用 AP。
圖 1. CHRE 架構架構
情境感知中樞 HAL
Context Hub 硬體抽象層 (HAL) 是
Android 架構和裝置的 CHRE 實作，定義於
hardware/interfaces/contexthub。
情境中心 HAL 會定義 Android 架構是透過哪些 API 取得
探索可用的內容中心和奈米應用程式
透過訊息傳遞 nanoapp，並讓 nano 應用程式能夠載入
卸載。情境中心 HAL 的參考實作，可與
如需 CHRE 的參考實作，請前往
system/chre/host。
如果本說明文件與 HAL 定義發生衝突，則 以 HAL 定義為優先。
初始化
當 Android 啟動時，
ContextHubService
叫用 getHubs() HAL 函式，以判斷是否有任何結構定義中樞
可用的在裝置上此為一次性呼叫，因此必須完成
可避免延遲啟動，而且必須根據新的
之後也無法導入內容中心。
載入並卸載 nano 應用程式
情境感知中樞可能包含裝置隨附的一組奈米應用程式
並會在 CHRE 啟動時載入。稱為預先載入的奈米應用程式
，並應加入至 queryApps() 的第一個可能回應中。
Context Hub HAL 也支援動態載入及卸載奈米應用程式，位於
透過 loadNanoApp() 和 unloadNanoApp() 函式執行。奈米應用程式
是以 CHRE 硬體專用的二進位格式提供給 HAL
裝置軟體實作。
如果實作 nanoapp 的實作作業需要將其寫入非揮發性
例如連接至執行 CHRE 的處理器的快閃儲存空間
CHRE 實作一律必須使用這些動態 nanoapp 來啟動，
已停用狀態。這表示在
透過 HAL 收到 enableNanoapp() 要求。預先載入的奈米應用程式
初始化為啟用狀態
情境中心重新啟動
雖然在正常操作過程中不會重新啟動 CHRE，但
可能就需要從非預期的狀況中復原，例如
存取未對應的記憶體位址。在這種情況下，CHRE 重新啟動
以及獨立於 Android 之外的版本HAL 會透過
RESTARTED 事件，只有在重新初始化 CHRE 後才能傳送此事件
可接受新的要求的點，例如 queryApps()。
CHRE 系統總覽
CHRE 的設計以事件導向架構為主，在這種架構中，主要單位
是傳遞至 nanoapp 事件處理進入點的事件雖然
CHRE 架構可以多執行緒，指定 nanoapp 時一律不會
以便同時處理多個執行緒CHRE 架構會與指定的 nanoapp 互動
經由三個 nanoapp 進入點 (nanoappStart()、
nanoappHandleEvent() 和 nanoappEnd()) 或
先前的 CHRE API 呼叫，nanoapp 會與 CHRE 架構和
第一個是 CHRE API 的基礎系統CHRE API 提供了一組
以及存取比對內容訊號的設施，包括
感應器、GNSS、Wi-Fi、WWAN 和音訊，還可使用額外
供應商專屬功能，由供應商專屬的 nanoapp 使用。
建構系統
建立 Context Hub HAL 和其他必要的 AP 端元件時 除了 Android 以外，在 CHRE 內執行的程式碼也有許多要求 與 Android 建構系統不相容，例如需要 工具鍊。因此，Android 開放原始碼計畫中的 CHRE 專案為簡化版本。 系統為基礎的 GNU Make 可編譯 nanoapps 及 CHRE 轉換為可與系統整合的程式庫裝置 製造商若新增對 CHRE 的支援，則應整合建構系統支援， 並將目標裝置上傳到 Android 開放原始碼計畫
CHRE API 已寫入 C99 語言標準， 實作會使用 C++11 受限子集，適用於資源受限 應用程式。
CHRE API
CHRE API 是定義軟體的 C 標頭檔案集合 nanoapp 和系統之間的介面專為打造奈米應用程式而設計 程式碼與所有支援 CHRE 的裝置都相容，因此 您不必修改 nanoapp 的原始碼即可支援新裝置 但可能需要針對目標裝置的 處理器指令集或應用程式二進位檔介面 (ABI)。CHRE 架構和 API 設計也確保 nano 應用程式與二進位檔相容 因此 nanoapp 就需要重新編譯，才能在實作不同版本的系統上 將 CHRE API 與編譯 nanoapp 的目標 API 進行比較。 換句話說，如果在支援 CHRE API 的裝置上執行 nanoapp 二進位檔， 第 1.3 版，該裝置已完成升級，可支援 CHRE API 1.4 版 (相同的 nanoapp) 二進位檔會繼續運作同樣地，nanoapp 可在 CHRE API 1.2 版上執行， 且可在執行階段判斷是否需要從 API v1.3 到 以及是否可以運作 功能降級
新版 CHRE API 會和 Android 一起發布，但以 CHRE 形式發布。 這是 供應商實作， 裝置支援的 CHRE API 版本不一定會連結至 Android 版本。
版本摘要
例如
Android HIDL 版本管理架構
CHRE API 遵循語意版本管理。
主要版本表示二進位檔相容性，而子版本則指出
在推出回溯相容的功能時增加。CHRE API
包含原始碼註解，可辨識哪個版本導入了函式
或參數，例如 @since v1.1
CHRE 實作也會透過
chreGetVersion()，表示會在何時修正錯誤或進行小幅更新
相關知識
版本 1.0 (Android 7)
包括對感應器的支援，以及 nanoapp 核心功能，例如事件和 計時器。
版本 1.1 (Android 8)
透過 GNSS 位置和原始測量值導入定位功能 Wi-Fi 掃描和行動網路資訊，以及一般修正項目 實現 nanoapp 對 nanoapp 的通訊以及其他改進項目。
版本 1.2 (Android 9)
新增低功率麥克風、Wi-Fi RTT 範圍、AP 提供的資料 喚醒和睡眠通知等功能，以及進行其他改善。
版本 1.3 (Android 10)
強化與感應器校正資料相關的功能，並支援 隨需清除批次感應器資料、定義步數偵測感應器類型，以及 以額外的精確度欄位擴充 GNSS 位置事件。
版本 1.4 (Android 11)
新增 5G 儲存格資訊、nanoapp 偵錯傾印支援
必要系統功能
感應器等比對內容訊號來源已歸類為選用 所有 CHRE 都需要一些核心功能 。這包括核心系統 API，例如用於設定的 API 計時器、傳送和接收訊息給應用程式處理器 記錄等如需完整詳細資料，請參閱 API 標頭。
除了 CHRE API 編纂的核心系統功能外， 在情境中樞 HAL 層級指定的強制 CHRE 系統層級功能。 其中最重要的是動態載入與卸載元件 nanoapps
C/C++ 標準程式庫
為了盡可能降低記憶體用量和系統複雜性，CHRE 實作項目為 僅支援部分標準 C 和 C++ 程式庫 要求執行階段支援的語言功能只要遵守這些原則 功能因記憶體容量和豐富的 OS 級別而明確排除 依附元件等等 CHRE 專屬 API。以下清單僅列舉部分示例，但並未涵蓋所有情況 功能不適用於 nano 應用程式：
- C++ 例外狀況和執行階段類型資訊 (RTTI)
- 支援標準程式庫多執行緒功能，包括 C++11 標頭
<thread>、<mutex>、<atomic>、<future> - C 和 C++ 標準輸入/輸出程式庫
- C++ 標準範本程式庫 (STL)
- C++ 標準規則運算式程式庫
- 透過標準函式 (例如
malloc、calloc、realloc、free、operator new) 和其他標準 程式庫函式 (例如目前採用的動態分配機制)std::unique_ptr - 本地化和萬國碼 (Unicode) 字元支援
- 日期和時間資料庫
- 修改正常程式流程的函式，包括
<setjmp.h><signal.h>、abort、std::terminate - 存取主機環境，包括
system、getenv - POSIX 和其他未納入 C99 或 C++11 語言中的程式庫 標準
在許多情況下，CHRE API 函式會提供同等功能
和公用程式庫舉例來說，chreLog 可用於偵錯記錄
針對 Android Logcat 系統指定
較傳統的程式
使用 printf 或 std::cout。
相對的，應用程式必須具備一些標準程式庫功能。取決於 透過靜態資料庫公開發布這些內容 安裝在 nanoapp 二進位檔中，或是 nanoapp 與系統之間的動態連結。這個 包括但不限於：
- 字串和陣列公用程式：
memcmp、memcpy、memmove、memset、strlen 數學程式庫：常用的單精度浮點函式：
- 基本作業：
ceilf、fabsf、floorf、fmaxf、fminf、fmodf、roundf、lroundf、remainderf - 指數和冪函式：
expf、log2f、powf、sqrtf - 三角與雙曲函式：
sinf、cosf、tanf、asinf、acosf、atan2f、tanhf
- 基本作業：
雖然有些基礎平台支援額外功能，但 nanoapp 不會將 CHRE 實作項目限制為可攜性 與 CHRE API 函式和經核准的標準程式庫的外部依附元件 函式。
選用功能
為了推廣軟硬體，CHRE API 分成多個功能領域 從 API 的角度來看，這屬於選用性質。雖然這些功能 可能不需要支援相容的 CHRE 實作項目， 支援特定的 nanoapp即使平台不支援 參照這些函式的奈米應用程式必須能 再載入網頁
感應器
CHRE API 能夠要求來自以下感應器的資料： 加速計、陀螺儀、磁力儀、環境光度感應器和鄰近區域。 這些 API 旨在提供與 Android 感應器類似的功能集 API，包括支援批次處理感應器範例，以降低耗電量。 在 CHRE 內處理感應器資料，大幅降低耗電量和延遲時間 與在 AP 上執行的動作信號比較得出。
GNSS
CHRE 提供 API，用於要求從全域導航要求位置資料 衛星系統 (GNSS)，包括 GPS 和其他衛星衛星定位系統。這個 包含定期位置修正的要求，以及原始測量資料。 但這兩者各自獨立CHRE 具有直接連結至 GNSS 的連結 子系統的用電比 AP 型 GNSS 要求少，因為 AP 在地點工作階段的整個生命週期中，都可能會睡著。
Wi-Fi
CHRE 能夠與 Wi-Fi 晶片互動，主要是 定位。雖然 GNSS 適合在戶外拍攝，但 Wi-Fi 掃描功能可提供準確的位置資訊，偵測已開發的室內裝置 在這些區塊建構 AI 應用項目時 必須特別小心除了能降低喚醒 AP 進行掃描的費用外，CHRE 也可以 監聽 Wi-Fi 掃描的 Wi-Fi 結果 基於連線目的的韌體，通常不會傳送到 AP 。在背景資訊充足的情況下使用連線掃描功能， 以減少掃描的 Wi-Fi 總次數，節省電力。
CHRE API 1.1 版已新增 Wi-Fi 支援，包括監控裝置 掃描結果並視需求觸發掃描作業我們在 1.2 版，且能執行 封包往返時間 (RTT) 針對支援這項功能的存取點進行測量，進而 準確的相對排名
WAN
CHRE API 可用來擷取儲存格識別資訊 ，這通常用於 概略位置。
音訊
CHRE 能透過低耗電麥克風處理一批音訊資料， 通常會利用用來實作 SoundTrigger HAL 的硬體。處理中 CHRE 中的音訊資料能夠與運動等其他資料結合 感應器。
參照實作
CHRE 架構的參考程式碼已納入 Android 開放原始碼計畫的 system/chre 中
在 C++11 中實作雖然不強制要求
根據這個程式碼集建構所有 CHRE 實作項目，
並加速採用新功能。您可以查看這個程式碼
可說是 Android 核心架構的
應用程式所用 API 的實作，做為基準和標準
相容性。雖然可根據供應商需求自訂及擴大應用範圍
功能，建議將通用程式碼維持在最靠近
參考。與 Android 的 HAL 類似，CHRE 參考資料
運用各種平台抽象化，以適應
任何符合基本規格需求的裝置
如需技術詳細資料和攜碼轉移指南，請參閱
讀我資訊
包含在 system/chre 專案中。