安卓Recovery无人值守自动擦除：AOSP源码与BCB命令实战

1. 项目缘起：这需求到底要解决什么问题

这段时间手头一直在做安卓设备的定制化改造，客户提了个很实际的需求：设备从产线下来，或者从租户手里收回来之后，需要保证里面的历史数据被彻底清掉。以前靠人手动进Recovery模式，音量键上下选到wipe data/factory reset，再按电源键确认，一天几十台机器弄下来眼睛都花了，还容易误触。客户问得很直接：能不能让设备一进Recovery模式就把数据擦了，UI界面都不出现，擦完自动重启？

这个需求的本质，是给安卓设备的Recovery模式去掉UI交互层，把它变成一个"无人值守"的自动擦除工具。听上去像某个冷门工程需求，其实在产线批量初始化、设备租赁回收、演示机清理、企业资产处置这些场景里非常常见。甚至很多做二手设备批发的朋友，也会在底层搞这么一套，省得一台一台手动恢复出厂。这篇文章我就把从原理到动手实现的全过程写清楚，包括AOSP源码级改法、不改镜像的BCB命令触发法，以及一种更暴力的init脚本法，适合不同权限条件下、不同开发阶段的同学参考。

1.1 需求拆解："去掉UI"这件事有三层含义

先说清楚，很多人一听"去掉UI界面"就觉得是让屏幕不显示东西。实际上在Recovery定制这个领域，"去掉UI"至少有三个层次。

第一层，隐藏UI，但从代码流程上UI仍会被初始化，只是不展示或者一闪而过。这种改法最简单，适合想保留Recovery完整功能、只是临时不让人看到的场景。

第二层，跳过UI初始化，让Recovery主程序在启动后直接进入数据擦除流程，然后自动重启。这种改法改动集中在recovery主程序，也就是bootable/recovery/recovery.cpp，是我个人最推荐、也是下文要重点讲透的方案。

第三层，从构建层面直接砍掉UI模块，让Recovery镜像里根本不含界面相关代码。这种最彻底，但改造成本高，还要处理一堆编译依赖，一般量产机上轻易不动。

我这次实际做的是第二层。原因很简单：它改动范围可控，出问题容易回退，而且对后续扩展——比如擦完自动进系统、或者擦完自动关机——非常友好。下文我会把这条路的每个细节都摊开讲。

1.2 在动手之前，先想清楚三个问题

再往下讲之前，有三件事必须想明白，否则后面做完了才发现方向错了，会很被动。

第一，这个Recovery是给谁用的。如果只是给自己开发调试用，随便改，怎么快怎么来。但如果要交给产线工人、甚至交给终端用户去操作，那就要想清楚"擦除完成后设备应该停在什么状态"——是自动重启进系统，还是停在Recovery里提示一下，又或者直接关机。不同状态对应不同的代码分支，别一股脑写死。

第二，设备能不能刷。做Recovery定制，无论是替换recovery分区还是改bootloader传递参数，前提都是设备允许刷写。商用设备如果Bootloader锁着，那只能走系统层授权方案，比如通过系统升级包刷入，这一条牵扯到设备准入策略，提前确认能少走很多弯路。

第三，擦除之后需不需要保留Recovery本身的功能。有些场景要求Recovery只做"擦数据"这一件事，擦完就没用了；有些场景则要求Recovery平时还能手动进、能刷升级包，只是在特定触发条件下才自动擦除。这两种需求在代码层面的写法差异很大，前者可以直接把UI流程删掉，后者则是保留UI但加一个自动分支。

我现在讲的这套，是"Recovery开机后无条件执行擦除并重启"，也就是最符合标题描述的形态。如果你需要的是"条件触发"，在这个基础上加一个判断即可，原理完全一样。

2. 先把底层链路打通：Recovery模式到底是怎么启动的

说到改Recovery，首先得把它的启动链路搞明白。很多教程上来就让人改recovery.cpp，但改完编译烧录，发现设备根本进不了修改后的Recovery，或者进了之后卡在logo。这种问题十有八九是没搞懂启动链路导致的。

2.1 从按下电源键到Recovery界面：一条完整的启动链

安卓设备正常开机时，流程大概是这样的：BootROM（固化在SoC里的小程序）→ Bootloader → Linux内核 → init进程 → Android系统。进Recovery模式和这个流程基本一样，唯一的区别是Bootloader在启动内核之前，会先去读一个小分区——misc分区，看看里面有没有"启动到Recovery"的指令，如果有，就把Recovery镜像所在分区加载起来。

具体到Recovery镜像，它通常是recovery分区里的一个完整启动镜像，包含内核和ramdisk。ramdisk被内核解压后，init进程会读取里面的init.rc和init.recovery.rc，把基础环境搭起来——挂载驱动、设置属性、启动recovery服务——接着才轮到真正的Recovery主程序，也就是我们说的recovery进程开始干活。

这个过程里，misc分区扮演的角色非常关键。你可以把它理解成贴在设备门口的一张纸条，Bootloader出门前看一眼纸条："今天要去Recovery值班。"然后就把Recovery叫起来了。这张纸条上能写的内容不止是"去Recovery"，还可以附带参数，比如"去Recovery并擦除数据"。

misc分区里放的是一个固定结构体，叫bootloader_message，在AOSP源码的bootable/recovery/bootloader_message.cpp里有完整定义。结构体里几个关键字段，我整理了个表：

这个结构体看着简单，但所有的"无人值守"玩法——不管官方OTA升级还是我们这次要做的一键擦除——本质上都是在往这张纸条上写字。

2.2 Recovery主程序的main()：UI和命令行在这里分叉

Recovery进程启动之后，会先做一些初始化工作，比如挂载必要的分区、读取当前分区状态，然后去解析bootloader_message里recovery字段带过来的参数。AOSP里这套逻辑全在bootable/recovery/recovery.cpp的main()函数里。

我用大白话给你翻译一下main()的工作流程：

第一，读取参数。如果是从misc分区来的，参数里可能是"--wipe_data"、"--update_package=..."这类东西；如果是从adb命令进来的，参数就是adb sideload传的那套。总之，main()先拿到一摞命令纸条。

第二，初始化UI。也就是把屏幕点亮、把Recovery的图形界面画出来。注意，这一步跟后面执行什么操作是并列的，不是先后的关系。之所以先初始化UI，是为了后面无论执行什么操作，都能往屏幕上打印进度。

第三，检查有没有命令。如果命令纸条是空的——也就是没人告诉它要干嘛——那Recovery就进入交互界面，等着你按音量键和电源键操作。如果纸条上写了命令，那就走命令行模式：执行命令、显示进度、完成之后根据命令决定重启还是继续。

这段话是整个项目的核心。UI和命令执行是两条分支，UI只负责"给人看"，命令执行才是"干活的"。我们想去掉UI，思路立刻就清晰了：要么让Recovery在初始化UI之前把活干完并重启，要么把UI初始化这步直接跳过，反正活已经干完了。

2.3 数据擦除这件事，系统到底在做什么

搞清楚UI分叉之后，还得知道"擦除数据"具体干了什么，否则容易搞出"数据没擦干净"的翻车事故。

在AOSP原生Recovery里，wipe data/factory reset会执行WipeData()，它的核心工作是：

• 格式化/data分区。这是用户数据、应用数据、系统设置、账户信息存放的地方，普通的"恢复出厂设置"就是把它整个抹掉。
• 清除/cache分区。缓存分区里存着系统更新的临时文件和各种应用缓存，一般擦除操作会顺手清掉。
• 重置加密状态。如果设备启用了文件级加密（FBE）或全盘加密，WipeData还需要把加密相关的key和目录结构重新初始化，否则重启后系统会因为找不到解密密钥而卡住。
• 重置一些系统标志位，比如告诉系统"这次开机属于恢复出厂后的首次开机"，以便触发欢迎引导流程。

所以别看"擦数据"三个字简单，背后涉及分区格式化、文件系统重建、加密元数据重置，任何一步出错，轻则开机卡在启动动画，重则直接变砖。这也是为什么我坚持用Recovery自带的流程来擦，而不是自己写脚本去格式化分区——官方流程考虑得比我周全。

3. 核心实操一：改AOSP源码，打造无UI自动擦除的Recovery

好，原理讲完了，下面开始动手。我以AOSP的bootable/recovery为主线，Android 9/10的代码结构为参考来讲。如果你用的版本更老或者更新，文件名和函数名可能稍有出入，但思路是通用的。

3.1 环境准备：源码、lunch配置、编译工具链

改源码之前，先把编译环境弄好。我这边用的是Ubuntu 18.04，主源码是Android 9，因为这台设备的BSP是基于这个版本定的，省得自己适配内核和vendor。

准备工作分三步：

第一步，同步AOSP源码。注意，不要只同步bootable/recovery这一个目录，因为编译Recovery镜像时依赖很多其他模块，比如system/core、external/、frameworks/base的一部分头文件。老老实实把整个源码树同步下来最省心。同步时，建议用repo工具配合--depth=1控制历史记录体积，否则搞不好要下几百GB的数据。

第二步，lunch设备。这一步很关键。AOSP里Recovery镜像并不单独按arm64或x86架构编译，它要服从整个系统的Makefile和产品配置。执行：

source build/envsetup.sh lunch <你的设备代号>-userdebug

userdebug版带root权限，调试Recovery模式时方便很多。没有现成设备的兄弟，也可以用模拟器支持的配置先跑通编译流程，比如lunch aosp_arm64-userdebug，逻辑是一样的。

第三步，确认工具链。Android 9的AOSP编译需要OpenJDK 8，Ubuntu 18.04自带的可能是OpenJDK 11，需要额外装一下并在build/envsetup.sh里指定。很多新人在这里就卡住了，报错提示一堆版本不支持，其实换一下JDK路径就行。

3.2 手术刀：修改recovery.cpp的主流程

准备工作就绪，接下来是主角——bootable/recovery/recovery.cpp。

打开这个文件，定位到main()函数。我用简化伪代码说明改动思路，方便你理解位置：

int main(int argc, char** argv) { // ... 各种初始化，挂载分区、读取参数等等 ... // 原代码：初始化UI // std::unique_ptr<RecoveryUI> ui = ...; // device->StartRecoveryUI(); // 原代码：根据是否有命令行参数决定进UI还是执行命令 // if (args.empty()) { // // 进入交互式UI // } else { // // 执行命令 // } // ===== 修改点：直接执行擦除并重启 ===== LOG(INFO) << "[AutoWipe] Forcing wipe_data without UI..."; if (WipeData() == true) { LOG(INFO) << "[AutoWipe] wipe_data done, rebooting..."; // 擦除成功后直接重启 Reboot("reboot"); // 如果 reboot 成功，这里不会返回 } else { LOG(ERROR) << "[AutoWipe] wipe_data failed!"; } // 兜底：万一上边没走通，退回到正常流程 // ... }

简单说，我把UI初始化和命令解析全部绕过了，在main()里拿到最基本的资源之后直接调WipeData()。擦完数据立刻Reboot("reboot")，参数"reboot"表示重启进系统，如果你想擦完直接关机，这里改成"shutdown"就行了。

有几个细节值得单独说。

第一，WipeData()在这个文件里是static函数，直接调用没问题，它实现在同文件下面。它会自己去挂载/data分区、格式化、处理加密状态。我不会自己去写格式化分区的逻辑，能复用系统的就复系统。

第二，Reboot()函数在AOSP里最终会往misc分区的command字段写东西，告诉Bootloader正常重启。如果之前是通过命令纸条进Recovery的，这里必须把纸条清掉或改写，否则会陷入"重启又进Recovery"的死循环。AOSP的Reboot函数里会处理这件事，但我见过某些定制BSP有坑，所以建议在重启前打印一下misc分区当前的内容，确认command字段被清干净了。

第三，日志输出。我把日志里加了个"[AutoWipe]"前缀，这样接上adb看logcat或者看串口log时能一眼过滤出关键节点，排查问题会快很多。

3.3 只改主程序够不够？聊聊显示和按键的死角

有朋友会问：main()里不初始化UI，那屏幕会显示什么？会不会还有Recovery的logo或者按键反应？

实际效果是这样：Recovery进程被init启动后，如果没有去初始化图形驱动，屏幕通常会停留在开机logo，或者直接黑屏。这正好符合"去掉UI界面显示"的需求。但有个死角你要注意——init进程在启动recovery服务之前，屏幕上显示的内容是由内核和init控制的，这部分不受recovery.cpp管辖。如果客户连开机logo都不想要，你就得去改内核命令行或者bootloader的显示逻辑，那已经是另一个项目了，本文不展开。

再一个死角是按键。Recovery模式下的音量键和电源键，在UI没有启动的时候一般不会被recovery进程监听，因为按键事件的读取也是UI模块的一部分。所以只要你不初始化UI，按键基本是死的，不会出现误触把流程打断的情况。倒是adb按键有可能还能用，开发调试时注意别手滑。

3.4 编译recoveryimage并刷机验证

代码改完，编译和刷机验证是重头戏。编译命令很简单：

# 在源码根目录 source build/envsetup.sh lunch <你的设备代号>-userdebug mka recoveryimage

如果只改了bootable/recovery，增量编译通常一两分钟就能出镜像。编译产物在out/target/product/<设备代号>/recovery.img。

刷机前老规矩，先备份原版recovery.img：

adb pull /dev/block/by-name/recovery ./recovery_backup.img

用fastboot刷入：

adb reboot bootloader fastboot flash recovery out/target/product/<设备代号>/recovery.img fastboot reboot

然后按键进Recovery模式（一般是关机状态下按住音量上+电源键，不同设备有差异）。如果一切正常，你会看到：屏幕停留在开机画面或者黑屏，大约几十秒后设备自动重启，重启后进入的是首次开机引导界面——说明数据已经被清掉了。

这里我建议验证时做两步确认。

第一步，进系统后随便创建点数据，放个文件、登录一个账号，再进Recovery，确认重启后数据确实没了。

第二步，串口同时挂着log，确认日志里出现了[AutoWipe] wipe_data done这一行。如果没出现，说明Recovery进程可能都没起来，或者执行到一半崩了。

我第一次改完烧进去，遇到的就是"Recovery根本不执行"，后来查串口才发现是设备树里Recovery镜像的ramdisk挂载路径跟源码默认路径对不上，导致init找不到recovery二进制。这种问题不挂串口是真难排查，后面我会在常见问题里再专门讲。

4. 核心实操二：不想改镜像，用BCB命令实现无人值守擦除

改AOSP源码的方案虽然彻底，但门槛不低——你得有全套源码和编译环境。如果手头只有一台已经定死的量产机，没源码没BSP，那怎么办？

别急，还有一条路：利用Recovery自带的命令行机制，往misc分区里写"命令纸条"，让Recovery启动后自动执行擦除。这就是我前面反复说的BCB（Bootloader Control Block）玩法。

4.1 原理回顾：往"纸条"上写命令

这个方案不需要改任何镜像，只需要在系统运行状态下，往misc分区写入一段特定格式的数据。Recovery启动后，main()会解析这段数据里的recovery字段，发现里面有"--wipe_data"参数，就会照着执行。

它和源码版方案的区别是：Recovery还是那个官方Recovery，UI初始化还是会走，但因为你写了命令，main()不会进入人机交互界面，而是直接执行擦除。所以从用户视角看，依然是"不出现UI、自动擦除、自动重启"。这也算"去掉UI"的另一种实现——不是物理去掉，而是让它没有出场机会。

4.2 在系统内用shell命令写入BCB

具体怎么往misc分区写？最简单的方式是利用root权限和dd命令。

首先找到misc分区在设备上的节点路径：

ls -l /dev/block/by-name/misc

一般会指向类似/dev/block/mmcblk0p24这样的节点。然后构造BCB数据并写入。

根据bootloader_message结构体，command字段和recovery字段分别在固定偏移处。要写的内容是：command位置填"boot-recovery"，recovery位置填"--wipe_data\n"。用dd直接写整个结构体有点风险，因为不同版本结构体字段对齐可能不同。我建议用一个小的C程序或者Android里现成的工具来写，别拿echo硬怼。

如果你手头工具受限，只能在终端里操作，这里给出一个可以工作的大致dd写法（注意，这只是最低限度写法，字段偏移依赖具体设备，先确认结构体再动手）：

# 假设misc节点是/dev/block/by-name/misc # 先备份原内容 dd if=/dev/block/by-name/misc of=/sdcard/misc_backup.img bs=2048 count=1 # 写入boot-recovery + --wipe_data，具体偏移要对齐结构体 # 这里用printf构造前64字节，command占前32，recovery从偏移32处开始 printf 'boot-recovery\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0--wipe_data\n' | dd of=/dev/block/by-name/misc bs=2048 count=1 conv=notrunc # 写入完成，重启进Recovery reboot recovery

这里我必须强调一句：直接dd操作misc分区的风险非常高，如果结构体字段错了，可能导致Recovery识别不了命令，甚至破坏Bootloader的参数区域导致无法开机。生产环境建议写一个完整结构体的工具，或者用AOSP源码里的工具链，而不是像我上面这样用printf硬拼。

4.3 更稳妥的方式：用工具或升级包触发

如果你不想碰裸命令，还有一个更稳的途径：写一个很小的系统辅助程序，拿到root权限后通过JNI调用或直接执行二进制，把BCB字段拼好再写进去，然后执行reboot recovery。这种方式的好处是结构体由代码控制，不容易错。

再或者，利用系统自带的升级包机制。Recovery是支持--update_package=/sdcard/xxx.zip的，你可以在系统里触发一次升级流程，让Recovery去处理你的zip包。在zip包里做数据擦除动作，这其实是OTA增量包里很常见的做法。不过这种方式水更深，涉及包签名和Recovery的校验逻辑，适合有定制系统的团队，这里点到为止。

4.4 这个方案在设备管理和回收场景中的应用

这条BCB路线在实际项目中特别好用，尤其是跟企业设备管理结合的时候。举个例子：租赁公司远程下发一个指令到设备上，设备端程序收到后往BCB写入"--wipe_data"，然后重启进Recovery自动擦除，擦完自动回系统。整个过程管理员不用碰设备，用户体验也是"重启一下就变成了出厂状态"。

这种"触发式擦除"跟本文源码版方案正好互补：源码版适合产线批量烧录时用，BCB版适合运营期按需触发。很多设备定制项目其实是两套同时做的，产线用源码版，售后和回收用BCB版。

5. 核心实操三：init.recovery.rc脚本法——最暴力但也最粗糙的方案

再介绍一种思路相对暴力的方案：直接改Recovery ramdisk里的init.recovery.rc脚本，让系统在初始化阶段就执行格式化动作。这个方案我不建议量产使用，但作为快速原型验证非常有用。

5.1 思路：在Recovery的init阶段直接把分区格式化

Recovery镜像本身是一个ramdisk，里面的init.rc/init.recovery.rc控制着Recovery系统的启动流程。正常情况下，recovery服务是在init阶段后期启动的，然后由它去处理各种命令。但我们完全可以绕过去——在init阶段直接把用户数据分区格式化掉，然后触发重启。

具体做法是