Entwicklung von Gerätemanifesten,Entwicklung von Gerätemanifesten

Bei der Entwicklung und Veröffentlichung neuer Geräte können Anbieter die Ziel-FCM-Version im Gerätemanifest (DM) definieren und deklarieren. Beim Upgrade des Anbieter-Images für alte Geräte können Anbieter wählen, ob sie neue HAL-Versionen implementieren und die Ziel-FCM-Version erhöhen möchten.

Entwicklung neuer Geräte

Beim Definieren der Ziel-FCM-Version des Geräts für neue Geräte:

  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ätemanifestdatei.
  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 .

Veröffentlichung neuer Geräte

Wenn ein neues Gerät veröffentlicht wird, muss seine anfängliche Ziel-FCM-Version bestimmt und im Gerätemanifest als „ target-level “-Attribut im <manifest> -Element der obersten Ebene deklariert werden.

Beispielsweise müssen Geräte, die mit Android 9 gestartet werden, über die Ziel-FCM-Version 3 verfügen (die derzeit verfügbare höhere Version). So deklarieren Sie dies im Gerätemanifest:

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

Anbieterimage aktualisieren

Beim Upgrade des Anbieter-Images für ein altes Gerät können Anbieter wählen, ob sie neue HAL-Versionen implementieren und die Ziel-FCM-Version erhöhen möchten.

HALs aktualisieren

Während eines Anbieter-Image-Upgrades können Anbieter neue HAL-Versionen implementieren, sofern der HAL-Name, der Schnittstellenname und der Instanzname identisch sind. Zum Beispiel:

  • Google Pixel 2- und Pixel 2 XL-Geräte wurden mit Target FCM Version 2 veröffentlicht, die das erforderliche Audio 2.0 HAL android.hardware.audio@2.0::IDeviceFactory/default implementierte.
  • Für das Audio 4.0 HAL, das mit Android 9 veröffentlicht wurde, können Google Pixel 2- und Pixel 2 XL-Geräte ein vollständiges OTA verwenden, um auf das 4.0 HAL zu aktualisieren, das android.hardware.audio@4.0::IDeviceFactory/default implementiert.
  • Auch wenn in der compatibility_matrix.2.xml nur Audio 2.0 angegeben ist, wurde die Anforderung an ein Anbieter-Image mit Target FCM Version 2 gelockert, da das Android 9-Framework (FCM Version 3) Audio 4.0 hinsichtlich der Funktionalität als Ersatz für Audio 2.0 HAL betrachtet .

Zusammenfassend lauten die Anforderungen compatibility_matrix.3.xml folgt compatibility_matrix.2.xml

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

Aktualisieren der Ziel-FCM-Version

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 arbeiten kann. Um die Ziel-FCM-Version 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 HAL-Versionen in der Gerätemanifestdatei.
  3. Ändern Sie die Ziel-FCM-Version in der Gerätemanifestdatei.
  4. Entfernen Sie veraltete HAL-Versionen.

Beispielsweise wurden Google Pixel- und Pixel XL-Geräte mit Android 7.0 gestartet, sodass ihre Ziel-FCM-Version mindestens eine ältere Version sein muss. Das Gerätemanifest deklariert jedoch die Ziel-FCM-Version 2, da das Hersteller-Image aktualisiert wurde, um mit compatibility_matrix.2.xml übereinzustimmen:

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

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

Beispielsweise verfügen Google Pixel 2- und Pixel 2 XL-Geräte über Target FCM Version 2. Sie implementieren zwar einige HALs, die für compatibility_matrix.3.xml erforderlich sind (z. B. Audio 4.0, Health 2.0 usw.), entfernen jedoch nicht android.hardware.radio.deprecated@1.0 , das bei FCM Version 3 (Android 9) veraltet ist. Daher können diese Geräte die Ziel-FCM-Version nicht auf 3 aktualisieren.

Vorschreiben von Kernel-Anforderungen während OTA

Aktualisieren von Geräten von Android 9 oder niedriger

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

Diese Änderungen führen das Build-Flag PRODUCT_OTA_ENFORCE_VINTF_KERNEL_REQUIREMENTS ein und lassen das Flag für Geräte, die mit Android 9 oder niedriger gestartet werden, deaktiviert.

  • Beim Update auf Android 10 prüfen OTA-Clients auf Geräten mit Android 9 oder niedriger die Kernel-Anforderungen im OTA-Paket nicht korrekt. Diese Änderungen sind erforderlich, um Kernel-Anforderungen aus dem generierten OTA-Paket zu entfernen.
  • Beim Update auf Android 11 ist es optional, das Build-Flag PRODUCT_OTA_ENFORCE_VINTF_KERNEL_REQUIREMENTS zu setzen, um die VINTF-Kompatibilität zu überprüfen, wenn das Update-Paket generiert wird.

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

Aktualisieren von Geräten von Android 10

Android 10 führt ein neues Build-Flag ein, PRODUCT_OTA_ENFORCE_VINTF_KERNEL_REQUIREMENTS . Bei Geräten, die mit Android 10 gestartet wurden, wird dieses Flag automatisch auf true gesetzt. Wenn das Flag auf true gesetzt ist, extrahiert ein Skript die Kernel-Version und die Kernel-Konfigurationen aus dem installierten Kernel-Image.

  • Beim Update 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 überprüfen.
  • Beim Update auf Android 11 liest die OTA-Paketgenerierung die Kernel-Version und -Konfiguration, um die Kompatibilität zu überprü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 Kernelformat zu unterstützen und zu AOSP beizutragen.
  • Legen Sie BOARD_KERNEL_VERSION auf die Kernel-Version und BOARD_KERNEL_CONFIG_FILE auf den Pfad der erstellten Kernel-Konfigurationsdatei .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 Kernel-Anforderungen zu überspringen. Dies wird nicht empfohlen, da etwaige Inkompatibilitäten verborgen bleiben und erst entdeckt werden, wenn nach dem Update VTS-Tests ausgeführt werden.

Sie können den Quellcode des Kernel-Informationsextraktionsskripts extract_kernel.py anzeigen.