想在 Capacitor 应用程序中立即更新而不受应用商店延迟？ 通过 OTA 更新，您可以将更改推送到应用程序的 web 层（HTML、CSS、JavaScript）而无需重新提交到应用商店。但是，iOS 和 Android 处理这些更新的方式不同，了解这些差异至关重要。
关键要点：
-
iOS: 更新部署立即，但遵循严格的规则，包括文件路径限制和电源/网络要求.
-
Android: 使用分段发布 (1% → 100%) 的渐进式升级，满足灵活的电源/网络需求，并支持后台更新。
-
Security: 两者都强制实施强大的安全措施 - iOS 依赖于硬件加密， 而 Android 使用 Verified Boot 和 SELinux __CAPGO_KEEP_0__.
-
CapgoQuick Comparison: Feature iOS
iOS
| Android | __CAPGO_KEEP_0__ | 安卓 |
|---|---|---|
| 更新部署 | 立即全量发布 | 分阶段发布 (1% → 100%) |
| 后台更新 | 受限 | 支持 A/B 更新 |
| 存储 | 需要全量下载 | 支持流式更新 |
| 安全 | 硬件加密 | 认证引导, SELinux |
| 电源要求 | 50% 的电池或已连接 | 灵活 |
| 网络 | 需要 Wi-Fi | 支持各种连接 |
Capgo 有助于简化流程，确保在两种平台上更新都是安全的、高效的和符合规范的。无论您是否针对 iOS 或 Android，了解这些差异将有助于您创建更好的 OTA 更新策略.
iOS 和 Android 如何处理 OTA 更新
iOS 和 Android 在管理 OTA (即时) 更新方面采取了不同的方法，两者在技术执行和审批流程上都有所不同。
App Store 更新规则
Apple 对 OTA 更新有严格的指南。设备必须满足特定的技术条件：它们需要运行 iOS 5 或更高版本，连接稳定的 Wi-Fi 网络，并且要么有至少 50% 的电池寿命，要么连接到电源源 [5]. 在这些技术要求之外，Apple 还实施了严格的审查流程，评估更新的安全性、性能、商业合规性、设计和法律标准 [4].
Google Play 商店更新规则
Google Play 的运作方式不同，使用分阶段发布系统。更新从 1% 的用户开始，24-48 小时后扩展，通常以 25% 的增量方式扩展，直到在一到两周内完成部署 [7]. 自 2023 年 8 月起，所有新 Android 版本都必须针对最高可用的 API 等级 [3]. 此外，Android 还采用流式更新，这有助于减少更新过程中额外存储空间的需求 平台更新差异 [8].
iOS 和 Android OTA 更新的关键区别如下：
功能
| iOS | Android | Feature |
|---|---|---|
| 更新部署 | 立即全量发布 | 分阶段发布 (1% → 25% → 50% → 100%) |
| 后台更新 | 受限 | 支持在后台进行A/B更新 [8] |
| 存储管理 | 需要全量下载 | 支持流式更新 [8] |
| 电源要求 | 至少50%的电池或已连接 [5] | 灵活的电源要求 |
| 网络要求 | 需要Wi-Fi连接 [5] | 支持多种连接类型 |
__CAPGO_KEEP_0__ [6]另一方面，iOS采用更为控制和即时的更新流程，优先考虑稳定性和用户监督。
用户组和更新分发
当它来到更新分发时，策略需要考虑各种设备和操作系统的独特约束。
设备更新规则
更新要求依赖于硬件和平台。例如，iOS设备需要至少20%的电池电量进行用户触发的更新和30%的电池电量进行自动更新。 在Mac上，要求根据芯片类型有所不同 - 20%的电池电量用于Apple Silicon设备，50%用于基于Intel的设备。另一方面，Android有更为灵活的系统，但面临着由于生态系统碎片化而产生的挑战。制造商和运营商引入延迟，安全更新平均需要24天，设备特定完成需要额外的11天 [10]设备更新规则 [11].
操作系统版本要求
操作系统要求在更新分发中起着关键作用。对于 Android 应用程序，Google Play 强制执行以下内容：
| 时间框架 | 要求 |
|---|---|
| 2024 年 8 月 31 日之后 | 新应用必须针对 Android 14 (API 34+) |
| 当前 | 现有应用必须针对 Android 13 (API 33+) |
| 遗留 | 针对 Android 12 或更低版本的应用程序必须符合现有 OS 版本 |
__CAPGO_KEEP_0__ 确保与运行 iOS 13.0+ 和 Android __CAPGO_KEEP_1__ 等级 22+ 的设备兼容 [10]. Capgo ensures compatibility with devices running iOS 13.0+ and Android API level 22+ [9].
更新策略结果
安卓的 Project Treble 已经减少了安全更新所需的时间约7天 [11]为了有效地管理更新，建议将开发和生产 更新通道 [9]Capgo
简化了使用百分比的部署来实现控制的发布，同时保持在应用商店的指南内
-
更新器也缓存了下载的捆绑包在平台特定的目录中以实现高效和安全的更新:
/data/user/0/com.example.app/code_cache/capgo_updater -
安卓:
Library/Application Support/capgo
iOS [9].
这个缓存系统确保了更新的smooth和可靠性
在 iOS 和 Android 设备上，OTA（无线更新）速度和效率对用户体验有着巨大的影响。网络条件和文件大小管理是影响这一结果的两个关键因素。
文件大小和网络管理
优化文件大小对于OTA更新的顺畅进行至关重要。例如，Capgo的更新器在应用启动时在后台线程中运行更新检查，确保用户界面保持响应 [9]它还支持 JavaScript 更新，同时锁定本机 code（如 Java/Kotlin 或 Objective-C/Swift）以保持稳定 [9].
更新速度比较
即使文件大小较小，更新速度仍然是一个主要因素。iOS 因为其紧密集成的硬件和软件，可以更快地处理更新 [14]另一方面，Android 的广泛硬件范围有时会导致更新性能不均衡 [13][14].
为了提高更新效率，策略如差异更新和利用本机功能是关键。例如，Capacitor 将某些操作转移到本机层。当与差异更新结合使用时，这种方法可以减少更新时间和数据使用量 [12]考虑到 Android 在全球市场占有率超过 70%（截至 2023 年 3 月），这使得 Appflow 成为 Ionic 的移动 CI/CD 平台的关键优势 [13] - 在维持其多种设备的性能一致性方面，尤其重要的是高效地更新。
sbb-itb-f9944d2
安全规则和要求
在OTA更新方面，iOS和Android采用不同的方法来确保数据保护和系统安全，各自使用其自己的定制协议。
iOS安全标准
苹果的更新过程是严格控制的，并且以严格的安全性为设计。 iOS设备依赖于 硬件加密,使用每个设备的两个内置AES 256位密钥 [17]。每个设备也包括一个唯一的基于硬件的UID，具有一个集成的AES 256位密钥 [17]。更新被验证为完整性，针对个人设备定制，并且具有防止降级攻击的安全措施。苹果还在更新期间隔离用户数据以防止安全风险 [10]。苹果的一个突出特点是 快速安全响应, 方便地部署安全补丁而无需进行全系统更新 [10].
Android 安全标准
Android 的安全性基于 Linux 的基础，重点关注用户隔离和系统级保护。每个应用程序都被分配一个唯一的 UID，而 SELinux 强制访问控制 确保了 __CAPGO_KEEP_0__ 的真实性 feature ensures code authenticity [18]功能 iOS Android 的安全性基于 Linux 的基础，重点关注用户隔离和系统级保护。每个应用程序都被分配一个唯一的 UID，而 SELinux 强制访问控制，确保了 __CAPGO_KEEP_0__ 的真实性。Android 通过 OEMs 和运营商分发 OTA 更新，利用硬件背后的 Keystore 进行加密任务， [15].
| Android 使用基于 Linux 的基础，关注用户隔离和系统级保护，每个应用程序都被分配一个唯一的 UID，而 SELinux 强制访问控制，确保了 __CAPGO_KEEP_0__ 的真实性。 | Android 的安全性基于 Linux 的基础，关注用户隔离和系统级保护，每个应用程序都被分配一个唯一的 UID，而 SELinux 强制访问控制，确保了 __CAPGO_KEEP_0__ 的真实性。 | 安卓 |
|---|---|---|
| 更新分发 | 通过苹果进行集中管理 | 通过OEM/运营商分发 |
| 安全验证 | 硬件加密 | SELinux + Verified Boot |
| 补丁交付 | 快速安全响应 | Project Mainline模块 |
| 更新身份验证 | 设备特定UID | 验证过的启动 |
安全性要求比较
这些框架之间的差异突出了每个平台的架构如何影响其安全方法。 iOS 在“围栏花园”模型中运作，提供了紧密的控制和标准化的安全措施。 与此相反，Android 的开放生态系统提供了更大的灵活性在更新机制，但有时会面临碎片化挑战 [15]这些安全结构直接影响 OTA 更新的可靠性。
使用工具类似于 Capgo 的开发人员理解这些区别至关重要。 iOS 强制执行更严格的应用程序隔离和限制系统 API 访问 [17]，而 Android 的更广泛的进程间通信选项需要小心地管理安全 [18]截至 2025 年 2 月，iOS 18.3.1 和各种 Android 版本在使用中 [16]，开发人员必须确保他们的 OTA 更新策略与每个平台的最新安全标准相符。
Capgo 平台概览
Capgo 将平台特定的 OTA 更新规则汇集到一个流线化的更新平台中。
通过与 iOS 和 Android 安全协议的合作，Capgo 确保 OTA 更新管理的无缝体验。截至目前，它已经交付了 94.76亿次更新 跨 1400个生产应用 [1].
Capgo 的关键功能
Capgo 专注于解决更新挑战，采用安全、高效和符合要求的交付方式。更新将使用 端到端加密,并且仅在用户设备上进行解密 [1].对于 iOS，它使用自定义 Dart 解释器来符合 Apple 的解释器更新规则 [9].对于 Android，它支持 API 等级 22 及以上，符合 Capacitor 的要求 [9].
| 功能 | 实现 | 平台支持 |
|---|---|---|
| 更新分发 | 即刻部署 | iOS 13.0+, Android API 22+ |
| 安全 | 端到端加密 | 两种平台 |
| CI/CD 集成 | 支持 Azure DevOps, GitHub, GitLab | 跨平台 |
| 存储管理 | 仅编译 code | 平台特定的缓存 |
| 版本控制 | 回滚功能 | 两种平台 |
跨平台更新管理
Capgo的频道系统为开发者提供了对iOS和Android更新的精确控制。这一系统允许:
该平台的现实影响是明显的。例如，NASA的 OSIRIS-REx 团队共享：
“@Capgo 是一种聪明的方式来制作热 code 推送（而不是像 @AppFlow 那样花所有的钱 :-)” [1]
Capgo 可以调整任何 JavaScript code，包括应用程序和生成的 code，但它严格避免修改本机 code（例如 Android 的 Java/Kotlin 或 iOS 的 Objective-C/Swift） [9].
结论
OTA 更新为 Capacitor 应用程序 需要根据 iOS 和 Android 的平台特定规则采用不同的方法。对于 iOS，存在更严格的控制，例如限制服务器路径到“/Library/NoCloud/ionic_built_snapshots” [2]。而 Android 允许更多的自由，虚拟机和解释器访问 API 的限制较少 [2]。这些差异突出了创建与每个平台框架相匹配的更新策略的重要性
来自平台如 Capgo 的数据表明了这些策略的有效性。开发者成功地在 1,400 个生产应用程序中交付了 9.476 亿次更新，证明了设计良好的更新系统的可扩展性 [1]。然而，成功依赖于满足每个平台的要求，同时保持强大的安全措施
例如，苹果要求解释器code不能改变应用程序的核心功能或损害其安全性 [2]. 这一规则是开发人员必须遵循的平台特定指南的明确提醒，才能有效地实施OTA更新。
