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 neue HAL-Versionen implementieren und die Ziel-FCM-Version erhöhen.

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 .
  6. Setzen PRODUCT_ENFORCE_VINTF_MANIFEST auf true .

Freigabe neuer Geräte

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

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

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

Aktualisieren des Anbieterimages

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.

Aktualisieren von HALs

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

  • Google Pixel 2- und Pixel 2 XL-Geräte, die mit Target FCM Version 2 veröffentlicht wurden und die erforderliche Audio 2.0 HAL android.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 Pixel 2 XL-Geräte ein vollständiges OTA verwenden, um auf die 4.0 HAL zu aktualisieren, die android.hardware.audio@4.0::IDeviceFactory/default implementiert.
  • Obwohl die Datei „ compatibility_matrix.2.xml “ nur Audio 2.0 angibt, 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 sind die compatibility_matrix.2.xml wie compatibility_matrix.3.xml :

FCM-Version (System) Ziel-FCM-Version (Anbieter) Anforderungen
2 (8,1) 2 (8,1) Ton 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:

  1. Implementieren Sie alle neuen erforderlichen HAL-Versionen für die FCM-Zielversion.
  2. Ändern Sie die HAL-Versionen in der Gerätemanifestdatei.
  3. Ändern Sie die Ziel-FCM-Version in der Gerätemanifestdatei.
  4. Entfernen Sie veraltete HAL-Versionen.

Zum Beispiel Google Pixel- und Pixel XL-Geräte, die mit Android 7.0 eingeführt wurden, sodass ihre Ziel-FCM-Version mindestens veraltet 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 FCM-Zielversion nicht aktualisiert werden.

Zum Beispiel haben Google Pixel 2- und Pixel 2 XL-Geräte Target FCM Version 2. Sie implementieren zwar einige HALs, die von compatibility_matrix.3.xml benötigt werden (z. B. Audio 4.0, Gesundheit 2.0 usw.), entfernen aber 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 mit Android 9 oder niedriger

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

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

  • 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 PRODUCT_OTA_ENFORCE_VINTF_KERNEL_REQUIREMENTS -Kompatibilität zu prüfen, wenn das Update-Paket generiert wird.

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

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-Update-Paket die Kernel-Version 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 Kernelversion und -konfiguration, 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 zu AOSP beizutragen.
  • Setzen BOARD_KERNEL_VERSION auf die Kernel-Version und BOARD_KERNEL_CONFIG_FILE auf den Pfad der erstellten Kernel-Konfigurationsdatei .config . Beide Variablen müssen aktualisiert werden, wenn das Kernel-Image aktualisiert wird.
  • Alternativ können PRODUCT_OTA_ENFORCE_VINTF_KERNEL_REQUIREMENTS auf false setzen, um die Überprüfung der Kernel-Anforderungen zu überspringen. Dies wird nicht empfohlen, da jede Inkompatibilität verborgen ist und erst entdeckt wird, wenn VTS-Tests nach dem Update ausgeführt werden.

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