一、 Recovery模式中的三個部分
Recovery的工作需要整個軟件平臺的配合，從通信架構上來看，主要有三個部分。
①MainSystem：即上面提到的正常啓動模式（BCB中無命令），是用boot.img啓動的系統，Android的正常工作模式。更新時，在這種模式中我們的上層操作就是使用OTA或者從SD卡中升級update.zip包。在重啓進入Recovery模式之前，會向BCB中寫入命令，以便在重啓後告訴bootloader進入Recovery模式。
②Recovery：系統進入Recovery模式後會裝載Recovery分區，該分區包含recovery.img（同boot.img相同，包含了標準的內核和根文件系統）。進入該模式後主要是運行Recovery服務（/sbin/recovery）來做相應的操作（重啓、升級update.zip、擦除cache分區等）。
③Bootloader：除了正常的加載啓動系統之外，還會通過讀取MISC分區（BCB）獲得來至Mainsystem和Recovery的消息。
Recovery對其操作的過程爲：先讀取BCB然後讀取/cache/recovery/command，然後將二者重新寫回BCB，這樣在進入Main system之前，確保操作被執行。
先從Main System開始看，當我們在Main System使用update.zip包進行升級時，系統會重啓並進入Recovery模式。在系統重啓之前，我們可以看到，Main System定會向BCB中的command域寫入boot-recovery(粉紅色線)，用來告知Bootloader重啓後進入recovery模式。這一步是必須的。至於Main System是否向recovery域寫入值我們在源碼中不能肯定這一點。即便如此，重啓進入Recovery模式後Bootloader會從/cache/recovery/command中讀取值並放入到BCB的recovery域。而Main
System在重啓之前肯定會向/cache/recovery/command中寫入Recovery將要進行的操作命令。
至此，我們就大概知道了，在上層使用update.zip升級時，主系統是怎樣告知重啓後的系統進入Recovery模式的，以及在Recovery模式中完成什麼樣的操作。
在重啓之前會向BCB中寫入信息，以告知bootloader如何啓動，具體操作是這樣的：
• 向command域中寫入“boot-recovery” // 此操作必做
• 向recovery域寫入“recovery\n” // 此操作也可不做
這些操作很可能在kernel_restart(char *cmd)中完成，因爲這一部分與體系結構無關，如果要實現完整的Recovery，這部分工作是必須做的。
Bootloader得到進入Recovery模式的指示，用recovery.img啓動，進入Recovery模式，init.rc (bootable/recovery/etc/init.rc)的內容比Main system的要短的多，最重要的是把recovery程序作爲服務啓動：
service recovery /sbin/recovery
而recovery[1024]中則存放着升級包路徑，其存儲結構如下：第一行存放字符串“recovery”；第二行存放路徑信息“--update=/mnt/sdcard/update.zip”等。
2.get_arg()：這個函數主要做了上圖中get_arg()往右往下直到parse arg/v的工作。我們對照着流程一個一個看。
①read_bootloader_message()：主要工作是根據分區的文件格式類型（mtd或emmc）從MISC分區中讀取BCB數據塊到一個臨時的變量中。
②然後開始判斷Recovery服務是否有帶命令行的參數（/sbin/recovery，根據現有的邏輯是沒有的），若沒有就從BCB中讀取recovery域。如果讀取失敗則從/cache/recovery/command中讀取然後（LOGI("Got arguments from boot message\n");）。這樣這個BCB的臨時變量中的recovery域就被更新了。在將這個BCB的臨時變量寫回真實的BCB之前，又更新的這個BCB臨時變量的command域爲“boot-recovery”。這樣做的目的是如果在升級失敗（比如升級還未結束就斷電了）時，系統在重啓之後還會進入Recovery模式，直到升級完成。
③在這個BCB臨時變量的各個域都更新完成後使用write_bootloader_message()寫回到真正的BCB