Bei der Entwicklung und Veröffentlichung neuer Geräte können Anbieter die FCM-Zielversion im Gerätemanifest (DM) angegeben werden. Beim Upgrade des Anbieter-Images Bei alten Geräten können Anbieter neue HAL-Versionen implementieren die FCM-Zielversion.
Neue Geräte entwickeln
Beim Definieren der FCM-Zielversion für neue Geräte gilt Folgendes:
DEVICE_MANIFEST_FILE
verlassen undPRODUCT_ENFORCE_VINTF_MANIFEST
nicht definiert.- Implementieren Sie HALs für die FCM-Zielversion.
- Schreiben Sie die richtige Manifestdatei für das Gerät.
- Schreibe die FCM-Zielversion in die Manifestdatei des Geräts.
- Legen Sie
DEVICE_MANIFEST_FILE
fest. - Setzen Sie
PRODUCT_ENFORCE_VINTF_MANIFEST
auftrue
.
Neue Geräte veröffentlichen
Wenn ein neues Gerät veröffentlicht wird, muss seine anfängliche FCM-Zielversion
die im Gerätemanifest als
„target-level
“ in der obersten Ebene
<manifest>
-Element.
Beispielsweise müssen Geräte, die mit Android 9 auf den Markt gebracht werden, haben die FCM-Zielversion 3 (die derzeit höhere Version). So deklarieren Sie dies im Gerätemanifest:
<manifest version="1.0" type="device" target-level="3"> <!-- ... --> </manifest>
Anbieterbild upgraden
Beim Upgraden des Anbieter-Images für ein altes Gerät können Anbieter neue HAL-Versionen zu implementieren und die FCM-Zielversion zu erhöhen.
HALs aktualisieren
Während eines Anbieter-Image-Upgrades können Anbieter neue HAL-Versionen implementieren vorausgesetzt, dass der HAL-Name, der Schnittstellenname und der Instanzname identisch sind. Für Beispiel:
- Google Pixel 2 und Pixel 2 XL mit FCM-Zielversion veröffentlicht
2, die die erforderliche Audio-2.0-HAL implementiert haben
android.hardware.audio@2.0::IDeviceFactory/default
- Für das Audio-4.0-HAL, das mit Android veröffentlicht wurde
9 können Google Pixel 2 und Pixel 2 XL eine
vollständiges OTA-Update zum Upgrade auf 4.0 HAL, das
android.hardware.audio@4.0::IDeviceFactory/default
- Auch wenn
compatibility_matrix.2.xml
Audio 2.0 angibt die Anforderung an ein Anbieter-Image mit der FCM-Zielversion 2 gelockert, da das Framework von Android 9 (FCM-Version 3) betrachtet Audio 4.0 hinsichtlich der Funktionalität als Ersatz von Audio 2.0 HAL.
Zusammenfassend lässt sich sagen, dass für compatibility_matrix.2.xml
Für audio 2.0 und compatibility_matrix.3.xml
ist Audio 4.0 erforderlich, die
die folgenden Anforderungen:
FCM-Version (System) | FCM-Zielversion (Anbieter) | Voraussetzungen |
---|---|---|
2 (8,1) | 2 (8,1) | Audio 2.0 |
3 (9) | 2 (8,1) | Audio 2.0 oder 4.0 |
3 (9) | 3 (9) | Audio 4.0 |
FCM-Zielversion aktualisieren
Während eines Anbieter-Image-Upgrades können Anbieter auch den Ziel-FCM-Wert erhöhen. Version zur Angabe der FCM-Zielversion, die das aktualisierte Anbieter-Image verwenden kann mit. Um die FCM-Zielversion eines Geräts anzustoßen, müssen Anbieter folgende Schritte ausführen:
- Implementieren Sie alle neuen erforderlichen HAL-Versionen für die FCM-Zielversion.
- HAL-Versionen in der Manifestdatei des Geräts ändern
- Ändern Sie die FCM-Zielversion in der Manifestdatei des Geräts.
- Entfernen Sie verworfene HAL-Versionen.
Beispielsweise Google Pixel und Pixel XL, die mit Android 7.0 auf den Markt gebracht wurden.
Daher muss die FCM-Zielversion mindestens die alte Version sein. Das Gerät muss jedoch
Manifest deklariert die FCM-Zielversion 2, da das Anbieter-Image
wurde gemäß compatibility_matrix.2.xml
aktualisiert:
<manifest version="1.0" type="device" target-level="2">
Wenn die Anbieter nicht alle erforderlichen neuen HAL-Versionen implementieren oder nicht eingestellten HAL-Versionen ist, kann die FCM-Zielversion nicht aktualisiert werden.
Google Pixel 2 und Pixel 2 XL verwenden beispielsweise die FCM-Version 2.
Es werden zwar einige HALs implementiert, die
compatibility_matrix.3.xml
(z. B. Audio 4.0, Gesundheit 2.0 usw.),
entfernen sie nicht android.hardware.radio.deprecated@1.0
, was
in FCM Version 3 (Android 9) eingestellt. Daher sind diese
Geräte können die FCM-Zielversion nicht auf 3 aktualisieren.
Kernelanforderungen während des OTA-Updates festlegen
Geräte mit Android 9 oder niedriger aktualisieren
Auf Geräten mit Android 9 oder niedriger müssen die folgenden CLs Gepflückt:
Mit diesen Änderungen wird das Build-Flag eingeführt.
PRODUCT_OTA_ENFORCE_VINTF_KERNEL_REQUIREMENTS
und verlassen Sie die
Einstellung nicht für Geräte mit Android 9 oder
darunter.
- Bei der Aktualisierung auf Android 10 OTA-Clients auf Geräten mit Android 9 prüfen Sie die Kernel-Anforderungen im OTA-Paket nicht korrekt. Diese Änderungen sind erforderlich, um die Kernel-Anforderungen aus dem generierten OTA zu entfernen Paket.
-
Bei der Aktualisierung auf Android 11 ist es optional, die
Build-Flag
PRODUCT_OTA_ENFORCE_VINTF_KERNEL_REQUIREMENTS
zur Prüfung von VINTF Kompatibilität beim Generieren des Updatepakets.
Weitere Informationen zu diesem Build-Flag finden Sie unter Geräte über Android aktualisieren 10.
Geräte mit Android 10 aktualisieren
Mit Android 10 wird ein neues Build-Flag eingeführt,
PRODUCT_OTA_ENFORCE_VINTF_KERNEL_REQUIREMENTS
Für Geräte
mit Android 10 eingeführt wurde, ist dieses Flag
automatisch auf true
festgelegt. Wenn das Flag auf
true
, extrahiert ein Skript die Kernel-Version und den Kernel
Konfigurationen aus dem installierten Kernel-Image.
- Bei der Aktualisierung auf Android 10 enthält das OTA-Updatepaket Kernel-Version und -Konfiguration. OTA-Clients auf Android-Geräten 10 lesen diese Informationen, um Kompatibilität.
- Bei der Aktualisierung auf Android 11: Genre des OTA-Pakets Liest die Kernel-Version und -Konfiguration, um die Kompatibilität zu prüfen.
Wenn das Skript nicht extrahiert werden kann, Informationen zu Ihrem Kernel-Image erhalten, führen Sie einen der Folgendes:
- Bearbeiten Sie das Skript so, dass es Ihr Kernel-Format unterstützt und zu AOSP beiträgt.
BOARD_KERNEL_VERSION
auf die Kernel-Version festlegen undBOARD_KERNEL_CONFIG_FILE
zum Pfad des erstellten Kernels Konfigurationsdatei.config
. Beide Variablen müssen aktualisiert werden wenn das Kernel-Image aktualisiert wird.- Alternativ können Sie
PRODUCT_OTA_ENFORCE_VINTF_KERNEL_REQUIREMENTS
bisfalse
, um das Prüfen der Kernel-Anforderungen zu überspringen. Dies wird nicht empfohlen, weil Inkompatibilitäten bleiben verborgen und werden nur bei VTS-Tests nach dem Update erkannt.
Sie können sich den Quellcode des Skripts zur Extraktion von Kernel-Informationen ansehen.
extract_kernel.py