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

摘要

本申请实施例提供的一种升级操作系统的方法、设备、存储介质及计算机程序产品，方法应用于电子设备，方法包括：获取第一升级安装包，第一升级安装包包括针对的第一升级文件；在用户数据分区中保存第一升级文件；重启电子设备，加载基础分区、第二静态分区的数据；加载动态分区中第一子分区以外的其他子分区的数据，以及，加载第一升级文件；将第一升级文件落盘到动态分区的第一子分区；方法还包括，将第一静态分区的数据同步到第二静态分区。根据本申请实施例的方法，可以针对动态分区中的定制子分区进行独立升级，以实现针对定制操作系统的升级。

说明书

技术领域

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

背景技术

在现有技术的应用场景中，用户终端需要安装操作系统才可以被用户使用。例如，手机上需要安装手机操作系统(例如：IOS系统、安卓系统)才可以被用户使用。一般的，终端设备的操作系统由操作系统供应商提供(例如，安卓系统的操作系统供应商为谷歌)，而通常状况下，操作系统供应商所提供的操作系统是基础操作系统，其仅包含最基础的功能，其并不能完全满足用户的应用需求。因此，为了提升用户体验，终端设备供应商会根据客户需求、应用场景的不同，对基础操作系统进行优化，在基础操作系统的基础上增加定制内容，构建定制操作系统。在终端设备上安装定制操作系统，以使得终端设备可以提供优化的系统功能。例如，在手机出厂前，在安卓系统中增加指定网络运营商的客户服务系统，令手机开机后可以登录用户在该网络运营商下的用户账户以实现计费充值等功能。

在终端设备安装操作系统后，当操作系统出现版本升级时，需要升级终端设备上所安装的操作系统。一般的，操作系统的升级方案是由操作系统供应商提供。但是，由于操作系统供应商提供的操作系统是基础操作系统，因此，操作系统供应商提供的操作系统升级方案也是对应基础操作系统的。而定制操作系统与操作系统供应商提供的基础操作系统并不相同，其无法完全沿用基础操作系统的升级方法，因此，需要一种针对定制操作系统的操作系统升级方法。

发明内容

有鉴于此，本申请提供一种升级操作系统的方法、设备、存储介质及计算机程序产品，以利于解决现有技术中针对定制操作系统进行升级的问题。

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

获取第一升级安装包，所述第一升级安装包包括第一升级文件，所述第一升级文件为针对第一子分区的升级文件，所述第一子分区为所述动态分区的一个子分区；

在所述用户数据分区中创建虚拟动态分区，在所述虚拟动态分区中保存所述第一升级文件；

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

重启所述电子设备，确认当前的启动顺序为从所述第二静态分区启动；

加载所述基础分区的数据；

加载所述第二静态分区的数据；

加载动态分区数据，包括，加载所述动态分区中第一子分区以外的其他子分区的数据，以及，加载所述用户数据分区中的所述第一升级文件；

将所述用户数据分区中的所述第一升级文件落盘到所述动态分区的第一子分区；

其中，所述加载所述第二静态分区的数据之前，所述方法还包括，将所述第一静态分区的数据同步到所述第二静态分区。

在第一方面的一种实现方式中，所述将所述第一静态分区的数据同步到所述第二静态分区，包括：

读取所述第一静态分区的各个子分区中的数据；

将所述第一静态分区的各个子分区中的数据覆写到所述第二静态分区对应的子分区中。

在第一方面的一种实现方式中，所述将所述第一静态分区的数据同步到所述第二静态分区，包括：

计算第三子分区的数据的哈希值，其中，所述第三子分区为所述第一静态分区的一个子分区；

计算第四子分区的数据的哈希值，其中，所述第四子分区为所述第二静态分区的一个子分区，并且，所述第四子分区与所述第三子分区相对应；

当所述第三子分区的数据的哈希值与所述第四子分区的数据的哈希值不一致时，将所述第三子分区中的数据覆写到所述第四子分区中。

在第一方面的一种实现方式中，所述获取第一升级安装包之后，执行所述将所述第一静态分区的数据同步到所述第二静态分区。

在第一方面的一种实现方式中，所述获取第一升级安装包之前，所述方法还包括：

加载所述基础分区、所述第二静态分区以及所述动态分区的数据以运行第二操作系统；

获取第二升级安装包，所述第二升级安装包包括静态分区升级数据；

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

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

重启所述电子设备，确认当前的启动顺序为从所述第一静态分区启动；

加载所述基础分区、所述第一静态分区以及所述动态分区的数据，以运行所述第一操作系统；

其中，在所述重启所述电子设备，确认当前的启动顺序为从所述第一静态分区启动之后，执行所述将所述第一静态分区的数据同步到所述第二静态分区。

在第一方面的一种实现方式中，在加载所述第一静态分区的数据的过程中，在静态分区数据校验成功后，执行所述将所述第一静态分区的数据同步到所述第二静态分区。

在第一方面的一种实现方式中，在加载所述动态分区的数据的过程中，在待加载动态分区文件校验成功后，执行所述将所述第一静态分区的数据同步到所述第二静态分区。

在第一方面的一种实现方式中，所述第二升级安装包还包括动态分区升级数据；

所述重启所述电子设备，确认当前的启动顺序为从所述第一静态分区启动之前，所述方法还包括，在所述用户数据分区中创建虚拟动态分区，在所述虚拟动态分区中保存所述动态分区升级数据；

所述加载所述基础分区、所述第一静态分区以及所述动态分区的数据，以运行所述第一操作系统，包括，加载所述动态分区的数据以及所述动态分区升级数据；

所述加载所述基础分区、所述第一静态分区以及所述动态分区的数据，以运行所述第一操作系统之后，所述方法还包括，将所述动态分区升级数据落盘到所述动态分区；

在所述将所述动态分区升级数据落盘到所述动态分区之后，执行所述将所述第一静态分区的数据同步到所述第二静态分区。

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

所述在所述用户数据分区中创建虚拟动态分区，在所述虚拟动态分区中保存所述第一升级文件，包括：将所述第一升级文件以COW文件的形式保存在所述用户数据分区中；

所述加载动态分区数据，包括，基于快照技术加载所述动态分区以及所述第一升级文件的COW文件中需要加载的文件。

在第一方面的一种实现方式中，将所述用户数据分区中的所述第一升级文件落盘到所述动态分区的第一子分区，包括：

将所述第一升级文件覆写到所述第一子分区；

删除所述用户数据分区中的所述第一升级文件。

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

所述升级安装包还包括第二升级文件，所述第二升级文件为第二子分区的升级文件，所述第二子分区为动态分区的一个子分区；

所述方法还包括：在所述虚拟动态分区中保存所述第二升级文件；

所述加载动态分区数据，包括，加载所述动态分区中第一子分区、第二子分区以外的其他子分区的数据，以及，加载所述用户数据分区中的所述第一升级文件以及第二升级文件；

所述加载动态分区数据之后，所述方法还包括：将所述用户数据分区中的所述第二升级文件落盘到所述动态分区的第二子分区。

在第一方面的一种实现方式中，所述第一升级安装包还包括静态分区关联文件，所述静态分区关联文件与所述第一子分区关联的静态分区文件，所述重启所述电子设备，确认当前的启动顺序为从所述第二静态分区启动之前，执行所述将所述第一静态分区的数据同步到所述第二静态分区；

所述重启所述电子设备，确认当前的启动顺序为从所述第二静态分区启动之前，所述将所述第一静态分区的数据同步到所述第二静态分区之后，所述方法还包括，使用所述第一升级安装包中的静态分区关联文件更新所述第二静态分区中的静态分区关联文件。

在第一方面的一种实现方式中，所述重启所述电子设备，确认当前的启动顺序为从所述第二静态分区启动之后，所述方法还包括，将所述第二静态分区的数据同步到所述第一静态分区。

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

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

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

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

根据本申请实施例所提出的上述技术方案，至少可以实现下述技术效果：

根据本申请实施例的方法，可以针对动态分区中的定制子分区进行独立升级，以实现针对定制操作系统的升级。根据本申请实施例的方法，可以有效降低操作系统升级安装包的数据量，简化操作系统升级流程。

附图说明

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

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

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

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

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

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

图6所示为安卓系统在终端设备上的数据存储结构示意图；

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

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

图9a～图9d所示为根据本申请一实施例的操作系统升级逻辑示意图；

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

图11所示为根据本申请一实施例针对定制分区进行独立升级的升级执行流程图；

图12所示为根据本申请一实施例针对定制分区进行独立升级的升级执行流程图；

图13所示为根据本申请一实施例针对定制分区进行独立升级的升级执行流程图

图14所示为根据本申请一实施例的静态分区同步流程图；

图15所示为根据本申请一实施例的静态分区同步流程图；

图16所示为根据本申请一实施例的静态分区同步流程图；

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

图18所示为根据本申请一实施例的操作系统升级的流程图。

具体实施方式

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

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

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

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

在实际应用场景中，终端设备操作系统存在升级需求，由于操作系统的升级涉及到操作系统的文件修改，而操作系统的部分文件在运行过程中是无法进行修改的，因此，一种可行的操作系统升级方案是退出操作系统的运行状态，进入恢复(Recovery)模式升级操作系统。以手机为例，图1所示为根据本申请一实施例的操作系统升级流程图。假设终端设备当前运行的操作系统版本是1.1，需要升级到版本1.2。终端设备按照如图1所示的流程实现操作系统的升级。

S100，终端设备正常运行在版本1.1的操作系统下，获取版本1.2的操作系统的升级安装包；

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

S110，终端设备重启；

S120，重启后的终端设备并不通过版本1.1操作系统启动，而是进入Recovery模式；

S130，在Recovery模式下，终端设备使用版本1.2的操作系统的升级安装包进行系统升级；

S140，系统升级完毕后，终端设备重启；

S150，重启后的终端设备通过版本1.2的操作系统启动。

在图1所示方案中，终端设备必须重启并进入Recovery模式才可以进行系统升级，在进入Recovery模式后，终端设备的大部分功能是无法使用的，也就是说，在终端设备的操作系统升级的过程中，用户只能等待终端设备进行系统文件的更新升级，而无法正常使用终端设备，这会大大降低用户体验。因此，在一种可行的操作系统升级方案中，不进入Recovery模式升级操作系统，采用A/B升级方案在终端设备正常运行时进行无感知升级。

图2所示为根据本申请一实施例的数据存储结构示意图。如图2所示，终端设备上的数据存储区分为基础分区(Common)、系统分区(A)、系统分区(B)以及用户数据分区(Userdata)四个部分。

用户数据分区(Userdata)用于保存用户的个人数据，例如，用户个人安装的APP、用户个人保存的图片、文档以及视频等个人数据。基础部分中保存的数据为不参与操作系统升级的系统数据，例如，安卓系统数据中的基础(Common)分区。系统分区(A)与系统分区(B)相互独立，其上分别保存有完整的操作系统数据。例如，系统分区(A)以及系统分区(B)均包括静态分区(bootloader、boot、vendor_boot、dtbo、vbmeta)以及动态分区(super)。如图2所示，系统分区(A)包括静态分区(A)以及动态分区(Super)(A)，系统分区(B)包括静态分区(B)以及动态分区(Super)(B)

图3所示为针对图2所示实施例的终端设备存储结构进行操作系统升级的流程图。假设系统分区(A)保存的操作系统数据对应的操作系统版本为1.1。终端设备从系统分区(A)启动从而运行版本1.1的操作系统。如果当前需要升级到版本1.2的操作系统。终端设备按照如图3所示的流程实现操作系统的升级。

S300，终端设备加载基础分区(Common)、系统分区(A)，从系统分区(A)启动，从而运行版本1.1的操作系统；

S310，终端设备获取版本1.2操作系统的操作系统升级安装包；

S320，终端设备根据操作系统升级安装包针对系统分区(B)的操作系统数据进行数据读写操作，将版本1.2的操作系统的操作系统数据写入到系统分区(B)；

在S320中，由于操作系统升级的数据写入操作是针对系统分区(B)进行的，其并不会影响到系统分区(A)的数据，因此，在整个操作系统升级的过程中，用户可以正常使用终端设备。

S330，终端设备重启；

在S320之后，由于系统分区(A)的数据并未发生变化，因此，终端设备并不需要立即重启(不需要立刻执行S330)，可以由用户自行选择重启时机；这样，操作系统的升级过程并不会对用户使用终端设备产生影响，从而大大提高了用户体验。

S340，重启后的终端设备加载基础分区(Common)、系统分区(B)，从系统分区(B)启动，从而运行版本1.2的操作系统，完成操作系统升级。

基于图2、图3所示方案，虽然可以实现在终端设备正常运行时进行无感知升级，但是，在终端设备正常使用时，在非升级状态下，系统分区(A)以及系统分区(B)中只有一个分区被使用，另一分区被闲置，这就导致了数据存储空间利用率不高，大大压缩了用户可自由使用的数据存储空间。因此，在一种可行的操作系统升级方案中，采用基于虚拟分区的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)进行数据写入操作以升级静态分区。

例如，版本1.1升级到版本1.2的系统增量升级安装包包含版本1.2的静态分区的全量数据，设备将版本1.2的静态分区的数据覆写到静态分区(B)中。

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文件中的更新数据的大小与其所要更新的原始数据的大小一致，并且，COW文件中的更新数据在数据更新后在子分区中的保存位置与其所要更新的原始数据在子分区中的保存位置一致时，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地址段的数据)。

当COW文件中的更新数据的大小与其所要更新的原始数据的大小不一致时，COW文件(system_b-cow-img.img.0000)自身的COW文件地图可以为：

/system/app/A2.XXX：

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

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

Map1.2(cow文件中更新数据超出待更新数据大小的那一部分在原super分区中的待写入地址)：起始地址address start：025018(相对于system起始地址的偏移量)；偏移量大小size：1(即025018～025020地址段的数据)

Map2.2(cow文件中存储的，需要覆盖Map1.2地址的更新数据的地址)：起始地址address start：046033(相对于cow文件存储的起始地址的偏移量)；偏移量大小size：2(即046033～046035地址段的数据)。

在接下来的说明书描述中，为便于描述，仅以当COW文件中的更新数据的大小与其所要更新的原始数据的大小一致，并且，COW文件中的更新数据在数据更新后在子分区中的保存位置与其所要更新的原始数据在子分区中的保存位置一致的应用场景进行举例说明。

在上述例子中，地址段(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子分区的数据升级。

进一步的，在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文件的合并并不是物理意义上的合并，而是将动态分区(Super)中子分区的文件地图与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)的新版本的文件系统所包含的所有文件并计算哈希值。

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

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

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

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)上创建虚拟动态分区，因此有效提高了数据存储空间利用率。

针对定制操作系统，一种可行的定制操作系统架构是对基础操作系统进行全面优化，采用与基础操作系统完全不同的文件存储结构，这势必会大大增加定制操作系统的构建难度。为降低定制操作系统的构建难度，在本申请一实施例中，在保持基础操作系统文件存储架构不变的基础上，新增添定制分区，在定制分区中保存用于优化基础操作系统、增加系统功能的定制数据。

具体的，以采用虚拟A/B升级方式的安卓系统为例，图6所示为安卓系统在终端设备上的数据存储结构示意图。如图6所示，安卓系统数据存储区包含基础分区(Common)、静态分区(A)、静态分区(B)、动态分区(Super)、定制分区(A)、定制分区(B)、用户数据分区(Userdata)。

定制分区(A)与定制分区(B)用于保存定制数据，其为设备出厂前就在系统的数据存储结构中划分好的存储分区，定制分区可以是从用户数据分区中划分的部分分区。设备出厂时，定制分区(A)与定制分区(B)可以是空的，以便后续用户或厂商烧入定制数据；也可以在设备出厂前就在定制分区(A)与定制分区(B)预先烧入定制数据。

定制分区(A)与定制分区(B)的结构相互对应，子分区命名通过后缀_a以及_b相互区分。例如，定制分区(A)包括version_a、preload_a；定制分区(B)包括version_b、preload_b。

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

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

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

S710，设备获取操作系统升级安装包；操作系统升级安装包包含静态分区的升级数据、动态分区(Super)的升级数据以及定制分区的升级数据。操作系统升级安装包的获取过程可以参照S510。

S720，设备根据操作系统升级安装包，针对静态分区(B)部分的数据进行读写操作以升级静态分区；并且，针对定制分区(B)部分的数据进行读写操作以升级定制分区。

具体的，设备将静态分区的升级数据写入静态分区(B)，将定制分区的升级数据写入定制分区(B)。具体可以参照S520。

S730，设备根据操作系统升级安装包在用户数据分区(Userdata)创建虚拟动态分区，在虚拟动态分区写入动态分区(Super)的升级数据。具体可以参照S530。

在S720中，静态分区以及定制分区升级的数据操作是针对静态分区(B)以及定制分区(B)中的操作系统数据的，其并不会影响到当前启动的静态分区(A)以及定制分区(A)的操作系统数据；并且，在S730中，动态分区升级的数据操作是在用户数据分区(Userdata)中所创建的虚拟动态分区上完成的，其并不会影响到当前加载的动态分区(Super)。因此，在整个操作系统升级的过程中，用户可以正常使用设备。进一步的，针对动态分区(Super)，仅在需要进行升级时才会在用户数据分区(Userdata)上创建虚拟动态分区，升级完成后可以从用户数据分区删除创建的虚拟动态分区，因此有效提高了数据存储空间利用率。

S731，将设备的启动顺序由从静态分区(A)启动变更为从静态分区(B)启动。具体的，改写common分区中改写启动标识，将启动标识由A改写为B。

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

在S731之后，设备并不需要立即重启，可以由用户自行选择重启时机(自由选择执行S732的时机)；这样，操作系统的升级过程并不会对用户的正常手机操作产生影响，从而大大提高了用户体验。

S740，设备依次加载基础分区(Common)、静态分区(B)、动态分区(Super)+虚拟动态分区以及定制分区(B)，从静态分区(B)启动；参照S540、S541。

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

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

基于图6、图7所示方案，虽然可以实现在终端设备正常运行定制操作系统时进行无感知升级，但是，在终端设备正常使用时，在非升级状态下，定制分区(A)以及定制分区(B)中只有一个分区的数据被使用，另一个分区被闲置，这也导致了数据存储空间利用率不高，大大压缩了用户可自由使用的数据存储空间。因此，在本申请另一实施例的方案中，将定制分区融合到动态分区(Super)中，令定制分区成为动态分区(Super)的子分区，在进行操作系统升级时，在基于虚拟分区方案升级动态分区(Super)时同步升级定制分区。

图8所示为根据本申请一实施例的数据存储结构示意图。如图8所示，安卓系统数据存储区包含基础分区(Common)、静态分区(A)、静态分区(B)、定制动态分区(Super)、用户数据分区(Userdata)。静态分区(A)、静态分区(B)所包含的具体子分区可以参照图2所示实施例的相关描述。定制动态分区(Super)包含图4所示的基础操作系统的动态分区中的所有子分区；除此以外，定制数据以动态分区的子分区的形式被添加在动态分区中，如图8所示，定制动态分区(Super)还包含定制分区、货架分区(定制分区、货架分区用于保存定制数据)。由于定制分区、货架分区是定制动态分区(Super)的子分区。因此，整个定制操作系统(基础数据+定制数据)可以采用图5所示的虚拟A/B升级方式进行升级。

这里需要说明的是，在图8所示实施例中，定制数据保存在定制分区以及货架分区中。在本申请其他实施例中，也可以采用其他分区结构保存定制数据。例如，仅保留定制分区或仅保留货架分区；又例如，再额外增加一个服务分区。

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

图9a～图9d所示为根据本申请一实施例的操作系统升级逻辑示意图。如图9a所示，假设动态分区(Super)上的数据可以划分为6部分：S1、S2、S3、S4、S5、S6。在操作系统升级前操作系统的版本为1.1。在版本1.1的操作系统中，S1、S2、S3、S4、S5、S6的数据分别为A1、B1、C1、D1、E1、F1。操作系统需要从版本1.1升级到版本1.2。在版本1.2的操作系统中，数据组S1、S2、S3、S4、S5、S6中的数据分别为A1、B2、C1、D2、E1、F1。也就是说，从版本1.1到版本1.2，动态分区(Super)中被升级的数据组仅为S2以及S4。

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

S1000，设备依次加载基础分区(Common)、静态分区(A)以及动态分区(Super)，从静态分区(A)启动。如图9a所示。

S1010，设备获取操作系统升级安装包，系统升级安装包包括静态分区的升级文件以及动态分区的升级文件。参照S510。

S1020，设备根据操作系统升级安装包针对静态分区(B)部分的数据进行读写操作以升级静态分区，参照S520。

具体的，如图9b所示，从操作系统升级安装包中提取版本1.2的静态分区文件，将版本1.2的静态分区文件写入到静态分区(B)。

S1030，设备根据操作系统升级安装包在用户数据分区(Userdata)创建虚拟动态分区，在虚拟动态分区写入动态分区(Super)的升级数据，参照S530。

具体的，在本实施例中，操作系统升级安装包中针对动态分区(Super)的升级数据具有指向性，其并不是动态分区(Super)的全量数据，而是指向S2以及S4的升级数据B2以及D2。写入到虚拟动态分区中的数据为对应数据组S2以及S4的S2

例如，在操作系统升级安装包中，假设针对动态分区(Super)的升级数据被命名为S2

进一步的，如图9b所示，在虚拟动态分区采用快照技术(snapshot)，S2

具体的，创建虚拟动态分区的过程包括：

将对应S2

具体的，计算(S1+S2

如哈希值不一致，则中断升级流程并报错；。

如哈希值一致，则将基础分区(Common)的元数据(/metadata)中的落盘状态信息由“已落盘(merged)”改为“未落盘(wait for merge)”。

S1040，将设备的启动顺序由从静态分区(A)启动变更为从静态分区(B)启动。具体的，改写common分区中改写启动标识，将启动标识由A改写为B。

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

S1050，设备加载基础分区(Common)，加载静态分区(B)，如图9c所示。

S1052，如图9c所示，设备基于snapshot技术加载(S1、S2

S1054，设备启动成功，开机广播，开启升级进程。

S1055，升级进程启动合并(merge)落盘，将S2

merge落盘完成后，动态分区(Super)中S1、S2、S3、S4、S5、S6这6个数据组分别为A1、B2、C1、D2、E1、F1。动态分区(Super)升级到版本1.2。

S1056，删除用户数据分区(Userdata)上的COW文件。

S1057，将基础分区(Common)的元数据(/metadata)中的落盘状态信息由“未落盘(wait for merge)”改为“已落盘(merged)”。

S1054～S1057的具体执行可以参照S550～S551。最终设备上的操作系统文件状态如图9d所示。

具体的，在图9所示实施例中，S1、S2、S3、S4、S5、S6的划分仅仅是一种理论上的举例说明，本领域的技术人员可以根据实际需要设定动态分区(Super)的划分，例如，按照子分区进行划分，以子分区为单位进行动态分区(Super)的升级。又例如，将一个子分区划分为多个子部分，对子分区进行部分数据升级。

基于图9以及图10实施例，在升级动态分区(Super)时可以针对一个(第一子分区)或多个动态分区(Super)的子分区(例如，第一子分区、第二子分区)进行升级，而无需对动态分区(Super)进行整体升级。结合图8所示实施例，由于定制分区(第一子分区)、货架分区(第二子分区)是定制动态分区(Super)的子分区。因此，在仅需要升级定制分区和/或货架分区时，可以基于图9以及图10实施例的流程，在升级定制动态分区(Super)时，仅针对定制分区和/或货架分区进行升级，而无需对定制动态分区(Super)进行整体升级。

以下以定制分区为升级目标，通过具体实施例举例说明针对定制分区进行独立升级的升级执行流程。

在一应用场景中，针对定制操作系统的定制分区进行独立升级，静态分区也不需要升级，定制动态分区(Super)中仅需要升级定制分区。即，不执行图10实施例中的S1020；并且，在S1030中，虚拟动态分区的COW文件为定制分区的升级文件数据。

进一步的，在S1030后设备需要重启(S1040)，并且，在设备重启后的启动分区是被切换过的。即，如果重启前设备从静态分区(A)启动，那么重启后设备从静态分区(B)启动。

当静态分区(A)与静态分区(B)中的数据一致时，在不执行图10实施例中的S1020的情况下，如果重启前设备可以顺利加载静态分区(A)，从静态分区(A)启动；那么，重启后设备也可以顺利加载静态分区(B)，从静态分区(B)启动。

图11所示为针对定制分区进行独立升级的升级执行流程，静态分区(A)与静态分区(B)中的数据一致，当设备当前是从静态分区(A)启动时，设备按照如图11所示的流程实现独立升级定制分区。

S1100，设备依次加载基础分区(Common)、静态分区(A)以及定制动态分区(Super)，从静态分区(A)启动。假设当前定制动态分区(Super)中定制分区的版本为1.1。

S1110，设备获取定制分区升级安装包，定制分区升级安装包包含版本为1.2定制分区的升级文件。在本实施例中，定制分区升级安装包具有指向性，其仅包含定制分区(第一子分区)的升级数据(第一升级文件)。因此，基于定制分区升级安装包进行操作系统升级时不会向静态分区中写入数据。

S1120，设备在用户数据分区(Userdata)中写入COW文件，该COW文件包含版本为1.2定制分区的升级文件；设备修改基础分区(Common)的元数据(/metadata)中的落盘状态信息。S1120的具体实施可参照S530以及S1030。

S1130，将设备的启动顺序由从静态分区(A)启动变更为从静态分区(B)启动。具体的，改写common分区中改写启动标识，将启动标识由A改写为B。

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

S1140，设备加载基础分区(Common)，加载静态分区(B)。

S1160，设备利用snapshot加载定制动态分区(Super)以及用户数据分区(Userdata)的COW文件。参照S541以及S1052。

S1161，设备启动成功，开机广播，开启升级进程。

S1162，升级进程启动合并(merge)落盘，将用户数据分区(Userdata)的COW文件(版本1.2的定制分区升级文件)落盘到定制动态分区(Super)中的定制分区中。

S1163，删除用户数据分区(Userdata)上的COW文件。

S1170，将基础分区(Common)的元数据(/metadata)中的落盘状态信息由“未落盘(wait for merge)”改为“已落盘(merged)”。

S1161～S1070的具体执行可以参照S550～S551。

根据本申请实施例的方法，可以针对动态分区中的定制子分区进行独立升级，以实现针对定制操作系统的升级。根据本申请实施例的方法，可以有效降低操作系统升级安装包的数据量，简化操作系统升级流程。

在某些应用场景中，静态分区中会保存与定制分区中数据相关联的数据。例如，该相关联的数据可以是在静态分区中保存定制分区的校验码，该校验码用于在设备正常使用环节对定制分区进行校验，防止定制分区数据被篡改。因此，在对定制分区进行独立升级时，需要对静态分区中的关联数据进行更新。

图12所示为针对定制分区进行独立升级的升级执行流程，如果静态分区(A)与静态分区(B)中的数据一致，当设备当前是从静态分区(A)启动时，设备按照如图12所示的流程实现独立升级定制分区。

S1200，设备依次加载基础分区(Common)、静态分区(A)以及定制动态分区(Super)，从静态分区(A)启动。假设当前定制动态分区(Super)中定制分区的版本为1.1。

S1210，设备获取定制分区升级安装包，定制分区升级安装包包含版本为1.2定制分区的升级文件以及需要保存在静态分区中对应版本1.2定制分区的关联数据。

S1211，设备将静态分区(B)中对应定制分区的关联数据更新为对应版本1.2定制分区的关联数据。

S1220～S1270，参照S1120～S1170。

在某些应用场景中，当设备基于图5或图10所示流程进行操作系统升级后，静态分区(B)与静态分区(A)就存在版本差异，静态分区(A)与静态分区(B)的数据就可能是不一致的。这样，如果现在设备可以从静态分区(B)启动；那么，重启后设备就可能无法从静态分区(A)启动。

图13所示为针对定制分区进行独立升级的升级执行流程。设备从静态分区(A)启动后，基于图5或图10所示流程进行操作系统升级，从静态分区(B)启动完成操作系统升级。在此之后，在设备从静态分区(B)启动的状态下，设备按照如图13所示的流程实现独立升级定制分区。

S1300，设备依次加载基础分区(Common)、静态分区(B)以及定制动态分区(Super)，从静态分区(B)启动。假设当前定制动态分区(Super)中定制分区的版本为1.1。

S1310，设备获取定制分区升级安装包，定制分区升级安装包包含版本为1.2定制分区的升级文件。

S1311，设备将静态分区(B)的数据同步到静态分区(A)中。

S1320～S1370，参照S1120～S1170，区别在于，在S1340中，设备加载静态分区(A)。

进一步的，本申请对S1311的具体实现方式不做具体限制，本领域的技术人员可以采用多种可行的实现方式实现S1311。以下通过具体实施例举例说明S1311的具体实现流程。

在S520中，设备将操作系统升级安装包中的静态分区的数据写入到静态分区(B)。因此，如果使用同样的操作系统升级安装包，将操作系统升级安装包中的静态分区的数据写入到静态分区(A)中，就会使得静态分区(A)中的数据与静态分区(B)中的数据一致。

因此，在一应用场景中，S1311包括：获取从用户数据分区(Userdata)中读取S510中所保存的操作系统升级安装包，将操作系统升级安装包中的静态分区的数据写入到静态分区(A)中。

静态分区(A)与静态分区(B)在分区结构以及分区大小上是完全一致的。因此，可以直接将静态分区(A)的数据镜像到静态分区(B)，或者，将静态分区(B)的数据镜像到静态分区(A)。

图14所示为S1311的一种实现方式的流程图。终端设备执行如图14所示的下述流程以实现S1311。

S1400，将静态分区(B)中的所有数据读出，打包压缩后制作为镜像文件B；

S1410，将镜像文件B解包后恢复到静态分区(A)，从而实现将静态分区(B)的数据覆写到静态分区(A)。

静态分区(A)与静态分区(B)在分区结构上是一致的，其包含相同的子分区。因此，将静态分区(B)中每个子分区的文件覆写到静态分区(A)中对应子分区中，就可以实现将静态分区(B)中的数据同步到静态分区(A)。

图15所示为S1311的一种实现方式的流程图。终端设备执行如图15所示的下述流程以实现S1311。

S1500，读取设备存储器上与分区表相关的参数(该参数在设备出厂时预存在设备中)，合成存储器的总分区表。

例如，读取/dev/block/by-name/下各个分区的地址映射描述，将所有分区的地址映射整合为一个总分区表。

又例如，读取MBR中保存的分区表。

S1510，从总分区表中读取后缀名为_b的所有静态子分区，生成用于描述静态分区(B)各个子分区的列表1，列表1包括静态分区(B)中各个子分区的名称以及地址。例如：

表1

S1520，从总分区表中读取后缀名为_a的所有静态子分区，生成用于描述静态分区(A)各个子分区的列表2，列表2包括静态分区(A)中各个子分区的名称以及地址。例如：

表2

这里需要说明的是，在表1以及表2中，以文件路径的方式指代该子分区的地址，在实际应用场景中，本领域的技术人员可以使用多种不同的方式描述子分区的地址。例如，采用线性地址描述。

S1530，在列表1中选定一个未被选定过的子分区(第一子分区)，获取该子分区的名称(第一子分区名称)以及地址(第一文件路径)。

具体的，在S1530之前，列表1中的子分区均未被选定。在S1530中，可以按照列表1中子分区的排列顺序(编号顺序)依次选定子分区，也可以从所有未被选定过的子分区中随机选定。

进一步的，在选定一个子分区后，标记该子分区以便在后续确认该子分区是否被选定过。例如，如表1所示，在表1中增加被选定状态列，被选定状态的初始值为0，如子分区被选定，则被选定状态修改为1。

S1540，将S1530中选定的子分区与列表2中的各个子分区做去后缀匹配；确定列表2中，去掉后缀后，与S1530中选定的子分区名称一致的子分区(第二子分区名称)以及在列表2中，该第二子分区名称对应的子分区地址(第二文件路径)；

S1541，读取第一文件路径下的数据；

S1542，将读取到的数据覆写到第二文件路径下。

S1550，判断列表1中是否还存在未被选定过的子分区；

如果存在，返回步骤S1530，重新选定第一子分区；

如果不存在，静态分区同步结束。

以表1以及表2为例，在一应用场景中，设备执行下述流程：

选定表1中被选定状态为0的第一个子分区(编号1的bootloader_b子分区)，将编号1的被选定状态修改为1；

使用bootloader_b在表2中的所有子分区名称中做去后缀匹配，bootloader_a与bootloader_b在分别去掉_a以及_b后一致，因此，根据bootloader_b匹配到bootloader_a；

从表1中读取到bootloader_b对应的文件路径/dev/block/by-name/bootloader_b；

从表2中读取到bootloader_a对应的文件路径/dev/block/by-name/bootloader_a；

读取/dev/block/by-name/bootloader_b下的数据，将读取到的数据覆写到/dev/block/by-name/bootloader_a；

表1中仍存在被选定状态为0的子分区，选定表1中被选定状态为0的第一个子分区(编号2的boot_b子分区)，将编号2的被选定状态修改为1；

使用boot_b在表2中的所有子分区名称中做去后缀匹配，boot_a与boot_b在分别去掉_a以及_b后一致，因此，根据boot_b匹配到boot_a；

从表1中读取到boot_b对应的文件路径/dev/block/by-name/boot_b；

从表2中读取到boot_a对应的文件路径/dev/block/by-name/boot_a；

读取/dev/block/by-name/boot_b下的数据，将读取到的数据覆写到/dev/block/by-name/boot_a；

表1中仍存在被选定状态为0的子分区，选定表1中被选定状态为0的第一个子分区(编号3的vendor_boot_b子分区)，将编号3的被选定状态修改为1；

使用vendor_boot_b在表2中的所有子分区名称中做去后缀匹配，vendor_boot_a与vendor_boot_b在分别去掉_a以及_b后一致，因此，根据vendor_boot_b匹配到vendor_boot_a；

从表1中读取到vendor_boot_b对应的文件路径/dev/block/by-name/vendor_boot_b；

从表2中读取到vendor_boot_a对应的文件路径/dev/block/by-name/vendor_boot_a；

读取/dev/block/by-name/vendor_boot_b下的数据，将读取到的数据覆写到/dev/block/by-name/vendor_boot_a；

表1中仍存在被选定状态为0的子分区，选定表1中被选定状态为0的第一个子分区(编号4的dtbo_b子分区)，将编号4的被选定状态修改为1；

使用dtbo_b在表2中的所有子分区名称中做去后缀匹配，dtbo_a与dtbo_b在分别去掉_a以及_b后一致，因此，根据dtbo_b匹配到dtbo_a；

从表1中读取到dtbo_b对应的文件路径/dev/block/by-name/dtbo_b；

从表2中读取到vendor_boot_a对应的文件路径/dev/block/by-name/dtbo_a；

读取/dev/block/by-name/dtbo_b下的数据，将读取到的数据覆写到/dev/block/by-name/dtbo_a；

表1中仍存在被选定状态为0的子分区，选定表1中被选定状态为0的第一个子分区(编号5的vbmeta_b子分区)，将编号5的被选定状态修改为1；

使用vbmeta_b在表2中的所有子分区名称中做去后缀匹配，vbmeta_a与vbmeta_b在分别去掉_a以及_b后一致，因此，根据vbmeta_b匹配到vbmeta_a；

从表1中读取到vbmeta_b对应的文件路径/dev/block/by-name/vbmeta_b；

从表2中读取到vendor_boot_a对应的文件路径/dev/block/by-name/vbmeta_a；

读取/dev/block/by-name/vbmeta_b下的数据，将读取到的数据覆写到/dev/block/by-name/vbmeta_a；

表1中不存在被选定状态为0的子分区，静态分区同步完成。

进一步的，在上述方案中，表1以及表2为过渡数据，在静态分区同步完成后删除表1以及表2。

在操作系统升级的过程中，在S520，根据操作系统升级安装包针对静态分区(B)部分的数据进行读写操作时，并不一定会对静态分区(B)中所有的子分区进行改写。即，如果操作系统升级前静态分区(A)与静态分区(B)中的数据完全一致，那么，在采用图5所示流程升级操作系统后，静态分区(A)与静态分区(B)中某些子分区的数据有可能仍然保持一致。因此，在将静态分区(B)的数据同步到静态分区(A)的过程中，如果首先识别静态分区(B)与静态分区(A)数据不一致的子分区，仅同步数据不一致的子分区，就可以在实现数据一致的基础上，大大降低数据读写量。

图16所示为S1311的一种实现方式的流程图。终端设备执行如图16所示的下述流程以实现S1311。

S1600～S1640，参照S1500～S1540。

S1641，对第一路径下的数据做哈希计算，获得第一哈希值；

S1642，对第二子路径下的数据做哈希计算，获得第二哈希值；

S1643，验证第一哈希值与第二哈希值是否一致；

如果一致，跳转到S1650；

如果不一致，S1645，读取第一路径下的数据；

S1646，将读取到的数据覆写到第二路径下。

S1650，参照S1550；

如果存在，返回步骤S1630，重新选定第一子分区；

如果不存在，静态分区同步结束。

进一步的，在本申请的方案中，静态分区(A)与静态分区(B)间进行数据同步的执行节点为静态分区(A)与静态分区(B)中任意一个被写入升级数据后，S1311的执行时间节点并不仅限于S1310之后。

具体的，在S520之后，静态分区(B)中被写入升级数据，但是，由于此时操作系统运行加载静态分区(A)，此时，静态分区(B)的数据无法同步到静态分区(A)。而在S531后，在S540执行过程中，设备加载静态分区(B)以运行操作系统，操作系统的运行无需加载静态分区(A)，此时静态分区(B)的数据可以同步到静态分区(A)。因此，在本申请的实施例中，可以在S531之后的任意时刻执行S1311。本申请对S1311的执行时序不做具体限制，本领域的技术人员可以根据实际需求设定静态分区的同步时刻或者触发静态分区同步的触发条件。以下通过具体实施例举例描述S1311的其他执行时序。

图17所示为根据本申请一实施例的操作系统升级的流程图，当设备当前是从静态分区(A)启动时，设备按照如图17所示的流程实现操作系统的升级以及静态分区的同步。

S1700～S1732，参照S500～S532；

S1740，设备加载基础分区(Common)；

S1750，设备加载静态分区(B)；

S1751，判断静态分区(B)是否加载成功；

如静态分区(B)加载失败，S1752，重启设备并从静态分区(A)启动；

如静态分区(B)加载成功，S1753，将静态分区(B)的数据同步到静态分区(A)；S1753的执行参照S1311。

S1760，加载动态分区(Super)+虚拟动态分区；参照S541。

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

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

在虚拟A/B升级方案中，在设备重启并从升级后的静态分区启动后，设备会对动态分区+虚拟动态分区中当前系统运行所需要加载的文件进行验证，验证成功后才会加载动态分区+虚拟动态分区中当前系统运行所需要加载的文件。验证失败则会重启并回滚系统，此时系统升级失败。

因此，为避免在升级失败下进行静态分区同步，在本申请一实施例中，在动态分区+虚拟动态分区所需要加载的文件被成功验证，或者，动态分区+虚拟动态分区所需要加载的文件被成功加载后，才进行静态分区的同步。

图18所示为根据本申请一实施例的操作系统升级的流程图，当设备当前是从静态分区(A)启动时，设备按照如图18所示的流程实现操作系统的升级以及静态分区的同步。

S1800～S1852，参照S1700～S1752；

如果静态分区(B)加载成功，S1853，对动态分区+虚拟动态分区中需要加载的文件进行校验；例如，使用dmverity。

S1854，判断校验是否成功。

如校验失败，S1860，重启设备并回滚系统，例如，从静态分区(A)启动。

如校验成功，执行S1855；

S1855，将静态分区(B)的数据同步到静态分区(A)；S1855的执行参照S1311；

S1856～S1858，参照S1760～S1771。

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

进一步的，一般的，对于一个技术的改进可以很明显地区分是硬件上的改进(例如，对二极管、晶体管、开关等电路结构的改进)还是软件上的改进(对于方法流程的改进)。然而，随着技术的发展，当今的很多方法流程的改进已经可以视为硬件电路结构的直接改进。设计人员几乎都通过将改进的方法流程编程到硬件电路中来得到相应的硬件电路结构。因此，不能说一个方法流程的改进就不能用硬件实体模块来实现。例如，可编程逻辑器件(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、磁碟、光盘等，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本发明各个实施例或者实施例的某些部分所述的方法。

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