Entwicklung des Gerätemanifests

Beim Entwickeln und Veröffentlichen neuer Geräte können Anbieter die Ziel-FCM-Version im Gerätemanifest (DM) definieren und angeben. Beim Upgrade 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

Beachten Sie beim Definieren der FCM-Version für neue Geräte Folgendes:

  1. Lassen Sie DEVICE_MANIFEST_FILE und PRODUCT_ENFORCE_VINTF_MANIFEST unverändert.
  2. Implementieren Sie HALs für die Ziel-FCM-Version.
  3. Schreiben Sie die richtige Gerätemanifestdatei.
  4. Schreiben Sie die Ziel-FCM-Version in die Gerätemanifestdatei.
  5. Legen Sie DEVICE_MANIFEST_FILE fest.
  6. Legen Sie PRODUCT_ENFORCE_VINTF_MANIFEST auf true fest.

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 Element „<manifest>“ der obersten Ebene deklariert werden.

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

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

Anbieterbild aktualisieren

Beim Upgrade 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

Bei einem Anbieter-Image-Upgrade können Anbieter neue HAL-Versionen implementieren, sofern der HAL-Name, der Interface-Name und der Instanzname identisch sind. Beispiel:

  • Google Pixel 2 und Google Pixel 2 XL, die mit der Ziel-FCM-Version 2 veröffentlicht wurden, in der die erforderliche Audio 2.0 HAL implementiert istandroid.hardware.audio@2.0::IDeviceFactory/default
  • Für die Audio 4.0 HAL, die mit Android 9 veröffentlicht wurde, können Google Pixel 2 und Google Pixel 2 XL ein vollständiges OTA-Update auf die 4.0 HAL durchführen, die android.hardware.audio@4.0::IDeviceFactory/default implementiert.
  • Obwohl in der 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 Audio 4.0 im Android 9-Framework (FCM-Version 3) funktional als Ersatz für Audio 2.0 HAL gilt.

Zusammenfassend gilt: Da für compatibility_matrix.2.xml Audio 2.0 und für compatibility_matrix.3.xml Audio 4.0 erforderlich ist, gelten folgende Anforderungen:

FCM-Version (System) Ziel-FCM-Version (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

Ziel-FCM-Version aktualisieren

Bei einem Anbieter-Image-Upgrade können Anbieter auch die Ziel-FCM-Version erhöhen, um die Ziel-FCM-Version anzugeben, mit der das aktualisierte Anbieter-Image verwendet werden kann. Wenn Anbieter die Ziel-FCM-Version eines Geräts aktualisieren möchten, müssen sie 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ätemanifestdatei.
  3. Ändern Sie die Ziel-FCM-Version in der Gerätemanifestdatei.
  4. Entfernen Sie nicht mehr unterstützte HAL-Versionen.

Google Pixel und Google Pixel XL wurden beispielsweise mit Android 7.0 eingeführt. Daher muss die Ziel-FCM-Version mindestens „Legacy“ sein. Im Gerätemanifest wird jedoch die Ziel-FCM-Version 2 angegeben, da das Anbieter-Image auf compatibility_matrix.2.xml aktualisiert wurde:

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

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

Google Pixel 2 und Google Pixel 2 XL haben beispielsweise die Ziel-FCM-Version 2. Sie implementieren zwar einige von compatibility_matrix.3.xml erforderliche HALs (z. B. Audio 4.0 und Health 2.0), entfernen aber android.hardware.radio.deprecated@1.0 nicht, das in FCM-Version 3 (Android 9) eingestellt wird. Daher kann die Ziel-FCM-Version auf diesen Geräten nicht auf 3 aktualisiert werden.

Erforderliche Kernelanforderungen während des Over-the-air-Updates

Geräte mit Android 9 oder niedriger aktualisieren

Achten Sie darauf, dass auf Geräten mit Android 9 oder niedriger die folgenden CLs ausgewählt werden:

Durch diese Änderungen wird das Build-Flag PRODUCT_OTA_ENFORCE_VINTF_KERNEL_REQUIREMENTS eingeführt und das Flag für Geräte, die mit Android 9 oder niedriger eingeführt wurden, bleibt deaktiviert.

  • 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 Upgrade auf Android 11 können Sie optional das Build-Flag PRODUCT_OTA_ENFORCE_VINTF_KERNEL_REQUIREMENTS festlegen, um die VINTF-Kompatibilität beim Generieren des Update-Pakets zu prüfen.

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

Geräte mit Android 10 aktualisieren

Mit Android 10 wird eine neue Build-Flag eingeführt: PRODUCT_OTA_ENFORCE_VINTF_KERNEL_REQUIREMENTS. Bei Geräten, die mit Android 10 eingeführt wurden, ist dieses Flag automatisch auf true gesetzt. Wenn das Flag auf true festgelegt ist, extrahiert ein Script die Kernelversion und die Kernelkonfigurationen aus dem installierten Kernel-Image.

  • Beim Upgrade auf Android 10 enthält das OTA-Update-Paket die Kernelversion und ‑konfiguration. OTA-Clients auf Geräten mit Android 10 können diese Informationen lesen, um die Kompatibilität zu prüfen.
  • Bei der Aktualisierung auf Android 11 werden bei der Generierung des OTA-Pakets die Kernelversion und die Konfiguration gelesen, um die Kompatibilität zu prüfen.

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

  • Bearbeiten Sie das Script, um Ihr Kernelformat 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 setzen, um die Prüfung der Kernelanforderungen zu überspringen. Dies wird nicht empfohlen, da Inkompatibilitäten ausgeblendet werden und erst bei VTS-Tests nach der Aktualisierung erkannt werden.

Sie können sich den Quellcode des Scripts zur Extraktion von Kernelinformationen ansehen extract_kernel.py.