FCM-Lebenszyklus

Ein Android-Framework-Release verfügt über mehrere Framework-Kompatibilitätsmatrixen (FCMs) – eine für jede aktualisierbare Ziel-FCM-Version –, die definieren, was das Framework verwenden darf und die Anforderungen an die Ziel-FCM-Version definieren. Im Rahmen des FCM - Lebenszyklus, Android deprecates und entfernt HIDL HALs, dann ändern FCM - Dateien den Status der reflektieren HAL Version .

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

Terminologie

Framework-Kompatibilitätsmatrix (FCM) Eine XML-Datei, die Rahmenanforderungen für konforme Anbieterimplementierungen festlegt. Die Kompatibilitätsmatrix wird versioniert, und für jede Framework-Version wird eine neue Version eingefroren. Jede Framework-Version enthält mehrere FCMs.
Plattform FCM Versionen (S F) Die Menge aller FCM-Versionen in einem Framework-Release. Das Framework kann mit jeder Anbieterimplementierung arbeiten, die eines dieser FCMs erfüllt.
FCM-Version (F) Die höchste Version unter allen FCMs in einem Framework-Release.
Ziel-FCM-Version (V) Die gezielte FCM - Version (von S F), ausdrücklich erklärt , in dem Gerät manifest, dass ein Anbieter Implementierung erfüllt. Eine Anbieterimplementierung muss für ein veröffentlichtes FCM generiert werden, obwohl es in seinem Gerätemanifest möglicherweise neuere HAL-Versionen deklariert.
HAL-Version Eine HAL Version hat das Format foo@xy , wo foo der HAL Name ist und xy ist die spezifische Version; zB nfc@1.0 , keymaster@3.0 (die Wurzel - Präfix, zB android.hardware , wird in diesem Dokument weggelassen werden .)
Gerätemanifest XML-Dateien, die angeben, welche HAL-Versionen die Geräteseite der Anbieterschnittstelle, einschließlich der Anbieter- und ODM-Images, bereitstellt. Der Inhalt eines Gerätemanifests wird durch die Ziel-FCM-Version des Geräts eingeschränkt, kann jedoch HALs auflisten, die im Vergleich zum FCM, der V entspricht, absolut neuer sind.
Geräte-HALs HALs, die im Gerätemanifest aufgeführt (bereitgestellt) und in der Framework-Kompatibilitätsmatrix (FCM) aufgeführt sind (entweder erforderlich oder optional).
Gerätekompatibilitätsmatrix (DCM) Eine XML-Datei, die Anbieteranforderungen an konforme Framework-Implementierungen angibt. Jedes Gerät enthält ein DCM.
Rahmenmanifest Eine XML-Datei, die angibt, welche HAL-Versionen die Framework-Seite der Anbieterschnittstelle, einschließlich system, system_ext und Produktimages, bereitstellt. HALs im Framework-Manifest werden entsprechend der Ziel-FCM-Version des Geräts dynamisch deaktiviert.
Framework-HALs HALs, die wie im Framework-Manifest bereitgestellt und in der Gerätekompatibilitätsmatrix (DCM) entweder als erforderlich oder optional aufgeführt sind.

Entwicklung in einer neuen FCM-Version

Android erhöht die FCM-Version für jede Framework-Version (z. B. Android 8, 8.1 usw.). Bei der Entwicklung der neuen compatibility_matrix.current.xml erzeugt ( F ) und die bestehenden compatibility_matrix.f.xml (wobei f < F ) nicht mehr verändert.

Suchen Sie sich in einem neuen FCM Version Entwicklung F :

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

Einführung eines neuen HAL

Während der Entwicklung, wenn eine neue HAL (Wi-Fi, NFC, etc.) , um Android auf der aktuellen FCM Version Einführung F , fügen Sie die HAL compatibility_matrix.current.xml mit den folgenden optional Einstellungen:

  • optional="false" , wenn Geräte das Schiff mit V = F mit diesem HAL starten müssen,

    ODER
  • optional="true" , wenn Geräte das Schiff mit V = F ohne diese HAL starten.

Zum Beispiel Android 8.1 eingeführt cas@1.0 als optionales HAL. Abzugsvorrichtung mit Android 8.1 ist nicht berechtigt diesen HAL implementieren erforderlich, so dass der folgende Eintrag hinzugefügt wurde compatibility_matrix.current.xml (umbenannt in compatibility_matrix.2.xml nach Android 8.1 veröffentlicht):

<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 (geringfügig)

Während der Entwicklung, wenn eine HAL ein untergeordnete-Versions - Upgrade von hat xz zu x.(z+1) bei aktuellen FCM Version F , falls diese Version ist:

  • Erforderlich auf Abzugsvorrichtung mit V = F , der compatibility_matrix.current.xml must Zustand x.(z+1) und optional="false" .
  • Nicht erforderlich bei Geräten mit Start V = F , die compatibility_matrix.current.xml muss kopieren xy-z und Optionalität von compatibility_matrix.<F-1>.xml und ändern Sie die Version xw-(z+1) (wobei w >= y ).

Zum Beispiel Android 8.1 eingeführt broadcastradio@1.1 als kleinere Version 1.0 HAL aktualisieren. Die ältere Version, broadcastradio@1.0 ist optional für Geräte mit Android 8.0 starten , während die neueren Version, broadcastradio@1.1 , optional für Geräte mit Android 8.1 starten. 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 kopiert compatibility_matrix.current.xml (umbenannt in compatibility_matrix.2.xml nach Android 8.1 veröffentlicht) 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 (Hauptfach)

Während der Entwicklung , wenn ein HAL ein Haupt-Versions - Upgrade bei aktuellen FCM Version hat F , die neue Hauptversion x.0 wird hinzugefügt compatibility_matrix.current.xml mit den folgenden optional Einstellungen:

  • optional="false" mit nur Version x.0 , wenn Geräte das Schiff mit V = F mit starten muss x.0 .
  • optional="false" aber zusammen mit älteren Hauptversionen im gleich <hal> -Tag, wenn Geräten , die mit Schiff V = F mit diesem HAL starten muss, aber mit einer älteren Hauptversion starten.
  • optional="true" , wenn Geräte das Schiff mit V = F nicht die HAL starten müssen.

Zum Beispiel Android 9 einleiten health@2.0 als Haupt-Version Upgrade des 1.0 HAL und deprecates die 1,0 HAL. Die ältere Version, health@1.0 ist optional für Geräte mit Android 8.0 und Android 8.1 starten. Geräte, die mit Android 9 gestartet werden, dürfen nicht die veraltete 1.0 HAL bereitstellen, sondern müssen stattdessen die neue 2.0-Version bereitstellen. In 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 kopiert compatibility_matrix.current.xml (umbenannt compatibility_matrix.3.xml mit der Android - 9 - Version) 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 die 2.0 HAL in ist compatibility_matrix.3.xml mit optional="false" Geräte , die Einführung mit Android 9 muss mit 2,0 HAL versenden.
  • Da die 1,0 HAL nicht in ist compatibility_matrix.3.xml Geräte , die Einführung mit Android 9 muss die 1,0 HAL nicht bieten (wie diese HAL veraltet angesehen wird ).
  • Da die 1.0 HAL in Legacy/1/2.xml (ältere FCM-Versionen, mit denen Android 9 arbeiten kann) als optionale HAL vorhanden ist, kann das Android 9-Framework weiterhin mit der 1.0 HAL (die nicht als entfernte HAL-Version betrachtet wird) arbeiten ).

Neue FCM-Versionen

Der Prozess der Veröffentlichung einer FCM-Version auf der Systempartition wird ausschließlich von Google als Teil einer AOSP-Version durchgeführt und umfasst die folgenden Schritte:

  1. Benennen Sie compatibility_matrix.current.xml zu compatibility_matrix.F.xml .
  2. Stellen Sie sicher , die Datei hat das Attribut level="F" .
  3. Bearbeiten entsprechende Build - Regeln der Dateinamen ändern zu reflektieren.
  4. Stellen Sie sicher, dass alle Geräte erstellt und gestartet werden.
  5. Update VTS testet Geräte mit dem neuesten Rahmen starten , um sicherzustellen , (basierend auf Shipping API - Ebene) hat Ziel FCM Version V >= F .
  6. Veröffentlichen Sie die Datei in AOSP.

Diese Datei kann nicht geändert werden , sobald umbenannt und veröffentlicht. Zum Beispiel, während Android 9 Entwicklung werden die folgenden Dateien gebaut für hardware/interfaces/compatibility_matrices/ :

  • compatibility_matrix.legacy.xml
  • compatibility_matrix.1.xml
  • compatibility_matrix.2.xml
  • compatibility_matrix.current.xml

Wenn Android 9 freigegeben wird, compatibility_matrix.current.xml wird umbenannt compatibility_matrix.3.xml und die folgenden Dateien für integrierte hardware/interfaces/compatibility_matrices/ :

  • compatibility_matrix.legacy.xml
  • compatibility_matrix.1.xml
  • compatibility_matrix.2.xml
  • compatibility_matrix.3.xml

VTS Tests sicherstellen , dass Geräte mit Android starten 9 Ziel FCM Version> = 3 haben.

Darüber hinaus können die FCMs product und system_ext auch Anforderungen für jede Plattform-FCM-Version auflisten. Die Freigabe von FCM-Versionen auf den Partitionen product und system_ext erfolgt jeweils durch den Eigentümer dieser Images. Die FCM-Versionsnummern auf den Produkt- und system_ext-Partitionen müssen mit denen auf der Systempartition übereinstimmen. Ähnlich wie bei den FCM-Versionen auf 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 (dh bei AOSP-HALs trifft Google die Entscheidung). Dies kann passieren, wenn eine höhere HAL-Version (ob Minor oder Major) veröffentlicht wird.

Ein HAL-Gerät als veraltet markieren

Wenn ein bestimmtes Gerät HAL foo@xy bei FCM Version veraltet ist F , bedeutet dies , dass jedes Gerät mit Startziel FCM Version V = F oder später nicht implementieren muss foo in der Version xy oder einer beliebigen Version älter als xy . Eine veraltete HAL-Version wird weiterhin vom Framework zum Aktualisieren von Geräten unterstützt.

Wenn FCM Version F freigegeben wird, eine HAL Version foo@xy ist veraltet angesehen , wenn die spezifische HAL - Version ist nicht explizit im aktuellen FCM für Target FCM Version angegeben V = F . Für Geräte mit Start V = F , eine der folgenden Bedingungen erfüllt ist:

  • Das Framework erfordert eine höhere Version (Major oder Minor);
  • Das Framework benötigt die HAL nicht mehr.

Zum Beispiel in Android 9, health@2.0 wird als Haupt Versions - Upgrade von 1.0 HAL eingeführt. health@1.0 aus entfernt compatibility_matrix.3.xml aber vorhanden ist , in compatibility_matrix.legacy.xml , compatibility_matrix.1.xml und compatibility_matrix.2.xml . Daher health@1.0 veraltet betrachtet.

Ein Framework-HAL . als veraltet markieren

Wenn ein gegebener Rahmen HAL foo@xy bei FCM Version veraltet ist F , bedeutet dies , dass jedes Gerät Start mit Ziel FCM Version V = F oder später nicht den Rahmen zu schaffen , erwarten müssen foo in der Version xy oder an einer beliebigen Version älter als xy . Eine veraltete HAL-Version wird weiterhin vom Framework zum Aktualisieren von Geräten bereitgestellt.

Wenn FCM Version F freigegeben wird, eine HAL Version foo@xy ist veraltet angesehen , wenn der Rahmen Manifest gibt an max-level=" F - 1 " für foo@xy . Für Geräte mit Start V = F , wird der Rahmen für die HAL nicht liefern foo@xy . Das Gerät Kompatibilitätsmatrix auf Geräten mit Start V = F darf nicht Liste Rahmen HALs mit max-level < V .

Zum Beispiel in Android 12, schedulerservice@1.0 ist veraltet. Sein max-level - Attribut gesetzt ist 5 in Android 11. Siehe, die FCM - Version eingeführt Android 12 Rahmen manifestieren .

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

Als aktive Geräte eines bestimmten Ziel FCM Version V Abfall unter einem bestimmten Schwellenwert, wird die Ziel - FCM Version aus dem Satz S F des nächsten Rahmen Release entfernt. Dies geschieht durch die beiden folgenden Schritte:

  • Entfernen compatibility_matrix.V.xml von den Build - Regeln (so dass sie nicht auf dem System - Image installiert ist), und einen Code zu löschen , dass auf der entfernten Funktionalität implementiert oder abhing.
  • Entfernen von Rahmen mit HALs max-level niedriger als oder gleich V aus dem Rahmen manifest und Löschen jeden Code, implementiert der entfernte Rahmen HALs.

Geräte mit einem Ziel FCM Version außerhalb von S F für einen Rahmen Freisetzung gegeben werden , können nicht auf diese Version aktualisieren.

HAL-Versionsstatus

Die folgenden Abschnitte beschreiben (in chronologischer Reihenfolge) die möglichen Zustände einer HAL-Version.

Unveröffentlicht

Bei Geräte-HALs gilt eine HAL-Version, die sich in keiner der öffentlichen und eingefrorenen Kompatibilitätsmatrizen befindet, als unveröffentlicht und möglicherweise in Entwicklung. Dazu gehören HAL Versionen , die nur in sind compatibility_matrix.current.xml . Beispiele:

  • Während der Entwicklung von Android 9 (vor compatibiility_matrix.current.xml umbenannt wird compatibility_matrix.3.xml ), die health@2.0 wurde HAL eine nicht freigegebene HAL betrachtet.
  • Die teleportation@1.0 HAL ist nicht in irgendwelchen freigegeben Kompatibilität Matrices und ist auch eine nicht freigegebene HAL betrachtet.

Wenn sich bei Framework-HALs eine HAL-Version nur im Framework-Manifest eines nicht verwandten Entwicklungszweigs befindet, gilt sie als nicht veröffentlicht.

Veröffentlicht und aktuell

Bei Geräte-HALs wird eine HAL-Version freigegeben, die sich in einer öffentlichen und eingefrorenen Kompatibilitätsmatrix befindet. Zum Beispiel, nach FCM Version 3 eingefroren wird (wenn compatibiility_matrix.current.xml umbenannt wird compatibility_matrix.3.xml ) und AOSP veröffentlicht, die health@2.0 wird HAL eine freigegebene und aktuelle HAL Version betrachtet.

Wenn eine HAL - Version in einer öffentlichen und gefrorenen Kompatibilitätsmatrix ist, die die höchste FCM Version (ohne hat compatibility_matrix.current.xml ), die HAL - Version aktuell ist (dh nicht weiterentwickelt). Zum Beispiel bestehende HAL Versionen (wie nfc@1.0 in eingeführt compatibility_matrix.legacy.xml ) , die in existieren weiterhin compatibility_matrix.3.xml werden auch als freigegeben und aktuelle HAL Versionen berücksichtigt.

Für Rahmen HALs, wenn eine HAL - Version im Rahmen Manifest des neuesten Release - Zweiges ohne ist max-level - Attribut oder (ungewöhnlich) ein max-level gleich oder höher als die FCM - Version in diesem Zweig freigegeben wird , wird er als frei und aktuelle HAL-Version. Zum Beispiel kann die displayservice wird HAL freigegeben und Strom in Android 12, wie durch die Angabe Android 12framework manifest .

Veröffentlicht, aber veraltet

Für Geräte-HALs gilt eine HAL-Version nur dann als veraltet, wenn alle der folgenden Bedingungen erfüllt sind:

  • Es ist freigegeben.
  • Es befindet sich nicht in der öffentlichen und eingefrorenen Kompatibilitätsmatrix, die die höchste FCM-Version hat.
  • Es befindet sich in einer öffentlichen und eingefrorenen Kompatibilitätsmatrix, die das Framework noch unterstützt.

Beispiele:

Daher power@1.0 ist Strom, aber nicht veraltet, in Android 9.

Für Rahmen HALs, wenn eine HAL - Version im Rahmen Manifest des neuesten Release - Zweiges mit einem ist max-level - Attribute niedriger als die FCM - Version in diesem Zweig freigegeben wird , wird es eine Freigabe aber veraltete HAL - Version betrachtet. Zum Beispiel kann der schedulerservice wird HAL freigegeben , aber veraltet in Android 12, wie durch die Angabe Android 12framework manifest .

ENTFERNT

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

  • Es wurde zuvor veröffentlicht.
  • Es befindet sich nicht in einer öffentlichen und eingefrorenen Kompatibilitätsmatrix, die das Framework unterstützt.

Kompatibilitätsmatrizen, die öffentlich sind, eingefroren sind, aber nicht vom Framework unterstützt werden, werden in der Codebasis gehalten, um die entfernten HAL-Versionen zu definieren, sodass 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 dann entfernt, wenn die folgenden Bedingungen erfüllt sind:

  • Es wurde zuvor veröffentlicht.
  • Es ist in keinem Framework-Manifest des neuesten veröffentlichten Zweigs enthalten.

Ältere FCMs

Legacy der Ziel-FCM-Version ist ein besonderer Wert für alle Nicht-Treble-Geräte. Das Erbe FCM, compatibility_matrix.legacy.xml , listet die Anforderungen des Rahmen auf Legacy - Geräte (dh Geräte ins Leben gerufen vor Android 8.0).

Wenn diese Datei für eine FCM mit Version existiert F , jede nicht-Treble Gerät kann aufgerüstet werden F vorgesehen sein Gerät manifest ist mit dieser Datei kompatibel. Die Entfernung erfolgt nach dem gleichen Verfahren wie bei FCMs für andere Ziel-FCM-Versionen (entfernt, nachdem die Anzahl der aktiven Geräte vor 8.0 unter einen bestimmten Schwellenwert gefallen ist).

Freigegebene FCM-Versionen

Die Liste der freigegebenen FCM - Versionen finden Sie unter hardware/interfaces/compatibility_matrices .

Um die FCM - Version mit einer bestimmten Android - Release veröffentlicht zu finden, sieht Level.h .