Ab 2026 werden wir den Quellcode im 2. und 4. Quartal in AOSP veröffentlichen, um unser trunk-stable-Entwicklungsmodell zu unterstützen und die Plattformstabilität für das Ökosystem zu gewährleisten. Für die Entwicklung und das Beitragen zu AOSP empfehlen wir die Verwendung von android-latest-release anstelle von aosp-main. Der Manifestzweig android-latest-release verweist immer auf das neueste Release, das an AOSP übertragen wurde. Weitere Informationen finden Sie unter Änderungen an AOSP.

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 einer Framework-Version. 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 für ein veröffentlichtes 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 FC, 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 entsprechend der Target-FCM-Version des Geräts deaktiviert.
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 dort unter system/libvintf/include/vintf/Level.h zu finden.

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 12 ausgeliefert wird, hat in der Regel FCM-Level 6. Es kann aber auch FCM-Level 7 oder höher implementieren. Dadurch ändert sich das Android-Verhalten und es müssen neuere Anbieter-APIs verwendet werden, wie in den Kompatibilitätsmatrizen angegeben. Die unterstützten Ebenen für Android 16 sind:

FCM	Android-Version
6	Android 12/S
7	Android 13/T
8	Android 14/U
202404	Android 15/V
202504	Android 16/B

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

Als Project Treble angekündigt wurde, wurden Android-System-Images so entwickelt, dass sie abwärtskompatibel mit den drei vorherigen Versionen von Anbieterimplementierungen (insgesamt vier) sind. Um längere Gerätelebenszyklen zu unterstützen, wurde dieser Zeitraum verlängert. Für 202404 und höher werden die aktuelle und die sechs vorherigen FCM-Versionen (insgesamt sieben) unterstützt.

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 höheren 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 aktuelle 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.

Neue 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 dieses HAL implementieren. Daher wurde der folgende Eintrag zu compatibility_matrix.F.xml hinzugefügt (das 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 ein Versions-Upgrade von 2 auf 3 mit der aktuellen FCM-Version F erhält, 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 der FCM-Version F wird beispielsweise foo@2.0 als Major-Version-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 sich die 1.0-HAL nicht in compatibility_matrix.F.xml befindet, 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 das 1.0-HAL in älteren FCM-Versionen vorhanden ist, kann das Framework weiterhin mit dem 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 eines AOSP-Releases und umfasst die folgenden Schritte:

Achten Sie darauf, dass 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 eingeführt werden, die Ziel-FCM-Version >= 3 haben.

Außerdem können in den FCMs für „product“ 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 in 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 in der Version x.y oder einer älteren Version als x.y nicht 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 eingestellt, 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 eingeführt werden, 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 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, nicht erwarten dürfen, dass das Framework foo in der Version x.y oder in einer Version vor x.y bereitstellt. Eine verworfene HAL-Version wird weiterhin vom Framework 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

Wir verwenden einen zeitplanbasierten Prozess, um die Entfernung der Ziel-FCM-Version zu bestimmen. So können wir die Kompatibilität für die erforderlichen Zeiträume aufrechterhalten und die Partneranforderungen für Geräte mit längerer Lebensdauer unterstützen.

Wenn wir eine Ziel-FCM-Version aus der Menge S_F der nächsten Framework-Version entfernen, führen wir beide der folgenden Schritte aus:

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

Stufenweise Einstellung von Releasekonfigurationen

Die Branching-Strategie von „Trunk Stable“, bei der vierteljährliche Plattform-Releases (Quarterly Platform Releases, QPRs) direkt aus git_main anstelle von separaten Release-Entwicklungs-Branches stammen, erfordert einen gestaffelten Einstellungsprozess. Eine FCM-Version kann für Early Signals in trunk_staging-Builds entfernt werden, während sie im Release-Branch weiterhin unterstützt wird, um Geräte zu berücksichtigen, die das ganze Jahr über QPRs erhalten.

In der Regel werden in einem Framework-Release sechs FCMs unterstützt: eine aktuelle Version, vier vorherige Versionen und eine zusätzliche Version zur Unterstützung von QPRs. Diese Zahl kann steigen, wenn bestimmte FCM-Versionen (z. B. 202404 für Android 15) eine längere Unterstützung für Geräte bieten.

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 unverö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 Android 12-Framework-Manifest 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:

Sie wurde 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:

Die 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 veraltet.
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 letzten veröffentlichten Branch mit einem max-level-Attribut enthalten ist, das niedriger als die FCM-Versionsveröffentlichung in diesem Branch ist. Die schedulerservice-HAL wird beispielsweise 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 den Satz der 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 nur 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.