一、全量包概念解析

做系统开发这么多年，我经常被问到：「全量包到底是什么？跟增量包有啥区别？」

嗯，这个问题确实很基础，但也是很多新人容易混淆的地方。今天咱们就把它彻底讲清楚。

1.1 什么是全量包

全量包，说白了就是一个完整的、自包含的软件包。它包含了某个软件或系统版本的所有文件和数据。

你拿到一个全量包，不需要依赖任何其他东西，就能完成安装或升级。就像你买一台新手机，里面所有配件都齐了，开机就能用。

举个例子，Android 系统的全量包通常是一个 ZIP 文件，里面包含了 boot.img、system.img、vendor.img 等所有分区镜像。你刷这个包，手机就变成了一个完整的系统。

1.2 全量包 vs 增量包

很多初学者搞不清这两个概念。我刚开始做系统升级时也踩过坑——有一次把增量包当全量包用，结果刷完系统直接变砖。嗯，从那以后我再也不敢混淆了。

咱们直接看对比表，一目了然：

对比维度	全量包	增量包
包含内容	目标版本的全部文件	仅包含新旧版本的差异部分
包体大小	较大（通常几百 MB 到几 GB）	较小（通常几十 MB 到几百 MB）
安装依赖	无依赖，独立安装	必须基于特定旧版本
升级速度	较慢（需写入全部数据）	较快（只写入差异数据）
失败风险	低（完整写入，可回滚）	较高（依赖旧版本完整性）
适用场景	首次安装、大版本升级、恢复模式	小版本迭代、OTA 增量更新

你想想看，为什么增量包更小却风险更高？因为增量包只记录「从 A 版本到 B 版本的变化」。如果用户手机上的 A 版本已经被修改过（比如 root 过），增量包应用时就会出错。

1.3 全量包的应用场景

全量包的应用场景其实比你想的要多。我把它分成两大类来说：

1.3.1 系统升级

这是全量包最经典的应用场景。具体包括：

• 首次刷机：新手机出厂时，工厂会刷入全量包。我记得第一次参与产线刷机项目时，看到流水线上每台手机都在刷同一个全量包，那种场面还挺震撼的。
• 大版本升级：比如 Android 12 升到 Android 13，改动太大，增量包几乎不可能做，直接用全量包最稳妥。
• 恢复模式：手机变砖了怎么办？进 recovery 模式刷全量包。因为这时候系统已经不完整了，增量包根本用不了。
• 跨版本升级：用户从 Android 10 直接跳到 Android 13，中间跳过了两个大版本。增量包需要逐个版本升级，全量包一步到位。

1.3.2 应用分发

你可能觉得应用分发用增量包就够了，其实不然：

• 首次安装：用户第一次下载 App，必须用全量包。增量包？旧版本都没有，怎么增量？
• 大版本更新：App 架构大改、资源文件重组时，增量包反而更复杂，直接上全量包更省事。
• 渠道包分发：不同渠道（华为、小米、应用宝）的定制版本，每个渠道都是一个独立的全量包。
• 企业内部分发：企业内部 App 更新，为了确保一致性，很多团队直接发全量包。

1.4 全量包的核心流程

理解了概念，咱们来看看全量包从制作到应用的完整流程。我画了一张图，帮你建立整体认知：

这个流程看起来简单，但每个环节都有不少坑。比如签名生成时密钥管理不当，或者完整性校验时算法选择错误，都可能导致升级失败。

1.5 全量包的文件结构

最后，咱们看看一个典型的 Android 全量包长什么样。以我常用的 AOSP 全量包为例：

ota_update.zip
├── META-INF/
│   ├── MANIFEST.MF          # 文件清单和哈希值
│   ├── CERT.SF              # 签名文件
│   └── CERT.RSA             # 签名证书
├── boot.img                 # 内核镜像
├── system.img               # 系统分区
├── vendor.img               # 厂商分区
├── product.img              # 产品分区
├── system_other.img         # 系统其他分区
├── payload.bin              # 增量升级负载（全量包也有）
└── payload_properties.txt   # 升级属性配置

嗯，这里要注意：META-INF 目录下的三个文件是签名校验的核心。MANIFEST.MF 记录了每个文件的哈希值，CERT.SF 是对 MANIFEST.MF 的签名，CERT.RSA 包含了签名证书。后续章节我们会深入讲解这个签名链。