配置存儲 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 定義的值覆蓋。
  • 地址空間要求。系統屬性在每個進程中佔用相對大量的地址空間。系統性能列於分組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作為分離的接口已經不再向後兼容。