CN115562695B

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

Info

Publication number: CN115562695B
Application number: CN202210134783.7A
Authority: CN
Inventors: 张赠辉; 王艳召; 陈超; 黄九林
Original assignee: Honor Device Co Ltd
Current assignee: Honor Device Co Ltd
Priority date: 2022-01-10
Filing date: 2022-02-14
Publication date: 2023-10-27
Anticipated expiration: 2042-02-14
Also published as: CN117519742A; CN115562695A

Abstract

本申请实施例提供的一种操作系统升级方法、电子设备、存储介质及芯片系统，涉及计算机技术领域，可以针对操作系统中的部分子分区独立升级。其中，方法包括：获取第一升级安装包，第一升级安装包包括第一升级数据，第一升级数据是针对第一子分区的升级文件，第一子分区是动态分区的子分区。根据第二插槽数据中的多个第二描述组，得到多个第三描述组。多个第三描述组中包括与第一子分区对应的描述组，以及与第二子分区对应的描述组，第二子分区是动态分区中除第一子分区之外的子分区。重启电子设备后，读取第二插槽数据，基于第二插槽数据加载动态分区的数据。

Description

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

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

技术领域

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

背景技术

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

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

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

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

发明内容

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

第一方面，本申请实施例提供一种操作系统升级方法，该方法可以应用于电子设备。该电子设备包括处理器以及存储器，存储器包括基础分区、第一静态分区、第二静态分区、动态分区以及用户数据分区，动态分区包括第一插槽数据和第二插槽数据，动态分区包括多个子分区，第一插槽数据包括与多个子分区对应的多个第一描述组，第二插槽数据包括与多个子分区对应的多个第二描述组。加载基础分区、第一静态分区和动态分区的数据，可以运行第一操作系统。在加载动态分区的数据的过程中，读取多个第一描述组，基于多个第一描述组中地址项的值加载动态分区的数据。在运行第一操作系统的过程中，获取第一升级安装包，第一升级安装包包括第一升级数据，第一升级数据是针对第一子分区的升级数据，第一子分区是动态分区的子分区。根据多个第二描述组得到多个第三描述组，多个第三描述组中包括与第一子分区对应的描述组，还包括与第二子分区对应的描述组，第二子分区是动态分区中除第一子分区之外的子分区。也就是说，多个第三描述组中包括动态分区中需要升级和不需要升级的所有子分区的描述组，而并未删除掉此次不升级的子分区对应的描述组。将多个第二描述组写入目标文件中，在目标文件中删除与第二子分区对应的描述组，生成第一索引。该第一索引指示电子设备获取第一升级数据。在用户数据分区中保存第一升级数据。重启电子设备，加载基础分区、第二静态分区和动态分区的数据，以运行第二操作系统。在加载动态分区的数据的过程中，读取多个第三描述组中地址项的值，基于多个第三描述组中地址项的值加载第二子分区的数据。从而可以成功加载此次未升级的第二子分区的数据。以及，在加载动态分区的数据的过程中，读取目标文件，基于目标文件中的第一索引加载用户数据分区中的第一升级数据。从而第一索引可以明确指示设备仅从用户数据分区中读取第一升级数据，以成功加载第一子分区的数据。

综上所述，采用本申请实施例的方法，一方面，电子设备在得到的多个第三描述组中依然保留此次未升级的组件包括的子分区的描述组。后续在加载升级后的操作系统的动态分区时，不仅可以加载得到升级的第一子分区的数据，还可以加载到未升级的第二子分区的数据。从而实现动态分区的成功加载。另一方面，电子设备在创建第一索引时，会删除掉多个第二描述组中未升级的第二子分区对应的描述组，使得创建的第一索引可仅指示电子设备获取用于升级第一子分区的第一升级数据。从而可以准确指示电子设备获取升级数据。最后，在重启以运行第二操作系统时，则可以根据多个第三描述组和第一索引成功加载动态分区，避免遗漏。

在第一方面的一种可能的设计方式中，上述在获取第一升级安装包之后，还包括：从第一升级安装包中解析出第一数据(manifest)，第一数据中包括第一子分区的分区信息，而不包括第二子分区的分区信息。分区信息中包括子分区的分区标识。在根据多个第二描述组得到多个第三描述组的过程中，不删除与第二子分区对应的描述组，第二子分区是除分区信息中分区标识指示的子分区之外的子分区。

也就是说，采用本实施例的方法，针对manifest的分区信息中不涉及的第二子分区，也不会从第二插槽数据中将其删除。如此，不升级的第二子分区的描述组仍然保留在第二插槽数据中，后续运行第二操作系统时，则可以依据第二插槽数据加载到第二子分区的数据。

在第一方面的另一种可能的设计方式中，上述在目标文件中删除与第二子分区对应的描述组，包括：在目标文件中删除与第二子分区对应的描述组，第二子分区是除分区信息中分区标识指示的子分区之外的子分区。

也就是说，采用本实施例的方法，针对manifest的分区信息中不涉及的第二子分区，在生成第一索引时，会将其删除。从而使得到的第一索引仅指示电子设备读取第一子分区的升级数据。

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

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

在第一方面的另一种可能的设计方式中，上述在确定第一索引包括第一文件名之后，还包括：在用户数据分区中创建文件名为第一文件名的初始cow文件，初始cow文件中未存储升级数据。上述在用户数据分区中保存第一升级数据，包括：在初始cow文件中保存第一升级数据。

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

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

在第一方面的另一种可能的设计方式中，上述第一子分区包括动态分区的至少一个子分区，第二子分区包括动态分区的至少一个子分区。

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

在第一方面的另一种可能的设计方式中，上述第二静态分区包括多个子分区，第一升级安装包还包括第二升级数据，第二升级数据是针对第三子分区的升级数据，第三子分区是第二静态分区的子分区。也就是说，第一升级安装包还可以用于升级静态分区的子分区。相应的，在获取第一升级安装包之后，向存储器中写入升级数据时，还需要向第二静态分区的第三子分区中写入第二升级数据。

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

在第一方面的另一种可能的设计方式中，上述第一静态分区中包括多个子分区，第一静态分区中的多个子分区与第二静态分区中的多个子分区一一对应。上述在向第二静态分区的第三子分区中写入第二升级数据之前，还包括：若第三子分区包括预设子分区，将第一静态分区中第四子分区的数据同步至第二静态分区的对应子分区中，第四子分区是第一静态分区中除第三子分区之外的子分区。预设子分区是静态分区中存储数据量较大的子分区，例如，静态分区中base组件包括的子分区。也就是说，在此次需要升级的数据为大量数据的情况下，电子设备可以仅将第一静态分区中无需升级的子分区(即第四子分区)的数据同步给第二静态分区，以保证第二静态分区中无需升级的子分区(即第四子分区)的数据是最新的。从而可以通过小部分数据的同步而实现当前无需升级的子分区数据的同步。

若第三子分区不包括预设子分区，将第一静态分区中所有子分区的数据同步至第二静态分区的对应子分区中。如此，在大部分数据无需升级时，设备无需从第一静态分区去剔除不需要同步的数据，而可以通过全部同步来简化同步的步骤。

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

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

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

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

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

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

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

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

附图说明

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

具体实施方式

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

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

在终端设备(简称设备)出厂前，将操作系统烧录到设备中，从而实现在设备出厂前安装操作系统。此后，为了提升用户体验，可能需要对设备中的操作系统进行升级。此时，可采用空中下载技术(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中包括如下动态分区信息：

很显然，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组件)有升级需求时，可以将需要升级的组件(如version组件)的新版本和不需要升级的组件(如base组件和preload组件)的当前版本组合为一个新版本后发布，即发布组合升级包。然后，设备在获取到该组合升级包后，可以使用图5A所示的升级流程来完成升级。这种升级方式，当仅有一个组件需要升级时，也需要组合得到一个大版本的系统升级包，然后才能升级。如此，随着各个组件的升级需求越来越大，则会得到大量大版本的升级包，不利于设备供应商对系统版本的灵活管理。

若不采用上述发布组合升级包升级的方式，则可以当任一组件需要升级时，则发布该组件对应的升级安装包。如图8中的(b)所示，当base组件需要升级时，则可以单独发布base组件的升级安装包(也可称为base安装包)；当version组件需要升级，则可以单独发布version组件的升级安装包(也可称为version升级包)；preload组件需要升级，则可以单独发布preload组件的升级安装包(也可称为preload升级包)。也就是说，每个组件的版本可以独立演进。之后，采用图5A所示的升级流程来完成升级，则在调整slot1时，会删除掉此次不需要升级的子分区的子分区描述组。示例性的，仅需对version组件升级，则调整后的slot1中将仅保留version分区的子分区描述组，如大小、地址等信息。最后，在加载动态分区时，则会因slot1中缺少对preload组件、base组件包括的子分区的子分区描述组，最终影响定制动态分区(Super)的加载。

基于上述问题，本申请提供一种操作系统的升级方法，采用该方法，可以对操作系统(基础操作系统或者定制操作系统)中的一个组件进行独立升级，例如，base组件、version组件或者preload组件独立升级。从而使得各个组件的版本可以独立演进。具体的，当设备当前是从静态分区(A)启动时，设备按照图9A所示的流程实现独立组件的升级。

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

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

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

S901、设备获取第一组件的升级包。

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

为了方便说明，可以将第一组件的升级包称为第一升级安装包。将第一组件涉及的动态分区的子分区称为第一子分区。将第一组件涉及的静态分区(B)的子分区称为第三子分区。例如，第一组件是version组件，那么第一组件涉及的分区包括静态分区(B)中的vbmeta_version子分区和动态分区中的version子分区，则version子分区为第一子分区，静态分区(B)中的vbmeta_version子分区为第三子分区。

以及，第一组件的升级包中包括用于升级第一组件涉及的分区的升级数据。为了方便说明，可以将第一组件的升级包中用于升级动态分区的升级数据称为第一升级数据，将用于升级静态分区的升级数据称为第二升级数据。仍以第一组件是version组件为例，那么第一组件的升级包中包括用于升级静态分区(B)中vbmeta_version子分区的升级数据和用于升级动态分区中version子分区的升级数据，则用于升级version子分区的升级数据即为第一升级数据，用于升级静态分区(B)中vbmeta_version子分区的升级数据即为第二升级数据。

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

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分区的名字、大小、升级后的数据的校验值(如哈希值)以及升级数据在操作系统升级安装包里的位置；

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

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

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

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

以及，在调整slot1的过程中，设备不会从slot1中删除第一组件之外的其他组件(即第二组件)包括的子分区的子分区描述组。为了方便说明，可以将调整后的slot1中包括的多个子分区描述组称为多个第三描述组。

仍以第一组件是version组件，并且version分区大小未发生变化为例。设备从升级包中解析出的manifest中包括vbmeta_version分区的静态分区信息和version分区的动态分区信息。并且，调整前的slot1中包括如图9B中的(a)所示的子分区描述组，即：调整前的slot1中包括system、system_ext、product、vendor、cust、odm、version和preload共8个子分区的子分区描述组。设备根据manifest调整slot1后，得到调整后的slot1中包括如图9B中的(b)所示的子分区描述组。相较于调整前的slot1，调整后的slot1中并未删除preload组件和base组件包括的子分区的子分区描述组。例如，调整前的slot1中包括preload分区(属于preload组件包括的子分区)的子分区描述组，调整后的slot1中也同样包括preload分区的子分区描述组。需要注意的是，上述举例中，以version分区大小未发生变化为前提，则相较于调整前的slot1中的每个子分区描述组，调整后的slot1中对应的子分区描述组都是相同的。但是实际中，若version分区大小发生了变化，则slot1中的version分区的子分区描述组中地址(Extents)项可能会相应发生变化。

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

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

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

由于调整后的slot1不仅包括第一组件包括的子分区的子分区描述组，而且还保留第二组件包括的子分区的子分区描述组。该情况下，设备若直接复制调整后的slot1来得到cow文件的索引，则在后续加载动态分区(Super)时，该索引不仅会指示设备从用户数据分区(userdata)中读取第一组件包括的子分区对应的cow文件，还会指示设备从用户数据分区(userdata)中读取第二组件包括的子分区对应的cow文件。然而，此次并不需要升级第二组件，设备也不会在用户数据分区(userdata)中写入第二组件包括的子分区对应的cow文件，因此指示设备从用户数据分区(userdata)中读取第二组件包括的子分区对应的cow文件显然是不合理的。

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

仍以第一组件是version组件为例，则解析出的manifest中包括vbmeta_version分区的静态分区信息和version分区的动态分区信息。相应的，设备可在基础分区(Common)中仅记录version分区的cow文件的索引，以指示设备从用户数据分区(userdata)中读取version分区的cow文件。如此，索引可仅指示设备从用户数据分区(userdata)中读取需要升级组件包括的子分区的cow文件。

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

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

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

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

内容：version_b_cow_img；

位置：userdata。

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

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

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

S905、设备根据第一组件的升级包针对静态分区(B)进行数据写入操作以升级静态分区。

将升级包中用于升级静态分区(B)的升级数据(即第二升级数据)，写入到静态分区(B)中第一组件涉及的静态子分区(即第三子分区)中。

仍以第一组件是version组件为例，version组件包括的子分区中vbmeta_version分区属于静态分区。相应的，设备在写入数据时，将第一组件的升级包中vbmeta_version分区的数据写入静态分区(B)的vbmeta_version分区中，如静态分区(B)的/dev/block/by-name/vbmeta_version_b目录下。

S906、设备根据第一组件的升级包在用户数据分区(Userdata)创建虚拟动态分区，在虚拟动态分区写入动态分区(Super)的升级数据。在虚拟动态分区中，升级数据以cow文件保存。

仍以第一组件是version组件为例，version组件包括的子分区vesion分区属于动态分区。相应的，设备在用户数据分区(Userdata)的虚拟动态分区中写入version分区的升级数据，即写入第一升级数据。并且将升级数据存入cow文件version_b_cow_img.img.0000中。

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

S908、设备重启。

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

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

关于S905-S909未详细说明的部分，可参见前文S220-S240的说明，此处将不再赘述。

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

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

关于S910中未详细说明的部分，可参见前文S540的说明，此处将不再赘述。

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

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

采用图9A所示实施例的升级方案，设备在仅获取到单个组件的升级包后，可以仅针对该单个组件进行升级。从而实现独立组件独立演进。

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

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

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

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

继续参见图10，图9A中的S903进一步包括S1001和S1002：

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

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

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

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

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

继续参见图10，图9A中的S904进一步包括S1003和S1004：

S1003、设备根据manifest中的动态分区信息，调整第一文件中的数据。其中，在调整第一文件中的数据时，设备会删除第二组件包括的子分区的子分区描述组，第二组件是除第一组件之外的组件。

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

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

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

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

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

S1200、设备根据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文件的名字，具体可参见前文S904中的说明。在本实施例中，设备可直接在用户数据分区(userdata)下创建以名字命名的cow文件，并根据分区的大小设置cow文件占用的空间大小。

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

S1201、设备在空的cow文件中写入动态分区(Super)的升级数据。其中，一个空的cow文件中写入动态分区(Super)中一个子分区的升级数据。

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

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

针对该场景，在一些实施例中，若设备当前从静态分区(A)启动，则设备在获取到第一组件的升级包后，可以将静态分区(A)中第二组件(即当前无需升级的组件)包括的子分区的最新数据同步给静态分区(B)。或者，若设备当前从静态分区(B)启动，则设备在获取到第一组件的升级包后，可以将静态分区(B)中第二组件(即当前无需升级的组件)包括的子分区的最新数据同步给静态分区(A)。从而使无需升级的组件包括的子分区的最新数据，在静态分区(A)和静态分区(B)之间保持同步。具体的，在设备当前从静态分区(A)启动时，如图14所示，在图9A中S902之后、S905之前，还包括S1400和S1401：

S1400、若第一组件是基础(base)组件，设备将静态分区(A)中第二组件包括的子分区中的数据同步至静态分区(B)中的相应子分区。

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

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

S1401、若第一组件是定制(version)组件或者货架化(preload)组件，设备将静态分区(A)中所有子分区的数据同步至静态分区(B)中的相应子分区。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Claims

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

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

获取第一升级安装包，所述第一升级安装包包括第一升级数据，所述第一升级数据是针对第一子分区的升级数据，所述第一子分区是所述动态分区的子分区；

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

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

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

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

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

从所述第一升级安装包中解析出第一数据，所述第一数据中包括所述第一子分区的分区信息，所述分区信息中包括所述第一子分区的分区标识；

其中，在根据所述多个第二描述组得到所述多个第三描述组的过程中，不删除与所述第二子分区对应的描述组，所述第二子分区是除所述分区信息中分区标识指示的子分区之外的子分区。

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

在所述目标文件中删除与所述第二子分区对应的描述组，所述第二子分区是除所述分区信息中分区标识指示的子分区之外的子分区。

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

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

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

5.根据权利要求4所述的方法，其特征在于，在确定所述第一索引包括所述第一文件名之后，所述方法还包括：

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

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

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

6.根据权利要求1-5中任一项所述的方法，其特征在于，所述目标文件位于所述基础分区中。

7.根据权利要求1-5中任一项所述的方法，其特征在于，所述第一子分区包括所述动态分区的至少一个子分区，所述第二子分区包括所述动态分区的至少一个子分区。

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

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

向所述第二静态分区的所述第三子分区中写入所述第二升级数据。

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

在所述向所述第二静态分区的所述第三子分区中写入所述第二升级数据之前，所述方法还包括：

若所述第三子分区包括预设子分区，将所述第一静态分区中第四子分区的数据同步至所述第二静态分区的对应子分区中，所述第四子分区是所述第一静态分区中除所述第三子分区之外的子分区；

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

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

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

11.一种电子设备，其特征在于，所述电子设备包括处理器以及存储器，所述存储器包括基础分区、第一静态分区、第二静态分区、动态分区以及用户数据分区，所述动态分区包括多个子分区，所述处理器用于执行所述存储器上存储的软件代码，以使得所述电子设备执行如权利要求1-10中任一项所述的方法。

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

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