本申請涉及固件升級技術(shù)，具體涉及一種發(fā)布升級包的方法及裝置。本申請同時涉及一種輕量升級方法及裝置，一種輕量升級系統(tǒng)，以及一種制作輕量升級包的方法及裝置。

背景技術(shù)：

FOTA(Firmware Over-The-Air)，即空中下載軟件升級技術(shù)，也稱為遠程固件升級，是指通過云端升級技術(shù)，為具有連網(wǎng)功能的設(shè)備：例如手機、平板電腦、便攜式媒體播放器、移動互聯(lián)網(wǎng)設(shè)備等提供固件升級服務(wù)，用戶使用網(wǎng)絡(luò)以按需、易擴展的方式獲取智能終端系統(tǒng)升級包，從而完成系統(tǒng)升級、系統(tǒng)修復(fù)和優(yōu)化等功能。對于運營商和無線終端制造商來說，采用FOTA技術(shù)可以避免設(shè)備召回、減少客服電話和降低運作執(zhí)行成本；對于用戶來說，使用具備FOTA功能的終端設(shè)備，可以方便快捷地完成升級操作，避免去服務(wù)中心去尋求幫助的繁瑣過程。

現(xiàn)有固件升級主要有兩種方式：全量升級和增量升級。所謂全量升級，是將整個固件打包進行升級，這種升級包通常較大，一個升級包只能適配一個機型；而增量升級(也稱差分方式)，則通過比較前后兩個版本之間的差別，將差別做成升級包，這種升級包較小，一個升級包也只能適配一個機型。

現(xiàn)有固件升級不論是采用增量方式還是全量方式，都是針對單個機型進行升級，而且都是基于整個軟件系統(tǒng)的升級，由于移動終端設(shè)備的軟件系統(tǒng)通常比較復(fù)雜，包括應(yīng)用程序?qū)右约爸苯踊蛘唛g接為應(yīng)用程序?qū)犹峁└鞣N服務(wù)的各支撐層(例如：Android系統(tǒng)中的框架層、系統(tǒng)運行庫層、內(nèi)核層)，因此整個軟件系統(tǒng)的升級需要相對比較長的開發(fā)和測試周期，特別是在機型眾多、或者遇到功能相對豐富的支撐層(例如：框架層)需要升級時，整個系統(tǒng)需要更多的時間進行開發(fā)、測試和驗證。而應(yīng)用程序的發(fā)布周期通常都比較短，希望能夠迅速發(fā)布到多種機型上，上述固件更新方式顯然無法滿足應(yīng)用程序快速更新和發(fā)布的需求。

此外，現(xiàn)有方式的升級包通常只針對一款機型、并且涉及對多個分區(qū)的更新，在升級時需要區(qū)分機型和分區(qū)，要嚴(yán)格校驗被升級設(shè)備的分區(qū)和升級包中的設(shè)置是否一致，包括分區(qū)的大小、起始地址等，操作繁瑣、執(zhí)行效率低。

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

本申請實施例提供一種發(fā)布升級包的方法和裝置，以解決現(xiàn)有的全量以及增量升級方式無法滿足應(yīng)用的快速更新和發(fā)布的問題。本申請實施例還提供一種輕量升級方法和裝置，一種輕量升級系統(tǒng)，以及一種制作輕量升級包的方法和裝置。

本申請?zhí)峁┮环N發(fā)布升級包的方法，包括：

針對與系統(tǒng)耦合程度滿足預(yù)設(shè)要求的待發(fā)布應(yīng)用程序，制作輕量升級包；

向客戶端發(fā)送輕量升級信息，以供客戶端獲取輕量升級包并執(zhí)行相應(yīng)的升級操作。

可選的，所述與系統(tǒng)耦合程度滿足預(yù)設(shè)要求的待發(fā)布應(yīng)用程序包括：

不使用自定義庫文件的待發(fā)布應(yīng)用程序。

可選的，所述與系統(tǒng)耦合程度滿足預(yù)設(shè)要求的待發(fā)布應(yīng)用程序包括：

使用自定義庫文件、且所述自定義庫文件未與向應(yīng)用程序提供服務(wù)的支撐層集成在一起的待發(fā)布應(yīng)用程序；

所述針對與系統(tǒng)耦合程度滿足預(yù)設(shè)要求的待發(fā)布應(yīng)用程序制作輕量升級包，包括：將上述應(yīng)用程序及使用的自定義庫文件一起打包生成輕量升級包。

可選的，所述客戶端設(shè)備包括：采用Android系統(tǒng)的移動終端設(shè)備；所述支撐層包括：應(yīng)用框架層。

可選的，在所述向客戶端發(fā)送所述輕量升級信息之前，執(zhí)行下述操作：

接收來自客戶端的升級請求，所述請求中至少攜帶輕量升級版本號；

判斷是否存在其版本號大于所述輕量升級版本號的輕量升級包；

若是，則執(zhí)行所述向客戶端發(fā)送輕量升級信息的步驟，所述輕量升級信息中包含所述輕量升級包的相關(guān)信息。

可選的，所述請求中還攜帶用于安裝輕量升級包的分區(qū)的剩余容量信息；

當(dāng)判斷是否存在其版本號大于所述輕量升級版本號的輕量升級包的結(jié)果為 是時，執(zhí)行下述操作：

判斷所述剩余容量是否滿足安裝所述輕量升級包的需求；

若是，則執(zhí)行所述向客戶端發(fā)送輕量升級信息的步驟。

可選的，所述請求中還攜帶客戶端上報的以下信息之一或者組合：客戶端固件版本號、客戶端設(shè)備型號；

所述判斷是否存在其版本號大于所述輕量升級版本號的輕量升級包，包括：判斷是否存在與上述客戶端上報信息相對應(yīng)的、且其版本號大于所述輕量升級版本號的輕量升級包。

可選的，所述針對與系統(tǒng)耦合程度滿足預(yù)設(shè)要求的待發(fā)布應(yīng)用程序制作輕量升級包，包括：

生成與安裝輕量升級包的客戶端分區(qū)相同的目錄結(jié)構(gòu)；

將待打包文件復(fù)制到所述目錄結(jié)構(gòu)的相應(yīng)目錄中，所述待打包文件至少包含所述與系統(tǒng)耦合程度滿足預(yù)設(shè)要求的待發(fā)布應(yīng)用程序；

將上述目錄壓縮打包，得到所述輕量升級包。

可選的，在將上述目錄壓縮打包后，執(zhí)行下述操作：

對壓縮包進行簽名，并將簽名后的壓縮包作為所述輕量升級包。

可選的，在所述將上述目錄壓縮打包之前，執(zhí)行下述操作：

編寫用于在客戶端執(zhí)行升級操作的升級程序，并將所述升級程序復(fù)制到與客戶端預(yù)先約定的目錄結(jié)構(gòu)中；

所述將上述目錄壓縮打包包括：將包含待打包文件的目錄、以及包含升級程序的目錄壓縮打包。

可選的，所述向客戶端發(fā)送的輕量升級信息包括：用于獲取所述輕量升級包的地址信息。

相應(yīng)的，本申請還提供一種發(fā)布升級包的裝置，包括：

輕量升級包制作單元，用于針對與系統(tǒng)耦合程度滿足預(yù)設(shè)要求的待發(fā)布應(yīng)用程序，制作輕量升級包；

升級信息發(fā)送單元，用于向客戶端發(fā)送輕量升級信息，以供客戶端獲取輕量升級包并執(zhí)行相應(yīng)的升級操作。

可選的，所述裝置包括：

升級請求接收單元，用于在觸發(fā)所述升級信息發(fā)送單元之前，接收來自客戶端的升級請求，所述請求中至少攜帶輕量升級版本號；

版本判斷單元，用于判斷是否存在其版本號大于所述輕量升級版本號的輕量升級包；

所述升級信息發(fā)送單元具體用于，向客戶端發(fā)送輕量升級信息，所述輕量升級信息中包含所述輕量升級包的相關(guān)信息。

可選的，所述升級請求接收單元接收到的升級請求中還攜帶用于安裝輕量升級包的分區(qū)的剩余容量信息；

所述裝置還包括：

剩余容量判斷單元，用于當(dāng)所述版本判斷單元的輸出為是時，判斷所述剩余容量是否滿足安裝所述輕量升級包的需求，并且在滿足時觸發(fā)所述升級信息發(fā)送單元工作。

可選的，所述升級請求接收單元接收到的升級請求中還攜帶客戶端上報的以下信息之一或者組合：客戶端固件版本號、客戶端設(shè)備型號；

所述版本判斷單元具體用于，判斷是否存在與上述客戶端上報信息相對應(yīng)的、且其版本號大于所述輕量升級版本號的輕量升級包。

可選的，所述輕量升級包制作單元包括：

目錄結(jié)構(gòu)生成子單元，用于生成與安裝輕量升級包的客戶端分區(qū)相同的目錄結(jié)構(gòu)；

文件復(fù)制子單元，用于將待打包文件復(fù)制到所述目錄結(jié)構(gòu)的相應(yīng)目錄中，所述待打包文件至少包含所述與系統(tǒng)耦合程度滿足預(yù)設(shè)要求的待發(fā)布應(yīng)用程序；

壓縮打包子單元，用于將上述目錄壓縮打包，得到所述輕量升級包。

可選的，所述輕量升級包制作單元還包括：

壓縮包簽名子單元，用于在所述壓縮打包子單元完成壓縮打包操作后，對壓縮包進行簽名，并將簽名后的壓縮包作為所述輕量升級包。

可選的，所述輕量升級包制作單元還包括：

升級程序復(fù)制子單元，用于在觸發(fā)所述壓縮打包子單元之前，編寫用于在客戶端執(zhí)行升級操作的升級程序，并將所述升級程序復(fù)制到與客戶端預(yù)先約定 的目錄結(jié)構(gòu)中；

所述壓縮打包子單元具體用于，將包含待打包文件的目錄、以及包含升級程序的目錄壓縮打包。

可選的，所述升級信息發(fā)送單元發(fā)送的輕量升級信息包括：用于獲取所述輕量升級包的地址信息。

此外，本申請還提供一種輕量升級方法，包括：

接收服務(wù)器端發(fā)送的輕量升級信息，并獲取輕量升級包；

將所述輕量升級包安裝到預(yù)設(shè)分區(qū)中；

其中，所述輕量升級包是由服務(wù)器端針對與系統(tǒng)耦合程度滿足預(yù)設(shè)要求的應(yīng)用程序打包生成的。

可選的，在所述接收服務(wù)器端發(fā)送的輕量升級信息之前，執(zhí)行下述操作：

獲取本地的輕量升級版本號；

向服務(wù)器端發(fā)送升級請求，所述升級請求中至少攜帶所述輕量升級版本號。

可選的，在向服務(wù)器端發(fā)送升級請求之前，還獲取以下信息之一或者組合：固件版本號、設(shè)備型號；

所述升級請求中不僅攜帶所述輕量升級版本號、還攜帶上述獲取的信息。

可選的，所述升級請求中攜帶的信息是采用如下方式獲取的：通過讀取系統(tǒng)屬性獲取所述信息。

可選的，在向服務(wù)器端發(fā)送升級請求之前，執(zhí)行下述操作：

計算所述預(yù)設(shè)分區(qū)的剩余容量；

所述升級請求中不僅攜帶所述輕量升級版本號、還攜帶所述剩余容量信息。

可選的，所述輕量升級信息包括：用于獲取所述輕量升級包的地址信息；

所述獲取輕量升級包包括：根據(jù)所述地址信息下載所述輕量升級包。

可選的，所述將所述輕量升級包安裝到預(yù)設(shè)分區(qū)中，包括：

解壓縮所述輕量升級包；

將輕量升級包中的應(yīng)用程序及相關(guān)庫文件復(fù)制到所述預(yù)設(shè)分區(qū)的相應(yīng)目錄中；

更新本地的輕量升級版本號。

可選的，所述將輕量升級包中的應(yīng)用程序及相關(guān)文件復(fù)制到所述預(yù)設(shè)分區(qū)的相應(yīng)目錄中、以及更新輕量升級版本號的步驟，采用如下方式實現(xiàn)：

執(zhí)行所述輕量升級包中的升級程序，完成所述操作。

可選的，所述方法在采用Android系統(tǒng)的移動終端設(shè)備上實施；所述預(yù)設(shè)分區(qū)包括：系統(tǒng)分區(qū)。

相應(yīng)的，本申請還提供一種輕量升級裝置，包括：

輕量升級包獲取單元，用于接收服務(wù)器端發(fā)送的輕量升級信息，并獲取輕量升級包，其中，所述輕量升級包是由服務(wù)器端針對與系統(tǒng)耦合程度滿足預(yù)設(shè)要求的應(yīng)用程序打包生成的；

輕量升級包安裝單元，用于將所述輕量升級包安裝到預(yù)設(shè)分區(qū)中。

可選的，所述裝置包括：

輕量版本號獲取單元，用于在所述輕量升級包獲取單元工作之前，獲取本地的輕量升級版本號；

升級請求發(fā)送單元，用于向服務(wù)器端發(fā)送升級請求，所述升級請求中至少攜帶所述輕量升級版本號。

可選的，所述裝置還包括：

設(shè)備信息獲取單元，用于在觸發(fā)所述升級請求發(fā)送單元工作之前，獲取以下信息之一或者組合：固件版本號、設(shè)備型號；

所述升級請求發(fā)送單元發(fā)送的升級請求中不僅攜帶輕量升級版本號，還攜帶所述設(shè)備信息獲取單元獲取的上述信息。

可選的，所述輕量版本號獲取單元和所述設(shè)備信息獲取單元具體用于，通過讀取系統(tǒng)屬性獲取所需信息。

可選的，所述裝置還包括：

剩余容量計算單元，用于在觸發(fā)所述升級請求發(fā)送單元工作之前，計算所述預(yù)設(shè)分區(qū)的剩余容量；

所述升級請求發(fā)送單元發(fā)送的升級請求中不僅攜帶輕量升級版本號，還攜帶所述剩余容量信息。

可選的，所述輕量升級包獲取單元接收的輕量升級信息中包含：用于獲取所述輕量升級包的地址信息；

所述輕量升級包獲取單元具體用于，接收服務(wù)器端發(fā)送的輕量升級信息，并根據(jù)其中的地址信息下載輕量升級包。

可選的，所述輕量升級包安裝單元包括：

解壓縮子單元，用于解壓縮所述輕量升級包；

文件復(fù)制安裝子單元，用于將輕量升級包中的應(yīng)用程序及相關(guān)庫文件復(fù)制到所述預(yù)設(shè)分區(qū)的相應(yīng)目錄中；

版本號更新子單元，用于更新本地的輕量升級版本號。

此外，本申請還提供一種輕量升級系統(tǒng)，包括：根據(jù)上述任意一項所述的發(fā)布升級包的裝置，以及根據(jù)上述任意一項所述的輕量升級裝置。

此外，本申請還提供一種制作輕量升級包的方法，包括：

生成與安裝輕量升級包的客戶端分區(qū)相同的目錄結(jié)構(gòu)；

將與系統(tǒng)耦合程度滿足預(yù)設(shè)要求的待發(fā)布應(yīng)用程序復(fù)制到所述目錄結(jié)構(gòu)的相應(yīng)目錄中；

將上述目錄壓縮打包，得到所述輕量升級包。

相應(yīng)的，本申請還提供一種制作輕量升級包的裝置，包括：

目錄創(chuàng)建單元，用于生成與安裝輕量升級包的客戶端分區(qū)相同的目錄結(jié)構(gòu)；

文件復(fù)制單元，用于將與系統(tǒng)耦合程度滿足預(yù)設(shè)要求的待發(fā)布應(yīng)用程序復(fù)制到所述目錄結(jié)構(gòu)的相應(yīng)目錄中；

壓縮打包單元，用于將上述目錄壓縮打包，得到所述輕量升級包。

與現(xiàn)有技術(shù)相比，本申請具有以下優(yōu)點：

本申請?zhí)峁┑募夹g(shù)方案，服務(wù)器端針對與系統(tǒng)耦合程度滿足預(yù)設(shè)要求的待發(fā)布應(yīng)用程序制作輕量升級包，并向客戶端發(fā)送輕量升級信息；客戶端則根據(jù)服務(wù)器端提供的輕量升級信息獲取輕量升級包，并將輕量升級包安裝到預(yù)設(shè)分區(qū)中，從而與系統(tǒng)耦合程度滿足預(yù)設(shè)要求的應(yīng)用程序一旦開發(fā)測試完畢，就可以以輕量升級包的形式發(fā)布給客戶端，而不必等待整個軟件系統(tǒng)一起發(fā)布，實現(xiàn)了應(yīng)用程序的快速更新與發(fā)布。而且由于輕量升級包可以適配多種機型，在客戶端升級過程中可以不用區(qū)分機型、分區(qū)，可以簡化操作、提高執(zhí)行效率。

附圖說明

圖1是本申請的一種發(fā)布升級包的方法的實施例的流程圖；

圖2是本申請實施例提供的制作輕量升級包的處理流程圖；

圖3是本申請實施例提供的基于請求/響應(yīng)方式發(fā)送輕量升級信息的處理流程圖；

圖4是本申請的一種發(fā)布升級包的裝置的實施例的示意圖；

圖5是本申請的一種輕量升級方法的實施例的流程圖；

圖6是本申請實施例提供的基于請求/響應(yīng)方式獲取輕量升級信息的處理流程圖；

圖7是本申請實施例提供的將輕量升級包安裝到預(yù)設(shè)分區(qū)的處理流程圖；

圖8是本申請的一種輕量升級裝置的實施例的示意圖；

圖9是本申請的一種輕量升級系統(tǒng)的實施例的示意圖；

圖10是本申請的一種制作輕量升級包的方法的實施例的流程圖；

圖11是本申請的一種制作輕量升級包的裝置的實施例的示意圖。

具體實施方式

在下面的描述中闡述了很多具體細節(jié)以便于充分理解本申請。但是，本申請能夠以很多不同于在此描述的其它方式來實施，本領(lǐng)域技術(shù)人員可以在不違背本申請內(nèi)涵的情況下做類似推廣，因此，本申請不受下面公開的具體實施的限制。

在本申請中，分別提供了一種發(fā)布輕量升級包的方法及裝置，一種輕量升級方法及裝置，一種輕量升級系統(tǒng)，以及一種制作輕量升級包的方法及裝置，在下面的實施例中逐一進行詳細說明。

請參考圖1，其為本申請的一種發(fā)布升級包的方法的實施例的流程圖。所述方法通常在負責(zé)發(fā)布升級包的服務(wù)器端實施，所述方法包括如下步驟：

步驟101、針對與系統(tǒng)耦合程度滿足預(yù)設(shè)要求的待發(fā)布應(yīng)用程序，制作輕量升級包。

現(xiàn)有的客戶端固件升級方式，不論是全量升級還是增量升級，都是針對整個軟件系統(tǒng)制作升級包，因此發(fā)布周期長。而本申請的技術(shù)方案則僅針對與系 統(tǒng)耦合程度滿足預(yù)設(shè)要求的待發(fā)布應(yīng)用程序制作輕量升級包，從而實現(xiàn)應(yīng)用程序的快速發(fā)布。

所述待發(fā)布應(yīng)用程序，通常是指已經(jīng)完成開發(fā)和調(diào)試等階段、可以提供給客戶端更新使用的應(yīng)用程序。與系統(tǒng)耦合程度滿足預(yù)設(shè)要求的待發(fā)布應(yīng)用程序，通常是指可以獨立更新升級、而不依賴于軟件系統(tǒng)整體更新升級的應(yīng)用程序。

對于采用不同平臺的客戶端，其軟件系統(tǒng)架構(gòu)可能不完全相同，但是通常都采用分層架構(gòu)的方式，不僅包括應(yīng)用程序?qū)?、還包括直接或者間接為應(yīng)用程序提供各種服務(wù)的各支撐層。所述與系統(tǒng)耦合程度滿足預(yù)設(shè)要求的待發(fā)布應(yīng)用程序可以包括：不使用自定義庫文件的待發(fā)布應(yīng)用程序、以及使用自定義庫文件、且自定義庫文件未與向應(yīng)用程序提供服務(wù)的支撐層集成在一起的待發(fā)布應(yīng)用程序。下面以采用Android平臺的客戶端軟件架構(gòu)為例，作進一步說明。

基于Android平臺的軟件架構(gòu)，從高到低通?？梢苑譃樗膶樱簯?yīng)用程序?qū)?、?yīng)用程序框架層(framework)、系統(tǒng)運行庫層和核心層。其中，應(yīng)用程序?qū)影ㄒ幌盗泻诵膽?yīng)用程序以及常用應(yīng)用程序；應(yīng)用程序框架層則包含應(yīng)用程序運行所必需的功能組件，應(yīng)用程序通過使用這些功能組件可以實現(xiàn)其所需的功能；系統(tǒng)運行庫層提供各種子程序以及Java核心庫；核心層則是Linux內(nèi)核，提供硬件驅(qū)動、內(nèi)存管理、進程管理等核心功能?？梢赃@樣理解，框架層(framework)是直接為應(yīng)用程序提供支持的支撐層，系統(tǒng)運行庫層和核心層則是間接為應(yīng)用程序提供支持的支撐層。

有的應(yīng)用程序通過使用框架層組件，即可實現(xiàn)自己的功能；有的應(yīng)用程序需要實現(xiàn)某些特殊功能、而框架層未提供相應(yīng)組件，這種情況下應(yīng)用程序可以自己定義并開發(fā)相應(yīng)的庫，并將自定義庫文件與應(yīng)用程序集成在一起，即：打成一個包；有的應(yīng)用程序則將自定義庫文件放置在框架層，但是并未與框架層集成在一起，即并未與框架層編譯到一個JAR包中，而是將庫文件獨立打包。

上面列舉的這三種情況，都屬于本實施例所述的與系統(tǒng)耦合程度滿足預(yù)設(shè)要求的應(yīng)用程序，其中前兩種情況可以認為與系統(tǒng)沒有耦合，第三種情況雖與系統(tǒng)存在耦合、但是耦合程度較低，符合這三種情況的應(yīng)用程序都可以獨立于向其提供服務(wù)的支撐層進行更新升級，因此本步驟可以針對滿足上述條件的待發(fā)布應(yīng)用程序制作輕量升級包，從而可以實現(xiàn)應(yīng)用程序的快速更新和發(fā)布。

在制作輕量升級包時，針對上述第一種情況，將待發(fā)布應(yīng)用程序加入輕量 升級包即可，對于后兩種情況，則可以將待發(fā)布應(yīng)用程序和使用的庫文件一起加入輕量升級包。

輕量升級包中可以只包含上述要更新的文件，為了便于客戶端執(zhí)行正確的升級操作，本實施例還提供一種優(yōu)選實施方式：編寫用于在客戶端執(zhí)行升級操作的升級程序，并將所述升級程序也添加到輕量升級包中。

基于上述描述，制作輕量升級包的過程具體包括生成目錄結(jié)構(gòu)、復(fù)制待打包文件、壓縮打包、簽名這樣幾個步驟，下面結(jié)合附圖2，以制作Android客戶端的輕量升級包為例，對制作輕量升級包的過程作詳細說明。

步驟101-1、生成與安裝輕量升級包的客戶端分區(qū)相同的目錄結(jié)構(gòu)。

輕量升級包通常安裝在客戶端的預(yù)設(shè)分區(qū)中，對于采用Android系統(tǒng)的客戶端來說，所述預(yù)設(shè)分區(qū)通常是指系統(tǒng)(system)分區(qū)。本步驟在本地文件系統(tǒng)中創(chuàng)建與客戶端系統(tǒng)分區(qū)相同的目錄結(jié)構(gòu)，即：先創(chuàng)建system目錄，然后在system目錄下創(chuàng)建app、framework、lib等子目錄。

步驟101-2、將待打包文件復(fù)制到所述目錄結(jié)構(gòu)的相應(yīng)目錄中，所述待打包文件至少包含所述與系統(tǒng)耦合程序滿足預(yù)設(shè)要求的待發(fā)布應(yīng)用程序。

可以將需要升級的應(yīng)用程序復(fù)制到app目錄下；如果應(yīng)用程序使用的自定義庫文件以獨立JAR包的形式放置在框架層，可以將相應(yīng)JAR包復(fù)制到framework目錄下。

步驟101-3、編寫用于在客戶端執(zhí)行升級操作的升級程序，并將所述升級程序復(fù)制到與客戶端預(yù)先約定的目錄結(jié)構(gòu)中。

對于采用Android系統(tǒng)的客戶端，用于執(zhí)行升級操作的升級程序通常稱為腳本文件，也稱升級腳本，服務(wù)器端可以在輕量升級包的特定目錄中包含該文件，客戶端則從輕量升級包的所述特定目錄(雙方預(yù)先約定相同的目錄)中獲取該文件并執(zhí)行，從而完成升級操作。

升級腳本主要負責(zé)將輕量升級包中的文件寫入對應(yīng)的系統(tǒng)分區(qū)中、并改寫客戶端本地的輕量升級版本號。本步驟編寫實現(xiàn)上述功能的升級腳本，例如：updater-script文件，然后在本地文件系統(tǒng)創(chuàng)建與system目錄處于同一層的META-INF目錄、以及該目錄的子目錄com\custom\fota，并將編寫好的升級腳本復(fù)制到該子目錄中。

需要說明的是，如果客戶端執(zhí)行升級腳本中的命令時，需要調(diào)用其它可執(zhí) 行文件或者函數(shù)庫，則可以將這些可執(zhí)行文件或者函數(shù)庫也復(fù)制到與升級腳本相同的目錄中。

步驟101-4、將上述目錄壓縮打包。

將上述包含應(yīng)用程序(及相關(guān)庫文件)的目錄、以及包含升級程序的目錄壓縮打包。例如，可以采用通常使用的zip壓縮工具對上述system目錄以及META-INF目錄進行壓縮，生成輕量升級包update_unsigned.zip，也可以采用如下所示的zip命令進行壓縮打包：

$zip-qry../update_unsigned.zip./

步驟101-5、對壓縮包進行簽名，并將簽名后的壓縮包作為所述輕量升級包。

客戶端設(shè)備通常僅針對其認可的輕量升級包執(zhí)行升級操作，為了便于客戶端對輕量升級包的來源以及安全性進行驗證，可以對已經(jīng)壓縮生成的輕量升級包進行簽名。例如：可以使用簽名工具signapk.jar或者jarsigner進行簽名，生成最終的可發(fā)布給客戶端的輕量升級包update.zip。

至此，通過上述步驟101-1至101-5完成了輕量升級包的制作。需要說明的是，上述步驟是以采用Android系統(tǒng)的客戶端為例，描述輕量升級包的制作過程，在其他實施過程中，可以采用不同的分區(qū)名稱、目錄名稱、壓縮工具、簽名工具等，只要能夠制作本申請所述的輕量升級包、并在客戶端成功升級，就都不偏離本申請的核心，在本申請的保護范圍之內(nèi)。

通過上面的描述可以看出，現(xiàn)有技術(shù)制作全量或者增量升級包需要通過編譯工具、對整個待升級的軟件系統(tǒng)(全量或者增量)執(zhí)行build過程得到可升級安裝的image文件，而本技術(shù)方案僅需要針對與系統(tǒng)耦合程度滿足預(yù)設(shè)要求(無耦合或者耦合程度較低)的待發(fā)布應(yīng)用程序，通過打包壓縮的方式制作輕量升級包即可，簡化升級包的制作過程，而且得到的升級包尺寸較小，可以適配多種客戶端機型，在客戶端升級安裝時，不需要區(qū)分機型、分區(qū)。

在具體實施時，當(dāng)與系統(tǒng)耦合程度滿足預(yù)設(shè)要求的應(yīng)用程序完成開發(fā)、調(diào)試等階段可以發(fā)布時，服務(wù)器端可以采用本步驟制作相應(yīng)的輕量升級包。

為了便于區(qū)分生成的各個輕量升級包，通?？梢詾檩p量升級包指定輕量升級版本號，對于固件版本多樣化、以及設(shè)備型號眾多的應(yīng)用場景，還可以建立輕量升級包與固件版本號以及客戶端設(shè)備型號的對應(yīng)關(guān)系。例如：制作輕量升級包的版本號為20150801.0111，該輕量升級包可以應(yīng)用于多個固件版本，則可 以建立上述輕量升級版本號與所述多個固件版本之間的對應(yīng)關(guān)系；如果該輕量升級包可以在多個客戶端設(shè)備型號中使用，但是在個別機型中受限，則可以將所述輕量升級版本號與可以適用的客戶端設(shè)備型號建立對應(yīng)關(guān)系。從而在后續(xù)的步驟中，可以根據(jù)客戶端上報的信息查找是否存在適合客戶端的輕量升級包。

步驟102、向客戶端發(fā)送輕量升級信息，以供客戶端獲取輕量升級包并執(zhí)行相應(yīng)的升級操作。

制作完輕量升級包后，可以向客戶端發(fā)送輕量升級信息，例如可以通過與客戶端之間的長連接通道，向客戶端推送輕量升級信息，也可以根據(jù)客戶端的升級請求向客戶端發(fā)送輕量升級信息。

在具體實施時，上述兩種發(fā)送輕量升級信息的方式(推送方式、請求/響應(yīng)方式)都是可行的，考慮到后者可以根據(jù)客戶端請求中攜帶的信息選擇適合客戶端安裝的輕量升級包并發(fā)送相關(guān)信息，從而可以保證客戶端執(zhí)行正確的升級操作，因此是一種優(yōu)選實施方式，下面結(jié)合附圖3對該優(yōu)選實施方式作進一步說明，具體包括步驟102-1至102-3。

步驟102-1、接收來自客戶端的升級請求。

所述升級請求中至少攜帶輕量升級版本號，該版本號是客戶端最近一次進行更新所采用的輕量升級版本號?？紤]在固件版本及設(shè)備型號眾多的應(yīng)用場景下，輕量升級包可能無法適用于所有的固件版本，也可能無法適用于所有的設(shè)備型號，來自客戶端的升級請求中還可以包括客戶端固件版本號和/或客戶端設(shè)備型號；此外，為了保證有足夠的空間進行升級，所述升級請求中還可以包括客戶端用于安裝輕量升級包的分區(qū)的剩余容量信息。本步驟從升級請求中獲取上述信息，在步驟102-2中可以綜合考慮客戶端上報的這些信息，選擇可供客戶端安裝的輕量升級包。

步驟102-2、判斷是否存在可供客戶端安裝的輕量升級包，若存在，執(zhí)行步驟102-3，否則向客戶端返回沒有更新應(yīng)答。

可以先根據(jù)客戶端上報的固件版本號和/或設(shè)備型號，查找是否存在與所述固件版本號和/或設(shè)備型號對應(yīng)的輕量升級包；如果找到，再進一步判斷找到的輕量升級包中是否存在其版本號大于客戶端上報的輕量升級版本號的輕量升級包，例如：客戶端上報的輕量升級版本號是20150801.0111，找到的輕量升級包的版本號為20150818.0111，則認為存在版本號大于所述輕量升級版本號的新版 本輕量升級包，該升級包即為可供客戶端安裝的輕量升級包，可以繼續(xù)執(zhí)行步驟102-3。如果不存在同時符合上述兩個條件的輕量升級包，則向客戶端返回沒有更新應(yīng)答。

優(yōu)選地，在找到符合條件的輕量升級包后，在繼續(xù)執(zhí)行步驟102-3之前，可以根據(jù)客戶端上報的分區(qū)剩余容量信息判斷客戶端是否有足夠的空閑分區(qū)安裝所述輕量升級包：如果新版本輕量升級包與客戶端已安裝的輕量升級包的大小的差值大于客戶端上報的分區(qū)剩余容量，則說明客戶端有足夠的空閑分區(qū)，則可以繼續(xù)執(zhí)行步驟102-3，否則向客戶端返回沒有更新應(yīng)答。

需要說明的是，如果客戶端在升級請求中上報的信息僅包括輕量升級版本號，那么本步驟直接查找是否存在其版本號大于所述輕量升級版本號的輕量升級包就可以了，同樣可以實現(xiàn)本申請的技術(shù)方案。

步驟102-3、向客戶端發(fā)送輕量升級信息，以供客戶端獲取輕量升級包并執(zhí)行相應(yīng)的升級操作。

所述輕量升級信息中可以直接包含在步驟102-2中選擇的輕量升級包，也可以包含下載所述輕量升級包的地址信息，從而客戶端可以根據(jù)接收到的輕量升級信息獲取輕量升級包并執(zhí)行相應(yīng)的升級操作。

至此，通過步驟101至步驟102，對本申請?zhí)峁┑囊环N發(fā)布升級包的方法實施例進行了詳細描述。通過描述可以看出，由于本方法沒有采用傳統(tǒng)的制作全量或者增量升級包的方式，而是僅針對與系統(tǒng)無耦合或者耦合比較小的應(yīng)用程序制作輕量升級包、并向客戶端發(fā)送輕量升級信息，即：不必等待整個軟件系統(tǒng)都完成開發(fā)、調(diào)試等任務(wù)后一起發(fā)布，而是單獨發(fā)布針對應(yīng)用程序的輕量升級包，從而滿足了應(yīng)用程序快速變化的需求，實現(xiàn)了應(yīng)用程序的快速更新與發(fā)布。

在上述的實施例中，提供了一種發(fā)布升級包的方法，與之相對應(yīng)的，本申請還提供一種發(fā)布升級包的裝置。請參看圖4，其為本申請的一種發(fā)布升級包的裝置的實施例示意圖。由于裝置實施例基本相似于方法實施例，所以描述得比較簡單，相關(guān)之處參見方法實施例的部分說明即可。下述描述的裝置實施例僅僅是示意性的。

本實施例的一種發(fā)布升級包的裝置，包括：輕量升級包制作單元401，用于針對與系統(tǒng)耦合程度滿足預(yù)設(shè)要求的待發(fā)布應(yīng)用程序，制作輕量升級包；升級 信息發(fā)送單元402，用于向客戶端發(fā)送輕量升級信息，以供客戶端獲取輕量升級包并執(zhí)行相應(yīng)的升級操作。

可選的，所述裝置包括：

升級請求接收單元，用于在觸發(fā)所述升級信息發(fā)送單元之前，接收來自客戶端的升級請求，所述請求中至少攜帶輕量升級版本號；

版本判斷單元，用于判斷是否存在其版本號大于所述輕量升級版本號的輕量升級包；

所述升級信息發(fā)送單元具體用于，向客戶端發(fā)送輕量升級信息，所述輕量升級信息中包含所述輕量升級包的相關(guān)信息。

可選的，所述升級請求接收單元接收到的升級請求中還攜帶用于安裝輕量升級包的分區(qū)的剩余容量信息；

所述裝置還包括：

剩余容量判斷單元，用于當(dāng)所述版本判斷單元的輸出為是時，判斷所述剩余容量是否滿足安裝所述輕量升級包的需求，并且在滿足時觸發(fā)所述升級信息發(fā)送單元工作。

可選的，所述升級請求接收單元接收到的升級請求中還攜帶客戶端上報的以下信息之一或者組合：客戶端固件版本號、客戶端設(shè)備型號；

所述版本判斷單元具體用于，判斷是否存在與上述客戶端上報信息相對應(yīng)的、且其版本號大于所述輕量升級版本號的輕量升級包。

可選的，所述輕量升級包制作單元包括：

目錄結(jié)構(gòu)生成子單元，用于生成與安裝輕量升級包的客戶端分區(qū)相同的目錄結(jié)構(gòu)；

文件復(fù)制子單元，用于將待打包文件復(fù)制到所述目錄結(jié)構(gòu)的相應(yīng)目錄中，所述待打包文件至少包含所述與系統(tǒng)耦合程度滿足預(yù)設(shè)要求的待發(fā)布應(yīng)用程序；

壓縮打包子單元，用于將上述目錄壓縮打包，得到所述輕量升級包。

可選的，所述輕量升級包制作單元還包括：

壓縮包簽名子單元，用于在所述壓縮打包子單元完成壓縮打包操作后，對壓縮包進行簽名，并將簽名后的壓縮包作為所述輕量升級包。

可選的，所述輕量升級包制作單元還包括：

升級程序復(fù)制子單元，用于在觸發(fā)所述壓縮打包子單元之前，編寫用于在客戶端執(zhí)行升級操作的升級程序，并將所述升級程序復(fù)制到與客戶端預(yù)先約定的目錄結(jié)構(gòu)中；

所述壓縮打包子單元具體用于，將包含待打包文件的目錄、以及包含升級程序的目錄壓縮打包。

可選的，所述升級信息發(fā)送單元發(fā)送的輕量升級信息包括：用于獲取所述輕量升級包的地址信息。

此外，本申請還提供一種輕量升級方法，所述方法通常在利用升級包進行固件升級更新的客戶端實施。請參考圖5，其為本申請?zhí)峁┑囊环N輕量升級方法的實施例的流程圖，本實施例與上述方法實施例步驟相同的部分不再贅述，下面重點描述不同之處。本申請?zhí)峁┑囊环N輕量升級方法包括：

步驟501、接收服務(wù)器端發(fā)送的輕量升級信息，并獲取輕量升級包。

所述輕量升級包是由服務(wù)器端針對與系統(tǒng)耦合程度滿足預(yù)設(shè)要求的應(yīng)用程序打包生成的，相關(guān)說明請參見之前提供的一種發(fā)布升級包的方法實施例中的文字，此處不再贅述。

作為一種簡便易行的實施方式，服務(wù)器端在制作好輕量升級包后，可以直接將輕量升級信息推送給客戶端，客戶端可以根據(jù)接收到的輕量升級信息獲取輕量升級包。

在具體實施時，客戶端也可以采用請求/響應(yīng)方式來獲取輕量升級信息，下面結(jié)合附圖6對這種實施方式作進一描述，具體包括步驟501-1至501-5。

步驟501-1、獲取本地的輕量升級版本號、固件版本號、設(shè)備型號。

本步驟獲取客戶端設(shè)備的基本信息，包括：輕量升級版本號、固件版本號和設(shè)備型號。在具體實施時，可以采用系統(tǒng)提供的接口函數(shù)獲取上述信息，例如在采用Android系統(tǒng)的客戶端設(shè)備中，可以通過getprop()函數(shù)或者類似接口讀取設(shè)備的屬性信息，從而獲取上述各信息。

步驟501-2、計算用于安裝輕量升級包的預(yù)設(shè)分區(qū)的剩余容量。

輕量升級包的安裝過程，是對通過系統(tǒng)方式(例如全量升級或者增量升級) 安裝的應(yīng)用程序所在的分區(qū)(即本申請所述的預(yù)設(shè)分區(qū))中的信息進行替換更新的過程。為了保證能夠正確地完成升級操作，并且不會影響其他分區(qū)中的原有信息，可以計算所述預(yù)設(shè)分區(qū)的剩余容量并在后續(xù)步驟501-3中上報給服務(wù)器端，以供服務(wù)器端做出相應(yīng)的判斷。在具體實施時，通?？梢酝ㄟ^客戶端所采用的系統(tǒng)或者平臺提供的接口獲取所述預(yù)設(shè)分區(qū)的相關(guān)信息并進一步計算得到剩余容量。

以采用Android系統(tǒng)的智能手機為例，通常有以下分區(qū)：preload、userdata、cache、boot、system、recovery等，其中用于安裝輕量升級包中的應(yīng)用程序以及相關(guān)庫文件的通常是system分區(qū)，即系統(tǒng)分區(qū)。通過Android系統(tǒng)提供的StatFs類可以獲取文件系統(tǒng)的狀態(tài)，因此本步驟可以通過StatFs類中的函數(shù)獲取system分區(qū)的空閑數(shù)據(jù)塊的數(shù)目、及數(shù)據(jù)塊大小，從而計算得到空閑空間的大小，即所述剩余容量信息。

步驟501-3、向服務(wù)器端發(fā)送升級請求，所述請求中攜帶上述各信息。

向負責(zé)提供輕量升級信息的服務(wù)器端發(fā)送升級請求，所述請求中至少攜帶輕量升級版本號。此外，也可以攜帶固件版本號、設(shè)備型號、以及用于安裝輕量升級包的預(yù)設(shè)分區(qū)的剩余容量信息。

如果輕量升級包可以適用于各種固件版本，那么可以不獲取自身的固件版本號，在升級請求中也可以不攜帶該信息(服務(wù)器端不用進行篩選)；同樣的道理，如果輕量升級包可以適用于各種設(shè)備型號，那么可以不獲取自身的設(shè)備型號，在升級請求中也可以不攜帶該信息。如果客戶端預(yù)設(shè)分區(qū)的容量足夠大、或者檢查預(yù)設(shè)分區(qū)的剩余容量是否充足的功能由客戶端在升級之前自行完成，那么也可以不將所述剩余容量信息上報給服務(wù)器端。這些都是實施方式的具體變更方式，都不偏離本申請的核心，都在本申請的保護范圍之內(nèi)。

步驟501-4、接收服務(wù)器端返回的輕量升級信息，并獲取輕量升級包。

如果服務(wù)器端返回的輕量升級信息中包含輕量升級包，那么直接從中讀取輕量升級包即可；如果服務(wù)器端返回的輕量升級信息中包含獲取輕量升級包的地址信息，那么本步驟可以根據(jù)所述地址信息下載所述輕量升級包。

具體實施時，服務(wù)器端也可能返回沒有更新應(yīng)答(例如，因為所述預(yù)設(shè)分區(qū)的剩余容量不足，因此無法進行升級)，在這種情況下，則不用繼續(xù)執(zhí)行后續(xù)步驟502。

步驟502、將所述輕量升級包安裝到預(yù)設(shè)分區(qū)中。

將在步驟501中獲取的輕量升級包安裝到預(yù)設(shè)分區(qū)中，可以先檢查一下簽名信息是否正確，例如可以使用jarsigner工具進行驗證，若通過驗證，則執(zhí)行后續(xù)的升級操作，具體包括步驟502-1至步驟502-3，下面結(jié)合附圖7進行說明。

步驟502-1、解壓縮所述輕量升級包。

所述輕量升級包通常采用壓縮包格式，可以采用與服務(wù)器端所采用的壓縮工具對應(yīng)的解壓縮工具，將輕量升級包展開為原有的目錄結(jié)構(gòu)。

步驟502-2、將輕量升級包中的應(yīng)用程序及相關(guān)庫文件復(fù)制到所述預(yù)設(shè)分區(qū)的相應(yīng)目錄中。

仍以采用Android系統(tǒng)的客戶端設(shè)備為例，可以將輕量升級包中system/app目錄下的應(yīng)用程序復(fù)制到系統(tǒng)分區(qū)的app目錄下，將system/framework目錄下的jar包文件復(fù)制到系統(tǒng)分區(qū)的framework目錄下。

步驟502-3、更新本地的輕量升級版本號。

完成上述復(fù)制操作后，可以更新本地的輕量升級版本號，例如，對于采用Android系統(tǒng)的客戶端設(shè)備，可以調(diào)用setprop()函數(shù)或者類似接口，將本地存儲的設(shè)備屬性信息中的輕量升級版本號更新為步驟501獲取的輕量升級包的版本號。

在具體實施時，如果輕量升級包中提供了升級程序(例如升級腳本updater-script文件)，那么上述步驟502-2與502-3完成的功能，通?？梢酝ㄟ^執(zhí)行所述升級程序來完成。

至此，通過步驟501至步驟502，對本申請?zhí)峁┑妮p量升級方法的實施例進行了描述。通過上述描述可以看出，由于輕量升級包是針對應(yīng)用程序的快速發(fā)布方式，客戶端通過獲取輕量升級包并執(zhí)行相應(yīng)的升級操作，可以縮短客戶端使用者獲取及使用新版本應(yīng)用程序的等待周期，提升使用體驗。而且由于輕量升級包可以適配多種設(shè)備型號、而且通常僅針對預(yù)設(shè)分區(qū)進行更新，因此在客戶端的升級過程中不用區(qū)分機型、分區(qū)，可以簡化操作、提高執(zhí)行效率。

在上述的實施例中，提供了一種輕量升級方法，與之相對應(yīng)的，本申請還提供一種輕量升級裝置。請參看圖8，其為本申請的一種輕量升級裝置的實施例示意圖。由于裝置實施例基本相似于方法實施例，所以描述得比較簡單，相關(guān)之處參見方法實施例的部分說明即可。下述描述的裝置實施例僅僅是示意性的。

本實施例的一種輕量升級裝置，包括：輕量升級包獲取單元801，用于接收服務(wù)器端發(fā)送的輕量升級信息，并獲取輕量升級包，其中，所述輕量升級包是由服務(wù)器端針對與系統(tǒng)耦合程度滿足預(yù)設(shè)要求的應(yīng)用程序打包生成的；輕量升級包安裝單元802，用于將所述輕量升級包安裝到預(yù)設(shè)分區(qū)中。

可選的，所述裝置包括：

輕量版本號獲取單元，用于在所述輕量升級包獲取單元工作之前，獲取本地的輕量升級版本號；

升級請求發(fā)送單元，用于向服務(wù)器端發(fā)送升級請求，所述升級請求中至少攜帶所述輕量升級版本號。

可選的，所述裝置還包括：

設(shè)備信息獲取單元，用于在觸發(fā)所述升級請求發(fā)送單元工作之前，獲取以下信息之一或者組合：固件版本號、設(shè)備型號；

所述升級請求發(fā)送單元發(fā)送的升級請求中不僅攜帶輕量升級版本號，還攜帶所述設(shè)備信息獲取單元獲取的上述信息。

可選的，所述輕量版本號獲取單元和所述設(shè)備信息獲取單元具體用于，通過讀取系統(tǒng)屬性獲取所需信息。

可選的，所述裝置還包括：

剩余容量計算單元，用于在觸發(fā)所述升級請求發(fā)送單元工作之前，計算所述預(yù)設(shè)分區(qū)的剩余容量；

所述升級請求發(fā)送單元發(fā)送的升級請求中不僅攜帶輕量升級版本號，還攜帶所述剩余容量信息。

可選的，所述輕量升級包獲取單元接收的輕量升級信息中包含：用于獲取所述輕量升級包的地址信息；

所述輕量升級包獲取單元具體用于，接收服務(wù)器端發(fā)送的輕量升級信息，并根據(jù)其中的地址信息下載輕量升級包。

可選的，所述輕量升級包安裝單元包括：

解壓縮子單元，用于解壓縮所述輕量升級包；

文件復(fù)制安裝子單元，用于將輕量升級包中的應(yīng)用程序及相關(guān)庫文件復(fù)制到所述預(yù)設(shè)分區(qū)的相應(yīng)目錄中；

版本號更新子單元，用于更新本地的輕量升級版本號。

此外，本申請還提供一種輕量升級系統(tǒng)，如圖9所示，該系統(tǒng)包括上述實施例所述的發(fā)布升級包的裝置901和輕量升級裝置902。所述輕量升級裝置可以部署于智能手機、平板電腦等多種客戶端設(shè)備；所述發(fā)布升級包的裝置通常部署于負責(zé)向客戶端發(fā)布升級包的服務(wù)器，但并不局限于服務(wù)器，也可以是能夠?qū)崿F(xiàn)本申請所述的發(fā)布升級包的方法的任何設(shè)備。

例如，輕量升級裝置部署于智能手機上，發(fā)布升級包的裝置部署于服務(wù)器上。所述服務(wù)器針對與系統(tǒng)耦合程度滿足預(yù)設(shè)要求的待發(fā)布應(yīng)用程序，制作輕量升級包，并根據(jù)客戶端的升級請求向客戶端發(fā)送獲取相應(yīng)輕量升級包的地址信息，客戶端根據(jù)所述地址信息下載輕量升級包、并安裝到預(yù)設(shè)分區(qū)中，從而實現(xiàn)了應(yīng)用程序的快速更新與發(fā)布。

上述例子僅僅是示意性的，在其他的實施方式中，也可以采用不同的部署方式和實施方式，只要能夠?qū)崿F(xiàn)本申請所述的輕量升級系統(tǒng)的整體功能，就都在本申請的保護范圍之內(nèi)。

此外，本申請還提供一種制作輕量升級包的方法。請參考圖10，其為本申請?zhí)峁┑闹谱鬏p量升級包的方法實施例的流程圖，本實施例與上述兩個方法實施例步驟相同的部分不再贅述，下面重點描述不同之處。本申請?zhí)峁┑闹谱鬏p量升級包的方法包括：

步驟1001、生成與安裝輕量升級包的客戶端分區(qū)相同的目錄結(jié)構(gòu)。

步驟1002、將與系統(tǒng)耦合程度滿足預(yù)設(shè)要求的待發(fā)布應(yīng)用程序復(fù)制到所述目錄結(jié)構(gòu)的相應(yīng)目錄中。

如果滿足所述預(yù)設(shè)要求的待發(fā)布應(yīng)用程序使用自定義庫文件，還可以將所述自定義庫文件復(fù)制到所述目錄結(jié)構(gòu)的相應(yīng)目錄中。

步驟1003、將上述目錄壓縮打包，得到所述輕量升級包。

在上述的實施例中，提供了一種制作輕量升級包的方法，與之相對應(yīng)的，本申請還提供一種制作輕量升級包的裝置。請參看圖11，其為本申請的一種制作輕量升級包的裝置實施例示意圖。由于裝置實施例基本相似于方法實施例，所以描述得比較簡單，相關(guān)之處參見方法實施例的部分說明即可。下述描述的 裝置實施例僅僅是示意性的。

本實施例的一種制作輕量升級包的裝置，包括：目錄創(chuàng)建單元1101，用于生成與安裝輕量升級包的客戶端分區(qū)相同的目錄結(jié)構(gòu)；文件復(fù)制單元1102，用于將與系統(tǒng)耦合程度滿足預(yù)設(shè)要求的待發(fā)布應(yīng)用程序復(fù)制到所述目錄結(jié)構(gòu)的相應(yīng)目錄中；壓縮打包單元1103，用于將上述目錄壓縮打包，得到所述輕量升級包。

本申請雖然以較佳實施例公開如上，但其并不是用來限定本申請，任何本領(lǐng)域技術(shù)人員在不脫離本申請的精神和范圍內(nèi)，都可以做出可能的變動和修改，因此本申請的保護范圍應(yīng)當(dāng)以本申請權(quán)利要求所界定的范圍為準(zhǔn)。

在一個典型的配置中，計算設(shè)備包括一個或多個處理器(CPU)、輸入/輸出接口、網(wǎng)絡(luò)接口和內(nèi)存。

內(nèi)存可能包括計算機可讀介質(zhì)中的非永久性存儲器，隨機存取存儲器(RAM)和/或非易失性內(nèi)存等形式，如只讀存儲器(ROM)或閃存(flash RAM)。內(nèi)存是計算機可讀介質(zhì)的示例。

1、計算機可讀介質(zhì)包括永久性和非永久性、可移動和非可移動媒體可以由任何方法或技術(shù)來實現(xiàn)信息存儲。信息可以是計算機可讀指令、數(shù)據(jù)結(jié)構(gòu)、程序的模塊或其他數(shù)據(jù)。計算機的存儲介質(zhì)的例子包括，但不限于相變內(nèi)存(PRAM)、靜態(tài)隨機存取存儲器(SRAM)、動態(tài)隨機存取存儲器(DRAM)、其他類型的隨機存取存儲器(RAM)、只讀存儲器(ROM)、電可擦除可編程只讀存儲器(EEPROM)、快閃記憶體或其他內(nèi)存技術(shù)、只讀光盤只讀存儲器(CD-ROM)、數(shù)字多功能光盤(DVD)或其他光學(xué)存儲、磁盒式磁帶，磁帶磁磁盤存儲或其他磁性存儲設(shè)備或任何其他非傳輸介質(zhì)，可用于存儲可以被計算設(shè)備訪問的信息。按照本文中的界定，計算機可讀介質(zhì)不包括非暫存電腦可讀媒體(transitory media)，如調(diào)制的數(shù)據(jù)信號和載波。

2、本領(lǐng)域技術(shù)人員應(yīng)明白，本申請的實施例可提供為方法、系統(tǒng)或計算機程序產(chǎn)品。因此，本申請可采用完全硬件實施例、完全軟件實施例或結(jié)合軟件和硬件方面的實施例的形式。而且，本申請可采用在一個或多個其中包含有計算機可用程序代碼的計算機可用存儲介質(zhì)(包括但不限于磁盤存儲器、CD-ROM、光學(xué)存儲器等)上實施的計算機程序產(chǎn)品的形式。