為配合主幹穩定開發模型，並確保生態系統的平台穩定性，我們將自 2026 年起，在第 2 季和第 4 季將原始碼發布至 AOSP。如要建構及貢獻 AOSP，請使用 android-latest-release。android-latest-release 資訊清單分支版本一律會參照推送至 Android 開放原始碼計畫的最新版本。詳情請參閱「Android 開放原始碼計畫變更」。

Google uses AI technology to translate content into your preferred language. AI translations can contain errors.

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 檔案：指定供應商介面裝置端提供的 HAL 版本，包括供應商和 ODM 映像檔。裝置資訊清單的內容會受到裝置目標 FCM 版本的限制，但可以列出相對於 V.
裝置 HAL: 裝置資訊清單中列出 (提供) 的 HAL，以及架構相容性矩陣 (FCM) 中列出的 HAL。
裝置相容性矩陣 (DCM): XML 檔案：指定符合架構實作的供應商需求。每部裝置都包含一個 DCM。
架構資訊清單: XML 檔案，用於指定供應商介面架構端提供的 HAL 版本，包括系統、system_ext 和產品映像檔。架構資訊清單中的 HAL 會根據裝置的目標 FCM 版本動態停用。
架構 HAL: 架構資訊清單中列為提供的 HAL，以及裝置相容性矩陣 (DCM) 中列出的 HAL。

程式碼集中的 FCM 生命週期

本文將抽象地說明 FCM 生命週期。如要查看支援的資訊清單，請參閱 hardware/interfaces/compatibility_matrices/compatibility_matrix.<FCM>.xml，瞭解 FCM 在 system/libvintf/include/vintf/Level.h 中的位置。

搭載相應 Android 發布版本的裝置，其 FCM 值應大於或等於同等層級。舉例來說，搭載 Android 12 的裝置通常會使用 FCM 層級 6，但也可以實作 FCM 層級 7 以上版本，這會改變 Android 行為，並強制使用相容性矩陣中指定的新版供應商 API。Android 16 支援的等級如下：

FCM	Android 版本
6	Android 12/S
7	Android 13/T
8	Android 14/U
202404	Android 15/V
202504	Android 16/B

FCM 級別等於或高於供應商 API 級別。

Project Treble 推出時，Android 系統映像檔的建構方式可回溯相容於前三個版本的供應商實作 (共四個版本)。為延長裝置使用壽命，我們將支援的 FCM 版本數量增加至七個，包括目前版本和前六個版本，適用於 202404 以上版本。

Android 淘汰 FCM 層級後，現有裝置仍可繼續使用。只要分支版本提供 HAL，以較低 FCM 層級為目標的裝置就能隱含使用較高 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

在開發期間，將新的 HAL (Wi-Fi、NFC 等) 導入 Android 時，請在目前的 FCM 版本 F 中將 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 從 2 升級至目前 FCM 版本 F 的 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 版本 F 為目標，且提供 HAL，就必須提供新的 2.0 版。在本例中，先前的 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 版本 F 為目標的裝置不得提供 1.0 HAL (因為這個 HAL 已淘汰)。
由於舊版 FCM 版本中存在 1.0 HAL，框架仍可與 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 以上版本的裝置，都不得實作 foo 的 x.y 版本或任何舊版。x.y架構仍支援已淘汰的 HAL 版本，可供裝置升級。

發布 FCM 版本 F 時，如果最新 FCM for Target FCM 版本 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 以上啟動的任何裝置，都不應期望架構提供 foo 版本 x.y，或任何舊於 x.y 的版本。架構仍會為升級裝置提供已淘汰的 HAL 版本。

發布 FCM 版本 F 時，如果架構資訊清單指定 foo@x.y，則 HAL 版本 foo@x.y 會視為已淘汰。max-level="F - 1"如果是搭載 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 版本

我們採用排程式程序來決定移除目標 FCM 版本，以維持必要時間的相容性，並支援合作夥伴對使用壽命較長裝置的要求。

從下一個架構版本的 S_F 集合中移除目標 FCM 版本時，我們會執行下列兩個步驟：

從建構規則中移除 compatibility_matrix.V.xml (這樣就不會安裝在系統映像檔上)，並刪除實作或依附於已移除功能的任何程式碼。
從架構資訊清單中移除 max-level 低於或等於 V 的架構 HAL，並刪除實作已移除架構 HAL 的任何程式碼。

版本設定的逐步淘汰程序

Trunk Stable 的分支策略是直接從 git_main 取得每季平台版本 (QPR)，而非從個別的 release-dev 分支取得，因此需要錯開淘汰程序。FCM 版本可能會在 trunk_staging 建構版本中因早期信號而移除，但仍會在發布分支版本中受到支援，以配合全年採用 QPR 的裝置。

一般來說，架構版本會支援六個 FCM：一個目前版本、四個舊版，以及一個額外版本來支援 QPR。如果特定 FCM 版本 (例如 Android 15 的 202404) 延長裝置使用壽命的支援期限，這個數字可能會增加。

如果裝置的目標 FCM 版本不在特定架構版本的 S_F 範圍內，就無法升級至該版本。

移除完全淘汰的 HAL

移除 FCM 版本後，任何 FCM 中都不會再出現某些 HAL 介面或 HAL 介面版本。也就是說，Android 不再支援這些裝置，即使是升級裝置也不例外。

HAL 不再受支援後，開發人員會從 Android 移除對該 HAL 介面的參照，包括架構中的用戶端程式碼、預設實作項目和 VTS 測試案例。

如果沒有任何支援的 HAL 繼承要移除的 HAL，則可透過幾個額外步驟移除 HAL 定義本身。

從原始碼中移除 HAL 介面定義。包括 *.aidl 檔案和 Android.bp aidl_interface 模組。
如果是 HIDL，請從 hardware/interfaces/current.txt 移除 HASH。
如果是 AIDL，請移除含有凍結 AIDL 檔案的 aidl_api 目錄。
從 hardware/interfaces/compatibility_matrices/exclude/fcm_exclude.cpp 移除介面。

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 版本為最新版本 (即未遭淘汰)。舉例來說，compatibility_matrix.3.xml 中持續存在的現有 HAL 版本 (例如 compatibility_matrix.legacy.xml 中導入的 nfc@1.0) 也視為已發布的現行 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 中，這項功能已淘汰。
Android 9 中的電源 HAL 子版本已升級，但 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 版本。舉例來說，Android 12 中已發布 schedulerservice HAL，但已遭淘汰，如 Android 12 架構資訊清單所指定。

已移除

如為裝置 HAL，只有在符合下列條件時，系統才會移除 HAL 版本：

先前已發布。
架構支援的任何公開和凍結相容性矩陣中，都沒有這個項目。

公開且凍結但架構不支援的相容性矩陣會保留在程式碼庫中，以定義已移除的 HAL 版本集，方便編寫 VTS 測試，確保新裝置不會使用已移除的 HAL。

如果是架構 HAL，只有在符合下列條件時，才會移除 HAL 版本：

先前已發布。
不在最新發布分支的任何架構資訊清單中。

舊版 FCM

Target FCM Version legacy 是所有非 Treble 裝置的特殊值。舊版 FCM (compatibility_matrix.legacy.xml) 列出舊版裝置 (即 Android 8.0 推出前發布的裝置) 的架構需求。

如果 FCM 存在這個檔案，且版本為 F，只要裝置資訊清單與這個檔案相容，任何非 Treble 裝置都可以升級至 F。移除程序與其他 Target FCM 版本相同 (當使用前 8.0 裝置的數量低於特定門檻時，系統就會移除)。

已發布的 FCM 版本

如要查看已發布的 FCM 版本清單，請前往 hardware/interfaces/compatibility_matrices。

如要找出特定 Android 版本隨附的 FCM 版本，請參閱Level.h。