Diese Seite wurde von der Cloud Translation API übersetzt.

FCM-Lebenszyklus

Ein Android-Framework-Release hat mehrere Framework-Kompatibilitätsmatrixen. (eines für jede FCM-Zielversion), die definieren, die das Framework möglicherweise verwendet, und die Ziel-FCM-Versionsanforderungen. Im Rahmen der FCM werden HIDL HALs von Android verworfen und entfernt. Anschließend werden die FCM-Dateien in Der Status der HAL-Version wird angezeigt.

Um reine Framework-OTAs in ihren eigenen Ökosystemen zu ermöglichen, müssen Partner, die Anbieteroberflächen sollten auch HIDL HALs mit den gleichen .

Terminologie

Framework-Kompatibilitätsmatrix (FCM): Eine XML-Datei mit den Framework-Anforderungen für konforme Anbieter Implementierungen. Die Kompatibilitätsmatrix ist versioniert und eine neue Version für jeden Framework-Release eingefroren. Jede Framework-Version enthält mehreren FCMs.
FCM-Plattformversionen (S_F): Alle FCM-Versionen in einem Framework-Release. Das Framework funktioniert unabhängig von Anbieterimplementierung, die einer dieser FCMs entsprechen.
FCM-Version (F): Die höchste Version aller FCMs in einem Framework-Release.
FCM-Zielversion (V): Die FCM-Version, auf die die Anzeige ausgerichtet ist (von S_F), die explizit auf dem Gerät deklariert ist die eine Anbieterimplementierung erfüllt. Eine Anbieterimplementierung muss die anhand einer veröffentlichten FCM generiert wurden. Gerätemanifest
HAL-Version: Eine HAL-Version hat das Format foo@x.y, wobei foo der HAL-Name und x.y der die spezifische Version z.B. nfc@1.0, keymaster@3.0 (das Stammpräfix, z.B. android.hardware, wird in diesem Dokument ausgelassen.)
Gerätemanifest: XML-Dateien, die angeben, welche HAL-Versionen auf der Geräteseite der Anbieterschnittstelle verwendet werden. einschließlich der Anbieter- und ODM-Images. Der Inhalt eines Gerätemanifests durch die FCM-Zielversion des Geräts eingeschränkt ist, kann aber HALs auflisten, gegenüber dem FC, der V entspricht.
Geräte-HALs: HALs, die im Gerätemanifest (bereitgestellt) und aufgeführt sind (entweder erforderlich oder optional) in der Framework-Kompatibilitätsmatrix (FCM).
Gerätekompatibilitätsmatrix (DCM): Eine XML-Datei mit den Anbieteranforderungen an konformes Framework Implementierungen. Jedes Gerät enthält einen DCM.
Framework-Manifest: Eine XML-Datei, die angibt, welche HAL-Version die Framework-Seite des Anbieters verwendet wie „system_ext“, „system_ext“ und „Produktbilder“. HALs in der Framework-Manifest entsprechend dem FCM-Ziel des Geräts dynamisch deaktiviert. Version.
Framework-HALs: HALs, die wie im Framework-Manifest angegeben aufgeführt sind und entweder erforderlich oder optional sind.

FCM-Lebenszyklus in der Codebasis

In diesem Dokument wird der FCM-Lebenszyklus in der Zusammenfassung beschrieben. Um die unterstützte Manifeste, siehe hardware/interfaces/compatibility_matrix.<FCM>.xml wo FCM zu finden ist, system/libvintf/include/vintf/Level.h

Ein Gerät mit der entsprechenden Android-Release-Version sollte einen FCM-Wert größer oder gleich der entsprechenden Ebene. Beispiel: Geräteversand mit Android 11 würden in der Regel FCM-Level 5 haben, FCM-Level 6 oder höher, das mehrere zusätzliche Anforderungen mit sich bringt 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

Wenn eine FCM-Ebene von Android eingestellt wird, wird sie weiterhin für vorhandene Geräte unterstützt.

In einer neuen FCM-Version entwickeln

Android erhöht die FCM-Version für jeden Framework-Release (z. B. Android 8 und 8.1). In der Entwicklungsphase ist die neue compatibility_matrix.F.xml erstellt und die vorhandene compatibility_matrix.f.xml (wobei f < F) nicht geändert.

So beginnst du mit der Entwicklung in einer neuen FCM-Version F:

Neueste compatibility_matrix.<F-1>.xml kopieren 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 in der .

Einen neuen HAL einführen

Während der Entwicklung bei der Einführung eines neuen HAL (WLAN, NFC usw.) in Android Fügen Sie in der aktuellen FCM-Version F den HAL mitcompatibility_matrix.F.xml die folgenden optional-Einstellungen:

optional="false", wenn Geräte, die mit V = F versendet werden, mit diesem HAL starten 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 mit Android 8.1 starten, sind für die Implementierung dieses HAL nicht erforderlich, der folgende Eintrag wurde compatibility_matrix.F.xml hinzugefügt (zuvor war er im Laufe der Entwicklung vorübergehend compatibility_matrix.current.xml Release):

<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) ausführen

Während der Entwicklung, wenn für einen HAL ein Nebenversionsupgrade von x.z auf x.(z+1) mit der aktuellen FCM-Version F, wenn diese Version:

Erforderlich auf Geräten, die mit V = F und compatibility_matrix.F.xml auf den Markt gebracht werden müssen x.(z+1) und optional="false" angeben.
Nicht erforderlich auf Geräten, die mit V = F auf den Markt gebracht werden, compatibility_matrix.F.xml muss x.y-z und optionale Einstellungen kopieren aus compatibility_matrix.<F-1>.xml und ändere die Version in x.w-(z+1) (wobei w >= y).

Mit Android 8.1 wurde beispielsweise broadcastradio@1.1 als Nebenversion eingeführt. Upgrade von 1.0 HAL. Die ältere Version broadcastradio@1.0 ist optional für mit Android 8.0 und der neueren Version auf den Markt, broadcastradio@1.1 ist für Geräte mit Android 8.1 optional. 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>

Upgrade einer HAL (Hauptversion) ausführen

Während der Entwicklung, wenn für einen HAL bei aktuellem FCM ein Hauptversionsupgrade durchgeführt wird Version F, die neue Hauptversion x.0 wird hinzugefügt zu compatibility_matrix.F.xml mit den folgenden optional-Einstellungen:

optional="false" nur mit Version x.0, bei Geräten, die mit V = F muss mit x.0 gestartet werden.
optional="false", aber zusammen mit älteren Hauptversionen im selben <hal> Tag angegeben, wenn Geräte, die mit V = F geliefert werden, mit diesem HAL gestartet werden müssen, mit einer älteren Hauptversion.
optional="true", wenn Geräte, die mit V = F ausgeliefert werden, nicht auf den Markt gebracht werden müssen den HAL.

Unter Android 9 wird beispielsweise health@2.0 als ein Upgrade der Hauptversion von 1.0 HAL und die Einstellung der HAL 1.0. Je älter Version health@1.0 ist für Geräte mit Android 8.0 und Android 8.1 Geräte, die mit Android 9 auf den Markt gebracht werden, müssen die neue Version 2.0 bereitstellen. Nehmen wir beispielsweise an, compatibility_matrix.legacy.xml, compatibility_matrix.1.xml und compatibility_matrix.2.xml diesen Eintrag enthalten:

<hal format="hidl" optional="true">
    <name>android.hardware.health</name>
    <version>1.0</version>;
    <interface>
        <name>IHealth</name>
        <instance>default</instance>
    </interface>
</hal>

Diesen Eintrag nach compatibility_matrix.F.xml kopieren und ändern als folgt:

<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 compatibility_matrix.3.xml befindet, optional="false", Geräte, die mit Android auf den Markt gebracht werden 9 müssen mit 2.0 HAL versendet werden.
Da sich die 1.0-HAL nicht in compatibility_matrix.3.xml befindet, dürfen auf Geräten, die mit Android 9 auf den Markt kommen, 1.0 HAL (da dieser HAL als veraltet gilt).
Da das HAL 1.0 in legacy/1/2.xml (älteren FCM-Versionen, die Android 9 unterstützt) als optionales HAL, der Das Android 9-Framework funktioniert weiterhin mit dem HAL 1.0 (die nicht als entfernte HAL-Version gilt).

Neue FCM-Versionen

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

Achten Sie darauf, dass compatibility_matrix.F.xml das Attribut level="F" hat.
Achten Sie darauf, dass alle Geräte erstellt und gestartet werden.
VTS-Tests aktualisieren um sicherzustellen, dass Geräte mit dem neuesten Framework (basierend auf Versand-API-Ebene) die FCM-Zielversion V >= F haben.
Veröffentlichen Sie die Datei in AOSP.

Beispiel: VTS-Tests dass Geräte mit Android auf den Markt gebracht werden, 9 haben die FCM-Zielversion >= 3.

Darüber hinaus können die FCMs für produkt- und system_extern auch Anforderungen für die einzelnen FCM-Plattformversionen verwenden. Veröffentlichung von FCM-Versionen für das Produkt und system_ext die Partitionen werden vom Eigentümer dieser Images durchgeführt. FCM-Version die Nummern in den Partitionen „product“ und „system_ext“ müssen mit denen auf der Datei übereinstimmen. Systempartitionierung. Ähnlich wie bei den FCM-Versionen auf der Systempartition Kompatibilitätsmatrix in FCM Version F in den Partitionen „product“ und „system_ext“ die Anforderungen auf einem Gerät mit der FCM-Zielversion F widerspiegelt.

Einstellung der HAL-Version

Die Einstellung einer HAL-Version ist eine Entscheidung des Entwicklers (d.h. für AOSP HALs, Google die Entscheidung trifft). Es kann passieren, wenn eine höhere HAL-Version (Neben- oder „Major“ (Hauptversion) veröffentlicht.

Geräte-HAL einstellen

Wenn der HAL foo@x.y eines bestimmten Geräts mit der FCM-Version F eingestellt wird, bedeutet das, dass Geräte, die mit der FCM-Zielversion V = F oder höher gestartet werden, Implementieren Sie foo auf Version x.y oder einer beliebigen älteren Version als x.y. Ein nicht mehr unterstütztes Attribut Die HAL-Version wird vom Framework für Geräteupgrades weiterhin unterstützt.

Wenn die FCM-Version F veröffentlicht wird, wird eine HAL-Version foo@x.y berücksichtigt veraltet, wenn die spezifische HAL-Version nicht explizit in der neuesten Version FCM für die FCM-Zielversion V = F. Für Geräte, die mit V = F auf den Markt gebracht werden, erfüllt sind:

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

In Android 9 wird beispielsweise health@2.0 eingeführt. als Hauptversions-Upgrade von 1.0 HAL. health@1.0 wird entfernt aus compatibility_matrix.3.xml, ist jedoch vorhanden in compatibility_matrix.legacy.xml, compatibility_matrix.1.xml, und Kompatibilität_matrix.2.xml. Daher gilt health@1.0 als veraltet.

Framework-HAL verwerfen

Wenn ein bestimmtes Framework HAL foo@x.y mit der FCM-Version F verworfen wird, bedeutet das dass Geräte, die mit der FCM-Zielversion V = F oder höher gestartet werden, erwartet, dass das Framework foo ab Version x.y oder einer beliebigen älteren Version bereitstellt. als x.y. Eine veraltete HAL-Version wird vom Framework weiterhin für ein Upgrade von Geräten ausführen.

Wenn die FCM-Version F veröffentlicht wird, wird eine HAL-Version foo@x.y berücksichtigt veraltet, wenn im Framework-Manifest angegeben ist, max-level="F - 1" für foo@x.y. Für Geräte, die auf den Markt gebracht werden Mit V = F stellt das Framework den HAL foo@x.y nicht bereit. Das Gerät Auf Geräten, die mit V = F auf den Markt gebracht werden, darf in der Kompatibilitätsmatrix kein Framework aufgeführt sein HALs mit max-level < V.

In Android 12 ist schedulerservice@1.0 beispielsweise eingestellt. Das Attribut max-level ist auf 5 gesetzt, die eingeführte FCM-Version. für Android 11. Weitere Informationen finden Sie unter Android 12-Framework Manifestdatei.

Keine Unterstützung mehr für FCM-Zielversionen

Wenn aktive Geräte mit einer bestimmten FCM-Zielversion V unter eine bestimmte wird die FCM-Zielversion aus dem Satz _F der Einstellung entfernt. nächsten Framework-Release. Dies geschieht durch die beiden folgenden Schritte:

compatibility_matrix.V.xml aus den Build-Regeln entfernen, damit es nicht auf dem System-Image installiert ist) und jeglichen Code zu löschen, der von den entfernten Funktionen abhing.
Framework-HALs mit max-level kleiner oder gleich V werden aus dem Framework-Manifest bekannt und löschen Sie jeglichen Code, der die entfernten Framework-HALs.

Geräte mit einer FCM-Zielversion außerhalb von S_F für ein bestimmtes Framework kann kein Upgrade auf diesen Release durchgeführt werden.

HAL-Versionsstatus

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

Unveröffentlicht

Bei Geräte-HALs, wenn eine HAL-Version nicht öffentlich verfügbar und eingefroren ist Kompatibilitätsmatrizen gilt, gilt es als unveröffentlicht und befindet sich möglicherweise in der Entwicklung. Dies gilt auch für HAL-Versionen, die nur in compatibility_matrix.F.xml verfügbar sind. Beispiele:

Während der Entwicklung von Android 9 health@2.0 HAL wurde als unveröffentlichter HAL betrachtet und war nur in folgendem Land vorhanden: compatibility_matrix.3.xml.
Der HAL teleportation@1.0 befindet sich in keiner freigegebenen Kompatibilitätsmatrix und gilt auch als unveröffentlichter HAL.

Für Framework-HALs: Wenn eine HAL-Version nur im Framework-Manifest vorhanden ist eines anderen Entwicklungszweigs, gilt es als unveröffentlicht.

Veröffentlicht und aktuell

Bei Geräte-HALs: Wenn eine HAL-Version öffentlich verfügbar und nicht mehr kompatibel ist Matrix verwendet, wird es veröffentlicht. Beispiel: Nachdem FCM Version 3 eingefroren und veröffentlicht wurde, gegenüber AOSP gilt, gilt der health@2.0 HAL als freigegebene und aktuelle HAL-Version.

Wenn sich eine HAL-Version in einer öffentlichen und eingefrorenen Kompatibilitätsmatrix mit der höchste FCM-Version, in der die HAL-Version aktuell ist (d.h. nicht veraltet). Für vorhandene HAL-Versionen (wie nfc@1.0, die in compatibility_matrix.legacy.xml) die weiterhin in compatibility_matrix.3.xml vorhanden sind, gelten auch als veröffentlichten und aktuellen HAL-Versionen.

Wenn bei Framework-HALs eine HAL-Version im Framework-Manifest enthalten ist des zuletzt freigegebenen Zweigs ohne das Attribut max-level oder (ungewöhnlich) ein max-level gleich oder höher als die in diesem Zweig veröffentlichte FCM-Version ist, gilt als veröffentlichte und aktuelle HAL-Version. Beispiel: Der Parameter displayservice HAL wurde veröffentlicht und ist in Android aktuell 12, wie in den Android 12-Framework Manifest-Datei.

Veröffentlicht, aber eingestellt

Bei Geräte-HALs wird eine HAL-Version nur dann verworfen, wenn Folgendes zutrifft: erfüllt sind:

Es wird veröffentlicht.
Sie 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 immer noch unterstützt.

Beispiele:

Der HAL „health@1.0“ 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 sie in den Android 9
Der Leistungs-HAL hat ein Nebenversionsupgrade in Android. 9, aber power@1.0 ist 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 aktuell, aber NICHT veraltet. 9.

Wenn bei Framework-HALs eine HAL-Version im Framework-Manifest der neuesten Version freigegebener Zweig mit einem Attribut max-level, das niedriger als der FCM-Versionsrelease ist in diesem Zweig gilt er als veröffentlichte, aber nicht mehr unterstützte HAL-Version. Für Beispiel: Der HAL schedulerservice wurde veröffentlicht, aber veraltet in Android 12 gemäß den Android 12-Framework-Manifest.

Entfernt

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

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

Kompatibilitätsmatrixen, die öffentlich oder eingefroren sind, aber nicht vom Framework in der Codebasis gespeichert, um die entfernten HAL-Versionen zu definieren, VTS-Tests können geschrieben werden, um sicherzustellen, dass entfernte HALs sich nicht auf neuen Geräten befinden.

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

Sie wurde bereits veröffentlicht.
Er befindet sich in keinem Framework-Manifest des zuletzt veröffentlichten Zweigs.

Alte FCMs

Die alte FCM-Zielversion ist ein spezieller Wert für alle Geräte, die keine Höhen haben. Die Das alte FCM (compatibility_matrix.legacy.xml) listet die Anforderungen des Frameworks auf älteren Geräten, d.h. Geräten, die vor Android 8.0 auf den Markt gebracht wurden.

Wenn diese Datei für eine FCM mit der Version F existiert, kann jedes Nicht-Höhen-Gerät Das Upgrade wurde auf F durchgeführt, sofern das Gerätemanifest mit dieser Datei kompatibel ist. Das werden bei der Entfernung von FCM-Standards genauso wie bei anderen FCM-Zielversionen entfernt. (entfernt, nachdem die Anzahl der aktiven Geräte, die älter als 8.0 sind, unter einen bestimmten Wert Grenzwert).

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, findest du unter Level.h