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

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

         Recovery服務毫無疑問是Recovery啟動模式中最核心的部分。它完成Recovery模式所有的工作。Recovery程式對應的源碼檔案位於：/gingerbread0919/bootable/recovery/recovery.c。

一、 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服務的通用流程。

二、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函數