配置存儲 HAL

透過集合功能整理內容 你可以依據偏好儲存及分類內容。

Android 8.0 將單體 Android 操作系統拆分為通用 ( system.img ) 和特定於硬件的 ( vendor.imgodm.img ) 分區。由於此更改,必須從安裝到系統分區的模塊中刪除條件編譯,並且此類模塊必須在運行時確定係統的配置(並根據該配置表現不同)。

ConfigStore HAL 提供了一組 API,用於訪問用於配置 Android 框架的只讀配置項。本頁描述了 ConfigStore HAL 的設計(以及為什麼不將系統屬性用於此目的);本節的其他頁面詳細介紹了HAL 接口服務實現客戶端使用,均以surfaceflinger為例。有關 ConfigStore 接口類的幫助,請參閱添加接口類和項

為什麼不使用系統屬性?

我們考慮使用系統屬性,但發現了幾個基本問題,包括:

  • 值的長度限制。系統屬性對其值的長度(92 字節)有嚴格的限制。此外,由於這些限制已作為 C 宏直接暴露給 Android 應用程序,因此增加長度可能會導致向後兼容性問題。
  • 沒有類型支持。所有值本質上都是字符串,API 只是將字符串解析為intbool 。其他復合數據類型(例如,數組和結構)應由客戶端編碼/解碼(例如, "aaa,bbb,ccc"可以編碼為三個字符串的數組)。
  • 覆蓋。因為只讀系統屬性是作為一次寫入屬性實現的,所以想要覆蓋 AOSP 定義的只讀值的供應商/ODM 必須在 AOSP 定義的只讀值之前導入他們自己的只讀值。反過來,這會導致供應商定義的可重寫值被 AOSP 定義的值覆蓋。
  • 地址空間要求。系統屬性在每個進程中佔用了相對大量的地址空間。系統屬性以固定大小為 128 KB 的prop_area單元分組,所有這些都分配給進程地址空間,即使其中只有一個系統屬性正在被訪問。這可能會導致地址空間非常寶貴的 32 位設備出現問題。

我們試圖在不犧牲兼容性的情況下克服這些限制,但仍然擔心系統屬性並非旨在支持訪問只讀配置項。最終,我們認為系統屬性更適合在整個 Android 中實時共享一些動態更新的項目,並且需要一個專門用於訪問只讀配置項目的新系統。

ConfigStore HAL 設計

基本設計很簡單:

Configstore HAL 設計

圖 1. ConfigStore HAL 設計

  • 描述 HIDL 中的構建標誌(當前用於有條件地編譯框架)。
  • 供應商和 OEM 通過實現 HAL 服務為構建標誌提供 SoC 和設備特定的值。
  • 修改框架以使用 HAL 服務在運行時查找配置項的值。

框架當前引用的配置項包含在版本化 HIDL 包 ( android.hardware.configstore@1.0 ) 中。供應商/OEM 通過實現此包中的接口為配置項提供值,框架在需要獲取配置項的值時使用這些接口。

安全注意事項

在同一接口中定義的構建標誌受相同的 SELinux 策略影響。如果一個或多個構建標誌應該有不同的 SELinux 策略,它們必須被分離到另一個接口。這可能需要對android.hardware.configstore package進行重大修訂,因為分離的接口不再向後兼容。