1. 項(xiàng)目緣起這需求到底要解決什么問題這段時(shí)間手頭一直在做安卓設(shè)備的定制化改造客戶提了個(gè)很實(shí)際的需求設(shè)備從產(chǎn)線下來或者從租戶手里收回來之后需要保證里面的歷史數(shù)據(jù)被徹底清掉。以前靠人手動(dòng)進(jìn)Recovery模式音量鍵上下選到wipe data/factory reset再按電源鍵確認(rèn)一天幾十臺(tái)機(jī)器弄下來眼睛都花了還容易誤觸?？蛻魡柕煤苤苯幽懿荒茏屧O(shè)備一進(jìn)Recovery模式就把數(shù)據(jù)擦了UI界面都不出現(xiàn)擦完自動(dòng)重啟這個(gè)需求的本質(zhì)是給安卓設(shè)備的Recovery模式去掉UI交互層把它變成一個(gè)無人值守的自動(dòng)擦除工具。聽上去像某個(gè)冷門工程需求其實(shí)在產(chǎn)線批量初始化、設(shè)備租賃回收、演示機(jī)清理、企業(yè)資產(chǎn)處置這些場(chǎng)景里非常常見。甚至很多做二手設(shè)備批發(fā)的朋友也會(huì)在底層搞這么一套省得一臺(tái)一臺(tái)手動(dòng)恢復(fù)出廠。這篇文章我就把從原理到動(dòng)手實(shí)現(xiàn)的全過程寫清楚包括AOSP源碼級(jí)改法、不改鏡像的BCB命令觸發(fā)法以及一種更暴力的init腳本法適合不同權(quán)限條件下、不同開發(fā)階段的同學(xué)參考。1.1 需求拆解去掉UI這件事有三層含義先說清楚很多人一聽去掉UI界面就覺得是讓屏幕不顯示東西。實(shí)際上在Recovery定制這個(gè)領(lǐng)域去掉UI至少有三個(gè)層次。第一層隱藏UI但從代碼流程上UI仍會(huì)被初始化只是不展示或者一閃而過。這種改法最簡(jiǎn)單適合想保留Recovery完整功能、只是臨時(shí)不讓人看到的場(chǎng)景。第二層跳過UI初始化讓Recovery主程序在啟動(dòng)后直接進(jìn)入數(shù)據(jù)擦除流程然后自動(dòng)重啟。這種改法改動(dòng)集中在recovery主程序也就是bootable/recovery/recovery.cpp是我個(gè)人最推薦、也是下文要重點(diǎn)講透的方案。第三層從構(gòu)建層面直接砍掉UI模塊讓Recovery鏡像里根本不含界面相關(guān)代碼。這種最徹底但改造成本高還要處理一堆編譯依賴一般量產(chǎn)機(jī)上輕易不動(dòng)。我這次實(shí)際做的是第二層。原因很簡(jiǎn)單它改動(dòng)范圍可控出問題容易回退而且對(duì)后續(xù)擴(kuò)展——比如擦完自動(dòng)進(jìn)系統(tǒng)、或者擦完自動(dòng)關(guān)機(jī)——非常友好。下文我會(huì)把這條路的每個(gè)細(xì)節(jié)都攤開講。1.2 在動(dòng)手之前先想清楚三個(gè)問題再往下講之前有三件事必須想明白否則后面做完了才發(fā)現(xiàn)方向錯(cuò)了會(huì)很被動(dòng)。第一這個(gè)Recovery是給誰用的。如果只是給自己開發(fā)調(diào)試用隨便改怎么快怎么來。但如果要交給產(chǎn)線工人、甚至交給終端用戶去操作那就要想清楚擦除完成后設(shè)備應(yīng)該停在什么狀態(tài)——是自動(dòng)重啟進(jìn)系統(tǒng)還是停在Recovery里提示一下又或者直接關(guān)機(jī)。不同狀態(tài)對(duì)應(yīng)不同的代碼分支別一股腦寫死。第二設(shè)備能不能刷。做Recovery定制無論是替換recovery分區(qū)還是改bootloader傳遞參數(shù)前提都是設(shè)備允許刷寫。商用設(shè)備如果Bootloader鎖著那只能走系統(tǒng)層授權(quán)方案比如通過系統(tǒng)升級(jí)包刷入這一條牽扯到設(shè)備準(zhǔn)入策略提前確認(rèn)能少走很多彎路。第三擦除之后需不需要保留Recovery本身的功能。有些場(chǎng)景要求Recovery只做擦數(shù)據(jù)這一件事擦完就沒用了有些場(chǎng)景則要求Recovery平時(shí)還能手動(dòng)進(jìn)、能刷升級(jí)包只是在特定觸發(fā)條件下才自動(dòng)擦除。這兩種需求在代碼層面的寫法差異很大前者可以直接把UI流程刪掉后者則是保留UI但加一個(gè)自動(dòng)分支。我現(xiàn)在講的這套是Recovery開機(jī)后無條件執(zhí)行擦除并重啟也就是最符合標(biāo)題描述的形態(tài)。如果你需要的是條件觸發(fā)在這個(gè)基礎(chǔ)上加一個(gè)判斷即可原理完全一樣。2. 先把底層鏈路打通Recovery模式到底是怎么啟動(dòng)的說到改Recovery首先得把它的啟動(dòng)鏈路搞明白。很多教程上來就讓人改recovery.cpp但改完編譯燒錄發(fā)現(xiàn)設(shè)備根本進(jìn)不了修改后的Recovery或者進(jìn)了之后卡在logo。這種問題十有八九是沒搞懂啟動(dòng)鏈路導(dǎo)致的。2.1 從按下電源鍵到Recovery界面一條完整的啟動(dòng)鏈安卓設(shè)備正常開機(jī)時(shí)流程大概是這樣的BootROM固化在SoC里的小程序→ Bootloader → Linux內(nèi)核 → init進(jìn)程 → Android系統(tǒng)。進(jìn)Recovery模式和這個(gè)流程基本一樣唯一的區(qū)別是Bootloader在啟動(dòng)內(nèi)核之前會(huì)先去讀一個(gè)小分區(qū)——misc分區(qū)看看里面有沒有啟動(dòng)到Recovery的指令如果有就把Recovery鏡像所在分區(qū)加載起來。具體到Recovery鏡像它通常是recovery分區(qū)里的一個(gè)完整啟動(dòng)鏡像包含內(nèi)核和ramdisk。ramdisk被內(nèi)核解壓后init進(jìn)程會(huì)讀取里面的init.rc和init.recovery.rc把基礎(chǔ)環(huán)境搭起來——掛載驅(qū)動(dòng)、設(shè)置屬性、啟動(dòng)recovery服務(wù)——接著才輪到真正的Recovery主程序也就是我們說的recovery進(jìn)程開始干活。這個(gè)過程里misc分區(qū)扮演的角色非常關(guān)鍵。你可以把它理解成貼在設(shè)備門口的一張紙條Bootloader出門前看一眼紙條今天要去Recovery值班。然后就把Recovery叫起來了。這張紙條上能寫的內(nèi)容不止是去Recovery還可以附帶參數(shù)比如去Recovery并擦除數(shù)據(jù)。misc分區(qū)里放的是一個(gè)固定結(jié)構(gòu)體叫bootloader_message在AOSP源碼的bootable/recovery/bootloader_message.cpp里有完整定義。結(jié)構(gòu)體里幾個(gè)關(guān)鍵字段我整理了個(gè)表字段長(zhǎng)度作用command32字節(jié)寫boot-recovery表示請(qǐng)求進(jìn)入Recoverystatus32字節(jié)Recovery向Bootloader回報(bào)執(zhí)行狀態(tài)recovery768字節(jié)Recovery要執(zhí)行的命令行參數(shù)多個(gè)參數(shù)用\n分隔stage32字節(jié)用于多步驟操作的狀態(tài)記錄reserved手動(dòng)對(duì)齊填充預(yù)留空間總長(zhǎng)2048字節(jié)這個(gè)結(jié)構(gòu)體看著簡(jiǎn)單但所有的無人值守玩法——不管官方OTA升級(jí)還是我們這次要做的一鍵擦除——本質(zhì)上都是在往這張紙條上寫字。2.2 Recovery主程序的main()UI和命令行在這里分叉Recovery進(jìn)程啟動(dòng)之后會(huì)先做一些初始化工作比如掛載必要的分區(qū)、讀取當(dāng)前分區(qū)狀態(tài)然后去解析bootloader_message里recovery字段帶過來的參數(shù)。AOSP里這套邏輯全在bootable/recovery/recovery.cpp的main()函數(shù)里。我用大白話給你翻譯一下main()的工作流程第一讀取參數(shù)。如果是從misc分區(qū)來的參數(shù)里可能是--wipe_data、--update_package...這類東西如果是從adb命令進(jìn)來的參數(shù)就是adb sideload傳的那套?？傊甿ain()先拿到一摞命令紙條。第二初始化UI。也就是把屏幕點(diǎn)亮、把Recovery的圖形界面畫出來。注意這一步跟后面執(zhí)行什么操作是并列的不是先后的關(guān)系。之所以先初始化UI是為了后面無論執(zhí)行什么操作都能往屏幕上打印進(jìn)度。第三檢查有沒有命令。如果命令紙條是空的——也就是沒人告訴它要干嘛——那Recovery就進(jìn)入交互界面等著你按音量鍵和電源鍵操作。如果紙條上寫了命令那就走命令行模式執(zhí)行命令、顯示進(jìn)度、完成之后根據(jù)命令決定重啟還是繼續(xù)。這段話是整個(gè)項(xiàng)目的核心。UI和命令執(zhí)行是兩條分支UI只負(fù)責(zé)給人看命令執(zhí)行才是干活的。我們想去掉UI思路立刻就清晰了要么讓Recovery在初始化UI之前把活干完并重啟要么把UI初始化這步直接跳過反正活已經(jīng)干完了。2.3 數(shù)據(jù)擦除這件事系統(tǒng)到底在做什么搞清楚UI分叉之后還得知道擦除數(shù)據(jù)具體干了什么否則容易搞出數(shù)據(jù)沒擦干凈的翻車事故。在AOSP原生Recovery里wipe data/factory reset會(huì)執(zhí)行WipeData()它的核心工作是格式化/data分區(qū)。這是用戶數(shù)據(jù)、應(yīng)用數(shù)據(jù)、系統(tǒng)設(shè)置、賬戶信息存放的地方普通的恢復(fù)出廠設(shè)置就是把它整個(gè)抹掉。清除/cache分區(qū)。緩存分區(qū)里存著系統(tǒng)更新的臨時(shí)文件和各種應(yīng)用緩存一般擦除操作會(huì)順手清掉。重置加密狀態(tài)。如果設(shè)備啟用了文件級(jí)加密FBE或全盤加密WipeData還需要把加密相關(guān)的key和目錄結(jié)構(gòu)重新初始化否則重啟后系統(tǒng)會(huì)因?yàn)檎也坏浇饷苊荑€而卡住。重置一些系統(tǒng)標(biāo)志位比如告訴系統(tǒng)這次開機(jī)屬于恢復(fù)出廠后的首次開機(jī)以便觸發(fā)歡迎引導(dǎo)流程。所以別看擦數(shù)據(jù)三個(gè)字簡(jiǎn)單背后涉及分區(qū)格式化、文件系統(tǒng)重建、加密元數(shù)據(jù)重置任何一步出錯(cuò)輕則開機(jī)卡在啟動(dòng)動(dòng)畫重則直接變磚。這也是為什么我堅(jiān)持用Recovery自帶的流程來擦而不是自己寫腳本去格式化分區(qū)——官方流程考慮得比我周全。3. 核心實(shí)操一改AOSP源碼打造無UI自動(dòng)擦除的Recovery好原理講完了下面開始動(dòng)手。我以AOSP的bootable/recovery為主線Android 9/10的代碼結(jié)構(gòu)為參考來講。如果你用的版本更老或者更新文件名和函數(shù)名可能稍有出入但思路是通用的。3.1 環(huán)境準(zhǔn)備源碼、lunch配置、編譯工具鏈改源碼之前先把編譯環(huán)境弄好。我這邊用的是Ubuntu 18.04主源碼是Android 9因?yàn)檫@臺(tái)設(shè)備的BSP是基于這個(gè)版本定的省得自己適配內(nèi)核和vendor。準(zhǔn)備工作分三步第一步同步AOSP源碼。注意不要只同步bootable/recovery這一個(gè)目錄因?yàn)榫幾gRecovery鏡像時(shí)依賴很多其他模塊比如system/core、external/、frameworks/base的一部分頭文件。老老實(shí)實(shí)把整個(gè)源碼樹同步下來最省心。同步時(shí)建議用repo工具配合--depth1控制歷史記錄體積否則搞不好要下幾百GB的數(shù)據(jù)。第二步lunch設(shè)備。這一步很關(guān)鍵。AOSP里Recovery鏡像并不單獨(dú)按arm64或x86架構(gòu)編譯它要服從整個(gè)系統(tǒng)的Makefile和產(chǎn)品配置。執(zhí)行source build/envsetup.sh lunch 你的設(shè)備代號(hào)-userdebuguserdebug版帶root權(quán)限調(diào)試Recovery模式時(shí)方便很多。沒有現(xiàn)成設(shè)備的兄弟也可以用模擬器支持的配置先跑通編譯流程比如lunch aosp_arm64-userdebug邏輯是一樣的。第三步確認(rèn)工具鏈。Android 9的AOSP編譯需要OpenJDK 8Ubuntu 18.04自帶的可能是OpenJDK 11需要額外裝一下并在build/envsetup.sh里指定。很多新人在這里就卡住了報(bào)錯(cuò)提示一堆版本不支持其實(shí)換一下JDK路徑就行。3.2 手術(shù)刀修改recovery.cpp的主流程準(zhǔn)備工作就緒接下來是主角——bootable/recovery/recovery.cpp。打開這個(gè)文件定位到main()函數(shù)。我用簡(jiǎn)化偽代碼說明改動(dòng)思路方便你理解位置int main(int argc, char** argv) { // ... 各種初始化掛載分區(qū)、讀取參數(shù)等等 ... // 原代碼初始化UI // std::unique_ptrRecoveryUI ui ...; // device-StartRecoveryUI(); // 原代碼根據(jù)是否有命令行參數(shù)決定進(jìn)UI還是執(zhí)行命令 // if (args.empty()) { // // 進(jìn)入交互式UI // } else { // // 執(zhí)行命令 // } // 修改點(diǎn)直接執(zhí)行擦除并重啟 LOG(INFO) [AutoWipe] Forcing wipe_data without UI...; if (WipeData() true) { LOG(INFO) [AutoWipe] wipe_data done, rebooting...; // 擦除成功后直接重啟 Reboot(reboot); // 如果 reboot 成功這里不會(huì)返回 } else { LOG(ERROR) [AutoWipe] wipe_data failed!; } // 兜底萬一上邊沒走通退回到正常流程 // ... }簡(jiǎn)單說我把UI初始化和命令解析全部繞過了在main()里拿到最基本的資源之后直接調(diào)WipeData()。擦完數(shù)據(jù)立刻Reboot(reboot)參數(shù)reboot表示重啟進(jìn)系統(tǒng)如果你想擦完直接關(guān)機(jī)這里改成shutdown就行了。有幾個(gè)細(xì)節(jié)值得單獨(dú)說。第一WipeData()在這個(gè)文件里是static函數(shù)直接調(diào)用沒問題它實(shí)現(xiàn)在同文件下面。它會(huì)自己去掛載/data分區(qū)、格式化、處理加密狀態(tài)。我不會(huì)自己去寫格式化分區(qū)的邏輯能復(fù)用系統(tǒng)的就復(fù)系統(tǒng)。第二Reboot()函數(shù)在AOSP里最終會(huì)往misc分區(qū)的command字段寫東西告訴Bootloader正常重啟。如果之前是通過命令紙條進(jìn)Recovery的這里必須把紙條清掉或改寫否則會(huì)陷入重啟又進(jìn)Recovery的死循環(huán)。AOSP的Reboot函數(shù)里會(huì)處理這件事但我見過某些定制BSP有坑所以建議在重啟前打印一下misc分區(qū)當(dāng)前的內(nèi)容確認(rèn)command字段被清干凈了。第三日志輸出。我把日志里加了個(gè)[AutoWipe]前綴這樣接上adb看logcat或者看串口log時(shí)能一眼過濾出關(guān)鍵節(jié)點(diǎn)排查問題會(huì)快很多。3.3 只改主程序夠不夠聊聊顯示和按鍵的死角有朋友會(huì)問main()里不初始化UI那屏幕會(huì)顯示什么會(huì)不會(huì)還有Recovery的logo或者按鍵反應(yīng)實(shí)際效果是這樣Recovery進(jìn)程被init啟動(dòng)后如果沒有去初始化圖形驅(qū)動(dòng)屏幕通常會(huì)停留在開機(jī)logo或者直接黑屏。這正好符合去掉UI界面顯示的需求。但有個(gè)死角你要注意——init進(jìn)程在啟動(dòng)recovery服務(wù)之前屏幕上顯示的內(nèi)容是由內(nèi)核和init控制的這部分不受recovery.cpp管轄。如果客戶連開機(jī)logo都不想要你就得去改內(nèi)核命令行或者bootloader的顯示邏輯那已經(jīng)是另一個(gè)項(xiàng)目了本文不展開。再一個(gè)死角是按鍵。Recovery模式下的音量鍵和電源鍵在UI沒有啟動(dòng)的時(shí)候一般不會(huì)被recovery進(jìn)程監(jiān)聽因?yàn)榘存I事件的讀取也是UI模塊的一部分。所以只要你不初始化UI按鍵基本是死的不會(huì)出現(xiàn)誤觸把流程打斷的情況。倒是adb按鍵有可能還能用開發(fā)調(diào)試時(shí)注意別手滑。3.4 編譯recoveryimage并刷機(jī)驗(yàn)證代碼改完編譯和刷機(jī)驗(yàn)證是重頭戲。編譯命令很簡(jiǎn)單# 在源碼根目錄 source build/envsetup.sh lunch 你的設(shè)備代號(hào)-userdebug mka recoveryimage如果只改了bootable/recovery增量編譯通常一兩分鐘就能出鏡像。編譯產(chǎn)物在out/target/product/設(shè)備代號(hào)/recovery.img。刷機(jī)前老規(guī)矩先備份原版recovery.imgadb pull /dev/block/by-name/recovery ./recovery_backup.img用fastboot刷入adb reboot bootloader fastboot flash recovery out/target/product/設(shè)備代號(hào)/recovery.img fastboot reboot然后按鍵進(jìn)Recovery模式一般是關(guān)機(jī)狀態(tài)下按住音量上電源鍵不同設(shè)備有差異。如果一切正常你會(huì)看到屏幕停留在開機(jī)畫面或者黑屏大約幾十秒后設(shè)備自動(dòng)重啟重啟后進(jìn)入的是首次開機(jī)引導(dǎo)界面——說明數(shù)據(jù)已經(jīng)被清掉了。這里我建議驗(yàn)證時(shí)做兩步確認(rèn)。第一步進(jìn)系統(tǒng)后隨便創(chuàng)建點(diǎn)數(shù)據(jù)放個(gè)文件、登錄一個(gè)賬號(hào)再進(jìn)Recovery確認(rèn)重啟后數(shù)據(jù)確實(shí)沒了。第二步串口同時(shí)掛著log確認(rèn)日志里出現(xiàn)了[AutoWipe] wipe_data done這一行。如果沒出現(xiàn)說明Recovery進(jìn)程可能都沒起來或者執(zhí)行到一半崩了。我第一次改完燒進(jìn)去遇到的就是Recovery根本不執(zhí)行后來查串口才發(fā)現(xiàn)是設(shè)備樹里Recovery鏡像的ramdisk掛載路徑跟源碼默認(rèn)路徑對(duì)不上導(dǎo)致init找不到recovery二進(jìn)制。這種問題不掛串口是真難排查后面我會(huì)在常見問題里再專門講。4. 核心實(shí)操二不想改鏡像用BCB命令實(shí)現(xiàn)無人值守擦除改AOSP源碼的方案雖然徹底但門檻不低——你得有全套源碼和編譯環(huán)境。如果手頭只有一臺(tái)已經(jīng)定死的量產(chǎn)機(jī)沒源碼沒BSP那怎么辦別急還有一條路利用Recovery自帶的命令行機(jī)制往misc分區(qū)里寫命令紙條讓Recovery啟動(dòng)后自動(dòng)執(zhí)行擦除。這就是我前面反復(fù)說的BCBBootloader Control Block玩法。4.1 原理回顧往紙條上寫命令這個(gè)方案不需要改任何鏡像只需要在系統(tǒng)運(yùn)行狀態(tài)下往misc分區(qū)寫入一段特定格式的數(shù)據(jù)。Recovery啟動(dòng)后main()會(huì)解析這段數(shù)據(jù)里的recovery字段發(fā)現(xiàn)里面有--wipe_data參數(shù)就會(huì)照著執(zhí)行。它和源碼版方案的區(qū)別是Recovery還是那個(gè)官方RecoveryUI初始化還是會(huì)走但因?yàn)槟銓懥嗣頼ain()不會(huì)進(jìn)入人機(jī)交互界面而是直接執(zhí)行擦除。所以從用戶視角看依然是不出現(xiàn)UI、自動(dòng)擦除、自動(dòng)重啟。這也算去掉UI的另一種實(shí)現(xiàn)——不是物理去掉而是讓它沒有出場(chǎng)機(jī)會(huì)。4.2 在系統(tǒng)內(nèi)用shell命令寫入BCB具體怎么往misc分區(qū)寫最簡(jiǎn)單的方式是利用root權(quán)限和dd命令。首先找到misc分區(qū)在設(shè)備上的節(jié)點(diǎn)路徑ls -l /dev/block/by-name/misc一般會(huì)指向類似/dev/block/mmcblk0p24這樣的節(jié)點(diǎn)。然后構(gòu)造BCB數(shù)據(jù)并寫入。根據(jù)bootloader_message結(jié)構(gòu)體command字段和recovery字段分別在固定偏移處。要寫的內(nèi)容是command位置填boot-recoveryrecovery位置填--wipe_data\n。用dd直接寫整個(gè)結(jié)構(gòu)體有點(diǎn)風(fēng)險(xiǎn)因?yàn)椴煌姹窘Y(jié)構(gòu)體字段對(duì)齊可能不同。我建議用一個(gè)小的C程序或者Android里現(xiàn)成的工具來寫別拿echo硬懟。如果你手頭工具受限只能在終端里操作這里給出一個(gè)可以工作的大致dd寫法注意這只是最低限度寫法字段偏移依賴具體設(shè)備先確認(rèn)結(jié)構(gòu)體再動(dòng)手# 假設(shè)misc節(jié)點(diǎn)是/dev/block/by-name/misc # 先備份原內(nèi)容 dd if/dev/block/by-name/misc of/sdcard/misc_backup.img bs2048 count1 # 寫入boot-recovery --wipe_data具體偏移要對(duì)齊結(jié)構(gòu)體 # 這里用printf構(gòu)造前64字節(jié)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 # 寫入完成重啟進(jìn)Recovery reboot recovery這里我必須強(qiáng)調(diào)一句直接dd操作misc分區(qū)的風(fēng)險(xiǎn)非常高如果結(jié)構(gòu)體字段錯(cuò)了可能導(dǎo)致Recovery識(shí)別不了命令甚至破壞Bootloader的參數(shù)區(qū)域?qū)е聼o法開機(jī)。生產(chǎn)環(huán)境建議寫一個(gè)完整結(jié)構(gòu)體的工具或者用AOSP源碼里的工具鏈而不是像我上面這樣用printf硬拼。4.3 更穩(wěn)妥的方式用工具或升級(jí)包觸發(fā)如果你不想碰裸命令還有一個(gè)更穩(wěn)的途徑寫一個(gè)很小的系統(tǒng)輔助程序拿到root權(quán)限后通過JNI調(diào)用或直接執(zhí)行二進(jìn)制把BCB字段拼好再寫進(jìn)去然后執(zhí)行reboot recovery。這種方式的好處是結(jié)構(gòu)體由代碼控制不容易錯(cuò)。再或者利用系統(tǒng)自帶的升級(jí)包機(jī)制。Recovery是支持--update_package/sdcard/xxx.zip的你可以在系統(tǒng)里觸發(fā)一次升級(jí)流程讓Recovery去處理你的zip包。在zip包里做數(shù)據(jù)擦除動(dòng)作這其實(shí)是OTA增量包里很常見的做法。不過這種方式水更深涉及包簽名和Recovery的校驗(yàn)邏輯適合有定制系統(tǒng)的團(tuán)隊(duì)這里點(diǎn)到為止。4.4 這個(gè)方案在設(shè)備管理和回收?qǐng)鼍爸械膽?yīng)用這條BCB路線在實(shí)際項(xiàng)目中特別好用尤其是跟企業(yè)設(shè)備管理結(jié)合的時(shí)候。舉個(gè)例子租賃公司遠(yuǎn)程下發(fā)一個(gè)指令到設(shè)備上設(shè)備端程序收到后往BCB寫入--wipe_data然后重啟進(jìn)Recovery自動(dòng)擦除擦完自動(dòng)回系統(tǒng)。整個(gè)過程管理員不用碰設(shè)備用戶體驗(yàn)也是重啟一下就變成了出廠狀態(tài)。這種觸發(fā)式擦除跟本文源碼版方案正好互補(bǔ)源碼版適合產(chǎn)線批量燒錄時(shí)用BCB版適合運(yùn)營(yíng)期按需觸發(fā)。很多設(shè)備定制項(xiàng)目其實(shí)是兩套同時(shí)做的產(chǎn)線用源碼版售后和回收用BCB版。5. 核心實(shí)操三init.recovery.rc腳本法——最暴力但也最粗糙的方案再介紹一種思路相對(duì)暴力的方案直接改Recovery ramdisk里的init.recovery.rc腳本讓系統(tǒng)在初始化階段就執(zhí)行格式化動(dòng)作。這個(gè)方案我不建議量產(chǎn)使用但作為快速原型驗(yàn)證非常有用。5.1 思路在Recovery的init階段直接把分區(qū)格式化Recovery鏡像本身是一個(gè)ramdisk里面的init.rc/init.recovery.rc控制著Recovery系統(tǒng)的啟動(dòng)流程。正常情況下recovery服務(wù)是在init階段后期啟動(dòng)的然后由它去處理各種命令。但我們完全可以繞過去——在init階段直接把用戶數(shù)據(jù)分區(qū)格式化掉然后觸發(fā)重啟。具體做法是