解读

国内 Android 设备升级场景分为「系统 OTA」与「应用热更新」两条主线。面试官问“升级失败时如何回滚”，既考察你对 Android 分区布局、启动链、事务原子性的理解，也考察你在业务层能否把“用户可感知”的降级做成零中断、零数据丢失。回答时要先明确回滚粒度：是整包系统版本回退，还是业务 Bundle/插件降级，还是本地数据库/schema 逆向；再给出“检测失败→触发回滚→恢复可用→上报 telemetry”的闭环，并体现国内合规（工信部 24 小时内可回退要求）、商用稳定性（不能变砖）、用户隐私（回退不泄露数据）三大红线。

知识点

1. A/B Seamless Update（A/B 系统）：Google 自 Android 7.0 引入，国内小米、OPPO、vivo 旗舰已强制启用。slot A/B 互为备份，update_engine 以事务方式写 slot B，失败自动标记 BOOT_FAIL，BootControl HAL 在下次启动时切回 slot A，实现“一键回滚”。
2. 非 A/B 方案（recovery + cache 分区）：低端机仍用传统 recovery，升级包写在 /cache，升级前先备份 system、boot、vendor 镜像到 /sdcard/rollback，升级脚本里设置「进度条 85% 未写成功则 reboot-recovery 执行 backup.sh 还原镜像」；需保证 backup 镜像有厂商 RSA 签名，防止回滚包被篡改。
3. 应用层热更新回滚：Tinker、Sophix、QZone 方案均支持“全量合成失败自动清 patch 目录”，但业务仍需在 Application.attachBaseContext 里做 crc/checksum 校验，发现 dex 合成异常则调用 RollbackHelper.revertToOriginalApk()，并清掉 SharedPreference 中标记的新版本号。
4. 数据库/schema 回滚：Room 在 Migration 失败时会抛 IllegalStateException，需自定义 FallbackMigration，把用户数据导出到 /data/data/pkg/backup/，然后重建表再导入；若重建失败，则弹出“兼容模式”弹窗，引导用户本地导出 CSV 后卸载重装。
5. 监控与灰度：升级结果通过 MMAP 无锁日志写到 /data/misc/logcat/ota_result.json，失败码映射到 0x20* 段，回滚后 15 分钟内由 Worker 上传至自建 OTA 平台，触发灰度熔断；国内厂商需对接工信部 OTA 备案系统，回滚率超过 3% 自动停流。
6. 安全与合规：回滚镜像必须走 OTA 签名验证（RSA-4096 + verity hash tree），且版本号不能低于 anti-rollback fuse 所记录的最低版本，否则设备直接拒绝启动；国内还需通过《移动智能终端补充设备标识》审核，确保回滚不会重置 OAID。

答案

以 A/B 系统为例，完整回滚流程如下：

1. 升级前：UpdateEngine 在系统 Server 进程申请 slot B 写权限，同时把当前 slot A 的 metadata（boot.img hash、system.verity、vbmeta.avb）备份到 /metadata/ota/rollback/，并设置 boot_control.setSnapshotMergeStatus(MERGING)。
2. 升级中：update_engine 以块为单位写入 slot B，每 4 KB 计算 SHA-256，写入失败立即标记 MERGE_FAILED，并通过 boot_control.setActiveBootSlot(0) 把下一次启动指向 slot A；同时写 misc 分区命令位 BOOTLOADER_CTRL，让 bootloader 在重启时跳过 slot B。
3. 升级后首次启动：init 进程读取 misc 分区，若状态为 GREEN，则继续正常启动；若读取到 dm-verity 校验失败或 init 第二阶段返回 -1，则触发 rescue party，计数 +1；当连续两次启动失败，bootloader 自动切回 slot A，并擦除 slot B 的 vbmeta，完成“无感回滚”。
4. 应用层兜底：在系统升级脚本最后一步写入 /system/etc/ota_result，应用启动时读取该文件；若发现字段 "success=false"，则弹 Toast“检测到异常，已为您恢复上一版本”，同时调用 Firebase/国内友盟事件回传，方便后台熔断后续灰度。
5. 用户数据保护：回滚只还原 system、vendor、boot 三分区，/data 分区保留，因此数据库高版本 schema 需在升级前写 version=latest 到 /data/backup/schema_version，回滚后若系统版本号低于该值，则触发 Room fallback migration，保证用户聊天记录、钱包余额不丢失。

一句话总结：利用 A/B 双分区的事务原子性，把“写失败→标记→切槽”做成硬件级回滚；再用应用层校验 + 灰度熔断做二次兜底，确保用户零感知、数据零丢失、合规零风险。

拓展思考

1. 折叠屏/车载多场景：车载 IVI 无 A/B 分区，升级失败需靠双系统（Android + QNX）心跳，Android 分区损坏时由 MCU 切换 QNX 并 OTA 回写，面试可提“双系统互相救援”思路。
2. 差分回滚包体积优化：国内 5G 套餐仍限流量，可把回滚包做成反向差分（new→old 的 bsdiff），平均减少 62% 流量；需保证差分包也走 RSA 签名，且与 full OTA 共用同一证书链。
3. 用户主动降级：工信部要求“用户可自主选择版本”，但 anti-rollback fuse 会阻止。可在设置里增加“开发者回滚”开关，解锁 bootloader 后允许 fastboot flash 旧版本，但清空 data 并重置 OAID，兼顾隐私合规。
4. 回滚率 KPI：大厂 OTA 团队把“回滚率 < 0.3%”写进 PBC，面试时可反问“贵司灰度策略是时间窗口还是用户量窗口？回滚率超标如何归因？”体现闭环思维。