Entwicklung des Gerätemanifests

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:

1. DEVICE_MANIFEST_FILE verlassen und PRODUCT_ENFORCE_VINTF_MANIFEST nicht definiert.
2. Implementieren Sie HALs für die FCM-Zielversion.
3. Schreiben Sie die richtige Manifestdatei für das Gerät.
4. Schreibe die FCM-Zielversion in die Manifestdatei des Geräts.
5. Legen Sie DEVICE_MANIFEST_FILE fest.
6. Setzen Sie PRODUCT_ENFORCE_VINTF_MANIFEST auf true.

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

1. Implementieren Sie alle neuen erforderlichen HAL-Versionen für die FCM-Zielversion.
2. HAL-Versionen in der Manifestdatei des Geräts ändern
3. Ändern Sie die FCM-Zielversion in der Manifestdatei des Geräts.
4. 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:

• CL 722283
• CL 722284
• CL 722345

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 und BOARD_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 bis false, 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