在 Android 10 中，ConfigStore HAL 使用建置標誌在vendor分區中儲存配置值， system分區中的服務使用 HIDL 存取這些值（在 Android 9 中也是如此）。但由於記憶體消耗高、使用困難，ConfigStore HAL 已被棄用。
ConfigStore HAL 保留在 AOSP 中以支援舊的供應商分區。在運行 Android 10 或更高版本的裝置上， surfaceflinger首先讀取系統屬性；如果沒有為「SurfaceFlingerProperties.sysprop」中的設定項定義系統屬性，則「surfaceflinger」將回退到 ConfigStore HAL。
Android 8.0 將整體 Android 作業系統分為通用 ( system.img ) 和特定於硬體的 ( vendor.img和odm.img ) 分區。由於此更改，必須從安裝到系統分區的模組中刪除條件編譯，並且此類模組必須在運行時確定係統的配置（並且根據該配置表現不同）。
ConfigStore HAL 提供了一組 API，用於存取用於配置 Android 框架的唯讀配置項目。本頁描述了 ConfigStore HAL 的設計（以及為什麼系統屬性不用於此目的）；本節的其他頁面詳細介紹了HAL 介面、服務實作和客戶端使用，全部以surfaceflinger作為範例。有關 ConfigStore 介面類別的協助，請參閱新增介面類別和項目。
為什麼不使用系統屬性？
我們考慮使用系統屬性，但發現了幾個基本問題，包括：
- 值的長度限制。系統屬性對其值的長度（92 位元組）有嚴格的限制。此外，由於這些限制已作為 C 巨集直接暴露給 Android 應用程序，因此增加長度可能會導致向後相容性問題。
- 沒有類型支援。所有值本質上都是字串，API 只是將字串解析為
int或bool。其他複合資料類型（例如陣列和結構）應由客戶端編碼/解碼（例如，"aaa,bbb,ccc"可以編碼為三個字串的陣列）。 - 覆蓋。由於唯讀系統屬性被實作為一次性寫入屬性，因此想要覆寫 AOSP 定義的唯讀值的供應商/ODM 必須在 AOSP 定義的唯讀值之前匯入自己的唯讀值。反過來，這會導致供應商定義的可重寫值被 AOSP 定義的值覆蓋。
- 解決空間要求。系統屬性在每個行程中佔用相對較大的位址空間。系統屬性按固定大小為 128 KB 的
prop_area單元進行分組，所有這些單元都分配給進程位址空間，即使僅存取其中的單一系統屬性。這可能會在位址空間寶貴的 32 位元裝置上引起問題。
我們試圖在不犧牲相容性的情況下克服這些限制，但仍擔心系統屬性並未設計為支援存取唯讀設定項。最終我們認為系統屬性更適合在整個 Android 系統中即時共享一些動態更新的項目，並且需要一個專門用於存取只讀配置項目的新系統。
ConfigStore HAL 設計
基本設計很簡單：
圖 1. ConfigStore HAL 設計
- 描述 HIDL 中的建置標誌（目前用於條件編譯框架）。
- 供應商和 OEM 透過實施 HAL 服務為建置標誌提供 SoC 和設備特定值。
- 修改框架以使用 HAL 服務在執行時尋找配置項的值。
框架目前引用的配置項目包含在版本化 HIDL 套件 ( android.hardware.configstore@1.0 ) 中。供應商/OEM 透過實作此套件中的介面來向配置項提供值，並且框架在需要取得配置項的值時使用這些介面。
安全考慮
在同一介面中定義的建置標誌受相同 SELinux 策略的影響。如果一個或多個建置標誌應具有不同的 SELinux 策略，則必須將它們分離到另一個介面。這可能需要對android.hardware.configstore package進行重大修改，因為分離的介面不再向後相容。