FCM生命週期

一個 Android 框架版本有多個框架兼容性矩陣 (FCM)——每個可升級的目標 FCM 版本都有一個——定義了框架可能使用的內容和目標 FCM 版本要求。由於FCM生命週期的一部分,Android的棄用及排除HIDL的HAL,然後修改FCM文件,以反映的情況HAL版本

為了在自己的生態系統中啟用僅限框架的 OTA,擴展供應商接口的合作夥伴也應該使用相同的方法棄用和刪除 HIDL HAL。

術語

框架兼容性矩陣 (FCM)一個 XML 文件,用於指定符合供應商實現的框架要求。兼容性矩陣是版本化的,每個框架版本都會凍結一個新版本。每個框架版本都包含多個 FCM。
平台FCM版本(S F)框架版本中所有 FCM 版本的集合。該框架可以與滿足這些 FCM 之一的任何供應商實現一起使用。
FCM 版 (F)框架版本中所有 FCM 中的最高版本。
目標 FCM 版本 (V)有針對性的FCM版本(來自S對F),在設備清單中聲明明確,一個供應商實現滿足。供應商實現必須針對已發布的 FCM 生成,儘管它可能會在其設備清單中聲明更新的 HAL 版本。
哈爾版本一個HAL版本的格式foo@xy ,其中foo是HAL名稱, xy是具體的版本;例如nfc@1.0keymaster@3.0 (根前綴,例如android.hardware ,在整個本文件中省略)。
設備清單XML 文件指定供應商接口的設備端提供哪些 HAL 版本,包括供應商和 ODM 映像。設備清單的內容受設備的目標 FCM 版本限制,但可以列出相對於 V 對應的 FCM 嚴格更新的 HAL。
設備 HAL在設備清單中列出(提供)並在框架兼容性矩陣 (FCM) 中列出(必需或可選)的 HAL。
設備兼容性矩陣 (DCM)一個 XML 文件,指定供應商對符合框架實現的要求。每個設備包含一個 DCM。
框架清單一個 XML 文件,用於指定供應商接口的框架端(包括 system、system_ext 和產品映像)提供的 HAL 版本。框架清單中的 HAL 會根據設備的目標 FCM 版本動態禁用。
框架 HAL在框架清單中列為提供並在設備兼容性矩陣 (DCM) 中列為必需或可選的 HAL。

在新的 FCM 版本中開發

Android 會為每個框架版本(例如 Android 8、8.1 等)增加 FCM 版本。在開發過程中,新的compatibility_matrix.current.xml被創建( F )和現有compatibility_matrix.f.xml (其中f < F )不再改變。

要開始一個新的FCM版本開發F

  1. 拷貝最新compatibility_matrix.<F-1>.xmlcompatibility_matrix.current.xml
  2. 更新level的文件中屬性F
  3. 添加相應的構建規則以將此兼容性矩陣安裝到設備。

引入新的 HAL

在開發過程中,對當前FCM版本引入了新的HAL(的Wi-Fi,NFC等)到Android時F ,加上HAL到compatibility_matrix.current.xml有以下optional設置:

  • optional="false" ,如果設備是船舶與V = F必須用這個HAL推出,

    或者
  • optional="true" ,如果設備是船舶與V = F可以沒有這個HAL推出。

例如,機器人8.1引入cas@1.0作為可選HAL。設備採用Android 8.1推出不需要實現這個HAL,所以下面的條目添加到compatibility_matrix.current.xml (更名為compatibility_matrix.2.xml的Android 8.1發布之後):

<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已經從一個小的版本升級xzx.(z+1)在目前的FCM版本F ,如果該版本是:

  • 需要與發射裝置V = F ,所述compatibility_matrix.current.xml絕狀態x.(z+1)optional="false"
  • 不需要與發射裝置V = F ,所述compatibility_matrix.current.xml必須複製xy-z從和可選性compatibility_matrix.<F-1>.xml和更改版本來xw-(z+1)其中, w >= y )。

例如,機器人8.1引入broadcastradio@1.1作為次要版本1.0 HAL的升級。舊版本, broadcastradio@1.0 ,是可選的與Android 8.0同時推出新版本,設備broadcastradio@1.1 ,是可選的配合Android 8.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 (重命名為compatibility_matrix.2.xml的Android 8.1釋放之後),並作如下修改:

<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添加到compatibility_matrix.current.xml有以下optional設置:

  • optional="false" ,只有版本x.0 ,如果設備是船舶與V = F必須推出x.0
  • optional="false" ,但與舊主要版本在同一沿<hal>標籤,如果設備是船舶與V = F必須用這個HAL推出,但可與較早的主要版本推出。
  • optional="true" ,如果設備是船舶與V = F不必啟動HAL。

例如,機器人9引入health@2.0作為主要版本1.0 HAL的升級和棄用1.0 HAL。舊版本, health@1.0 ,是可選的與Android 8.0和Android 8.1的降落裝置。搭載 Android 9 的設備不得提供已棄用的 1.0 HAL,而必須提供新的 2.0 版本。在compatibility_matrix.legacy.xmlcompatibility_matrix.1.xmlcompatibility_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 (重命名為compatibility_matrix.3.xml與Android 9釋放)和修改如下:

<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.xmloptional="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 版本

在系統分區上發布 FCM 版本的過程由 Google 作為 AOSP 發布的一部分單獨完成,包括以下步驟:

  1. 重命名compatibility_matrix.current.xmlcompatibility_matrix.F.xml
  2. 確保文件具有屬性level="F"
  3. 相應的編輯生成規則,以反映該文件的名稱更改。
  4. 確保所有設備構建和啟動。
  5. 更新VTS測試,以確保與最新架構(基於航運API級)發射裝置具有目標FCM版V >= F
  6. 將文件發佈到 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 版本的要求。 product 和 system_ext 分區上的 FCM 版本的發布分別由這些映像的所有者完成。產品和 system_ext 分區上的 FCM 版本號必須與系統分區上的版本號一致。與系統分區上的 FCM 版本類似,產品和 system_ext 分區中 FCM 版本 F 的兼容性矩陣反映了對具有目標 FCM 版本 F 的設備的要求。

HAL 版本棄用

棄用 HAL 版本是開發人員的決定(即對於 AOSP HAL,由 Google 做出決定)。當發布更高的 HAL 版本(無論是次要版本還是主要版本)時,可能會發生這種情況。

棄用設備 HAL

當給定的設備HAL foo@xy在FCM版本已經過時F ,這意味著與目標FCM版本的任何設備發射V = F或更高版本必須不實現foo在版本xy或任何比舊版本xy 。用於升級設備的框架仍支持已棄用的 HAL 版本。

當FCM版本F被釋放時,HAL版本foo@xy如果特定HAL版本未在目標FCM下載最新版的FCM明確表示不推薦使用V = F 。對於具有發射裝置V = F ,滿足下列條件之一為真:

  • 框架需要更高版本(主要或次要);
  • 該框架不再需要 HAL。

例如,在9的Android, health@2.0被引入作為1.0 HAL的主要版本升級。 health@1.0從除去compatibility_matrix.3.xml但存在於compatibility_matrix.legacy.xmlcompatibility_matrix.1.xml ,和compatibility_matrix.2.xml 。因此, health@1.0不推薦使用。

棄用框架 HAL

當給定的框架HAL foo@xy在FCM版本已經過時F ,這意味著與目標FCM版本的任何設備發射V = F或更高版本,不要指望框架提供foo的版本為xy ,或在任何比舊版本xy 。不推薦使用的 HAL 版本仍由用於升級設備的框架提供。

當FCM版本F被釋放時,HAL版本foo@xy不推薦使用,如果框架清單指定要max-level=" F - 1 "foo@xy 。對於具有發射裝置V = F ,框架不提供HAL foo@xy 。上設備的設備兼容性矩陣與發射V = F不得列表框架的HAL與max-level < V

例如,在12的Android, schedulerservice@1.0已棄用。它的max-level屬性設置為5 ,在Android中11看介紹的FCM版本的Android框架12表現

取消對目標 FCM 版本的支持

當某個目標FCM版的有源器件V低於某一閾值下降,則目標FCM版從設定的下一個框架釋放的F除去。這是通過以下兩個步驟完成的:

  • 除去compatibility_matrix.V.xml從構建規則(以便它不是系統圖像上安裝的),和刪除或實現取決於被移除的功能性的任何代碼。
  • 移除與框架的HAL max-level低於或等於V從框架清單,並刪除任何代碼實現所移除的框架的HAL。

用的F目標FCM版本之外對於給定的框架釋放裝置無法升級到該版本。

HAL 版本狀態

以下部分(按時間順序)描述了 HAL 版本的可能狀態。

未發行

對於設備 HAL,如果 HAL 版本不在任何公開和凍結的兼容性矩陣中,則將其視為未發布且可能正在開發中。這包括HAL版本是只在compatibility_matrix.current.xml 。例子:

  • 在Android的9(之前的發展compatibiility_matrix.current.xml更名為compatibility_matrix.3.xml ),該health@2.0 HAL被認為是一個未發布的HAL。
  • teleportation@1.0 HAL是不是在任何發行兼容性列表,並且也被認為是未發行的HAL。

對於框架 HAL,如果 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,如果HAL版本是在沒有最新發布的分支的框架清單max-level屬性或(異常)一個max-level等於或大於這個分支發布的FCM版本高,被認為是釋放和當前的 HAL 版本。例如, displayservice HAL被釋放,並且電流的Android 12,由指定的 Android 12framework manifest

已發布但已棄用

對於設備 HAL,當且僅當滿足以下所有條件時,才會棄用 HAL 版本:

  • 它被釋放。
  • 它不在公共和凍結兼容性矩陣中具有最高的 FCM 版本。
  • 框架仍然支持公共和凍結的兼容性矩陣。

例子:

因此power@1.0是最新的,但不會被棄用,在Android的9。

對於框架的HAL,如果HAL版本是最新發布的分支,通過一個框架清單max-level屬性比這個分支發布的版本FCM降低,它被認為是釋放,但不建議使用HAL版本。例如, schedulerservice HAL被釋放,但在12的Android棄用,由指定的 Android 12framework manifest

已移除

對於設備 HAL,當且僅當滿足以下條件時,才會刪除 HAL 版本:

  • 它之前已發布。
  • 它不在框架支持的任何公共和凍結兼容性矩陣中。

公開、凍結但不受框架支持的兼容性矩陣保留在代碼庫中以定義已刪除的 HAL 版本集,以便可以編寫 VTS 測試以確保已刪除的 HAL 不在新設備上。

對於框架 HAL,當且僅當滿足以下條件時,才會刪除 HAL 版本:

  • 它之前已發布。
  • 它不在最新發布的分支的任何框架清單中。

傳統 FCM

Target FCM Version legacy 是所有非 Treble 設備的特殊值。遺留FCM, compatibility_matrix.legacy.xml ,列表在傳統設備上的框架的要求(即,設備推出之前的Android 8.0)。

如果該文件存在與版本的FCM F ,任何非高音設備可以升級到F提供其設備清單是與此文件相兼容。它的刪除遵循與其他目標 FCM 版本的 FCM 相同的程序(在活動的 8.0 之前的設備數量下降到特定閾值以下後刪除)。

已發布的 FCM 版本

發布FCM版本列表下可以找到hardware/interfaces/compatibility_matrices

為了找到與特定的Android版本發布的FCM版本,請參閱Level.h