FCM 生命週期

Android 框架版本具有多個框架兼容性矩陣 (FCM)（每個可升級的目標 FCM 版本一個），用於定義框架可以使用的內容和目標 FCM 版本要求。作為 FCM 生命週期的一部分，Android 棄用並刪除 HIDL HAL，然後修改 FCM 文件以反映HAL Version的狀態。

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

術語

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

在新的 FCM 版本中進行開發

Android 會增加每個框架版本（例如 Android 8、8.1 等）的 FCM 版本。在開發過程中，將創建新的compatibility_matrix.F.xml ，並且現有的compatibility_matrix.f.xml （其中f < F ）不再更改。

要開始在新的 FCM 版本F中進行開發：

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

引入新的 HAL

在開發過程中，當在當前 FCM 版本F上向 Android 引入新的 HAL（Wi-Fi、NFC 等）時，請使用以下optional設置將 HAL 添加到compatibility_matrix.F.xml ：

  • 如果V = F附帶的設備必須使用此 HAL 啟動，則optional="false" ，

    或者
  • 如果V = F附帶的設備可以在沒有此 HAL 的情況下啟動，則optional="true" 。

例如，Android 8.1 引入了cas@1.0作為可選 HAL。使用 Android 8.1 啟動的設備不需要實現此 HAL，因此以下條目已添加到compatibility_matrix.F.xml （在該版本的開發過程中臨時命名為compatibility_matrix.current.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.F.xml必須聲明x.(z+1)和optional="false" 。
  • 在使用V = F啟動的設備上不需要， compatibility_matrix.F.xml必須從compatibility_matrix.<F-1>.xml複製xy-z和可選性，並將版本更改為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.F.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將添加到compatibility_matrix.F.xml中，並具有以下optional設置：

  • 如果使用V = F設備必須使用x.0啟動，則僅使用版本x.0的optional="false" 。
  • 如果V = F附帶的設備必須使用此 HAL 啟動，但可以使用舊的主要版本啟動，則optional="false" ，但與同一<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.F.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 版本

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

  1. 確保compatibility_matrix.F.xml具有屬性level="F" 。
  2. 確保所有設備構建並啟動。
  3. 更新 VTS 測試，確保使用最新框架（基於 Shipping API 級別）啟動的設備具有目標 FCM 版本V >= F 。
  4. 將文件發佈到 AOSP。

例如， VTS 測試可確保搭載 Android 9 的設備的目標 FCM 版本 >= 3。

此外，產品和 system_ext FCM 還可能列出每個平台 FCM 版本的要求。產品和 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或更高版本啟動的任何設備不得在版本xy或任何早於xy的版本上實現foo 。升級設備的框架仍然支持已棄用的 HAL 版本。

發布 FCM 版本F時，如果目標 FCM 版本V = F的最新 FCM 中未明確說明特定的 HAL 版本，則 HAL 版本foo@xy將被視為已棄用。對於以V = F啟動的設備，滿足以下條件之一：

  • 框架需要更高版本（主要或次要）；
  • 該框架不再需要 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被視為已棄用。

棄用框架 HAL

當給定框架 HAL foo@xy在 FCM 版本F中被棄用時，這意味著使用目標 FCM 版本V = F或更高版本啟動的任何設備都不得期望框架提供版本xy或任何早於xy的版本的foo 。框架仍提供已棄用的 HAL 版本用於升級設備。

當 FCM 版本F發佈時，如果框架清單為foo@xy指定max-level=" F - 1 "則 HAL 版本foo@xy將被視為已棄用。對於使用V = F啟動的設備，框架不提供 HAL foo@xy 。以V = F啟動的設備上的設備兼容性矩陣不得列出max-level < V的框架 HAL。

例如，在 Android 12 中， schedulerservice@1.0已棄用。其max-level屬性設置為5 ，即 Android 11 中引入的 FCM 版本。請參閱Android 12 框架清單。

刪除對目標 FCM 版本的支持

當某個目標FCM版本V的活動設備下降到某個閾值以下時，從下一個框架版本的集合SF中移除該目標FCM版本。這是通過以下兩個步驟完成的：

  • 從構建規則中刪除compatibility_matrix.V.xml （以便它不會安裝在系統映像上），並刪除實現或依賴於已刪除功能的任何代碼。
  • 從框架清單中刪除max-level低於或等於V框架 HAL，並刪除實現已刪除框架 HAL 的任何代碼。

對於給定框架版本，目標 FCM 版本在 S F之外的設備無法升級到該版本。

HAL 版本狀態

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

未發布

對於設備 HAL，如果 HAL 版本不在任何公共和凍結的兼容性矩陣中，則它被視為未發布且可能正在開發中。這包括僅在compatibility_matrix.F.xml中的 HAL 版本。例子：

  • 在 Android 9 的開發過程中， health@2.0 HAL 被認為是未發布的 HAL，僅存在於compatibiility_matrix.3.xml中。
  • teleportation@1.0 HAL 不在任何已發布的兼容性矩陣中，也被視為未發布的 HAL。

對於框架 HAL，如果 HAL 版本僅出現在不相關開發分支的框架清單中，則被視為未發布。

已發布和當前版本

對於設備 HAL，如果 HAL 版本位於任何公共且凍結的兼容性矩陣中，則會發布該版本。例如，在 FCM 版本 3 被凍結並發佈到 AOSP 後， health@2.0 HAL 被視為已發布的當前 HAL 版本。

如果 HAL 版本位於具有最高 FCM 版本的公共且凍結的兼容性矩陣中，則 HAL 版本是最新版本（即未棄用）。例如，在compatibility_matrix.legacy.xml中繼續存在的現有HAL版本（例如compatibility_matrix.3.xml中引入的nfc@1.0 ）也被視為已發布的當前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 已發布，但在 Android 12 中已棄用，如 Android 12framework manifest 。

已刪除

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

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

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

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

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

舊版 FCM

目標 FCM 版本舊版對於所有非 Treble 設備來說是一個特殊值。舊版 FCM compatibility_matrix.legacy.xml列出了舊版設備（即 Android 8.0 之前啟動的設備）上框架的要求。

如果版本F的 FCM 存在此文件，則任何非 Treble 設備都可以升級到F ，前提是其設備清單與此文件兼容。其刪除過程與其他目標 FCM 版本的 FCM 相同（在 8.0 之前的活動設備數量降至特定閾值以下後刪除）。

發布的 FCM 版本

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

要查找隨特定 Android 版本一起發布的 FCM 版本，請參閱Level.h 。