Android系統Recovery工做原理之使用update.zip升級過程分析（六）---R...

Android系統Recovery工做原理之使用update.zip升級過程分析（六）---Recovery服務流程細節

         Recovery服務毫無疑問是Recovery啓動模式中最核心的部分。它完成Recovery模式全部的工做。Recovery程序對應的源碼文件位於：/gingerbread0919/bootable/recovery/recovery.c。

1、 Recovery的三類服務：

         先看一下在這個源碼文件中開始部分的一大段註釋，這將對咱們理解Recovery服務的主要功能有很大幫助。代碼以下：

         /* * The recovery tool communicates with the main system through /cache files. * /cache/recovery/command - INPUT - command line for tool, one arg per line * /cache/recovery/log - OUTPUT - combined log file from recovery run(s) * /cache/recovery/intent - OUTPUT - intent that was passed in * * The arguments which may be supplied in the recovery.command file: * --send_intent=anystring - write the text out to recovery.intent * --update_package=path - verify install an OTA package file * --wipe_data - erase user data (and cache), then reboot * --wipe_cache - wipe cache (but not user data), then reboot * --set_encrypted_filesystem=on|off - enables / diasables encrypted fs * * After completing, we remove /cache/recovery/command and reboot. * Arguments may also be supplied in the bootloader control block (BCB). * These important scenarios must be safely restartable at any point: * * FACTORY RESET * 1. user selects "factory reset" * 2. main system writes "--wipe_data" to /cache/recovery/command * 3. main system reboots into recovery * 4. get_args() writes BCB with "boot-recovery" and "--wipe_data" * -- after this, rebooting will restart the erase -- * 5. erase_volume() reformats /data * 6. erase_volume() reformats /cache * 7. finish_recovery() erases BCB * -- after this, rebooting will restart the main system -- * 8. main() calls reboot() to boot main system * * OTA INSTALL * 1. main system downloads OTA package to /cache/some-filename.zip * 2. main system writes "--update_package=/cache/some-filename.zip" * 3. main system reboots into recovery * 4. get_args() writes BCB with "boot-recovery" and "--update_package=..." * -- after this, rebooting will attempt to reinstall the update -- * 5. install_package() attempts to install the update * NOTE: the package install must itself be restartable from any point * 6. finish_recovery() erases BCB * -- after this, rebooting will (try to) restart the main system -- * 7. ** if install failed ** * 7a. prompt_and_wait() shows an error icon and waits for the user * 7b; the user reboots (pulling the battery, etc) into the main system * 8. main() calls maybe_install_firmware_update() * ** if the update contained radio/hboot firmware **: * 8a. m_i_f_u() writes BCB with "boot-recovery" and "--wipe_cache" * -- after this, rebooting will reformat cache & restart main system -- * 8b. m_i_f_u() writes firmware image into raw cache partition * 8c. m_i_f_u() writes BCB with "update-radio/hboot" and "--wipe_cache" * -- after this, rebooting will attempt to reinstall firmware -- * 8d. bootloader tries to flash firmware * 8e. bootloader writes BCB with "boot-recovery" (keeping "--wipe_cache") * -- after this, rebooting will reformat cache & restart main system -- * 8f. erase_volume() reformats /cache * 8g. finish_recovery() erases BCB * -- after this, rebooting will (try to) restart the main system -- * 9. main() calls reboot() to boot main system * * SECURE FILE SYSTEMS ENABLE/DISABLE * 1. user selects "enable encrypted file systems" * 2. main system writes "--set_encrypted_filesystems=on|off" to * /cache/recovery/command * 3. main system reboots into recovery * 4. get_args() writes BCB with "boot-recovery" and * "--set_encrypted_filesystems=on|off" * -- after this, rebooting will restart the transition -- * 5. read_encrypted_fs_info() retrieves encrypted file systems settings from /data * Settings include: property to specify the Encrypted FS istatus and * FS encryption key if enabled (not yet implemented) * 6. erase_volume() reformats /data * 7. erase_volume() reformats /cache * 8. restore_encrypted_fs_info() writes required encrypted file systems settings to /data * Settings include: property to specify the Encrypted FS status and * FS encryption key if enabled (not yet implemented) * 9. finish_recovery() erases BCB * -- after this, rebooting will restart the main system -- * 10. main() calls reboot() to boot main system */

          從註釋中咱們能夠看到Recovery的服務內容主要有三類：

         ①FACTORY RESET，恢復出廠設置。

         ②OTA INSTALL，即咱們的update.zip包升級。

         ③ENCRYPTED FILE SYSTEM ENABLE/DISABLE，使能/關閉加密文件系統。具體的每一類服務的大概工做流程，註釋中都有，咱們在下文中會詳細講解OTA INSTALL的工做流程。這三類服務的大概的流程都是通用的，只是不一樣操做體現與不一樣的操做細節。下面咱們看Recovery服務的通用流程。

2、Recovery服務的通用流程：

        在這裏咱們以OTA INSTALL的流程爲例具體分析。並從相關函數的調用過程圖開始，以下圖:

          

          咱們順着流程圖分析，從recovery.c的main函數開始：

          1.    ui_init()：Recovery服務使用了一個基於framebuffer的簡單ui（miniui）系統。這個函數對其進行了簡單的初始化。在Recovery服務的過程當中主要用於顯示一個背景圖片（正在安裝或安裝失敗）和一個進度條（用於顯示進度）。另外還啓動了兩個線程，一個用於處理進度條的顯示（progress_thread），另外一個用於響應用戶的按鍵（input_thread）。

          2.    get_arg()：這個函數主要作了上圖中get_arg()往右往下直到parse arg/v的工做。咱們對照着流程一個一個看。

                ①get_bootloader_message()：主要工做是根據分區的文件格式類型（mtd或emmc）從MISC分區中讀取BCB數據塊到一個臨時的變量中。

                ②而後開始判斷Recovery服務是否有帶命令行的參數（/sbin/recovery，根據現有的邏輯是沒有的），若沒有就從BCB中讀取recovery域。若是讀取失敗則從/cache/recovery/command中讀取而後。這樣這個BCB的臨時變量中的recovery域就被更新了。在將這個BCB的臨時變量寫回真實的BCB以前，又更新的這個BCB臨時變量的command域爲「boot-recovery」。這樣作的目的是若是在升級失敗（好比升級還未結束就斷電了）時，系統在重啓以後還會進入Recovery模式，直到升級完成。

                ③在這個BCB臨時變量的各個域都更新完成後使用set_bootloader_message()寫回到真正的BCB塊中。

                這個過程能夠用一個簡單的圖來歸納，這樣更清晰：

                                 

          3.     parserargc/argv：解析咱們得到參數。註冊所解析的命令（register_update_command），在下面的操做中會根據這一步解析的值進行一步步的判斷，而後進行相應的操做。

          4.    if(update_package)：判斷update_package是否有值，如有就表示須要升級更新包，此時就會調用install_package()（即圖中紅色的第二個階段）。在這一步中將要完成安裝實際的升級包。這是最爲複雜，也是升級update.zip包最爲核心的部分。咱們在下一節詳細分析這一過程。爲從宏觀上理解Recovery服務的框架，咱們將這一步先略過，假設已經安裝完成了。咱們接着往下走，看安裝完成後Recovery怎樣一步步結束服務，並重啓到新的主系統的。

          5.    if(wipe_data/wipe_cache)：這一步判斷實際是兩步，在源碼中是先判斷是否擦除data分區（用戶數據部分）的，而後再判斷是否擦除cache分區。值得注意的是在擦除data分區的時候必須連帶擦除cache分區。在只擦除cache分區的情形下能夠不擦除data分區。

          6.    maybe_install_firmware_update()：若是升級包中包含/radio/hboot firmware的更新，則會調用這個函數。查看源碼發現，在註釋中（OTA INSTALL）有這一個流程。可是main函數中並無顯示調用這個函數。目前還沒有發現究竟是在什麼地方處理。可是其流程仍是向上面的圖示同樣。即，① 先向BCB中寫入「boot-recovery」和「—wipe_cache」以後將cache分區格式化，而後將firmware image 寫入原始的cache分區中。②將命令「update-radio/hboot」和「—wipe_cache」寫入BCB中，而後開始從新安裝firmware並刷新firmware。③以後又會進入圖示中的末尾，即finish_recovery()。

          7.    prompt_and_wait()：這個函數是在一個判斷中被調用的。其意義是若是安裝失敗（update.zip包錯誤或驗證簽名失敗），則等待用戶的輸入處理（如經過組合鍵reboot等）。

          8.    finish_recovery()：這是Recovery關閉並進入Main System的必經之路。其大致流程以下：

                                               

               ① 將intent（字符串）的內容做爲參數傳進finish_recovery中。若是有intent須要告知Main System，則將其寫入/cache/recovery/intent中。這個intent的做用尚不知有何用。

               ② 將內存文件系統中的Recovery服務的日誌（/tmp/recovery.log）拷貝到cache（/cache/recovery/log）分區中，以便告知重啓後的Main System發生過什麼。

               ③ 擦除MISC分區中的BCB數據塊的內容，以便系統重啓後不在進入Recovery模式而是進入更新後的主系統。

               ④ 刪除/cache/recovery/command文件。這一步也是很重要的，由於重啓後Bootloader會自動檢索這個文件，若是未刪除的話又會進入Recovery模式。原理在上面已經講的很清楚了。

          9.    reboot()：這是一個系統調用。在這一步Recovery完成其服務重啓並進入Main System。此次重啓和在主系統中重啓進入Recovery模式調用的函數是同樣的，可是其方向是不同的。因此參數也就不同。查看源碼發現，其重啓模式是RB_AUTOBOOT。這是一個系統的宏。

 

            至此，咱們對Recovery服務的整個流程框架已有了大概的認識。下面就是升級update.zip包時特有的也是Recovery服務中關於安裝升級包最核心的第二個階段。即咱們圖例中的紅色2的那個分支。

           咱們將在下一篇詳細講解這一部分，即Recovery服務的核心部分install_package函數