智慧型手機內含多個處理器，每個處理器都經過最佳化，可執行不同工作。不過，Android 只會在一個處理器上執行：應用程式處理器 (AP)。AP 經過調整，可為遊戲等螢幕開啟使用情境提供優異效能，但耗電量過高，無法支援需要頻繁、短時間處理作業的功能，即使螢幕關閉也一樣。較小的處理器則能更有效率地處理這些工作負載，完成工作時不會明顯影響電池續航力。不過，這些低功耗處理器的軟體環境較為受限，且差異可能很大，因此難以進行跨平台開發。
情境感知中樞執行階段環境 (CHRE) 提供通用平台，可透過簡單、標準化的嵌入式友善 API，在低功耗處理器上執行應用程式。裝置原始設備製造商 (OEM) 和信任的合作夥伴可以輕鬆使用 CHRE，將處理作業從 AP 卸載，藉此節省電量、改善使用者體驗的各個層面，並啟用一類常時運作、情境感知功能，尤其是涉及將機器學習應用於環境感應的功能。
核心概念
CHRE 是軟體環境，可讓稱為「微型應用程式」的小型原生應用程式在低功耗處理器上執行，並透過常見的 CHRE API 與基礎系統互動。為加快正確實作 CHRE API，AOSP 內含 CHRE 的跨平台參考實作項目。參考實作包含常見的程式碼和抽象化，可透過一系列平台抽象層 (PAL) 存取基礎硬體和軟體。微型應用程式幾乎一律會與一或多個在 Android 中執行的用戶端應用程式建立關聯，這些應用程式會透過受限存取權 ContextHubManager 系統 API 與 CHRE 和微型應用程式互動。
從高層次來看，CHRE 架構與整個 Android 架構有相似之處。不過，兩者之間有幾個重要差異：
- CHRE 僅支援以原生程式碼 (C 或 C++) 開發的微型應用程式，不支援 Java。
- 由於資源限制和安全性限制，CHRE 不開放任意第三方 Android 應用程式使用。只有系統信任的應用程式可以存取。
此外，CHRE 的概念與感應器中樞之間也有重要差異。雖然感應器中樞和 CHRE 通常會使用相同的硬體實作，但 CHRE 本身不會提供 Android Sensors HAL 所需的感應器功能。CHRE 與 Context Hub HAL 相關聯，可做為裝置專屬感應器架構的用戶端，接收感應器資料，不必涉及 AP。
圖 1. CHRE 架構
情境感知中樞 HAL
Context Hub 硬體抽象層 (HAL) 是 Android 架構與裝置 CHRE 實作之間的介面，定義於 hardware/interfaces/contexthub。Android 架構會透過 Context Hub HAL 定義的 API 探索可用的情境中樞和微型應用程式、透過訊息傳遞與這些微型應用程式互動，以及載入和卸載微型應用程式。您可以在 system/chre/host 找到與 CHRE 參考實作項目搭配使用的 Context Hub HAL 參考實作項目。
如果本文件與 HAL 定義有所牴觸，應以 HAL 定義為準。
初始化
Android 啟動時，ContextHubService 會叫用 getHubs() HAL 函式，判斷裝置上是否有任何情境中樞。這是會封鎖的一次性呼叫，因此必須快速完成，以免延遲啟動，且必須傳回準確結果，因為之後無法導入新的情境中樞。
載入及卸載微型應用程式
情境中樞可以包含裝置映像檔中的一組微型應用程式，並在 CHRE 啟動時載入。這些稱為預先載入的微型應用程式，應包含在 queryApps() 的第一個可能回應中。
Context Hub HAL 也支援在執行階段透過 loadNanoApp() 和 unloadNanoApp() 函式，動態載入及卸載 nanoapp。系統會以二進位格式將微型應用程式提供給 HAL，這種格式專為裝置的 CHRE 硬體和軟體實作項目而設計。
如果載入微型應用程式的實作方式是將其寫入非揮發性記憶體 (例如連接至執行 CHRE 的處理器的快閃儲存空間)，則 CHRE 實作方式一律必須以停用狀態啟動這些動態微型應用程式。也就是說，在透過 HAL 收到 enableNanoapp() 要求之前，系統不會執行任何微型應用程式的程式碼。預先載入的微應用程式可以在啟用狀態下初始化。
情境感知中樞重新啟動
雖然 CHRE 在正常運作期間不會重新啟動，但如果發生嘗試存取未對應的記憶體位址等非預期狀況，可能就需要重新啟動。在這種情況下，CHRE 會獨立於 Android 重新啟動。HAL 會透過 RESTARTED 事件將這項資訊通知 Android，且必須在 CHRE 重新初始化至可接受新要求 (例如 queryApps()) 的程度後，才傳送這項事件。
CHRE 系統總覽
CHRE 採用事件導向架構設計，主要運算單元是傳遞至微型應用程式事件處理進入點的事件。雖然 CHRE 架構可以採用多執行緒，但系統絕不會從多個執行緒平行執行特定微型應用程式。CHRE 架構會透過三個 Nanoapp 進入點 (nanoappStart()、nanoappHandleEvent() 和 nanoappEnd()) 之一，或透過先前 CHRE API 呼叫中提供的回呼與特定 Nanoapp 互動，而 Nanoapp 則會透過 CHRE API 與 CHRE 架構和基礎系統互動。CHRE API 提供一系列基本功能，以及存取情境信號的設施，包括感應器、GNSS、Wi-Fi、WWAN 和音訊，並可透過額外的廠商專屬功能擴充，供廠商專屬的微型應用程式使用。
建構系統
雖然 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 與系統之間的軟體介面。這項功能可讓微型應用程式程式碼與支援 CHRE 的所有裝置相容，也就是說，微型應用程式的原始碼不需要修改，就能支援新的裝置類型，但可能需要針對目標裝置的處理器指令集或應用程式二進位檔介面 (ABI) 重新編譯。CHRE 架構和 API 設計也確保 Nanoapp 在不同版本的 CHRE API 之間具有二進位檔相容性，這表示 Nanoapp 不必重新編譯，即可在實作不同版本 CHRE API 的系統上執行 (與 Nanoapp 編譯時所用的目標 API 相比)。換句話說，如果裝置支援 CHRE API v1.3，且該裝置升級後支援 CHRE API v1.4，則在該裝置上執行的相同 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 版 (Android 7)
包括感應器和核心微型應用程式功能 (例如事件和計時器) 的支援。
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 蜂巢式網路資訊、奈米應用程式偵錯傾印等支援功能，並進行其他改良。
必要系統功能
雖然感應器等脈絡信號來源會歸類為選用功能領域，但所有 CHRE 實作項目都必須具備幾項核心功能。包括核心系統 API，例如設定計時器、在應用程式處理器上傳送及接收訊息給用戶端、記錄等。詳情請參閱「API 標頭」。
除了 CHRE API 中編碼的核心系統功能外，Context Hub HAL 層級也指定了強制執行的 CHRE 系統層級功能。其中最重要的是動態載入和卸載微型應用程式的功能。
C/C++ 標準程式庫
為盡量減少記憶體用量和系統複雜度，CHRE 實作項目只需要支援標準 C 和 C++ 程式庫的子集，以及需要執行階段支援的語言功能。基於這些原則，部分功能因記憶體和廣泛的 OS 層級依附元件而明確排除，其他功能則因有更合適的 CHRE 專屬 API 取代而排除。以下僅為部分參考示例，這些功能不適用於微型應用程式：
- 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 - C99 或 C++11 語言標準未納入的 POSIX 和其他程式庫
在許多情況下，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 API 函式和核准的標準程式庫函式，否則不會視為可跨 CHRE 實作項目移植。
選用功能
為推廣硬體和軟體，CHRE API 分為多個功能領域，從 API 的角度來看，這些領域都是選用項目。雖然這些功能可能不是支援相容 CHRE 實作項目所需的項目，但可能是支援特定微型應用程式的必要條件。即使平台不支援特定 API 集，參照這些函式的微型應用程式也必須能夠建構及載入。
感應器
CHRE API 可讓您要求感應器資料，包括加速計、陀螺儀、磁力計、環境光感應器和近接感應器。這些 API 的功能集與 Android Sensors API 類似，包括支援批次處理感應器樣本，以減少耗電量。在 CHRE 內處理感應器資料，與在 AP 上執行作業相比，可大幅降低耗電量和動作訊號處理延遲時間。
GNSS
CHRE 提供 API，可從全球導航衛星系統 (GNSS) (包括 GPS 和其他衛星星群) 要求位置資料。這包括定期修正位置的要求，以及原始測量資料，但兩者都是獨立功能。由於 CHRE 直接連結至 GNSS 子系統，因此與 AP 型 GNSS 要求相比，電力消耗較低，因為 AP 在位置資訊工作階段的整個生命週期內都能保持休眠狀態。
Wi-Fi
CHRE 可與 Wi-Fi 晶片互動，主要用於定位。GNSS 適用於室外位置，但 Wi-Fi 掃描結果可提供室內和已開發區域的準確位置資訊。除了避免因掃描而喚醒 AP 產生的費用，CHRE 還可以監聽 Wi-Fi 韌體為連線目的執行的 Wi-Fi 掃描結果，這些結果通常不會傳送至 AP，以免耗電。運用連線掃描功能取得情境資訊，有助於減少 Wi-Fi 掃描總次數，進而節省電力。
CHRE API v1.1 新增了 Wi-Fi 支援功能，包括監控掃描結果及視需要觸發掃描。v1.2 擴充了這些功能，可針對支援這項功能的存取點執行封包往返時間 (RTT) 測量，進而準確判斷相對位置。
WWAN
CHRE API 可擷取服務基地台及其鄰近基地台的手機識別資訊，通常用於概略位置用途。
音訊
CHRE 可以處理低功耗麥克風的音訊資料批次，這通常會運用用於實作 SoundTrigger HAL 的硬體。在 CHRE 中處理音訊資料，可與動作感應器等其他資料融合。
參考實作
AOSP 的 system/chre 專案中包含 CHRE 架構的參考程式碼，以 C++11 實作。雖然並非必要，但建議所有 CHRE 實作項目都以這個程式碼集為基礎，確保一致性並加速採用新功能。這段程式碼可視為 Android 核心架構的類似項目，因為它是應用程式所用 API 的開放原始碼實作項目，可做為相容性的基準和標準。雖然您可以透過供應商專屬功能自訂及擴充這項程式碼，但建議盡可能維持與參考程式碼相近的通用程式碼。與 Android 的 HAL 類似，CHRE 參考實作項目會使用各種平台抽象化，以便適應符合最低需求的任何裝置。
如需技術詳細資料和移植指南，請參閱 system/chre 專案隨附的 README。