Google 会使用 AI 技术将内容翻译成您偏好的语言。AI 翻译可能包含错误。

版本管理

Magdalena Skarbińska

Demián Renzulli

独立式 Web 应用 (IWA) 在 Web 平台之上提供高信任度、安全且版本离散的运行时环境。在生产环境中（尤其是在受管理的企业中），管理员和开发者需要对软件部署进行精细控制。

为了满足这些要求，Chrome 为 IWA 提供了全面的版本管理功能，包括更新渠道、版本固定和版本降级。这些功能可让您在整个用户群中实现部署可预测性和快速恢复控制。

可用性

版本管理行为取决于 IWA 是由管理员管理还是由用户直接安装：

受管理的 IWA：管理功能（包括政策驱动的固定和降级）将从 Chrome 133 开始提供。
非受管（用户安装的）IWA：面向用户的功能（例如手动选择渠道）将从 Chrome 150 开始提供。

会话类型兼容性

所有版本管理功能（包括更新渠道和版本固定）都与所有 ChromeOS 会话类型完全兼容。其中包括：

标准受管理用户会话
受管理的访客会话 (MGS)
专用的自助服务终端模式环境

更新渠道

通过使用更新渠道，开发者可以针对不同的部署和测试受众群体对特定应用 build 进行细分。如需配置渠道，请向应用更新清单中的每个版本条目添加一个可选的渠道数组字段。这些频道名称不限于固定的平台关键字（例如 canary 或 stable），而是由开发者定义的任意标识符，必须采用小写 ASCII 字母数字字符串格式（可以包含连字符或下划线，但不能包含空格）。如果版本条目完全省略了 channels 字段，Chrome 会隐式地将其可用性默认设置为“default”渠道。最终，管理政策中指定的频道名称必须与清单中定义的字符串完全匹配；任何拼写错误或配置不匹配都会导致无法识别符合条件的版本，从而有效停止这些客户端的更新。

清单配置

如需配置渠道，请向 Web 应用清单中的每个版本条目添加一个可选的 channels 数组。以下是一些需要考虑的事项：

渠道映射：如果版本条目定义了 channels 数组，则该版本只能在指定渠道上安装。
默认后备：如果版本条目完全省略了 channels 字段，Chrome 会假定该版本仅属于 default 渠道。
完全字符串匹配：客户端政策配置中指定的频道名称必须与更新清单中定义的字符串完全匹配（区分大小写）。如果没有版本与目标频道名称匹配，应用将无法找到符合条件的更新。

更新清单示例

以下示例展示了支持多个发布渠道的更新清单：

{
  "versions": [
    {
      "version": "0.1.0",
      "src": "https://github.com/chromeos/iwa-sink/releases/download/v0.1.0/iwa-sink.swbn",
      "channels": ["delta"]
    },
    {
      "version": "0.2.0",
      "src": "https://github.com/chromeos/iwa-sink/releases/download/v0.2.0/iwa-sink.swbn",
      "channels": ["delta", "default"]
    },
    {
      "version": "0.3.0",
      "src": "https://github.com/chromeos/iwa-sink/releases/download/v0.3.0/iwa-sink.swbn",
      "channels": ["beta", "delta"]
    },
    {
      "version": "0.4.0",
      "src": "https://github.com/chromeos/iwa-sink/releases/download/v0.4.0/iwa-sink.swbn"
    }
  ]
}

根据此清单，每个目标渠道都有以下版本：

默认： 0.2.0、0.4.0（缺少明确的渠道，默认为默认渠道）
delta： 0.1.0、0.2.0、0.3.0
beta： 0.3.0

IWA 更新引擎支持通过在应用的更新清单中查找 channels 字段来定位特定发布渠道。

固定版本

在合规性要求高或高度稳定的企业环境中，管理员必须确保设备运行特定版本的业务关键型软件。版本固定功能允许管理员将 IWA 锁定到特定版本，从而停止所有后续后台更新。这为企业提供了一种高度可靠的方式来维护稳定的配置，并遵守严格的内部或行业法规。

如需将独立式 Web 应用 (IWA) 冻结在特定发布 build，企业管理员可以在 IsolatedWebAppInstallForceList 政策中配置 pinned_version 属性。此功能主要通过 Google 管理控制台中应用详细信息面板下的交互式界面控件进行管理，并遵循标准的 IWA 安装工作流，但管理员也可以灵活地使用原始 JSON 配置直接部署这些政策值。管理员成功定位到有效的版本字符串后，Chrome 会拉取该显式软件包，并阻止所有后续自动向前更新。

特殊行为和限制

恢复更新（取消固定）：如需恢复自动更新，请移除 pinned_version 属性或将其值更改为较新的目标版本。
默认不降级：将 pinned_version 设置为低于当前安装版本的版本不会触发回滚，除非明确启用了 allow_downgrades。
固定目标不可用：如果指定的更新渠道中缺少配置的 pinned_version，或者配置的低于已安装的版本（且已停用降级），Chrome 将保留当前安装的版本，并阻止任何进一步的更新。
全新部署：如果受管设备上尚未安装 IWA，并且无法检索到指定的 pinned_version 或更新清单中缺少该版本，则 IWA 将无法安装。

正在降级版本

如果新部署的更新引入了严重 bug 或漏洞，管理员可能需要将设备回滚到之前的稳定状态。Chrome 支持将已安装的受管理 IWA 降级到较低版本，而以前该平台仅允许向前更新，不支持降级。

只有在满足以下两个政策条件时，才能降级：

pinned_version 设置为有效的旧版本。
allow_downgrades 明确设置为 true。

降级的工作原理

触发机制：回滚会在常规更新检查周期（每 4-6 小时运行一次）内进行处理。
后台运行：Chrome 会使用更新清单中指定的旧版 Web 软件包 (.swbn) 完整重新安装 IWA。

渠道过渡逻辑

使用政策切换应用的目标渠道时，更新引擎会遵循特定行为：

场景 A：切换到具有较早版本的渠道

如果允许降级：如果 pinned_version 与目标渠道上的旧版本匹配，并且 allow_downgrades 为 true，则会发生回滚（并且本地用户数据会被清除）。
如果降级不被允许：不会发生降级。设备将继续使用当前安装的更高版本，并且只有在新选择的渠道上有更新的版本时才会更新。

场景 B：切换到具有相同版本的渠道

无更改：如果新选择的渠道指向的版本号与当前安装的版本号相同，Chrome 将不会对已安装的软件包进行任何修改。
逐字节一致性原则：开发者必须保证不同渠道中相同版本号的应用包含相同的、字节匹配的代码签名。在不同渠道中部署具有相同版本字符串的不同代码库可能会导致应用状态出现异常和不稳定。

管理政策配置

企业版本控制通过集中式 Google 管理控制台平台使用 IsolatedWebAppInstallForceList 政策架构强制执行。这些设置可以直接通过管理控制台中的界面控件进行管理，也可以使用原始 JSON 政策配置进行部署。
以下管理政策配置示例演示了更新渠道、版本固定和降级：

政策值表示

[
  {
    "update_manifest_url": "https://awesome-kitchen-sink.glitch.me/update.json",
    "web_bundle_id": "aiv4bxauvcu3zvbu6r5yynoh4atkzqqaoeof5mwz54b4zfywcrjuoaacai",
    "channel": "beta",
    &quot;pinned_version": "0.7.0",
    "allow_downgrades": true
  }
]

架构参数说明

channel（字符串，可选）：指示 Chrome 仅评估更新清单中分配给此渠道的版本。如果省略，Chrome 会评估“default”渠道。
pinned_version（字符串，可选）：将设备明确锁定到指定的版本字符串。后续自动后台更新会被阻止。
allow_downgrades （布尔值，可选）：启用回滚功能。如果此政策设为 true，并且与有效的旧版 pinned_version 配对，Chrome 将触发降级重新安装。警告：将此参数设置为 true 会阻止所有标准转发更新，即使省略 pinned_version 字段也是如此。

非受管（用户安装的）IWA（从 150 版开始）

对于非受管、用户安装的独立式 Web 应用，版本控制通过手动用户互动进行：

安装包 ──► 用户选择渠道 ──► 自动检查所选渠道

自动更新的清单前提条件

为了让用户安装的 IWA 能够在后台检查并接收自动定期更新，应用的本地 Web 应用清单（即 /.well-known/manifest.webmanifest 处打包在软件包内的元数据）必须包含有效的 update_manifest_url 字段。

如果应用的本地清单文件中省略了此网址，则非代管式更新引擎将永远不会执行后台检查，并且应用将永久冻结在其初始安装版本。

手动选择渠道

在首次安装非受管 IWA 期间，浏览器会检查更新清单，如果开发者配置了多个渠道，浏览器会直接向用户显示可用的渠道选项（例如“稳定版”“Beta 版”）。

密钥生命周期规则

首次安装来源：无论用户在安装时选择哪个渠道，初始安装始终会部署所提供的安装软件包中打包的文件。
后续更新：安装后，未来的更新将仅从所选渠道查询。只有当高于已安装版本的版本发布到该目标渠道时，应用才会更新。
切换渠道：如需在安装后切换到其他更新渠道，用户必须卸载 IWA 并重新安装，然后在安装流程中选择所需渠道。

如何测试托管式部署

对于通过 Chrome 企业版管理控制台管理设备或直接配置政策的管理员：

前往组织设置下的应用详细信息面板。
应用配置属性，以测试固定和渠道目标。由于这些控件与标准用户会话、受管理的访客会话 (MGS) 和自助服务终端完全兼容，因此您可以验证所有目标部署环境中的行为。
如需在本地检查更新检查，请在测试客户端上前往 chrome://web-app-internals，以手动强制执行更新检查并分析传入的清单数据包。

总结

独立式 Web 应用的安全架构旨在为开发者提供支持，同时保持对应用生命周期行为的严格可预测性和控制。通过利用 Chrome 的版本管理功能，开发者和 IT 管理员都可以构建符合严格合规标准和运营目标的强大部署流水线。

在设计和管理应用的更新策略时，请牢记以下核心原则：

使用渐进式渠道：通过更新渠道（例如 beta、dev 或自定义通道），您可以逐步收集遥测数据和反馈。这样可以确保重大更新在默认渠道上向普通用户发布之前，经过严格的验证。
固定版本以确保稳定性：在高度结构化或合规性驱动的企业环境中，将关键端点锁定到经过验证的确切 pinned_version，以保护运营免受意外中断或工作流中断的影响。
将降级作为紧急情况下的备用方案：认识到版本降级是一种强大的纠正性安全阀，在以前是不可能实现的。不过，由于回滚会触发完整重新安装并清除所有本地客户端存储空间（IndexedDB、LocalStorage、Cookie），因此应严格保留用于关键安全修复。对于普通补丁，部署前瞻性次要更新始终是理想的策略。
了解政策标志：请注意管理开关；即使未主动定义固定版本，开启 allow_downgrades 也会停止所有后续更新。
建立逐字节完整性：确保跨不同渠道部署的相同版本号映射到相同的、字节匹配的软件包，以避免客户端在渠道之间转换时出现不稳定的应用状态。

通过将这些功能直接集成到更新清单和企业政策架构中，您可以确保更新流程可靠、可审核且安全，从而维护隔离式 Web 应用生态系统的高信任保证。