FCM-Lebenszyklus

Eine Android-Framework-Version verfügt über mehrere Framework-Kompatibilitätsmatrizen (FCMs), eine für jede aktualisierbare Ziel-FCM-Version, die definieren, was das Framework verwenden darf und welche Anforderungen an die Ziel-FCM-Version gelten. Als Teil des FCM-Lebenszyklus veraltet und entfernt Android HIDL-HALs und ändert dann FCM-Dateien, um den Status der HAL-Version widerzuspiegeln.

Um reine Framework-OTAs in ihren eigenen Ökosystemen zu ermöglichen, sollten Partner, die Anbieterschnittstellen erweitern, mit denselben Methoden auch HIDL-HALs ablehnen und entfernen.

Terminologie

Framework-Kompatibilitätsmatrix (FCM)
Eine XML-Datei, die Framework-Anforderungen für konforme Anbieterimplementierungen angibt. Die Kompatibilitätsmatrix wird versioniert und für jede Framework-Version wird eine neue Version eingefroren. Jede Framework-Version enthält mehrere FCMs.
Plattform-FCM-Versionen ( SF )
Der Satz aller FCM-Versionen in einem Framework-Release. Das Framework kann mit jeder Anbieterimplementierung verwendet werden, die einen dieser FCMs erfüllt.
FCM-Version (F)
Die höchste Version aller FCMs in einer Framework-Version.
Ziel-FCM-Version (V)
Die gezielt im Gerätemanifest deklarierte FCM-Version (von S F ), die eine Anbieterimplementierung erfüllt. Eine Anbieterimplementierung muss für einen veröffentlichten FCM generiert werden, obwohl dieser möglicherweise neuere HAL-Versionen in seinem Gerätemanifest deklariert.
HAL-Version
Eine HAL-Version hat das Format foo@xy , wobei foo der HAL-Name und xy die spezifische Version ist; z. B. nfc@1.0 , keymaster@3.0 (das Root-Präfix, z. B. android.hardware , wird in diesem Dokument weggelassen.)
Gerätemanifest
XML-Dateien, die angeben, welche HAL-Versionen die Geräteseite der Anbieterschnittstelle, einschließlich der Anbieter- und ODM-Images, bereitstellt. Der Inhalt eines Gerätemanifests wird durch die Ziel-FCM-Version des Geräts eingeschränkt, kann jedoch HALs auflisten, die im Vergleich zum FC, der V entspricht, streng neuer sind.
Geräte-HALs
HALs, die im Gerätemanifest aufgeführt (bereitgestellt) und in der Framework-Kompatibilitätsmatrix (FCM) aufgeführt (entweder erforderlich oder optional) sind.
Gerätekompatibilitätsmatrix (DCM)
Eine XML-Datei, die Anbieteranforderungen für konforme Framework-Implementierungen angibt. Jedes Gerät enthält einen DCM.
Framework-Manifest
Eine XML-Datei, die angibt, welche HAL-Versionen die Framework-Seite der Anbieterschnittstelle, einschließlich System, system_ext und Produktbilder, bereitstellt. HALs im Framework-Manifest werden entsprechend der Ziel-FCM-Version des Geräts dynamisch deaktiviert.
Framework-HALs
HALs, die wie im Framework-Manifest bereitgestellt und in der Gerätekompatibilitätsmatrix (DCM) als erforderlich oder optional aufgeführt sind.

FCM-Lebenszyklus in der Codebasis

Dieses Dokument beschreibt den FCM-Lebenszyklus in einer Zusammenfassung. Informationen zu den derzeit unterstützten Manifesten finden Sie unter hardware/interfaces/compatibility_matrix.<FCM>.xml , wo FCM in system/libvintf/include/vintf/Level.h zu finden ist.

Ab Android 14 sind die unterstützten Level:

FCM Android-Version
4 Android 10/Q
5 Android 11/R
6 Android 12/S
7 Android 13/T
8 Android 14/U

Entwicklung in einer neuen FCM-Version

Android erhöht die FCM-Version für jede Framework-Version (z. B. Android 8, 8.1 usw.). Während der Entwicklung wird die neue compatibility_matrix.F.xml erstellt und die vorhandene compatibility_matrix.f.xml (wobei f < F ) nicht mehr geändert.

So beginnen Sie mit der Entwicklung einer neuen FCM-Version F :

  1. Kopieren Sie die neueste compatibility_matrix.<F-1>.xml nach compatibility_matrix.F.xml .
  2. Aktualisieren Sie das level in der Datei auf F .
  3. Fügen Sie entsprechende Build-Regeln hinzu, um diese Kompatibilitätsmatrix auf dem Gerät zu installieren.

Wir stellen einen neuen HAL vor

Wenn Sie während der Entwicklung ein neues HAL (Wi-Fi, NFC usw.) in Android auf der aktuellen FCM-Version F einführen, fügen Sie das HAL mit den folgenden optional Einstellungen zu compatibility_matrix.F.xml hinzu:

  • optional="false" , wenn Geräte, die mit V = F ausgeliefert werden, mit diesem HAL gestartet werden müssen,
  • optional="true" , wenn Geräte, die mit V = F ausgeliefert werden, ohne diesen HAL gestartet werden können.

Mit Android 8.1 wurde beispielsweise cas@1.0 als optionales HAL eingeführt. Geräte, die mit Android 8.1 gestartet werden, müssen diese HAL nicht implementieren, daher wurde der folgende Eintrag zu compatibility_matrix.F.xml “ hinzugefügt (die während der Entwicklung dieser Version vorübergehend compatibility_matrix.current.xml “ hieß):

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

Upgrade eines HAL (geringfügig)

Wenn während der Entwicklung ein HAL ein Nebenversions-Upgrade von xz auf x.(z+1) bei der aktuellen FCM-Version F hat, wenn diese Version ist:

  • Erforderlich auf Geräten, die mit V = F gestartet werden, muss die Datei compatibility_matrix.F.xml x.(z+1) und optional="false" angeben.
  • Auf Geräten, die mit V = F gestartet werden, ist dies nicht erforderlich. compatibility_matrix.F.xml muss xy-z und Optionalität aus compatibility_matrix.<F-1>.xml kopieren und die Version in xw-(z+1) ändern (wobei w >= y ).

Mit Android 8.1 wurde beispielsweise broadcastradio@1.1 als Nebenversions-Upgrade von 1.0 HAL eingeführt. Die ältere Version, broadcastradio@1.0 , ist optional für Geräte, die mit Android 8.0 starten, während die neuere Version, broadcastradio@1.1 , optional für Geräte ist, die mit Android 8.1 starten. In 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>

Dieser Eintrag wurde nach compatibility_matrix.F.xml kopiert und wie folgt geändert:

<hal format="hidl" optional="true">
    <name>android.hardware.broadcastradio</name>
    <version>1.0-1</version>
    <interface>
        <name>IBroadcastRadioFactory</name>
        <instance>default</instance>
    </interface>
</hal>

Aktualisieren Sie einen HAL (Hauptversion)

Wenn während der Entwicklung ein HAL ein Hauptversions-Upgrade auf die aktuelle FCM-Version F durchführt, wird die neue Hauptversion x.0 zu compatibility_matrix.F.xml mit den folgenden optional Einstellungen hinzugefügt:

  • optional="false" nur mit Version x.0 , wenn Geräte, die mit V = F ausgeliefert werden, mit x.0 gestartet werden müssen.
  • optional="false" , aber zusammen mit älteren Hauptversionen im selben <hal> -Tag, wenn Geräte, die mit V = F ausgeliefert werden, mit diesem HAL starten müssen, aber mit einer älteren Hauptversion starten können.
  • optional="true" , wenn Geräte, die mit V = F ausgeliefert werden, die HAL nicht starten müssen.

Beispielsweise führt Android 9 health@2.0 als Hauptversions-Upgrade von 1.0 HAL ein und veraltet 1.0 HAL. Die ältere Version, health@1.0 , ist optional für Geräte, die mit Android 8.0 und Android 8.1 starten. Geräte, die mit Android 9 gestartet werden, dürfen nicht die veraltete Version 1.0 HAL bereitstellen, sondern müssen stattdessen die neue Version 2.0 bereitstellen. I compatibility_matrix.legacy.xml , compatibility_matrix.1.xml und 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>

Dieser Eintrag wird nach compatibility_matrix.F.xml kopiert und wie folgt geändert:

<hal format="hidl" optional="false">
    <name>android.hardware.health</name>
    <version>2.0</version>
    <interface>
        <name>IHealth</name>
        <instance>default</instance>
    </interface>
</hal>

Einschränkungen:

  • Da sich die HAL-Version 2.0 in der Datei „ compatibility_matrix.3.xml “ mit optional="false" befindet, müssen Geräte, die mit Android 9 gestartet werden, mit der HAL-Version 2.0 ausgeliefert werden.`
  • Da sich die HAL-Version 1.0 nicht in compatibility_matrix.3.xml befindet, dürfen Geräte, die mit Android 9 gestartet werden, die HAL-Version 1.0 nicht bereitstellen (da diese HAL als veraltet gilt).
  • Da die 1.0-HAL in der Datei „legacy/1/2.xml“ (ältere FCM-Versionen, mit denen Android 9 arbeiten kann) als optionale HAL vorhanden ist, kann das Android 9-Framework weiterhin mit der 1.0-HAL arbeiten (die nicht als entfernte HAL-Version gilt). ).

Neue FCM-Versionen

Der Prozess der Veröffentlichung einer FCM-Version auf der Systempartition wird ausschließlich von Google als Teil einer AOSP-Version durchgeführt und umfasst die folgenden Schritte:

  1. Stellen Sie sicher, dass die compatibility_matrix.F.xml das Attribut level="F" hat.
  2. Stellen Sie sicher, dass alle Geräte erstellt und gestartet werden.
  3. Aktualisieren Sie die VTS-Tests, um sicherzustellen, dass Geräte, die mit dem neuesten Framework (basierend auf der Versand-API-Ebene) gestartet werden, über die Ziel-FCM-Version V >= F verfügen.
  4. Veröffentlichen Sie die Datei auf AOSP.

VTS-Tests stellen beispielsweise sicher, dass Geräte, die mit Android 9 gestartet werden, eine Ziel-FCM-Version >= 3 haben.

Darüber hinaus können die FCMs „product“ und „system_ext“ auch Anforderungen für die FCM-Versionen der einzelnen Plattformen auflisten. Die Veröffentlichung von FCM-Versionen auf den Partitionen „product“ und „system_ext“ erfolgt jeweils durch den Eigentümer dieser Images. Die FCM-Versionsnummern auf den Produkt- und system_ext-Partitionen müssen mit denen auf der Systempartition übereinstimmen. Ähnlich wie bei FCM-Versionen auf der Systempartition spiegelt die Kompatibilitätsmatrix bei FCM-Version F in den Partitionen „product“ und „system_ext“ die Anforderungen an ein Gerät mit der Ziel-FCM-Version F wider.

Einstellung der HAL-Version

Das Verwerfen einer HAL-Version ist eine Entscheidung des Entwicklers (d. h. bei AOSP-HALs trifft Google die Entscheidung). Dies könnte passieren, wenn eine höhere HAL-Version (ob Neben- oder Hauptversion) veröffentlicht wird.

Verwerfen Sie ein Gerät als HAL

Wenn ein bestimmtes Geräte-HAL foo@xy bei FCM-Version F veraltet ist, bedeutet das, dass jedes Gerät, das mit der Ziel-FCM-Version V = F oder höher gestartet wird, foo nicht bei Version xy oder einer älteren Version als xy implementieren darf. Eine veraltete HAL-Version wird weiterhin vom Framework zum Aktualisieren von Geräten unterstützt.

Wenn die FCM-Version F veröffentlicht wird, gilt eine HAL-Version foo@xy als veraltet, wenn die spezifische HAL-Version nicht explizit im neuesten FCM für die Ziel-FCM-Version V = F angegeben ist. Für Geräte, die mit V = F starten, gilt eine der folgenden Bedingungen:

  • Das Framework erfordert eine höhere Version (Haupt- oder Nebenversion);
  • Das Framework benötigt die HAL nicht mehr.

Beispielsweise wird in Android 9 health@2.0 als Hauptversions-Upgrade von 1.0 HAL eingeführt. health@1.0 wurde aus compatibility_matrix.3.xml entfernt, ist aber in compatibility_matrix.legacy.xml “, compatibility_matrix.1.xml “ und „Compatibility_matrix.2.xml“ vorhanden. Daher gilt health@1.0 als veraltet.

Verwerfen Sie ein Framework-HAL

Wenn ein bestimmtes Framework-HAL foo@xy bei FCM-Version F veraltet ist, bedeutet dies, dass jedes Gerät, das mit der Ziel-FCM-Version V = F oder höher gestartet wird, nicht damit rechnen darf, dass das Framework foo bei Version xy oder einer älteren Version als xy bereitstellt. Für die Aktualisierung von Geräten wird vom Framework weiterhin eine veraltete HAL-Version bereitgestellt.

Wenn die FCM-Version F veröffentlicht wird, gilt eine HAL-Version foo@xy als veraltet, wenn das Framework-Manifest max-level=" F - 1 " für foo@xy angibt. Für Geräte, die mit V = F gestartet werden, stellt das Framework den HAL foo@xy nicht bereit. Die Gerätekompatibilitätsmatrix auf Geräten, die mit V = F gestartet werden, darf keine Framework-HALs mit max-level < V auflisten.

In Android 12 ist beispielsweise schedulerservice@1.0 veraltet. Sein max-level Attribut ist auf 5 gesetzt, die in Android 11 eingeführte FCM-Version. Siehe Android 12-Framework-Manifest .

Entfernung der Unterstützung für FCM-Zielversionen

Wenn aktive Geräte einer bestimmten Ziel-FCM-Version V unter einen bestimmten Schwellenwert fallen, wird die Ziel-FCM-Version aus dem Satz S F der nächsten Framework-Version entfernt. Dies geschieht durch die beiden folgenden Schritte:

  1. Entfernen Sie compatibility_matrix.V.xml aus den Build-Regeln (damit es nicht auf dem Systemabbild installiert wird) und löschen Sie jeglichen Code, der die entfernte Funktionalität implementiert oder davon abhängt.

  2. Entfernen von Framework-HALs mit max-level kleiner oder gleich V aus dem Framework-Manifest und Löschen jeglichen Codes, der die entfernten Framework-HALs implementiert.

Geräte mit einer Ziel-FCM-Version außerhalb von S F für eine bestimmte Framework-Version können nicht auf diese Version aktualisiert werden.

HAL-Versionsstatus

Die folgenden Abschnitte beschreiben (in chronologischer Reihenfolge) die möglichen Zustände einer HAL-Version.

Unveröffentlicht

Bei Geräte-HALs gilt: Wenn eine HAL-Version in keiner der öffentlichen und eingefrorenen Kompatibilitätsmatrizen enthalten ist, gilt sie als unveröffentlicht und möglicherweise in der Entwicklung. Dies schließt HAL-Versionen ein, die nur in compatibility_matrix.F.xml enthalten sind. Beispiele:

  • Während der Entwicklung von Android 9 galt die HAL health@2.0 als unveröffentlichte HAL und war nur in compatibility_matrix.3.xml vorhanden.
  • Die teleportation@1.0 HAL ist in keiner veröffentlichten Kompatibilitätsmatrix enthalten und gilt auch als unveröffentlichte HAL.

Bei Framework-HALs gilt: Wenn eine HAL-Version nur im Framework-Manifest eines nicht verwandten Entwicklungszweigs enthalten ist, gilt sie als unveröffentlicht.

Freigegeben und aktuell

Bei Geräte-HALs gilt: Wenn sich eine HAL-Version in einer öffentlichen und eingefrorenen Kompatibilitätsmatrix befindet, wird sie veröffentlicht. Nachdem beispielsweise FCM Version 3 eingefroren und auf AOSP veröffentlicht wurde, gilt die HAL health@2.0 als freigegebene und aktuelle HAL-Version.

Wenn sich eine HAL-Version in einer öffentlichen und eingefrorenen Kompatibilitätsmatrix befindet, die die höchste FCM-Version aufweist, ist die HAL-Version aktuell (dh nicht veraltet). Beispielsweise werden vorhandene HAL-Versionen (z. B. nfc@1.0 , eingeführt in compatibility_matrix.legacy.xml ), die weiterhin in compatibility_matrix.3.xml vorhanden sind, ebenfalls als veröffentlichte und aktuelle HAL-Versionen betrachtet.

Wenn sich bei Framework-HALs eine HAL-Version im Framework-Manifest des zuletzt veröffentlichten Zweigs ohne das Attribut max-level “ oder (ungewöhnlich) mit einem max-level gleich oder höher als die in diesem Zweig veröffentlichte FCM-Version befindet, gilt sie als veröffentlicht und aktuelle HAL-Version. Beispielsweise ist der displayservice HAL in Android 12 veröffentlicht und aktuell, wie im Android 12-Framework-Manifest angegeben.

Veröffentlicht, aber veraltet

Für Geräte-HALs ist eine HAL-Version genau dann veraltet, wenn alle folgenden Bedingungen erfüllt sind:

  • Es wird freigegeben.
  • Die höchste FCM-Version befindet sich nicht in der öffentlichen und eingefrorenen Kompatibilitätsmatrix.
  • Das Framework unterstützt weiterhin eine öffentliche und eingefrorene Kompatibilitätsmatrix.

Beispiele:

Daher ist power@1.0 in Android 9 aktuell, aber NICHT veraltet.

Wenn sich bei Framework-HALs eine HAL-Version im Framework-Manifest des zuletzt veröffentlichten Zweigs befindet und ein max-level Attribut aufweist, das niedriger ist als die FCM-Versionsversion in diesem Zweig, gilt sie als veröffentlichte, aber veraltete HAL-Version. Beispielsweise ist der schedulerservice HAL in Android 12 veröffentlicht, aber veraltet, wie im Android 12-Framework-Manifest angegeben.

ENTFERNT

Bei Geräte-HALs wird eine HAL-Version genau dann entfernt, wenn Folgendes zutrifft:

  • Es wurde zuvor veröffentlicht.
  • Es befindet sich in keiner öffentlichen und eingefrorenen Kompatibilitätsmatrix, die das Framework unterstützt.

Kompatibilitätsmatrizen, die öffentlich und eingefroren sind, aber vom Framework nicht unterstützt werden, werden in der Codebasis gespeichert, um die entfernten HAL-Versionen zu definieren, damit VTS-Tests geschrieben werden können, um sicherzustellen, dass entfernte HALs nicht auf neuen Geräten vorhanden sind.

Bei Framework-HALs wird eine HAL-Version genau dann entfernt, wenn Folgendes erfüllt ist:

  • Es wurde zuvor veröffentlicht.
  • Es ist in keinem Framework-Manifest des zuletzt veröffentlichten Zweigs enthalten.

Ältere FCMs

Die veraltete Ziel-FCM-Version ist ein besonderer Wert für alle Nicht-Treble-Geräte. Der Legacy-FCM, compatibility_matrix.legacy.xml , listet die Anforderungen des Frameworks auf Legacy-Geräten auf (d. h. Geräte, die vor Android 8.0 gestartet wurden).

Wenn diese Datei für ein FCM mit Version F vorhanden ist, kann jedes Nicht-Treble-Gerät auf F aktualisiert werden, sofern sein Gerätemanifest mit dieser Datei kompatibel ist. Die Entfernung erfolgt nach dem gleichen Verfahren wie bei FCMs für andere FCM-Zielversionen (entfernt, nachdem die Anzahl der aktiven Geräte vor 8.0 unter einen bestimmten Schwellenwert fällt).

Veröffentlichte FCM-Versionen

Die Liste der veröffentlichten FCM-Versionen finden Sie unter hardware/interfaces/compatibility_matrices .

Informationen zur FCM-Version, die mit einer bestimmten Android-Version veröffentlicht wurde, finden Sie unter Level.h .