安卓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里有完整定义。结构体里几个关键字段我整理了个表字段长度作用command32字节写boot-recovery表示请求进入Recoverystatus32字节Recovery向Bootloader回报执行状态recovery768字节Recovery要执行的命令行参数多个参数用\n分隔stage32字节用于多步骤操作的状态记录reserved手动对齐填充预留空间总长2048字节这个结构体看着简单但所有的无人值守玩法——不管官方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工具配合--depth1控制历史记录体积否则搞不好要下几百GB的数据。第二步lunch设备。这一步很关键。AOSP里Recovery镜像并不单独按arm64或x86架构编译它要服从整个系统的Makefile和产品配置。执行source build/envsetup.sh lunch 你的设备代号-userdebuguserdebug版带root权限调试Recovery模式时方便很多。没有现成设备的兄弟也可以用模拟器支持的配置先跑通编译流程比如lunch aosp_arm64-userdebug逻辑是一样的。第三步确认工具链。Android 9的AOSP编译需要OpenJDK 8Ubuntu 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_ptrRecoveryUI 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.imgadb 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启动后自动执行擦除。这就是我前面反复说的BCBBootloader Control Block玩法。4.1 原理回顾往纸条上写命令这个方案不需要改任何镜像只需要在系统运行状态下往misc分区写入一段特定格式的数据。Recovery启动后main()会解析这段数据里的recovery字段发现里面有--wipe_data参数就会照着执行。它和源码版方案的区别是Recovery还是那个官方RecoveryUI初始化还是会走但因为你写了命令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-recoveryrecovery位置填--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 bs2048 count1 # 写入boot-recovery --wipe_data具体偏移要对齐结构体 # 这里用printf构造前64字节command占前32recovery从偏移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 bs2048 count1 convnotrunc # 写入完成重启进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阶段直接把用户数据分区格式化掉然后触发重启。具体做法是