在 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"可編碼為三個字串的陣列)。 - 覆寫。由於唯讀系統屬性是以一次寫入的屬性實作，因此供應商/ODM 如要覆寫 AOSP 定義的唯讀值，必須先匯入自己的唯讀值，再匯入 AOSP 定義的唯讀值。這會導致供應商定義的可覆寫值，遭到 AOSP 定義的值覆寫。
- 位址空間需求。系統屬性會在每個程序中佔用相對大量的位址空間。系統資源會以
prop_area單位進行分組，且固定大小為 128 KB，即使只存取其中的單一系統資源，所有資源都會分配至程序位址空間。這可能會導致位址空間有限的 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。