在开发和发布新设备时,供应商可以在设备清单 (DM) 中定义和声明目标 FCM 版本。升级旧设备的供应商映像时,供应商可以选择实现新的 HAL 版本并递增目标 FCM 版本。
1. Developing new devices
在为新设备定义设备目标 FCM 版本时:
- 不要定义 DEVICE_MANIFEST_FILE 和 PRODUCT_ENFORCE_VINTF_MANIFEST。
- 为目标 FCM 版本实现 HAL。
- 编写正确的设备清单文件。
- 将目标 FCM 版本写入设备清单文件。
- 设置 DEVICE_MANIFEST_FILE。
- 将 PRODUCT_ENFORCE_VINTF_MANIFEST 设为 true。
2. Releasing new devices
当release新设备时,需要确定设备的初始目标 FCM 版本,并在设备清单中通过顶级 <manifest>
元素中的“target-level”属性予以声明。
例如,搭载 Android 9 的设备的目标 FCM 版本必须为 3(目前已提供更高版本)。如需在设备清单中声明此项,请编写以下代码:
<manifest version="1.0" type="device" target-level="3">
<!-- ... -->
</manifest>
3. Upgrading vendor image
升级旧设备的供应商映像时,供应商可以选择实现新的 HAL 版本并递增目标 FCM 版本。
3.1 升级 HAL
在供应商映像升级期间,供应商可以实现新的 HAL 版本,前提是 HAL 名称、接口名称和实例名称均相同。例如:
Google Pixel 2 和 Pixel 2 XL 设备发布时目标 FCM 版本为 2,实现了所需的音频 2.0 HAL android.hardware.audio@2.0::IDeviceFactory/default
。
对于随 Android 9 发布的音频 4.0 HAL,Google Pixel 2 和 Pixel 2 XL 设备可以通过完整 OTA 升级至 4.0 HAL,这样会实现 android.hardware.audio@4.0::IDeviceFactory/default
。
尽管 compatibility_matrix.2.xml 仅指定了音频 2.0,但由于 Android 9 框架(FCM 版本 3)认为音频 4.0 在功能方面可以替代音频 2.0 HAL,因此对采用目标 FCM 版本 2 的供应商映像的要求已放宽。
综上所述,鉴于 compatibility_matrix.2.xml 要求使用音频 2.0,而 compatibility_matrix.3.xml 要求使用音频 4.0,总体要求如下:
FCM Version (System) | Target FCM Version (Vendor) | Requirements |
---|---|---|
2 (8.1) | 2 (8.1) | Audio 2.0 |
3 (9) | 2 (8.1) | Audio 2.0 or 4.0 |
3 (9) | 3 (9) | Audio 4.0 |
3.2 Upgrading Target FCM
在供应商映像升级期间,供应商还可以递增目标 FCM 版本,以指定可与升级后的供应商映像配合使用的目标 FCM 版本。要达到设备的目标 FCM 版本,供应商需要:
- 为目标 FCM 版本实现所有需要的新 HAL 版本。
- 在设备清单文件中修改 HAL 版本。
- 在设备清单文件中修改目标 FCM 版本。
- 移除已弃用的 HAL 版本。
例如,Google Pixel 和 Pixel XL 设备搭载的是 Android 7.0,因此它们的目标 FCM 版本一定至少是旧版。不过,device manifest中声明目标 FCM 版本为 2,因为供应商映像已更新,以符合 compatibility_matrix.2.xml
的要求:
<manifest version="1.0" type="device" target-level="2">
如果供应商未实现所有需要的新 HAL 版本或未移除弃用的 HAL 版本,则无法升级目标 FCM 版本。
例如,Google Pixel 2 和 Pixel 2 XL 设备的目标 FCM 版本为 2。虽然这些设备的供应商确实实现了 compatibility_matrix.3.xml
要求使用的一些 HAL(例如音频 4.0、health 2.0 等),但未移除在 FCM 版本 3 (Android 9) 中弃用的 android.hardware.radio.deprecated@1.0
。因此,这些设备无法将目标 FCM 版本升级至 3。
4. 在 OTA 期间强制执行内核要求(Mandating kernel requirements during OTA)
从 Android 9 或更低版本更新设备
如果设备接收的是 Android 9 更新,请先按需挑选以下 CL,然后再生成 OTA 更新软件包:
CL 722283
CL 722284
CL 722345
这些更改引入了构建标记 PRODUCT_OTA_ENFORCE_VINTF_KERNEL_REQUIREMENTS
,并让该标记保持未设置状态(针对搭载 Android 9 或更低版本的设备)。
- When updating to Android 10, OTA clients on devices running Android 9 or lower don't check kernel requirements in the OTA package correctly. These changes are needed to drop kernel requirements from the generated OTA package.
- When updating to Android 11, it is optional to set the PRODUCT_OTA_ENFORCE_VINTF_KERNEL_REQUIREMENTS build flag to check VINTF compatibility when the update package is generated.
从 Android 10 更新设备
Android 10 引入了一个新的构建标记 PRODUCT_OTA_ENFORCE_VINTF_KERNEL_REQUIREMENTS
。对于搭载 Android 10 的设备,此标记会自动设为 true。当此标记设为 true 时,脚本会从已安装的内核映像中提取内核版本和内核配置,并将此信息写入 OTA 软件包元数据。搭载 Android 10 或更高版本的设备上的 OTA 客户端会读取此信息以检查兼容性。
- When updating to Android 10, OTA update package contains kernel version and configuration. OTA clients on devices running Android 10 read this information to check compatibility.
- When updating to Android 11, OTA package genreation reads kernel version and configuration to check compatibility.
If the script fails to extract this information for your kernel image, do one of the following:
- Edit the script to support your kernel format and contribute to AOSP.
- Set BOARD_KERNEL_VERSION to the kernel version and BOARD_KERNEL_CONFIG_FILE to the path of the built kernel configuration file .config. Both variables must be updated when the kernel image is updated.
- Alternatively, set PRODUCT_OTA_ENFORCE_VINTF_KERNEL_REQUIREMENTS to false to skip checking kernel requirements. This is not recommended because any incompatibility is hidden and is only discovered when running VTS tests after the update.
You can view the source code of the kernel information extraction script extract_kernel.py
评论 (0)