Android框架版本具有多個框架兼容性矩陣(FCM)(每個可升級的Target FCM版本一個),它們定義了框架可以使用的功能以及Target FCM版本要求。作為FCM生命週期的一部分,Android會棄用並刪除HIDL HAL,然後修改FCM文件以反映HAL版本的狀態。
為了在其自身的生態系統中啟用僅框架的OTA,擴展供應商界面的合作夥伴也應使用相同的方法棄用和刪除HIDL HAL。
術語
框架兼容性矩陣(FCM) | 一個XML文件,該文件指定對符合標準的供應商實現的框架要求。對兼容性列表進行了版本控制,並為每個框架版本凍結了一個新版本。每個框架版本都包含多個FCM。 |
---|---|
平台FCM版本( SF ) | 框架版本中所有FCM版本的集合。該框架可以與滿足這些FCM之一的任何供應商實施一起使用。 |
FCM版本(F) | 框架版本中所有FCM中的最高版本。 |
目標FCM版本(V) | 在設備清單中明確聲明的目標FCM版本(來自S F ),供賣方實現。儘管供應商實現可能會在其設備清單中聲明較新的HAL版本,但仍必須針對已發布的FCM生成供應商實現。 |
HAL版本 | HAL版本的格式為foo@xy ,其中foo 是HAL名稱,而xy 是特定版本;例如nfc@1.0 , keymaster@3.0 (整個文檔中省略了根前綴,例如android.hardware 。) |
設備清單 | 一個XML文件,用於指定供應商映像提供的HAL版本。設備清單的內容受設備的目標FCM版本約束,但可以列出相對於與V對應的FCM嚴格更新的HAL。 |
在新的FCM版本中進行開發
Android為每個框架版本(例如Android 8、8.1等)增加FCM版本。在開發過程中,將創建新的compatibility_matrix.current.xml
( F
),並且現有的compatibility_matrix.f.xml
(其中f
< F
)不再更改。
要開始在新的FCM版本F
:
- 將最新的
compatibility_matrix.<F-1>.xml
複製到compatibility_matrix.current.xml
。 - 將文件中的
level
屬性更新為F
- 添加相應的構建規則以將該兼容性矩陣安裝到設備。
推出新的HAL
在開發過程中,在當前FCM版本F
上向Android引入新的HAL(Wi-Fi,NFC等)時,請使用以下optional
設置將HAL添加到compatibility_matrix.current.xml
:
- 如果
V = F
附帶的設備必須與此HAL一起啟動,則為optional="false"
,
要么 - 如果
V = F
附帶的設備可以在沒有此HAL的情況下啟動,則為optional="true"
。
例如,Android 8.1引入了cas@1.0
作為可選的HAL。不需要使用Android 8.1啟動的設備來實現此HAL,因此以下條目已添加到compatibility_matrix.current.xml
(在Android 8.1發布後重命名為compatibility_matrix.2.xml
):
<hal format="hidl" optional="true"> <name>android.hardware.cas</name> <version>1.0</version> <interface> <name>IMediaCasService</name> <instance>default</instance> </interface> </hal>
升級HAL(次要)
在開發過程中,如果HAL在當前FCM版本F
從xz
到x.(z+1)
進行次要版本升級,則該版本為:
- 在以
V = F
啟動的設備上是必需的,compatibility_matrix.current.xml
必須聲明x.(z+1)
和optional="false"
。 - 在以
V = F
啟動的設備上不是必需的,compatibility_matrix.current.xml
必須從compatibility_matrix.<F-1>.xml
複製xy-z
和可選compatibility_matrix.<F-1>.xml
,並將版本更改為xw-(z+1)
(其中w >= y
)。
例如,Android 8.1引入了broadcastradio@1.1
作為1.0 HAL的次要版本升級。對於使用Android 8.0啟動的設備,較舊版本的broadcastradio@1.0
是可選的,而對於使用Android 8.1啟動的設備,較新版本的broadcastradio@1.1
是可選的。在compatibility_matrix.1.xml
:
<hal format="hidl" optional="true"> <name>android.hardware.broadcastradio</name> <version>1.0</version> <interface> <name>IBroadcastRadioFactory</name> <instance>default</instance> </interface> </hal>
此項已復製到compatibility_matrix.current.xml
(在Android 8.1發布後重命名為compatibility_matrix.2.xml
),並進行瞭如下修改:
<hal format="hidl" optional="true"> <name>android.hardware.broadcastradio</name> <version>1.0-1</version> <interface> <name>IBroadcastRadioFactory</name> <instance>default</instance> </interface> </hal>
升級HAL(主要)
在開發過程中,當HAL在當前FCM版本F
進行主版本升級時,新的主版本x.0
將使用以下optional
設置添加到compatibility_matrix.current.xml
:
- 如果版本為
V = F
必須使用x.0
啟動,則僅具有x.0
版本的optional="false"
。 -
optional="false"
但與帶有相同<hal>
標記的較早的主要版本一起使用,如果帶有V = F
必須與此HAL一起啟動,但可以使用較早的主要版本啟動。 - 如果
V = F
附帶的設備不必啟動HAL,則為optional="true"
。
例如,Android 9引入了health@2.0
作為1.0 HAL的主要版本升級,並棄用了1.0 HAL。對於使用Android 8.0和Android 8.1啟動的設備,舊版本health@1.0
是可選的。使用Android 9啟動的設備不得提供已棄用的1.0 HAL,而必須提供新的2.0版本。在compatibility_matrix.legacy.xml
, compatibility_matrix.1.xml
和compatibility_matrix.2.xml
:
<hal format="hidl" optional="true"> <name>android.hardware.health</name> <version>1.0</version> <interface> <name>IHealth</name> <instance>default</instance> </interface> </hal>
將該條目複製到compatibility_matrix.current.xml
(在Android 9版本中重命名為compatibility_matrix.3.xml
),並進行如下修改:
<hal format="hidl" optional="false"> <name>android.hardware.health</name> <version>2.0</version> <interface> <name>IHealth</name> <instance>default</instance> </interface> </hal>
限制條件:
- 因為2.0 HAL在
compatibility_matrix.3.xml
並且帶有optional="false"
,所以使用Android 9啟動的設備必須隨附2.0 HAL。 - 由於1.0 HAL不在
compatibility_matrix.3.xml
,因此使用Android 9啟動的設備不得提供1.0 HAL(因為該HAL被認為已棄用)。 - 由於1.0 HAL作為可選HAL存在於legacy / 1 / 2.xml(Android 9可以使用的較舊FCM版本)中,因此Android 9框架仍可以與1.0 HAL(不視為已刪除的HAL版本)一起使用)。
新的FCM版本
作為AOSP版本的一部分,由Google單獨完成在系統分區上發布FCM版本的過程,包括以下步驟:
- 重命名
compatibility_matrix.current.xml
為compatibility_matrix.F.xml
。 - 確保文件具有屬性
level="F"
。 - 編輯相應的構建規則以反映文件名更改。
- 確保所有設備均已構建並啟動。
- 更新VTS測試,以確保使用最新框架(基於Shipping API級別)啟動的設備具有Target FCM版本
V >= F
- 將文件發佈到AOSP。
重命名和發布後將無法更改此文件。例如,在Android 9開發期間,以下文件是為hardware/interfaces/compatibility_matrices/
構建的:
-
compatibility_matrix.legacy.xml
-
compatibility_matrix.1.xml
-
compatibility_matrix.2.xml
-
compatibility_matrix.current.xml
在發布Android 9時, compatibility_matrix.current.xml
重命名為compatibility_matrix.3.xml
並為hardware/interfaces/compatibility_matrices/
構建了以下文件:
-
compatibility_matrix.legacy.xml
-
compatibility_matrix.1.xml
-
compatibility_matrix.2.xml
-
compatibility_matrix.3.xml
VTS測試確保使用Android 9啟動的設備的目標FCM版本> = 3。
此外,product和system_ext FCM可能還會列出每個平台FCM版本的要求。 FCM版本在product和system_ext分區上的發布分別由這些映像的所有者完成。 product和system_ext分區上的FCM版本號必須與系統分區上的FCM版本號對齊。與系統分區上的FCM版本類似,產品和system_ext分區中FCM版本F的兼容性矩陣反映了對目標FCM版本F的設備的要求。
HAL版本棄用
棄用HAL版本是開發人員的決定(例如,對於AOSP HAL,由Google做出決定)。發行更高的HAL版本(次要或主要)時,可能會發生這種情況。在FCM版本F
棄用給定的HAL foo@xy
時,這意味著以目標FCM版本V = F
或更高版本啟動的任何設備都不得在xy
版本或比xy
早的任何版本中實現foo
。用於升級設備的框架仍支持不推薦使用的HAL版本。
當發布FCM版本F
,如果在目標FCM版本V = F
的最新FCM中未明確聲明特定的HAL版本,則認為HAL版本foo@xy
已過時。對於使用V
啟動的設備,滿足以下條件之一:
- 該框架需要更高版本(主要或次要);
- 該框架不再需要HAL。
例如,在Android 9中,引入health@2.0
作為1.0 HAL的主要版本升級。 health@1.0
已從compatibility_matrix.3.xml
中刪除,但存在於compatibility_matrix.legacy.xml
, compatibility_matrix.1.xml
和compatibility_matrix.2.xml
。因此,不推薦使用health@1.0
。
刪除對目標FCM版本的支持
當某個目標FCM版本V
活動設備降至某個閾值以下時,將從下一個框架版本的集合S F中刪除目標FCM版本。這是通過從構建規則中刪除compatibility_matrix.V.xml
(以便不再將其安裝在系統映像上),以及刪除所有已實現或依賴於已刪除功能的代碼來完成的。對於給定的框架版本,目標FCM版本超出S F的設備無法升級到該版本。
HAL版本狀態
以下各節按時間順序描述了HAL版本的可能狀態。
未發行
如果任何公共和凍結兼容性矩陣中都沒有HAL版本,則認為該版本尚未發布,並且可能正在開發中。這包括僅在compatibility_matrix.current.xml
HAL版本。例子:
- 在Android 9的開發過程中(在
compatibiility_matrix.current.xml
重命名為compatibility_matrix.3.xml
),health@2.0
HAL被視為未發布的HAL。 -
teleportation@1.0
HAL不在任何已發布的兼容性矩陣中,並且也被視為未發布的HAL。
發布和最新
如果HAL版本存在於任何公共和凍結兼容性列表中,則將其發布。例如,凍結FCM版本3(將compatibiility_matrix.current.xml
重命名為compatibility_matrix.3.xml
)並發佈到AOSP之後, health@2.0
HAL被視為已發布的最新HAL版本。
如果HAL版本位於FCM版本最高的公共和凍結兼容性矩陣中(不包括compatibility_matrix.current.xml
),則該HAL版本為當前版本(即不建議使用)。例如,現有的HAL版本(如nfc@1.0
在引入compatibility_matrix.legacy.xml
),其繼續存在compatibility_matrix.3.xml
也被認為是釋放和電流HAL版本。
已發布但已棄用
僅在以下情況下,不推薦使用HAL版本:
- 它被釋放;
- 並非公開和凍結兼容性矩陣中的FCM版本最高。
- 框架仍然支持公共和凍結兼容性矩陣。
例子:
-
health@1.0
HAL放在compatibility_matrix.legacy.xml
,compatibility_matrix.1.xml
和compatibility_matrix.2.xml
,但不在compatibility_matrix.3.xml
。因此,它在Android 9中被視為已棄用。 - power HAL在Android 9中進行了次要版本升級,但是
power@1.0
仍在compatibility_matrix.3.xml
。-
power@1.0
位於compatibility_matrix.legacy.xml
,compatibility_matrix.1.xml
和compatibility_matrix.2.xml
。 -
compatibility_matrix.3.xml
具有power@1.0-1
。
-
因此power@1.0
是最新的,但不會被棄用,在Android的9。
已移除
僅在以下情況下,才會刪除HAL版本:
- 它先前已發布;
- 這不是在任何公共和冷凍兼容性矩陣,該框架支持。
公開,凍結但框架不支持的兼容性矩陣保留在代碼庫中,以定義已刪除的HAL版本集,以便可以編寫VTS測試以確保已刪除的HAL不在新設備上。
舊版FCM
對於所有非高音設備,“目標FCM版本”舊版是一個特殊值。舊版FCM compatibility_matrix.legacy.xml
_matrix.legacy.xml列出了舊版設備(即Android 8.0之前啟動的設備)對框架的要求。
如果對於版本為F
的FCM存在此文件,則只要其設備清單與此文件兼容,任何非Treble設備都可以升級到F
刪除它的步驟與其他目標FCM版本的FCM相同(在活動的8.0之前的設備數量降至某個閾值以下之後刪除)。
發行的FCM版本
可以在hardware/interfaces/compatibility_matrices
下找到已發布的FCM版本的列表。
要查找隨特定Android版本發行的FCM版本,請參閱Level.h
。