Google is committed to advancing racial equity for Black communities. See how.
本頁面由 Cloud Translation API 翻譯而成。
Switch to English

ConfigStore HAL

Android 8.0將整體式Android OS分為通用( 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定義的值覆蓋。
  • 地址空間要求。系統屬性在每個進程中佔用相對大量的地址空間。系統屬性以prop_area單位分組,固定大小為128 KB,即使僅訪問其中的單個系統屬性,所有這些屬性都分配給進程地址空間。這可能會在地址空間很寶貴的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進行重大修訂,因為分離的接口不再向後兼容。