CN115686584A

CN115686584A - 一种操作系统升级方法、设备、存储介质及计算机程序产品

Info

Publication number: CN115686584A
Application number: CN202110872080.XA
Authority: CN
Inventors: 王艳召; 郝庆涛; 陈超; 张赠辉
Original assignee: Honor Device Co Ltd
Current assignee: Honor Device Co Ltd
Priority date: 2021-07-30
Filing date: 2021-07-30
Publication date: 2023-02-03
Anticipated expiration: 2041-07-30
Also published as: US20230229424A1; CN115686584B; EP4202649A4; WO2023005370A1; CN117873511A; EP4202649A1

Abstract

本申请实施例提供的一种升级操作系统的方法、设备、存储介质及计算机程序产品，包括：获取操作系统升级包，操作系统升级包包括第二分区表以及操作系统升级数据，其中，在第二分区表以及第一分区表中，名称相同的分区的地址配置一致；触发电子设备的第一次重启，在第一次重启之后，电子设备进入恢复模式；在恢复模式下，将电子设备的分区表更新为第二分区表；触发电子设备的第二次重启，在第二次重启之后，电子设备加载基础分区、第一静态分区以及动态分区的数据以运行第一操作系统；根据操作系统升级数据升级电子设备的操作系统，将第一操作系统升级为第二操作系统。本申请实施例的升级方案大大简化了分区表更新的操作难度，提高了用户体验。

Description

一种操作系统升级方法、设备、存储介质及计算机程序产品

技术领域

本申请涉及计算机技术领域，具体地涉及一种操作系统升级方法、设备、存储介质及计算机程序产品。

背景技术

在现有技术的应用场景中，用户终端需要安装操作系统才可以被用户使用。例如，手机上需要安装手机操作系统(例如：IOS系统、安卓系统)才可以被用户使用。

在终端设备安装操作系统后，当操作系统出现版本升级时，需要升级终端设备上所安装的操作系统。一般的，终端设备的操作系统的分区架构是事先在终端设备的存储器上规划好的。操作系统的升级主要是在原有的操作系统分区架构下对操作系统数据进行更新。但是，在进行某些改动较大的版本升级时，需要改动操作系统的分区架构，例如，增加分区或者是删除分区。因此，需要一种支持调整分区架构的操作系统升级方法。

发明内容

有鉴于此，本申请提供一种升级操作系统的方法、设备、存储介质及计算机程序产品，以利于解决现有技术中如何调整设备存储器的分区架构的问题。

第一方面，本申请实施例提供了一种升级操作系统的方法，应用于电子设备，电子设备包括处理器以及存储器，存储器包括基础分区、第一静态分区、第二静态分区、动态分区以及用户数据分区，电子设备当前的分区表为对应第一操作系统的第一分区表，电子设备启动后加载基础分区、第一静态分区以及动态分区的数据以运行第一操作系统，第一操作系统运行之后，方法包括：

获取操作系统升级包，操作系统升级包包括对应第二操作系统的第二分区表以及操作系统升级数据，操作系统升级数据用于将第一操作系统升级到第二操作系统，其中，在第二分区表以及第一分区表中，名称相同的分区的地址配置一致；

触发电子设备的第一次重启，在第一次重启之后，电子设备进入恢复模式；

在恢复模式下，将电子设备的分区表更新为第二分区表；

触发电子设备的第二次重启，在第二次重启之后，电子设备加载基础分区、第一静态分区以及动态分区的数据以运行第一操作系统；

根据操作系统升级数据升级电子设备的操作系统，将第一操作系统升级为第二操作系统。

根据本申请第一方面的方案，可以针对采用虚拟A/B升级方案的操作系统进行升级并在升级过程中更新设备存储器的分区表；根据本申请第一方面的方案，不需要准备烧录工具，设备基于下载的操作系统升级包就可以自行完成分区表的更新；根据本申请第一方面的方案大大简化了设备分区表更新的操作难度，提高了用户体验。

在第一方面的一种实现方式中，重启电子设备，进入恢复模式之前，方法还包括：

执行分区表更新准备操作，分区表更新准备操作用于配置电子设备在恢复模式下的执行流程。

在第一方面的一种实现方式中，执行分区表更新准备操作，包括：

将第二分区表保存到缓存；

在缓存中写入第一控制命令，第一控制命令对应第一操作流程，第一操作流程用于将电子设备的分区表更新为第二分区表。

在第一方面的一种实现方式中，第一操作流程包括：

校验第二分区表；

第二分区表校验成功后，验证第二分区表以及第一分区表中，名称相同的分区的地址配置是否一致；

当第二分区表以及第一分区表中，名称相同的分区的地址配置一致时，使用第二分区表更新电子设备的分区表。

在第一方面的一种实现方式中，在恢复模式下，将电子设备的分区表更新为第二分区表，包括：

加载缓存中的第二分区表以及第一控制命令；

解析第一控制命令，根据第一控制命令调用第一操作流程的执行代码；

执行第一操作流程的执行代码。

在第一方面的一种实现方式中，执行分区表更新准备操作之前，方法还包括：

确认操作系统升级包是否用于更新分区；

当操作系统升级包用于更新分区时，确认电子设备的分区表是否已基于第二分区表进行过更新；

当电子设备的分区表未基于第二分区表进行过更新时，执行分区表更新准备操作。

在第一方面的一种实现方式中，确认操作系统升级包是否用于更新分区，包括：

解析操作系统升级包对应的描述文件，当描述文件中包含分区升级包标志时，操作系统升级包用于更新分区。

在第一方面的一种实现方式中：

确认电子设备的分区表是否已基于第二分区表进行过更新，其中，根据分区更新标志位的状态确认电子设备的分区表是否已基于第二分区表进行过更新，在获取操作系统升级包之前，分区更新标志位的状态为未更新；

在恢复模式下，将电子设备的分区表更新为第二分区表，包括，将分区更新标志位的状态设置为已更新；

根据操作系统升级数据升级电子设备的操作系统，将第一操作系统升级为第二操作系统，包括，将分区更新标志位的状态设置为未更新。

在第一方面的一种实现方式中，在根据操作系统升级数据升级电子设备的操作系统之前，方法还包括：

在第二次重启之后，在第一操作系统运行之后，再次确认电子设备的分区表是否已基于第二分区表进行过更新；

当第一升级包获取工具确认电子设备的分区表已基于第二分区表进行过更新时，根据操作系统升级数据升级电子设备的操作系统。

在第一方面的一种实现方式中，第一操作系统包括第一升级包获取工具以及第一升级引擎，第一操作系统运行之后，方法包括：

第一升级包获取工具获取操作系统升级包；

第一升级包获取工具确认操作系统升级包是否用于更新分区；

当操作系统升级包用于更新分区时，第一升级包获取工具确认电子设备的分区表是否已基于第二分区表进行过更新；

当电子设备的分区表未基于第二分区表进行过更新时，第一升级包获取工具执行分区表更新准备操作；

第一升级包获取工具记录第一升级流程断点，第一升级流程断点对应确认电子设备的分区表是否已基于第二分区表进行过更新；

第一升级包获取工具触发第一次重启；

第一次重启之后，电子设备进入恢复模式，在恢复模式下，电子设备的分区表被更新为第二分区表，之后，电子设备的分区表已基于第二分区表进行过更新；

在恢复模式下，触发第二次重启；

第二次重启之后，电子设备加载基础分区、第一静态分区以及动态分区的数据以运行第一操作系统；

第一操作系统运行之后，第一升级包获取工具读取第一升级流程断点，再次确认电子设备的分区表是否已基于第二分区表进行过更新；

当第一升级包获取工具确认电子设备的分区表已基于第二分区表进行过更新，第一升级包获取工具触发第一升级引擎根据操作系统升级数据升级电子设备的操作系统。

在第一方面的一种实现方式中，第一操作系统包括第二升级包获取工具以及第二升级引擎，第一操作系统运行之后，方法包括：

第二升级包获取工具获取操作系统升级包；

第二升级包获取工具触发第二升级引擎进入升级流程；

第二升级引擎确认操作系统升级包是否用于更新分区；

当操作系统升级包用于更新分区时，第二升级引擎确认电子设备的分区表是否已基于第二分区表进行过更新；

当电子设备的分区表未基于第二分区表进行过更新时，第二升级引擎执行分区表更新准备操作；

第二升级引擎向第二升级包获取工具返回分区表更新准备操作执行完成的状态信息；

第二升级包获取工具记录第二升级流程断点，第二升级流程断点对应第二升级包获取工具触发第二升级引擎进入升级流程；

第二升级包获取工具触发电子设备的第三重启；

第三重启之后，电子设备进入恢复模式，在恢复模式下，电子设备的分区表被更新为第二分区表，之后，电子设备的分区表已基于第二分区表进行过更新；

在恢复模式下，触发电子设备的第四重启；

第四重启之后，电子设备加载基础分区、第一静态分区以及动态分区的数据以运行第一操作系统；

第一操作系统运行之后，第二升级包获取工具读取第二升级流程断点，再次触发第二升级引擎进入升级流程；

第二升级引擎再次确认操作系统升级包是否用于更新分区；

当操作系统升级包用于更新分区时，第二升级引擎再次确认电子设备的分区表是否已基于第二分区表进行过更新；

当电子设备的分区表未基于第二分区表进行过更新时，第二升级引擎根据操作系统升级数据升级电子设备的操作系统。

在第一方面的一种实现方式中，操作系统升级数据还包括静态分区升级数据以及动态分区升级数据，根据操作系统升级数据升级电子设备的操作系统，包括：

基于静态分区升级数据升级第二静态分区的数据；

在用户数据分区中创建虚拟动态分区，将动态分区升级数据写入到虚拟动态分区；

将电子设备的启动顺序由从第一静态分区启动，修改为从第二静态分区启动；

触发电子设备的第三次重启；

在第三次重启之后，电子设备加载基础分区、第二静态分区、动态分区以及虚拟动态分区的数据以运行第二操作系统；

在第二操作系统运行后，将虚拟动态分区的数据落盘到动态分区。

第二方面，本申请提出了一种电子设备，电子设备包括处理器以及存储器，存储器包括基础分区、第一静态分区、第二静态分区、动态分区以及用户数据分区，动态分区包括多个子分区，处理器用于执行存储器上存储的软件代码，以使得电子设备启动后加载基础分区、第一静态分区以及动态分区的数据以运行第一操作系统；

并且，在第一操作系统运行之后，使得电子设备执行如第一方面的方法流程。

第三方面，本申请提出了一种计算机可读存储介质，计算机可读存储介质中存储有计算机程序，当其在计算机上运行时，使得计算机执行如第一方面的方法。

第四方面，本申请提出了一种计算机程序产品，计算机程序产品包括计算机程序，当其在计算机上运行时，使得计算机执行如第一方面的方法。

附图说明

为了更清楚地说明本申请实施例的技术方案，下面将对实施例中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本申请的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动性的前提下，还可以根据这些附图获得其它的附图。

图1所示为根据本申请一实施例的数据存储结构示意图；

图2所示为根据本申请一实施例的数据存储结构示意图；

图3所示为根据本申请一实施例对操作系统进行升级的流程图；

图4所示为根据本申请一实施例的数据存储结构示意图；

图5所示为根据本申请一实施例进行操作系统升级的流程图；

图6所示为根据本申请一实施例出厂前进行系统烧录的烧录系统框架结构示意图；

图7所示为根据本申请一实施例的数据存储结构示意图；

图8所示为根据本申请一实施例的重新配置分区架构的分区结构示意图；

图9a所示为根据本申请一实施例进行操作系统升级的流程图；

图9b所示为根据本申请一实施例的操作系统升级包内部文件构成示意图；

图10所示为根据本申请一实施例进行操作系统升级的流程图；

图11所示为根据本申请一实施例进行操作系统升级的部分流程图；

图12为根据本申请一实施例的手机运行界面示意图；

图13为根据本申请一实施例的手机运行界面示意图；

图14所示为根据本申请一实施例进行操作系统升级的部分流程图；

图15所示为根据本申请一实施例进行操作系统升级的流程图；

图16所示为根据本申请一实施例进行操作系统升级的部分流程图。

具体实施方式

为了更好的理解本申请的技术方案，下面结合附图对本申请实施例进行详细描述。

应当明确，所描述的实施例仅仅是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其它实施例，都属于本申请保护的范围。

在本申请实施例中使用的术语是仅仅出于描述特定实施例的目的，而非旨在限制本申请。在本申请实施例和所附权利要求书中所使用的单数形式的“一种”、“所述”和“该”也旨在包括多数形式，除非上下文清楚地表示其他含义。

应当理解，本文中使用的术语“和/或”仅仅是一种描述关联对象的关联关系，表示可以存在三种关系，例如，甲和/或乙，可以表示：单独存在甲，同时存在甲和乙，单独存在乙这三种情况。另外，本文中字符“/”，一般表示前后关联对象是一种“或”的关系。

改动操作系统的分区架构，一种可行的解决方案是退出操作系统，进入恢复(Recovery) 模式，在Recovery下对设备的存储器进行整体刷新，重新配置设备存储器的分区结构并在重新配置的分区中写入操作系统程序。

一般的，分区表用于描述设备中存储器的分区部署，定义每个分区的起始地址和大小。分区表通常保存在设备的存储器的磁盘头部，在设备启动时，可以通过读取分区表来定位存储器上的各个分区。

以一采用全局唯一标识分区表(GUID Partition Table，GPT)的磁盘为例。图1所示为根据本申请一实施例的数据存储结构示意图。假设版本1.0的操作系统的分区架构包含GPT分区、x-loader分区、bootloader分区、boot分区、vendor-boot分区、Super分区以及Userdata分区。其中，分区表保存在GPT分区；Userdata用于保存用户的个人数据，例如，用户个人安装的APP、用户个人保存的图片、文档以及视频等个人数据；x-loader分区、bootloader分区、 boot分区、vendor-boot分区以及Super分区用于保存操作系统数据。

保存在GPT分区的分区表如表1所示：

表1

在表1中，AD1～AD6分别代表不同的地址字串。地址的数字串为16进制，地址字串加1代表偏移一个存储位(bit)，每8个存储位为一个字节(Byte)，每1024个字节为1KB，每1024KB为1MB。

例如：

AD1为0x000000FF偏移256KB的存储位，即为0x002000FF；

x-loader的地址为0x00000100～0x002000FF，0x00000100～0x002000FF的大小为256KB；

AD1+1为0x000200FF偏移一个存储位，即为0x00200100；

AD2为AD1(0x002000FF)偏移600KB的存储位，即为0x006B00FF；bootloader的地址为 0x00200100～0x006B00FF，0x00200100～0x006B00FF的大小为600KB。

假设在操作系统升级到版本2.0后，分区架构中增加了一个A分区。图2所示为根据本申请一实施例的数据存储结构示意图。假设版本2.0的操作系统的分区架构包含GPT分区、x- loader分区、bootloader分区、boot分区、A分区、vendor-boot分区、Super分区以及Userdata 分区。

保存在GPT分区的分区表如表2所示：

表2

在表2中，AD21、AD22分别代表不同的地址字串。AD21为AD3偏移32MB的存储位；AD22 为AD21偏移32MB的存储位。相较于表1的分区结构，在表2的分区结构中，Super的大小减少了 32MB。由于版本1.0的操作系统的分区架构对应图1所示分区架构，版本2.0的操作系统的分区架构对应图2所示分区架构，图1所示分区架构与图2所示分区架构并不相同，因此，设备上的操作系统从版本1.0升级到版本2.0的过程中，首先需要将设备存储器上的分区架构由图 1所示的分区架构重新配置图2所示的分区架构。即，将GPT中保存的分区表由表1刷新为表2。

不难理解，相较于表1所示的各个分区起始地址-终止地址，表2所示的分区起始地址-终止地址中，vendor-boot分区以及Super分区的起始地址-终止地址发生了改变，因此，如果将分区表由表1刷新为表2(重新配置分区架构)，存储器中的vendor-boot分区以及Super分区上的数据就不可用；那么，即使操作系统从版本1.0升级到版本2.0，vendor-boot分区以及Super 分区中的数据未发生变化，在分区表由表1刷新为表2后，也需要对存储器中的vendor-boot 分区以及Super分区进行数据重新写入。

因此，针对操作系统由1.0升级到2.0，一种可行的升级方案是在刷新分区表后，对所有的操作系统数据分区进行数据重新写入。

具体的，图3所示为根据本申请一实施例对操作系统进行升级的流程图。如图3所示，设备执行下述流程以将操作系统由版本1.0升级到版本2.0：

S300，获取操作系统升级包，将操作系统升级包保存到Userdata分区，操作系统升级包包括表2所示的分区表以及版本2.0的操作系统对应的bootloader分区、boot分区、A分区、 vendor-boot分区、Super分区的镜像数据；

S310，重启设备进入恢复(Recovery)模式；

S320，在恢复(Recovery)模式下，读取Userdata分区的操作系统升级包；

S321，提取操作系统升级包中的分区表，使用操作系统升级包中的分区表替换设备存储器 GPT分区中的分区表；在S321之前，GPT分区中的分区表如表1所示；

S322，分别提取操作系统升级包中bootloader分区、boot分区、A分区、vendor-boot分区、 Super分区的镜像数据，按照表2所示的分区起始地址-终止地址，将镜像数据恢复到bootloader 分区、boot分区、A分区、vendor-boot分区、Super分区的镜像数据；

S330，重启设备，启动操作系统。

虽然基于图3所示流程可以实现对操作系统分区架构的调整，但是，随着数据安全性要求的不断提高，在某些操作系统中，禁止在恢复(Recovery)模式下对用户个人数据进行访问，这就使得在恢复(Recovery)模式设备无法在分区中重新写入操作系统数据。

以采用虚拟A/B升级方式的安卓系统为例，图4所示为根据本申请一实施例的数据存储结构示意图。如图4所示，安卓系统数据存储区包含基础分区(Common)、静态分区(A)、静态分区(B)、动态分区(Super)、用户数据分区(Userdata)。

用户数据分区(Userdata)用于保存用户的个人数据，例如，用户个人安装的APP、用户个人保存的图片、文档以及视频等个人数据。基础部分中保存的数据为不参与操作系统升级的系统数据。静态分区(A)与静态分区(B)的结构相互对应，子分区命名通过后缀_a以及_b 相互区分。例如，静态分区(A)包括bootloader_a、boot_a、vendor_boot_a、dtbo_a、vbmeta_a；静态分区(B)包括bootloader_b、boot_b、vendor_boot_b、dtbo_b、vbmeta_b。动态分区(Super) 包含多个子分区(System、system_ext、vendor、product、Cust、Odm)。

在设备启动时，从一个静态分区启动。例如，设备从静态分区(A)启动：依次加载基础分区(Common)、静态分区(A)以及动态分区(Super)；设备从静态分区(B)启动：依次加载基础分区(Common)、静态分区(B)以及动态分区(Super)。

以采用主引导记录(Master Boot Record，MBR)格式的通用闪存(UniversalFlash Storage， UFS)为例。在UFS的MBR(主引导扇区，UFS的第一个扇区，即C/H/S地址的0柱面0磁头1扇区)中，保存有设备启动顺序描述，例如，从静态分区(A)启动(启动顺序标志为A) 或从静态分区(B)启动(启动顺序标志为A)。设备启动后首先从UFS的MBR中读取设备启动顺序。

图5所示为针对图4所示实施例的操作系统数据存储结构进行操作系统升级的流程图，当设备当前是从静态分区(A)启动时，设备按照如图5所示的流程实现操作系统的升级。

S500，设备依次加载基础分区(Common)、静态分区(A)以及动态分区(Super)，从静态分区(A)启动。

S510，设备获取操作系统升级包。

示例的，在一种可行的实现方案中，设备定期向搜包服务器发起搜包请求，搜包请求包含设备当前运行的操作系统的版本号(例如版本1.1)；搜包服务器根据搜包请求中的操作系统版本号，检索当前是否存在更新版本号的操作系统安装包(例如版本1.2)；当存在更新版本的操作系统安装包时，搜包服务器向设备反馈操作系统升级包(例如，由版本1.1升级到版本1.2 的系统增量升级安装包)的下载地址；设备根据操作系统升级包的下载地址下载操作系统升级包。

S520，设备根据操作系统升级包针对静态分区(B)进行数据写入操作以升级静态分区。

在S520的执行过程中，存在S520执行失败(静态分区升级失败)的情况。针对该情况，设备会中断整个操作系统升级操作，向用户输出升级失败提示(例如，显示升级失败的对话框)，自动重新升级或者由用户确定是否重新升级或放弃升级。

为检测S520中是否存在静态分区升级失败的情况，在S520中，会对数据写入后的静态分区(B)进行数据校验以确认静态分区数据是否成功写入。

例如，在一应用场景中，版本1.1升级到版本1.2的系统升级安装包包含版本1.2的静态分区的全量数据以及版本1.2的静态分区的全量数据的哈希值。设备将版本1.2的静态分区的全量数据覆写到静态分区(B)中。数据写入之后，设备计算静态分区(B)中数据的哈希值，校验静态分区(B)中数据的哈希值与版本1.1升级到版本1.2的系统升级安装包中版本1.2的静态分区的全量数据的哈希值是否一致。如果一致，则说明数据写入成功，可以进行后续的操作系统升级操作；如果不一致，则说明数据写入失败，升级失败。

又例如，在一应用场景中，版本1.1升级到版本1.2的系统升级安装包包含版本1.1升级到版本1.2的静态分区的差分数据、版本1.1的静态分区的全量数据的哈希值以及版本1.2的静态分区的全量数据的哈希值。

设备在向静态分区(B)写入数据之前，首先计算静态分区(A)中数据的哈希值，校验静态分区(A)中数据的哈希值与版本1.1升级到版本1.2的系统升级安装包中版本1.1的静态分区的全量数据的哈希值是否一致，如果一致，则说明当前静态分区(A)中数据为版本1.1的静态分区数据，版本1.1升级到版本1.2的静态分区的差分数据可用；如果不一致，则版本1.1 升级到版本1.2的静态分区的差分数据不可用，升级失败。

在设备确定版本1.1升级到版本1.2的静态分区的差分数据可用后，读取静态分区(A) 中数据，使用版本1.1升级到版本1.2的静态分区的差分数据以及静态分区(A)中数据执行还原得到版本1.2的静态分区的全量数据，将版本1.2的静态分区的全量数据覆写到静态分区 (B)中。数据写入之后，设备计算静态分区(B)中数据的哈希值，校验静态分区(B)中数据的哈希值与版本1.1升级到版本1.2的系统升级安装包中版本1.2的静态分区的全量数据的哈希值是否一致。如果一致，则说明数据写入成功，可以进行后续的操作系统升级操作；如果不一致，则说明数据写入失败，升级失败。

以一个静态分区的子分区boot为例，在一应用场景中，版本1.1升级到版本1.2的系统升级安装包包含下述数据：

Name:boot(分区名称，表示当前数据为指向静态分区的子分区boot的升级数据)

Start:12222(数据块起始地址，表示静态分区的子分区boot的升级数据(差分数据DELTA1) 的起始位置为12222)

size:2410(数据大小，表示静态分区的子分区boot的升级数据(差分数据DELTA1)的大小为2410)

原hash值:HASH11(版本1.1的静态分区的子分区boot的数据的哈希值)

镜像目标hash值:HASH12(版本1.2的静态分区的子分区boot的数据的哈希值)

差分数据delta:DELTA1(版本1.1升级到版本1.2的静态分区的差分数据)

在S520中，设备通过common分区中的misc分区读取设备的固定挂载路径，如 /dev/block/by-name/misc。从UFS器件中读取卡槽位(slot-b)，替换得到个子分区路径，如/dev/block/by-name/boot_b。

继续以子分区boot为例，设备首先计算/dev/block/by-name/boot_a下数据的哈希值，校验 /dev/block/by-name/boot_a下数据的哈希值与哈希值HASH11是否一致，如果一致，则DELTA1 可用，如果不一致，则升级操作失败。

当/dev/block/by-name/boot_a下数据的哈希值与哈希值HASH11一致时，设备基于 Start:12222以及size:2410读取DELTA1，使用DELTA1与/dev/block/by-name/boot_a下数据执行还原得到版本1.2的静态分区的子分区boot的全量数据。设备将版本1.2的静态分区的子分区boot的全量数据写到/dev/block/by-name/boot_b下。

数据写入后，设备计算/dev/block/by-name/boot_b下数据的哈希值，校验/dev/block/by- name/boot_b下数据的哈希值与哈希值HASH12是否一致，如果一致，则静态分区的子分区boot 升级成功，可以针对下一个静态分区子分区进行升级；如果不一致，则升级操作失败。

在一应用场景中，设备根据系统升级安装包所包含的静态分区子分区升级数据对静态分区的子分区进行升级，具体的，如果系统升级安装包包含某个静态分区子分区升级数据，则按照上述boot子分区的升级流程对该静态分区(B)中的该子分区进行升级，如果系统升级安装包不包含某个静态分区子分区升级数据，则将静态分区(A)中该子分区的数据直接同步到静态分区(B)中该子分区中。在升级过程中，当一个子分区出现升级错误，哈希校验失败，则中断升级操作，升级失败；当所有子分区升级成功，则静态分区升级成功，可以执行后续步骤。

进一步的，当某个静态分区(静态分区(A)或静态分区(B))升级失败时，静态分区的数据无法用于顺利启动操作系统，为了避免在操作系统启动过程中加载升级失败的静态分区而导致操作系统启动错误，在一应用场景中，静态分区具备对应的状态标记(可启动或不可启动)。设备在加载静态分区数据之前首先读取静态分区状态标记，仅当静态分区的状态标记为可启动时才加载静态分区的数据。在升级静态分区的数据之前，会将静态分区标记为不可启动，在静态分区的数据升级成功后再将静态分区标记为可启动，这样，如果静态分区升级失败，则静态分区的状态会保持在不可启动。设备就不会加载升级失败的静态分区的数据。

例如，在S520中，在升级静态分区(B)的数据之前，标记静态分区(B)为不可启动。具体的，静态分区的状态标记保存在Common分区。在S520中，在升级静态分区(B)的数据之前，将Common分区中静态分区的状态标记中slot-b标记为unbootable。当S520成功执行(所有的哈希校验均成功时)后，标记静态分区(B)为可启动。例如，在S520之后，将 Common分区中静态分区的状态标记中slot-b标记为bootable。

S530，设备根据操作系统升级包在用户数据分区(Userdata)创建虚拟动态分区，在虚拟动态分区写入动态分区(Super)的升级数据。例如，在操作系统升级包中包含版本1.2的动态分区的数据，设备在虚拟动态分区中写入版本1.2的动态分区(Super)的数据。

进一步的，在虚拟A/B升级方案中，针对动态分区(Super)，采用增量升级方式。在升级过程中，用户数据分区(Userdata)的虚拟动态分区中保存的并不是升级后新版本的动态分区 (Super)的全部文件，而是旧版本的动态分区(Super)中需要升级的数据在升级后的升级结果。即，用户数据分区(Userdata)的虚拟动态分区中保存的是动态分区的更新数据。

以system子分区为例，假设在版本1.1中，system子分区中的数据可以分为system1、 system2两部分。从版本1.1升级到版本1.2，数据system2没有发生变化，数据syetem1被升级为system3。那么，在S530中，设备在用户数据分区(Userdata)创建虚拟动态分区，在虚拟动态分区中写入数据system3。

例如，版本1.1升级到版本1.2的系统增量升级安装包包含版本1.1升级到版本1.2的动态分区(Super)更新数据，该动态分区(Super)更新数据包含数据system3。

进一步的，在虚拟A/B升级方案中，基于快照技术(snapshot)实现动态分区(Super)的增量升级。具体的，用户数据分区(Userdata)的虚拟动态分区中，采用写时拷贝(Copy-On- Write，COW)文件保存动态分区(Super)的升级数据。

具体的，用户数据分区(Userdata)中保存的动态分区(Super)的升级数据包含多个COW 文件，每个COW文件对应一个动态分区(Super)的子分区，COW文件的命名与其所针对的动态分区(Super)子分区相对应。

在S510所获取的操作系统升级包中，动态分区(Super)的升级数据的COW文件以二进制代码形式压缩保存。在操作系统升级包中，每个COW文件根据其所针对的动态分区(Super) 子分区所命名。例如，针对system子分区的COW文件被命名为system-cow-img.img.0000。

在S530中，设备解包操作系统升级包以获取所有的COW文件，为每个COW文件附加A/B分区标记。具体的，当设备当前从静态分区(A)启动时，可以理解为设备当前运行操作系统所加载的动态分区(Super)为动态分区(A)。在升级操作系统时，用户数据分区(Userdata) 中创建的虚拟动态分区是针对动态分区(B)。因此，为COW文件附加对应动态分区(B)的名称标记_b。例如，为system-cow-img.img.0000附加_b生成system_b-cow-img.img.0000。

进一步的，在S530中，在用户数据分区(Userdata)中创建Update文件夹，将重命名的 COW文件保存到Update文件夹下。例如，在一应用场景中，在向用户数据分区(Userdata)写入COW文件后，用户数据分区(Userdata)的Update文件夹中包含下述文件：

system_b-cow-img.img.0000；

system_ext_b-cow-img.img.0000；

vendor_b-cow-img.img.0000；

product_b-cow-img.img.0000；

cust_b-cow-img.img.0000；

odm_b-cow-img.img.0000。

具体的，COW文件中包含COW文件自身的COW文件地图(快照map)以及升级数据。COW文件地图(快照)与COW文件所针对的动态分区(Super)的子分区的文件地图相对应。动态分区(Super)的子分区的文件地图用于描述当前版本的操作系统(本次升级之前的版本，例如，版本1.1)动态分区(Super)的子分区中的所有文件以及各个文件的保存地址。

COW文件中的升级数据为相较于当前版本的子分区数据，新版本的子分区数据中被更新的文件；COW文件自身的COW文件地图则用于描述被更新的文件与当前版本的子分区中的文件间的对应关系以及被更新的文件的保存地址。

基于动态分区(Super)的子分区的文件地图以及COW文件中的COW文件地图，就可以使用COW文件中的升级数据替换动态分区(Super)的子分区中的对应文件，从而实现动态分区(Super)数据的升级。具体的，在需要获取动态分区(Super)的子分区的文件地图时，可以基于snapshot对动态分区(Super)的子分区的数据进行快照操作以生成动态分区(Super) 的子分区的文件地图。也可以在制作操作系统升级包时，预先生成动态分区(Super)的子分区的文件地图，将该文件地图加入到COW文件中。

以system子分区为例，假设system子分区中按照以下路径保存数据：

/system/app/A0.XXX；

/system/app/A1.XXX；

/system/app/A2.XXX；

/system/B0.XXX；

/system/B1.XXX；

/system/user/C0.XXX；

/system/user/C1.XXX；

/system/user/C2.XXX；

/system/user/C3.XXX。

system子分区的文件地图可以是：

/system/app/A0.XXX：024010～024013；

/system/app/A1.XXX：024014～024017；

/system/app/A2.XXX：024018～024020；

/system/B0.XXX：024021～024026；

/system/B1.XXX：024027～024028；

/system/user/C0.XXX：024029～024032；

/system/user/C1.XXX：024033～024035；

/system/user/C2.XXX：024036～024040；

/system/user/C3.XXX：024041～024044。

文件名后的数值(例如，/system/app/A0.XXX：024010～024013中的024010～024013)为该文件在动态分区(Super)的system子分区的物理保存地址(块地址)。

假设当前操作系统升级需要更新数据/system/app/A2.XXX以及/system/user/C2.XXX。

可以视为：

/system/app/A2.XXX以及/system/user/C2.XXX为system子分区数据的system1部分；

/system/app/A0.XXX、/system/app/A1.XXX、/system/B0.XXX、/system/B1.XXX、/system/user/C0.XXX、/system/user/C1.XXX以及/system/user/C3.XXX为system子分区数据的 system2部分。

那么，针对system子分区的COW文件(system_b-cow-img.img.0000)就包含最新版的 /system/app/A2.XXX以及/system/user/C2.XXX。

可以视为，最新版的/system/app/A2.XXX以及/system/user/C2.XXX为system3。升级目标是使用system3更新掉system1。

COW文件(system_b-cow-img.img.0000)自身的COW文件地图可以为：

/system/app/A2.XXX：

Map1(原super分区中待更新数据的地址)：起始地址address start：024018(相对于system 起始地址的偏移量)；偏移量大小size：2(即024018～024020地址段的数据)

Map2(cow文件中存储的更新数据的地址)：起始地址address start：045033(相对于cow 文件存储的起始地址的偏移量)；偏移量大小size：2(即045033～045035地址段的数据)；

/system/user/C2.XXX：

Map1(原super分区中待更新数据的地址)：起始地址address start：024036(相对于system 起始地址的偏移量)；偏移量大小size：4(即024036～024040地址段的数据)

Map2(cow文件中存储的更新数据的地址)：起始地址address start：045036(相对于cow 文件存储的起始地址的偏移量)；偏移量大小size：4(即045036～045040地址段的数据)；

文件名后的数值(045033～045035以及045036～045040)分别为COW文件(system_b-cow- img.img.0000)中最新版的/system/app/A2.XXX以及/system/user/C2.XXX在用户数据分区 (Userdata)的物理保存地址(块地址)。

这样，如果使用地址045033～045035上的A2.XXX替换掉地址024018～024020上的A2.XXX，并且，使用地址045036～045040上的C2.XXX替换掉地址024036～024040上的C2.XXX，就可以完成动态分区(Super)的system子分区的数据升级。

在COW文件成功写入到用户数据分区(Userdata)后，将基础分区(Common)的元数据分区(/metadata)中的落盘状态信息由“已落盘(merged)”改为“未落盘(wait formerge)”。落盘状态信息用于表示当前是否存在需要落盘到动态分区(Super)的COW文件。具体的，落盘状态信息包含针对动态分区(Super)的整体标识以及针对每个子分区的子分区标识。当整体标识为“已落盘(merged)”时，代表动态分区(Super)的所有子分区均不需要进行落盘操作；当整体标识为“未落盘(wait for merge)”时，代表动态分区(Super)的一个或多个子分区需要进行落盘操作；当子分区标识为“已落盘(merged)”时，代表该子分区不需要进行落盘操作；当子分区标识为“未落盘(wait for merge)”时，代表该子分区需要进行落盘操作。

进一步的，在某些应用场景中，在S530中，设备不仅仅向用户数据分区(Userdata)写入 COW文件，还会刷新动态分区(Super)的metadata中的分区信息。

具体的，图6所示为一应用场景下设备出厂前进行系统烧录的烧录系统框架结构示意图。在采用虚拟A/B升级方式的安卓系统中，由于只有静态分区采用A/B方案，而动态分区采用升级时构造虚拟动态分区的方案。因此，为了静态分区与动态分区的匹配，如图4所示，在动态分区(Super)的头部的元数据(/supermetadata)中，包含对应静态分区(A)的Slot0(插槽一数据)以及静态分区(B)的Slot1(插槽二数据)。Slot0以及Slot1用于保存Super分区的分区表。

例如，在UFS的MBR中，设备启动顺序描述中，配置Slot0对应从静态分区(A)启动，配置Slot1对应从静态分区(B)启动。在设备启动时，根据启动的静态分区的不同，选择从Slot0或Slot1中的一个中获取Super分区的分区信息。例如，在设备由静态分区A启动时，在加载Super分区时，设备首先读取Slot0，以获取Super分区的子分区地址；在设备由静态分区 B启动时，在加载Super分区时，设备首先读取Slot1，以获取Super分区的子分区地址。

具体的，Slot0以及Slot1中包含多个子分区描述组，每个子分区描述组对应Super分区的一个子分区。每个子分区描述组包含：

名称(Name)项，其值为子分区的名称；

组(Group)项，其值为子分区类型；

属性(Attributes)项，其值为分区读写属性，例如，只读属性(readonly)；

地址(Extents)项，其值为子分区的地址(例如，分区大小、偏移量)。

在Name项以及Group项中，值的后缀为_a，则对应静态分区(A)；值的后缀为_b，则对应静态分区(B)。

在由静态分区A启动，加载Super分区时，首先读取Slot0。在读取Slot0时，由于后缀为 _a对应静态分区(A)，设备读取Slot0中Name项和/或Group项后缀为_a的分区描述组中Extents项的值，以获取Super分区的子分区地址。

在由静态分区B启动，加载Super分区时，首先读取Slot1。在读取Slot1时，由于后缀为 _b对应静态分区(B)，设备读取Slot0中Name项和/或Group项后缀为_b的分区描述组中 Extents项的值，以获取Super分区的子分区地址。

在S510所获取的操作系统升级包中，包含1.2版本的动态分区(Super)的分区信息，在 S530中，设备从操作系统升级包中提取1.2版本的动态分区(Super)的分区信息，使用1.2版本的动态分区(Super)的分区信息刷新静态分区(B)所对应的Slot1中的分区信息。

以System子分区为例，假设在S530之前，动态分区(Super)的/supermetadata的Slot 1 中包含如下内容：

Metadata version:10.2

Metadata size:1300bytes

Metadata max size:65536bytes

Metadata slot count:3

Header flags:virtual_ab_device

Partition table:------------------------

Name:system_b

Group:ry_dynamic_partitions_b

Attributes:readonly,updated

Extents:0..6995967linear super 2048

在S510所获取的操作系统升级包中，1.2版本的动态分区(Super)的分区信息包含如下内容：

Name:system

Group:ry_dynamic_partitions

Extents:0..699XXXX linear super 2048

在S530中，设备通过当前需要升级的静态分区为静态分区(B)定位到对应静态分区(B) 的动态分区(Super)的/supermetadata的Slot 1，使用1.2版本的动态分区(Super)的分区信息刷新Slot 1中的内容。在S530之后，动态分区(Super)的/supermetadata的Slot1中包含如下内容：

Metadata version:10.2

Metadata size:1300bytes

Metadata max size:65536bytes

Metadata slot count:3

Header flags:virtual_ab_device

Partition table:------------------------

Name:system_b

Group:ry_dynamic_partitions_b

Attributes:readonly,updated

Extents:0..699XXXX linear super 2048

进一步的，在S530的执行过程中，存在S530执行失败的情况。针对该情况，设备会中断整个操作系统升级操作，向用户输出升级失败提示(例如，显示升级失败的对话框)，自动重新升级或者由用户确定是否重新升级或放弃升级。(参照S520中静态分区数据写入失败)

具体的，当用户数据分区(Userdata)的存储空间不足时会导致S530执行失败。在S530 中，在设备根据操作系统升级包在用户数据分区(Userdata)创建虚拟动态分区的过程中，虚拟动态分区的大小是由操作系统升级包中版本1.2的动态分区的数据的大小决定的。当用户数据分区(Userdata)上的空余空间不足以创建虚拟动态分区时，S530执行失败。

例如，在一应用场景中，设备从操作系统升级包中提取COW文件并将COW文件写入用户数据分区(Userdata)的Update文件夹中。操作系统升级包中包含COW文件内容以及COW文件大小。在S530中，设备首先根据操作系统升级包中的cow文件名称以及COW文件大小在用户数据分区(Userdata)的Update文件夹下创建空COW文件，然后从操作系统升级包中提取COW文件数据写入空COW文件。

以system子分区为例，在操作系统升级包中，针对system子分区的COW文件被命名为 system-cow-img.img.0000，system-cow-img.img.0000的大小为XXXX。设备在用户数据分区 (Userdata)的Update文件夹下创建system_b-cow文件，system_b-cow文件的大小为XXXX，内容为空。在system_b-cow文件创建完成后，设备就可以从系统升级安装包中提取system-cow- img.img.0000，写入system_b-cow并改名为system_b-cow-img.img.0000。

设备在用户数据分区(Userdata)的Update文件夹下创建空COW文件system_b-cow、 system_ext_b-cow、vendor_b-cow、product_b-cow、cust_b-cow、odm_b-cow。当所有的空COW 文件创建完成后，设备就可以从系统升级安装包中提取COW文件数据，写入空COW文件并改名。

最终用户数据分区(Userdata)的Update文件夹中包含下述文件：

system_b-cow-img.img.0000；

system_ext_b-cow-img.img.0000；

vendor_b-cow-img.img.0000；

product_b-cow-img.img.0000；

cust_b-cow-img.img.0000；

odm_b-cow-img.img.0000。

在创建空COW文件的过程中，设备每次创建一个空COW文件，在一个空COW文件创建成功后创建下一个。在此过程中，当一个空COW文件创建失败，则说明用户数据分区(Userdata)的存储空间不足，S530执行失败，操作系统升级失败。

进一步的，在S530中，COW文件的提取失败也会导致S530执行失败。具体的，在操作系统升级包中，以二进制代码形式保存COW文件，在将COW文件写入用户数据分区(Userdata) 时，首先需要从操作系统升级包中提取COW文件，将COW文件打开，将COW文件数据写入到用户数据分区(Userdata)。在上述过程中，如果操作系统升级包存在数据错误，COW文件无法提取或打开，则S530执行失败，操作系统升级失败。

进一步的，在S530中，COW文件的写入失败也会导致S530执行失败。为检测COW文件写入是否成功，在S530中，在将COW文件写入用户数据分区(Userdata)后，还需要对动态分区(Super)+COW文件进行整体校验，校验动态分区(Super)+COW文件的有效性，验证当前版本的动态分区(Super)数据+COW文件的合成结果是否为新版本的动态分区(Super) 数据。

具体的，以从1.1版本升级到1.3版本为例，计算动态分区(Super)中不需要升级的数据 (从版本1.1到版本1.2未发生变化的数据)与COW文件中升级数据(从版本1.1到版本1.2 需要升级的数据)的合成结果的哈希值，判断该哈希值与1.3版本中动态分区(Super)的完整数据的哈希值是否一致，如果一致，则说明COW文件有效；如果不一致，则说明COW文件无效，升级失败，中断升级进程并报错；其中，1.3版本中动态分区(Super)的完整数据的哈希值被保存在操作系统升级包中。

具体的，在校验过程中，基于snapshot合并动态分区(Super)+COW文件。在snapshot的实现过程中，动态分区(Super)与COW文件的合并并不是物理意义上的合并，而是将system 子分区的整体文件地图与COW文件自身的COW文件地图进行合并，生成新版本的子分区数据的文件地图。

例如，将system子分区的文件地图：

/system/app/A0.XXX：024010～024013；

/system/app/A1.XXX：024014～024017；

/system/app/A2.XXX：024018～024020；

/system/B0.XXX：024021～024026；

/system/B1.XXX：024027～024028；

/system/user/C0.XXX：024029～024032；

/system/user/C1.XXX：024033～024035；

/system/user/C2.XXX：024036～024040；

/system/user/C3.XXX：024041～024044。

与COW文件地图：

/system/app/A2.XXX：045033～045035；

/system/user/C2.XXX：045036～045040。

合并。则得到system子分区的新版本的文件地图：

/system/app/A0.XXX：024010～024013；

(指向动态分区(Super)中/system/app下的A0.XXX)

/system/app/A1.XXX：024014～024017；

(指向动态分区(Super)中/system/app下的A1.XXX)

/system/app/A2.XXX：045033～045035；

(指向用户数据分区(Userdata)中/Update/system_b-cow-img.img.0000中的A2.XXX)

/system/B0.XXX：024021～024026；

(指向动态分区(Super)中/system下的B0.XXX)

/system/B1.XXX：024027～024028；

(指向动态分区(Super)中/system下的B1.XXX)

/system/user/C0.XXX：024029～024032；

(指向动态分区(Super)中/system/user下的C0.XXX)

/system/user/C1.XXX：024033～024035；

(指向动态分区(Super)中/system/user下的C1.XXX)

/system/user/C2.XXX：045036～045040；

(指向用户数据分区(Userdata)中/Update/system_b-cow-img.img.0000中的C2.XXX)

/system/user/C3.XXX：024041～024044。

(指向动态分区(Super)中/system/user下的C3.XXX)

在新版本的system子分区的文件地图中，/system/app/A2.XXX的保存地址并不是指向存储器上动态分区(Super)上的/system/app/A2.XXX，而是指向存储器上用户数据分区(Userdata) 中system_b-cow-img.img.0000中的A2.XXX；/system/user/C2.XXX的保存地址并不是指向存储器上动态分区(Super)上的/system/user/C2.XXX，而是指向存储器上用户数据分区(Userdata) 中system_b-cow-img.img.0000中的C2.XXX。

在校验过程中，按照上述合成方式，获取动态分区(Super)的所有子分区的新版本的文件地图(如果用户数据分区(Userdata)中并未写入某个子分区的对应COW文件，则直接以该子分区的文件地图为新版本的文件地图)。将所有子分区的新版本的文件地图组合生成动态分区(Super)的新版本的文件系统。

基于动态分区(Super)的新版本的文件系统读取数据，读取动态分区(Super)的新版本的文件系统所包含的所有文件并计算哈希值。

S531，将设备的启动顺序由可从静态分区(A)启动变更为可从静态分区(B)启动。

例如，改写主引导记录(Master Boot Record，MBR)的启动顺序标识，将启动顺序标识由 A改写为B。在设备上电后，当设备读取到启动顺序标识为A，设备从静态分区(A)启动，启动过程中加载静态分区(A)；当设备读取到启动顺序标识为B，设备从静态分区(B)启动，启动过程中加载静态分区(B)。

进一步的，在S531中，还将Common分区中静态分区的状态标记中slot-b标记为bootable。

S532，设备重启。退出当前的操作系统，切断设备电源，再次开启设备电源。

S540，设备依次加载基础分区(Common)、静态分区(B)。

S541，设备加载动态分区(Super)以及用户数据分区(Userdata)的虚拟动态分区。

具体的，设备读取元数据(/metadata)中的落盘状态信息，基于落盘状态信息确定是否需要从用户数据分区(Userdata)的指定路径中检索COW文件，并采用snapshot合并加载动态分区(Super)以及COW文件。

进一步的，在S541中，设备并不加载动态分区(Super)以及用户数据分区(Userdata) 中的全部COW文件，而是根据操作系统运行需求加载对应的文件。具体的，在S541中，设备根据操作系统运行需求确定需要加载的文件，基于snapshot从动态分区(Super)或虚拟动态分区中的COW文件中提取对应的文件进行加载。

具体的，在S541中，当动态分区(Super)的子分区首存在对应的COW文件时，先基于snapshot生成动态分区(Super)各个子分区的新版本的文件地图。生成新版本的文件地图的过程可以参照S530。设备根据操作系统运行需求确定需要加载的文件，基于动态分区(Super) 子分区的新版本的文件地图进行文件加载。

例如，操作系统运行需求加载system子分区下目录user(/system/user)中的所有数据。设备读取元数据(/metadata)中的落盘状态信息，落盘状态信息中system子分区的子分区标识为“未落盘(wait for merge)”，因此，设备在用户数据分区(Userdata)中/Update下搜索COW 文件，在Update下搜索到COW文件system_b-cow-img.img.0000后，基于snapshot，根据 system_b-cow-img.img.0000中的COW文件的文件地图生成system子分区的新版本的文件地图。按照system子分区的新版本的文件地图中/system/user下所有文件的保存地址进行数据加载，例如，根据system子分区的新版本的文件地图中：

/system/user/C0.XXX：024029～024032；

/system/user/C1.XXX：024033～024035；

/system/user/C2.XXX：045036～045040；

/system/user/C3.XXX：024041～024044。

加载地址024029～024032处的C0.XXX、地址024033～024035处的C1.XXX、地址045036～045040处的C2.XXX以及地址024041～024044处的C3.XXX。

进一步的，在加载system子分区下目录user(/system/user)中的所有数据时，当落盘状态信息中system子分区的子分区标识为“已落盘(merged)”时，设备就不会在用户数据分区 (Userdata)中/Update下搜索COW文件，而是直接加载system子分区下目录user(/system/user) 中的所有数据。

进一步的，在加载system子分区下目录user(/system/user)中的所有数据时，当落盘状态信息中system子分区的子分区标识为“未落盘(wait for merge)”时，如果设备在用户数据分区 (Userdata)中/Update下未搜索到对应system子分区的COW文件时，则说明升级过程中数据写入错误(COW文件写入错误或者落盘状态信息写入错误)，此时设备回滚系统并报错。

进一步的，在S541中，在加载文件之前，设备还需要对加载文件进行校验。不同于S530，在S541中，不对动态分区(Super)+COW文件进行整体验证，而是仅对需要加载的文件进行验证。例如，基于dmverity进行校验(dm-verity是dm(device mapper)的一个目标(target)，是一个虚拟块设备，专门用于文件系统的校验)。校验成功则加载文件，校验失败则重启设备，回滚系统或者尝试再次加载文件。

S550，设备成功启动，进入用户交互界面。

S551，设备将虚拟动态分区的数据落盘到动态分区(Super)。

在本申请说明书的描述中，落盘操作指的是，在操作系统升级过程中，将用户数据分区 (Userdata)上虚拟动态分区中保存的动态分区(Super)升级文件(COW文件)写入到动态分区(Super)中，使得动态分区(Super)的文件完成数据升级，以便设备在下次启动时不需要加载动态分区(Super)和虚拟动态分区，只需加载动态分区(Super)就可以完成设备启动。

具体的，设备在启动成功后进行开机广播，开机广播后开启升级进程。升级进程读取基础分区(Common)的元数据(/metadata)中的落盘状态信息，如果落盘状态信息为“已落盘 (merged)”，则设备进入正常运行模式。

如果落盘状态信息为“未落盘(wait for merge)”，升级进程将用户数据分区(Userdata)中的COW文件落盘到动态分区(Super)中。

具体的，升级进程将用户数据分区(Userdata)中的COW文件中的升级数据写入到动态分区(Super)中的对应地址上，使得动态分区(Super)中的全部数据均为升级后的新版本的数据。

例如，基于system子分区的文件地图中的/system/app/A2.XXX：024018～024020以及COW 文件地图中的/system/app/A2.XXX：045033～045035，将地址045033～045035上的数据写入到地址024014～024017上；基于system子分区的文件地图中的/system/user/C2.XXX： 024036～024040以及COW文件地图中的/system/user/C2.XXX：045036～045040，将地址 045036～045040上的数据写入到地址024036～024040上。

在此之后升级进程删除用户数据分区(Userdata)中的COW文件，将存储空间归还给用户数据分区(Userdata)；并且，将基础分区(Common)的元数据(/metadata)中的落盘状态信息由“未落盘(wait for merge)”改为“已落盘(merged)”。

在S520中，静态分区升级的数据操作是针对静态分区(B)中的操作系统数据的，其并不会影响到当前启动的静态分区(A)的操作系统数据；并且，在S530中，动态分区升级的数据操作是在用户数据分区(Userdata)中所创建的虚拟动态分区上完成的，其并不会影响到当前挂载的动态分区(Super)。因此，在整个操作系统升级的过程中，用户可以正常使用设备；并且，在S531完成后，设备并不需要立即重启，可以由用户自行选择重启时机；这样，操作系统的升级过程并不会对用户的正常手机操作产生影响，从而大大提高了用户体验。进一步的，针对动态分区(Super)，仅在需要进行升级时才会在用户数据分区(Userdata)上创建虚拟动态分区，因此有效提高了数据存储空间利用率。

图7所示为根据本申请一实施例的数据存储结构示意图。如果需要对图4所示的的分区结构进行重新配置，例如，在静态分区(A)以及静态分区(B)中分别增加子分区A_a以及A_b，得到图7所示的数据存储结构，就需要将设备的存储器的磁盘头部(例如，MBR分区或GPT 分区)中所保存的分区表刷新为图7所示数据存储结构所对应的分区表(原始分区表为图4所示分区结构所对应的分区表)。由于在图5所示的升级流程中，设备在操作系统运行的状态下完成操作系统数据升级；而操作系统正常运行状态下，存储器的磁盘头部的分区表是只读的，因此，按照图5所示的升级流程，无法完成分区表的刷新。

因此，一种逻辑上可行的应用方案是基于图3所示流程，在用户数据分区(Userdata)中保存操作系统升级包，该操作系统升级包包含图7所示数据存储结构的分区表以及图7所示的数据存储结构中各个分区的镜像数据。设备重启后进入恢复(Recovery)模式，在恢复(Recovery) 模式下读取用户数据分区(Userdata)中保存的操作系统升级包，使用操作系统升级包中的分区表刷新磁盘MBR中的分区表，基于刷新后的分区表定位各个分区，将操作系统升级包中各个分区的镜像数据恢复到各个分区。

然而，在采用虚拟A/B升级方式的安卓系统中，为了确保用户数据安全，用户数据分区(Userdata)中保存的数据是被加密的，只有在安卓系统正常运行下才可以对用户数据分区 (Userdata)中保存的数据进行访问。也就是说，当设备重启进入恢复(Recovery)模式后，其无法访问用户数据分区(Userdata)中保存的数据。这样，设备就无法在恢复(Recovery)模式中重新配置分区结构并重新为新配置的各个分区写入数据。

针对上述问题，本申请提出了一种虚拟A/B升级与恢复(Recovery)模式升级相结合的操作系统升级方法。先在恢复(Recovery)模式下刷新分区表以重新配置分区架构，然后启动操作系统，采用虚拟A/B升级的方式升级操作系统数据。

由于在重新配置分区架构后需要启动操作系统，因此，就要求重新配置分区架构后，操作系统启动时所要加载的各个分区仍然可用。即，在重新配置分区架构前后，操作系统启动时所要加载的各个分区的起始地址-终止地址保持不变。针对上述要求，本申请提出了一种新的操作系统分区架构。在本申请一实施例的分区架构中，并不把磁盘的所有空间都创建为可用的分区，而是预留一部分空间作为预留(reserve)分区。reserve分区为不可用的分区，其在设备运行时不体现在设备的可用分区中，即，假设操作系统对应的分区架构如图4所示，如果设备的存储器上配置有reserve分区，则设备运行操作系统时，其可用的分区依然如图4所示，reserve 分区并未体现。

而在重新配置分区架构时，如果需要新增分区，使用reserve分区来创建新分区；如果需要删除分区，则将需要删除的分区转换为reserve分区；在重新配置分区架构前后，reserve分区以外的其他分区保持不变。

以增加新分区的应用场景为例，图8所示为根据本申请一实施例的重新配置分区架构的分区结构示意图。在重新配置分区架构之前，图4所示的分区架构映射到存储器上的一部分存储空间分配如图8左图所示。图8左图对应的分区表如表3所示：

表3

在表3中，AD31～AD38分别代表不同的地址字串。参照表1的AD1～AD6。XX为分区大小，不同分区的XX可以相同也可以不同。

将图4所示的分区架构重新配置分区为图7所示的分区架构，在重新配置分区架构之后，图7所示的分区架构映射到存储器上的一部分存储空间分配如图8右图所示。图8右图对应的分区表如表4所示：

表4

同样，针对删除分区的应用场景，则是将上述流程倒过来，将删除的分区配置为新的reserve 分区。

进一步的，根据所要创建的新分区的大小，可以采用分割单个reserve分区和/或合并多个 reserve分区的方式，切割一个reserve分区的一部分空间创建新分区，或合并多个reserve分区创建新分区。

图9a所示为根据本申请一实施例进行操作系统升级的流程图。设备执行如图9a所示以实现包含分区架构重新配置的操作系统升级。

S900，设备依次加载基础分区(Common)、静态分区(A)以及动态分区(Super)，从静态分区(A)启动。

S910，获取操作系统升级包，操作系统升级包的获取过程可以参照S510。

操作系统升级包包含最新版本的操作系统所对应的分区结构的分区表以及操作系统升级数据。操作系统升级数据的具体内容可以参照图5所示升级流程中的操作系统升级包的内容。

操作系统升级包所包含的分区表与设备存储器上当前的分区表上，同名分区的地址相同。

例如，假设设备当前操作系统(版本1.0)对应的分区结构如图4所示，最新版本的操作系统(版本2.0)对应的分区结构如图7所示。在设备存储器上，当前的分区结构除包含图4 所示分区以及子分区以外，还包含reserve分区。设备当前的分区表的一部分如表3所示。而操作系统升级包所包含的分区表的一部分如表4所示。并且，操作系统升级数据包含静态分区子分区A的数据。

在操作系统升级包中，操作系统升级数据通常被打包为update_base.zip。在S910中，设备在获取操作系统升级包的同时还获取到针对操作系统升级包的描述文件(filelist文件)，该 filelist文件用于描述update_base.zip的相关信息，例如，filelist文件中包括update_base.zip所针对的操作系统版本号、update_base.zip的哈希值等。

在S910所获取的操作系统升级包中，update_base.zip中包含最新版本的操作系统所对应的分区结构的分区表。

具体的，在生成操作系统升级包以及对应操作系统升级包的filelist文件的过程中：

将分区表镜像单独打包成update_ptable.zip(按update_base.zip包类型打包)，update_ptable.zip签名后打入到update_base.zip中，再整体签名。

图9b所示为根据本申请一实施例的操作系统升级包内部文件构成示意图。如图9b所示， update_ptable.zip将分区表镜像(update_ptable.zip)打包在根目录。在update_ptable.zip中， ptable.img为分区表镜像文件。

在操作系统升级包的filelist文件中增加分区升级包标志，该分区升级包标志用于标识当前操作系统升级包中的update_base.zip包含最新版本的分区表。

进一步的，包含分区表的操作系统升级包被配置为关键节点包，在进行操作系统升级的过程中，跨版本的升级操作不能跳过关键节点包。即，设备必须首先基于关键节点包升级操作系统(重新配置分区结构)后，才能升级到关键节点包之后的版本的操作系统。例如，版本2.0 之前的操作系统对应图4所示的分区结构。版本2.0开始，操作系统对应图7所示的分区结构。版本2.0的操作系统的操作系统升级包就为关键节点包。假设设备当前的操作系统版本为1.0，最新的操作系统为2.1，设备不能直接升级到版本2.1的操作系统，而必须首先基于版本2.0的操作系统升级包升级到版本2.0的操作系统(重新配置分区结构为图7所示分区结构)，才能继续升级到版本2.1。

S911，检测本次操作系统升级是否需要更新分区表。具体的，检测S910所获取的，针对操作系统升级包的filelist文件里是否包含分区升级包标志。

如果不包含，则说明update_base.zip不包含分区表，本次操作系统升级不需要更新分区表，执行S912，基于操作系统升级包中的操作系统升级数据(update_base.zip)进行操作系统升级， S912的执行参照S520～S551。

如果filelist文件里包含分区升级包标志。则说明update_base.zip包含分区表，本次操作系统升级需要更新分区表，执行S913，重启并进入恢复(Recovery)模式。

S914，在恢复(Recovery)模式下，使用update_base.zip中的分区表更新设备存储器上的分区表；

S920，重启设备，依次加载基础分区(Common)、静态分区(A)以及动态分区(Super)，从静态分区(A)启动。

S921，基于操作系统升级包中的操作系统升级数据(update_base.zip)进行操作系统升级， S921的执行参照S520～S551。

根据图9a所示实施例的方法，可以针对采用虚拟A/B升级方案的操作系统进行升级并在升级过程中更新设备存储器的分区表。本申请实施例的升级方案大大简化了设备分区表更新的操作难度，提高了用户体验。根据图9a所示实施例的方法，可以针对采用虚拟A/B升级方案的操作系统进行升级并在升级过程中更新设备存储器的分区表；根据图9a所示实施例的方法，不需要准备烧录工具，设备基于下载的操作系统升级包就可以自行完成分区表的更新；根据图 9所示实施例的方法大大简化了设备分区表更新的操作难度，提高了用户体验。

具体的，操作升级操作是由设备上安装的操作系统更新程序所完成的。具体的，升级包获取工具(update apk clent)以及升级引擎(update engine)是操作系统中的两个模块。升级包获取工具(update apk clent)用于获取操作系统的升级安装包，将操作系统升级包下载并保存到用户数据分区(Userdata)。参照S210。

例如，升级包获取工具(update apk clent)定期向搜包服务器发起搜包请求，搜包请求包含设备当前操作系统版本号(例如版本1.1)、设备SN号、产品型号、制式等信息(例如版本 1.1)；搜包服务器根据搜包请求中的操作系统版本号，检索安装包服务器上是否存在更新版本号的操作系统安装包(例如版本1.2)；当存在更新版本的操作系统安装包时，搜包服务器向升级包获取工具(update apk clent)反馈操作系统升级包(例如，由版本1.1升级到版本1.2的操作系统升级包)的下载地址(例如，URL地址)以及系统升级安装包对应的filelist文件；升级包获取工具(update apk clent)根据操作系统升级包的下载地址从安装包服务器下载操作系统升级包。

当升级包获取工具(update apk clent)获取到操作系统升级包后，其启动升级引擎(update engine)，由升级引擎(update engine)根据操作系统升级包进行操作系统的升级。

具体的，当升级包获取工具(update apk clent)获取到操作系统升级包后，升级包获取工具(update apk clent)设置升级引擎(update engine)的启动属性，将启动属性设置为true。常驻操作系统后台的服务servicemanger会监控升级引擎(update engine)302的启动属性，当 servicemanger检测到升级引擎(update engine)的启动属性为true时，servicemanger启动升级引擎(update engine)。

升级包获取工具(update apk clent)通过binder通信获取升级引擎(updateengine)的状态，当升级包获取工具(update apk clent)确认升级引擎(update engine)成功启动时，升级包获取工具(update apk clent)向升级引擎(update engine)传递升级参数(例如，当前的升级操作是文件更新操作还是文件落盘操作)，触发升级引擎(updateengine)进入升级流程。具体的升级流程可以参照S520～S551。

在本申请一实施例中，基于升级包获取工具(update apk clent)实现S911。具体的，图10 所示为根据本申请一实施例进行操作系统升级的流程图。设备执行如图10所示以实现包含分区架构重新配置的操作系统升级。

S1000，升级服务器推送发布最新版本的、用于更新分区表的操作系统升级包。

设备依次加载基础分区(Common)、静态分区(A)以及动态分区(Super)，从静态分区 (A)启动。S1000可以在设备启动后执行，也可以在设备启动前执行。设备在从静态分区(A) 启动的状态下，update apk clent执行S1010，获取操作系统升级包，操作系统升级包的获取过程可以参照S910。

S1011，update apk clent检测针对操作系统升级包的filelist文件里是否包含分区升级包标志。参照S911。

由于update apk clent获取的操作系统升级包为用于更新分区表的操作系统升级包，因此，针对操作系统升级包的filelist文件里包含分区升级包标志。执行S1012，update apk clent判断是否已使用操作系统升级包进行过更新分区表操作。在当前执行的S1012中，update apk clent 判定尚未使用操作系统升级包进行过更新分区表操作。因此，执行S1013，update apk clent执行分区表更新准备操作。

在update apk clent完成分区表更新准备操作后，执行S1014，update apk clent触发设备重启(第一次重启)，重启后的设备进入Recovery模式。

S1020，在Recovery模式下，设备使用操作系统升级包中的分区表更新设备存储器上的分区表。

在Recovery模式下，当设备完成分区表的更新后，执行S1021，触发设备再次重启(第二次重启)，重启后的设备依次加载基础分区(Common)、静态分区(A)以及动态分区(Super)，从静态分区(A)启动。

设备在从静态分区(A)启动的状态下，update apk clent再次执行S1012，判断是否已使用操作系统升级包进行过更新分区表操作。在再次执行的S1012中，update apkclent判定已使用操作系统升级包进行过更新分区表操作。因此，update apk clent执行S1030，触发update engine进入升级流程。

在升级流程中，update engine执行S1031，校验操作系统升级包。具体的，校验操作系统升级包的数字签名是否合法，确认操作系统升级包是否为合法的升级包。

当操作系统升级包通过校验后，update engine执行S1032，根据操作系统升级包升级静态分区以及动态分区的数据，具体参照S520、S530以及S531。

在update engine完成S1032的升级操作后，update engine执行S1033，向updateapk clent 返回升级操作完成的状态信息。

S1040，update apk clent触发设备重启(第三次重启)，例如，向用户弹框提示，用户用选择立即重启或稍后重启。

设备重启后依次加载基础分区(Common)、静态分区(B)以及动态分区(Super)，从静态分区(B)启动。参照S540以及S541。

设备从静态分区(B)启动后，update apk clent执行S1041，update apk clent触发update engine进入merge流程。

S1042，update engine执行merge流程，参照S551。merge流程完成后设备的操作系统完成升级。

具体的，图11所示为根据本申请一实施例进行操作系统升级的部分流程图。

在S1010中，升级包获取工具(update apk clent)获取操作系统升级包以及filelist文件。在此之后，S1011～S1014执行如图11所示的下述步骤。

S1100，升级包获取工具(update apk clent)解析filelist文件，判断filelist文件中是否包含分区升级包标志；

如filelist文件中不包含分区升级包标志，S1101，设备根据操作系统升级包进行操作系统升级。具体的，升级包获取工具(update apk clent)启动升级引擎(updateengine)，由升级引擎(update engine)根据操作系统升级包升级静态分区(B)以及动态分区，重启设备从静态分区(B)启动，升级包获取工具(update apk clent)启动升级引擎(update engine)进行落盘操作。参照S520～S551。

如filelist文件中包含分区升级包标志，S1102(即S1012)，升级包获取工具(update apk clent)判断分区表是否已被更新。

具体的，在S1102中，升级包获取工具(update apk clent)根据保存在common分区的元数据(/metadata)中的分区更新标志位(ptable oeminfo)的状态来判断分区表是否已被更新。当ptable oeminfo＝0(状态为未更新)时，分区表未被更新；当ptable oeminfo＝1(状态为已更新)时，分区表已被更新；ptable oeminfo默认的初始状态为0。

在设备尚未使用操作系统升级包进行过更新分区表操作时，ptable oeminfo＝0时，升级包获取工具(update apk clent)执行分区表更新准备操作，分区表更新准备操作(即S1013)包括S1110～S1111：

S1110，从update_base.zip中提取update_ptable.zip，将update_ptable.zip解压后保存到缓存分区(cache目录)。

S1111，写针对分区表更新的command命令(CMD)。具体的，将command命令写入到缓存分区(cache目录)，该command命令用于指示设备执行更新分区表的流程。

例如，update_ptable.zip包含分区表镜像ptable.img以及ptable.img的哈希值H1。在S1111 中，写入command命令，command命令包含指向流程(1)的执行流程标识符(Process1)。

流程(1)包括下述步骤：

计算ptable.img的哈希值H2；

对比H1以及H2；

如不同，报错并重启设备(设备重启后加载基础分区(Common)、静态分区(A)以及动态分区(Super)，从静态分区(A)启动)；

如相同，读取设备当前的分区表(假设设备当前的分区表为ptable0)；

打开ptable.img(假设ptable.img打开后为ptable1)；

验证ptable0与ptable1中名称一致的分区的分区地址起始位置-终止位置是否一致；

如果ptable0与ptable1中名称一致的分区的分区地址起始位置-终止位置不一致，报错并重启设备(设备重启后加载基础分区(Common)、静态分区(A)以及动态分区(Super)，从静态分区(A)启动)；

如果ptable0与ptable1中所有名称一致的分区的分区地址起始位置-终止位置一致，使用 ptable.img更新设备存储器上当前的分区表(更新ptable0为ptable1)；

配置ptable oeminfo＝1；

重启设备(设备重启后加载基础分区(Common)、静态分区(A)以及动态分区(Super)，从静态分区(A)启动)。

在S1111后，update apk clent完成分区表更新准备操作。之后update apk clent执行S1112，记录断点，记录操作系统当前的升级进度，当设备重启进入操作系统后，操作系统升级操作从 S1102开始。

在S1112后，update apk clent完成分区表更新准备操作，update apk clent触发设备重启(第一次重启)，具体的，update apk clent执行S1113，弹出对话框，提示用户当前的操作系统升级需要重启设备。

具体的，S1010、S1100、S1110、S1111以及S1112的执行均可以在用户正常使用手机的过程中后台执行。

具体的，图12为根据本申请一实施例的手机运行界面示意图。当手机顺利启动操作系统后，进入如图12中1201所示的系统界面。手机进行操作系统升级(执行S1010、S1100、S1110、 S1111以及S1112)，手机的显示界面可以为图12中1202所示的界面，从而向用户展示操作系统升级进度。S1010、S1100、S1110、S1111以及S1112的执行也可以在系统后台运行，用户在手机运行S1010、S1100、S1110、S1111以及S1112时可以切换至1201所示的系统界面，打开其他应用；或者，用户在手机运行S1010、S1100、S1110、S1111以及S1112时可以切换至系统正在运行的其他应用的应用界面，例如，1203所示的聊天应用界面。

在S1113中，当手机需要重启时，手机向用户输出重启提示，由用户确认是否立即重启。

例如，图13为根据本申请一实施例的手机运行界面示意图。手机当前展示如图12中1202 所示的界面，向用户展示操作系统升级进度。在S1113中，手机展示如图13中1303所示的界面，由用户确认立即重启或是稍后重启。

又例如，手机当前展示如图12中1203所示的界面，用户使用聊天应用。在S1113中，手机展示如图13中1301所示的界面，弹出提示通知。用户点击提示通知，进入如图13中1303所示的界面，由用户确认立即重启或是稍后重启。或者，用户打开下拉通知栏，手机展示如图 13中1302所示的界面。在下拉通知栏中，用户点击提示通知，进入如图13中1303所示的界面，由用户确认立即重启或是稍后重启。

具体的，在S1113中，如果用户点击重启按钮，执行S1120(即S1014)，设备重启，重启后的设备进入恢复(Recovery)模式。

在S1113中，如果用户点击稍后按钮，执行S1121，设备暂停升级流程，并在预设的定时升级节点重新启动升级流程，升级流程启动后设备重启，重启后的设备进入恢复(Recovery) 模式。

图14所示为根据本申请一实施例进行操作系统升级的部分流程图。在S1120或S1121之后，设备重启进入恢复(Recovery)模式，在恢复(Recovery)模式下，设备执行如图14所示的流程。

具体的，S1020～S1021包括：

S1400，挂载缓存数据，具体的，挂载cache目录下的数据(update_ptable.zip解压内容以及S1111写的command命令)；

S1410，解析command命令，具体的，解析S1111写的command命令；

S1420，根据command命令，调用流程(1)的执行代码。

例如，解析获取command命令中指向流程(1)的执行流程标识符(Process1)。根据执行流程标识符(Process1)调取预存的、对应Process1的执行流程(流程(1))的执行代码，执行流程(1)的执行代码从而实现流程(1)。具体的，在S1420中，设备对挂载的ptable.img进行哈希值校验；校验通过后验证ptable.img是否可用；当ptable.img可用时刷新设备存储器上原有的分区表；刷新成功后重启设备(第二次重启)。

S1420的具体执行参照S1111中流程(1)的描述。

在S1420之后，设备加载基础分区(Common)、静态分区(A)以及动态分区(Super)，从静态分区(A)启动。在操作系统启动后，设备加载S1112保存的断点，从S1102开始继续进行操作系统升级操作，再次执行S1102。

S1102，升级包获取工具(update apk clent)判断分区表是否已被更新。

具体的，在S1420中，设备执行S1111写的command命令所对应的流程(1)，在分区表被成功更新后配置ptable oeminfo＝1。因此，在再次执行的S1102中，升级包获取工具(update apk clent)读取到保存在common分区的元数据(/metadata)中的分区更新标志位(ptable oeminfo) 为ptable oeminfo＝1时，分区表已被更新。

因此，在再次执行的S1102后，执行S1101(即S1030)，设备根据操作系统升级包进行操作系统升级。参照S520～S551。进一步的，在S1101中，在操作系统升级成功后，升级引擎 (update engine)配置ptable oeminfo＝0。具体的，在S531中，升级引擎(updateengine)配置 ptable oeminfo＝0。

进一步的，在另一实施例中，基于升级引擎(update engine)实现S911。具体的，图15所示为根据本申请一实施例进行操作系统升级的流程图。设备执行如图15所示以实现包含分区架构重新配置的操作系统升级。

S1500，升级服务器推送发布最新版本的、用于更新分区表的操作系统升级包。

设备依次加载基础分区(Common)、静态分区(A)以及动态分区(Super)，从静态分区 (A)启动。S1500可以在设备启动后执行，也可以在设备启动前执行。设备在从静态分区(A) 启动的状态下，update apk clent执行S1510，获取操作系统升级包，操作系统升级包的获取过程可以参照S910。

S1511，update apk clent触发update engine进入升级流程。在升级流程中，update engine执行S1520，校验操作系统升级包。具体的，校验操作系统升级包的数字签名是否合法，确认操作系统升级包是否为合法的升级包。

当操作系统升级包通过校验后，update engine执行S1521，检测针对操作系统升级包的 filelist文件里是否包含分区升级包标志。参照S911。

由于update apk clent获取的操作系统升级包为用于更新分区表的操作系统升级包，因此，针对操作系统升级包的filelist文件里包含分区升级包标志。执行S1522，update engine判断是否已使用操作系统升级包进行过更新分区表操作。在当前执行的S1522中，update engine判定尚未使用操作系统升级包进行过更新分区表操作。因此，执行S1523，update engine执行分区表更新准备操作。

在update engine完成分区表更新准备操作后，update engine执行S1524，向update apk clent 返回分区表更新准备操作完成的状态信息。

在update apk clent确认update engine完成分区表更新准备操作后，updateapk clent执行 S1530，触发设备重启(第一次重启)，重启后的设备进入Recovery模式。

S1540，在Recovery模式下，设备使用操作系统升级包中的分区表更新设备存储器上的分区表。参照S1020。

在Recovery模式下，当设备完成分区表的更新后，执行S1541，触发设备再次重启(第二次重启)，重启后的设备依次加载基础分区(Common)、静态分区(A)以及动态分区(Super)，从静态分区(A)启动。

设备在从静态分区(A)启动的状态下，update apk clent再次执行S1511，触发update engine 进入升级流程。update engine再次执行S1520，校验操作系统升级包。

当操作系统升级包通过校验后，update engine再次执行S1521，检测针对操作系统升级包的filelist文件里是否包含分区升级包标志。

update engine再次执行S1522，判断是否已使用操作系统升级包进行过更新分区表操作。在当前执行的S1522中，update engine判定已使用操作系统升级包进行过更新分区表操作。因此，执行S1525，根据操作系统升级包升级静态分区以及动态分区的数据，具体参照S520、 S530以及S531。

在update engine完成S1525的升级操作后，update engine执行S1526，向updateapk clent 返回升级操作完成的状态信息。

S1550，update apk clent触发设备重启(第三次重启)，例如，向用户弹框提示，用户用选择立即重启或稍后重启。

设备从静态分区(B)启动后，update apk clent执行S1551，update apk clent触发update engine进入merge流程。

S1552，update engine执行merge流程，参照S551。merge流程完成后设备的操作系统完成升级。

具体的，图16所示为根据本申请一实施例进行操作系统升级的部分流程图。

在S1510中，升级包获取工具(update apk clent)获取操作系统升级包以及filelist文件。在此之后，设备执行如图16所示的下述步骤实现S1511～S1530。

S1600，升级包获取工具(update apk clent)启动升级引擎(update engine)。

S1601，升级引擎(update engine)校验操作系统升级包。

校验成功后，升级引擎(update engine)执行S1610，解析filelist文件，判断filelist文件中是否包含分区升级包标志；

如filelist文件中不包含分区升级包标志，执行S1611,根据操作系统升级包进行操作系统的升级。具体的，update engine根据操作系统升级包升级静态分区以及动态分区的数据，具体参照S520、S530以及S531。update apk clent触发设备重启，设备重启后依次加载基础分区 (Common)、静态分区(B)以及动态分区(Super)，从静态分区(B)启动。设备从静态分区 (B)启动后，update apk clent触发update engine进入merge流程。updateengine执行merge 流程，merge流程完成后设备的操作系统完成升级。参照S520～S551。

如filelist文件中包含分区升级包标志，升级引擎(update engine)执行S1612，升级引擎 (update engine)判断分区表是否已被更新。参照S1102，ptable oeminfo＝0，升级引擎(update engine)执行分区表更新准备操作。分区表更新准备操作包括：

S1620，从update_base.zip中提取update_ptable.zip，将update_ptable.zip解压后保存到缓存分区(cache目录)。

S1621，写针对分区表更新的command命令(CMD)。参照S1111。

在分区表更新准备操作完成之后，update engine执行S1622，向update apkclent返回分区表更新准备操作完成的状态信息。

在update apk clent确认update engine完成分区表更新准备操作后，updateapk clent执行 S1630，记录断点，记录操作系统当前的升级进度，当设备重启进入操作系统后，操作系统升级操作从S1600开始。

S1631、S1632、S1633，参照S1113、S1120、S1121。

在S1632或S1633之后，设备重启进入恢复(Recovery)模式，在恢复(Recovery)模式下，设备执行如图14所示的流程：S1400～S1420。

在恢复(Recovery)模式下重启设备之后，设备加载基础分区(Common)、静态分区(A) 以及动态分区(Super)，从静态分区(A)启动。在操作系统启动后，设备加载S1630保存的断点，继续进行操作系统升级操作。如图15所示，操作系统升级操作从S1600开始再次执行后续流程，在S1610中，升级引擎(update engine)解析filelist文件，判断filelist文件中包含分区升级包标志。

在恢复(Recovery)模式下，设备执行S1621写的command命令对应的流程(1)，在分区表被成功更新后配置ptable oeminfo＝1。因此，在再次执行的S1612中，升级引擎(update engine)读取到保存在common分区的元数据(/metadata)中的分区更新标志位(ptable oeminfo) 为ptable oeminfo＝1时，分区表已被更新。

因此，在再次执行的S1612之后，执行S1611，根据操作系统升级包进行操作系统的升级。

进一步的，在S1611中，在操作系统升级成功后，升级引擎(update engine)配置ptable oeminfo＝0。参照S1101。

可以理解的是，上述实施例中的部分或全部步骤或操作仅是示例，本申请实施例还可以执行其它操作或者各种操作的变形。此外，各个步骤可以按照上述实施例呈现的不同的顺序来执行，并且有可能并非要执行上述实施例中的全部操作。

进一步的，一般的，对于一个技术的改进可以很明显地区分是硬件上的改进(例如，对二极管、晶体管、开关等电路结构的改进)还是软件上的改进(对于方法流程的改进)。然而，随着技术的发展，当今的很多方法流程的改进已经可以视为硬件电路结构的直接改进。设计人员几乎都通过将改进的方法流程编程到硬件电路中来得到相应的硬件电路结构。因此，不能说一个方法流程的改进就不能用硬件实体模块来实现。例如，可编程逻辑器件(Programmable Logic Device,PLD)(例如现场可编程门阵列(Field ProgrammableGate Array，FPGA))就是这样一种集成电路，其逻辑功能由访问方对器件编程来确定。由设计人员自行编程来把一个数字装置“集成”在一片PLD上，而不需要请芯片制造厂商来设计和制作专用的集成电路芯片。而且，如今，取代手工地制作集成电路芯片，这种编程也多半改用“逻辑编译器(logic compiler)”软件来实现，它与程序开发撰写时所用的软件编译器相类似，而要编译之前的原始代码也得用特定的编程语言来撰写，此称之为硬件描述语言(Hardware Description Language，HDL)，而 HDL也并非仅有一种，而是有许多种，如ABEL(Advanced Boolean Expression Language)、 AHDL(Altera Hardware DescriptionLanguage)、Confluence、CUPL(Cornell University Programming Language)、HDCal、JHDL(Java Hardware Description Language)、Lava、Lola、 MyHDL、PALASM、RHDL(RubyHardware Description Language)等，目前最普遍使用的是 VHDL(Very-High-SpeedIntegrated Circuit Hardware Description Language)与Verilog。本领域技术人员也应该清楚，只需要将方法流程用上述几种硬件描述语言稍作逻辑编程并编程到集成电路中，就可以很容易得到实现该逻辑方法流程的硬件电路。

因此，本申请实施例所提出的方法流程可以以硬件方式实现，例如，使用控制器，控制器控制触摸屏以实现本申请实施例所提出的方法流程。

控制器可以按任何适当的方式实现，例如，控制器可以采取例如微处理器或处理器以及存储可由该(微)处理器执行的计算机可读程序代码(例如软件或固件)的计算机可读介质、逻辑门、开关、专用集成电路(Application Specific Integrated Circuit，ASIC)、可编程逻辑控制器和嵌入微控制器的形式，控制器的例子包括但不限于以下微控制器：ARC 625D、Atmel AT91SAM、Microchip PIC18F26K20以及Silicone Labs C8051F320，存储器控制器还可以被实现为存储器的控制逻辑的一部分。本领域技术人员也知道，除了以纯计算机可读程序代码方式实现控制器以外，完全可以通过将方法步骤进行逻辑编程来使得控制器以逻辑门、开关、专用集成电路、可编程逻辑控制器和嵌入微控制器等的形式来实现相同功能。因此这种控制器可以被认为是一种硬件部件，而对其内包括的用于实现各种功能的装置也可以视为硬件部件内的结构。或者甚至，可以将用于实现各种功能的装置视为既可以是实现方法的软件模块又可以是硬件部件内的结构。

与上述实施例对应，本申请还提供了一种电子设备。电子设备包括用于存储计算机程序指令的存储器和用于执行程序指令的处理器，其中，当该计算机程序指令被该处理器执行时，触发电子设备执行如本申请实施例所述的方法步骤。

本申请还提供一种计算机程序产品，计算机程序产品包括计算机程序，当其在计算机上运行时，使得计算机执行本申请实施例提供的部分或全部步骤。

本领域的技术人员可以清楚地了解到本发明实施例中的技术可借助软件加必需的通用硬件平台的方式来实现。基于这样的理解，本发明实施例中的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品可以存储在存储介质中，如ROM/RAM、磁碟、光盘等，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本发明各个实施例或者实施例的某些部分所述的方法。

本说明书中各个实施例之间相同相似的部分互相参见即可。尤其，对于装置实施例和终端实施例而言，由于其基本相似于方法实施例，所以描述的比较简单，相关之处参见方法实施例中的说明即可。

Claims

1.一种升级操作系统的方法，其特征在于，应用于电子设备，所述电子设备包括处理器以及存储器，所述存储器包括基础分区、第一静态分区、第二静态分区、动态分区以及用户数据分区，所述电子设备当前的分区表为对应第一操作系统的第一分区表，所述电子设备启动后加载所述基础分区、所述第一静态分区以及动态分区的数据以运行所述第一操作系统，所述第一操作系统运行之后，所述方法包括：

获取操作系统升级包，所述操作系统升级包包括对应第二操作系统的第二分区表以及操作系统升级数据，所述操作系统升级数据用于将所述第一操作系统升级到所述第二操作系统，其中，在所述第二分区表以及所述第一分区表中，名称相同的分区的地址配置一致；

触发所述电子设备的第一次重启，在所述第一次重启之后，所述电子设备进入恢复模式；

在所述恢复模式下，将所述电子设备的分区表更新为所述第二分区表；

触发所述电子设备的第二次重启，在所述第二次重启之后，所述电子设备加载所述基础分区、所述第一静态分区以及动态分区的数据以运行所述第一操作系统；

根据所述操作系统升级数据升级所述电子设备的操作系统，将所述第一操作系统升级为所述第二操作系统。

2.根据权利要求1所述的方法，其特征在于，所述重启所述电子设备，进入恢复模式之前，所述方法还包括：

执行分区表更新准备操作，所述分区表更新准备操作用于配置所述电子设备在所述恢复模式下的执行流程。

3.根据权利要求2所述的方法，其特征在于，所述执行分区表更新准备操作，包括：

将所述第二分区表保存到缓存；

在所述缓存中写入第一控制命令，所述第一控制命令对应第一操作流程，所述第一操作流程用于将所述电子设备的分区表更新为所述第二分区表。

4.根据权利要求3所述的方法，其特征在于，所述第一操作流程包括：

校验所述第二分区表；

所述第二分区表校验成功后，验证所述第二分区表以及所述第一分区表中，名称相同的分区的地址配置是否一致；

当所述第二分区表以及所述第一分区表中，名称相同的分区的地址配置一致时，使用所述第二分区表更新所述电子设备的分区表。

5.根据权利要求3所述的方法，其特征在于，所述在所述恢复模式下，将所述电子设备的分区表更新为所述第二分区表，包括：

加载所述缓存中的所述第二分区表以及所述第一控制命令；

解析所述第一控制命令，根据所述第一控制命令调用所述第一操作流程的执行代码；

执行所述第一操作流程的执行代码。

6.根据权利要求2～5中任一项所述的方法，其特征在于，所述执行分区表更新准备操作之前，所述方法还包括：

确认所述操作系统升级包是否用于更新分区；

当所述操作系统升级包用于更新分区时，确认所述电子设备的分区表是否已基于所述第二分区表进行过更新；

当所述电子设备的分区表未基于所述第二分区表进行过更新时，执行所述分区表更新准备操作。

7.根据权利要求6所述的方法，其特征在于，所述确认所述操作系统升级包是否用于更新分区，包括：

解析所述操作系统升级包对应的描述文件，当所述描述文件中包含分区升级包标志时，所述操作系统升级包用于更新分区。

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

所述确认所述电子设备的分区表是否已基于所述第二分区表进行过更新，其中，根据分区更新标志位的状态确认所述电子设备的分区表是否已基于所述第二分区表进行过更新，在所述获取操作系统升级包之前，所述分区更新标志位的状态为未更新；

所述在所述恢复模式下，将所述电子设备的分区表更新为所述第二分区表，包括，将所述分区更新标志位的状态设置为已更新；

所述根据所述操作系统升级数据升级所述电子设备的操作系统，将所述第一操作系统升级为所述第二操作系统，包括，将所述分区更新标志位的状态设置为未更新。

9.根据权利要求6～8中任一项所述的方法，其特征在于，在所述根据所述操作系统升级数据升级所述电子设备的操作系统之前，所述方法还包括：

在所述第二次重启之后，在所述第一操作系统运行之后，再次确认所述电子设备的分区表是否已基于所述第二分区表进行过更新；

当确认所述电子设备的分区表已基于所述第二分区表进行过更新时，根据所述操作系统升级数据升级所述电子设备的操作系统。

10.根据权利要求9所述的方法，其特征在于，所述第一操作系统包括第一升级包获取工具以及第一升级引擎，所述第一操作系统运行之后，所述方法包括：

所述第一升级包获取工具获取所述操作系统升级包；

所述第一升级包获取工具确认所述操作系统升级包是否用于更新分区；

当所述操作系统升级包用于更新分区时，所述第一升级包获取工具确认所述电子设备的分区表是否已基于所述第二分区表进行过更新；

当所述电子设备的分区表未基于所述第二分区表进行过更新时，所述第一升级包获取工具执行所述分区表更新准备操作；

所述第一升级包获取工具记录第一升级流程断点，所述第一升级流程断点对应所述确认所述电子设备的分区表是否已基于所述第二分区表进行过更新；

所述第一升级包获取工具触发所述第一次重启；

所述第一次重启之后，所述电子设备进入所述恢复模式，在所述恢复模式下，所述电子设备的分区表被更新为所述第二分区表，之后，所述电子设备的分区表已基于所述第二分区表进行过更新；

在所述恢复模式下，触发所述第二次重启；

所述第二次重启之后，所述电子设备加载所述基础分区、所述第一静态分区以及动态分区的数据以运行所述第一操作系统；

所述第一操作系统运行之后，所述第一升级包获取工具读取所述第一升级流程断点，再次确认所述电子设备的分区表是否已基于所述第二分区表进行过更新；

当所述第一升级包获取工具确认所述电子设备的分区表已基于所述第二分区表进行过更新，所述第一升级包获取工具触发所述第一升级引擎根据所述操作系统升级数据升级所述电子设备的操作系统。

11.根据权利要求9所述的方法，其特征在于，所述第一操作系统包括第二升级包获取工具以及第二升级引擎，所述第一操作系统运行之后，所述方法包括：

所述第二升级包获取工具获取所述操作系统升级包；

所述第二升级包获取工具触发所述第二升级引擎进入升级流程；

所述第二升级引擎确认所述操作系统升级包是否用于更新分区；

当所述操作系统升级包用于更新分区时，所述第二升级引擎确认所述电子设备的分区表是否已基于所述第二分区表进行过更新；

当所述电子设备的分区表未基于所述第二分区表进行过更新时，所述第二升级引擎执行所述分区表更新准备操作；

所述第二升级引擎向所述第二升级包获取工具返回所述分区表更新准备操作执行完成的状态信息；

所述第二升级包获取工具记录第二升级流程断点，所述第二升级流程断点对应所述第二升级包获取工具触发所述第二升级引擎进入升级流程；

所述第二升级包获取工具触发所述电子设备的第三重启；

所述第三重启之后，所述电子设备进入所述恢复模式，在所述恢复模式下，所述电子设备的分区表被更新为所述第二分区表，之后，所述电子设备的分区表已基于所述第二分区表进行过更新；

在所述恢复模式下，触发所述电子设备的第四重启；

所述第四重启之后，所述电子设备加载所述基础分区、所述第一静态分区以及动态分区的数据以运行所述第一操作系统；

所述第一操作系统运行之后，所述第二升级包获取工具读取所述第二升级流程断点，再次触发所述第二升级引擎进入升级流程；

所述第二升级引擎再次确认所述操作系统升级包是否用于更新分区；

当所述操作系统升级包用于更新分区时，所述第二升级引擎再次确认所述电子设备的分区表是否已基于所述第二分区表进行过更新；

当所述电子设备的分区表未基于所述第二分区表进行过更新时，所述第二升级引擎根据所述操作系统升级数据升级所述电子设备的操作系统。

12.根据权利要求1所述的方法，其特征在于，所述操作系统升级数据还包括静态分区升级数据以及动态分区升级数据，所述根据所述操作系统升级数据升级所述电子设备的操作系统，包括：

基于所述静态分区升级数据升级所述第二静态分区的数据；

在所述用户数据分区中创建虚拟动态分区，将所述动态分区升级数据写入到所述虚拟动态分区；

将所述电子设备的启动顺序由从所述第一静态分区启动，修改为从所述第二静态分区启动；

触发所述电子设备的第三次重启；

在所述第三次重启之后，所述电子设备加载所述基础分区、所述第二静态分区、所述动态分区以及所述虚拟动态分区的数据以运行所述第二操作系统；

在所述第二操作系统运行后，将所述虚拟动态分区的数据落盘到所述动态分区。

13.一种电子设备，其特征在于，所述电子设备包括处理器以及存储器，所述存储器包括基础分区、第一静态分区、第二静态分区、动态分区以及用户数据分区，所述动态分区包括多个子分区，所述处理器用于执行所述存储器上存储的软件代码，以使得所述电子设备启动后加载所述基础分区、所述第一静态分区以及所述动态分区的数据以运行第一操作系统；

并且，在所述第一操作系统运行之后，使得所述电子设备执行如权利要求1～12中任一项所述的方法流程。

14.一种计算机可读存储介质，其特征在于，所述计算机可读存储介质中存储有计算机程序，当其在计算机上运行时，使得计算机执行如权利要求1～12中任一项所述的方法。

15.一种计算机程序产品，其特征在于，所述计算机程序产品包括计算机程序，当其在计算机上运行时，使得计算机执行如权利要求1～12中任一项所述的方法。