Entwicklung des Gerätemanifests

Beim Entwickeln und Veröffentlichen neuer Geräte können Anbieter die FCM-Zielversion im Geräte-Manifest (Device Manifest, DM) definieren und deklarieren. Beim Aktualisieren des Anbieter-Images für alte Geräte können Anbieter neue HAL-Versionen implementieren und die Ziel-FCM-Version erhöhen.

Neue Geräte entwickeln

So legen Sie die FCM-Zielversion für neue Geräte fest:

1. Lassen Sie DEVICE_MANIFEST_FILE und PRODUCT_ENFORCE_VINTF_MANIFEST undefiniert.
2. Implementieren Sie HALs für die Ziel-FCM-Version.
3. Schreiben Sie die richtige Geräte-Manifestdatei.
4. Schreiben Sie die Ziel-FCM-Version in die Gerätemanifestdatei.
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 auf den Markt kommt, muss seine ursprüngliche FCM-Zielversion ermittelt und im Gerätemanifest als Attribut „target-level“ im <manifest>-Element der obersten Ebene deklariert werden.

Für Geräte, die mit Android 9 auf den Markt kommen, muss beispielsweise die Ziel-FCM-Version 3 sein (die zu diesem Zeitpunkt verfügbare höhere Version). So deklarieren Sie dies im Gerätemanifest:

<manifest version="1.0" type="device" target-level="3">
    <!-- ... -->
</manifest>

Vendor-Image aktualisieren

Beim Aktualisieren des Anbieter-Images für ein altes Gerät können Anbieter neue HAL-Versionen implementieren und die Ziel-FCM-Version erhöhen.

HALs aktualisieren

Während eines Upgrades des Anbieter-Images können Anbieter neue HAL-Versionen implementieren, sofern HAL-Name, Schnittstellenname und Instanzname gleich sind. Beispiel:

• Google Pixel 2- und Pixel 2 XL-Geräte wurden mit der Ziel-FCM-Version 2 ausgeliefert, in der das erforderliche Audio 2.0-HALandroid.hardware.audio@2.0::IDeviceFactory/defaultimplementiert wurde.
• Für den Audio 4.0 HAL, der mit Android 9 veröffentlicht wurde, können Google Pixel 2 und Pixel 2 XL ein vollständiges OTA-Update auf den 4.0 HAL durchführen, der android.hardware.audio@4.0::IDeviceFactory/default implementiert.
• Obwohl in compatibility_matrix.2.xml nur Audio 2.0 angegeben ist, wurde die Anforderung an ein Anbieter-Image mit der Ziel-FCM-Version 2 gelockert, da das Android 9-Framework (FCM-Version 3) Audio 4.0 in Bezug auf die Funktionalität als Ersatz für die Audio 2.0-HAL betrachtet.

Zusammenfassend lässt sich sagen, dass compatibility_matrix.2.xml Audio 2.0 und compatibility_matrix.3.xml Audio 4.0 erfordert. Die Anforderungen sind also wie folgt:

FCM-Zielversion upgraden

Während eines Anbieter-Image-Upgrades können Anbieter auch die Ziel-FCM-Version erhöhen, um die Ziel-FCM-Version anzugeben, mit der das aktualisierte Anbieter-Image kompatibel ist. Um die FCM-Zielversion eines Geräts zu erhöhen, müssen Anbieter Folgendes tun:

1. Implementieren Sie alle neuen erforderlichen HAL-Versionen für die Ziel-FCM-Version.
2. Ändern Sie die HAL-Versionen in der Geräte-Manifestdatei.
3. Ändern Sie die Ziel-FCM-Version in der Geräte-Manifestdatei.
4. Veraltete HAL-Versionen entfernen

Auf Google Pixel und Pixel XL wurde beispielsweise Android 7.0 eingeführt. Die Ziel-FCM-Version muss also mindestens „legacy“ sein. Im Gerätemanifest wird jedoch die FCM-Zielversion 2 deklariert, da das Anbieter-Image an compatibility_matrix.2.xml angepasst wurde:

<manifest version="1.0" type="device" target-level="2">

Wenn Anbieter nicht alle erforderlichen neuen HAL-Versionen implementieren oder eingestellte HAL-Versionen nicht entfernen, kann die Ziel-FCM-Version nicht aktualisiert werden.

Auf dem Google Pixel 2 und dem Google Pixel 2 XL ist beispielsweise die FCM-Zielversion 2 installiert. Sie implementieren zwar einige von compatibility_matrix.3.xml benötigte HALs (z. B. Audio 4.0, Health 2.0 usw.), entfernen aber nicht android.hardware.radio.deprecated@1.0, das in FCM-Version 3 (Android 9) als veraltet gilt. Daher kann die Ziel-FCM-Version auf diesen Geräten nicht auf 3 aktualisiert werden.

Kernelanforderungen während OTA erzwingen

Geräte mit Android 9 oder niedriger aktualisieren

Auf Geräten mit Android 9 oder niedriger müssen die folgenden CLs cherry-picked werden:

• CL 722283
• CL 722284
• CL 722345

Mit diesen Änderungen wird das Build-Flag PRODUCT_OTA_ENFORCE_VINTF_KERNEL_REQUIREMENTS eingeführt. Das Flag bleibt für Geräte, die mit Android 9 oder niedriger auf den Markt gekommen sind, nicht festgelegt.

• Beim Aktualisieren auf Android 10 prüfen OTA-Clients auf Geräten mit Android 9 oder niedriger die Kernelanforderungen im OTA-Paket nicht richtig. Diese Änderungen sind erforderlich, um die Kernelanforderungen aus dem generierten OTA-Paket zu entfernen.
• Beim Aktualisieren auf Android 11 ist es optional, das Build-Flag PRODUCT_OTA_ENFORCE_VINTF_KERNEL_REQUIREMENTS festzulegen, um die VINTF-Kompatibilität beim Generieren des Updatepakets zu prüfen.

Weitere Informationen zu diesem Build-Flag finden Sie unter Geräte von Android 10 aktualisieren.

Geräte von Android 10 aktualisieren

Mit Android 10 wird ein neues Build-Flag eingeführt: PRODUCT_OTA_ENFORCE_VINTF_KERNEL_REQUIREMENTS. Für Geräte, die bei Markteinführung Android 10 nutzen, wird dieses Flag automatisch auf true gesetzt. Wenn das Flag auf true gesetzt ist, extrahiert ein Skript die Kernelversion und die Kernelkonfigurationen aus dem installierten Kernel-Image.

• Beim Aktualisieren auf Android 10 enthält das OTA-Updatepaket die Kernelversion und -konfiguration. OTA-Clients auf Geräten mit Android 10 lesen diese Informationen, um die Kompatibilität zu prüfen.
• Beim Aktualisieren auf Android 11 werden beim Generieren von OTA-Paketen die Kernel-Version und -Konfiguration gelesen, um die Kompatibilität zu prüfen.

Wenn das Skript diese Informationen für Ihr Kernel-Image nicht extrahieren kann, führen Sie einen der folgenden Schritte aus:

• Bearbeiten Sie das Skript, um Ihr Kernel-Format zu unterstützen, und tragen Sie zum AOSP bei.
• Legen Sie BOARD_KERNEL_VERSION auf die Kernelversion und BOARD_KERNEL_CONFIG_FILE auf den Pfad der erstellten Kernelkonfigurationsdatei .config fest. Beide Variablen müssen aktualisiert werden, wenn das Kernel-Image aktualisiert wird.
• Alternativ können Sie PRODUCT_OTA_ENFORCE_VINTF_KERNEL_REQUIREMENTS auf false festlegen, um die Überprüfung der Kernelanforderungen zu überspringen. Dies wird nicht empfohlen, da Inkompatibilitäten verborgen bleiben und erst bei der Ausführung von VTS-Tests nach dem Update erkannt werden.

Sie können den Quellcode des Skripts zum Extrahieren von Kernelinformationen extract_kernel.py ansehen.