Ein Android-Framework-Release hat mehrere Framework Compatibility Matrixes (FCMs), eine für jede aktualisierbare FCM-Zielversion. Diese definieren, was das Framework verwenden darf und welche Anforderungen an die FCM-Zielversion gelten. Im Rahmen des FCM-Lebenszyklus werden HIDL HALs von Android verworfen und entfernt. Anschließend werden die FCM-Dateien so geändert, dass sie dem Status der HAL-Version entsprechen.
Um reine Framework-OTAs in ihren eigenen Umgebungen zu aktivieren, sollten Partner, die Benutzeroberflächen von Anbietern erweitern, auch HIDL HALs mit denselben Methoden einstellen und entfernen.
Terminologie
- Framework-Kompatibilitätsmatrix (FCM)
- Eine XML-Datei mit den Framework-Anforderungen für konforme Anbieterimplementierungen. Die Kompatibilitätsmatrix ist versioniert und eine neue Version wird für jeden Framework-Release eingefroren. Jeder Framework-Release enthält mehrere FCMs.
- FCM-Plattformversionen (SF)
- Alle FCM-Versionen in einem Framework-Release. Das Framework kann mit jeder Anbieterimplementierung verwendet werden, die einen dieser FCMs erfüllt.
- FCM-Version (F)
- Die höchste Version aller FCMs in einem Framework-Release.
- FCM-Zielversion (V)
- Die explizit im Gerätemanifest deklarierte FCM-Version (von SF), die eine Anbieterimplementierung erfüllt. Für eine veröffentlichte FCM muss eine Anbieterimplementierung generiert werden, auch wenn im Gerätemanifest neue HAL-Versionen deklariert werden können.
- HAL-Version
- Eine HAL-Version hat das Format
foo@x.y
, wobeifoo
der HAL-Name undx.y
die spezifische Version ist; 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, einschließlich Anbieter und ODM-Images, bereitgestellt werden. Der Inhalt eines Gerätemanifests wird durch die FCM-Zielversion des Geräts eingeschränkt. Es können jedoch HALs aufgelistet werden, die im Vergleich zum FC für V entsprechend neuer sind.
- Geräte-HALs
- HALs, die im Gerätemanifest (erforderlich oder optional) und in der Framework-Kompatibilitätsmatrix (FCM) aufgeführt sind (bereitgestellt).
- Gerätekompatibilitätsmatrix (DCM)
- Eine XML-Datei mit den Anbieteranforderungen an konforme Framework-Implementierungen. Jedes Gerät enthält einen DCM.
- Framework-Manifest
- Eine XML-Datei, die angibt, welche HAL-Version der Framework-Seite der Anbieterschnittstelle, einschließlich System-, system_ext- und Produkt-Images, bereitstellt. HALs im Framework-Manifest werden entsprechend der FCM-Zielversion des Geräts dynamisch deaktiviert.
- Framework-HALs
- HALs, die im Framework-Manifest angegeben und in der Device Compatibility Matrix (DCM) als erforderlich oder optional aufgeführt sind.
FCM-Lebenszyklus in der Codebasis
In diesem Dokument wird der FCM-Lebenszyklus in der Zusammenfassung beschrieben. Die derzeit unterstützten Manifeste finden Sie unter hardware/interfaces/compatibility_matrix.<FCM>.xml
. FCM finden Sie in system/libvintf/include/vintf/Level.h
.
Ein Gerät mit der entsprechenden Android-Release-Version muss einen FCM-Wert haben, der größer oder gleich der entsprechenden Stufe ist. Ein Gerät, das mit Android 11 versendet wird, hat in der Regel FCM-Level 5, implementiert aber FCM-Level 6 oder höher. Für dieses Gerät gelten dann verschiedene zusätzliche Anforderungen, 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.
Entwicklung in einer neuen FCM-Version
Android erhöht die FCM-Version für jeden Framework-Release (z. B. Android 8, 8.1 usw.). Während der Entwicklung wird die neue compatibility_matrix.F.xml
erstellt und die vorhandene compatibility_matrix.f.xml
(wobei f
< F
) nicht mehr geändert wird.
So beginnst du mit der Entwicklung in einer neuen FCM-Version F
:
- Kopieren Sie die aktuelle
compatibility_matrix.<F-1>.xml
incompatibility_matrix.F.xml
. - Aktualisieren Sie das Attribut
level
in der Datei aufF
. - Fügen Sie entsprechende Build-Regeln hinzu, um diese Kompatibilitätsmatrix auf dem Gerät zu installieren.
Wir stellen vor: einen neuen HAL
Wenn Sie während der Entwicklung einen neuen HAL (WLAN, NFC usw.) für Android mit der aktuellen FCM-Version F
einführen, fügen Sie den HAL mit den folgenden optional
-Einstellungen zu compatibility_matrix.F.xml
hinzu:
optional="false"
, wenn Geräte, die mitV = F
versendet werden, mit diesem HAL starten müssen,optional="true"
, wenn Geräte, die mitV = 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, die mit Android 8.1 auf den Markt gebracht werden, müssen diesen HAL nicht implementieren. Daher wurde der folgende Eintrag zu compatibility_matrix.F.xml
hinzugefügt (der früher während der Entwicklung dieses Release vorübergehend compatibility_matrix.current.xml
hieß):
<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 ein HAL ein Nebenversionsupgrade von x.z
auf x.(z+1)
bei der aktuellen FCM-Version F
hat, wenn diese Version:
- Auf Geräten erforderlich, die mit
V = F
auf den Markt gebracht werden, müssen imcompatibility_matrix.F.xml
sowohlx.(z+1)
als auchoptional="false"
angezeigt werden. - Auf Geräten, die mit
V = F
auf den Markt gebracht werden, musscompatibility_matrix.F.xml
denx.y-z
und die optionale Einstellung auscompatibility_matrix.<F-1>.xml
kopieren und die Version inx.w-(z+1)
ändern (wobeiw >= y
).
Unter Android 8.1 wurde beispielsweise broadcastradio@1.1
als Nebenversions-Upgrade von 1.0 HAL eingeführt. Die ältere Version broadcastradio@1.0
ist für Geräte mit Android 8.0 optional, während die neuere Version broadcastradio@1.1
für Geräte mit Android 8.1 optional ist. 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
Wenn für einen HAL während der Entwicklung ein Hauptversionsupgrade mit der aktuellen FCM-Version F
durchgeführt wird, wird die neue Hauptversion x.0
mit den folgenden optional
-Einstellungen zu compatibility_matrix.F.xml
hinzugefügt:
optional="false"
nur mit Versionx.0
, wenn Geräte, die mitV = F
ausgeliefert werden, mitx.0
auf den Markt gebracht werden müssen.optional="false"
, aber zusammen mit älteren Hauptversionen im selben<hal>
-Tag, wenn Geräte, die mitV = F
ausgeliefert werden, mit diesem HAL starten müssen, aber mit einer älteren Hauptversion starten können.optional="true"
, wenn Geräte, die mitV = F
ausgeliefert werden, HAL nicht starten müssen.
Unter Android 9 wird beispielsweise health@2.0
als Hauptversions-Upgrade der HAL 1.0 eingeführt und die HAL 1.0 verworfen. Die ältere Version health@1.0
ist für Geräte mit Android 8.0 und Android 8.1 optional.
Auf Geräten, die mit Android 9 auf den Markt gebracht werden, darf die eingestellte Version 1.0 HAL nicht verfügbar sein. Stattdessen muss die neue Version 2.0 bereitgestellt werden. I
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 nach compatibility_matrix.F.xml
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
compatibility_matrix.3.xml
mitoptional="false"
befindet, müssen Geräte, die mit Android 9 starten, mit 2.0 HAL ausgeliefert werden. - Da sich die HAL 1.0 nicht in
compatibility_matrix.3.xml
befindet, dürfen Geräte, die mit Android 9 gestartet werden, nicht die Version 1.0 HAL bereitstellen, da dieser HAL als veraltet gilt. - Da das HAL 1.0 in der Datei "legacy/1/2.xml" (ältere FCM-Versionen, mit denen Android 9 funktionieren kann) als optionaler HAL vorhanden ist, kann das Android 9-Framework weiterhin mit dem HAL 1.0 (die nicht als entfernte HAL-Version gilt) funktioniert.
Neue FCM-Versionen
Die Veröffentlichung einer FCM-Version auf der Systempartition wird ausschließlich von Google im Rahmen eines AOSP-Release ausgeführt und umfasst die folgenden Schritte:
- Achten Sie darauf, dass
compatibility_matrix.F.xml
das Attributlevel="F"
hat. - Achten Sie darauf, dass alle Geräte erstellt und gestartet werden.
- Aktualisiere die VTS-Tests, damit Geräte, die mit dem neuesten Framework (basierend auf dem Shipping API-Level) gestartet werden, die FCM-Zielversion
V >= F
haben. - Veröffentlichen Sie die Datei in AOSP.
VTS-Tests stellen beispielsweise sicher, dass Geräte, die mit Android 9 gestartet werden, die FCM-Zielversion >= 3 haben.
Darüber hinaus können die FCMs für Produkt und system_ext auch Anforderungen für die einzelnen FCM-Versionen der Plattform auflisten. Die Veröffentlichung von FCM-Versionen auf den Partitionen „product“ und „system_ext“ erfolgt durch den Inhaber dieser Images. Die FCM-Versionsnummern der Produkt- und system_ext-Partitionen müssen mit denen in der Systempartition übereinstimmen. Ähnlich wie FCM-Versionen auf der Systempartition gibt die Kompatibilitätsmatrix bei FCM-Version F in den Produkt- und system_ext-Partitionen die Anforderungen auf einem Gerät mit der FCM-Zielversion F wieder.
Einstellung der HAL-Version
Die Einstellung einer HAL-Version ist eine Entscheidung des Entwicklers (d.h. für 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 die HAL foo@x.y
eines bestimmten Geräts mit der FCM-Version F
verworfen wird, bedeutet dies, dass Geräte, die mit der FCM-Zielversion V = F
oder höher gestartet werden, foo
nicht in Version x.y
oder einer älteren Version als x.y
implementieren dürfen. Eine verworfene HAL-Version wird vom Framework für Geräteupgrades weiterhin unterstützt.
Wenn die FCM-Version F
veröffentlicht wird, gilt eine HAL-Version foo@x.y
als verworfen, wenn die spezifische HAL-Version nicht explizit in der neuesten FCM-Version für die FCM-Zielversion V = F
angegeben ist. Bei Geräten, die mit V = F
gestartet 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 Upgrade der Hauptversion von 1.0 HAL eingeführt. health@1.0
wird 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.
Framework-HAL verwerfen
Wenn ein bestimmtes Framework-HAL foo@x.y
mit der FCM-Version F
verworfen wird, bedeutet dies, dass Geräte, die mit der FCM-Zielversion V = F
oder höher gestartet werden, nicht davon ausgehen dürfen, dass das Framework foo
in der Version x.y
oder einer älteren Version als x.y
bereitstellt. Eine verworfene HAL-Version wird vom Framework für Geräteupgrades weiterhin bereitgestellt.
Wenn die FCM-Version F
veröffentlicht wird, gilt die HAL-Version foo@x.y
als verworfen, wenn im Framework-Manifest für foo@x.y
max-level="F - 1"
angegeben ist. Bei Geräten, die mit V = F
gestartet werden, bietet das Framework den HAL foo@x.y
nicht. Die Gerätekompatibilitätsmatrix auf Geräten, die mit V = F
gestartet werden, darf keine Framework-HALs mit max-level < V
enthalten.
In Android 12 wurde beispielsweise schedulerservice@1.0
eingestellt. Das Attribut max-level
ist auf 5
gesetzt, die mit Android 11 eingeführte FCM-Version. Weitere Informationen findest du unter Android 12-Framework-Manifest.
Keine Unterstützung mehr für FCM-Zielversionen
Wenn die aktiven Geräte einer bestimmten FCM-Zielversion V
unter einen bestimmten Schwellenwert fallen, wird die FCM-Zielversion aus der festgelegten F des nächsten Framework-Release entfernt. Dies geschieht durch die beiden folgenden Schritte:
Entfernen von
compatibility_matrix.V.xml
aus den Build-Regeln, damit es nicht auf dem System-Image installiert wird, und Löschen von Code, der die entfernte Funktion implementiert oder davon abhängtEntfernen von Framework-HALs mit
max-level
kleiner oder gleichV
aus dem Framework-Manifest und Löschen von Code, der die entfernten Framework-HALs implementiert.
Geräte mit einer FCM-Zielversion außerhalb von SF für einen bestimmten Framework-Release können kein Upgrade auf diesen Release durchführen.
HAL-Versionsstatus
In den folgenden Abschnitten werden die möglichen Status einer HAL-Version (in chronologischer Reihenfolge) beschrieben.
Unveröffentlicht
Wenn eine HAL-Version bei Geräte-HALs in keiner der öffentlichen und eingefrorenen Kompatibilitätsmatrixen enthalten ist, gilt sie als unveröffentlicht und möglicherweise in der Entwicklung.
Dies gilt auch für HAL-Versionen, die nur in compatibility_matrix.F.xml
verfügbar sind.
Beispiele:
- Bei der Entwicklung von Android 9 galt
health@2.0
HAL als unveröffentlichter HAL und war nur incompatibility_matrix.3.xml
vorhanden. - Der HAL
teleportation@1.0
befindet sich in keiner freigegebenen Kompatibilitätsmatrix und wird auch als unveröffentlichter HAL betrachtet.
Wenn sich eine HAL-Version für Framework-HALs nur im Framework-Manifest eines anderen Entwicklungszweigs befindet, gilt sie als unveröffentlicht.
Veröffentlicht und aktuell
Wenn sich eine HAL-Version in einer öffentlichen und eingefrorenen Kompatibilitätsmatrix für Geräte-HALs befindet, wird sie freigegeben. Wenn beispielsweise FCM Version 3 eingefroren und über AOSP veröffentlicht wurde, gilt der HAL health@2.0
als freigegebene 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 verworfen). Vorhandene HAL-Versionen (wie nfc@1.0
in compatibility_matrix.legacy.xml
eingeführt, die in compatibility_matrix.3.xml
weiterhin vorhanden sind) werden beispielsweise auch als veröffentlichte und aktuelle HAL-Versionen betrachtet.
Wenn sich eine HAL-Version im Framework-Manifest des zuletzt freigegebenen Zweigs ohne das Attribut max-level
oder (ungewöhnlich) eine max-level
, die der in diesem Zweig freigegebenen FCM-Version entspricht oder höher ist, befindet, wird sie für Framework-HALs als freigegebene und aktuelle HAL-Version betrachtet. Beispielsweise wird der HAL displayservice
in Android 12 veröffentlicht und ist aktuell, wie im Android 12-Framework-Manifest angegeben.
Veröffentlicht, aber eingestellt
Bei Geräte-HALs wird eine HAL-Version nur dann verworfen, wenn alle der folgenden Bedingungen erfüllt sind:
- Es wird veröffentlicht.
- Sie befindet sich nicht in der öffentlichen und eingefrorenen Kompatibilitätsmatrix mit der höchsten FCM-Version.
- Sie befindet sich in einer öffentlichen und eingefrorenen Kompatibilitätsmatrix, die vom Framework weiterhin unterstützt wird.
Beispiele:
- Der HAL
health@1.0
befindet sich incompatibility_matrix.legacy.xml
,compatibility_matrix.1.xml
undcompatibility_matrix.2.xml
, aber nicht incompatibility_matrix.3.xml
. Daher gilt sie in Android 9 als veraltet. - Für den Power-HAL wird in Android 9 ein Nebenversionsupgrade ausgeführt, aber
power@1.0
befindet sich noch incompatibility_matrix.3.xml
. power@1.0
compatibility_matrix.legacy.xml
,compatibility_matrix.1.xml
undcompatibility_matrix.2.xml
.compatibility_matrix.3.xml
hatpower@1.0-1
.
Daher ist power@1.0
aktuell, aber in Android 9 NICHT verworfen.
Wenn sich bei Framework-HALs eine HAL-Version im Framework-Manifest des zuletzt veröffentlichten Zweigs mit einem Attribut max-level
befindet, das niedriger als der FCM-Versionsrelease in diesem Zweig ist, wird sie als freigegebene, aber nicht mehr unterstützte HAL-Version betrachtet. Beispielsweise wurde der HAL schedulerservice
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:
- Sie wurde bereits veröffentlicht.
- Es befindet sich in keiner öffentlichen und eingefrorenen Kompatibilitätsmatrix, die vom Framework unterstützt wird.
Öffentliche, eingefrorene, aber nicht vom Framework unterstützte Kompatibilitätsmatrizes werden in der Codebasis gespeichert, um die entfernten HAL-Versionen zu definieren, sodass VTS-Tests geschrieben werden können, um sicherzustellen, dass entfernte HALs sich nicht auf neuen Geräten befinden.
Bei Framework-HALs wird eine HAL-Version nur dann entfernt, wenn die folgenden Bedingungen erfüllt sind:
- 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 Legacy-FCM-Version (compatibility_matrix.legacy.xml
) listet die Framework-Anforderungen für Legacy-Geräte auf, also Geräte, die vor Android 8.0 auf den Markt gebracht wurden.
Wenn diese Datei für eine FCM mit der Version F
vorhanden ist, kann jedes Nicht-Treble-Gerät auf F
aktualisiert werden, sofern sein Gerätemanifest mit dieser Datei kompatibel ist. Sie werden genauso entfernt wie FCMs für andere FCM-Zielversionen (werden entfernt, nachdem die Anzahl der aktiven Geräte vor Version 8.0 unter einen bestimmten Grenzwert fällt).
Veröffentlichte FCM-Versionen
Die Liste der freigegebenen 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
.