自 2025 年 3 月 27 日起，我们建议您使用 android-latest-release 而非 aosp-main 构建 AOSP 并为其做出贡献。如需了解详情，请参阅 AOSP 的变更。

设备清单开发

在开发和发布新设备时，供应商可以在设备清单 (DM) 中定义和声明目标 FCM 版本。升级旧设备的供应商映像时，供应商可以选择实现新的 HAL 版本并递增目标 FCM 版本。

开发新设备

在为新设备定义设备目标 FCM 版本时：

不要定义 DEVICE_MANIFEST_FILE 和 PRODUCT_ENFORCE_VINTF_MANIFEST。
为目标 FCM 版本实现 HAL。
编写正确的设备清单文件。
将目标 FCM 版本写入设备清单文件。
设置 DEVICE_MANIFEST_FILE。
将 PRODUCT_ENFORCE_VINTF_MANIFEST 设置为 true。

发布新设备

发布新设备时，需要确定设备的初始目标 FCM 版本，并在设备清单中通过顶级 <manifest> 元素中的“target-level”属性予以声明。

例如，发布时搭载 Android 9 的设备的目标 FCM 版本必须为 3（目前已提供更高版本）。如需在设备清单中声明此项，请编写以下代码：

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

升级供应商映像

升级旧设备的供应商映像时，供应商可以选择实现新的 HAL 版本并递增目标 FCM 版本。

升级 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 版本（系统）	目标 FCM 版本（供应商）	要求
2 (8.1)	2 (8.1)	音频 2.0
3 (9)	2 (8.1)	音频 2.0 或 4.0
3 (9)	3 (9)	音频 4.0

升级目标 FCM 版本

在供应商映像升级期间，供应商还可以递增目标 FCM 版本，以指定可与升级后的供应商映像配合使用的目标 FCM 版本。如要达到设备的目标 FCM 版本，供应商需要：

为目标 FCM 版本实现所有需要的新 HAL 版本。
在设备清单文件中修改 HAL 版本。
在设备清单文件中修改目标 FCM 版本。
移除已弃用的 HAL 版本。

例如，Google Pixel 和 Pixel XL 设备搭载的是 Android 7.0，因此它们的目标 FCM 版本一定至少是旧版。不过，设备清单中声明目标 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。

在 OTA 期间强制执行内核要求

从 Android 9 或更低版本更新设备

在搭载 Android 9 或更低版本的设备上，请确保按需挑选以下 CL：

这些更改引入了构建标志 PRODUCT_OTA_ENFORCE_VINTF_KERNEL_REQUIREMENTS，并让该标志保持未设置状态（针对搭载 Android 9 或更低版本的设备）。

更新到 Android 10 时，搭载 Android 9 或更低版本的设备上的 OTA 客户端无法正确检查 OTA 软件包中的内核要求。需要执行这些更改才能舍弃生成的 OTA 软件包中的内核要求。
更新到 Android 11 时，可以选择设置 PRODUCT_OTA_ENFORCE_VINTF_KERNEL_REQUIREMENTS 构建标志，以在生成更新软件包时检查 VINTF 兼容性。

如需详细了解此构建标志，请参阅从 Android 10 更新设备。

从 Android 10 更新设备

Android 10 引入了新的构建标记 PRODUCT_OTA_ENFORCE_VINTF_KERNEL_REQUIREMENTS。对于搭载 Android 10 的设备，此标志会自动设为 true。当此标志设为 true 时，脚本会从已安装的内核映像中提取内核版本和内核配置。

更新到 Android 10 时，OTA 更新软件包会包含内核版本和配置。搭载 Android 10 的设备上的 OTA 客户端会读取此信息以检查兼容性。
更新到 Android 11 时，OTA 软件包生成脚本会读取内核版本和配置以检查兼容性。

如果脚本无法从内核映像中提取此信息，请执行以下操作之一：

修改脚本以支持您的内核格式，并将该脚本提供给 AOSP。
将 BOARD_KERNEL_VERSION 设为内核版本，并将 BOARD_KERNEL_CONFIG_FILE 设为构建的内核配置文件 .config 的路径。更新内核映像时，必须更新这两个变量。
或者，将 PRODUCT_OTA_ENFORCE_VINTF_KERNEL_REQUIREMENTS 设置为 false 以跳过检查内核要求。我们不推荐这样做，因为任何不兼容行为都会被隐藏，并且仅在更新后运行 VTS 测试时才会被发现。

您可以查看内核信息提取脚本 extract_kernel.py 的源代码。