CN105573780B - 一种基于容器的移动终端操作系统升级方法和装置 - Google Patents

Abstract

本申请公开了一种基于容器的移动终端操作系统升级方法，其中两个以上操作系统分别在不同容器中运行，该方法包括：将具有获取更新进程的操作系统切换到前台，及将其余操作系统切换到后台；从服务器下载前台和后台操作系统的增量升级包；在用户确认升级时重启系统进入recovery模式；对所述升级包进行解密并验证所述升级包的签名是否合法；在签名合法时将前台操作系统的系统分区挂载到保存前台操作系统升级文件的目录，及将后台操作系统的系统分区挂载到保存后台操作系统升级文件的目录；对升级文件分别进行校验；及用bspatch和升级包中的补丁文件对待升级文件进行更新。本发明可实现一次升级两个操作系统，且仅需重启一次机器。

Description

一种基于容器的移动终端操作系统升级方法和装置

技术领域

本申请涉及电数字数据处理领域，尤其涉及一种在基于容器的多操作系统移动终端中进行操作系统升级的方法和装置。

背景技术

目前，行业内对移动操作系统升级的方案主要有2种。一种是完整升级，即将一个完整的操作系统镜像(通常几百M大小)写入到存储设备。另一种是增量升级，即仅仅更新两个版本之间的差异文件，升级包通常很小。然而，无论哪种方案，都是一次只能升级一个操作系统。随着容器技术的引入和发展，需要一次同时对两个以上系统进行升级。

发明内容

本申请的目标在于提供一种能够一次对两个以上操作系统进行升级的方法和装置。

本申请的目标由一种基于容器的移动终端操作系统升级方法实现，其中两个以上操作系统分别在不同容器中运行，该方法包括：

将具有获取更新进程的操作系统切换到前台，及将其余操作系统切换到后台；

前台操作系统从服务器下载前台操作系统和后台操作系统的增量升级包；

在用户确认升级时重启整个移动终端系统进入升级recovery模式；

对所述升级包进行解密并验证所述升级包的签名是否合法；

在所述签名合法时将前台操作系统的系统分区挂载到保存前台操作系统升级文件的目录，及将后台操作系统的系统分区挂载到保存后台操作系统升级文件的目录；

对升级文件分别进行校验以确保升级文件版本正确及未被修改过；及

用bspatch和升级包中的补丁文件对待升级文件进行更新。

本申请的目标还由一种基于容器的移动终端操作系统升级装置实现，其中两个以上操作系统分别在不同容器中运行，该装置包括：

系统切换单元，用于将具有获取更新进程的操作系统切换到前台，及将其余操作系统切换到后台；

升级包下载单元，用于使前台操作系统从服务器下载前台操作系统和后台操作系统的增量升级包；

升级确认单元，用于使用户能进行是否升级的确认；

重启单元，用于在用户确认升级时重启整个移动终端系统进入升级recovery模式；

解密单元，用于对所述升级包进行解密；

验证单元，用于验证所述升级包的签名是否合法；

分区挂载单元，用于在所述签名合法时将前台操作系统的系统分区挂载到保存前台操作系统升级文件的目录，及将后台操作系统的系统分区挂载到保存后台操作系统升级文件的目录；

校验单元，用于对升级文件分别进行校验以确保升级文件版本正确及未被修改过；及

更新单元，用于用bspatch(补丁合成工具)和升级包中的补丁文件对待升级文件进行更新。

基于Linux容器技术，可以在同一个移动终端设备上同时运行2个以上操作系统，在bootfs(启动文件系统)启动时使各个操作系统分别运行于不同容器中，各个操作系统共享kernel(内核)。本发明在进行系统升级时，首先从服务器下载2个操作系统的增量升级包，然后重启机器进入recovery模式，同时增量升级两个操作系统。与分两次对两个操作系统进行升级相比，本发明方法只需要对机器重启一次，且提高了升级过程的安全性。

除非明确指出，在此所用的单数形式“一”、“该”均包括复数含义(即具有“至少一”的意思)。应当进一步理解，说明书中使用的术语“具有”、“包括”和/或“包含”表明存在所述的特征、步骤、操作、元件和/或部件，但不排除存在或增加一个或多个其他特征、步骤、操作、元件、部件和/或其组合。如在此所用的术语“和/或”包括一个或多个列举的相关项目的任何及所有组合。除非明确指出，在此公开的任何方法的步骤不必精确按照所公开的顺序执行。

附图说明

本发明将在下面参考附图并结合优选实施例进行更完全地说明。

图1为根据本发明方法的一实施例的流程图。

图2为根据本发明方法的另一实施例的流程图。

图3为根据本发明装置的一实施例的结构示意图。

图4为根据本发明装置的另一实施例的结构示意图。

为清晰起见，这些附图均为示意性及简化的图，它们只给出了对于理解本发明所必要的细节，而省略其他细节。

具体实施方式

通过下面给出的详细描述，本发明的适用范围将显而易见。然而，应当理解，在详细描述和具体例子表明本发明优选实施例的同时，它们仅为说明目的给出。

基于Linux容器技术，可以在同一个移动终端设备如手机上同时运行2个以上操作系统，如2个或3个以上操作系统。在此以2个为例进行说明。在bootfs启动时，把第一操作系统OS-1如SyberOS和第二操作系统OS-2如Android分别运行于不同容器中，两个操作系统共享内核kernel。

图1示出了本发明方法的一实施例，用于一次对操作系统OS-1和OS-2均进行升级，该方法开始于步骤S10，通过设备节点/proc/dev_ns/switch_ns将OS-2切换到后台，OS-1切换到前台，OS-1中有一个otad进程负责从服务器下载升级包。切换可通过控制容器前后台切换的节点switch_ns进行，各容器只需向其写入1，即切换到前台，写入0，即切换到后台。在实施例中，在切换操作系统之前通知用户。之后，处理进行到步骤S20，OS-1中的otad进程从服务器下载两个操作系统的升级包，下载后存放在内置sdcard目录上。两个操作系统的升级包可打包成一个文件，也可分成两个文件。

在实施例中，升级包可按如下所述进行制作。首先从服务器下载版本1(Syberos_cactus_20150724-140050-s.img)和版本2(Syberos_cactus_20150724-145821-s.img)的完整升级包到PC，使用sintool.py去掉完整升级包的签名，然后使用qtool.py分别将完整升级包解开到目录Syberos_cactus_20150724-140050和Syberos_cactus_20150724-145821，最后使用otatool.py基于这两个版本制作增量升级包。完整升级包中包含syberos的rootfs.img、zImage、u-boot.bin和android的system.img、boot.img等。otatool.py首先会创建目录update，然后分别把两个版本的syberos的rootfs.img挂载到目录rootfsDirOld和rootfsDirNew，把两个版本的android的system.img挂载到目录systemDirOld和systemDirNew，然后对比两个版本的文件差异，如果有差异则使用开源软件bsdiff生成patch，记录md5码和文件属性，软硬链接等，syberos的差异patch写到update目录，android的差异patch写到update/android目录，写脚本update/update.sh。拷贝新版本的syberos的zImage、uboot.bin和android的boot.img等到update目录。然后将update目录打包成capsule.tar，使用sintool.py进行签名，然后再使用对称加密进行加密。

在升级包下载完毕之后，处理进行到步骤S25，提示用户是否进行升级。如果用户确认升级，则处理进行到步骤S30，发送dbus reboot ota重启系统进入recovery模式。之后，处理进行到步骤S40，运行capsule，capsule进程首先会判断增量升级包capsule.enc是否存在，如果存在则对升级包进行解密，然后处理进行到步骤S45，利用pubkey验证升级包的签名是否合法，合法则允许进入下一步升级流程，不合法则提示用户升级包非法，结束升级。签名验证成功后，处理进行到步骤S50，解压缩capsule.tar到/tmp目录，挂载syberos的rootfs分区到/syberfs目录，挂载android的system分区到/android目录，然后执行update.sh脚本开始升级。整个升级流程由update.sh控制，其包括步骤S60和S70。在步骤S60，首先会对待升级文件进行md5sum校验，以确保待升级文件版本正确及没有被修改过，保证手机中待更新文件与差分包中补丁文件匹配，然后在步骤S70，用bspatch工具和升级包中的patch文件对待升级文件进行更新。打过patch后文件内容就更新到新版本了。该实施例的方法只需重启一次机器即可完成两个操作系统的升级，大大提升了系统升级的便利性。

图2示出了本发明方法的另一实施例，其包括图1所示实施例的所有步骤。此外，图2所示的实施例还包括步骤S80，在文件内容更新到新版本之后对文件属性重新赋值，处理软硬链接。之后，处理进行到步骤S90，SyberOS的rootfs和Android的system分区更新后，将升级包中的syberos的zImage和u-boot.bin、Android的boot.img等写入到相应分区。执行cap-list.sh setcap设置能力，执行preparedata恢复数据分区用户和属组。

图3示出了本发明装置的一实施例，其用于在基于容器的多操作系统移动终端中对两个以上操作系统同时进行升级，其中两个以上操作系统分别在不同容器中运行，该装置包括：通知单元05，用于在切换操作系统之前通知用户。系统切换单元10，用于将具有获取更新进程的操作系统切换到前台，及将其余操作系统切换到后台；升级包下载单元20，用于使前台操作系统从服务器下载前台操作系统和后台操作系统的增量升级包；升级确认单元25，用于使用户能进行是否升级的确认；重启单元30，用于在用户确认升级时重启整个移动终端系统进入升级recovery模式；解密单元40，用于对所述升级包进行解密；验证单元45，用于验证所述升级包的签名是否合法；分区挂载单元50，用于在所述签名合法时将前台操作系统的系统分区挂载到保存前台操作系统升级文件的目录，及将后台操作系统的系统分区挂载到保存后台操作系统升级文件的目录；校验单元60，用于对升级文件分别进行校验以确保升级文件版本正确及未被修改过；及更新单元70，用于用bspatch和升级包中的补丁文件对待升级文件进行更新。

图4示出了本发明装置的另一实施例，其包括图3所示实施例的所有单元。此外，该实施例还包括：赋值单元80，用于对打过补丁的文件的属性重新赋值和/或处理软硬链接；设置和恢复单元90，用于设置能力并恢复数据分区用户和属组。

一些优选实施例已经在前面进行了说明，但是应当强调的是，本发明不局限于这些实施例，而是可以本发明主题范围内的其它方式实现。

Claims (10)

1.一种基于容器的移动终端操作系统升级方法，其中两个以上操作系统分别在不同容器中运行，其特征在于，所述方法包括：

将具有获取更新进程的操作系统切换到前台，及将其余操作系统切换到后台；

前台操作系统从服务器下载前台操作系统和后台操作系统的增量升级包；

在用户确认升级时重启整个移动终端系统进入升级recovery模式；

对所述升级包进行解密并验证所述升级包的签名是否合法；

在所述签名合法时将前台操作系统的系统分区挂载到保存前台操作系统升级文件的目录，及将后台操作系统的系统分区挂载到保存后台操作系统升级文件的目录；

对升级文件分别进行校验以确保升级文件版本正确及未被修改过；及

用bspatch和升级包中的补丁文件对待升级文件进行更新。

2.根据权利要求1所述的方法，其特征在于，前台操作系统和后台操作系统的增量升级包打包成一个文件。

3.根据权利要求1所述的方法，其特征在于，所述方法还包括：

对打过补丁的文件的属性重新赋值和/或处理软硬链接。

4.根据权利要求1-3任一所述的方法，其特征在于，所述方法还包括：

设置能力并恢复数据分区用户和属组。

5.根据权利要求1所述的方法，其特征在于，所述切换通过设备节点进行。

6.根据权利要求1所述的方法，其特征在于，所述方法还包括：

在切换操作系统之前通知用户。

7.一种基于容器的移动终端操作系统升级装置，其中两个以上操作系统分别在不同容器中运行，其特征在于，所述装置包括：

系统切换单元，用于将具有获取更新进程的操作系统切换到前台，及将其余操作系统切换到后台；

升级包下载单元，用于使前台操作系统从服务器下载前台操作系统和后台操作系统的增量升级包；

升级确认单元，用于使用户能进行是否升级的确认；

重启单元，用于在用户确认升级时重启整个移动终端系统进入升级recovery模式；

解密单元，用于对所述升级包进行解密；

验证单元，用于验证所述升级包的签名是否合法；

分区挂载单元，用于在所述签名合法时将前台操作系统的系统分区挂载到保存前台操作系统升级文件的目录，及将后台操作系统的系统分区挂载到保存后台操作系统升级文件的目录；

校验单元，用于对升级文件分别进行校验以确保升级文件版本正确及未被修改过；及

更新单元，用于用bspatch和升级包中的补丁文件对待升级文件进行更新。

8.根据权利要求7所述的装置，其特征在于，所述装置还包括：

赋值单元，用于对打过补丁的文件的属性重新赋值和/或处理软硬链接。

9.根据权利要求7所述的装置，其特征在于，所述装置还包括：

设置和恢复单元，用于设置能力并恢复数据分区用户和属组。

10.根据权利要求7所述的装置，其特征在于，所述装置还包括：

通知单元，用于在切换操作系统之前通知用户。