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進行重大修訂，因為分離的接口不再向後兼容。