FCM 生命週期

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

為了在自己的生態系統中啟用僅框架的 OTA，擴展供應商接口的合作夥伴也應使用相同的方法棄用和刪除 HIDL 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>.xml複製到compatibility_matrix.current.xml 。
2. 將文件中的level屬性更新為F 。
3. 添加相應的構建規則以將此兼容性矩陣安裝到設備中。

引入新的 HAL

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

• optional="false"如果附帶V = F的設備必須使用此 HAL 啟動，
  
  要么
  
• 如果附帶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和可選性並將版本更改為xw-(z+1) （其中w >= y ）。

例如，Android 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 （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將添加到compatibility_matrix.current.xml並具有以下optional設置：

• optional="false"僅適用x.0版本，如果附帶V = F的設備必須使用x.0啟動。
• 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 版本

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

1. 將compatibility_matrix.current.xml重命名為compatibility_matrix.F.xml 。
2. 確保文件具有屬性level="F" 。
3. 編輯相應的構建規則以反映文件名更改。
4. 確保所有設備都構建並啟動。
5. 更新 VTS 測試以確保使用最新框架（基於 Shipping API 級別）啟動的設備具有 Target FCM Version 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 版本的發布分別由這些映像的所有者完成。 product 和 system_ext 分區上的 FCM 版本號必須與 system 分區上的版本一致。與系統分區上的 FCM 版本類似，產品和 system_ext 分區中 FCM 版本 F 的兼容性矩陣反映了對具有目標 FCM 版本 F 的設備的要求。

HAL 版本棄用

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

棄用設備 HAL

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

當 FCM 版本F發佈時，如果特定 HAL 版本未在目標 FCM 版本V = F的最新 FCM 中明確說明，則認為已棄用 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中被棄用時，這意味著任何使用 Target 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 @1.0 已棄用。它的max-level屬性設置為5 ，即 Android 11 中引入的 FCM 版本。請參閱Android 12 框架清單。

刪除對目標 FCM 版本的支持

當某個 Target FCM Version V的活動設備下降到某個閾值以下時，Target FCM Version 從下一個框架版本的集合 S _F中刪除。這是通過以下兩個步驟完成的：

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

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

HAL 版本狀態

以下部分描述（按時間順序）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，如果 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 版本是最新的（即未棄用）。例如，在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 版本的公開和凍結的兼容性矩陣中。
• 它位於框架仍然支持的公共和凍結的兼容性矩陣中。

例子：

• 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 版本在最新發布的分支的框架清單中，且其max-level屬性低於該分支中發布的 FCM 版本，則將其視為已發布但已棄用的 HAL 版本。例如， schedulerservice服務 HAL 已發布，但在 Android 12 中已棄用，如 Android 12framework manifest 。

已移除

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

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

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

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

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

舊版 FCM

Target FCM Version legacy 是所有非 Treble 設備的特殊值。舊版 FCM， compatibility_matrix.legacy.xml ，列出了框架對舊版設備（即 Android 8.0 之前啟動的設備）的要求。

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

發布的 FCM 版本

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

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