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 gestellt werden. Als Teil des FCM-Lebenszyklus veraltet und entfernt Android HIDL-HALs und modifiziert 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, auch HIDL-HALs mit denselben Methoden verwerfen und entfernen.

Terminologie

Framework-Kompatibilitätsmatrix (FCM) Eine XML-Datei, die Rahmenbedingungen für konforme Anbieterimplementierungen spezifiziert. Die Kompatibilitätsmatrix ist versioniert, und für jede Framework-Version wird eine neue Version eingefroren. Jede Framework-Version enthält mehrere FCMs.
Plattform-FCM-Versionen (S F ) Die Menge aller FCM-Versionen in einem Framework-Release. Das Framework kann mit jeder Anbieterimplementierung arbeiten, die eines dieser FCMs erfüllt.
FCM-Version (F) Die höchste Version unter allen FCMs in einer Framework-Version.
Ziel-FCM-Version (V) Die gezielte FCM-Version (von S F ), die explizit im Gerätemanifest deklariert ist, dass eine Anbieterimplementierung erfüllt. Eine Anbieterimplementierung muss für einen veröffentlichten FCM generiert werden, obwohl er 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; 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 Herstellerschnittstelle, einschließlich der Hersteller- 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 relativ zu dem FCM, 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 an konforme Framework-Implementierungen spezifiziert. Jedes Gerät enthält ein DCM.
Framework-Manifest Eine XML-Datei, die angibt, welche HAL-Versionen die Framework-Seite der Herstellerschnittstelle, einschließlich system, system_ext und Produktimages, bereitstellt. HALs im Frameworkmanifest werden gemäß der Ziel-FCM-Version des Geräts dynamisch deaktiviert.
Framework-HALs HALs, die im Rahmenmanifest als bereitgestellt und in der Gerätekompatibilitätsmatrix (DCM) entweder als erforderlich oder optional aufgeführt sind.

Entwickeln 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.current.xml “ erstellt ( F ) und die vorhandene „ compatibility_matrix.f.xml “ (wobei f < F ) nicht mehr geändert.

Um mit der Entwicklung einer neuen FCM-Version F zu beginnen:

  1. Kopieren Sie die neueste compatibility_matrix.<F-1>.xml nach " compatibility_matrix.current.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.

Einführung einer neuen HAL

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

  • optional="false" , wenn Geräte, die mit V = F ausgeliefert werden, mit dieser HAL starten müssen,

    ODER
  • optional="true" , wenn Geräte, die mit V = F ausgeliefert werden, ohne diese HAL starten können.

Beispielsweise wurde mit Android 8.1 cas@1.0 als optionale 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.current.xml “ hinzugefügt (nach der Veröffentlichung von Android 8.1 in „ compatibility_matrix.2.xml “ umbenannt):

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

Upgrade einer HAL (minor)

Wenn während der Entwicklung eine HAL ein Unterversions-Upgrade von xz auf x.(z+1) in 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.current.xmlx.(z+1) und optional="false" .
  • Auf Geräten, die mit V = F gestartet werden, nicht erforderlich, muss die Datei „ compatibility_matrix.current.xmlxy-z und Optionalität aus compatibility_matrix.<F-1>.xml kopieren und die Version in xw-(z+1) “ ändern (wobei „ w >= y ).

Beispielsweise wurde mit Android 8.1 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.current.xml compatibility_matrix.2.xml umbenannt) 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>

Upgrade einer HAL (groß)

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

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

Beispielsweise führt Android 9 health@2.0 als Hauptversions-Upgrade der 1.0-HAL ein und verwirft die 1.0-HAL. Die ältere Version, health@1.0 , ist optional für Geräte, die mit Android 8.0 und Android 8.1 gestartet werden. Geräte, die mit Android 9 gestartet werden, dürfen nicht die veraltete HAL 1.0 bereitstellen und müssen stattdessen die neue Version 2.0 bereitstellen. In 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 in die Datei „ compatibility_matrix.3.xml “ (mit der Version von Android 9 in „ compatibility_matrix.current.xml “ umbenannt) 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 2.0-HAL in der Datei „ compatibility_matrix.3.xml “ mit optional="false" befindet, müssen Geräte, die mit Android 9 gestartet werden, mit 2.0-HAL ausgeliefert werden.
  • Da die 1.0-HAL nicht in compatibility_matrix.3.xml enthalten ist, dürfen Geräte, die mit Android 9 gestartet werden, die 1.0-HAL nicht bereitstellen (da diese HAL als veraltet gilt).
  • Da die 1.0-HAL in „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 betrachtet wird). ).

Neue FCM-Versionen

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

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

Diese Datei kann nach dem Umbenennen und Veröffentlichen nicht mehr geändert werden. Beispielsweise werden während der Entwicklung von Android 9 die folgenden Dateien für hardware/interfaces/compatibility_matrices/ :

  • compatibility_matrix.legacy.xml
  • compatibility_matrix.1.xml
  • compatibility_matrix.2.xml
  • compatibility_matrix.current.xml

Wenn Android 9 veröffentlicht wird, wird „ compatibility_matrix.current.xml “ in „ compatibility_matrix.3.xml “ umbenannt und die folgenden Dateien werden für hardware/interfaces/compatibility_matrices/ :

  • compatibility_matrix.legacy.xml
  • compatibility_matrix.1.xml
  • compatibility_matrix.2.xml
  • compatibility_matrix.3.xml

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

Zusätzlich können die Produkt- und System_ext-FCMs auch Anforderungen für jede Plattform-FCM-Versionen auflisten. Die Freigabe von FCM-Versionen auf den Produkt- und system_ext-Partitionen erfolgt jeweils durch den Eigentümer dieser Images. 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 Ziel-FCM-Version F wider.

Veraltung der HAL-Version

Das Verwerfen einer HAL-Version ist eine Entscheidung des Entwicklers (dh für AOSP-HALs trifft Google die Entscheidung). Es könnte passieren, wenn eine höhere HAL-Version (ob Minor oder Major) veröffentlicht wird.

Veralten Sie eine Geräte-HAL

Wenn eine bestimmte Geräte-HAL foo@xy bei FCM-Version F veraltet ist, bedeutet dies, dass jedes Gerät, das mit Ziel-FCM-Version V = F oder höher gestartet wird, foo nicht bei Version xy oder einer Version älter 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 in der neuesten FCM für die Ziel-FCM-Version V = F angegeben ist. Für Geräte, die mit V = F gestartet werden, trifft eine der folgenden Bedingungen zu:

  • 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.

Veralten Sie eine Framework-HAL

Wenn eine bestimmte Framework-HAL foo@xy bei FCM-Version F veraltet ist, bedeutet dies, dass jedes Gerät, das mit Ziel-FCM-Version V = F oder höher gestartet wird, nicht erwarten darf, dass das Framework foo bei Version xy oder bei einer Version vor xy bereitstellt. Eine veraltete HAL-Version wird weiterhin vom Framework zum Aktualisieren von Geräten 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 die HAL foo@xy nicht bereit. Die Gerätekompatibilitätsmatrix auf Geräten, die mit V = F starten, 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 Ziel-FCM-Versionen

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:

  • Entfernen von „ compatibility_matrix.V.xml “ aus den Buildregeln (damit es nicht auf dem Systemabbild installiert wird) und Löschen von Code, der die entfernte Funktionalität implementiert oder von ihr abhängt.
  • Entfernen von Framework-HALs mit max-level kleiner oder gleich V aus dem Framework-Manifest und Löschen von Code, 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

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

  • Während der Entwicklung von Android 9 (bevor compatibiility_matrix.current.xml in compatibility_matrix.3.xml umbenannt wurde) galt die HAL health@2.0 als unveröffentlichte HAL.
  • Die teleportation@1.0 ist in keiner veröffentlichten Kompatibilitätsmatrix enthalten und wird auch als unveröffentlichte HAL betrachtet.

Wenn sich eine HAL-Version für Framework-HALs nur im Framework-Manifest eines nicht verwandten Entwicklungszweigs befindet, gilt sie als unveröffentlicht.

Freigegeben und aktuell

Wenn sich eine HAL-Version für Geräte-HALs in einer öffentlichen und eingefrorenen Kompatibilitätsmatrix befindet, wird sie freigegeben. Nachdem beispielsweise FCM Version 3 eingefroren (wenn compatibiility_matrix.current.xml in compatibility_matrix.3.xml umbenannt wurde) und in AOSP veröffentlicht wurde, wird die HAL health@2.0 als freigegebene und aktuelle HAL-Version betrachtet.

Wenn sich eine HAL-Version in einer öffentlichen und eingefrorenen Kompatibilitätsmatrix befindet, die die höchste FCM-Version hat (mit Ausnahme von compatibility_matrix.current.xml ), ist die HAL-Version aktuell (dh nicht veraltet). Zum Beispiel werden bestehende HAL-Versionen (wie nfc@1.0 eingeführt in compatibility_matrix.legacy.xml ), die weiterhin in compatibility_matrix.3.xml existieren, ebenfalls als freigegebene und aktuelle HAL-Versionen betrachtet.

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

Freigegeben, aber veraltet

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

  • Es wird freigegeben.
  • Es befindet sich nicht in der öffentlichen und eingefrorenen Kompatibilitätsmatrix mit der höchsten FCM-Version.
  • Es befindet sich in einer öffentlichen und eingefrorenen Kompatibilitätsmatrix, die das Framework weiterhin unterstützt.

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 mit einem Attribut „ max-level “ befindet, das niedriger ist als die in diesem Zweig veröffentlichte FCM-Version, wird sie als veröffentlichte, aber veraltete HAL-Version betrachtet. Beispielsweise ist der schedulerservice HAL in Android 12 veröffentlicht, aber veraltet, wie von der angegeben Android 12framework manifest .

ENTFERNT

Bei Geräte-HALs wird eine HAL-Version nur 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, eingefroren, aber nicht vom Framework unterstützt werden, werden in der Codebasis aufbewahrt, um die entfernten HAL-Versionen zu definieren, sodass VTS-Tests geschrieben werden können, um sicherzustellen, dass sich entfernte HALs nicht auf neuen Geräten befinden.

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

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

Legacy-FCMs

Target FCM Version Legacy ist ein besonderer Wert für alle Nicht-Treble-Geräte. Die 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 eingeführt wurden).

Wenn diese Datei für einen FCM mit Version F vorhanden ist, kann jedes Nicht-Treble-Gerät auf F aktualisiert werden, vorausgesetzt, sein Gerätemanifest ist mit dieser Datei kompatibel. Seine Entfernung folgt dem gleichen Verfahren wie FCMs für andere Ziel-FCM-Versionen (entfernt, nachdem die Anzahl aktiver Geräte vor 8.0 unter einen bestimmten Schwellenwert gefallen ist).

Veröffentlichte FCM-Versionen

Die Liste der freigegebenen FCM-Versionen finden Sie unter hardware/interfaces/compatibility_matrices .

Die mit einer bestimmten Android-Version veröffentlichte FCM-Version finden Sie unter Level.h .