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:
- Lassen Sie
DEVICE_MANIFEST_FILE
undPRODUCT_ENFORCE_VINTF_MANIFEST
undefiniert. - Implementieren Sie HALs für die Ziel-FCM-Version.
- Schreiben Sie die richtige Gerätemanifestdatei.
- Schreiben Sie die Ziel-FCM-Version in die Gerätemanifestdatei.
- Legen Sie
DEVICE_MANIFEST_FILE
fest. - Setzen Sie
PRODUCT_ENFORCE_VINTF_MANIFEST
auftrue
.
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 .
compatibility_matrix.3.xml
lauten die Anforderungen wie 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:
- Implementieren Sie alle neuen erforderlichen HAL-Versionen für die Ziel-FCM-Version.
- Ändern Sie HAL-Versionen in der Gerätemanifestdatei.
- Ändern Sie die Ziel-FCM-Version in der Gerätemanifestdatei.
- 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 überprü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 undBOARD_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
auffalse
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.
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:
- Lassen Sie
DEVICE_MANIFEST_FILE
undPRODUCT_ENFORCE_VINTF_MANIFEST
undefiniert. - Implementieren Sie HALs für die Ziel-FCM-Version.
- Schreiben Sie die richtige Gerätemanifestdatei.
- Schreiben Sie die Ziel-FCM-Version in die Gerätemanifestdatei.
- Legen Sie
DEVICE_MANIFEST_FILE
fest. - Setzen Sie
PRODUCT_ENFORCE_VINTF_MANIFEST
auftrue
.
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 .
compatibility_matrix.3.xml
lauten die Anforderungen wie 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:
- Implementieren Sie alle neuen erforderlichen HAL-Versionen für die Ziel-FCM-Version.
- Ändern Sie HAL-Versionen in der Gerätemanifestdatei.
- Ändern Sie die Ziel-FCM-Version in der Gerätemanifestdatei.
- 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 undBOARD_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
auffalse
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.