Fuchsia 旨在进行更新。不过，这也是一项仍在开发中的工作。 本部分将重点介绍一些正在进行或尚未开始的工作，用于提升 Fuchsia 的更改和更新能力。
整个 Surface 中的版本控制和兼容性元数据
- FIDL 支持可用性注释。
- 尚未针对 Fuchsia IDK 中的 C/C++ 头文件实现可用性注解。实现此方法后，下一步是将这些注解应用于 SDK 头文件。
- FIDL API 摘要有助于检测破坏 API 的更改。目前，我们没有针对 C/C++ API 的等效项。通过将内容哈希与已知参考进行比较来检测可能破坏性的更改，这会导致错误检测。例如，重新设置头文件格式与 API 或 ABI 无关，但会错误地触发更改检测器。
- 支持 vDSO 向后兼容性。例如，如果已知某个组件以旧版 ABI 修订版本为目标，Fuchsia 可以将 vDSO shim 加载到其地址空间中，该空间会导出旧 ABI 并调用最新的 vDSO ABI。
- 尚无指明用于构建给定软件包或组件的 Fuchsia SDK 版本的机制。引入这种机制并使用它为预构建软件包添加注解对检测不兼容情况非常有用。
完成从 Fuchsia ABI 到 FIDL 的迁移
虽然 Fuchsia ABI 主要是在 FIDL 中定义的，但仍有一些旧版 ABI 是以其他术语定义的，在更新性方面不具有相同的功能。
- 虽然系统调用是在 FIDL 中定义的，但其某些输入和输出类型在 Zircon 头文件中仍被定义为 C 结构。例如，
zx_object_get_info是在 FIDL 中定义的，但其输出类型（buffer参数）是一个对 FIDL 定义不透明的字节缓冲区，并且采用zx_info_*_tC 结构体的格式。 - processargs 协议用于引导具有启动功能的新创建的进程。引导消息的格式定义为 C 结构体，并且应转换为 FIDL。
完成 Fuchsia SDK
Fuchsia IDK 和以其为基础构建的 SDK 可用于开发 Fuchsia 组件，而无需查看 Fuchsia 的源代码或使用 Fuchsia 自己的构建系统。不过，仍存在一些尚不能脱离树外的开发者用例。
- 尚无法在树外组装产品。具体而言，某些平台组件只能接收树内的配置值，而可扩缩的配置解决方案仍处于设计阶段。
- 目前尚不支持树外组件测试和树外系统测试。某些测试运行时功能仅在树内可用，目前无法扩展测试运行程序框架以支持树外的新测试框架。目前还没有在 SDK 后面编写系统测试的 Fuchsia 系统自动化框架。
- 尚无法针对稳定的驱动程序运行时开发驱动程序。目前提供树内驱动程序开发套件 (DDK)，但尚不支持树外驱动程序开发。我们正在演示第一个树外 Fuchsia 驱动程序。
废弃未列出的平台 ABI
您应严格定义平台 Surface 的完整性，并以 FIDL 等支持通过版本控制和转换支持等机制实现可更新性的 FIDL 等表示方式。目前，平台 surface 的某些方面不符合这些要求。
- 某些树外组件测试框架通过指定平台组件的
fuchsia-pkg://启动网址来为其启动测试替身。这些网址不提供更新功能。相反，树外组件会暴露给平台实现细节，例如包含实现特定平台功能的特定组件的特定软件包的名称。这些测试经常会在 Fuchsia 平台和 SDK 修订版本之间无法正常工作，即使 SDK 或平台接口中未注册破坏 API 或 ABI 的更改。除了弃用现有用例之外，我们还应采取措施防止这些问题再次出现。 - Fuchsia 脚本层 (SL4F) 是一个用于测试的系统自动化框架。SL4F 由主机端测试驱动，该测试使用根据现有系统的规范实现的 JSON-RPC/HTTPS 协议。这一决策加快了移植大量连接测试清单的速度。但是，JSON-RPC/HTTPS 协议的可更新性不如 FIDL 中所提供且对
ffx插件有益，它也没有架构。因此，今后我们不应支持通过树外测试使用 SL4F 进行系统自动化，而应引入替代解决方案。
制定正式的诊断合同
Fuchsia 支持多种诊断工具，可用于了解系统内部状态并排查问题。内部诊断会按其性质显示实现详情，并显示进程名称和层次结构等信息。
例如，在对有缺陷的系统进行问题排查或收集快照时（例如在崩溃后），此信息会很有用。在这种情况下，需要关注内部实现细节。然而，诊断并不适合获得良好的公共合同。
- 可以在运行时使用由选择器指定的
fuchsia.diagnostics.ArchiveAccessor功能读取运行时诊断信息，例如特定组件的 log 或 Inspect 属性。该选择器由一个组件名称、一个诊断层次结构路径选择器和一个属性选择器组成。Moniker 可能会公开平台实现细节，例如拓扑和平台组件名称。层次结构和属性选择器可能也会被视为实现细节，而且它们也没有可更新性机制。这些是基于紫红色的产品中树外组件的已知实例，它们使用诊断选择器在运行时读取系统诊断信息。这些组件会向平台实现细节公开，并且往往会在这些细节发生变化时出现故障。平台本身之外的 Fuchsia 诊断客户端应移植到使用严格定义的 FIDL 协议，以精确读取其所需的信息，并且应限制开放式ArchiveAccessor功能，以供树外组件进一步使用。 - 组件以不同的方式生成诊断信息，例如 Inspect 属性的内部层次结构或日志中的非结构化文本。大多数执行此操作的平台组件都不能保证为此类信息使用特定架构。例如，即使是具有结构和类型的 Inspect，也不具有 FIDL 中提供的所有可更新性功能。因此，离线处理平台诊断信息（例如在 SDK 未提供的工具或产品专属信息中心内）必定会受损。
- 跟踪、CPU 性能监控和
mem等性能工具会收集和公开性能信息，例如进程名称及其相互关系。此信息对于调查某些系统的性能非常有用，但它反映的是私密实现细节，而非公共协定。
弃用旧版开发者工具
我们为 Fuchsia 开发者提供了多种 SDK 工具，最重要的是 ffx 及其众多命令。新的 ffx 工具按照 FIDL 中定义的术语在主机和 Fuchsia 目标之间进行交互，这提供了可更新性。但是，某些旧版工具仍会提供给不具有可更新性功能的外部开发者。
- 支持 SSH（例如使用
funnel工具），可为主机提供类似于目标 Fuchsia 设备上的远程根 shell 的开发者体验。客户端可能会规避预期的平台 Surface，例如通过直接观察、启动和终止系统进程。 - SCP（通过 SSH 复制文件）也获得类似支持，它提供对全局命名空间和可变文件系统的无限制访问权限，再次规避预期的平台表面。
- 某些开发者功能（示例）作为旧版 shell 组件（而不是
ffx命令）向开发者公开。这样可让开发者看到无法轻易更改的平台实现细节（例如软件包和组件的名称），并将输入和输出表示为人类可读的文本（而不是类型化数据和结构化数据）。 - 某些
ffx命令（例如ffx component）会公开组件名称和拓扑等内部实现详情。它们用于诊断和问题排查，不能作为 API 使用。
兼容性测试
您可以使用与静态分析工具和构建系统的持续集成来检查 API 和 ABI 兼容性。此外，Fucsia 兼容性测试套件 (CTS) 可以测试不同的受支持平台和 SDK 版本组合。这些测试可以扩展 API 和 ABI 的兼容性概念，确保保留重要的预期行为。
CTS 项目是新的，覆盖范围相当低。CTS 是一种深度防御形式，因此提高覆盖率有助于确保兼容性，即使 CTS 覆盖率从未覆盖平台 Surface 的 100% 也是如此。