本發(fā)明屬于計算機技術領域，尤其涉及一種操作系統(tǒng)的空間下載技術(Over-the-Air Technology，OTA)升級方法及裝置。

背景技術：

對Android系統(tǒng)來說，其對應著多個系統(tǒng)分區(qū)，包括system、boot、recovery、cache、data等原生分區(qū)，同時，還存在著一些自定義的擴展分區(qū)，這些不同分區(qū)有的用來存儲操作系統(tǒng)程序，有的用來存儲用戶數(shù)據(jù)，有的用來實現(xiàn)操作系統(tǒng)的某些特殊功能。目前，隨著應用體積的增大，可能出現(xiàn)某個分區(qū)的可用空間已無法允許安裝新的應用，需要增大分區(qū)的情況。例如一個EMMC(Embedded Multi Media Card)芯片的存儲空間被劃分為N段，每一段對應一個分區(qū)，若需要將分區(qū)2從8M擴展到10M，那么分區(qū)1無需變化，分區(qū)3的位置肯定要發(fā)生改變，而其他分區(qū)的位置也有可能發(fā)生改變，至少要保證從其他分區(qū)中減少2M的存儲空間，以劃分給分區(qū)2，才能保證芯片的整體存儲空間大小不變。

目前，若要對Android系統(tǒng)進行OTA升級，其前提是新版本系統(tǒng)的系統(tǒng)分區(qū)(包括分區(qū)的名稱、大小、節(jié)點等信息)無修改，但如前文所述，在實際的操作系統(tǒng)版本升級過程中，會出現(xiàn)對現(xiàn)有分區(qū)進行修改、調整的情況，現(xiàn)有的OTA升級方法則無法適用于該情況，導致Android系統(tǒng)的OTA升級不成功。

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

本發(fā)明實施例的目的在于提供一種操作系統(tǒng)的OTA升級方法及裝置，旨在解決現(xiàn)有的操作系統(tǒng)OTA升級方法無法適用于系統(tǒng)分區(qū)已修改的情況，導致OTA升級不成功的問題。

本發(fā)明實施例是這樣實現(xiàn)的，一種操作系統(tǒng)的空間下載技術OTA升級方法，包括：

獲取OTA升級包中的第一分區(qū)表，所述第一分區(qū)表用于存放對應版本的操作系統(tǒng)的分區(qū)參數(shù)，所述分區(qū)參數(shù)包括分區(qū)名稱、對應的驅動設備節(jié)點及分區(qū)大??；

將所述第一分區(qū)表與終端的第二分區(qū)表進行比較；

判斷兩個分區(qū)表中的recovery分區(qū)是否一致；若兩個分區(qū)表中的recovery分區(qū)不一致，則退出升級；若兩個分區(qū)表中的recovery分區(qū)一致，則判斷兩個分區(qū)表中的剩余分區(qū)是否一致；

若所述兩個分區(qū)表中的剩余分區(qū)的比較結果不一致，則從所述OTA升級包中讀取recovery.img文件，將recovery.img文件刷入recovery分區(qū)中，然后傳入升級指令，并重啟所述終端，進入recovery系統(tǒng)，將所述OTA升級包內包含的所有分區(qū)進行升級操作；

若所述兩個分區(qū)表中的剩余分區(qū)的比較結果一致，則直接傳入升級指令，并重啟所述終端，進入recovery系統(tǒng)，將所述OTA升級包內包含的所有分區(qū)進行升級操作。

本發(fā)明實施例的另一目的在于提供一種操作系統(tǒng)的空間下載技術OTA升級裝置，包括：

獲取單元，用于獲取OTA升級包中的第一分區(qū)表，所述第一分區(qū)表用于存放對應版本的操作系統(tǒng)的分區(qū)參數(shù)，所述分區(qū)參數(shù)包括分區(qū)名稱、對應的驅動設備節(jié)點及分區(qū)大??；

比較單元，用于將所述第一分區(qū)表與終端的第二分區(qū)表進行比較；

判斷單元，用于判斷兩個分區(qū)表中的recovery分區(qū)是否一致；

處理單元，用于若兩個分區(qū)表中的recovery分區(qū)不一致，則退出升級；若兩個分區(qū)表中的recovery分區(qū)一致，則判斷兩個分區(qū)表中的剩余分區(qū)是否一致；

第一升級單元，用于若所述兩個分區(qū)表中的剩余分區(qū)的比較結果不一致， 則從所述OTA升級包中讀取recovery.img文件，將recovery.img文件刷入recovery分區(qū)中，然后傳入升級指令，并重啟所述終端，進入recovery系統(tǒng)，將所述OTA升級包內包含的所有分區(qū)進行升級操作；

第二升級單元，用于若所述兩個分區(qū)表中的剩余分區(qū)的比較結果一致，則直接傳入升級指令，并重啟所述終端，進入recovery系統(tǒng)，將所述OTA升級包內包含的所有分區(qū)進行升級操作。

通過本發(fā)明實施例所示方案，使得在升級后的操作系統(tǒng)對系統(tǒng)分區(qū)有調整時，仍然能夠利用OTA完成操作系統(tǒng)升級，避免了分區(qū)調整對操作系統(tǒng)升級過程所帶來的影響，保證了操作系統(tǒng)的升級效率。

附圖說明

為了更清楚地說明本發(fā)明實施例中的技術方案，下面將對實施例或現(xiàn)有技術描述中所需要使用的附圖作簡單地介紹，顯而易見地，下面描述中的附圖僅僅是本發(fā)明的一些實施例，對于本領域普通技術人員來講，在不付出創(chuàng)造性勞動性的前提下，還可以根據(jù)這些附圖獲得其他的附圖。

圖1是本發(fā)明實施例一提供的操作系統(tǒng)的OTA升級方法的實現(xiàn)流程圖；

圖2是本發(fā)明實施例四提供的操作系統(tǒng)的OTA升級裝置的結構框圖。

具體實施方式

以下描述中，為了說明而不是為了限定，提出了諸如特定系統(tǒng)結構、技術之類的具體細節(jié)，以便透切理解本發(fā)明實施例。然而，本領域的技術人員應當清楚，在沒有這些具體細節(jié)的其它實施例中也可以實現(xiàn)本發(fā)明。在其它情況中，省略對眾所周知的系統(tǒng)、裝置、電路以及方法的詳細說明，以免不必要的細節(jié)妨礙本發(fā)明的描述。

在本發(fā)明實施例中，所述操作系統(tǒng)，可以為適用于本方案的移動終端的智能操作系統(tǒng)，包括但不限于Android、iOS、Symbian、Windows Phone和BlackBerry OS等，以下實施例僅以Android系統(tǒng)為例進行說明，其他智能操作系統(tǒng)只要能夠支持本方案實現(xiàn)的，均可以按相同或相似原理實現(xiàn)本方案，在此不一一贅述。

為了說明本發(fā)明所述的技術方案，下面通過具體實施例來進行說明。

實施例一：

圖1示出了本發(fā)明實施例一提供的操作系統(tǒng)的OTA升級方法的實現(xiàn)流程，詳述如下：

在步驟S101中，獲取OTA升級包中的第一分區(qū)表，所述第一分區(qū)表用于存放對應版本的操作系統(tǒng)的分區(qū)參數(shù)，所述分區(qū)參數(shù)包括分區(qū)名稱、對應的驅動設備節(jié)點及分區(qū)大小。

OTA升級包由操作系統(tǒng)的升級服務器提供，需要進行系統(tǒng)升級的終端設備可以通過升級應用從升級服務器中下載OTA升級包到本地。所述分區(qū)表專門用于存儲其對應版本的操作系統(tǒng)的分區(qū)參數(shù)，其中，分區(qū)參數(shù)至少包括了分區(qū)名稱、對應的驅動設備節(jié)點及分區(qū)大小，例如：

/recovery/dev/block/mmcblk0p12000000，代表Android系統(tǒng)中的recovery分區(qū)對應的驅動設備節(jié)點是/dev/block/mmcblk0p1，其為第1個分區(qū)，對應的分區(qū)大小是2000000字節(jié)；

/system/dev/block/mmcblk0p3800000000，代表Android系統(tǒng)中的system分區(qū)對應的驅動設備節(jié)點是/dev/block/mmcblk0p3，其為第3個分區(qū)，對應的分區(qū)大小是800000000字節(jié)。

在本實施例中，對于第一分區(qū)表來說，其存儲的是OTA升級包對應的升級后的操作系統(tǒng)的分區(qū)參數(shù)。

在步驟S102中，將所述第一分區(qū)表與終端的第二分區(qū)表進行比較。

所述第二分區(qū)表，其存儲的是終端設備當前版本的操作系統(tǒng)(即未升級版本的操作系統(tǒng))的分區(qū)參數(shù)。

通過將第一分區(qū)表與第二分區(qū)表進行比較，若此次系統(tǒng)升級未對系統(tǒng)分區(qū)進行調整，那么第一分區(qū)表與第二分區(qū)表的數(shù)據(jù)是一致的，若第一分區(qū)表與第 二分區(qū)表的比較結果不一致，則表明此次系統(tǒng)升級對系統(tǒng)分區(qū)進行了調整。

在步驟S103中，判斷兩個分區(qū)表中的recovery分區(qū)是否一致。

在步驟S104中，若兩個分區(qū)表中的recovery分區(qū)不一致，則退出升級；若兩個分區(qū)表中的recovery分區(qū)一致，則判斷兩個分區(qū)表中的剩余分區(qū)是否一致。

基于步驟S102的比較結果，首先，判斷兩個分區(qū)表中的recovery分區(qū)是否一致。

由于本發(fā)明實施例后續(xù)升級方案能夠成功進行的前提，在于操作系統(tǒng)的recovery分區(qū)在升級前后未修改(包括recovery分區(qū)的分區(qū)名稱、大小、節(jié)點等分區(qū)信息均未發(fā)生改變)，因此，若判斷出第一分區(qū)表與第二分區(qū)表中關于recovery分區(qū)的分區(qū)信息不一致，后續(xù)升級方案則無法成功進行，那么，直接終止并退出升級過程。若第一分區(qū)表與第二分區(qū)表中關于recovery分區(qū)的分區(qū)信息一致，則繼續(xù)執(zhí)行后續(xù)方案，檢測兩個分區(qū)表中除recovery分區(qū)之外的剩余分區(qū)是否一致。

在步驟S105中，若所述兩個分區(qū)表中的剩余分區(qū)的比較結果不一致，則從所述OTA升級包中讀取recovery.img文件，將recovery.img文件刷入recovery分區(qū)中，然后傳入升級指令，并重啟所述終端，進入recovery系統(tǒng)，將OTA升級包內包含的所有分區(qū)進行升級操作。

在S106中，若所述兩個分區(qū)表中的剩余分區(qū)的比較結果一致，則直接傳入升級指令，并重啟所述終端，進入recovery系統(tǒng)，將所述OTA升級包內包含的所有分區(qū)進行升級操作。

一旦recovery.img文件刷入recovery分區(qū)中，則可以傳入升級指令并重啟終端，然后進入到recovery系統(tǒng)中去，recovery系統(tǒng)的kernel層根據(jù)新的分區(qū)情況去生成新的驅動設備節(jié)點，運行升級程序，將OTA升級包內的數(shù)據(jù)依次寫入到新劃分的各個分區(qū)中，并在完成之后重啟進入操作系統(tǒng)，從而完成操作系統(tǒng)的升級過程。

通過本發(fā)明實施例一所示方案，使得在升級后的操作系統(tǒng)對系統(tǒng)分區(qū)有調整時，仍然能夠利用OTA完成操作系統(tǒng)升級，避免了分區(qū)調整對操作系統(tǒng)升級過程所帶來的影響，保證了操作系統(tǒng)的升級效率。

實施例二：

本實施例與本發(fā)明實施例一大致相同，區(qū)別在于步驟S105進一步包括：將所述第一分區(qū)表的數(shù)據(jù)更新至所述第二分區(qū)表中。

在本實施例中，當完成系統(tǒng)升級過程之后，對終端設備本地存儲的第二分區(qū)表進行更新，以保證當下一次進行操作系統(tǒng)升級時，可以將終端設備本地實際的分區(qū)情況與升級版本的操作系統(tǒng)的分區(qū)情況進行比較，保證分區(qū)情況比較結果的準確性。

具體地，可以通過如下方式實現(xiàn)：

在制作升級包時，將第一分區(qū)表存放在系統(tǒng)分區(qū)(以下簡稱system分區(qū))的指定路徑中，例如，存放在ststem/etc目錄之下，那么在升級過程中，升級包內的數(shù)據(jù)會依次寫入到各個分區(qū)，則第一分區(qū)表就會被存儲在終端設備本地對應的指定路徑中，從而完成本地存放的第二分區(qū)表的更新過程。

實施例三：

本實施例在本發(fā)明實施例一的基礎上，增加了對recovery分區(qū)相關的分區(qū)參數(shù)的限定步驟，在步驟S101之前進一步包括以下步驟：設定所述第一分區(qū)表中recovery分區(qū)的驅動設備節(jié)點及分區(qū)大小始終固定不變。

在本發(fā)明前述實施例中，在對第一分區(qū)表和第二分區(qū)表的比較過程中，首先可以比較二者關于recovery分區(qū)的相關分區(qū)參數(shù)是否發(fā)生了變化，若recovery分區(qū)也發(fā)生了變化，則OTA升級方法也不再適用，會直接退出升級過程。在本實施例中，可以設定無論操作系統(tǒng)如何升級，recovery分區(qū)相關的分區(qū)參數(shù)始終固定不變，以保證OTA升級方法的順利執(zhí)行。

將recovery分區(qū)始終設置為操作系統(tǒng)的第一個分區(qū)且分區(qū)大小不變，這樣無論實際的系統(tǒng)分區(qū)需求如何變化，升級過程中對其他分區(qū)怎樣調整，都不會影響到recovery分區(qū)的分區(qū)參數(shù)。且由于recovery分區(qū)是專門用于操作系統(tǒng)升級的最小系統(tǒng)，功能單一，自身有變化的可能性也較小，因此，通過本實施例的方案限制，并不會對整個操作系統(tǒng)升級方案產生較大的影響。

實施例四：

對應于上文實施例所述的操作系統(tǒng)的OTA升級方法，圖2示出了本發(fā)明操作系統(tǒng)的OTA升級裝置的結構框圖，所述操作系統(tǒng)的OTA升級裝置可以是內置于智能終端設備或智能終端設備的操作系統(tǒng)內的軟件單元、硬件單元或者是軟硬結合的單元。為了便于說明，僅示出了與本實施例相關的部分。

參照圖2，該裝置包括：

獲取單元21，獲取OTA升級包中的第一分區(qū)表，所述第一分區(qū)表用于存放對應版本的操作系統(tǒng)的分區(qū)參數(shù)，所述分區(qū)參數(shù)包括分區(qū)名稱、對應的驅動設備節(jié)點及分區(qū)大??；

比較單元22，將所述第一分區(qū)表與終端的第二分區(qū)表進行比較；

判斷單元23，判斷兩個分區(qū)表中的recovery分區(qū)是否一致；

處理單元24，若兩個分區(qū)表中的recovery分區(qū)不一致，則退出升級；若兩個分區(qū)表中的recovery分區(qū)一致，則判斷兩個分區(qū)表中的剩余分區(qū)是否一致；

第一升級單元25，若所述兩個分區(qū)表中的剩余分區(qū)的比較結果不一致，則從所述OTA升級包中讀取recovery.img文件，將recovery.img文件刷入recovery分區(qū)中，然后傳入升級指令，并重啟所述終端，進入recovery系統(tǒng)，將所述OTA升級包內包含的所有分區(qū)進行升級操作；

第二升級單元26，若所述兩個分區(qū)表中的剩余分區(qū)的比較結果一致，則直接傳入升級指令，并重啟所述終端，進入recovery系統(tǒng)，將所述OTA升級包內包含的所有分區(qū)進行升級操作。

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

更新單元，將所述第一分區(qū)表的數(shù)據(jù)更新至所述第二分區(qū)表中。

可選地，所述更新單元具體用于：

將所述第一分區(qū)表寫入所述操作系統(tǒng)的系統(tǒng)分區(qū)的指定路徑，以作為更新后的所述第二分區(qū)表存儲。

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

設定單元，設定所述第一分區(qū)表中recovery分區(qū)的驅動設備節(jié)點及分區(qū)大小始終固定不變。

可選地，所述設定單元具體用于：

設定所述第一分區(qū)表中recovery分區(qū)為所述操作系統(tǒng)的第一個分區(qū)，且設定該recovery分區(qū)的分區(qū)大小固定不變。

所屬領域的技術人員可以清楚地了解到，為了描述的方便和簡潔，僅以上述各功能單元、模塊的劃分進行舉例說明，實際應用中，可以根據(jù)需要而將上述功能分配由不同的功能單元、模塊完成，即將所述裝置的內部結構劃分成不同的功能單元或模塊，以完成以上描述的全部或者部分功能。實施例中的各功能單元、模塊可以集成在一個處理單元中，也可以是各個單元單獨物理存在，也可以兩個或兩個以上單元集成在一個單元中，上述集成的單元既可以采用硬件的形式實現(xiàn)，也可以采用軟件功能單元的形式實現(xiàn)。另外，各功能單元、模塊的具體名稱也只是為了便于相互區(qū)分，并不用于限制本申請的保護范圍。上述系統(tǒng)中單元、模塊的具體工作過程，可以參考前述方法實施例中的對應過程，在此不再贅述。

本領域普通技術人員可以意識到，結合本文中所公開的實施例描述的各示例的單元及算法步驟，能夠以電子硬件、或者計算機軟件和電子硬件的結合來實現(xiàn)。這些功能究竟以硬件還是軟件方式來執(zhí)行，取決于技術方案的特定應用和設計約束條件。專業(yè)技術人員可以對每個特定的應用來使用不同方法來實現(xiàn)所描述的功能，但是這種實現(xiàn)不應認為超出本發(fā)明的范圍。

在本發(fā)明所提供的實施例中，應該理解到，所揭露的裝置和方法，可以通過其它的方式實現(xiàn)。例如，以上所描述的系統(tǒng)實施例僅僅是示意性的，例如，所述模塊或單元的劃分，僅僅為一種邏輯功能劃分，實際實現(xiàn)時可以有另外的劃分方式，例如多個單元或組件可以結合或者可以集成到另一個系統(tǒng)，或一些特征可以忽略，或不執(zhí)行。另一點，所顯示或討論的相互之間的耦合或直接耦合或通訊連接可以是通過一些接口，裝置或單元的間接耦合或通訊連接，可以是電性，機械或其它的形式。

所述作為分離部件說明的單元可以是或者也可以不是物理上分開的，作為單元顯示的部件可以是或者也可以不是物理單元，即可以位于一個地方，或者也可以分布到多個網絡單元上?？梢愿鶕?jù)實際的需要選擇其中的部分或者全部單元來實現(xiàn)本實施例方案的目的。

另外，在本發(fā)明各個實施例中的各功能單元可以集成在一個處理單元中，也可以是各個單元單獨物理存在，也可以兩個或兩個以上單元集成在一個單元中。上述集成的單元既可以采用硬件的形式實現(xiàn)，也可以采用軟件功能單元的形式實現(xiàn)。

所述集成的單元如果以軟件功能單元的形式實現(xiàn)并作為獨立的產品銷售或使用時，可以存儲在一個計算機可讀取存儲介質中?；谶@樣的理解，本發(fā)明實施例的技術方案本質上或者說對現(xiàn)有技術做出貢獻的部分或者該技術方案的全部或部分可以以軟件產品的形式體現(xiàn)出來，該計算機軟件產品存儲在一個存儲介質中，包括若干指令用以使得一臺計算機設備(可以是個人計算機，服務器，或者網絡設備等)或處理器(processor)執(zhí)行本發(fā)明實施例各個實施例所述方法的全部或部分步驟。而前述的存儲介質包括：U盤、移動硬盤、只讀存儲器(ROM，Read-Only Memory)、隨機存取存儲器(RAM，Random Access Memory)、磁碟或者光盤等各種可以存儲程序代碼的介質。

以上所述實施例僅用以說明本發(fā)明的技術方案，而非對其限制；盡管參照前述實施例對本發(fā)明進行了詳細的說明，本領域的普通技術人員應當理解：其 依然可以對前述各實施例所記載的技術方案進行修改，或者對其中部分技術特征進行等同替換；而這些修改或者替換，并不使相應技術方案的本質脫離本發(fā)明實施例各實施例技術方案的精神和范圍。

以上所述僅為本發(fā)明的較佳實施例而已，并不用以限制本發(fā)明，凡在本發(fā)明的精神和原則之內所作的任何修改、等同替換和改進等，均應包含在本發(fā)明的保護范圍之內。