CN116450169A - 操作系统升级方法、电子设备、存储介质及芯片系统 - Google Patents

Abstract

本申请实施例提供的一种操作系统升级方法、电子设备、存储介质及芯片系统，涉及计算机技术领域，可以针对操作系统中的多个子分区组合升级，灵活满足各种升级需求。其中，方法包括：获取第一升级安装包和第二升级安装包。第一升级安装包包括第一数据，第一数据包括第一子分区的分区信息，第二升级安装包包括第二数据，第二数据包括第二子分区的分区信息。根据第三数据和多个第二描述组得到多个第三描述组，第三数据中包括第一子分区和第二子分区的分区信息，多个第三描述组中包括与第一子分区、第二子分区和第三子分区分别对应的描述组。重启电子设备，读取多个第三描述组中地址项的值，基于多个第三描述组中地址项的值加载动态分区的数据。

Description

操作系统升级方法、电子设备、存储介质及芯片系统

本申请要求于2022年1月10日提交国家知识产权局、申请号为202210023196.0、发明名称为“操作系统升级方法、设备、存储介质及计算机程序产品”的中国专利申请的优先权，其全部内容通过引用结合在本申请中。

技术领域

本申请涉及计算机技术领域，尤其涉及一种操作系统升级方法、电子设备、存储介质及芯片系统。

背景技术

在手机、笔记本电脑等终端设备中，操作系统是其最基本也是最为重要的基础性系统软件。终端设备在安装操作系统的情况下，才能被用户使用。以终端设备是手机为例，手机上需要安装手机操作系统，如苹果移动设备操作系统(iPhone Operation System，IOS)、安卓(Android)系统等，才可以被用户使用。

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

在终端设备安装定制操作系统后，当出现版本升级时，需要升级终端设备上所安装的定制操作系统。并且，在定制操作系统中，大量的升级需求仅需升级定制操作系统中部分存储区中的数据。

然而，目前操作系统的升级方案是由操作系统供应商提供的。操作系统供应商提供的升级方案通常是针对操作系统整体进行升级。若将该升级方案用于定制操作系统的升级需求，则当定制操作系统中任一部分存储区中的数据需要升级时，均需将需要升级的部分的新版本和不需要升级的部分的当前版本组合为一个新版本后发布，即发布组合升级包。然后，根据组合升级包对整个定制操作系统升级。如此，随着定制操作系统的升级需求变大，则会得到大量大版本的升级包，不利于终端设备供应商对定制操作系统的版本进行灵活管理。

发明内容

本申请实施例提供一种操作系统升级方法、电子设备、存储介质及芯片系统，可以针对操作系统中的多个子分区组合升级，灵活满足各种升级需求。

第一方面，本申请实施例提供一种操作系统升级方法，该方法可以应用于电子设备。电子设备包括处理器以及存储器，存储器包括基础分区、第一静态分区、第二静态分区、动态分区以及用户数据分区，动态分区包括第一插槽数据和第二插槽数据，动态分区包括多个子分区，第一插槽数据包括与多个子分区对应的多个第一描述组，第二插槽数据包括与多个子分区对应的多个第二描述组。加载基础分区、第一静态分区和动态分区的数据，以运行第一操作系统，在加载动态分区的数据的过程中，读取多个第一描述组，基于多个第一描述组中地址项的值加载动态分区的数据。获取第一升级安装包和第二升级安装包，第一升级安装包用于升级第一子分区，第二升级安装包用于升级第二子分区，第一子分区和第二子分区是动态分区的子分区，第一升级安装包包括第一数据(manifest)，第一数据包括第一子分区的分区信息，第二升级安装包包括第二数据，第二数据包括第二子分区的分区信息。根据第三数据和多个第二描述组得到多个第三描述组，第三数据中包括第一子分区的分区信息和第二子分区的分区信息，多个第三描述组中包括与第一子分区对应的描述组，与第二子分区对应的描述组，和与第三子分区对应的描述组，第三子分区是动态分区中除第一子分区和第二子分区之外的子分区。重启电子设备，加载基础分区、第二静态分区和动态分区的数据，以运行第二操作系统，在加载动态分区的数据的过程中，读取多个第三描述组中地址项的值，基于多个第三描述组中地址项的值加载动态分区的数据。

综上，采用本申请实施例的方法，在获取到多个(如两个)升级安装包后，电子设备将多个升级安装包中解析出的manifest进行合并，得到包括动态分区所有需要升级的子分区(如第一子分区和第二子分区)的manifest。然后，在基于该合并后的manifest得到多个第三描述组的过程中，针对manifest的分区信息中不涉及的子分区(如第三子分区)，也不会从第二插槽数据中将其删除。如此，不升级的子分区的描述组仍然保留在第二插槽数据中，后续运行第二操作系统时，则可以依据第二插槽数据加载到不升级的子分区的数据。从而不会出现加载不完全的情况，最终可实现成功加载动态分区。

在第一方面的一种可能的设计方式中，上述在获取第一升级安装包和第二升级安装包之后，还包括：将多个第二描述组写入目标文件中，在目标文件中删除与第三子分区对应的描述组，生成第一索引。

也就是说，电子设备在创建第一索引时，会删除掉多个第二描述组中未升级的子分区对应的描述组，使得创建的第一索引可仅指示电子设备获取升级的子分区的升级数据。从而可以准确指示电子设备获取升级数据。

在第一方面的一种可能的设计方式中，上述目标文件位于基础分区。

在第一方面的一种可能的设计方式中，上述在加载基础分区、第一静态分区和动态分区的数据之后，还包括：获取第三升级安装包，第三升级安装包用于升级第四子分区，第四子分区是动态分区的子分区，第三升级安装包包括第三数据，第三数据包括第四子分区的分区信息。根据第三数据和多个第二描述组得到多个第三描述组，第三数据中还包括第四子分区的分区信息，第三子分区是动态分区中除第一子分区、第二子分区和第四子分区之外的子分区。

也就是说，采用本实施例的方法，还可以是使用三个升级安装包来升级更多的子分区。应理解，还可以使用四个升级安装包、五个升级安装包等来灵活实现各种组合升级的需求。本申请实施例对此不作具体限定。

在第一方面的一种可能的设计方式中，第一升级安装包包括第一升级数据，第一升级数据用于升级第一子分区，第二升级安装包包括第二升级数据，第二升级数据用于升级第二子分区。上述方法还包括：在用户数据分区中保存第一升级数据和第二升级数据。在加载动态分区的数据的过程中，读取目标文件，基于目标文件中的第一索引加载用户数据分区中的第一升级数据和第二升级数据。

也就是说，采用本实施例的方法，在多个升级安装包组合升级的场景中，电子设备通过依次遍历多个升级安装包的方式，来实现将各个升级安装包中的升级数据写入到用户数据分区中。而不只是针对一个升级安装包保存数据，可以避免遗漏，实现各种组合的完全升级。然后，在加载动态分区时，需要从用户数据分区中获取所有的升级数据，从而实现动态分区的完全加载。

在第一方面的一种可能的设计方式中，上述在目标文件中删除与第二子分区对应的描述组，生成第一索引，包括：在目标文件中删除与第三子分区对应的描述组，得到与第一子分区对应的描述组和与第二子分区对应的描述组，与第一分区对应的描述组中包括第一子分区的名称，与第二子分区对应的描述组中包括第二子分区的名称。基于第一子分区的名称生成与第一子分区对应的第一文件名，基于第二子分区的名称生成与第二子分区对应的第二文件名，第一索引包括第一文件名和第二文件名。

也就是说，采用本实施例的方法，电子设备可以生成包括第一文件名和第二文件名的第一索引，从而可以准确指示电子设备在加载动态分区时需要查找的升级数据所在的文件。

在第一方面的另一种可能的设计方式中，上述在基于第一子分区的名称生成与第一子分区对应的第一文件名，基于第二子分区的名称生成与第二子分区对应的第二文件名之后，还包括：在用户数据分区中创建文件名为第一文件名的第一初始cow文件，以及创建文件名为第二文件名的第二初始cow文件，第一初始cow文件和第二初始cow文件中未存储升级数据。上述在用户数据分区中保存第一升级数据和第二升级数据，包括：在第一初始cow文件中保存第一升级数据，在第二初始cow文件中保存第二升级数据。

也就是说，采用本实施例的方法，电子设备可以在用户数据分区中创建与第一索引中的文件名一致的初始cow文件，并在该初始cow文件中保存升级数据。后续，电子设备在读取升级数据时，可以通过检索文件名准确的获取到升级数据。

在第一方面的另一种可能的设计方式中，上述第二静态分区包括多个子分区，第一升级安装包还包括第三升级数据，第三升级数据用于升级第五子分区，第二升级安装包还包括第四升级数据，第四升级数据用于升级第六子分区，第五子分区和第六子分区是第二静态分区的子分区。上述在获取第一升级安装包和第二升级安装包后，还包括：将第三升级数据写入第五子分区，将第四升级数据写入第六子分区。

也就是说，采用本实施例的方法，电子设备可以对动态分区和静态分区的部分子分区升级。从而灵活满足各种部分升级的需求。

在第一方面的另一种可能的设计方式中，第一静态分区包括多个子分区，第一静态分区的多个子分区与第二静态分区的多个子分区一一对应。在将第三升级数据写入第五子分区，将第四升级数据写入第六子分区之前，方法还包括：若第二静态分区包括第七子分区，检测第五子分区和第六子分区中是否包括预设子分区，第七子分区是第二静态分区中除第五子分区和第六子分区之外的子分区。若第五子分区和第六子分区中包括预设子分区，将第一静态分区的第七子分区的数据同步至第二静态分区的第七子分区中。

也就是说，在此次需要升级的数据为大量数据的情况下，电子设备可以仅将第一静态分区中无需升级的子分区(即第七子分区)的数据同步给第二静态分区，以保证第二静态分区中无需升级的子分区(即第七子分区)的数据是最新的。从而可以通过小部分数据的同步而实现当前无需升级的子分区数据的同步。

若第五子分区和第六子分区中不包括预设子分区，将第一静态分区中所有子分区的数据同步至第二静态分区的对应子分区中。

如此，在大部分数据无需升级时，设备无需从第一静态分区去剔除不需要同步的数据，而可以通过全部同步来简化同步的步骤。

也就是说，采用本实施例的方法，在更新第二静态分区中的数据之前，可以先使无需升级的子分区的最新数据，在第一静态分区和第二静态分区之间保持同步。然后对第二静态分区进行数据更新。如此，可以保证第二静态分区中各个子分区的数据都是最新的。

在第一方面的另一种可能的设计方式中，上述将第三升级数据写入第五子分区，将第四升级数据写入第六子分区，包括：若第二静态分区不包括第七子分区，将第三升级数据写入第五子分区，将第四升级数据写入第六子分区。也就是说，采用本实施例的方法，若静态分区中的所有数据均需要更新，则可以直接进行数据更新，而无需同步。从而可以节省系统升级的操作。

在第一方面的另一种可能的设计方式中，上述在用户数据分区中保存第一升级数据和第二升级数据，包括：遍历第一升级安装包和第二升级安装包，遍历到第一升级安装包时，在用户数据分区中保存第一升级数据，遍历到第二升级安装包时，在用户数据分区中保存第二升级数据。上述方法还包括：记录当前遍历到的升级安装包包括的升级数据的保存进度，以及记录当前遍历的升级安装包的遍历序数。计算保存进度和遍历序数对应的更新进度，显示更新进度。

也就是说，采用本实施例的方法，电子设备通过记录保存进度和遍历序数，可以计算得到实时的更新进度并显示。

在第一方面的另一种可能的设计方式中，上述在用户数据分区中保存第一升级数据和第二升级数据的过程中，还包括：若电子设备掉电重启，在第一升级安装包和第二升级安装包中定位遍历序数对应的目标升级安装包，以及在目标升级安装包的升级数据中定位写入进度对应的目标数据。从目标升级安装包的目标数据开始，在用户数据分区中继续保存第一升级数据和第二升级数据。

也就是说，采用本实施例的方法，针对数据更新过程中掉电重启的异常情况，电子设备可以准确的从掉电时更新到的位置处继续保存数据。

在第一方面的另一种可能的设计方式中，在根据第三数据和多个第二描述组得到多个第三描述组之前，还包括：合并第一数据和第二数据，得到第三数据。

也就是说，采用本实施例的方法，可以通过合并多个升级安装包中的manifest，得到包括动态分区中所有需要升级的子分区的分区信息的manifest。从而便于后续据此合并后的manifest来完成升级。

在第一方面的另一种可能的设计方式中，上述在加载基础分区、第二静态分区和动态分区的数据之后，还包括：将用户数据分区中的多个第一升级数据和第二升级数据落盘到动态分区的对应子分区中。

也就是说，采用本实施例的方法，通过落盘操作，使得动态分区的文件完成数据升级，以便设备在下次启动时不需要加载动态分区和虚拟动态分区，只需加载动态分区就可以完成设备启动。

在第一方面的另一种可能的设计方式中，上述第一子分区、第二子分区、第三子分区……都可以包括一个或多个子分区。从而可以灵活实现各种子分区的组合升级。

第二方面，本申请实施例还提供一种电子设备，所述电子设备包括处理器以及存储器，所述存储器包括基础分区、第一静态分区、第二静态分区、动态分区以及用户数据分区，所述动态分区包括多个子分区，所述处理器用于执行所述存储器上存储的软件代码，以使得所述电子设备执行上述第一方面及其任一种可能的设计方式的方法。

第三方面，本申请实施例提供一种芯片系统，该芯片系统应用于包括显示屏和存储器的电子设备；所述芯片系统包括一个或多个接口电路和一个或多个处理器；所述接口电路和所述处理器通过线路互联；所述接口电路用于从所述电子设备的存储器接收信号，并向所述处理器发送所述信号，所述信号包括所述存储器中存储的计算机指令；当所述处理器执行所述计算机指令时，所述电子设备执行如第一方面及其任一种可能的设计方式所述的方法。

第四方面，本申请实施例还提供一种计算机存储介质，该计算机存储介质包括计算机指令，当所述计算机指令在电子设备上运行时，使得电子设备执行如第一方面及其任一种可能的设计方式所述的方法。

第五方面，本申请提供一种计算机程序产品，当所述计算机程序产品在计算机上运行时，使得所述计算机执行如第一方面及其任一种可能的设计方式所述的方法。

可以理解地，上述提供的第二方面所述的电子设备，第三方面所述的芯片系统，第四方面所述的计算机存储介质，第五方面所述的计算机程序产品所能达到的有益效果，可参考第一方面及其任一种可能的设计方式中的有益效果，此处不再赘述。

附图说明

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

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

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

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

图4所示为根据本申请一实施例的部分卡槽数据示意图；

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

图5B所示为根据本申请一实施例的调整卡槽数据的示意图；

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

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

图8所示为根据本申请一实施例的独立组件升级的示意图；

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

图10所示为根据本申请一实施例的manifest的合并过程示意图；

图11所示为根据本申请一实施例的调整卡槽数据的示意图；

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

图13所示为根据本申请一实施例的创建索引的示意图；

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

图15所示为根据本申请一实施例的数据更新的示意图；

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

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

图18所示为根据本申请一实施例的掉电后数据更新的示意图；

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

图20所示为根据本申请一实施例的芯片系统的结构示意图。

具体实施方式

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

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

在终端设备(简称设备)出厂前，将操作系统烧录到设备中，从而实现在设备出厂前安装操作系统。此后，为了提升用户体验，可能需要对设备中的操作系统进行升级。此时，可采用空中下载技术(Over-the-Air Technology，OTA)来完成升级。其中，OTA是通过设备的无线网络接口实现对设备的操作系统进行远程版本更新的技术，实现远程升级设备中操作系统的目的。

需要说明的是，本申请实施例的设备包括但不限于可以安装操作系统的智能手机、智能耳机、平板电脑、智能冰箱、智能音箱等。设备也可以是设备内部可以安装操作系统的控制板。操作系统的示例性实施例包括但不限于Linux或者其它操作系统。

在采用OTA升级操作系统时，为了可以在设备正常运行时进行无感知升级，以及提升数据存储空间的利用率，可以采用虚拟A/B升级方案来完成操作系统的升级。

以安卓系统为例，虚拟A/B升级方案可以适用于具有图1所示的数据存储结构的操作系统的升级。如图1所示，安卓系统数据存储区包含基础分区(Common)、静态分区(A)、静态分区(B)、动态分区(Super)、用户数据分区(Userdata)。下面对各个分区进行介绍：用户数据分区(Userdata)用于保存用户的个人数据，例如，用户个人安装的APP、用户个人保存的图片、文档以及视频等个人数据。基础分区(Common)用于保存系统数据，基础分区中保存的数据不参与操作系统升级。静态分区(A)与静态分区(B)的结构相互对应，静态分区(A)与静态分区(B)可以包括多个子分区，静态分区(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)称为第一静态分区，将静态分区(B)称为第二静态分区。

在设备启动时，从一个静态分区启动，即通过加载该静态分区以启动操作系统。例如，设备从静态分区(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中读取设备启动顺序描述，从而根据设备启动顺序描述确定需要从静态分区(A)还是静态分区(B)启动。MBR通常记录在基础分区(Common)中。当然，在不同平台中，MBR也可以记录在不同的位置，本申请实施例对此不作具体限定。

图2所示为针对具有图1所示的数据存储结构的操作系统进行操作系统升级的流程图，假设设备当前是从静态分区(A)启动，设备按照如图2所示虚拟A/B升级方案的流程实现操作系统的升级。

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

S210，设备获取操作系统升级安装包。

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

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

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

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

例如，在操作系统升级安装包中包含版本1.2的动态分区(Super)的数据，设备在虚拟动态分区中写入版本1.2的动态分区(Super)的数据。

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

以System子分区为例，假设在版本1.1中，System子分区中的数据可以分为数据system1、数据system2。从版本1.1升级到版本1.2，数据system2没有发生变化，数据syetem1被升级为数据system3。那么，在S230中，设备在用户数据分区(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)的子分区。在操作系统升级安装包中，动态分区(Super)的升级数据的cow文件以二进制代码形式压缩保存，每个cow文件根据其所对应的动态分区(Super)的子分区所命名。例如，针对system子分区的cow文件被命名为system-cow-img.img.0000。

进一步的，设备获取操作系统升级安装包，解包操作系统升级安装包以获取所有的cow文件后，为每个cow文件附加A/B分区标记。并进一步的，在用户数据分区(Userdata)中创建Update文件夹，将cow文件保存到Update文件夹下。

比如，当设备当前从静态分区(A)启动时，可以理解为设备当前运行操作系统所加载的动态分区(Super)为动态分区(A)。在升级操作系统时，用户数据分区(Userdata)中创建的虚拟动态分区是针对动态分区(B)。因此，在S230中，设备获取操作系统升级安装包，解包操作系统升级安装包以获取所有的cow文件后，为cow文件附加对应动态分区(B)的名称标记_b。例如，为system-cow-img.img.0000附加_b生成system_b-cow-img.img.0000。进一步的，在用户数据分区(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文件中。

进一步的，在S230中，在将cow文件写入用户数据分区(Userdata)后，还需要对动态分区(Super)+cow文件进行整体校验，校验动态分区(Super)+cow文件的有效性，验证当前版本的动态分区(Super)数据+cow文件的合成结果是否为新版本的动态分区(Super)数据。若有效，则将基础分区(Common)的元数据分区(/metadata)中的落盘状态信息由“已落盘(merged)”改为“未落盘(wait for merge)”。落盘状态信息用于表示当前是否存在需要落盘到动态分区(Super)的cow文件。具体的，落盘状态信息包含针对动态分区(Super)的整体标识以及针对每个子分区的子分区标识。当整体标识为“已落盘(merged)”时，代表动态分区(Super)的所有子分区均不需要进行落盘操作；当整体标识为“未落盘(wait formerge)”时，代表动态分区(Super)的一个或多个子分区需要进行落盘操作；当子分区标识为“已落盘(merged)”时，代表该子分区不需要进行落盘操作；当子分区标识为“未落盘(wait for merge)”时，代表该子分区需要进行落盘操作。若无效，则升级失败，中断升级进程并报错。

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

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

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

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

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

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

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

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

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

S251，设备将虚拟动态分区的数据落盘到动态分区(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)”。

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

进一步的，图3所示为根据本申请一实施例的数据存储结构示意图。如图3所示，在动态分区(Super)的头部的元数据(/supermetadata)中，包含对应静态分区(A)的Slot0以及静态分区(B)的Slot1。Slot0以及Slot1用于保存Super分区的分区表。为了方便说明，可以将对应静态分区(A)的Slot0称为第一插槽，Slot0中的数据称为第一插槽数据，将对应静态分区(B)的Slot1称为第二插槽，Slot1中的数据称为第二插槽数据。

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

具体的，Slot0以及Slot1中包含多个子分区描述组，一个子分区描述组对应Super分区的一个子分区。也就是说，Slot0中包括与多个子分区对应的多个描述组，Slot1也包括与多个子分区对应的多个描述组。为了方便说明，可以将Slot0中的多个子分区描述组称为多个第一描述组，将Slot1中的多个子分区描述组称为多个第二描述组。

子分区描述组包含：名称(Name)项，组(Group)项，属性(Attributes)项，地址(Extents)项中的至少一种。下面对子分区描述组包含的各项进行描述：

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

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

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

地址(Extents)项，其值为子分区的地址，例如，0..6995967linear super 2048。

在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)的子分区地址。

一般的，在设备出厂前进行系统烧录后，初始的Slot0以及Slot1中，针对Super分区的每个子分区，存在两个子分区描述组，一个子分区描述组对应静态分区(A)，一个子分区描述组对应静态分区(B)。在读取Slot0或Slot1时，设备根据后缀(_a或_b)选定需要读取的子分区描述组。

即，在Slot0以及Slot1中，针对Super分区的每个子分区，均存在两个子分区描述组(例如，第一描述组和第二描述组)。针对同一子分区的两个子分区描述组的Name项和Group项的值的前缀相同，后缀不同(分别为_a以及_b)。针对同一子分区的两个子分区描述组的地址项的值可以不同。

图4所示为一实施例中初始的Slot0所保存的部分数据。如图4所示，Name项以及Group项的值的后缀为_a的子分区描述组中，Extents项的值为子分区的真实地址。Name项以及Group项的值的后缀为_b的分区描述组中，Extents项的值被置空。在由静态分区A启动，加载Super分区时，首先读取Slot0。在读取Slot0时，由于后缀为_a对应静态分区(A)，设备读取Slot0中Name项和/或Group项后缀为_a的子分区描述组中Extents项的值，以获取Super分区的子分区地址，从而顺利加载Super分区。

在读取Slot0时，由于后缀为_b对应静态分区(B)，设备无需读取Slot0中Name项和/或Group项后缀为_b的子分区描述组，因此，Name项以及Group项的值的后缀为_b的子分区描述组中，Extents项的值被置空不会影响Super分区的加载。

进一步，在一些实施例中，初始的Slot1所保存的数据与图4所示的数据结构类似，区别在于，为了确保顺利加载Super分区，在Slot1的数据中，Name项以及Group项的值的后缀为_b的子分区描述组中，Extents项的值为子分区的真实地址。Name项以及Group项的值的后缀为_a的子分区描述组中，Extents项的值被置空。

由此可见，当系统升级时，设备需要对slot0或者slot1中的子分区描述组及时更新。如此，在后续切换启动的静态分区时，设备才能读取到正确的子分区描述，如Extents项，以成功加载动态分区(Super)分区。

并且，在加载动态分区(Super)时(如S241中)，需要从用户数据分区(Userdata)的虚拟动态分区中读取cow文件。为了可以准确的从用户数据分区(Userdata)中读取到cow文件，设备还可以在基础分区(Common)中创建cow文件的索引。该cow文件的索引用于指示设备从用户数据分区(Userdata)中读取cow文件。然后，设备在加载动态分区(Super)时，可以根据该索引从用户数据分区(Userdata)中读取到相应的cow文件。

下面将在图3的基础上，结合slot1的更新和cow文件的索引的创建来说明虚拟A/B升级方案的流程。具体的，当设备当前是从静态分区(A)启动时，设备按照如图5A所示的流程实现操作系统的升级。

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

S210、设备获取操作系统升级安装包。

S510、设备解析操作系统升级安装包，获得应用清单数据(manifest)。

在操作系统升级安装包中，mainfest中记录了更新后的操作系统(如版本1.2)的数据存储结构中静态分区的分区信息(简称静态分区信息)和动态分区的分区信息(简称动态分区信息)。其中，静态分区信息包括静态分区中各个子分区的名字、大小、升级后的数据的校验值(如哈希值)以及升级数据(差分或者全量镜像的数据)在操作系统升级安装包里的位置。动态分区信息包括动态分区中各个子分区的名字、大小、升级后的数据的校验值(如哈希值)以及升级数据(差分或者全量镜像的数据)在操作系统升级安装包里的位置。

示例性的，更新后的操作系统的动态分区包括如下6个子分区：system、system_ext、vendor、product、cust以及odm。相应的，manifest中包括如下动态分区信息：

system分区的名字、大小、升级后的数据的校验值(如哈希值)以及升级数据在操作系统升级安装包里的位置；

system_ext分区的名字、大小、升级后的数据的校验值(如哈希值)以及升级数据在操作系统升级安装包里的位置；

vendor分区的名字、大小、升级后的数据的校验值(如哈希值)以及升级数据在操作系统升级安装包里的位置；

product分区的名字、大小、升级后的数据的校验值(如哈希值)以及升级数据在操作系统升级安装包里的位置；

cust分区的名字、大小、升级后的数据的校验值(如哈希值)以及升级数据在操作系统升级安装包里的位置；

odm分区的名字、大小、升级后的数据的校验值(如哈希值)以及升级数据在操作系统升级安装包里的位置。

进一步的，若相较于当前的操作系统，更新后的操作系统的数据存储结构中动态分区包括的子分区减少了，则manifest中的动态分区信息涉及的子分区不会包括当前的操作系统中动态分区里的所有子分区。

示例性的，当前的操作系统的数据存储结构中，动态分区(Super)包括system、system_ext、vendor、product、cust、odm共6个子分区，而升级后的操作系统的数据存储结构中，动态分区(Super)包括system、product、cust、odm共4个子分区。相应的，manifest中包括如下动态分区信息：

system分区的名字、大小、升级后的数据的校验值(如哈希值)以及升级数据在操作系统升级安装包里的位置；

product分区的名字、大小、升级后的数据的校验值(如哈希值)以及升级数据在操作系统升级安装包里的位置；

cust分区的名字、大小、升级后的数据的校验值(如哈希值)以及升级数据在操作系统升级安装包里的位置；

odm分区的名字、大小、升级后的数据的校验值(如哈希值)以及升级数据在操作系统升级安装包里的位置。

很显然，manifest包括的动态分区信息不涉及system_ext和vendor分区。

S520、设备根据manifest中的动态分区信息，调整动态分区(Super)里slot1的子分区描述组，得到调整后的slot1。其中，调整后的slot1中子分区描述组涉及的子分区与manifest中动态分区信息涉及的子分区一一对应。

具体的，设备根据子分区的名字和大小调整slot1中相应子分区的地址(Extents)项，使调整后的slot1中各个子分区的地址(Extents)项与相应子分区大小相匹配。以及，设备从slot1中删除manifest的动态分区信息不涉及的子分区的子分区描述组。即，更新后的slot1的子分区描述组涉及的子分区，与manifest中动态分区信息涉及的子分区一一对应。

以各个子分区的分区大小均未发生改变，并且，调整前的slot1是图5B中的(a)所示初始的slot1为例，初始的slot1中包括system、system_ext、product、vendoer、cust、odm共6个子分区的子分区描述组，并且每个子分区包括两个子分区描述组，一个子分区描述组对应静态分区(A)，一个子分区描述组对应静态分区(B)。此次从操作系统升级包中解析出的manifest中，包括system、product、cust、odm共4个子分区的动态分区信息，则经过调整后可得到如图5B中的(b)所示的slot1。相较于调整前的slot1，调整后的slot1中删除了system_ext和vendor分区的子分区描述组，而仅包括system、product、cust、odm共4个子分区的子分区描述组。

进一步的，若调整前的slot1为初始的slot1(如图5B中的(a)所示)，则相较于调整前的slot1，调整后的slot1仅保留与静态分区(B)对应的子分区描述组，即后缀为_b的子分区描述组，而删除了与静态分区(A)对应的子分区描述组，即后缀为_a的子分区描述组。

S530、设备根据调整后的slot1在基础分区(Common)中记录cow文件的索引。

其中，cow文件的索引可指示设备从用户数据分区(Userdata)中查找相应的cow文件，以完成动态分区(Super)的加载。

设备将更新后的slot1中的子分区描述组复制一份到基础分区(Common)下，如基础分区(Common)的元数据(/metadate)下/gsi/ota/lp_metadata文件中，则得到cow文件的索引。

示例性的，仍以图5B中的(b)所示调整后的slot1为例，将该调整后的slot1中的子分区描述组复制一份到基础分区(Common)下/metadate/gsi/ota/lp_metadata文件中，则/metadate/gsi/ota/lp_metadata文件中可记录包括system、product、cust、odm共4个子分区对应的cow文件的索引。例如，/metadate/gsi/ota/lp_metadata中cow文件的索引如下所示：

Name:system_b

Group:ry_dynamic_partitions_b

Attributes:readonly

Extents:

0…6995967 linear super 2048

------------------------

Name:product_b

Group:ry_dynamic_partitions_b

Attributes:readonly

Extents:

0…65535 linear super 6998016

------------------------

Name:odm_b

Group:ry_dynamic_partitions_b

Attributes:readonly

Extents:

0…1949695 linear super 9431040

------------------------

Name:cust_b

Group:ry_dynamic_partitions_b

Attributes:readonly

Extents:

0…180223 linear super 16263168。

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

S540、设备根据操作系统升级安装包在用户数据分区(Userdata)创建虚拟动态分区，在虚拟动态分区中，采用cow文件保存动态分区(Super)的升级数据。

在虚拟动态分区中，一个cow文件存放一个子分区的升级数据。例如，system_b_cow_img.img.000文件存放system分区的升级数据，cust_b_cow_img.img.000文件存放cust分区的升级数据。

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

S232、设备重启。

S240、设备依次加载基础分区(Common)、静态分区(B)，从静态分区(B)启动。

S550、设备根据调整后的slot1和cow文件的索引，加载动态分区(Super)以及用户数据分区(Userdata)的虚拟动态分区中的cow文件。

设备在加载动态分区(Super)时，可以从调整后的slot1中读取子分区描述组，以及读取cow文件的索引和落盘状态信息。其中，设备读取子分区描述组，可以获取各个子分区的地址(Extents)项，即各个子分区在动态分区中的偏移地址。设备读取落盘状态信息，可以确定是否需要从用户数据分区(Userdata)中检索各个子分区对应的cow文件。具体的，读取到落盘状态信息的整体标识为“已落盘”时，则确定无需从用户数据分区(Userdata)中检索所有子分区对应的cow文件。读取到落盘状态信息的整体标识为“未落盘”时，则可以进一步读取落盘状态信息中针对各个子分区的子分区标识。若子分区标识为“已落盘”，则确定无需从用户数据分区(Userdata)中检索相应子分区对应的cow文件。若子分区标识为“未落盘”，则确定需要从用户数据分区(Userdata)中检索相应子分区对应的cow文件。设备读取cow文件的索引，可以根据cow文件的索引指示的文件名，从用户数据分区(Userdata)中检索相应的cow文件。

示例性的，设备读取落盘状态信息，确定需要检索system子分区对应的cow文件。然后，设备读取包括如下内容的cow文件的索引：

Name:system_b，

Group:ry_dynamic_partitions_b，

Attributes:readonly，

Extents:0…6995967 linear super 2048，

可以读取到与system子分区对应的名称项“system_b”。然后，设备根据cow文件的命名规则，可以确定名称项“system_b”对应的cow文件的文件名为system_b_cow_img。设备可以从用户数据分区(Userdata)中检索文件名为system_b_cow_img的cow文件。从而检索到system分区对应的cow文件。

之后，设备采用snapshot可合并加载动态分区(Super)以及cow文件。

关于S550中未详细说明的部分，例如，采用snapshot可合并加载动态分区(Super)以及cow文件的内容，可参见图2所示的实施例中S241的相关说明，此处不再赘述。

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

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

需要在此说明的是，关于图5A中未详细说明的步骤，可参见图2所示实施例中相关步骤的说明，图5A所示的实施例中不再赘述。例如，采用S550中采用snapshot合并加载动态分区(Super)以及cow文件的内容，可参见图2所示的实施例中S241的相关说明。

采用上述图5A所示的升级方案，设备在获取到操作系统升级安装包后，可以调整动态分区(Super)的slot1和创建cow文件的索引。然后，设备使用调整后的slot1和cow文件的索引，可以加载得到启动动态分区(Super)所需的数据，从而成功启动动态分区(Super)。

然而，在实际场景中，极有可能只需对整个操作系统中的部分分区升级，在这种升级场景中，采用图5A所示的升级方案则会存在一定不足。下面将以定制操作系统为例，来说明部分分区升级的需求，以及面对这种需求，采用图5A所示的升级方案的不足。

基础操作系统(如图1和图3所示的数据存储结构对应的系统)仅包含最基础的功能，其并不能完全满足用户的应用需求。因此，为了提升用户体验，设备供应商会根据客户需求、应用场景的不同，对基础操作系统进行优化，在基础操作系统的基础上增加定制内容，构建定制操作系统。在设备上安装定制操作系统，以使得设备可以提供优化的系统功能。

图6所示为根据本申请一实施例的数据存储结构示意图。如图6所示，安卓系统数据存储区包含基础分区(Common)、静态分区(A)、静态分区(B)、定制动态分区(Super)、用户数据分区(Userdata)。静态分区(A)、静态分区(B)所包含的具体子分区可以参照前文实施例的相关描述。定制动态分区(Super)不仅包含图1和图3所示的基础操作系统数据存储结构中动态分区(Super)的所有子分区。除此以外，定制数据以动态分区的子分区的形式被添加在定制动态分区(Super)中，如图6所示，定制动态分区(Super)还包含定制(version)分区、货架(preload)分区。Version分区、preload分区用于保存定制数据。

例如，version分区可以用于存放运营商(如移动、联通)相关的定制化数据。preload分区可以用于存放设备出厂时预装的三方应用的相关数据。这里需要说明的是，在图6所示的实施例中，定制数据保存在version分区以及preload分区中。在本申请其他实施例中，也可以采用其他分区结构保存定制数据。例如，仅保留version分区或仅保留preload分区。又例如，再额外增加一个服务分区。

在上述定制操作系统中，为了满足用户日益增加的定制化需求，可能需要频繁对定制数据进行升级。与此同时，为了方便对定制操作系统管理，可以将定制操作系统的数据存储结构划分为多个组件。图7为本申请一实施例的数据存储结构示意图。如图7所示，可以将定制动态分区中的version分区和静态分区中用于存储version分区的校验内容的分区(如vbmeta_version分区)合称为定制(version)组件，将定制动态分区中的preload分区和静态分区中用于存储preload分区的校验内容的分区(如vbmeta_preload分区)合称为货架化(preload)组件，以及将定制动态分区中基础操作系统数据存储结构中动态分区的所有子分区，如system、system_ext、product、vendor等分区，和静态分区中的剩余部分合称为基础(base)组件。这里需要说明的是，图7所示的实施例中，组件的划分仅为示例性的。实际实施时，可根据各个分区的关联性灵活进行划分。例如，可以将定制动态分区中的每个分区和静态分区中用于校验该分区的空间划分为一个组件。下文中，将主要以如图7所示划分的base组件、version组件和preload组件为例，来说明本申请方案。

通过划分组件，可以将关联性强的分区，例如，存储的数据的作用相似的分区，划分为同一组件。并且，当任一组件的数据有更新时，则会产生升级需求。尤其是preload组件，其升级需求极大。

由于version分区、preload分区是定制动态分区(Super)的子分区。因此，整个定制操作系统(基础数据+定制数据)也可以采用图5A所示的升级方案进行升级。如图8中的(a)所示，当有至少两个组件(如version组件和preload组件)有升级需求时，可以将需要升级的组件(如version组件和preload组件)的新版本和不需要升级的组件(如base组件)的当前版本组合为一个新版本后发布，即发布组合升级包。然后，设备在获取到该组合升级包后，可以使用图5A所示的升级流程来完成升级。这种升级方式，当任意数量的组件需要升级时，都需要组合得到一个大版本的系统升级包，然后才能升级。如此，随着各个组件的升级需求越来越大，则会得到大量大版本的升级包，不利于灵活管理。

若不采用上述发布组合升级包升级的方式，如图8中的(b)所示，当base组件需要升级时，则可以发布base组件的升级安装包(也可称为base安装包)；当version组件需要升级，则可以发布version组件的升级安装包(也可称为version升级包)；preload组件需要升级，则可以发布preload组件的升级安装包(也可称为preload升级包)。也就是说，每个组件的版本可以独立演进。当有多个组件需要升级时，可以发布该多个组件对应的升级安装包。之后，若采用图5A所示的升级流程来完成升级，则设备只会针对其中一个升级安装包解析出的manifest来调整slot1和创建cow文件的索引。这样，会导致对slot1的调整不完全，创建的cow文件的索引也不准确，最终影响定制动态分区(Super)的加载。

基于上述问题，本申请提供一种操作系统中多个组件组合升级的方法，采用该方法，可以对操作系统(基础操作系统或者定制操作系统)中至少两个组件组合进行升级更新，从而可以灵活适配各种升级需求。例如，base组件和version组件组合升级的需求，version组件和preload组件组合升级的需求等。具体的，当设备当前是从静态分区(A)启动时，设备按照图9所示的流程实现多个组件的组合升级。

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

从静态分区(A)启动时，读取Slot0中的多个子分区描述组，以加载动态分区的数据。此时，运行的是升级前的操作系统，也可以称为第一操作系统。

应理解，在将图9的实施例应用于基础操作系统的升级时，则动态分区(Super)是指基础操作系统中的动态分区(Super)。在将图9的实施例应用于定制操作系统的升级时，则动态分区(Super)是指定制操作系统中的定制动态分区(Super)。下文中也是如此，将不再一一赘述。

S901、设备获取多个组件的多个升级包。

本申请实施例中，多个升级包包括base升级包和version升级包的组合，base升级包和preload升级包的组合，version升级包和preload升级包的组合，base升级包、version升级包和preload升级包的组合中的一种。当多个组件有升级需求时，设备可一次下载得到多个组件的多个升级包。然后，针对该多个升级包统一对多个组件升级。

并且，各个升级包可用于升级相应组件涉及的动态子分区(即动态分区的子分区)和/或静态子分区(即静态分区的子分区)。应理解，每个组件涉及的动态子分区可以为一个或多个，涉及的静态子分区也可以为一个或多个。例如，多个组件包括version组件。version组件涉及的动态子分区为version分区，涉及的静态子分区为vbmeta_version分区，则version升级包可用于升级version分区和用于升级vbmeta_version分区。

为了方便说明，可以将一个组件的升级包称为一个升级安装包，有多个组件的多个升级包时，则可以用前缀第一、第二……来区别。以base升级包和version升级包的组合为例，可以将base升级包称为第一升级安装包，将version升级包称为第二升级安装包。以及，为了方便说明，可以将第一升级安装包用于升级的动态子分区称为第一子分区，将第二升级安装包用于升级的动态子分区称为第二子分区，将除多个升级包用于升级的动态子分区之外的子分区称为第三子分区。可以将第一升级安装包用于升级的静态子分区称为第五子分区，将第二升级安装包用于升级的动态子分区称为第六子分区，将除多个升级包用于升级的静态子分区之外的子分区称为第七子分区。应理解，实际实施时，根据数据存储结构中组件的划分，还可以有第三升级安装包、第四升级安装包等等，对应这些升级安装包，则可以升级另一些动态子分区和静态子分区，例如，第三升级包可以用于升级动态分区的第四子分区。本申请实施例对此不作具体限定。

在一种可行的实现方案中，设备定期向搜包服务器发起搜包请求，搜包请求包含设备当前运行的操作系统中各个组件的版本号；搜包服务器根据搜包请求中各个组件的版本号，检索当前是否存在更新版本号的各个组件的升级包。示例性的，设备当前运行的操作系统中base组件、version组件和preload组件的版本号均为版本1.1，若搜包服务器检索到base组件的最新版本号还是版本1.1，但是version组件和preload组件的最新版本号为1.2，则表明存在更新版本号的version组件和preload组件的升级包。当多个组件存在更新版本的升级包时，搜包服务器向设备反馈该多个组件的升级包的下载地址。设备根据下载地址即可下载相应组件的升级包。

设备在下载多个组件的升级包后，响应于升级系统的事件，例如，用户输入升级的操作、达到预定的升级时间等，设备中的在线升级服务(online update client，OUC)可将升级包在设备中的位置发送给设备的更新引擎(update engine)。之后，由该更新引擎来执行具体的升级操作，如后续的升级包解析、数据写入等操作，以完成升级。

S902、设备解析每个升级包，获得多个升级包对应的多个应用清单数据(manifest)。

从每个升级包的元数据(/metadata)中，设备可读取到payload.bin的头数据在升级包中的偏移位置和大小。然后，设备根据该payload.bin的头数据在升级包中的偏移位置和大小则可以从升级包中获取到manifest。

示例性的，升级包的元数据(/metadata)中记录的部分内容如下所示：

files＝payload_metadata.bin:720:1346,payload.bin:720:285881,payload_properties.txt:286653:150,VERSION.mbn:286929:106,SOFTWARE_VER.mbn:286849:21,metadata:63:616。

上述内容中，payload_metadata.bin:720:1346的含义为：payload.bin的头数据(即manifest)在升级包的偏移位置(如720，单位字节)和大小(如1346，单位字节)。然后，设备根据该偏移位置和大小则可获得manifest的原始裸数据(即升级包里记录的原始数据)，再调用对该原始裸数据解码可获得manifest的具体内容。

本申请实施例中，从每个升级包中解析出的manifest中包括的静态分区信息仅涉及该多个组件包括的静态分区的子分区，动态分区信息仅涉及该多个组件包括的动态分区的子分区，而不涉及其他组件。其他组件是指该多个组件之外的组件。其中，静态分区信息或者动态分区信息(可简称为分区信息)都包括子分区的名字(也可以理解为分区标识)、大小、升级后的数据的校验值(如哈希值)以及升级数据在升级包里的位置。为了方便说明，可以将从多个升级包中解析出的多个应用清单数据称为第一数据、第二数据……，例如，将从第一升级安装包中解析出的应用清单数据称为第一数据，将从第二升级安装包中解析出的应用清单数据称为第二数据……。

示例性的，多个组件包括version组件。由于version组件包括静态分区中的vbmeta_version分区和动态分区中的version分区，相应的，解析出的manifest中可以包括如下分区信息：

vbmeta_version分区的名字、大小、升级后的数据的校验值(如哈希值)信息、升级数据在version升级包里的位置；

version分区的名字、大小、升级后的数据的校验值(如哈希值)信息、升级数据在version升级包里的位置。

又示例性的，多个组件包括preload组件。由于preload组件包括静态分区中的vbmeta_preload分区和动态分区中的preload分区，相应的，解析出的manifest中可以包括如下分区信息：

vbmeta_preload分区的名字、大小、升级后的数据的校验值(如哈希值)信息、升级数据在preload升级包里的位置；

preload分区的名字、大小、升级后的数据的校验值(如哈希值)信息、升级数据在preload升级包里的位置。

再示例性的，多个组件包括base组件。由于base组件包括静态分区中除vbmeta_version和vbmeta_preload之外的分区，例如boot、recovery等分区，和基础操作系统中动态分区包括的子分区，例如，system、product等分区，相应的，解析出的manifest中可以包括如下分区信息：

boot分区的名字、大小、升级后的数据的校验值(如哈希值)信息、升级数据在操作系统升级包里的位置；

recovery分区的名字、大小、升级后的数据的校验值(如哈希值)信息、升级数据在操作系统升级包里的位置；

……(其他静态分区的子分区的分区信息)

system分区的名字、大小、升级后的数据的校验值(如哈希值)信息、升级数据在操作系统升级包里的位置；

system_ext分区的名字、大小、升级后的数据的校验值(如哈希值)信息、升级数据在操作系统升级包里的位置；

vendor分区的名字、大小、升级后的数据的校验值(如哈希值)信息、升级数据在操作系统升级包里的位置；

……(其他动态分区的子分区的分区信息)。

S903、设备将多个manifest合并，得到合并后的manifest。

为了方便说明，可以将合并后的manifest称为第三数据。

在合并处理时，设备可以将多个manifest按照第一预设顺序首尾拼接。示例性的，第一预设顺序从前至后依次为从base升级包解析出的manifest，从version升级包解析出的manifest和从preload升级包解析出的manifest。或者，设备也可以将多个manifest中的静态分区信息和动态分区信息分别按照第一预设顺序拼接。示例性的，参见图10，以多个升级包包括base升级包、version升级包和preload升级包为例，设备在将从该三个升级包中解析出的三个manifest合并时，可以依次将从base升级包中解析出的manifest、从version升级包中解析出的manifest和从preload升级包中解析出的manifest中的静态分区信息拼接，以及依次将从base升级包中解析出的manifest、从version升级包中解析出的manifest和从preload升级包中解析出的manifest中的动态分区信息拼接，得到拼接后的manifest。

经过S903，设备可以得到合并后的manifest，并且可以将合并后的manifest放入新创建的对象，如mergedmanifest中。后续设备则可以仅根据mergedmanifest的值来完成相应的处理即可，如调整slot1，创建cow文件的索引等。

S904、设备根据合并后的manifest中的动态分区信息，调整动态分区(Super)里slot1中的子分区描述组，得到调整后的slot1。其中，调整子分区描述组的过程中，设备不从slot1中删除其他组件包括的子分区的子分区描述组，其他组件是除多个组件之外的组件。

其中，合并后的manifest包括：动态分区中多个组件包括的子分区的动态分区信息，动态分区信息中包括子分区的名字和大小。设备在根据合并后的manifest调整slot1的过程中，设备根据动态分区信息中子分区的名字和大小调整slot1中相应子分区描述组中的地址(Extents)项。若子分区的大小未发生变化，则slot1中相应子分区描述组中的地址(Extents)项不改变。若子分区的大小发生变化，则调整slot1中相应子分区描述组中的地址(Extents)项。从而使调整后的slot1中各个子分区描述组的地址(Extents)项与相应子分区的大小相匹配。下文实施例中，将主要以子分区的大小未发生改变来说明本申请方案。

以及，若多个组件仅为base组件、versio组件和preload组件中的两个，则表明不是所有的组件需要升级。本申请实施例中，设备在根据合并后的manifest调整slot1的过程中，不会从slot1中删除其他组件包括的子分区的子分区描述组，即删除不需要升级的组件包括的子分区的子分区描述组。为了方便说明，可以将调整后的slot1中包括的多个子分区描述组称为多个第三描述组。

示例性的，多个组件为version组件和preload组件，即仅有version组件和preload组件需要升级，而base组件无需升级。其中，version组件包括的子分区为version分区，preload组件包括的子分区为preload分区，那么合并后的manifest中包括version分区和preload分区的动态分区信息。假设升级前后动态分区的各个子分区的大小未发生变化，且调整前的slot1中包括如图11中的(a)所示的子分区描述组，即：调整前的slot1中包括system、system_ext、product、vendor、cust、odm、version和preload共8个子分区的子分组描述组。设备根据manifest调整slot1后，得到调整后的slot1中包括如图11中的(b)所示的子分区描述组。相较于调整前的slot1，调整后的slot1中并未删除version分区和preload分区之外的子分区描述组。例如，调整前的slot1中包括system、system_ext、product等分区(属于base组件包括的子分区)的子分区描述组，调整后的slot1中也同样包括system、system_ext、product等分区(属于base组件包括的子分区)的子分区描述组(如图11中的(b)中的虚线框所示)。上述举例中，以各个子分区的大小未发生变化为前提，则相较于调整前的slot1中的每个子分区描述组，调整后的slot1中对应的子分区描述组都是相同的。但是实际中，若多个组件中至少一个子分区(如version分区)升级前的大小和升级后的大小不同，则slot1中该至少一个子分区的子分区描述组中地址(Extents)项可能会相应发生变化。

也就是说，在调整slot1的过程中，不会删除合并后的manifest中动态分区信息不涉及的子分区(如第三子分区)的描述组。

需要说明的是，若调整前的slot1是初始的slot1，那么在根据manifest调整slot1的过程中，设备会删除与静态分区(A)对应的子分区描述组，即后缀为_a的子分区描述组，而仅保留与静态分区(B)对应的子分区描述组，即后缀为_b的子分区描述组。

S905、设备根据合并后的manifest中的动态分区信息，在基础分区(Common)中记录cow文件的索引。其中，该索引与manifest中动态分区信息涉及的子分区一致。

为了方便说明，可以将S905及其后续步骤中cow文件的索引称为第一索引。

若多个组件仅为base组件、versio组件和preload组件中的两个，则表明不是所有的组件需要升级。该情况下，调整后的slot1不仅包括多个组件(即需要升级的组件)对应的子分区描述组，而且还保留有其他组件(即不需要升级的组件)对应的子分区描述组。设备若直接复制调整后的slot1来得到cow文件的索引，则在后续加载动态分区(Super)时，该索引不仅会指示设备从用户数据分区(userdata)中读取多个组件(即需要升级的组件)包括的子分区对应的cow文件，还会指示设备从用户数据分区(userdata)中读取其他组件(即不需要升级的组件)包括的子分区对应的cow文件。然而，此次并不需要升级其他组件，设备也不会在用户数据分区(userdata)中写入其他组件包括的子分区对应的cow文件，因此，指示设备从用户数据分区(userdata)中读取其他组件包括的子分区对应的cow文件显然是不合理的。

基于此，在本申请实施例中，设备根据合并的manifest中的动态分区信息，在基础分区(Common)下记录cow文件的索引。其中，该索引与合并后的manifest中动态分区信息涉及的子分区一致。如此，索引可仅指示设备从用户数据分区(userdata)中读取需要升级的组件包括的子分区对应的cow文件。

仍以多个组件是version组件和preload组件为例，则合并后的manifest中包括version分区和preload分区的动态分区信息。相应的，设备可在基础分区(Common)中仅记录version分区的cow文件的索引和preload分区的cow文件的索引，以指示设备从用户数据分区(userdata)中读取version分区和preload分区对应的cow文件。

在一些实施例中，设备可以在获取到多个升级包后，在基础分区(Common)的元数据(/metadate)下创建/gsi/ota/lp_metadata文件，并在该/gsi/ota/lp_metadata文件中记录cow文件的索引。从而可以方便设备从固定的位置获取到cow文件的索引。

在一些实施例中，cow文件的索引包括cow文件的名字。示例性的，设备可以根据合并后的manifest中包括动态分区信息涉及的子分区(如第一子分区、第二子分区)，和cow文件的命名规则，来生成动态分区信息涉及的子分区的cow文件的名字，并将该名字作为索引。例如，动态分区信息涉及的子分区为version分区和preload分区，并且设备当前从静态分区(A)启动，则可生成version分区的cow文件的名字可以为：version_b_cow_img，生成preload分区的cow文件的名字可以为：preload_b_cow_img。其中，后缀_b对应静态分区(B)，则可以在从静态分区(B)重启时读取以加载动态分区。设备可将该名字version_b_cow_img写入基础分区(Common),作为version分区的cow文件的索引；将设备可将该名字preload_b_cow_img写入基础分区(Common),作为preload分区的cow文件的索引。如此，可以通过名字准确指示需要查找的cow文件。为了方便说明，可以将第一子分区的cow文件的名字称为第一文件名，将第二子分区的cow文件的名字称为第二文件名。

在一些实施例中，cow文件的索引还包括cow文件的存储位置。示例性的，存储位置可以是用户数据分区(userdata)。又示例性的，存储位置可以是用户数据分区(userdata)的目标目录(例如，/data/gsi/ota目录)，用户数据分区(userdata)的目标目录用于存储升级数据，若升级数据以cow文件存储，则cow文件也存储在该目标目录下。如此，可以通过存储位置准确指示查找cow文件的位置。

仍以多个组件是version组件和preload组件为例，则得到的cow文件的索引可以包括下述信息：

内容：version_b_cow_img、preload_b_cow_img

位置：userdata。

上述索引表示在用户数据分区(userdata)中有名为version_b_cow_img和名为preload_b_cow_img的cow文件。

应理解，前述S904和S905并没有严格的先后顺序。实际实施时，S905也可以在S904之前，或者S904和S905可以同时执行，本申请实施例对此不作具体限定。

在本申请实施例中，在得到合并后的manifest之后，一方面经过上述S904，设备可以根据合并后的manifest调整slot1，调整后的slot1中依然保留此次未升级的组件包括的子分区的子分区描述组。另一方面经过S905，设备可以根据合并或manifest创建cow文件的索引，使cow文件的索引仅指示设备从用户数据分区(userdata)中读取此次需要升级的组件包括的子分区对应的cow文件。

S906、设备根据多个升级包在用户数据分区(Userdata)创建虚拟动态分区，并依次根据多个升级包针对静态分区(B)进行数据写入操作以升级静态分区，以及在虚拟动态分区中写入动态分区(Super)的升级数据。在虚拟动态分区中，采用cow文件保存动态分区(Super)的升级数据。

其中，每个升级包中包括用于升级动态子分区的升级数据和用于升级静态子分区的升级数据。为了方便说明，可以将第一升级安装包用于升级动态子分区(如第一子分区)的升级数据称为第一升级数据，将第二升级安装包用于升级动态子分区(如第二子分区)的升级数据称为第二升级数据。以及，可以将第一升级安装包用于升级静态子分区(如第五子分区)的升级数据称为第三升级数据，将第二升级安装包用于升级静态子分区(如第六子分区)的升级数据称为第四升级数据。

本申请实施例中，设备将多个升级包中用于升级静态子分区的数据写入静态分区(B)的相应子分区(如第五子分区、第六子分区)，以及将多个升级包中用于升级动态子分区的数据写入虚拟动态分区中。

示例性的，以多个组件是version组件和preload组件为例。version组件包括vbmeta_version分区(属于静态分区的子分区)和version分区(属于动态分区的子分区)，preload组件包括vbmeta_preload分区(属于静态分区的子分区)和preload分区(属于动态分区的子分区)。相应的，设备在数据更新时，将version升级包中vbmeta_version分区的数据和preload升级包中vbmeta_preload分区的数据写入静态分区(B)的相应分区中。例如，将vbmeta_version分区的数据写入/dev/block/by-name/vbmeta_version_b目录下，将vbmeta_preload分区的数据写入/dev/block/by-name/vbmeta_preload_b目录下，其中，目录中的后缀_b对应静态分区(B)。以及，将version升级包中version分区的数据和preload升级包中preload分区的数据以cow文件写入虚拟动态分区中。例如，将version分区的数据写入到虚拟动态分区中名为version_b_cow_img的cow文件中，将preload分区的数据写入到虚拟动态分区中名为preload_b_cow_img的cow文件中，同样的，文件名中的后缀_b对应静态分区(B)。

进一步的，由于涉及多个组件的升级，设备在数据更新时，则可以依次将每个升级包中用于升级静态子分区的数据和用于升级动态子分区的数据写入到相应的位置。而不能如图5A所示的升级方案中(S220和S540)仅根据将一个升级包的数据进行写入操作即完成数据更新。

具体的，设备在向静态分区(B)以及虚拟动态分区写入数据时，可以按照第二预设顺序依次遍历多个升级包，例如，第二预设顺序从前到后依次为base升级包、version升级包和preload升级包。并在遍历到每个升级包时，则从该升级包中获取升级数据写入到相应的位置，完成数据更新。其中，若为静态分区的升级数据，则写入到静态分区(B)中，若为动态分区的升级数据，则以cow文件的形式写入到用户数据分区(Userdata)下。每完成一个升级包对应的数据写入后，则判断是否还有升级包需要更新，若有，则继续遍历。若没有，则结束S906。

在一种具体的实现方式中，设备在获取到多个升级包后，可以将多个升级包按照第二预设顺序放入目标数组中，其中每个升级包为目标数组的一个元素。在S906中，设备可以从数组中依次取元素，在取到一个元素后，则完成相应升级包的数据写入。并且，每完成一个升级包的数据写入后，设备可继续从目标数组中取元素，若能取到元素，则判定还有升级包需要更新，则继续数据写入。反之，若不能取到元素，则判定所有升级包的数据已完成更新，则结束S906。

以多个组件是version组件和preload组件，第二预设顺序从前到后依次为base升级包、version升级包和preload升级包为例，由于多个组件中不包括base组件，设备则可以仅依次将version升级包和preload升级包放入目标数组中。在S906中，设备第一次可以从目标数组中取出version升级包，将version升级包中vbmeta_version分区的数据写入静态分区(B)的vbmeta_version分区中，将version升级包中version分区的数据以cow文件写入虚拟动态分区中，从而完成针对version升级包的数据更新。然后，设备第二次可以从目标数组中取出preload升级包，并将preload升级包中vbmeta_preload分区的数据写入静态分区(B)的vbmeta_preload分区中，将preload升级包中preload分区的数据以cow文件写入虚拟动态分区中，从而完成针对preload升级包的数据更新。至此，目标数组中的升级包已全部被取出，设备从目标数组中已经取不到升级包了，则可以判定所有升级包均已完成更新，则结束S906。

进一步的，在S906中完成数据更新之后，设备对各个子分区更新后的数据进行校验。在本申请实施例中，设备可以根据合并后的manifest来完成校验。

针对静态分区中的各个子分区，设备可以计算操作系统中该子分区升级后的数据的校验值(如哈希值)，然后将该校验值与合并后的manifest中相应子分区的目标校验值(如哈希值)比较，如果两者相同，则校验成功。以vbmeta_version分区为例，设备在对vbmeta_version分区完成数据写入后，可以计算/dev/block/by-name/vbmeta_version_b目录下的数据的sha256值，并将该sha256值与合并后的manifest中vbmeta_version分区的sha256值比较，两者相同则校验成功。

针对动态分区中的各个子分区，设备可以计算该子分区的数据和虚拟动态分区中该子分区的cow文件中数据的合成结果的校验值(如哈希值)，然后将该哈希值与合并后的manifest中相应子分区的目标校验值(如哈希值)比较，如果两者相同，则校验成功。以version分区为例，设备在向虚拟动态分区中名为version_b_cow_img的cow文件中写入version分区的升级数据后，可以计算动态分区中version分区的数据和虚拟动态分区中名为version_b_cow_img的cow文件中数据的合成结果的sha256值，并将该sha256值与合并后的manifest中version分区的sha256值比较，两者相同则校验成功。

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

S908、设备重启。

S909、设备依次加载基础分区(Common)、静态分区(B)，从静态分区(B)启动。

此时从静态分区(B)启动升级后的操作系统，也可以称为第二操作系统。

S910、设备根据调整后的slot1和cow文件的索引，加载动态分区(Super)以及用户数据分区(Userdata)中虚拟动态分区的cow文件。

本申请实施例中，调整后的slot1中包括base组件、version组件和preload组件对应的子分区描述组。因此，设备读取该调整后的slot1中的子分区描述组时，可以获取到动态分区中所有子分区的地址(Extents)项。以及，cow文件的索引中仅包括多个组件(即此次需要升级的组件)包括的子分区对应的cow文件的索引。因此，设备读取该cow文件的索引，可以仅获取到动态分区中升级的所有子分区对应的cow文件，即第一升级数据和第二升级数据。

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

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

另外，图9所示实施例中未详细说明的部分，可参见前文图5A所示实施例的说明，此处将不再赘述。

采用图9所示实施例的方案，设备在获取到多个组件的升级包后，可以针对多个升级包进行处理，完成对多个组件的升级。如此，可以灵活满足至少两个组件需要升级的需求。

进一步的，设备可以将调整前的slot1中的子分区描述组作为调整slot1和创建cow文件的索引的基础数据，然后通过增删改查等修改操作，来得到调整后的slot1和cow文件的索引。具体的，参见图12，在图9所示的流程中S904和S905之前，还包括S1200：

S1200、设备将静态分区(B)对应的slot1中的子分区描述组分别存到第一临时对象和第一文件中。

其中，第一临时对象(如target_metadata)是update engine进程创建的临时对象，用于调整slot1。第一文件(如lp_metadata)是update engine在基础分区(common)的元数据(metadata)下创建的文件，用于创建cow文件的索引。为了方便说明，也可以将第一文件称为目标文件。

具体的，设备可以将静态分区(B)对应的slot1(此时为调整前的slot1)中的子分区描述组复制到第一临时对象和第一文件中，以分别作为调整slot1的基础数据和创建cow文件的索引的基础数据。

继续参见图12，图9中的S904进一步包括S1201和S1202：

S1201、设备根据合并后的manifest中的动态分区信息，调整第一临时对象中的数据。其中，在调整第一临时对象中的数据的过程中，设备不删除其他组件包括的子分区的子分区描述组，其他组件是除多个组件之外的组件。

关于S1201调整第一临时对象中的数据的具体实现，可参见前文S904中调整slot1的说明，此处不再赘述。

S1202、设备将调整后第一临时对象中的数据更新到slot1中，得到调整后的slot1。

具体的，设备可以将调整后第一临时对象中的数据写入到slot1中，覆盖slot1中的原始数据，从而得到调整后的slot1。并且，在将调整后第一临时对象中的数据写入到slot1中，则释放该第一临时对象。

经过上述S1201和S1202，设备在第一临时对象中完成对slot1的调整，而不直接对slot1进行调整。如此，调整的过程并不直接针对slot1，从而可以避免调整过程影响操作系统的运行。

继续参见图12，图9中的S905进一步包括S1203和S1204：

S1203、设备根据合并后的manifest中的动态分区信息，调整第一文件中的数据。其中，在调整第一文件中的数据的过程中，设备会删除其他组件包括的子分区的子分区描述组，其他组件是除多个组件之外的组件。

仍以多个组件是version组件和preload组件为例，则合并后的manifest中的动态分区信息涉及的子分区为version分区和preload分区，其他组件为base组件。若第一文件的基础数据如图13中的(a)所示，则设备在调整第一文件中的数据时，会将base组件包括的子分区(例如，system、product等)的子分区描述组删除。在删除后，剩下的数据则如图13中的(b)所示，仅剩下version分区和preload分区的子分区描述组。

S1204、设备根据调整后第一文件中的数据生成cow文件的索引。

设备可以根据第一文件中剩余的描述组中名称项的值，以及cow文件的命名规则来生成cow文件的文件名，作为cow文件的索引，具体可参见前文S904中的说明。为了方便说明，可以将生成cow文件的文件名称为第一文件名，该第一文件名与多个组件涉及的动态分区的子分区对应。

经过上述S1203和S1204，设备以调整前slot1中的数据作为创建cow文件的索引的基础数据，则可以通过简单的增删改查来完成索引的创建。

进一步的，在创建得到cow文件的索引后，设备可以进一步根据该索引在用户数据分区(userdata)下创建空的cow文件(也可以称为初始cow文件)，以用于存储升级数据。其中，创建空的cow文件，可以理解为前文中的创建虚拟动态分区。具体的，如图14所示，图9中的S906进一步包括S1400和S1401：

S1400、设备根据cow文件的索引在用户数据分区(userdata)下创建空的cow文件。

cow文件的索引中，记录有动态分区中需要升级的各个子分区的相关信息，如子分区的名字、子分区对应的cow文件的名字等。设备根据该相关信息，可以生成与动态分区中需要升级的各个子分区对应的空的cow文件。示例性的，cow文件的索引中记录有分区名字“version”，设备根据cow文件的命名规则，则可以生成version分区对应的cow文件的名字为：version_b_cow_img。其中，后缀_b对应静态分区(B)，则可以在从静态分区(B)重启时读取以加载动态分区。然后，设备在用户数据分区(userdata)下创建名为version_b_cow_img的空的cow文件，并根据version分区的大小设置cow文件占用的空间大小，以为存储升级数据留足空间。其中，设备可以根据manifest中version分区大小而获取到version分区的大小。

在一些实施例中，cow文件的索引中包括cow文件的名字，具体可参见前文S905中的说明。在本实施例中，设备可直接在用户数据分区(userdata)下创建以名字命名的cow文件，并根据分区的大小设置cow文件占用的空间大小。为了方便说明，可以将根据第一文件名生成的初始cow文件称为第一初始cow文件，将根据第二文件名生成的初始cow文件称为第二初始cow文件。应明确，若第一子分区为多个，则第一文件名为多个，相应的，第一初始cow文件也为多个。同理，若第二子分区为多个，则第二文件名为多个，相应的，第二初始cow文件也为多个。

需要在此说明的是，S1400中创建空的cow文件的时机并不以图14所示的顺序为限。实际实施时，可以在创建得到cow文件的索引后，随时创建空的cow文件。并且，设备在获取到升级包后，直至重启的过程中，都是在正常运行的，则一直有运行数据在占用用户数据分区(userdata)的空间。因此，越早创建空的cow文件，则可以越早占用存储升级数据的空间。如此，可以避免因设备运行占用用户数据分区(userdata)的空间过多，而导致用于存储升级数据的空间不足。

S1401、设备依次根据多个升级包针对静态分区(B)进行数据写入操作以升级静态分区，以及在空的cow文件中写入动态分区(Super)的升级数据。其中，一个空的cow文件中写入动态分区(Super)中一个子分区的升级数据。

例如，在第一初始cow文件中写入第一升级数据，在第二初始cow文件中写入第二升级数据。

采用本实施例，设备根据cow文件的索引来创建空的cow文件，以占用存储升级数据的空间，避免设备运行而导致没有足够的空间存储升级数据。

如图15所示，在一种场景中，在设备出厂后，静态分区(A)和静态分区(B)中初始的数据是相同的，vbmeta_version分区的初始数据都是X1，vbmeta_preload分区的初始数据都是Y1，其他子分区的初始数据都是Z1。若设备当前从静态分区(A)启动，且当前需要升级version组件和preload组件，则设备在对静态分区进行数据更新时(如S906中)，会更新静态分区(B)中的vbmeta_version分区的数据，得到更新的数据X2，以及更新静态分区(B)中的vbmeta_preload分区的数据，得到更新的数据Y2。此时，静态分区(A)和静态分区(B)中vbmeta_version分区的数据则不相同了。此后，当设备当前从静态分区(B)启动，且当前需要升级preload组件和base组件，则设备在对静态分区进行数据更新时(如S906中)，会更新静态分区(B)中的vbmeta_preload分区的数据，得到更新的数据Y3，以及更新静态分区(B)中的system、system_ext分区(base组件包括的子分区)的数据，得到更新的数据Z2。此时，虽然完成了preload组件和base组件包括的子分区的数据更新，但是当前不需要升级的version组件包括的vbmeta_version分区的数据还是初始的数据X1，而不是此前更新后的X2。如此，则会导致静态分区(B)中的数据不是对应最新版本的数据。

针对该场景，在一些实施例中，若多个组件是base组件、version组件和preload组件中的两个，且设备当前从静态分区(A)启动，则设备在获取到多个升级包后，可以将静态分区(A)中其他组件(即当前无需升级的组件)包括的子分区的最新数据同步给静态分区(B)。或者，设备当前从静态分区(B)启动，则设备在获取到多个升级包后，可以将静态分区(B)中其他组件(即当前无需升级的组件)包括的子分区的最新数据同步给静态分区(A)。从而使无需升级的组件包括的子分区的最新数据，在静态分区(A)和静态分区(B)之间保持同步。具体的，在设备当前从静态分区(A)启动时，如图16所示，在图9中S902之后、S906之前，还包括S1600和S1601：

S1600、设备检测多个组件是否包括基础(base)组件、定制(version)组件和货架化(preload)组件。若是，则执行S906；若否，则执行S1601或者S1602。

若多个组件包括base组件、version组件和preload组件，则表明所有组件均需要升级。相应的，所有组件包括的子分区都需要更新。所有组件当然就涉及静态分区(B)的所有子分区，即静态分区(B)的所有子分区都需要更新，而不存在无需更新的子分区(如第七子分区)。该情况下，设备无需先在静态分区(A)和静态分区(B)之间同步最新的数据，而可以直接遍历多个升级包，进行数据更新。

若多个组件不包括base组件、version组件和preload组件的全部，则表明只有部分组件需要升级。即静态分区(B)中只有部分子分区需要更新。换言之，静态分区(B)中还有部分子分区(如第七子分区)无需更新。该情况下，设备则需要在静态分区(A)和静态分区(B)之间同步最新的数据。

S1601、若多个组件包括基础(base)组件，设备将静态分区(A)中其他组件包括的子分区的数据同步至静态分区(B)中的相应子分区。其中，其他组件是多个组件之外的组件。

其中，多个组件包括base组件的情况有如下两种：多个组件是base组件和version组件，或者base组件和preload组件。相应的，除该多个组件之外的其他组件则不包括base组件。

通常情况下，在静态分区的所有数据中，base组件包括的数据占据大部分，而version组件和preload组件包括的数据仅仅是一小部分。因此，在多个组件包括base组件时，设备可以将静态分区(A)中其他组件包括的子分区(第七子分区)的数据同步至静态分区(B)中的相应子分区内。示例性的，多个组件是base组件和preload组件，则其他组件是version组件，设备可以将静态分区(A)的vbmeta_version分区(即vbmeta_version_a)中的数据同步到静态分区(B)的vbmeta_version分区(即vbmeta_version_b)。如此，设备可以通过小部分数据的同步而实现静态分区中当前无需升级的子分区数据的同步。

为了方便说明，可以将静态分区(B)中涉及的数据量较大的子分区，例如，静态分区(B)中基础(base)组件涉及的子分区，称为预设子分区。

S1602、若多个组件不包括基础(base)组件，设备将静态分区(A)中所有子分区的数据同步至静态分区(B)中的相应子分区。

多个组件是version组件和preload组件，则多个组件不包括base组件。相应的，其他组件则是base组件。即，静态分区中的大部分数据都无需升级。因此，在多个组件不包括base组件时，设备可以直接将静态分区(A)中所有子分区的数据同步到静态分区(B)的相应子分区中。如此，在大部分数据无需升级时，设备无需从静态分区(A)去剔除不需要同步的数据，而可以通过全部同步来简化同步的步骤。

需要在此说明的是，S1600-S1602的执行时机并不以图16所示为限。实际实施时，设备可以在S902-S906之间的任意时刻执行上述S1600-S1602，本申请实施例对此不作具体限定。

采用本实施例，设备可以将静态分区(A)中当前无需升级的子分区的最新数据同步到静态分区(B)中，然后对静态分区(B)进行数据更新。如此，可以保证静态分区(B)中各个子分区的数据都是最新的。

进一步的，在数据更新的过程中(如图9A中的S906中)，设备可以显示数据更新的更新进度，例如，50％、80％等。当更新进度达到100％，则表示多个组件的数据更新完成。如图17所示，在设备执行图9中的S906的过程中，还包括S1700和S1701：

S1700、设备记录数据更新当前针对的组件的写入进度，以及记录数据更新当前针对的组件的排序数。

其中，写入进度可以反映当前针对的组件已完成写入的数据量，也可以称为保存进度。排序数可反映当前针对的组件在多个组件中更新时的排序位数。在一种具体的实现方式中，设备可以在用户数据分区(Userdata)中/data/misc/update_log/perfs目录下记录上述写入进度和排序数(即payload_id，也可以称为遍历序数)。

以多个升级包是version升级包和preload升级包，且第二预设顺序从前到后依次为base升级包、version升级包和preload升级包为例，则设备首先针对version组件进行数据更新，此时数据更新当前针对的组件为version组件，version组件为此次数据更新的第一个组件，则排序数为1。并且，随着设备不断写入数据，设备可实时更新针对version组件已完成写入的数据量，即针对version组件的写入进度。在针对version组件已完成写入的数据量达到version组件需要写入的数据总量后，设备开始针对preload组件进行数据更新，此时数据更新当前针对的组件为preload组件，preload组件为此次数据更新的第二个组件，则排序数更新为2。同样的，随着设备不断写入数据，设备可实时更新针对preload组件已完成写入的数据量，即针对preload组件的写入进度。

S1701、设备根据写入进度和排序数计算更新进度，显示该更新进度。

其中，更新进度是指针对多个组件已完成写入的数据量，占多个组件需要写入的数据总量的百分比。将写入进度对应的已完成写入的数据量记为p，排序数记为n，则更新进度q可通过如下公式计算得到：q＝[SUM(前n-1个组件需要写入的数据量)+p]/SUM(多个组件需要写入的数据量)。

仍以S1700中的举例来说，假设写入进度为70条数据，排序数为2，version组件需要写入的数据量为200条数据，preload组件需要写入的数据量为100条数据，那么更新进度q＝(200+70)/(200+100)＝90％。

在一种具体的实现方式中，设备可以根据合并后的manifest中获取每个组件需要写入的数据总量。具体的，合并后的manifest中，每条分区信息中包括升级数据在相应升级安装包中的位置，该位置包括起始位置的偏移量、结束位置的偏移量以及数据量的大小。其中，数据量的大小即为相应子分区的数据量。之后，设备将同一组件包括的多个子分区的数据量求和，则可得到相应组件的数据总量。

采用本实施例，设备可以在多个组件数据更新的过程中，准确的显示更新进度。

更进一步的，如图18中的(a)所示，在一些场景中，设备按照base组件、version组件、preload组件的顺序更新数据，并且在更新version组件的过程中，设备掉电。在设备重启后，若再次从base组件开始更新数据，则可能导致数据重复写入，影响升级。并且，还会影响延长升级时长。

基于该问题，在一些实施例中，设备可以根据前述图17所示实施例中记录的写入进度和排序数，从掉电时对应的更新进度继续开始更新。具体的，当设备重启后，设备可以确定是否为在更新数据的过程中掉电后重启的情况，若是，则确定需要继续执行(resume)数据更新。设备则可以根据排序数定位到掉电时正在更新的组件，也可以理解为定位到正在写入的目标升级包。如图18中的(b)所示，根据排序数2定位到version组件，即正在进行version升级包的数据写入。然后根据写入进度定位到掉电时正在更新的组件中正在更新的数据(目标数据)。如图18中的(c)所示，根据写入进度80条数据定位到掉电时已完成version组件中已写入80条数据的位置。最后，设备可以从定位的位置继续更新。如此，可以提高异常掉电处理的灵活性。

进一步的，在落盘(如图9中的S912)完成后，设备可以将cow文件的索引删除。具体的，如图19所示，在图9A中的S912之后，还包括S1900：

S1900、在虚拟动态分区中的所有数据落盘完成后，设备将cow文件的索引删除。

在存在至少一个子分区的数据未落盘完成的情况下，设备掉电，则在设备再次重启后，需要再次根据cow文件的索引来加载动态分区。因此，在本实施例中，当基础分区(Common)的元数据(/metadata)中所有子分区的落盘状态信息均由“未落盘(wait formerge)”改为“已落盘(merged)”后，则表明所有数据均已落盘完成，此时则将cow文件的索引删除。如此，设备可以在落盘过程中异常掉电重启的情况下，继续使用cow文件的索引来加载动态分区。

本申请实施例提供了一种电子设备，该电子设备可以包括：存储器和一个或多个处理器。该存储器和处理器耦合。该存储器用于存储计算机程序代码，该计算机程序代码包括计算机指令。当处理器执行计算机指令时，电子设备可执行上述方法实施例中设备执行的各个功能或者步骤。

本申请实施例还提供一种芯片系统，如图20所示，该芯片系统2000包括至少一个处理器2001和至少一个接口电路2002。处理器2001和接口电路2002可通过线路互联。例如，接口电路2002可用于从其它装置(例如电子设备的存储器)接收信号。又例如，接口电路2002可用于向其它装置(例如处理器2001)发送信号。示例性的，接口电路2002可读取存储器中存储的指令，并将该指令发送给处理器2001。当所述指令被处理器2001执行时，可使得电子设备执行上述实施例中的各个步骤。当然，该芯片系统还可以包含其他分立器件，本申请实施例对此不作具体限定。

本申请实施例还提供一种计算机存储介质，该计算机存储介质包括计算机指令，当该计算机指令在电子设备上运行时，使得该电子设备执行上述方法实施例中设备执行的各个功能或者步骤。

本申请实施例还提供一种计算机程序产品，当该计算机程序产品在计算机上运行时，使得该计算机执行上述方法实施例中设备执行的各个功能或者步骤。

通过以上实施方式的描述，所属领域的技术人员可以清楚地了解到，为描述的方便和简洁，仅以上述各功能模块的划分进行举例说明，实际应用中，可以根据需要而将上述功能分配由不同的功能模块完成，即将装置的内部结构划分成不同的功能模块，以完成以上描述的全部或者部分功能。

在本申请所提供的几个实施例中，应该理解到，所揭露的装置和方法，可以通过其它的方式实现。例如，以上所描述的装置实施例仅仅是示意性的，例如，该模块或单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个装置，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，装置或单元的间接耦合或通信连接，可以是电性，机械或其它的形式。

该作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是一个物理单元或多个物理单元，即可以位于一个地方，或者也可以分布到多个不同地方。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。

另外，在本申请各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现，也可以采用软件功能单元的形式实现。

该集成的单元如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个可读取存储介质中。基于这样的理解，本申请实施例的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的全部或部分可以以软件产品的形式体现出来，该软件产品存储在一个存储介质中，包括若干指令用以使得一个设备(可以是单片机，芯片等)或处理器(processor)执行本申请各个实施例该方法的全部或部分步骤。而前述的存储介质包括：U盘、移动硬盘、只读存储器(read only memory，ROM)、随机存取存储器(random access memory，RAM)、磁碟或者光盘等各种可以存储程序代码的介质。

以上内容，仅为本申请的具体实施方式，但本申请的保护范围并不局限于此，任何在本申请揭露的技术范围内的变化或替换，都应涵盖在本申请的保护范围之内。因此，本申请的保护范围应以该权利要求的保护范围为准。

Claims (17)

1.一种操作系统升级方法，其特征在于，应用于电子设备，所述电子设备包括处理器以及存储器，所述存储器包括基础分区、第一静态分区、第二静态分区、动态分区以及用户数据分区，所述动态分区包括第一插槽数据和第二插槽数据，所述动态分区包括多个子分区，所述第一插槽数据包括与所述多个子分区对应的多个第一描述组，所述第二插槽数据包括与所述多个子分区对应的多个第二描述组；

加载所述基础分区、所述第一静态分区和所述动态分区的数据，以运行第一操作系统，在加载所述动态分区的数据的过程中，读取所述多个第一描述组，基于所述多个第一描述组中地址项的值加载所述动态分区的数据；

获取第一升级安装包和第二升级安装包，所述第一升级安装包用于升级第一子分区，所述第二升级安装包用于升级第二子分区，所述第一子分区和所述第二子分区是所述动态分区的子分区，所述第一升级安装包包括第一数据，所述第一数据包括所述第一子分区的分区信息，所述第二升级安装包包括第二数据，所述第二数据包括所述第二子分区的分区信息；

根据第三数据和所述多个第二描述组得到多个第三描述组，所述第三数据中包括所述第一子分区的分区信息和所述第二子分区的分区信息，所述多个第三描述组中包括与所述第一子分区对应的描述组，与第二子分区对应的描述组，和与第三子分区对应的描述组，所述第三子分区是所述动态分区中除所述第一子分区和所述第二子分区之外的子分区；

重启所述电子设备，加载所述基础分区、所述第二静态分区和所述动态分区的数据，以运行第二操作系统，在加载所述动态分区的数据的过程中，读取所述多个第三描述组中地址项的值，基于所述多个第三描述组中地址项的值加载所述动态分区的数据。

2.根据权利要求1所述的方法，其特征在于，在所述获取第一升级安装包和第二升级安装包之后，所述方法还包括：

将所述多个第二描述组写入目标文件中，在所述目标文件中删除与所述第三子分区对应的描述组，生成第一索引。

3.根据权利要求1或2所述的方法，其特征在于，在所述加载所述基础分区、所述第一静态分区和所述动态分区的数据之后，所述方法还包括：

获取第三升级安装包，所述第三升级安装包用于升级第四子分区，所述第四子分区是所述动态分区的子分区，所述第三升级安装包包括第三数据，所述第三数据包括所述第四子分区的分区信息；

根据所述第三数据和所述多个第二描述组得到所述多个第三描述组，所述第三数据中还包括所述第四子分区的分区信息，所述第三子分区是所述动态分区中除所述第一子分区、所述第二子分区和所述第四子分区之外的子分区。

4.根据权利要求2或3所述的方法，其特征在于，所述第一升级安装包包括第一升级数据，所述第一升级数据用于升级所述第一子分区，所述第二升级安装包包括第二升级数据，所述第二升级数据用于升级所述第二子分区；

所述方法还包括：

在所述用户数据分区中保存所述第一升级数据和所述第二升级数据；

在加载所述动态分区的数据的过程中，读取所述目标文件，基于所述目标文件中的所述第一索引加载所述用户数据分区中的所述第一升级数据和所述第二升级数据。

5.根据权利要求4所述的方法，其特征在于，所述在所述目标文件中删除与所述第二子分区对应的描述组，生成第一索引，包括：

在所述目标文件中删除与所述第三子分区对应的描述组，得到与所述第一子分区对应的描述组和与所述第二子分区对应的描述组，所述与所述第一分区对应的描述组中包括所述第一子分区的名称，所述与所述第二子分区对应的描述组中包括所述第二子分区的名称；

基于所述第一子分区的名称生成与所述第一子分区对应的第一文件名，基于所述第二子分区的名称生成与所述第二子分区对应的第二文件名，所述第一索引包括所述第一文件名和所述第二文件名。

6.根据权利要求5所述的方法，其特征在于，在所述基于所述第一子分区的名称生成与所述第一子分区对应的第一文件名，基于所述第二子分区的名称生成与所述第二子分区对应的第二文件名之后，所述方法还包括：

在所述用户数据分区中创建文件名为所述第一文件名的第一初始cow文件，以及创建文件名为所述第二文件名的第二初始cow文件，所述第一初始cow文件和所述第二初始cow文件中未存储升级数据；

所述在所述用户数据分区中保存所述所述第一升级数据和所述第二升级数据，包括：

在所述第一初始cow文件中保存所述第一升级数据，在所述第二初始cow文件中保存所述第二升级数据。

7.根据权利要求1-6中任一项所述的方法，其特征在于，所述第一子分区包括一个或多个子分区，所述第二子分区包括一个或多个子分区，所述第三子分区包括一个或多个子分区。

8.根据权利要求4-7中任一项所述的方法，其特征在于，所述第二静态分区包括多个子分区，所述第一升级安装包还包括第三升级数据，所述第三升级数据用于升级第五子分区，所述第二升级安装包还包括第四升级数据，所述第四升级数据用于升级第六子分区，所述第五子分区和所述第六子分区是所述第二静态分区的子分区；

在所述获取第一升级安装包和所述第二升级安装包后，所述方法还包括：

将所述第三升级数据写入所述第五子分区，将所述第四升级数据写入所述第六子分区。

9.根据权利要求8所述的方法，其特征在于，所述第一静态分区包括多个子分区，所述第一静态分区的所述多个子分区与所述第二静态分区的所述多个子分区一一对应；

在将所述第三升级数据写入所述第五子分区，将所述第四升级数据写入所述第六子分区之前，所述方法还包括：

若所述第二静态分区包括第七子分区，检测所述第五子分区和所述第六子分区中是否包括预设子分区，所述第七子分区是所述第二静态分区中除所述第五子分区和所述第六子分区之外的子分区；

若所述第五子分区和所述第六子分区中包括所述预设子分区，将所述第一静态分区的所述第七子分区的数据同步至所述第二静态分区的所述第七子分区中；

若所述第五子分区和所述第六子分区中不包括所述预设子分区，将所述第一静态分区中所有子分区的数据同步至所述第二静态分区的对应子分区中。

10.根据权利要求9所述的方法，其特征在于，所述将所述第三升级数据写入所述第五子分区，将所述第四升级数据写入所述第六子分区，包括：

若所述第二静态分区不包括所述第七子分区，将所述第三升级数据写入所述第五子分区，将所述第四升级数据写入所述第六子分区。

11.根据权利要求4-10中任一项所述的方法，其特征在于，在所述用户数据分区中保存所述第一升级数据和所述第二升级数据，包括：

遍历所述第一升级安装包和所述第二升级安装包，遍历到所述第一升级安装包时，在所述用户数据分区中保存所述第一升级数据，遍历到所述第二升级安装包时，在所述用户数据分区中保存所述第二升级数据；

所述方法还包括：

记录当前遍历到的升级安装包包括的升级数据的保存进度，以及记录当前遍历的升级安装包的遍历序数；

计算所述保存进度和所述遍历序数对应的更新进度，显示所述更新进度。

12.根据权利要求11所述的方法，其特征在于，在所述用户数据分区中保存所述第一升级数据和所述第二升级数据的过程中，所述方法还包括：

若所述电子设备掉电重启，在所述第一升级安装包和所述第二升级安装包中定位所述遍历序数对应的目标升级安装包，以及在所述目标升级安装包的升级数据中定位所述写入进度对应的目标数据；

从所述目标升级安装包的所述目标数据开始，在所述用户数据分区中继续保存所述第一升级数据和所述第二升级数据。

13.根据权利要求1-12中任一项所述的方法，其特征在于，在所述根据第三数据和所述多个第二描述组得到多个第三描述组之前，所述方法还包括：

合并所述第一数据和所述第二数据，得到所述第三数据。

14.根据权利要求4-13中任一项所述的方法，其特征在于，在所述加载所述基础分区、所述第二静态分区和所述动态分区的数据之后，所述方法还包括：

将所述用户数据分区中的所述多个第一升级数据和所述第二升级数据落盘到所述动态分区的对应子分区中。

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

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

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

17.一种芯片系统，其特征在于，所述芯片系统应用于包括处理器和存储器的电子设备，所述芯片系统包括一个或多个接口电路和一个或多个处理器，所述接口电路和所述处理器通过线路互联，所述接口电路用于从所述电子设备的存储器接收信号，并向所述处理器发送所述信号，所述信号包括所述存储器中存储的计算机指令，当所述处理器执行所述计算机指令时，使得所述电子设备执行如权利要求1-14中任一项所述的方法。