Google is committed to advancing racial equity for Black communities. See how.
本頁面由 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.0keymaster@3.0 (本文檔中省略了根前綴,例如android.hardware 。)
設備清單一個XML文件,用於指定供應商映像提供的HAL版本。設備清單的內容受設備的目標FCM版本限制,但可以列出相對於與V對應的FCM嚴格更新的HAL。

在新的FCM版本中進行開發

Android為每個框架版本(例如Android 8、8.1等)增加FCM版本。在開發過程中,將創建新的compatibility_matrix.current.xmlF ),而現有的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.xmlcompatibility_matrix.1.xmlcompatibility_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.xmlcompatibility_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.xmlcompatibility_matrix.1.xmlcompatibility_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