本申請涉及電數(shù)字數(shù)據(jù)的處理領(lǐng)域，尤其涉及一種系統(tǒng)更新方法和保存用于實現(xiàn)前述方法的可執(zhí)行代碼的非短暫計算機可讀介質(zhì)。

背景技術(shù)：

目前android系統(tǒng)recovery升級采用的是兩層設(shè)計架構(gòu)：recovery主體程序+updater腳本執(zhí)行程序+升級包。執(zhí)行方式為recovery主體程序先啟動，在完成必要的掛載分區(qū)、校驗升級包簽名后，再fork出一個進程來加載執(zhí)行updater程序來執(zhí)行升級腳本。在這種架構(gòu)中，recovery主體程序內(nèi)部的代碼都是根據(jù)系統(tǒng)具體的需求固定死的，比如分區(qū)名稱、簽名驗證規(guī)則、解析升級腳本的規(guī)則等等，一旦系統(tǒng)發(fā)布到市場后，只能在滿足現(xiàn)有代碼基礎(chǔ)上做適當?shù)男薷幕蛘呱墸瑹o法對系統(tǒng)進行根本性的改變，也就是無法任意定制系統(tǒng)。例如，發(fā)布出去的是一個系統(tǒng)，現(xiàn)在希望通過升級程序變成雙系統(tǒng)，甚至改變用戶可見存儲大小等等，這些需求是現(xiàn)有androidrecovery程序架構(gòu)無法滿足的，因為androidrecovery設(shè)計架構(gòu)的前提條件是不改變分區(qū)表的前提下進行升級，因此設(shè)計了前述架構(gòu)。同時，android的升級包是明文的，也就是說一旦解壓后，可以看到明文的升級腳本內(nèi)容，這不利于系統(tǒng)安全性，會泄露系統(tǒng)相關(guān)分區(qū)以及升級信息。

技術(shù)實現(xiàn)要素：

為了克服現(xiàn)有技術(shù)中存在的不足，本發(fā)明要解決的技術(shù)問題是提供一種系統(tǒng)更新方法，其使能通過更新任意定制和改造系統(tǒng)，而代碼改寫量遠小于傳統(tǒng)recovery升級架構(gòu)的代碼改寫量。

為解決上述技術(shù)問題，本發(fā)明系統(tǒng)更新方法，包括：

生成用于執(zhí)行更新的主程序；

生成一個或多個更新子程序執(zhí)行體，其中每一更新子程序具有相應(yīng)的功能，及所述一個或多個更新子程序執(zhí)行體在成功執(zhí)行后構(gòu)成所述系統(tǒng)的至少一部分；

生成更新配置文件，所述更新配置文件包含所述一個或多個更新子程序執(zhí)行體的路徑；

其中所述主程序在啟動運行時，加載解析所述更新配置文件，并根據(jù)所述更新配置文件中的所述路徑逐一加載和執(zhí)行所述一個或多個更新子程序執(zhí)行體中的每一更新子程序執(zhí)行體。

作為本發(fā)明所述方法的改進，所述方法還包括：將所述一個或多個更新子程序執(zhí)行體和所述更新配置文件打包成更新包。

作為本發(fā)明所述方法的進一步改進，所述方法還包括：所述主程序在啟動運行時，對所述更新包的合法性進行校驗。

作為本發(fā)明所述方法的另一種改進，所述方法還包括：所述主程序在加載一更新子程序執(zhí)行體之后對其進行安全性校驗。

作為本發(fā)明所述方法的又一種改進，所述方法還包括：每一更新子程序執(zhí)行體在執(zhí)行后將執(zhí)行結(jié)果回傳給所述主程序。

作為本發(fā)明所述方法的再一種改進，所述方法還包括：所述主程序在所有更新子程序執(zhí)行體成功執(zhí)行后提供更新成功的反饋。

為解決上述技術(shù)問題，本發(fā)明非短暫計算機可讀介質(zhì)，保存有用于執(zhí)行系統(tǒng)更新的主程序、一個或多個更新子程序執(zhí)行體和更新配置文件，其中每一更新子程序具有相應(yīng)的功能，及所述一個或多個更新子程序執(zhí)行體在成功執(zhí)行后構(gòu)成所述系統(tǒng)的至少一部分，所述更新配置文件包含所述一個或多個更新子程序執(zhí)行體的路徑；其中，所述主程序在啟動運行時，加載解析所述更新配置文件，并根據(jù)所述更新配置文件中的所述路徑逐一加載和執(zhí)行所述一個或多個更新子程序執(zhí)行體中的每一更新子程序執(zhí)行體。

本發(fā)明方法提出了一種新的recovery架構(gòu)，其采用recovery主程序+recovery更新配置文件+子程序執(zhí)行體的方式。配置文件中保存的是主程序需要啟動執(zhí)行的子程序路徑，用戶根據(jù)需要可以配置任意多個子程序，用戶可以定制每一個子程序的功能，而recovery主程序代碼永遠不需要改變，僅僅是按照配置文件的內(nèi)容來加載并執(zhí)行子程序即可，每一個子程序的執(zhí)行結(jié)果都會回傳給主程序，從而可通過更新任意定制系統(tǒng)，滿足任意升級的需求。

另外，升級包的內(nèi)容僅僅包含新的recovery配置文件和新的子程序執(zhí)行體兩部分內(nèi)容，這樣的升級包即使泄露出去，也無法從中看出系統(tǒng)的相關(guān)信息，使系統(tǒng)更加安全。

結(jié)合附圖閱讀本發(fā)明實施方式的詳細描述后，本發(fā)明的其它特點和優(yōu)點將變得更加清楚。

附圖說明

圖1為根據(jù)本發(fā)明方法的一實施例的流程圖。

圖2為使用本發(fā)明方法進行系統(tǒng)更新的一實施例的流程圖。

為清晰起見，這些附圖均為示意性及簡化的圖，它們只給出了對于理解本發(fā)明所必要的細節(jié)，而省略其他細節(jié)。

具體實施方式

下面參照附圖對本發(fā)明的實施方式和實施例進行詳細說明。

通過下面給出的詳細描述，本發(fā)明的適用范圍將顯而易見。然而，應(yīng)當理解，在詳細描述和具體例子表明本發(fā)明優(yōu)選實施例的同時，它們僅為說明目的給出。

圖1示出了本發(fā)明方法應(yīng)用于android系統(tǒng)升級更新的實施例。當然，只要適當，本發(fā)明方法也可應(yīng)用于其它操作系統(tǒng)的更新升級。

下面結(jié)合圖1所示流程圖對本發(fā)明的系統(tǒng)更新方法的一實施例的各步驟進行具體說明。

在步驟s102中，移動設(shè)備廠商生成用于執(zhí)行android操作系統(tǒng)更新的recovery主程序。recovery主程序一旦生成，其代碼永遠不需要改變。

在步驟s104中，生成一個或多個更新子程序執(zhí)行體，每一更新子程序具有相應(yīng)的功能，及一個或多個更新子程序執(zhí)行體在成功執(zhí)行后構(gòu)成操作系統(tǒng)的至少一部分。各更新子程序之間有約定好的通訊機制，以確保各更新子程序之間能夠進行相互通訊。

在步驟s106中，生成更新配置文件，該更新配置文件包含所述一個或多個更新子程序執(zhí)行體的路徑。

在步驟s108中，將所述一個或多個更新子程序執(zhí)行體和所述更新配置文件打包成更新包，供終端用戶下載或向終端用戶推送。

其中，所述主程序在啟動運行時，對所述更新包的合法性進行校驗。在通過合法性校驗的基礎(chǔ)上，加載解析所述更新包中的更新配置文件，并根據(jù)所述更新配置文件中的所述路徑逐一加載和執(zhí)行所述一個或多個更新子程序執(zhí)行體中的每一更新子程序執(zhí)行體，以對操作系統(tǒng)進行更新升級。

例如，假設(shè)更新配置文件中包含了安全校驗子程序、日志輸出子程序、ui子程序、分區(qū)掛載子程序、升級規(guī)則子程序、升級子程序的路徑。recovery主程序可預(yù)先安裝在終端用戶的移動設(shè)備上。在包含更新配置文件和更新子程序執(zhí)行體的更新包推送或下載到移動設(shè)備之后，可進行系統(tǒng)更新升級。圖2示出了更新升級的流程圖。

在步驟s202，recovery主程序啟動。

在步驟s204，recovery主程序首先校驗更新包的合法性。如果更新包通過合法性校驗，則處理進行到步驟s206，否則處理進行到步驟s230。

在步驟s206，recovery主程序加載解析更新配置文件。

在步驟s208，recovery主程序加載執(zhí)行安全校驗子程序，利用簽名機制對安全校驗子程序進行二進制校驗，校驗通過后該子程序執(zhí)行其自身邏輯。

在步驟s210，recovery主程序加載日志子程序，通知安全校驗子程序?qū)ζ溥M行校驗，校驗通過后該子程序執(zhí)行其自身邏輯。

在步驟s212，recovery主程序加載ui子程序，通知安全校驗子程序?qū)ζ溥M行校驗，校驗通過后該子程序執(zhí)行其自身邏輯。

在步驟s214，recovery主程序加載分區(qū)掛載子程序，通知安全校驗子程序?qū)ζ溥M行校驗，校驗通過后該子程序執(zhí)行其自身邏輯。

在步驟s216，recovery主程序加載升級子程序，通知安全校驗子程序?qū)ζ溥M行校驗，校驗通過后該子程序執(zhí)行其自身邏輯，升級前會查詢升級規(guī)則子程序是否允許升級。

在步驟s218，recovery主程序加載升級規(guī)則子程序，通知安全校驗子程序?qū)ζ溥M行校驗，校驗通過后該子程序執(zhí)行其自身邏輯。

在步驟s220，recovery主程序在所有子程序依次成功執(zhí)行后，提示反饋升級成功，由此系統(tǒng)將按照這些子程序的設(shè)計邏輯成為新的訂制系統(tǒng)。

步驟s208到步驟s218的任一步驟校驗未通過，則處理均進行到步驟s230。

在步驟s230，中間的任意過程失敗后(如任意更新子程序執(zhí)行體的校驗或執(zhí)行失敗)，recovery主程序用恰當?shù)姆绞椒答伣o用戶。

本發(fā)明方法的特點是可任意靈活擴展子程序，由此就可以按照需要對系統(tǒng)進行任意的改造，只要在升級包中提供recovery配置文件和子程序本身即可，recovery主程序無需改變。不同的子程序可以實現(xiàn)任意功能，只要用戶需要，理論上可以任意組織、重新設(shè)計并訂制系統(tǒng)。

本發(fā)明方法不僅實現(xiàn)了可擴展的智能recovery架構(gòu)，而且大大降低了程序員寫代碼的工作負荷，提高了生產(chǎn)率。

本發(fā)明的一實施例還提供一種非短暫計算機可讀介質(zhì)，其上保存有用于執(zhí)行系統(tǒng)更新的主程序、一個或多個更新子程序執(zhí)行體和更新配置文件，其中每一更新子程序具有相應(yīng)的功能，及所述一個或多個更新子程序執(zhí)行體在成功執(zhí)行后構(gòu)成所述系統(tǒng)的至少一部分，所述更新配置文件包含所述一個或多個更新子程序執(zhí)行體的路徑；其中，所述主程序在啟動運行時，加載解析所述更新配置文件，并根據(jù)所述更新配置文件中的所述路徑逐一加載和執(zhí)行所述一個或多個更新子程序執(zhí)行體中的每一更新子程序執(zhí)行體。根據(jù)一種實施方式，所述一個或多個更新子程序執(zhí)行體和所述更新配置文件包含在一個更新包中；和/或所述主程序在啟動運行時，對所述更新包的合法性進行校驗。

在某些情形下，只要適當，流程圖中和/或流水處理描述的步驟順序可修改，并不必須精確按照所描述的順序執(zhí)行。另外，本發(fā)明的多個不同方面可使用軟件、硬件、固件或者其組合和/或執(zhí)行所述功能的其它計算機實施的模塊或裝置進行實施。本發(fā)明的軟件實施可包括保存在計算機可讀介質(zhì)中并由一個或多個處理器執(zhí)行的可執(zhí)行代碼。計算機可讀介質(zhì)可包括計算機硬盤驅(qū)動器、rom、ram、閃存、便攜計算機存儲介質(zhì)如cd-rom、dvd-rom、閃盤驅(qū)動器和/或例如具有通用串行總線(usb)接口的其它裝置，和/或任何其它適當?shù)挠行位蚍嵌虝河嬎銠C可讀介質(zhì)或可執(zhí)行代碼可保存于其上并由處理器執(zhí)行的計算機存儲器。本發(fā)明可結(jié)合任何適當?shù)牟僮飨到y(tǒng)使用。

除非明確指出，在此所用的單數(shù)形式“一”、“該”均包括復(fù)數(shù)含義(即具有“至少一”的意思)。應(yīng)當進一步理解，說明書中使用的術(shù)語“具有”、“包括”和/或“包含”表明存在所述的特征、步驟、操作、元件和/或部件，但不排除存在或增加一個或多個其他特征、步驟、操作、元件、部件和/或其組合。如在此所用的術(shù)語“和/或”包括一個或多個列舉的相關(guān)項目的任何及所有組合。

前面說明了本發(fā)明的一些優(yōu)選實施例，但是應(yīng)當強調(diào)的是，本發(fā)明不局限于這些實施例，而是可以本發(fā)明主題范圍內(nèi)的其它方式實現(xiàn)。本領(lǐng)域技術(shù)人員可以在本發(fā)明技術(shù)構(gòu)思的啟發(fā)和不脫離本發(fā)明內(nèi)容的基礎(chǔ)上對本發(fā)明作出各種變形和修改，這些變形或修改仍落入本發(fā)明的保護范圍之內(nèi)。