| RFC-0115：build 类型 | |
|---|---|
| 状态 | 已接受 |
| 领域 |
|
| 说明 | 产品 build 类型的规范定义。 |
| Gerrit 更改 | |
| 作者 | |
| 审核人 | |
| 提交日期（年-月-日） | 2021-07-06 |
| 审核日期（年-月-日） | 2021-07-21 |
摘要
本文档介绍了 Fuchsia 的不同产品 build 类型：
eng、userdebug和user。
Fuchsia 中的构建类型是指应用的构建时间和运行时设置， 产品配置：
构建时设置包括软件包、工具、签名配置 以及定义系统行为的标志
运行时设置包括传递给正在运行的内核或软件的标志 根据 build 类型调制运行时行为。
本文档旨在正式批准 为已使用这些 API 的 Fuchsia 产品而打造的 build 类型。它还为不同服务 构建类型。
设计初衷
Fuchsia 定义了几种 build 类型，以供不同的用户使用 其中包括开发者、测试人员和最终用户。这些用户中的每一个 人们对跑步行为或 紫红色系统。
特定的 build 类型编码并保证特定 Fuchsia 系统 针对不同应用场景（如开发或产品） 提供给最终用户
此外，制作时间决策，例如将特定 package flavor，用于根据商品指定 build 类型。如需了解详情，请参阅 Package Flavors 部分 以及示例。
因此，不同的 build 类型提供了必要的灵活性 Fuchsia 平台及其用户支持 紫红色产品。
设计
本部分概述了 紫红色。它详细介绍了每种类型的不同属性以及 运行时约束条件（如果适用）。
另外还要牢记一个限制 因为其复杂性和实施成本较高。请参阅 缺点部分了解详情。
根据 Fuchsia 的当前要求， build 类型：
useruserdebugeng
如需关于 build 类型的详细说明，请参阅定义 部分。
其他 build 类型将要求提案通过 RFC 流程并得到 Fuchsia 工程小组的批准 委员会 (FEC)。
目标
此类设计的主要目标是：
- 为支持开发者的 build 类型正式制定通用惯例 以及最终的商品配送要求
- build 类型的实现方式尽可能相似， 产品行为的其他差异。
- build 类型已发布和资格审查时，具有相同的标准和 频率
定义
user
user build 类型用于出厂设备
最终用户。
对于 user build，该平台会强制执行最高的安全保证
并且仅包含产品所需的组件
。
userdebug
默认情况下，userdebug build 类型的行为与 user 相同，但允许
了解其他调试和插桩行为。
userdebug build 主要用于开发设备，
最终用户的产品测试和资格审查。
eng
eng build 类型主要面向开发者、测试人员和靴子
对完整产品体验而言，这由产品会话定义。
树内提供各种产品配置的 eng build，
以及作为预构建的系统映像与 Fuchsia SDK 一起提供。
产品配置
build 类型定义为产品专属配置。保持 具有相似性，则配置会继承和包含 来自 Fuchsia 的核心产品，并有选择地添加或移除软件包 和配置
build 类型关系可以总结如下：
图 1：作为产品配置的 build 类型。
注意：
eng 构建类型会继承 core，并且可以包含其他 产品专属的套装
user build 类型直接继承 core，但移除了任何额外的 软件包、调试功能和其他插桩属性。
然后，userdebug 将继承 user，并且仅与 启用调试和调试所需的其他功能 插桩。
userdebug 和 user 之间的反向继承可确保 最终用户产品需要对 user 所做的任何更改都会 自动反映在 userdebug 版本中。
设计大致反映了产品周期，其中
eng是 定义的首个产品配置，基于core构建 紫红色产品。然后，当产品 生命周期，定义userdebug和user来反映 应用场景和要求
实现
以下部分介绍了每种 build 类型的实现详情，如 组织在平台的主要区域
断言
Zircon 是为 Fuchsia 提供支持的核心平台， 由内核和一小部分用户空间服务、驱动程序、 和库。
在整个
代码库。还有内核和用户模式断言：
具体取决于构建类型。例如
对于所有 build 类型，ZX_ASSERT 始终处于启用状态，并且价格必须低于
以免影响性能
在另一个示例中，eng build 中的 assert_level 为 2，并启用
所有断言，同时在 userdebug 和 user build 中这是 0，
会停用标准 C assert() 和 ZX_DEBUG_ASSERT。
下表概述了内核中的断言：
| 属性 | 工程师 | userdebug、user |
|---|---|---|
| 评估 | 开启 | 开启 |
| DEBUG_ASSERT | 开启 | 关闭 |
| assert() | 开启 | 关闭 |
恢复分区
Fuchsia 最终用户产品使用 A/B/R 更新和恢复方案。
总的来说，该系统通过无线下载 (OTA) 机制进行更新， 利用 A/B 更新机制，在这种机制中，系统有两个副本 存在（一个处于活动状态，另一个处于非活动状态）。这可确保系统 具有回退机制，以防更新失败不过，后备是 无法启动，系统会使用存储在 recovery 分区来尝试恢复系统。
每个产品都可以定义自己的恢复映像。默认情况下，在 eng 中
则使用 zedboot。由于使用的是 zedboot
铺 Fuchsia 系统的功能时，它会提供调试
以恢复系统。
在 userdebug 和 user 中，使用不同的恢复映像，即
且符合最终用户产品的安全要求。
| 属性 | 工程师 | userdebug、user |
|---|---|---|
| 恢复 (R) | Zedboot | 最小恢复映像 |
软件包和更新
软件包自动更新
在 eng build 类型中，auto_update_packages 已启用
默认情况。因此，在解析组件时（即通过运行组件），
更新组件包的首先尝试
fuchsia.pkg.PackageResolver。
在日常开发中，此工具对于确保系统 始终运行来自开发者环境中的最新组件。
对于 userdebug 和 user build，此功能已停用。任何更改
对组件和软件包进行的更新
这会更改 base 系统中的软件包，
会触发重新启动。
| 属性 | 工程师 | userdebug、user |
|---|---|---|
| auto_update_packages | true | false |
软件包变种
软件包变种用于指定 eng
然后包含软件包的 eng 变种
组件。该软件包随后会包含在产品配置中
它定义了 eng build 类型。
例如：
package_flavor_selections += [
{
name = "my_component_pkg"
flavor = "eng"
},
]
同样，软件包的 user 变种会包含在 user 中
打造产品
系统更新
Fuchsia 使用无线下载 (OTA) 更新机制
系统更新。有两个入口点
omaha-client 或 system-update-checker 组件：
| 属性 | 工程师 | userdebug、user |
|---|---|---|
| 自动系统 OTA | false | true |
| 更新检查工具 | system-update-checker |
omaha-client |
| Omaha 配置 | 不适用 | 已定义 |
Omaha 配置定义了服务器端配置
适用于最终用户 build 的系统更新，例如 userdebug
和user。
Omaha 配置包含存储在
VBMeta，以确保软件的完整信任根
在执行前进行验证。
软件包集、可运行组件和许可名单
Fuchsia 开发板和产品定义扩充了三个依赖关系， 基础、缓存和宇宙。因此， 在这些集合中定义的软件包 确定它们在 Fuchsia 中的管理方式。
例如，只能通过以下方法对 base 集中的软件包进行更改：
系统 OTA 更新。因此，需要重新启动系统。
由于 universe 集允许访问整个 Fuchsia
软件集，则不允许在 user build 中使用。
| 属性 | 工程师 | userdebug | 用户 |
|---|---|---|---|
| 可用套装 | 基本、缓存、宇宙 | 基本、缓存、宇宙 | 基础 |
| 许可名单 | 允许所有软件包 | 基准 + 许可名单 | 仅基准 |
许可名单是一种政策，
确定可以运行哪个组件（根据组件网址）或
哪个组件可以在运行时访问特定服务有用
例如，为了确保 user build 不会运行开发
用于 eng build 的组件或服务。
再举一个例子，userdebug build 允许
运行用于检查系统的工具，如 iquery
来检查正在运行的组件的属性。
在 user 中，只有运行产品所需的软件
允许。在当前设计中，此软件仅限于
包含在 base 集中。
软件来源
Fuchsia 软件通过托管在 软件代码库。这些软件来源必须 并且通过链式加密链以加密方式验证 信任。
对于 eng build，对哪些软件来源没有限制
可在运行时添加到系统中。
对于 userdebug build，只有在
目标系统通过直接接口连接到开发者的
主机工作站。
user build 中的软件源代码是固定的，无法修改。
调试、日志和 Shell
eng 版本支持对 Fuchsia 系统的完整访问权限，并
所有调试端口和日志user 个 build 会限制所有访问和记录
userdebug 仅出于调试目的启用了有限的访问权限。
| 属性 | 工程师 | userdebug | 用户 |
|---|---|---|---|
| ssh | 已启用 | 已启用 | 已停用 |
| 序列号 | 已启用 | r/o 引导加载程序和内核 | 引导加载程序中的 r/o |
| debug_agent | 已启用 | 已停用 | 已停用 |
| k 命令 | 已启用 | 已停用 | 已停用 |
| ffx 运行时 | 已启用 | 已启用 | 已停用 |
崩溃报告
崩溃报告服务由fuchsia.feedback提供
API。默认情况下，系统会为 eng 停用崩溃上传功能
build。对于 user 和 userdebug build，必须明确征得用户同意
用于启用崩溃报告上传功能。
系统仍会捕获崩溃报告并将其存储在本地崩溃报告中 默认用于所有 build。
| 属性 | 工程师 | userdebug、user |
|---|---|---|
| 崩溃报告 | 已启用 | 已启用 |
| 崩溃上传 | 已停用 | 经用户同意后允许 |
崩溃上传的内容包括系统和内核日志文件以及组件 检查数据，以帮助进行问题分类。这些数据文件可以包含 个人身份信息 (PII)， 上传。
遥测
Fuchsia 平台提供了记录、收集和分析数据的服务
指标。此服务由 fuchsia.metrics 提供。
Cobalt 的两大支柱是保护用户
并提供高质量的汇总指标来满足
系统和组件软件开发者的需求。
| 属性 | 工程师 | userdebug、user |
|---|---|---|
| 指标收集 | 已启用 | 已启用 |
| 指标上传 | 已启用 | 经用户同意后允许 |
已验证执行
验证执行是 Fuchsia 安全性的中心设计，可确保 确保所有执行的代码都是可信的可信度以递归方式计算 通过哈希验证和 从可信实体开始进行数字签名， 不可变的信任锚。
启动时验证
启动时验证是验证执行的一个阶段，在此阶段中，引导加载程序
用于验证 Fuchsia zbi 是否可信
由引导加载程序执行
本地 build（无论是 eng、userdebug 还是 user）使用树内版本
开发密钥，而为发布构建的 build 则由更多
从安全密钥管理服务中获取的安全密钥。
预构建系统映像
预构建的 eng 映像会在 Fuchsia SDK 中提供，同时
userdebug 和 user build 可直接从 Fuchsia 下载
全球集成构建器。
构建时间优化
Fuchsia 平台的常规构建优化标志保留 在所有 build 类型中都相同，以保持 build 之间的一致性。
在 eng build 中，is_debug 设置为
true，它会将默认标志设置为 debug，而不是 speed，如下所示：
在 user 和 userdebug build 中设置。旗帜在
（在全局 BUILD.gn 文件中包含各种配置）。
对于组件，eng 软件包变种可以包含
使用特殊标记编译的组件。例如：
开发者通常会启用 DCHECK 断言
build 和聊天机器人配置，帮助发现 C++ 中的意外问题
组件。
性能
我们知道，在以下情况下，eng build 可能会导致性能下降：
与 userdebug 个 build 相比，实际惩罚因网址而异
产品和主板类型。主要的影响是启用额外的
以及平台中的断言使用
/zircon/system/ulib/perftest。
在组件中，启用 DCHECK 的 eng 变种还会导致
对性能产生重大影响
基准测试和测试期间使用的值
userdebug 和
user 个 build。对效果进行基准化分析时，首选 userdebug
在 eng build 的基础上构建而成。但这种方法的缺点是
请参阅下方的缺点部分。
安全注意事项
Fuchsia 的设计充分考虑了安全隐患 build 类型。在整个实施过程中 为所有用户提供最高级别的安全保障：
利用经过验证的执行来建立完全经过验证的信任 启动链，并使用单独的签名密钥进行加密 签名。
利用组件框架中的许可名单安全政策 确保仅解析和执行允许的组件。
仅包含供最终用户使用的必要软件包和组件 build。
停用最终用户 build 中的所有访问端口和设施。
隐私注意事项
Google 在设计 Fuchsia build 类型。会清理最终用户 build 上的所有日志，以检查是否存在个人身份信息 (PII) 必须征得用户同意，才能上传崩溃、日志和指标。
文档
build 类型将在 紫红 >概念 >构建系统 因此各个属性都有对应的规范化引用 应用行为。
测试
模拟器
最简单、最直接的方法就是测试 是利用 Fuchsia 模拟器来实现的。
使用模拟器模拟 build 类型后，开发者可以 比较和测试平台和应用的不同行为。 其缺点是测试系统的某些方面，例如 目前不支持 模拟器环境。
发布流程
Fuchsia 利用 CI（持续集成）和 CQ （提交队列）流水线，用于确保构建和测试代码更改 在 CL（更改列表）发布之前以及最终集成期间 。
CQ 流水线，用于跨不同产品构建和测试 CL 更改配置和环境
持续集成流水线、构建和测试已签入的代码 在不同的产品配置中使用相同的集成提交。
由于 build 类型也是作为产品配置实现的，因此所有 build 类型 build 类型配置的构建、测试和发布 通过相同的 CI/CQ 流水线完成此过程。
请注意，只有 eng build 类型的产品配置会进行如下测试：
是 CI/CQ 的一部分。不过，user 和 userdebug 仍是
持续构建流程
设施
测试框架和设施在宇宙中可用
eng 和 userdebug build。这些服务在默认情况下处于停用状态
但已列入可解析和在运行时执行的许可名单。
对于 user build，测试设施未被启用或被禁止
安全政策
例如，Fucsia 使用 SL4F 框架
端到端测试和适用于组件的 test_runner
框架测试。
对于自动化测试用例，可以使用上述框架。但是
如果需要其他软件包或其他工具，请使用 eng
build
缺点、替代方案和未知问题
此 RFC 中记录的设计已实施，并反映了 Fuchsia 产品 build 类型的当前状态。
通过利用产品配置来实现 build 类型，现有的 可以加以利用和重复使用主要的缺点是 这种方法缺乏可伸缩性和灵活性。例如： 对于每个新产品，至少提供三项产品配置 与这三种 build 类型相匹配的参数。存在相关的费用 这种方法可以实现冗余， 启动构建商所需的 Fuchsia 基础架构所需的资源 。
另一个缺点包括对 userdebug build 进行测试。开始时间
userdebug build 包含特定风格的软件包，
系统更新配置，但不启用调试标记，它们是
适合用于运行端到端测试。但由于存在安全限制
无法在官方 userdebug 中运行 SL4F
build。
作为替代方案，您可以使用独立系统组件
能够修改组合的图片，
组建允许测试的本地 userdebug build
框架也较为宽松。
未来，我们应该利用可扩展性更高的方法，
要应用的 eng、userdebug 和 user build 类型配置文件
不同的产品配置这样可以避免线性
新产品需要多个产品的扩缩问题
以适应 build 类型。
另外值得注意的是，当前的实施方式将产品与 但这并不是 Fuchsia 平台的长期期望。 如前所述，建议考虑采用更灵活的设计， 未来。
先验技术和参考资料
Android 操作系统：