本頁面由 Cloud Translation API 翻譯而成。

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 版本: HAL 版本的格式為 foo@x.y，其中 foo 是 HAL 名稱，x.y 是特定版本，例如 nfc@1.0、keymaster@3.0 (根前置字串，例如 android.hardware，在本文件中省略)。
裝置資訊清單: XML 檔案，用於指定供應商介面的裝置端 (包括供應商和 ODM 映像檔) 提供哪些 HAL 版本。裝置資訊清單的內容會受到裝置的目標 Firebase 雲端通訊版本限制，但可以列出相對於 V 對應的 FC 的 HAL，這些 HAL 必須是較新的版本。
裝置 HAL: 在裝置資訊清單中列出的 HAL (提供)，以及在架構相容性矩陣 (FCM) 中列出的 HAL。
裝置相容性矩陣 (DCM): XML 檔案，可指定符合架構實作項目的供應商需求。每部裝置都包含一個 DCM。
Framework 資訊清單: XML 檔案，用於指定供應商介面的架構端提供哪些 HAL 版本，包括系統、system_ext 和產品映像檔。框架資訊清單中的 HAL 會根據裝置的指定 FCM 版本，以動態方式停用。
架構 HAL: 在架構資訊清單中列出的 HAL，並列在裝置相容性矩陣 (DCM) 中。

程式碼集中的 FCM 生命週期

本文件將概略說明 FCM 生命週期。如要查看支援的資訊清單，請參閱 hardware/interfaces/compatibility_matrix.<FCM>.xml，其中 system/libvintf/include/vintf/Level.h 可找到 FCM。

裝置出貨時，對應的 Android 版本應具備 FCM 值，且大於或等於對應的級別。舉例來說，搭載 Android 11 的裝置通常會是 FCM 級別 5，但實作 FCM 級別 6 以上版本，這類版本會附帶相容性矩陣中指定的各種額外需求。支援的等級如下：

FCM	Android 版本
4	Android 10/Q
5	Android 11/R
6	Android 12/S
7	Android 13/T
8	Android 14/U
202404	Android 15/V

FCM 級別與供應商 API 級別相同或更新。

Android 淘汰 FCM 級別時，仍會支援現有裝置。只要分支中提供新版 FCM 層級的 HAL，鎖定較低 FCM 層級的裝置就會隱含允許使用這些 HAL。

在新版 FCM 中進行開發

Android 會為每個架構版本 (例如 Android 8 和 8.1) 增加 FCM 版本。在開發期間，系統會建立新的 compatibility_matrix.F.xml，並不再變更現有的 compatibility_matrix.f.xml (f < F)。

如要開始使用新的 FCM 版本 F 進行開發，請按照下列步驟操作：

將最新的 compatibility_matrix.<F-1>.xml 複製到 compatibility_matrix.F.xml。
將檔案中的 level 屬性更新為 F。
新增對應的建構規則，將這個相容性矩陣安裝到裝置上。

推出新的 HAL

開發期間，如果要在目前的 FCM 版本 F 中向 Android 引進新的 HAL (Wi-Fi、NFC 等)，請將 HAL 新增至 compatibility_matrix.F.xml。

舉例來說，Android 8.1 推出了 cas@1.0。搭載 Android 8.1 的裝置可以實作此 HAL，因此已將下列項目新增至 compatibility_matrix.F.xml (在該版本開發期間，曾暫時命名為 compatibility_matrix.current.xml)：

<hal format="hidl">
    <name>android.hardware.cas</name>
    <version>1.0</version>
    <interface>
        <name>IMediaCasService</name>
        <instance>default</instance>
    </interface>
</hal>

升級 HAL (次要)

AIDL HAL 版本會計為 HAL 子版本。HIDL 介面版本有 major.minor 版本，例如 1.2。

開發期間，如果 AIDL HAL 在目前的 FCM 版本 F 中從 2 升級至 3，新版本會新增至 compatibility_matrix.F.xml 中的 HAL 項目。HAL 項目的版本欄位可接受 2-3 等範圍。

舉例來說，Android FCM F 推出 foo@3 做為 HAL 的次要版本升級。舊版 foo@2 適用於指定舊版 FCM 的裝置，而新版 foo@3 適用於指定 Android FCM F 的裝置。在 2 之前的舊版 FCM 中，項目如下所示：

<hal format="aidl">
    <name>foo</name>
    <version>2</version>
    <interface>
        <name>IFoo</name>
        <instance>default</instance>
    </interface>
</hal>

這個項目已複製到 compatibility_matrix.F.xml，並修改為支援 3 版本，如下所示：

<hal format="aidl">
    <name>foo</name>
    <version>2-3</version>
    <interface>
        <name>IFoo</name>
        <instance>default</instance>
    </interface>
</hal>

升級 HAL (主要)

開發期間，如果 HAL 在目前的 FCM 版本 F 中進行主要版本升級，新的主版本 x.0 會透過以下設定新增至 compatibility_matrix.F.xml：

如果搭載 V = F 的裝置必須使用 x.0 啟動，則僅限 x.0 版本。
在同一個 <hal> 標記中使用較舊的主要版本，如果搭載 V = F 的裝置可以使用較舊的主要版本啟動。

舉例來說，FCM 版本 F 會引入 foo@2.0 做為 1.0 HAL 的主要版本升級，並淘汰 1.0 HAL。較舊的版本 foo@1.0 適用於指定舊版 FCM 的裝置。如果裝置指定 FCM 2.0 以上版本，則必須提供 HAL。F在這個範例中，先前的 FCM 版本包含以下項目：

<hal format="hidl">
    <name>foo</name>
    <version>1.0</version>;
    <interface>
        <name>IFoo</name>
        <instance>default</instance>
    </interface>
</hal>

將這個項目複製到 compatibility_matrix.F.xml，然後修改如下：

<hal format="hidl">
    <name>foo</name>
    <version>2.0</version>
    <interface>
        <name>IFoo</name>
        <instance>default</instance>
    </interface>
</hal>

限制：

由於 1.0 HAL 不在 compatibility_matrix.F.xml 中，因此指定 FCM 1.0 版本的裝置不得提供 1.0 HAL (因為這個 HAL 已淘汰)。F
由於 1.0 HAL 會出現在舊版 FCM 中，因此架構仍可與 1.0 HAL 搭配運作，因此可與指定舊版 FCM 的舊裝置回溯相容。

新的 FCM 版本

在系統分區發布 FCM 版本的程序，僅由 Google 在 AOSP 版本中執行，包括下列步驟：

請確認 compatibility_matrix.F.xml 具有 level="F" 屬性。
確認所有裝置都已建構及啟動。
更新 VTS 測試，確保使用最新架構 (根據發布 API 級別) 啟動的裝置，具有目標 FCM 版本 V >= F。
將檔案發布至 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@x.y 在 FCM 版本 F 中已淘汰，表示任何以目標 FCM 版本 V = F 以上版本啟動的裝置，都不得在 x.y 以上版本或 x.y 以下版本中實作 foo。升級裝置的架構仍支援已淘汰的 HAL 版本。

當 Firebase 雲端消息版本 F 發布時，如果最新的 Firebase 雲端消息版本 V = F 並未明確指出特定 HAL 版本，則 HAL 版本 foo@x.y 會視為已淘汰。對於透過 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@x.y 在 FCM 版本 F 中已淘汰，表示任何以目標 FCM 版本 V = F 以上版本啟動的裝置，都不得預期該架構會在 x.y 版本或 x.y 之前的任何舊版本中提供 foo。架構仍會為升級裝置提供已淘汰的 HAL 版本。

當 FCM 版本 F 發布時，如果架構資訊清單為 foo@x.y 指定 max-level="F - 1"，則 HAL 版本 foo@x.y 會視為已淘汰。如果裝置是透過 V = F 啟動，架構就不會提供 HAL foo@x.y。使用 V = F 啟動的裝置上，裝置相容性矩陣不得列出使用 max-level < V 的架構 HAL。

舉例來說，在 Android 12 中，schedulerservice@1.0 已淘汰。其 max-level 屬性設為 5，這是 Android 11 中推出的 FCM 版本。請參閱 Android 12 架構資訊清單。

移除對目標 FCM 版本的支援

當某個指定 Firebase 雲端通訊版本 V 的活躍裝置數量低於特定門檻時，系統會從下一個架構版本的 S_F 集合中移除該指定 Firebase 雲端通訊版本。這項操作會同時執行下列兩個步驟：

從建構規則中移除 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，且僅出現在 compatibility_matrix.3.xml 中。
teleportation@1.0 HAL 不在任何已發布的相容性矩陣中，也視為未發布的 HAL。

對於架構 HAL，如果 HAL 版本只位於不相關開發分支的架構資訊清單中，則系統會將其視為未發布。

已發布和目前

針對裝置 HAL，如果 HAL 版本位於任何公開且已凍結的相容性矩陣中，就會發布。舉例來說，當 FCM 3 版本凍結並發布至 Android 開放原始碼計畫後，health@2.0 HAL 就會視為已發布的現行 HAL 版本。

如果 HAL 版本位於公開且已凍結的相容性矩陣中，且該矩陣具有最高的 FCM 版本，則 HAL 版本為最新版本 (即未淘汰)。舉例來說，如果現有的 HAL 版本 (例如 compatibility_matrix.legacy.xml 中引入的 nfc@1.0) 仍存在於 compatibility_matrix.3.xml 中，也會視為已發布的現有 HAL 版本。

針對架構 HAL，如果 HAL 版本位於最新發布分支的架構資訊清單中，且沒有 max-level 屬性，或是 (不尋常地) max-level 等於或高於這個分支發布的 FCM 版本，則系統會將其視為已發布的目前 HAL 版本。舉例來說，displayservice HAL 已在 Android 12 中發布並更新，如 Android 12 架構資訊清單所述。

已發布但已淘汰

針對裝置 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 中已淘汰。
電源 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 12 架構資訊清單所述。

已移除

針對裝置 HAL，只有在下列條件成立時，系統才會移除 HAL 版本：

這項功能先前已發布。
但該版本並未列於架構支援的任何公開和已凍結的相容性矩陣中。

公開且已凍結的相容性矩陣，如果不受架構支援，則會保留在程式碼庫中，以定義已移除的 HAL 版本集，這樣就能編寫 VTS 測試，確保新裝置中沒有已移除的 HAL。

對於架構 HAL，只有在符合下列條件時，系統才會移除 HAL 版本：

這項功能先前已發布。
但在最新發布的分支版本中，並未出現在任何架構資訊清單中。

舊版 FCM

針對所有非 Treble 裝置，Target FCM Version legacy 是特殊值。舊版 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。