Diese Seite wurde von der Cloud Translation API übersetzt.

FCM-Lebenszyklus

Eine Android-Frameworkversion hat mehrere Framework Compatibility Matrices (FCMs), eine für jede aufrüstbare Ziel-FCM-Version. Darin wird definiert, was das Framework verwenden darf und welche Anforderungen an die Ziel-FCM-Version gelten. Im Rahmen des FCM-Lebenszyklus werden HIDL HALs von Android eingestellt und entfernt. Anschließend werden FCM-Dateien so geändert, dass der Status der HAL-Version widergespiegelt wird.

Um nur-Framework-OTAs in ihren eigenen Systemen zu ermöglichen, sollten Partner, die Anbieterschnittstellen erweitern, auch HIDL HALs mit denselben Methoden verwerfen und entfernen.

Terminologie

Framework Compatibility Matrix (FCM): Eine XML-Datei, die die Frameworkanforderungen an konforme Anbieterimplementierungen angibt. Die Kompatibilitätsmatrix ist versioniert und für jeden Framework-Release wird eine neue Version eingefroren. Jede Framework-Version enthält mehrere FCMs.
Plattform-FCM-Versionen (S_F): Die Gesamtheit aller FCM-Versionen in einem Framework-Release. Das Framework kann mit jeder Anbieterimplementierung verwendet werden, die eine dieser FCMs erfüllt.
FCM-Version (F): Die höchste Version aller FCMs in einem Framework-Release.
Ziel-FCM-Version (V): Die angestrebte FCM-Version (von S_F), die im Gerätemanifest explizit deklariert ist und die eine Anbieterimplementierung erfüllt. Eine Anbieterimplementierung muss anhand eines veröffentlichten FCM generiert werden, kann aber neuere HAL-Versionen in ihrem Gerätemanifest deklarieren.
HAL-Version: Eine HAL-Version hat das Format foo@x.y, wobei foo der HAL-Name und x.y die jeweilige Version ist, z. B. nfc@1.0, keymaster@3.0. Das Stammpräfix, z. B. android.hardware, wird in diesem Dokument nicht verwendet.
Gerätemanifest: XML-Dateien, die angeben, welche HAL-Versionen die geräteseitige Anbieteroberfläche, einschließlich der Anbieter- und ODM-Images, bereitstellt. Der Inhalt eines Gerätemanifests ist durch die Ziel-FCM-Version des Geräts eingeschränkt, kann aber HALs enthalten, die im Vergleich zum FC, der V entspricht, deutlich neuer sind.
Geräte-HALs: HALs, die im Gerätemanifest und in der Framework-Kompatibilitätsmatrix (FCM) aufgeführt sind.
Gerätekompatibilitätsmatrix (Device Compatibility Matrix, DCM): Eine XML-Datei, die die Anforderungen der Anbieter an konforme Framework-Implementierungen angibt. Jedes Gerät enthält eine DCM.
Framework-Manifest: Eine XML-Datei, in der angegeben ist, welche HAL-Versionen die Framework-Seite der Anbieterschnittstelle bereitstellt, einschließlich System-, System_ext- und Produktbildern. HALs im Framework-Manifest werden dynamisch gemäß der Ziel-FCM-Version des Geräts deaktiviert.
Framework HALs: HALs, die im Framework-Manifest und in der Gerätekompatibilitätsmatrix (DCM) aufgeführt sind.

FCM-Lebenszyklus in der Codebasis

In diesem Dokument wird der FCM-Lebenszyklus in der Zusammenfassung beschrieben. Die unterstützten Manifeste finden Sie unter hardware/interfaces/compatibility_matrix.<FCM>.xml, wo sich FCM in system/libvintf/include/vintf/Level.h befindet.

Auf einem Gerät mit der entsprechenden Android-Releaseversion muss der FCM-Wert mindestens dem entsprechenden Level entsprechen. Ein Gerät mit Android 11 hat beispielsweise in der Regel FCM-Level 5, implementiert aber FCM-Level 6 oder höher. Dies hat verschiedene zusätzliche Anforderungen zur Folge, die in den Kompatibilitätsmatrizen angegeben sind. Folgende Stufen werden unterstützt:

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

Die FCM-Ebene ist gleich oder neuer als die API-Ebene des Anbieters.

Wenn eine FCM-Ebene von Android eingestellt wird, wird sie weiterhin für bestehende Geräte unterstützt. Geräte, die auf niedrigere FCM-Ebenen ausgerichtet sind, dürfen implizit HALs verwenden, die in neueren FCM-Ebenen aufgeführt sind, sofern sie im Branch verfügbar sind.

In einer neuen FCM-Version entwickeln

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

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

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

Neue HAL einführen

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

Mit Android 8.1 wurde beispielsweise cas@1.0 eingeführt. Geräte, die mit Android 8.1 auf den Markt kommen, können diese HAL implementieren. Daher wurde der folgende Eintrag zu compatibility_matrix.F.xml hinzugefügt (dieser hieß während der Entwicklung dieser Version vorübergehend 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 (Nebenversion) aktualisieren

AIDL-HAL-Versionen gelten als HAL-Nebenversionen. HIDL-Schnittstellenversionen haben major.minor-Versionen wie 1.2.

Wenn während der Entwicklung ein AIDL HAL-Version von 2 auf 3 bei der aktuellen FCM-Version F aktualisiert wird, wird die neue Version dem HAL-Eintrag in compatibility_matrix.F.xml hinzugefügt. Im Versionsfeld eines HAL-Eintrags sind Bereiche wie 2-3 zulässig.

Beispiel: In Android FCM F wurde foo@3 als Nebenversionsupgrade der HAL eingeführt. Die ältere Version, foo@2, wird für Geräte verwendet, die auf ältere FCMs ausgerichtet sind. Die neuere Version, foo@3, kann für Geräte verwendet werden, die auf Android FCM F ausgerichtet sind. Der Eintrag in älteren FCMs vor Version 2 sieht so aus:

<hal format="aidl">
    <name>foo</name>
    <version>2</version>
    <interface>
        <name>IFoo</name>
        <instance>default</instance>
    </interface>
</hal>

Dieser Eintrag wurde in compatibility_matrix.F.xml kopiert und so geändert, dass er Version 3 unterstützt:

<hal format="aidl">
    <name>foo</name>
    <version>2-3</version>
    <interface>
        <name>IFoo</name>
        <instance>default</instance>
    </interface>
</hal>

HAL-Upgrade (wichtig)

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

Nur Version x.0, wenn Geräte, die mit V = F ausgeliefert werden, mit x.0 gestartet werden müssen.
Mit älteren Hauptversionen im selben <hal>-Tag, wenn Geräte, die mit V = F ausgeliefert werden, mit einer älteren Hauptversion gestartet werden können.

In FCM-Version F wird beispielsweise foo@2.0 als Major-Version-Upgrade der HAL 1.0 eingeführt und die HAL 1.0 wird eingestellt. Die ältere Version foo@1.0 wird für Geräte verwendet, die auf vorherige FCM-Versionen ausgerichtet sind. Geräte, die auf FCM-Version F ausgerichtet sind, müssen die neue Version 2.0 bereitstellen, wenn sie die HAL bereitstellen. In diesem Beispiel enthalten die vorherigen FCM-Versionen diesen Eintrag:

<hal format="hidl">
    <name>foo</name>
    <version>1.0</version>;
    <interface>
        <name>IFoo</name>
        <instance>default</instance>
    </interface>
</hal>

Kopieren Sie diesen Eintrag in compatibility_matrix.F.xml und ändern Sie ihn so:

<hal format="hidl">
    <name>foo</name>
    <version>2.0</version>
    <interface>
        <name>IFoo</name>
        <instance>default</instance>
    </interface>
</hal>

Einschränkungen:

Da die HAL 1.0 nicht in compatibility_matrix.F.xml enthalten ist, dürfen Geräte, die auf die FCM-Version F ausgerichtet sind, die HAL 1.0 nicht bereitstellen, da diese HAL als eingestellt gilt.
Da die HAL 1.0 in älteren FCM-Versionen vorhanden ist, kann das Framework weiterhin mit der HAL 1.0 verwendet werden. Daher ist es abwärtskompatibel mit älteren Geräten, die auf die älteren FCM-Versionen ausgerichtet sind.

Neue FCM-Versionen

Die Freigabe einer FCM-Version auf der Systempartition erfolgt ausschließlich von Google im Rahmen eines AOSP-Release und umfasst die folgenden Schritte:

Achten Sie darauf, dass das compatibility_matrix.F.xml das Attribut level="F" hat.
Prüfen Sie, ob alle Geräte erstellt und gestartet werden.
Aktualisieren Sie die VTS-Tests, damit Geräte, die mit dem neuesten Framework gestartet werden (basierend auf der Versand-API-Ebene), die Ziel-FCM-Version V >= F haben.
Datei im AOSP veröffentlichen.

Mit VTS-Tests wird beispielsweise sichergestellt, dass auf Geräten, die mit Android 9 ausgeliefert werden, die Ziel-FCM-Version >= 3 ist.

Außerdem können in den FCMs „product“ und „system_ext“ Anforderungen für die einzelnen FCM-Versionen der Plattform aufgeführt werden. Die Freigabe von FCM-Versionen auf den Partitionen „product“ und „system_ext“ erfolgt durch den jeweiligen Eigentümer dieser Images. Die FCM-Versionsnummern auf den Partitionen „product“ und „system_ext“ müssen mit denen auf der Systempartition übereinstimmen. Ähnlich wie bei FCM-Versionen in 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

Die Einstellung einer HAL-Version ist eine Entscheidung des Entwicklers. Bei AOSP-HALs trifft Google die Entscheidung. Das kann passieren, wenn eine höhere HAL-Version (egal ob Neben- oder Hauptversion) veröffentlicht wird.

HAL eines Geräts einstellen

Wenn eine bestimmte Geräte-HAL foo@x.y in der FCM-Version F eingestellt wird, bedeutet das, dass auf Geräten, die mit der Ziel-FCM-Version V = F oder höher gestartet werden, foo nicht in Version x.y oder einer älteren Version implementiert werden darf.x.y Eine eingestellte HAL-Version wird vom Framework weiterhin für das Upgrade von Geräten unterstützt.

Wenn die FCM-Version F veröffentlicht wird, gilt eine HAL-Version foo@x.y als eingestellt, wenn die jeweilige HAL-Version nicht ausdrücklich in der neuesten FCM-Version für die Ziel-FCM-Version V = F angegeben ist. Bei Geräten, die mit V = F gestartet werden, ist eine der folgenden Bedingungen erfüllt:

Für das Framework ist eine höhere Version (Haupt- oder Nebenversion) erforderlich.
Für das Framework ist die HAL nicht mehr erforderlich.

In Android 9 wird health@2.0 beispielsweise als Hauptversionsupgrade der 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 wird health@1.0 als eingestellt betrachtet.

HAL eines Frameworks einstellen

Wenn eine bestimmte HAL foo@x.y des Frameworks in der FCM-Version F eingestellt wird, bedeutet das, dass auf Geräten, die mit der Ziel-FCM-Version V = F oder höher gestartet werden, nicht davon ausgegangen werden darf, dass das Framework foo in Version x.y oder einer älteren Version bereitstellt.x.y Eine verworfene HAL-Version wird vom Framework weiterhin für das Upgrade von Geräten bereitgestellt.

Wenn die FCM-Version F veröffentlicht wird, gilt eine HAL-Version foo@x.y als eingestellt, wenn im Framework-Manifest max-level="F - 1" für foo@x.y angegeben ist. Für Geräte, die mit V = F gestartet werden, stellt das Framework nicht die HAL foo@x.y bereit. In der Gerätekompatibilitätsmatrix für Geräte, die mit V = F eingeführt werden, dürfen keine Framework-HALs mit max-level < V aufgeführt sein.

In Android 12 wird schedulerservice@1.0 beispielsweise eingestellt. Das max-level-Attribut ist auf 5 festgelegt, die FCM-Version, die in Android 11 eingeführt wurde. Siehe Android 12-Framework-Manifest.

Einstellung der Unterstützung für Ziel-FCM-Versionen

Wenn die Anzahl der aktiven Geräte einer bestimmten Ziel-FCM-Version V unter einen bestimmten Grenzwert fällt, wird die Ziel-FCM-Version aus dem Satz S_F der nächsten Framework-Version entfernt. Dazu gibt es zwei Möglichkeiten:

Entfernen Sie compatibility_matrix.V.xml aus den Build-Regeln, damit es nicht auf dem System-Image installiert wird, und löschen Sie den Code, der die entfernten Funktionen implementiert oder davon abhängig ist.
Entfernen Sie Framework-HALs mit einer max-level, die kleiner oder gleich V ist, aus dem Framework-Manifest und löschen Sie den Code, der die entfernten Framework-HALs implementiert.

Geräte mit einer Ziel-FCM-Version, die nicht zu S_F für eine bestimmte Framework-Version gehört, können nicht auf diese Version umgestellt werden.

HAL-Versionsstatus

In den folgenden Abschnitten werden die möglichen Status einer HAL-Version in chronologischer Reihenfolge beschrieben.

Unveröffentlicht

Wenn eine HAL-Version für Geräte nicht in einer der öffentlichen und eingefrorenen Kompatibilitätsmatrizen enthalten ist, gilt sie als nicht veröffentlicht und möglicherweise als in der Entwicklung befindlich. Dazu gehören auch HAL-Versionen, die nur in compatibility_matrix.F.xml verfügbar sind. Beispiele:

Während der Entwicklung von Android 9 galt die health@2.0 HAL 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 nicht veröffentlichte HAL.

Bei Framework-HALs gilt eine HAL-Version, die sich nur im Framework-Manifest eines nicht zugehörigen Entwicklungszweigs befindet, als nicht veröffentlicht.

Veröffentlicht und aktuell

Bei Geräte-HALs wird eine HAL-Version veröffentlicht, wenn sie in einer öffentlichen und eingefrorenen Kompatibilitätsmatrix enthalten ist. Nachdem beispielsweise FCM-Version 3 eingefroren und in AOSP veröffentlicht wurde, gilt die health@2.0 HAL als veröffentlichte und aktuelle HAL-Version.

Wenn sich eine HAL-Version in einer öffentlichen und eingefrorenen Kompatibilitätsmatrix mit der höchsten FCM-Version befindet, ist die HAL-Version aktuell (d.h. nicht eingestellt). Beispielsweise gelten vorhandene HAL-Versionen (z. B. nfc@1.0, eingeführt in compatibility_matrix.legacy.xml), die auch in compatibility_matrix.3.xml vorhanden sind, als veröffentlichte und aktuelle HAL-Versionen.

Bei Framework-HALs gilt eine HAL-Version im Framework-Manifest des zuletzt veröffentlichten Branches ohne das Attribut max-level oder (ungewöhnlich) mit einer max-level, die der in diesem Branch veröffentlichten FCM-Version entspricht oder höher ist, als veröffentlichte und aktuelle HAL-Version. Beispielsweise ist die displayservice HAL in Android 12 veröffentlicht und aktuell, wie im Android 12-Frameworkmanifest angegeben.

Veröffentlicht, aber nicht mehr unterstützt

Bei Geräte-HALs wird eine HAL-Version nur dann eingestellt, wenn alle folgenden Bedingungen erfüllt sind:

Es wird veröffentlicht.
Sie ist nicht in der öffentlichen und eingefrorenen Kompatibilitätsmatrix mit der höchsten FCM-Version enthalten.
Es ist in einer öffentlichen und unveränderlichen Kompatibilitätsmatrix aufgeführt, in der das Framework weiterhin unterstützt wird.

Beispiele:

Der health@1.0 HAL ist in compatibility_matrix.legacy.xml, compatibility_matrix.1.xml und compatibility_matrix.2.xml, aber nicht in compatibility_matrix.3.xml. Daher wird sie in Android 9 als veraltet betrachtet.
Die HAL für die Energieverwaltung hat in Android 9 ein Minor-Version-Upgrade erhalten, power@1.0 befindet sich jedoch noch in compatibility_matrix.3.xml.
power@1.0 compatibility_matrix.legacy.xml, compatibility_matrix.1.xml und compatibility_matrix.2.xml.
compatibility_matrix.3.xml hat power@1.0-1.

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

Bei Framework-HALs gilt eine HAL-Version im Framework-Manifest des zuletzt veröffentlichten Branches mit einem max-level-Attribut, das niedriger als die Version der FCM-Version in diesem Branch ist, als veröffentlichte, aber veraltete HAL-Version. Die schedulerservice HAL ist beispielsweise veröffentlicht, aber in Android 12 verworfen, wie im Android 12-Framework-Manifest angegeben.

Entfernt

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

Es wurde bereits veröffentlicht.
Es ist in keiner öffentlichen und eingefrorenen Kompatibilitätsmatrix aufgeführt, die vom Framework unterstützt wird.

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

Bei Framework-HALs wird eine HAL-Version nur dann entfernt, wenn folgende Bedingungen erfüllt sind:

Es wurde bereits veröffentlicht.
Es ist in keinem Framework-Manifest des zuletzt veröffentlichten Branches enthalten.

Legacy-FCMs

„Target FCM Version legacy“ ist ein spezieller Wert für alle Nicht-Treble-Geräte. In der Legacy-FCM-Version compatibility_matrix.legacy.xml sind die Anforderungen des Frameworks auf Legacy-Geräten (d.h. Geräten, die vor Android 8.0 auf den Markt gebracht wurden) aufgeführt.

Wenn diese Datei für einen FCM mit der Version F vorhanden ist, kann jedes Nicht-Treble-Gerät auf F aktualisiert werden, sofern das Gerätemanifest mit dieser Datei kompatibel ist. Das Entfernen erfolgt nach demselben Verfahren wie bei FCMs für andere Ziel-FCM-Versionen (entfernt, wenn die Anzahl der aktiven Geräte mit einer älteren Version als 8.0 unter einen bestimmten Grenzwert sinkt).

Veröffentlichte FCM-Versionen

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