智慧型手機包含許多處理器，每個處理器都針對執行不同的任務進行了最佳化。然而，Android 只在一種處理器上運行：應用程式處理器 (AP)。該 AP 經過調整，可以為遊戲等螢幕打開的用例提供出色的性能，但它太耗電了，無法支援始終需要頻繁、短時間突發處理的功能，即使螢幕關閉時也是如此。較小的處理器能夠更有效地處理這些工作負載，完成任務而不會明顯影響電池壽命。然而，這些低功耗處理器中的軟體環境更加有限，而且變化很大，使得跨平台開發變得困難。
Context Hub 執行階段環境 (CHRE) 提供了一個在低功耗處理器上運行應用程式的通用平台，並具有簡單、標準化、嵌入式友好的 API。 CHRE 使設備OEM 及其值得信賴的合作夥伴能夠輕鬆地從AP 卸載處理，以節省電池並改善用戶體驗的各個方面，並啟用一類始終在線、上下文感知的功能，尤其是那些涉及機器應用程序的功能學習環境感知。
關鍵概念
CHRE 是一種軟體環境，小型本機應用程式（稱為nanoapps）在低功耗處理器上執行，並透過通用 CHRE API 與底層系統互動。為了加速 CHRE API 的正確實現，AOSP 中包含了 CHRE 的跨平台參考實作。參考實作包括通用程式碼以及透過一系列平台抽象層 (PAL) 對底層硬體和軟體的抽象化。 Nanoapp 幾乎總是與 Android 中運行的一個或多個客戶端應用程式綁定，這些應用程式透過限制存取的ContextHubManager系統 API 與 CHRE 和 nanoapp 進行互動。
從較高的層面來看，CHRE 的架構與 Android 的整體架構之間存在著相似之處。但是，有一些重要的區別：
- CHRE 僅支援執行以本機程式碼（C 或 C++）開發的 nanoapp；不支援 Java。
- 由於資源限制和安全限制，CHRE 不開放供任意第三方 Android 應用程式使用。只有系統信任的應用程式才能存取它。
CHRE 和感測器集線器的概念之間也存在重要差異。雖然通常使用相同的硬體來實現感測器集線器和 CHRE，但 CHRE 本身並不提供Android 感測器 HAL所需的感測器功能。 CHRE 與 Context Hub HAL 綁定，它充當設備特定感測器框架的客戶端，用於接收感測器數據，而無需涉及 AP。
圖1. CHRE框架架構
上下文中心 HAL
Context Hub 硬體抽象層 (HAL) 是 Android 框架和裝置的 CHRE 實作之間的接口，在hardware/interfaces/contexthub中定義。 Context Hub HAL 定義了 API，Android 框架透過這些 API 發現可用的上下文中心及其 nanoapp，透過訊息傳遞與這些 nanoapp 進行交互，並允許載入和卸載 nanoapp。與 CHRE 參考實作搭配使用的 Context Hub HAL 參考實作位於system/chre/host 。
如果本文檔與 HAL 定義發生衝突，則以 HAL 定義為準。
初始化
當 Android 啟動時， ContextHubService會呼叫getHubs() HAL 函數來確定裝置上是否有可用的上下文集線器。這是一個阻塞的一次性調用，因此它必須快速完成以避免延遲啟動，並且它必須返回準確的結果，因為之後無法引入新的上下文中心。
載入和卸載 nanoapps
上下文中心可以包含一組 nanoapp，這些 nanoapp 包含在裝置映像中並在 CHRE 啟動時載入。這些被稱為預先載入的 nanoapps，並且應該包含在對queryApps()的第一個可能的回應中。
Context Hub HAL 也支援透過loadNanoApp()和unloadNanoApp()函數在執行時動態載入和解除安裝 nanoapp。 Nanoapp 以特定於設備的 CHRE 硬體和軟體實現的二進位格式提供給 HAL。
如果載入 nanoapp 的實作涉及將其寫入非揮發性記憶體（例如連接到執行 CHRE 的處理器的快閃記憶體），則 CHRE 實作必須始終在這些動態 nanoapp 處於停用狀態的情況下啟動。這表示在透過 HAL 接收到enableNanoapp()請求之前，nanoapp 的任何程式碼都不會執行。預先載入的 nanoapps 可以在啟用狀態下初始化。
上下文中心重新啟動
雖然 CHRE 預計不會在正常操作過程中重新啟動，但可能有必要從意外情況（例如嘗試存取未映射的記憶體位址）中恢復。在這些情況下，CHRE 獨立於 Android 重新啟動。 HAL 透過RESTARTED事件通知 Android，只有在 CHRE 重新初始化到可以接受新請求（例如queryApps()後，它才必須發送該事件。
CHRE系統概述
CHRE 是圍繞事件驅動架構設計的，其中主要計算單元是傳遞到 nanoapp 事件處理入口點的事件。雖然 CHRE 框架可以是多執行緒的，但給定的 nanoapp 永遠不會從多個執行緒並行執行。 CHRE 框架透過三個 nanoapp 入口點（ nanoappStart() 、 nanoappHandleEvent()和nanoappEnd() ）之一或透過先前 CHRE API 呼叫中提供的回調與給定的 nanoapp 進行交互，並且 nanoapp 與 CHRE 框架進行交互，並且透過CHRE API 存取底層系統。 CHRE API 提供了一組基本功能以及用於存取上下文訊號的設施，包括感測器、GNSS、Wi-Fi、WWAN 和音頻，並且可以透過其他特定於供應商的功能進行擴展，以供特定於供應商的nanoapp 使用。
建構系統
雖然 Context Hub HAL 和其他必要的 AP 端元件是與 Android 一起建置的，但在 CHRE 中運行的程式碼可能具有與 Android 建置系統不相容的要求，例如需要專門的工具鏈。因此，AOSP 中的 CHRE 專案提供了一個基於 GNU Make 的簡化建置系統，用於將 nanoapp 和 CHRE 框架編譯為可與系統整合的程式庫。添加對 CHRE 支援的設備製造商應將其目標設備的建置系統支援整合到 AOSP 中。
CHRE API 是按照 C99 語言標準編寫的，參考實作使用 C++11 的受限子集，適合資源有限的應用程式。
CHRE API
CHRE API 是 C 頭檔的集合，用於定義 nanoapp 和系統之間的軟體介面。它旨在使 nanoapps 程式碼在所有支援 CHRE 的裝置上相容，這意味著 nanoapp 的原始程式碼無需修改即可支援新的裝置類型，但可能需要專門針對目標裝置的處理器進行重新編譯指令集或應用程式二進位介面(ABI)。 CHRE 架構和 API 設計還確保 NanoApp 跨不同版本的 CHRE API 進行二進位相容，這意味著 NanoApp 不需要重新編譯即可在實現不同版本的 CHRE API 的系統上執行nanoapp 編譯所針對的目標 API。換句話說，如果 nanoapp 二進位檔案在支援 CHRE API v1.3 的裝置上運行，並且該裝置升級為支援 CHRE API v1.4，則相同的 nanoapp 二進位檔案將繼續運行。同樣，nanoapp 可以在 CHRE API v1.2 上運行，並且可以在運行時確定它是否需要 API v1.3 的功能來實現其功能，或者它是否可以運行，可能會導致功能正常降級。
新版本的 CHRE API 與 Android 一起發布，但由於 CHRE 實作是供應商實作的一部分，因此裝置上支援的 CHRE API 版本不一定連結到 Android 版本。
版本總結
與Android HIDL 版本控制方案一樣，CHRE API 遵循語意版本控制。主要版本表示二進位相容性，而次要版本在引入向後相容功能時會增加。 CHRE API 包含原始碼註釋，用於識別哪個版本引入了函數或參數，例如@since v1.1 。
CHRE 實作還透過chreGetVersion()公開特定於平台的補丁版本，該版本指示實作中何時進行錯誤修復或次要更新。
版本1.0（安卓7）
包括對感測器的支援以及核心 nanoapp 功能，例如事件和計時器。
版本1.1（安卓8）
透過 GNSS 位置和原始測量、Wi-Fi 掃描和蜂窩網路資訊引入定位功能，以及實現 nanoapp 到 nanoapp 通訊的一般改進以及其他改進。
版本1.2（安卓9）
新增了對來自低功耗麥克風的數據、Wi-Fi RTT 測距、AP 喚醒/睡眠通知以及其他改進的支援。
版本1.3（安卓10）
增強與感測器校準資料相關的功能，增加對按需刷新批量感測器資料的支持，定義步進偵測感測器類型，並透過附加精度欄位擴展 GNSS 位置事件。
版本1.4（安卓11）
增加了對 5G 小區資訊、nanoapp 調試轉儲和其他改進的支援。
強制系統功能
雖然上下文訊號源（例如感測器）被分類為選用功能區域，但所有 CHRE 實作都需要一些核心功能。這包括核心系統 API，例如用於設定計時器、向應用程式處理器上的客戶端發送和接收訊息、日誌記錄等的 API。有關完整詳細信息，請參閱API 標頭。
除了 CHRE API 中編碼的核心系統功能之外，還有在 Context Hub HAL 層級指定的強制性 CHRE 系統級功能。其中最重要的是動態載入和卸載 nanoapp 的能力。
C/C++標準函式庫
為了最大限度地減少記憶體使用和系統複雜性，CHRE 實作需要僅支援標準 C 和 C++ 函式庫以及需要執行時間支援的語言功能的子集。遵循這些原則，某些功能由於其記憶體和/或廣泛的作業系統級依賴性而被明確排除，而其他功能則因為它們被更合適的特定於 CHRE 的 API 所取代。雖然並不是詳盡的列表，但以下功能並不打算提供給 nanoapps：
- 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。即使平台不支援給定的 API 集，引用這些函數的 nanoapp 也必須能夠建置和載入。
感應器
CHRE API 提供了從加速度計、陀螺儀、磁力計、環境光感測器和接近度感測器請求資料的能力。這些 API 旨在提供類似於 Android 感測器 API 的功能集，包括支援批次感測器樣本以降低功耗。與在 AP 上運行相比，在 CHRE 中處理感測器資料可以實現更低的功耗和更低的運動訊號延遲處理。
全球導航衛星系統
CHRE 提供 API，用於從全球導航衛星系統 (GNSS)（包括 GPS 和其他衛星星座）請求位置資料。這包括定期定位的請求以及原始測量數據，儘管兩者都是獨立的功能。由於 CHRE 具有到 GNSS 子系統的直接鏈路，因此與基於 AP 的 GNSS 請求相比，功耗有所降低，因為 AP 可以在定位會話的整個生命週期中保持睡眠狀態。
無線上網
CHRE 提供與 Wi-Fi 晶片互動的能力，主要用於定位目的。雖然 GNSS 在室外位置效果良好，但 Wi-Fi 掃描的結果可以在室內和已開發地區提供準確的位置資訊。除了避免喚醒 AP 進行掃描的成本之外，CHRE 還可以偵聽 Wi-Fi 韌體執行的 Wi-Fi 掃描結果以進行連接，而出於連接目的，這些掃描結果通常不會傳送到 AP。利用上下文連線掃描有助於減少執行的 Wi-Fi 掃描總數，從而節省電力。
CHRE API v1.1 中新增了對 Wi-Fi 的支持，包括監控掃描結果和按需觸發掃描的功能。這些功能在 v1.2 中得到了擴展，能夠對支援該功能的存取點執行往返時間 (RTT)測量，從而實現準確的相對位置確定。
廣域網路
CHRE API 能夠檢索服務小區及其鄰居的小區標識訊息，這通常用於粗粒度定位目的。
聲音的
CHRE 可以處理來自低功耗麥克風的批量音訊數據，該麥克風通常利用用於實現 SoundTrigger HAL 的硬體。在 CHRE 中處理音訊資料可使其與其他資料（例如運動感測器）融合。
參考實現
CHRE 框架的參考程式碼包含在system/chre專案的 AOSP 中，以 C++11 實作。雖然不是嚴格要求，但建議所有 CHRE 實作都基於此程式碼庫，以幫助確保一致性並加速新功能的採用。該程式碼可以被視為 Android 核心框架的類似物，因為它是應用程式使用的 API 的開源實現，充當相容性的基線和標準。雖然可以使用特定於供應商的功能對其進行自訂和擴展，但建議保持公共代碼盡可能接近參考。與 Android 的 HAL 類似，CHRE 參考實作使用各種平台抽象，使其能夠適應任何滿足最低要求的裝置。
有關技術詳細資訊和移植指南，請參閱system/chre專案中包含的自述文件。