第一部分:核心概念与工作流程
在开始搭建之前,必须理解 Android OTA 的基本工作流程。

-
设备端:
- 检查更新: 设备上的
SystemUpdateService会定期或手动向服务器请求检查更新。 - 获取元数据: 服务器返回一个 XML 文件(通常是
ota_metadata或自定义的update.xml),其中包含更新包的信息(版本号、下载链接、MD5/SHA256校验和、强制更新标志等)。 - 下载更新: 设备根据元数据中的链接,下载 OTA 包(通常是
.zip文件)。 - 校验与安装: 下载完成后,设备会使用校验和验证包的完整性,验证通过后,设备会进入 Recovery 模式,由
recovery脚本解压并刷入更新包。
- 检查更新: 设备上的
-
服务器端:
- 提供元数据: 一个动态生成的 XML 文件,告诉设备“有什么更新”。
- 托管更新包: 一个静态的文件服务器,用于提供 OTA 包的下载。
- (可选)提供差分包: 提供基于旧版本到新版本的增量更新包,以节省流量和时间。
第二部分:搭建方案(从简到繁)
根据你的需求(个人测试、团队共享、商业发布),可以选择不同的方案。
最简单的静态文件服务器(适用于个人/测试)
这是最基础的方式,只需要一个 Web 服务器来托管文件。

工具: 任何 Web 服务器,如 Python 的 http.server、Nginx、Apache。
步骤:
-
准备文件:
- 创建一个目录,
ota_server。 - 将你的 OTA 更新包(
my_update.zip)放入该目录。 - 创建一个简单的
update.xml文件,这是关键!
- 创建一个目录,
-
编写
update.xml: 这个 XML 文件是设备获取更新信息的唯一来源。
(图片来源网络,侵删)
<?xml version="1.0" encoding="UTF-8"?>
<update>
<url>https://your-server.com/my_update.zip</url> <!-- OTA包的完整下载URL -->
<version>2.0</version> <!-- 新版本号 -->
<name>My Awesome Update</name> <!-- 更新名称 -->
<size>123456789</size> <!-- OTA包的大小(字节) -->
<md5>your_md5_hash_here</md5> <!-- OTA包的MD5校验和 -->
<!-- <sha256>your_sha256_hash_here</sha256> <!-- 更推荐使用SHA256 -->
<datetime>202510271200</datetime> <!-- 更新时间,格式:YYYYMMDDHHMM -->
<log>Fixed a critical bug and improved battery life.</log> <!-- 更新日志 -->
<!-- <fota>true</fota> <!-- 如果是差分包,可以加上这个标签 -->
</update>
如何获取 md5/sha256 和 size?
在 Linux/macOS 终端中:
# 获取MD5 md5sum my_update.zip # 获取SHA256 sha256sum my_update.zip # 获取文件大小(字节) ls -l my_update.zip
-
启动 Web 服务器:
-
使用 Python (推荐用于快速测试):
# 在 ota_server 目录下运行 python3 -m http.server 8080
你的服务器就在
http://<你的IP地址>:8080/运行了。 -
使用 Nginx (更稳定,适合长期使用):
server { listen 80; server_name your-server.com; location / { root /path/to/your/ota_server; autoindex on; # 允许列出目录内容 } }
-
缺点:
- 无法控制对不同设备的推送。
- 每次更新都需要手动修改
update.xml并重新上传所有文件。 - 无法处理差分包。
使用开源项目(强烈推荐,适用于团队/小型企业)
有很多优秀的开源项目帮你封装了复杂的逻辑,让你只需专注于构建 OTA 包。
推荐项目:
- OTAUpdater (by chiteroman): 一个功能强大且简单易用的 Java Web 应用,它支持多设备、多版本、强制更新、差分包等。
- LineageOS OTA Web Service: LineageOS 官方使用的工具,非常成熟和稳定,但配置相对复杂一些。
- COTA (Community OTA): 另一个流行的选择,基于 PHP。
这里以 OTAUpdater 为例,搭建一个功能完善的 OTA 服务器。
环境要求: Java 17+、Maven、Tomcat 9+ 或其他 Servlet 容器。
步骤:
-
获取源码并构建:
git clone https://github.com/chiteroman/OTAUpdater.git cd OTAUpdater # 编译项目 mvn clean package
构建成功后,你会在
target/目录下得到一个.war文件(ota-updater-1.0.war)。 -
准备数据库: OTAUpdater需要一个数据库来存储设备信息和更新元数据,推荐使用 MariaDB/MySQL。
- 创建数据库和用户:
CREATE DATABASE ota_db; CREATE USER 'ota_user'@'localhost' IDENTIFIED BY 'your_strong_password'; GRANT ALL PRIVILEGES ON ota_db.* TO 'ota_user'@'localhost'; FLUSH PRIVILEGES;
- 创建数据库和用户:
-
配置 Web 容器 (以 Tomcat 为例):
- 将生成的
.war文件放入 Tomcat 的webapps目录下(webapps/ota-updater.war)。 - 启动 Tomcat。
- 访问
http://<你的IP地址>:8080/ota-updater,你会看到一个设置向导。 - 按照向导提示,输入数据库连接信息(URL, 用户名, 密码, 数据库名)。
- 完成配置后,向导会创建必要的数据库表并跳转到登录界面,默认管理员用户名是
admin,密码在webapps/ota-updater/WEB-INF/classes/config.properties文件中查找adminPassword。
- 将生成的
-
配置设备: 在你的设备的
device.mk或BoardConfig.mk中,修改AB_OTA_UPDATER和OTA_URL等变量,使其指向你的 OTA 服务器地址。# In device.mk AB_OTA_UPDATER := true # OTA 服务器的URL,不需要末尾的斜杠 OTA_URL := "http://your-server.com:8080/ota-updater"
-
发布更新:
- 登录 OTAUpdater 的 Web 界面。
- 进入 "Updates" 或 "发布" 页面。
- 填写更新信息(版本号、名称、日志等)。
- 上传你的完整 OTA 包(
full_*.zip)。 - (可选)上传差分包(
incremental_*.zip),并指定它是从哪个旧版本升级的。 - 保存发布。
优点:
- 功能齐全: 支持多设备、多版本、强制更新、差分包、设备注册等。
- Web 界面管理: 无需手动编辑文件,通过网页即可管理所有更新。
- 自动化: 设备会自动注册,并定期检查更新。
云服务提供商的 OTA 解决方案(适用于商业发布)
对于大规模的商业发布,使用云服务是最佳选择,它们提供了高可用性、全球加速、安全性和数据分析。
代表服务:
- Google Play In-App Updates: 如果你的应用发布在 Google Play,这是最简单、最官方的 OTA 方式,它通过 Google Play 服务推送应用更新,而不是系统更新。
- Firebase App Distribution: 主要用于应用内测分发,可以生成链接给测试人员安装 APK,但不直接用于系统级 OTA。
- AWS Device Farm / Google Cloud IoT Core: 这些是更底层的平台,可以让你构建自己的 OTA 流水线,包括安全签名、版本控制和灰度发布。
- 第三方商业 OTA 平台: 如 airVantage (已并入 ThingsOnCloud)、JUICE 等,它们提供开箱即用的、功能强大的企业级 OTA 解决方案。
优点:
- 高可用性与可扩展性: 云服务保证服务不中断,并能应对大量设备同时请求。
- 全球加速: CDN 加速,确保全球各地的设备都能快速下载更新包。
- 安全性: 提供安全的签名、传输和存储机制。
- 数据分析与监控: 提供详细的更新成功率、设备状态等报表。
第三部分:生产环境最佳实践
无论你选择哪种方案,在生产环境中都需要考虑以下几点:
-
安全性:
- HTTPS: 必须 使用 HTTPS 协议,防止中间人攻击和篡改更新包,可以通过 Let's Encrypt 免费获取 SSL 证书。
- 签名校验: 设备在下载和刷入更新包前,必须使用公钥验证其数字签名,这是防止恶意软件被刷入系统的最后一道防线。
- 访问控制: 对 OTA 服务器接口进行身份验证,防止未授权的设备或用户获取更新信息。
-
可靠性与性能:
- 使用 CDN: 将 OTA 包托管在对象存储(如 AWS S3, Google Cloud Storage)上,并通过 CDN(如 Cloudflare, AWS CloudFront)分发,这能极大提高下载速度,并减轻源站压力。
- 断点续传: 实现断点续传功能,防止下载中断后需要重新下载整个大文件。
- 负载均衡: 如果流量很大,使用负载均衡器分发请求。
-
更新策略:
- 灰度发布: 不要一次性向所有设备推送更新,先向 1% 的设备推送,观察一段时间,确认没有问题后,再逐步扩大到 10%, 50%, 100%,这能有效降低因更新引入的 Bug 的影响范围。
- 强制更新 vs. 可选更新: 对于修复严重安全漏洞的更新,应设为强制更新,对于功能更新,则设为可选更新。
-
监控与回滚:
- 监控: 监控 OTA 服务器的状态、下载成功率、设备上报的更新状态等。
- 回滚机制: 如果发现某个更新版本存在严重问题,需要有机制可以快速将受影响的设备回滚到上一个稳定版本,这通常需要 A/B 分区支持。
| 方案 | 优点 | 缺点 | 适用场景 |
|---|---|---|---|
| 静态文件服务器 | 简单、快速、零成本 | 功能单一、手动维护、不安全 | 个人学习、临时测试 |
| 开源项目 (OTAUpdater) | 功能完善、Web界面管理、支持差分包 | 需要自建服务器和数据库 | 团队开发、小型项目、社区ROM |
| 云服务/商业平台 | 高可用、高安全、全球加速、功能强大 | 成本高、配置复杂 | 商业产品、大规模设备部署 |
对于大多数开发者和中小型团队来说,使用像 OTAUpdater 这样的开源项目是性价比最高、最实用的选择,它能以最小的成本,为你提供接近商业平台的核心功能,如果你的项目规模已经很大,或者对稳定性和安全性有极致要求,那么迁移到云服务提供商的解决方案是必然的选择。
