频繁的操作系统更新对于确保安全性和使用最新功能至关重要。默认情况下，ChromeOS 大约每 4 周会发布一次完整的操作系统更新到稳定渠道（稳定版）。每 2 到 3 周会有一次小幅更新，例如安全修复和软件更新。开发者可以在每个新的稳定版发布之前，在开发者版 (Dev) 或 Beta 版渠道中测试其应用，以确保应用正常运行。开发版每周更新一到两次，可显示 Chrome 团队目前正在开发的功能。此 build 仍可能存在 bug，但可让用户提前 9-12 周预览稳定版即将推出的功能。Beta 版可让用户提前 4-6 周体验即将在稳定版中推出的功能。
不过，对于系统管理员和开发者来说，每月使用这些现有渠道进行测试可能难以跟上。为了提供更好的支持并让每个人有更多时间进行测试，我们为 ChromeOS 制定了新的长期支持计划，其中包含长期支持渠道。
长期支持版本
ChromeOS 的长期支持版本是一项强大的工具，可减少组织中管理设备的工作量，并确保应用在每次操作系统更新后都能正常运行。管理员和开发者都应熟悉这些 API，以便为采用这些 API 的组织提供出色的体验。
ChromeOS 提供两个长期支持版本：长期支持候选版本 (LTC) 和长期稳定版本 (LTS)。
- 长期支持候选渠道 (LTC) - 用作下一个 LTS 版本的依据，在 LTS 发布前三个月从稳定渠道中分离出来，以便管理员进行预览和准备。
- 长期支持渠道 (LTS) - 每 6 个月更新一次，此渠道发布更新的频率最低，旨在取代常规稳定渠道。除了少数应保留在 LTC 渠道以进行测试的用户之外，在组织内采用长期支持版本时，大多数用户应使用 LTS 渠道。
稳定版、LTC 版和 LTS 版的发布时间表
LTC / LTS 生命周期的工作原理如下：
- LTC 版本（图中的 108 LTC）是从稳定版（108 稳定版）中剪切出来的，因此在第一个月，这两个版本是相同的。
- LTC 开始每两周接收一次安全修复程序，为期 3 个月，直到下一个 LTS 版本（图中的 108 LTS）发布。这意味着，在初始 LTC 版本发布 3 个月后，LTC 将与 LTS 保持一致。
- LTS 发布后，将继续每两周接收一次安全修复。
- 在 LTS 发布后仍采用 LTC 的设备也会继续每两周接收一次安全修复程序，并且会在下一个 LTC 版本发布时自动更新到该版本。
除了操作系统功能和 bug 修复之外，LTS 版本中还捆绑了固件更新，直到设备的自动更新到期日期 (AUE)。
如需启用任一渠道，您必须拥有 Google 网域和受管理的设备。您可以注册 Chrome 企业版升级服务试用，以便有权访问 Google 管理控制台，从而设置和部署受管理的 Chromebook。最后，在管理控制台中将受管理的设备切换到 LTS 或 LTC 渠道。我们建议让大多数设备采用 LTS 渠道，并使用 LTC 测试即将发布的 LTS 版本。
LTC / LTS 的测试工作流
LTC 和 LTS 旨在大幅减少管理员的测试工作量，同时确保安全的操作系统体验。为了让系统管理员和开发者与长期支持生命周期保持一致，您应：
- 在与即将发布的 LTC 渠道版本相匹配的稳定版发布之前，先在开发者版和 Beta 版上进行测试。
- LTC 发布后，请对其进行测试，以确保在 LTS 分支创建之前，所有应用的安全修复不会影响您的工作。
- LTC 升级为 LTS 后，LTS 将继续每两周接收一次安全修复。您也应该测试这些广告。
以生命周期图为参考：
- 从 108 稳定版开始测试，确保一切正常运行，因为 108 LTC 将从 108 稳定版中分离出来。
- 每两周在 108 LTC 上进行测试，直到 108 LTS 在初始剪辑日期后的三个月发布。
- 继续定期在 LTS 上进行测试，以确保安全修复不会破坏任何内容。
管理 LTC/LTS 版本之间的更改
无论是采用 ChromeOS 的长期支持版本，还是与采用该版本的组织合作，妥善管理版本之间的变更都至关重要。您可以添加基于新平台的功能，也可以依赖于在后续版本中已弃用的功能。或者，您可能依赖于特定应用版本的特定功能，或者希望让用户能够选择运行哪个版本。为确保应用访问的顺畅性，您应努力确保应用向后兼容，为每个版本提供单独的实例，或者同时采取这两种措施。
确保向后兼容性
向后兼容性可让新版应用在旧版平台上运行。您可以使用一种称为“功能检测”的技术来实现此目的，即在尝试使用新功能之前先检查其可用性。如果存在，则使用该值；如果不存在，则可以选择性地提供回退值。此技术的广义版本称为功能标志，其中会根据功能是否已启用（通过功能可用性或应用/用户级配置）来加载代码路径。Android 应用、Chrome 扩展程序和 Web 应用均可受益于此技术。通过确保应用的新版本具有向后兼容性，您可以为所有用户管理单个应用。
如果 Web 应用希望提供计算密集型动画，则可以针对支持 WebGPU 的浏览器实现 WebGPU，并在不支持 WebGPU 时回退到更简单的 JavaScript 驱动的动画。为此，他们可能会执行以下操作：
if ('gpu' in navigator) { // WebGPU is supported! Accelerate computation. } else { // No WebGPU, fallback to JavaScript implementation. }
提供单独的实例
有时，版本之间的差异过大，无法通过向后兼容性技术来处理。功能差异可能过大，或者您可能出于业务需求而需要使用与主应用不同的长期支持版本。在这种情况下，您可能需要考虑为每个版本提供单独的实例。虽然这可确保用户使用的是特定版本的应用，但可能会增加您的运营费用，因此在选择此解决方案时请注意这一点。
对于 Web 应用，提供单独的实例通常意味着在不同的网址托管应用的不同版本，这可能需要单独的服务器、数据库或其他网站基础架构。对于 Android 应用，这意味着每个版本都有单独的 Play 商店商品详情。这可能会让用户感到困惑，因为会有多个类似的应用可供选择，而他们可能不知道该选择哪个。Chrome 扩展程序也可以有多个商品详情，或者您可以建议客户通过 Chrome 管理控制台固定他们需要的 Chrome 扩展程序版本，具体方法请参阅这篇文档，其中详细介绍了如何固定扩展程序以及与固定相关的一些注意事项。
如果 Android 应用只想向 ChromeOS 用户提供长期支持版本，则可以创建一个单独的商品详情，并在其 AndroidManifest.xml 文件中添加以下内容，以指定该应用只能交付给 ChromeOS 设备：
<uses-feature android:name="org.chromium.arc" android:required="true" />