進行我們的可用性調查以改進此站點。
本頁面由 Cloud Translation API 翻譯而成。
Switch to English

FCM生命週期

Android框架版本具有多個框架兼容性矩陣（FCM）（每個可升級的Target FCM版本一個），它們定義了框架可以使用的功能以及Target FCM版本要求。作為FCM生命週期的一部分，Android會棄用並刪除HIDL HAL，然後修改FCM文件以反映HAL版本的狀態。

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

術語

框架兼容性矩陣（FCM）一個XML文件，該文件指定對符合標準的供應商實現的框架要求。對兼容性列表進行了版本控制，並為每個框架版本凍結了一個新版本。每個框架版本都包含多個FCM。
平台FCM版本（ SF ）框架版本中所有FCM版本的集合。該框架可以與滿足這些FCM之一的任何供應商實施一起使用。
FCM版本（F）框架版本中所有FCM中的最高版本。
目標FCM版本（V）在設備清單中明確聲明的目標FCM版本（來自S F ），供賣方實現。儘管供應商實現可能會在其設備清單中聲明較新的HAL版本，但仍必須針對已發布的FCM生成供應商實現。
HAL版本HAL版本的格式為foo@xy ，其中foo是HAL名稱，而xy是特定版本；例如nfc@1.0 ， keymaster@3.0 （整個文檔中省略了根前綴，例如android.hardware 。）
設備清單一個XML文件，用於指定供應商映像提供的HAL版本。設備清單的內容受設備的目標FCM版本約束，但可以列出相對於與V對應的FCM嚴格更新的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等）時，請使用以下optional設置將HAL添加到compatibility_matrix.current.xml ：

  • 如果V = F附帶的設備必須與此HAL一起啟動，則為optional="false" ，

    要么
  • 如果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和可選compatibility_matrix.<F-1>.xml ，並將版本更改為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.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將使用以下optional設置添加到compatibility_matrix.current.xml ：

  • 如果版本為V = F必須使用x.0啟動，則僅具有x.0版本的optional="false" 。
  • 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版本

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

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

HAL版本棄用

棄用HAL版本是開發人員的決定（例如，對於AOSP HAL，由Google做出決定）。發行更高的HAL版本（次要或主要）時，可能會發生這種情況。在FCM版本F棄用給定的HAL foo@xy時，這意味著以目標FCM版本V = F或更高版本啟動的任何設備都不得在xy版本或比xy早的任何版本中實現foo 。用於升級設備的框架仍支持不推薦使用的HAL版本。

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

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

刪除對目標FCM版本的支持

當某個目標FCM版本V活動設備降至某個閾值以下時，將從下一個框架版本的集合S F中刪除目標FCM版本。這是通過從構建規則中刪除compatibility_matrix.V.xml （以便不再將其安裝在系統映像上），以及刪除所有已實現或依賴於已刪除功能的代碼來完成的。對於給定的框架版本，目標FCM版本超出S F的設備無法升級到該版本。

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版本存在於任何公共和凍結兼容性列表中，則將其發布。例如，凍結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版本：

  • 它被釋放；
  • 並非公開和凍結兼容性矩陣中的FCM版本最高。
  • 框架仍然支持公共和凍結兼容性矩陣。

例子：

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

已移除

僅在以下情況下，才會刪除HAL版本：

  • 它先前已發布；
  • 這不是在任何公共和冷凍兼容性矩陣，該框架支持。

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

舊版FCM

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

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

發行的FCM版本

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

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