Ab dem 27. März 2025 empfehlen wir, android-latest-release anstelle von aosp-main zu verwenden, um AOSP zu erstellen und Beiträge dazu zu leisten. Weitere Informationen finden Sie unter Änderungen am AOSP.

Diese Seite wurde von der Cloud Translation API übersetzt.

FCM-Lebenszyklus

Eine Android-Framework-Version hat mehrere Framework Compatibility Matrixes (FCMs), eine für jede aktualisierbare Ziel-FCM-Version, die definiert, was das Framework verwenden darf, und Anforderungen an die Ziel-FCM-Version. Im Rahmen des FCM-Lebenszyklus werden HIDL-HALs unter Android eingestellt und entfernt. Anschließend werden FCM-Dateien so geändert, dass sie den Status der HAL-Version widerspiegeln.

Wenn Partner, die Anbieterschnittstellen erweitern, Framework-Only-OTAs in ihren eigenen Ökosystemen aktivieren möchten, sollten sie HIDL-HALs mit denselben Methoden einstellen und entfernen.

Terminologie

Framework Compatibility Matrix (FCM): Eine XML-Datei, in der die Framework-Anforderungen für konforme Anbieterimplementierungen angegeben sind. Die Kompatibilitätsmatrix ist versioniert und für jedes Framework-Release wird eine neue Version eingefroren. Jeder Framework-Release enthält mehrere FCMs.
FCM-Versionen für Plattformen (S_F): Die Menge 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 Ziel-FCM-Version (aus S_F), die explizit im Gerätemanifest deklariert wird und die eine Anbieterimplementierung erfüllt. Eine Anbieterimplementierung muss anhand eines veröffentlichten FCM generiert werden, obwohl darin neuere HAL-Versionen im Geräte-Manifest deklariert werden können.
HAL-Version: Eine HAL-Version hat das Format foo@x.y, wobei foo der HAL-Name und x.y die spezifische Version ist, z. B. nfc@1.0, keymaster@3.0. Das Root-Präfix (z. B. android.hardware) wird in diesem Dokument nicht verwendet.
Geräte-Manifest: XML-Dateien, in denen angegeben wird, welche HAL-Versionen die Geräteseite der Anbieterschnittstelle, 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 auflisten, die im Vergleich zum Gerätebaum, der V entspricht, streng neuer sind.
Geräte-HALs: HALs, die im Gerätemanifest und in der Framework-Kompatibilitätsmatrix (Framework Compatibility Matrix, FCM) aufgeführt sind.
Device Compatibility Matrix (DCM): Eine XML-Datei, in der die Anforderungen des Anbieters an konforme Framework-Implementierungen angegeben sind. Jedes Gerät enthält ein DCM.
Framework-Manifest: Eine XML-Datei, in der angegeben wird, welche HAL-Versionen die Framework-Seite der Anbieterschnittstelle, einschließlich System-, system_ext- und Produkt-Images, bereitstellt. HALs im Framework-Manifest werden dynamisch deaktiviert, je nach der Target-FCM-Version des Geräts.
Framework-HALs: HALs, die im Framework-Manifest und in der Gerätekompatibilitätsmatrix (Device Compatibility Matrix, DCM) als bereitgestellt aufgeführt sind.

FCM-Lebenszyklus in der Codebasis

In diesem Dokument wird der FCM-Lebenszyklus abstrakt beschrieben. Informationen zu den unterstützten Manifesten finden Sie unter hardware/interfaces/compatibility_matrices/compatibility_matrix.<FCM>.xml. FCM ist in system/libvintf/include/vintf/Level.h enthalten.

Ein Gerät, auf dem die entsprechende Android-Version ausgeliefert wird, sollte einen FCM-Wert haben, der mindestens dem entsprechenden Level entspricht. Ein Gerät, das mit Android 11 ausgeliefert wird, hat in der Regel FCM-Level 5, implementiert aber FCM-Level 6 oder höher, was mit verschiedenen zusätzlichen Anforderungen verbunden ist, die in den Kompatibilitätsmatrizen angegeben sind. Die unterstützten Stufen für Android 15 sind:

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

Das FCM-Level ist gleich oder neuer als das Anbieter‑API‑Level.

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

Entwicklung in einer neuen FCM-Version

Unter Android wird die FCM-Version für jede Framework-Version (z. B. Android 8 und 8.1) erhöht. 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 Version von compatibility_matrix.<F-1>.xml nach compatibility_matrix.F.xml.
Aktualisieren Sie das Attribut level in der Datei auf F.
Fügen Sie entsprechende Build-Regeln hinzu, um diese Kompatibilitätsmatrix auf dem Gerät zu installieren.

Neues HAL einführen

Wenn Sie während der Entwicklung ein neues HAL (WLAN, NFC usw.) in Android in der aktuellen FCM-Version F einführen, fügen Sie das HAL zu compatibility_matrix.F.xml hinzu.

In 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 (die während der Entwicklung dieser Version vorübergehend compatibility_matrix.current.xml hieß):

<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 Neben-HAL-Versionen. HIDL-Schnittstellenversionen haben major.minor-Versionen wie 1.2.

Wenn während der Entwicklung ein AIDL-HAL von Version 2 auf Version 3 aktualisiert wird (bei der aktuellen FCM-Version F), wird die neue Version dem HAL-Eintrag in compatibility_matrix.F.xml hinzugefügt. Im Feld „version“ eines HAL-Eintrags werden Bereiche wie 2-3 akzeptiert.

Bei Android FCM F wurde beispielsweise foo@3 als Nebenversions-Upgrade des HAL eingeführt. Die ältere Version, foo@2, wird für Geräte verwendet, die auf ältere FCMs ausgerichtet sind, während die neuere Version, foo@3, für Geräte verwendet werden kann, 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 zur Unterstützung von Version 3 folgendermaßen geändert:

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

HAL aktualisieren (wichtig)

Wenn während der Entwicklung ein HAL ein Upgrade der Hauptversion in der aktuellen FCM-Version F erhält, wird die neue Hauptversion x.0 mit den folgenden Einstellungen zu compatibility_matrix.F.xml hinzugefügt:

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

In FCM-Version F wird beispielsweise foo@2.0 als Hauptversions-Upgrade des 1.0-HAL eingeführt und das 1.0-HAL wird eingestellt. Die ältere Version foo@1.0 wird für Geräte verwendet, die auf frühere FCM-Versionen ausgerichtet sind. Geräte, die auf die FCM-Version F ausgerichtet sind, müssen die neue Version 2.0 bereitstellen, wenn sie das 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 nach 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 1.0-HAL nicht in compatibility_matrix.F.xml enthalten ist, dürfen Geräte, die auf die FCM-Version F ausgerichtet sind, die 1.0-HAL nicht bereitstellen, da diese HAL als veraltet gilt.
Da die 1.0-HAL in älteren FCM-Versionen vorhanden ist, kann das Framework weiterhin mit der 1.0-HAL arbeiten. Es ist also abwärtskompatibel mit alten Geräten, die auf die älteren FCM-Versionen ausgerichtet sind.

Neue FCM-Versionen

Die Veröffentlichung einer FCM-Version auf der Systempartition erfolgt ausschließlich durch Google im Rahmen einer AOSP-Version und umfasst die folgenden Schritte:

Achten Sie darauf, dass das compatibility_matrix.F.xml das Attribut level="F" hat.
Sorgen Sie dafür, dass alle Geräte erstellt und gebootet werden.
VTS-Tests aktualisieren, damit Geräte, die mit dem neuesten Framework (basierend auf dem Shipping API-Level) auf den Markt kommen, die Ziel-FCM-Version V >= F haben.
Datei in AOSP veröffentlichen.

VTS-Tests sorgen beispielsweise dafür, dass Geräte, die mit Android 9 auf den Markt kommen, die Ziel-FCM-Version >= 3 haben.

Außerdem können in den FCMs für Produkt und system_ext auch Anforderungen für die einzelnen Plattform-FCM-Versionen aufgeführt sein. Die Veröffentlichung von FCM-Versionen auf den Partitionen „product“ und „system_ext“ erfolgt durch den jeweiligen Inhaber 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 auf der Systempartition spiegelt die Kompatibilitätsmatrix bei FCM-Version F auf den Produkt- und system_ext-Partitionen die Anforderungen an ein Gerät mit der Ziel-FCM-Version F wider.

Einstellung von HAL-Versionen

Die Einstellung einer HAL-Version ist eine Entwicklerentscheidung (d.h. bei AOSP-HALs trifft Google die Entscheidung). Dies kann passieren, wenn eine höhere HAL-Version (Neben- oder Hauptversion) veröffentlicht wird.

Geräte-HAL einstellen

Wenn ein bestimmtes Geräte-HAL foo@x.y in der FCM-Version F eingestellt wird, bedeutet das, dass Geräte, die mit der Ziel-FCM-Version V = F oder höher auf den Markt kommen, foo nicht in der Version x.y oder einer älteren Version als x.y implementieren dürfen. Eine eingestellte HAL-Version wird vom Framework weiterhin für das Upgraden von Geräten unterstützt.

Wenn FCM-Version F veröffentlicht wird, gilt eine HAL-Version foo@x.y 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 auf den Markt kommen, gilt eine der folgenden Bedingungen:

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

In Android 9 wird health@2.0 beispielsweise 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 eingestellt.

Framework-HAL einstellen

Wenn ein bestimmtes Framework-HAL foo@x.y in FCM-Version F eingestellt wird, bedeutet das, dass Geräte, die mit der Ziel-FCM-Version V = F oder höher auf den Markt kommen, nicht erwarten dürfen, dass das Framework foo in Version x.y oder einer älteren Version als x.y bereitstellt. Eine verworfene HAL-Version wird vom Framework weiterhin für das Upgraden 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 auf den Markt kommen, stellt das Framework den HAL foo@x.y nicht bereit. In der Gerätekompatibilitätsmatrix für Geräte, die mit V = F auf den Markt kommen, dürfen keine Framework-HALs mit max-level < V aufgeführt sein.

In Android 12 ist schedulerservice@1.0 beispielsweise veraltet. Das Attribut max-level ist auf 5 festgelegt, die in Android 11 eingeführte FCM-Version. Weitere Informationen finden Sie im Manifest des Android 12-Frameworks.

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

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

compatibility_matrix.V.xml aus den Build-Regeln entfernen, damit es nicht im System-Image installiert wird, und jeglichen Code löschen, der die entfernten Funktionen implementiert oder von ihnen abhängig war.
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 FCM-Zielversion außerhalb von S_F für eine bestimmte Framework-Version können nicht auf diese Version aktualisiert werden.

Entfernen vollständig verworfener HALs

Wenn eine FCM-Version entfernt wird, sind einige HAL-Schnittstellen oder Versionen von HAL-Schnittstellen in keinem FCM mehr vorhanden. Das bedeutet, dass Android sie überhaupt nicht mehr unterstützt, auch nicht für das Upgraden von Geräten.

Wenn ein HAL nicht mehr unterstützt wird, entfernen Entwickler Verweise auf diese HAL-Schnittstelle aus Android, einschließlich des Clientcodes im Framework, der Standardimplementierung und der VTS-Testläufe.

Wenn es keine unterstützten HALs gibt, die von der entfernten HAL abgeleitet werden, kann die HAL-Definition selbst mit einigen zusätzlichen Schritten entfernt werden.

Entfernen Sie die HAL-Schnittstellendefinition aus dem Quellcode. Dazu gehören die *.aidl-Dateien und das Android.bp-Modul aidl_interface.
Wenn HIDL, entfernen Sie den HASH aus hardware/interfaces/current.txt.
Wenn Sie AIDL verwenden, entfernen Sie das Verzeichnis aidl_api mit den eingefrorenen AIDL-Dateien.
Entfernen Sie die Schnittstelle aus hardware/interfaces/compatibility_matrices/exclude/fcm_exclude.cpp.

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-HALs in keiner der öffentlichen und eingefrorenen Kompatibilitätsmatrizen enthalten ist, gilt sie als nicht veröffentlicht und möglicherweise in der Entwicklung. Dazu gehören auch HAL-Versionen, die nur in compatibility_matrix.F.xml verfügbar sind. Beispiele:

Während der Entwicklung von Android 9 wurde der health@2.0-HAL als unveröffentlichter HAL betrachtet 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 als nicht veröffentlicht, wenn sie nur im Framework-Manifest eines nicht verknüpften Entwicklungszweigs enthalten ist.

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 FCM Version 3 eingefroren und in AOSP veröffentlicht wurde, gilt die health@2.0-HAL als veröffentlichte und aktuelle HAL-Version.

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

Bei Framework-HALs gilt eine HAL-Version als veröffentlichte und aktuelle HAL-Version, wenn sie 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 enthalten ist. Beispielsweise wird der displayservice-HAL in Android 12 veröffentlicht und ist dort aktuell, wie im Manifest des Android 12-Frameworks angegeben.

Veröffentlicht, aber nicht mehr unterstützt

Für Geräte-HALs wird eine HAL-Version nur dann als veraltet eingestuft, 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 befindet sich in einer öffentlichen und eingefrorenen Kompatibilitätsmatrix, die das Framework weiterhin unterstützt.

Beispiele:

Der health@1.0-HAL befindet sich in compatibility_matrix.legacy.xml, compatibility_matrix.1.xml und compatibility_matrix.2.xml, aber nicht in compatibility_matrix.3.xml. Daher gilt er in Android 9 als verworfen.
Die Power-HAL hat in Android 9 ein Nebenversions-Upgrade erhalten, aber power@1.0 befindet sich weiterhin 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 veraltet.

Bei Framework-HALs gilt eine HAL-Version als veröffentlichte, aber veraltete HAL-Version, wenn sie im Framework-Manifest des neuesten veröffentlichten Branch mit einem max-level-Attribut enthalten ist, das niedriger als die FCM-Versionsfreigabe in diesem Branch ist. Beispiel: Der schedulerservice-HAL wird veröffentlicht, ist aber in Android 12 veraltet, wie im Android 12-Framework-Manifest angegeben.

Entfernt

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

Es wurde bereits veröffentlicht.
Es ist nicht in einer öffentlichen und eingefrorenen Kompatibilitätsmatrix enthalten, die vom Framework unterstützt wird.

Kompatibilitätsmatrizen, die öffentlich, eingefroren, aber nicht vom Framework unterstützt werden, werden im Code beibehalten, um die 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 die folgenden Bedingungen erfüllt sind:

Es wurde bereits veröffentlicht.
Es ist nicht in einem Framework-Manifest des zuletzt veröffentlichten Zweigs enthalten.

Alte FCMs

„Target FCM Version legacy“ ist ein spezieller Wert für alle Geräte, die nicht Treble-kompatibel sind. Die alte FCM compatibility_matrix.legacy.xml enthält die Anforderungen des Frameworks auf alten Geräten (d.h. Geräten, die vor Android 8.0 auf den Markt kamen).

Wenn diese Datei für ein FCM mit der Version F vorhanden ist, kann jedes Gerät, das nicht Treble-kompatibel ist, auf F aktualisiert werden, sofern sein Gerätemanifest mit dieser Datei kompatibel ist. Die Entfernung erfolgt nach demselben Verfahren wie bei FCMs für andere Target FCM-Versionen (Entfernung, wenn die Anzahl der aktiven Geräte vor Android 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.

Die FCM-Version, die mit einem bestimmten Android-Release veröffentlicht wurde, finden Sie unter Level.h.