Android 共享系统映像

本页将介绍几种机制,Android 设备 OEM 可利用这些机制构建自己的跨产品线共享系统映像 (SSI)。此外,本页还将介绍在基于 AOSP 的通用系统映像 (GSI) 基础上构建 OEM 专有 SSI 的过程。

背景

Treble 计划将整个 Android 拆分为两个部分:特定于硬件的部分(供应商实现)和通用操作系统部分(Android 操作系统框架)。各部分的软件安装于不同分区中:特定于硬件的软件安装于供应商分区中,而通用操作系统软件则安装于系统分区中。一个称为供应商接口 (VINTF) 的版本化接口在这两个分区中定义和强制执行。使用此分区系统,您可以在不修改供应商分区的情况下修改系统分区,反之亦然。

动机

在 AOSP 中发布的框架代码符合 Treble 架构标准,并保持与旧版供应商实现的向后兼容性。例如,基于 Android 10 AOSP 源代码构建的通用系统映像可以在任何搭载 Android 8 或更高版本的符合 Treble 标准的设备上运行。消费者设备上搭载的 Android 版本由 SoC 供应商和 OEM 修改。(请参阅 Android 版本的生命周期。)对框架做出的这些更改和扩展并未以保持向后兼容性为目标,这增加了操作系统升级的复杂性和成本。此类针对具体设备的变更和修改,增加了升级 Android 操作系统版本的成本和复杂性。

在 Android 11 之前,并无明确架构可帮助合作伙伴为 Android 操作系统框架构建模块化扩展。本文档将介绍 SoC 供应商和 OEM 可执行哪些步骤来创建 SSI。这意味着:在多款设备上重复使用以 Android 操作系统框架源代码为基础构建的同一个映像,从而保持与供应商实现的向后兼容性,并显著降低 Android 操作系统升级的复杂性和成本。如需了解创建 SSI 所需的具体步骤,请参阅基于 GSI 的 SSI 的建议步骤部分。请注意,您不必执行全部 4 个步骤。您选择的步骤(例如,仅第 1 步)取决于您的实现。

SSI 概览

在 SSI 中,特定于产品的软件组件和 OEM 扩展会被放入新的 /product 分区中。/product 分区中的组件使用明确定义的稳定接口与 /system 分区中的组件进行交互。OEM 可以选择构建一个 SSI,也可以选择将少量 SSI 用于多个设备 SKU。Android 操作系统的最新版本发布后,OEM 只需投入一次时间和精力将 SSI 更新至最新 Android 版本。然后即可重复使用 SSI 更新多款设备,而无需更新 /product 分区。

请注意,OEM 和 SoC 供应商构建的 SSI 包含 OEM 所需的所有自定义功能和修改。本页介绍的机制和最佳做法旨在帮助 OEM 实现以下关键目标:

  • 在多个设备 SKU 上重复使用 SSI。
  • 使用模块化扩展更新 Android 系统,以便更轻松地升级操作系统。

将特定于产品的组件划分到产品分区的核心理念,类似于 Treble 将特定于 SoC 的组件划分到供应商分区的理念。产品接口(类似于 VINTF)可实现 SSI 和产品分区之间的通信。请注意,就 SSI 而言,“组件”这一术语是指安装在映像中的所有资源、二进制文件、文本、库等,而这些本质上会成为分区。

围绕 SSI 的分区

图 1 显示了围绕 SSI 的分区,以及不同分区间的版本化接口和接口政策。本部分将详细介绍每个分区和接口。

围绕 SSI 的分区和接口方框图

图 1. 围绕 SSI 的分区和接口

映像和分区

本部分中的信息对术语“映像”和“分区”进行了区分。

  • “映像”是可以独立更新的一组软件的概念性整体。
  • “分区”是可以独立更新的一个物理存储位置。

图 1 中各部分的定义如下:

  • SSISSI 是 OEM 通用的映像,可以存在于多个设备上。它不包含任何特定用于硬件或特定于产品的组件。根据定义,指定 SSI 中的所有内容都在使用该 SSI 的所有设备之间共享。SSI 可由单个 /system 映像组成,也可由 /system/system_ext 分区组成,如图 1 所示。

    • /system 分区包含基于 AOSP 的组件,而 /system_ext 实现后则包含 OEM 和 SoC 供应商扩展,以及与 AOSP 组件紧密耦合的组件。例如,为 OEM 自己的应用提供自定义 API 的 OEM Java 框架库,相较 /system 分区更适合 /system_ext 分区。/system 分区和 /system_ext 分区的内容是基于 OEM 修改的 Android 源代码构建而成。

    • /system_ext 分区是可选项,但建议您将其用于与基于 AOSP 的组件紧密耦合的任何自定义功能和扩展。这些区别可帮助您确定需要进行的更改,以便在一段时间内将此类组件从 /system_ext 分区迁移到 /product 分区。

  • 产品:一组特定于产品或设备的组件,用于表示 OEM 对 Android 操作系统的自定义和扩展。将特定于 SoC 的组件放入 /vendor 分区。SoC 供应商还可以使用 /product 分区来支持相应的组件,如独立于 SoC 的组件。例如,如果 SoC 供应商向其 OEM 客户提供了独立于 SoC 的组件(可选择是否随产品一起提供),则 SoC 供应商可以将该组件放于产品映像中。组件的位置并非由其所有权决定,而是由其用途决定。

  • 供应商:一组特定于 SoC 的组件。

  • ODM:并非由 SoC 提供的一组板级组件。通常,SoC 供应商拥有供应商映像,而设备制造商拥有 ODM 映像。若并无单独的 /odm 分区,SoC 供应商和 ODM 映像将合并到 /vendor 分区。

映像之间的接口

围绕 SSI 存在两个用于供应商映像和产品映像的主要接口:

  • 供应商接口 (VINTF):VINTF 是位于供应商和 ODM 映像中的组件的接口。产品映像和系统映像中的组件只能通过此接口与供应商和 ODM 映像进行交互。例如,供应商映像不能依赖于系统映像的私有部分,反之亦然。Treble 计划最初提出了该定义,将映像拆分为系统分区和供应商分区。该接口的实现机制如下:

    • HIDL(直通式 HAL 仅适用于 systemsystem_ext 模块)
    • 稳定的 AIDL
    • 配置
      • 系统属性 API
      • 配置文件架构 API
    • VNDK
    • Android SDK API
    • Java SDK 库
  • 产品接口:产品接口是 SSI 与产品映像之间的接口。定义稳定的接口会将产品组件与 SSI 中的系统组件分离开来。产品接口需要与 VINTF 相同的稳定接口。然而,搭载 Android 11(及更高版本)的设备只会强制执行 VNDK 和 Android SDK API。

在 Android 11 中启用 SSI

本部分将介绍如何在 Android 11 中使用新功能来支持 SSI。

/system_ext 分区

Android 11 中引入了 /system_ext 分区作为可选分区。(该分区是放置 /system 分区中与 AOSP 定义的组件紧密耦合的非 AOSP 组件的位置。)/system_ext 分区被视为是 /system 分区特用于 OEM 的扩展,且未在两个分区间定义接口。/system_ext 分区中的组件可以对 /system 分区进行私有 API 调用,反之,/system 分区中的组件也可以对 /system_ext 分区进行私有 API 调用。

由于两个分区紧密耦合,Android 新版本发布时,这两个分区也会一起升级。为上一个 Android 版本创建的 /system_ext 分区不需要与下一个 Android 版本的 /system 分区兼容。

如需将模块安装到 /system_ext 分区,请将 system_ext_specific: true 添加到 Android.bp 文件。对于没有 /system_ext 分区的设备,请将此类模块安装到 /system 分区的 ./system_ext 子目录中。

历史信息

以下是一些关于 /system_ext 分区的历史信息。其设计目标是将所有特用于 OEM 的组件放入 /product 分区中,无论这些组件是否通用。然而,无法一次性迁移所有组件,尤其是在某些组件与 /system 分区紧密耦合的情况下。如需将紧密耦合的组件迁移到 /product 分区,必须扩展产品接口。这通常需要对组件本身进行大量重构,需要付出大量的时间和精力。首先将尚未准备好迁移到 /product 分区的组件临时放于 /system_ext 分区。SSI 的目标是最终弃用 /system_ext 分区。

然而,/system_ext 分区有助于使 /system 分区尽可能靠近 AOSP。使用 SSI 时,大部分升级工作都依赖于 /system 分区和 /system_ext 分区中的组件。如果系统映像的构建点与 AOSP 中的源代码相似,您可以将升级工作重点放在 system_ext 映像上。

/system/system_ext 分区中的组件取消捆绑,并放入 /product 分区

Android 9 引入了与 /system 分区结合使用的 /product 分区。/product 分区中的模块对系统资源的使用并无任何限制,反之亦然。为了在 Android 10 中实现 SSI,我们将产品组件拆分并放入 /system_ext 分区和 /product 分区。/system_ext 分区不必遵循 /product 分区在 Android 9 中对系统组件的使用限制。从 Android 10 开始,必须将 /product 分区与 /system 分区取消捆绑,并且必须使用来自 /system 分区和 /system_ext 分区的稳定接口。

/system_ext 分区的主要目的是扩展系统功能,而不是 /system_ext partition 部分所述的安装捆绑的产品模块。为此,请将特定于产品的模块取消捆绑,并将其移至 /product 分区中。解绑特定于产品的模块使得 /system_ext 对设备而言变得通用。(如需了解详情,请参阅将 /system_ext 分区设为通用。)

如需将 /product 分区从系统组件中解绑,/product 分区必须具有与 /vendor 分区(已从 Treble 计划解绑)相同的强制执行政策。

从 Android 11 开始,系统会如下所述强制执行 /product 分区的原生接口与 Java 接口。如需了解详情,请参阅强制执行产品分区接口

  • 原生接口/product 分区中的原生模块必须与其他分区取消捆绑。产品模块唯一允许的依赖项是来自 /system 分区中的部分 VNDK 库(包括 LLNDK)。产品应用所依赖的 JNI 库必须是 NDK 库。
  • Java 接口/product 分区中的 Java(应用)模块无法使用隐藏 API,因为它们不稳定。这些模块只能使用 /system 分区中的公共 API 和系统 API,以及 /system/system_ext 分区中的 Java SDK 库。您可以为自定义 API 定义 Java SDK 库

基于 GSI 的 SSI 的建议步骤

基于 GSI 的 SSI 的建议分区方式

图 2. 基于 GSI 的 SSI 的建议分区方式

通用系统映像 (GSI) 是直接基于 AOSP 构建的系统映像。它被用于 Treble 合规性测试(例如,CTS-on-GSI)并作为参考平台,可供应用开发者在没有运行所需 Android 版本的实际设备时,测试应用的兼容性。

OEM 也可以使用 GSI 创建其 SSI。如映像和分区中所述,SSI 由 AOSP 定义的组件的系统映像和 OEM 定义的组件的 system_ext 映像组成。将 GSI 用作 system 映像时,OEM 可以将工作重点放在用于升级的 system_ext 映像上。

本部分为希望在使用 AOSP 或近 AOSP 系统映像时,将其自定义模块化放入 /system_ext 分区和 /product 分区的 OEM 提供指南。如果 OEM 从 AOSP 源代码构建系统映像,则可以使用 AOSP 提供的 GSI 代替他们构建的系统映像。然而,OEM 无需一次性完成全部步骤(按原计划使用 GSI)。

第 1 步:为 OEM 系统映像 (OEM GSI) 沿用 generic_system.mk

通过沿用 generic_system.mk(在 Android 11 中名为 mainline_system.mk 并在 AOSP 中重命名为 generic_system.mk),系统映像 (OEM GSI) 包含 AOSP GSI 中的所有文件。这些文件可由 OEM 修改,因此除 AOSP GSI 文件外,OEM GSI 还可包含特定于 OEM 的文件。然而,不允许 OEM 修改 generic_system.mk 文件本身。

为 OEM GSI 沿用 `generic_system.mk`

图 3. 为 OEM 系统映像沿用 generic_system.mk

第 2 步:使 OEM GSI 与 AOSP GSI 具有相同的文件列表

OEM GSI 无法在此阶段提供额外的文件。特定于 OEM 的文件必须移至 system_ext 分区或 product 分区。

将添加的文件移出 OEM GSI

图 4. 将添加的文件移出 OEM GSI

第 3 步:在 OEM GSI 中定义允许列表,以限制修改后的文件

为检查修改后的文件,OEM 可以使用 compare_images 工具,并将 AOSP GSI 与 OEM GSI 进行比较。从 AOSP 启动目标 generic_system_* 获取 AOSP GSI。

通过定期使用 allowlist 参数运行 compare_images 工具,您可以监控允许列表之外的差异。如此,您就无需对 OEM GSI 进行其他修改。

定义允许列表,以缩短 OEM GSI 中的已修改文件列表

图 5. 定义允许列表,以缩短 OEM GSI 中的已修改文件列表

第 4 步:使 OEM GSI 具有与 AOSP GSI 相同的二进制文件

通过清理允许列表,OEM 可以将 AOSP GSI 用作其产品的系统映像。为清理允许列表,OEM 可以放弃 OEM GSI 中的更改,或将更改提交到 AOSP 中,以便 AOSP GSI 包含更改。

使 OEM GSI 具有与 AOSP GSI 相同的二进制文件

图 6. 使 OEM GSI 具有与 AOSP GSI 相同的二进制文件

为 OEM 定义 SSI

在构建时保护 /system 分区

为避免在 /system 分区中执行任何特定于产品的更改并定义 OEM GSI,OEM 可以使用名为 require-artifacts-in-path 的 makefile 宏,来阻止在调用该宏后声明任何系统模块。请参阅创建 makefile 和启用工件路径检查示例

OEM 可以定义一个列表,以允许在 /system 分区中临时安装特定于产品的模块。然而,该列表必须为空,以使 OEM GSI 对所有 OEM 产品通用。此过程用于定义 OEM GSI,并且可独立于 AOSP GSI 的步骤

强制执行产品接口

为保证 /product 分区取消捆绑,OEM 可以通过为原生模块设置 PRODUCT_PRODUCT_VNDK_VERSION:= current 以及为 Java 模块设置 PRODUCT_ENFORCE_PRODUCT_PARTITION_INTERFACE:= true,确保其设备强制执行产品接口。如果设备的 PRODUCT_SHIPPING_API_LEVEL 大于或等于 30,系统会自动设置这些变量。如需了解详情,请参阅强制执行产品分区接口

/system_ext 分区设为通用

/system_ext 分区可能因设备而异,因为它可以具有特定于设备的系统捆绑模块。由于 SSI 由 /system/system_ext 分区组成,因此 /system_ext 分区的差异会阻碍 OEM 定义 SSI。OEM 可以拥有自己的 SSI,并可以通过消除任何差异并将 /system_ext 分区设为通用,而在多个设备之间共享该 SSI。

本部分介绍有关将 /system_ext 分区设为通用的建议。

在系统分区中公开隐藏 API

许多特定于产品的应用无法安装在产品分区中,因为它们使用隐藏 API,产品分区中禁止使用此类 API。如需将特定于设备的应用迁移到产品分区,请撤销使用隐藏 API。

从应用中移除隐藏 API 的首选方法是用公共 API 或系统 API 进行替换。如并无可用于替换的 API,OEM 可以帮助 AOSP 为其设备定义新的系统 API。

此外,OEM 也可以通过在 /system_ext 分区中创建自己的 Java SDK 库来定义自定义 API。它可以使用系统分区中的隐藏 API,也可以向产品分区或供应商分区中的应用提供 API。 OEM 必须冻结面向产品的 API 以实现向后兼容性。

包含所有 APK 超集,并跳过每台设备的部分软件包安装

与系统捆绑的某些软件包在不同设备之间并不通用。很难将这些 APK 模块取消捆绑,并将其迁移到产品分区或供应商分区中。作为临时解决方案,OEM 可以让 SSI 包含所有模块,然后通过 SKU 属性 (ro.boot.hardware.sku) 过滤不需要的模块。为使用过滤器,OEM 可叠加框架资源 config_disableApkUnlessMatchedSku_skus_listconfig_disableApksUnlessMatchedSku_apk_list

如需进行更精确的设置,请声明用于停用不必要的软件包的广播接收器。广播接收器在收到 ACTION_BOOT_COMPLETED 消息时会调用 setApplicationEnabledSetting 以停用该软件包。

定义 RRO,而不使用静态资源叠加层

静态资源叠加层会处理叠加软件包。然而,它可能会阻碍定义 SSI,因此请确保已开启并正确设置 RRO 的属性。通过如下方式设置属性,OEM 可以将所有自动生成的叠加层设置为 RRO。

PRODUCT_ENFORCE_RRO_TARGETS := *
PRODUCT_ENFORCE_RRO_EXCLUDED_OVERLAYS := # leave it empty

如需详细配置,请手动定义 RRO,而不是依靠自动生成的配置。如需了解详情,请参阅运行时资源叠加层 (RRO)。此外,OEM 还可以使用 android:requiredSystemPropertyNameandroid:requiredSystemPropertyValue 属性定义依赖于系统属性的条件 RRO。

常见问题解答 (FAQ)

我能否定义多个 SSI?

具体取决于设备(或设备组)的共性和特性。OEM 可以尝试将 system_ext 分区设为通用,如将 system_ext 分区设为通用中所述。如果设备组具有许多差异,最好定义多个 SSI。

我能否修改 OEM GSI 的 generic_system.mk (mainline_system.mk)?

不能。但 OEM 可以为沿用 generic_system.mk 文件的 OEM GSI 定义新 makefile,并改用新的 makefile。有关示例,请参阅强制执行产品分区接口

我能否从 generic_system.mk 中移除与实现冲突的模块?

不能。GSI 有一组最低限度的可启动和可测试的模块集。如果您认为某个模块并非必需,请通过提交 bug 来更新 AOSP 中的 generic_system.mk 文件。