CN118113318A

CN118113318A - 一种操作系统的升级方法及电子设备

Info

Publication number: CN118113318A
Application number: CN202211524696.9A
Authority: CN
Inventors: 陈超; 王艳召
Original assignee: Honor Device Co Ltd
Current assignee: Honor Device Co Ltd
Priority date: 2022-11-30
Filing date: 2022-11-30
Publication date: 2024-05-31
Also published as: WO2024114029A1

Abstract

一种操作系统的升级方法及电子设备，可以应用于计算机技术领域。其中，电子设备获取补丁包，补丁包中包括第二分区表，第二分区表用于描述基础分区、第一静态分区、第二静态分区以及动态分区的另一种分区部署。在获取到补丁包之后，电子设备第一次重启，进入恢复模式。在恢复模式下，电子设备将基础分区、第一静态分区、第二静态分区以及动态分区中的数据迁出，将存储器的分区部署由第一分区表描述的分区部署更新为第二分区表描述的分区部署，将迁出的数据回迁到第二分区表描述的分区部署中对应的各个分区中。电子设备第二次重启。从而可以实现存储器中分区部署的调节，而不会受限制于出厂时的分区部署。

Description

一种操作系统的升级方法及电子设备

技术领域

本申请涉及计算机技术领域，尤其涉及一种操作系统的升级方法及电子设备。

背景技术

空中下载技术(Over-the-Air Technology)是通过电子设备的无线网络接口实现远程升级操作系统版本的技术。与此同时，电子设备的存储器件，如只读存储器(Read-OnlyMemory，ROM)可以采用虚拟A/B(即Virtual A/B)的数据存储结构数据。在Virtual A/B的数据存储结构中，有两个独立的静态分区(如静态分区(A)和静态分区(B))和一个共用的动态分区(Super)。针对Virtual A/B的数据存储结构的电子设备，在采用OTA升级(即VirtualA/B OTA升级)操作系统时，可以在电子设备基于某一静态分区(如静态分区(A)或者静态分区(B))正常运行时进行无感知升级，并且仅需要一个共用的动态分区(Super)，可以提升数据存储空间的利用率。

然而，发明人在实施本申请实施例的过程中发现，电子设备一经销售，采用现有的Virtual A/B OTA升级方案，只能在已有的数据存储结构的分区部署限制下，完成操作系统升级，极大的限制了升级方案的适用场景。

发明内容

有鉴于此，本申请提供了一种操作系统的升级方法及电子设备，可以实现存储器中分区部署的调节，而不会受限制于出厂时的分区部署。

第一方面，本申请实施例提供了一种操作系统的升级方法，应用于包括存储器(如ROM)的电子设备，存储器包括基础分区、第一静态分区、第二静态分区以及动态分区，电子设备中包括第一分区表，第一分区表用于描述基础分区、第一静态分区、第二静态分区以及动态分区的一种分区部署。其中，电子设备获取补丁包，补丁包中包括第二分区表，第二分区表用于描述基础分区、第一静态分区、第二静态分区以及动态分区的另一种分区部署。在获取到补丁包之后，电子设备第一次重启，进入恢复模式。在恢复(recovery)模式下，电子设备将基础分区、第一静态分区、第二静态分区以及动态分区中的数据迁出，将存储器的分区部署由第一分区表描述的分区部署更新为第二分区表描述的分区部署，将迁出的数据回迁到第二分区表描述的分区部署中对应的各个分区中。电子设备第二次重启，此次重启不会进入恢复模式，而是会进入正常的操作系统模式。

综上所述，采用本申请实施例，电子设备可以在恢复模式下调节分区部署，使得存储器中的数据存储结构可以发生改变。从而可以优化存储空间，而不会受限制于出厂时的分区部署，进一步还可以适应新的存储需求。并且，在调节分区部署的过程中，电子设备先迁出数据，再调节分区部署，最后将数据回迁，可以使得调节后的各个分区中依然保存有当前版本的操作系统的数据。那么，在获取到补丁包后第二次重启后，电子设备依然可以正常运行。

在第一方面一种可能的设计方式中，在电子设备第二次重启之后，上述方法还包括：电子设备获取电子设备的操作系统的升级包，将升级包中的升级数据写入到第二分区表描述的分区部署对应的各个分区中，完成操作系统升级。

也就是说，在调节分区部署后，各个分区可以存储目标版本的操作系统中的镜像数据，并且相邻子分区的数据也不会互相覆盖。那么，电子设备在获取到目标版本的操作系统的升级包后，则可以将升级数据写入到相应的分区中，使得操作系统可以升级到目标版本。

在第一方面另一种可能的设计方式中，第一分区表中包括第一版本(即电子设备当前运行的操作系统的版本，简称当前版本)的操作系统中，基础分区、第一静态分区以及第二静态分区中多个子分区的分区信息，以及，动态分区的分区信息。第二分区表中包括第二版本(即调节分区部署后的版本，简称升级到目标版本前的中间版本)的操作系统中，基础分区、第一静态分区以及第二静态分区中多个子分区的分区信息，以及，动态分区的分区信息。其中，分区信息包括分区大小、分区名称、起始地址以及结束地址。

在第一方面另一种可能的设计方式中，上述电子设备第一次重启，进入恢复模式，包括：如果第一分区表与第二分区表不同，电子设备第一次重启，进入恢复模式。

其中，若第一分区表与第二分区表相同，则表明分区表并未发生变化。针对这种情况，则认为出现了异常，无需进入恢复模式并进一步执行调节分区部署的处理。反之，若第二分区表与第一分区表不相同，则表明第二分区表相较于第一分区表有变化。针对这种情况，则需要进入恢复模式并进一步执行调节分区部署的处理。

也就是说，仅在第二分区表相较于第一分区表有更新的情况下，才进入恢复模式，避免在没有调节分区部署的情况下错误的进入到恢复模式。

在第一方面另一种可能的设计方式中，第一分区表与第二分区表不同，包括以下至少一项：第二分区表中包括第一分区的分区信息，第一分区表中不包括第一分区的分区信息。及，第二分区表中新增了第一分区。第一分区表中包括第二分区的分区信息，第二分区表中不包括第二分区的分区信息。即，第二分区表中删除了第二分区。第一分区表中包括第三分区的分区信息，第二分区表中包括第四分区的分区信息，第三分区的分区名称和第四分区的分区名称不同，但第三分区和第四分区用于存储相同的数据。即，第一分区表中的第三分区改名为第二分区表中的第四分区。以及，第一分区表和第二分区表中都包括第五分区的分区信息，但第一分区表中、第五分区的第一分区信息，与第二分区表中、第五分区的第一分区信息不同，第一分区信息不包括分区名称。即，第五分区的分区大小、起始地址和/或结束地址发生了变化。

其中，第一分区、第二分区、第三分区、第四分区、第五分区是基础分区、第一静态分区以及第二静态分区中的一个子分区，或者，第一分区、第二分区、第三分区、第四分区、第五分区是动态分区。也就是说，分区部署的变化，可以是基础分区、第一静态分区以及第二静态分区中子分区的变化，也可以是动态分区整体的变化。

在第一方面另一种可能的设计方式中，上述将迁出的数据回迁到第二分区表描述的分区部署中对应的各个分区中，包括：电子设备将从第六分区中迁出的数据，回迁到存储器中第一目标地址区间内。其中，第六分区是第二分区表中除第一分区、第二分区和第四分区之外的分区。即，第六分区既不是新增的分区，也不是删除的分区，也不是改名称的分区。换言之，第六分区可能是前述第五分区，还可能是分区大小、起始地址以及结束地址均未发生变化的分区。同样的，第六分区是基础分区、第一静态分区以及第二静态分区中的一个子分区，或者，第六分区是动态分区，第一目标地址区间是第二分区表中第六分区的起始地址和结束地址之间的区间。

也就是说，针对分区大小、起始地址和/或结束地址发生了变化的，或者分区大小、起始地址以及结束地址均未发生变化的分区，电子设备在回迁数据时，直接按照该分区在第二分区表中的起始地址和结束地址回迁即可。

在第一方面另一种可能的设计方式中，上述将迁出的数据回迁到第二分区表描述的分区部署中对应的各个分区中，包括：电子设备将存储器中第二目标地址区间内的数据清零。其中，第二目标地址区间是第二分区表中、第一分区的起始地址和结束地址之间的区间。

也就是说，将存储器中新增分区的起始地址和结束地址之间的数据清零，这样，可以保证存储器中新增分区对应的存储空间内没有脏数据，如没有当前版本的操作系统的镜像数据。在第一方面另一种可能的设计方式中，补丁包中包括第一指示信息，第一指示信息用于指示：与第一分区表相比，第二分区表中新增了第一分区。例如，第一指示信息为add：xbl_dump，指示与第一分区表相比，第二分区表中新增了xbl_dump分区。相应的，在电子设备将存储器中第二目标地址区间内的数据清零之前，上述方法还包括：电子设备读取第一指示信息，基于第一指示信息从第二分区表中查询第一分区的起始地址和结束地址。

也就是说，电子设备通过读取第一指示信息，可以获取到新增分区的名称，然后，电子设备可以基于该新增分区的名称，至第二分区表中查询该新增分区的起始地址和结束地址，用于确定清零数据所针对的第一目标地址区间。

在第一方面另一种可能的设计方式中，上述将迁出的数据回迁到第二分区表描述的分区部署中对应的各个分区中，包括：电子设备不回迁从第二分区中迁出的数据。

也就是说，对于删除分区，电子设备不会将从删除分区迁出的数据回迁，从而避免将多余的数据回迁。

在第一方面另一种可能的设计方式中，补丁包中包括第二指示信息，第二指示信息用于指示：与第一分区表相比，第二分区表中删除了第二分区。例如，第二指示信息为delete：abl_test，指示与第一分区表相比，第二分区表中删除了abl_test分区。上述方法还包括：电子设备读取第二指示信息，基于第二指示信息确定从第二分区中迁出的数据。

也就是说，电子设备通过读取第二指示信息，可以获取到删除分区的名称，然后，电子设备可以基于该删除分区的名称，从数据迁出的位置(如用户数据分区(Userdata))处查找以该删除分区的名称命名的文件，该文件中存储的数据即为从第二分区中迁出的数据。

在第一方面另一种可能的设计方式中，上述将迁出的数据回迁到第二分区表描述的分区部署中对应的各个分区中，包括：电子设备将从第三分区中迁出的数据，回迁到存储器的第三目标地址区间内。其中，第三目标地址区间是第二分区表中第四分区的起始地址和结束地址之间的区间。

也就是说，将从改名前的分区中迁出的数据回迁到改名后的分区的起始地址和结束地址之间。从而保证修改名称后的分区中存储的系统数据，与修改名称前的分区中存储的系统数据相同。

在第一方面另一种可能的设计方式中，补丁包中包括第三指示信息，第三指示信息用于指示：第一分区表中的第三分区，更新为第二分区表中的第四分区。例如，第三指示信息为change：abl_test，abl，指示第一分区表中的abl_test分区，更新为第二分区表中的abl分区。相应的，在电子设备将从第三分区的数据，回迁到存储器的第三目标地址区间内之前，上述方法还包括：电子设备读取第三指示信息，基于第三指示信息从第二分区表中查询第四分区的起始地址和结束地址。

也就是说，电子设备通过读取第三指示信息，可以获取到修改后的分区名称，然后，电子设备可以基于修改后的分区名称，从第二分区表中查询到修改名称后的分区的起始地址和结束地址，从而可以准确的确定出第三目标地址区间。

在第一方面另一种可能的设计方式中，在获取到补丁包之后，电子设备第一重启，上述方法包括：在获取到补丁包之后，如果补丁包中包括预设名称的数据包，或者，补丁包中包括第一标签，电子设备第一次重启。其中，预设名称的数据包用于调节分区部署，第一标签用于指示调节分区部署。

也就是说，在补丁包中包括用于调节分区部署的数据包，和/或包括用于指示调节分区部署的标签的情况下，电子设备才会重启进入recovery模式。换言之，只有在确定补丁包的作用为调节分区部署后，才重启进入recovery模式，避免在补丁包用于其他不需要使用recovery模式的作用下，错误的进入到recovery模式。

在第一方面另一种可能的设计方式中，上述将基础分区、第一静态分区、第二静态分区以及动态分区中的数据迁出，包括：如果补丁包中包括预设名称的数据包，将基础分区、第一静态分区、第二静态分区以及动态分区中的数据迁出。其中，预设名称的数据包用于调节分区部署。

也就是说，在第一次重启后，电子设备也只有在确定当前为调节分区部署的场景后，才进一步执行系统数据的迁移。从而避免在非调节分区部署的场景中，错误的迁移系统数据，最终影响系统运行。

在第一方面另一种可能的设计方式中，上述方法还包括：在补丁包中包括预设名称的数据包的情况下，电子设备将预设名称的数据包存储到电子设备的预设目录下，并在电子设备中写入预设指令，预设指令中包括预设名称。其中，预设目录是recovery模式下，电子设备可以访问的目录。相应的，在获取到补丁包之后，电子设备第一次重启之后，上述方法还包括：电子设备读取预设指令，从而可以读取到预设名称。那么，如果补丁包中包括预设名称的数据包，将基础分区、第一静态分区、第二静态分区以及动态分区中的数据迁出，包括：如果预设指令中包括预设名称，电子设备将基础分区、第一静态分区、第二静态分区以及动态分区的数据迁出。

也就是说，电子设备可以通过读取预设指令，来确定当前是否为调节分区部署的场景，从而进一步确定是否需要迁移数据。

在第一方面另一种可能的设计方式中，如果补丁包中包括预设名称的数据包，将基础分区、第一静态分区、第二静态分区以及动态分区中的数据迁出，包括：补丁包中包括预设名称的数据包，电子设备设置用于指示调节分区部署的预设全局变量。电子设备检测到预设全局变量，将基础分区、第一静态分区、第二静态分区以及动态分区中的数据迁出。

也就是说，通过设置用于指示调节分区部署的预设全局变量，如ptable-change，从而可以明确指示当前为调节分区部署。后续在代码运行的过程中，可以基于该预设全局变量执行对应调节分区部署的场景的操作，无需每次在执行操作前，都进行场景的判定。

在第一方面另一种可能的设计方式中，上述预设指令中包括预设目录，第二分区表存储在预设名称的数据包中。在将存储器的分区部署由第一分区表描述的分区部署更新为第二分区表描述的分区部署之前，上述方法还包括：电子设备根据预设指令至预设目录下获取预设名称的数据包，从预设名称的数据包中获取第二分区表。

也就是说，电子设备可以通过读取预设指令确定第二分区表的存储位置，从而可以准确的获取到第二分区表，以用于调节分区部署。

在第一方面另一种可能的设计方式中，存储器中还包括用户数据分区，将基础分区、第一静态分区、第二静态分区以及动态分区中的数据迁出，包括：电子设备将基础分区、第一静态分区、第二静态分区以及动态分区中的数据迁出至用户数据分区。将迁出的数据回迁到第二分区表描述的分区部署中对应的各个分区中，包括：将用户数据分区中基础分区、第一静态分区、第二静态分区以及动态分区的数据回迁至第二分区表描述的分区部署中对应的各个分区中。

在第一方面另一种可能的设计方式中，在将迁出的数据回迁到第二分区表描述的分区部署中对应的各个分区中之后，方法还包括：删除迁出的数据。如此，可以释放存储空间。

以将数据迁移到用户数据分区(Userdata)为例，在回迁完成后，电子设备可以对用户数据分区(Userdata)格式化，从而删除用户数据分区(Userdata)中的数据，释放存储空间。

在第一方面另一种可能的设计方式中，补丁包中包括第一版本号。上述电子设备获取补丁包，包括：在电子设备加载基础分区、第一静态分区以及动态分区，运行电子设备的情况下，电子设备获取补丁包。在电子设备获取补丁包之后，上述方法还包括：电子设备将第二静态分区中的版本号刷新为第一版本号。通过刷新版本号，电子设备后续可以携带刷新后的版本号请求补丁包或者升级包，便于准确获取到更新的补丁包或者升级包。电子设备设置电子设备的启动顺序为从第二静态分区启动。那么，电子设备后续启动时，可以从第二静态分区启动。并且，从第二静态分区启动，电子设备则可以从第二静态分区中读取最新的版本号，用于请求补丁包或者升级包。相应的，电子设备第二次重启之后，上述方法还包括：电子设备加载基础分区、第二静态分区以及动态分区，运行电子设备。电子设备从第二静态分区中读取第一版本号。电子设备获取电子设备的操作系统的升级包，包括：电子设备基于第一版本号获取电子设备的操作系统的升级包。如此，可以准确的获取到最新的升级包，以用于升级操作系统。

第二方面，本申请实施例提供了一种操作系统的升级方法，应用于包括存储器(如ROM)的电子设备，存储器包括基础分区、第一静态分区、第二静态分区、第一动态分区和第二动态分区，电子设备中包括第一分区表，第一分区表用于描述基础分区、第一静态分区、第二静态分区、第一动态分区和第二动态分区的一种分区部署。其中，电子设备获取补丁包，补丁包中包括第二分区表，第二分区表用于描述基础分区、第一静态分区、第二静态分区、第一动态分区和第二动态分区的另一种分区部署。在获取到补丁包之后，电子设备第一次重启，进入恢复模式。在恢复(recovery)模式下，电子设备将基础分区、第一静态分区、第二静态分区、第一动态分区和第二动态分区中的数据迁出，将存储器的分区部署由第一分区表描述的分区部署更新为第二分区表描述的分区部署，将迁出的数据回迁到第二分区表描述的分区部署中对应的各个分区中。电子设备第二次重启，此次重启不会进入恢复模式，而是会进入正常的操作系统模式。

也就是说，操作系统的升级方法还可以应用于全量A/B的数据存储结构(静态分区和动态分区都有两套)中，实现更新分区部署。

当然，在第二方面中，电子设备也可以实现类似第一方面的可能设计方式，用于调节分区部署。唯一需要说明的是，需要将上述第一方面中的动态分区替换为第一动态分区和第二动态分区。

第三方面，本申请实施例提供了一种操作系统的升级方法，应用于包括存储器(如ROM)的电子设备，存储器包括基础分区、静态分区和动态分区，电子设备中包括第一分区表，第一分区表用于描述基础分区、静态分区和动态分区的一种分区部署。其中，电子设备获取补丁包，补丁包中包括第二分区表，第二分区表用于描述基础分区、静态分区和动态分区的另一种分区部署。在获取到补丁包之后，电子设备第一次重启，进入恢复模式。在恢复(recovery)模式下，电子设备将基础分区、静态分区和动态分区中的数据迁出，将存储器的分区部署由第一分区表描述的分区部署更新为第二分区表描述的分区部署，将迁出的数据回迁到第二分区表描述的分区部署中对应的各个分区中。电子设备第二次重启，此次重启不会进入恢复模式，而是会进入正常的操作系统模式。

也就是说，操作系统的升级方法还可以应用于仅有一套静态分区和动态分区的数据存储结构中，实现更新分区部署。

当然，在第三方面中，电子设备也可以实现类似第一方面的可能设计方式，用于调节分区部署。唯一需要说明的是，需要将上述第一方面中的第一静态分区和第二静态分区替换为静态分区。

第四方面，本申请实施例还提供一种电子设备，所述电子设备包括处理器以及存储器，所述存储器可以采用虚拟A/B(静态分区有两套)、全量A/B(静态分区和动态分区都有两套)或者单系统(静态分区和动态分区都仅有一套)的数据存储结构，所述电子设备中还包括第一分区表，所述第一分区表用于描述数据存储结构的分区部署。所述处理器用于执行所述存储器上存储的软件代码，以使得所述电子设备执行上述第一方面、第二方面、第三方面及其任一种可能的设计方式的方法。

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

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

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

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

附图说明

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

图1为本申请实施例提供的升级系统的组成图；

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

图3为本申请实施例提供的数据存储结构的示意图之二；

图4为本申请实施例提供的数据存储结构的示意图之三；

图5为本申请实施例提供的电子设备130的硬件结构图；

图6为本申请实施例提供的操作系统的升级方法的交互图之一；

图7为本申请实施例提供的操作系统的升级方法的交互图之二；

图8为本申请实施例提供的镜像文件迁移的示意图；

图9为本申请实施例提供的镜像文件回迁的示意图之一；

图10为本申请实施例提供的镜像文件回迁的示意图之二；

图11为本申请实施例提供的镜像文件回迁的示意图之三；

图12为本申请实施例提供的镜像文件回迁的示意图之四；

图13为本申请实施例提供的虚拟A/B升级流程图；

图14为本申请实施例提供的虚拟A/B升级的过程示意图；

图15为本申请实施例提供的调节分区表的交互图；

图16为本申请实施例提供的数据存储结构的示意图之四；

图17为本申请实施例提供的芯片系统的结构图。

具体实施方式

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

本申请实施例提供了一种操作系统的升级方法，可以应用于本申请提供的升级系统中，用于对电子设备中的操作系统升级。参见图1，升级系统包括拍包服务器110、OTA服务器120和电子设备(如手机)130。

拍包服务器110可用于制作升级包和/或补丁包。其中，升级包用于升级操作系统。补丁包可用于修复操作系统的漏洞。应理解，利用补丁包修复操作系统也可以视为操作系统的一种升级。

OTA服务器120用于统一管理升级包和/或补丁包，以及用于接入的电子设备(如电子设备130)的升级管理。例如，OTA服务器120中记录电子设备130中操作系统的版本为V1.1，在后续接收到拍包服务器110制作完成的V2.0的操作系统后，确定电子设备130中的操作系统不是最新的。即，确定电子设备130需要升级操作系统。

电子设备130是指安装有操作系统，并且有升级操作系统的需求的设备。在电子设备130出厂前，将操作系统烧录到电子设备130中，从而实现在电子设备130出厂前安装操作系统。此后，为了提升用户体验，可能需要对电子设备130中的操作系统进行升级。此时，可采用OTA技术来完成升级。示例性的，电子设备130可以从OTA服务器120请求升级包和/或补丁包，或者接收OTA服务器120下发的升级包和/或补丁包，并基于升级包完成操作系统升级，基于补丁包修复操作系统的漏洞。

进一步的，如图1所示，电子设备130中安装有用于操作系统升级的操作系统更新程序。示例性的，操作系统更新程序包括在线更新客户端工具(online update clientapk，ouc apk)以及升级引擎(update engine)两个功能模块。ouc apk用于获取操作系统的升级包和/或补丁包，如从OTA服务器120获取升级包和/或补丁包。update engine用于执行操作系统的升级流程。

电子设备130中的存储器，如ROM，可以采用Virtual A/B的数据存储结构来存储数据。图2所示为一种Virtual A/B的数据存储结构的示意图，如图2所示，以安卓(Android)操作系统为例，Virtual A/B的数据存储结构包含基础分区(Common)、静态分区(A)(也可以称为第一静态分区)、静态分区(B)(也可以称为第二静态分区)、动态分区(Super)以及用户数据分区(Userdata)。

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

需要说明的是，图2所示的数据存储结构仅为示例性的。实际中，数据存储结构中的基础分区(Common)中也可以进一步包括多个子分区，如cache分区。以及，数据存储结构中的静态分区(A)、静态分区(B)以及动态分区(Super)可以包括比图2所示更多或者更少的子分区。例如，静态分区(A)中还可以包括Patch_a、dtbo_a、vbmeta_a等子分区，相应的，静态分区(B)中还可以包括Patch_b、dtbo_b、vbmeta_b等子分区。又如，动态分区(Super)中还可以包括version、preload等子分区。

在电子设备130启动时，电子设备130需要从一个静态分区启动。例如，电子设备130从静态分区(A)启动，则依次加载基础分区(Common)、静态分区(A)以及动态分区(Super)。又如，电子设备130从静态分区(B)启动，则依次加载基础分区(Common)、静态分区(B)以及动态分区(Super)。

静态分区(A)、静态分区(B)和动态分区(Super)可用于存储操作系统的镜像文件的数据(下文中统一简称为镜像数据)。例如，镜像文件boot.img存储在静态分区(A)的boot_a子分区。

实际中，通常需要面对镜像文件(如.img文件)扩大的需求。例如，镜像文件中需要增加新特性，则镜像文件需要扩大，否则无法容纳新特性。应理解，在镜像文件扩大后，存储对应的镜像数据往往需要更大的存储空间。

示例性的，数据存储结构的分布部署如图3中的左边所示，例如，静态分区(A)中boot_a子分区的存储空间为空间301，静态分区(B)中boot_b子分区的存储空间为空间302。镜像文件boot.img的数据存储在空间301和空间302中。当前版本(如V1.0版本)的操作系统中，镜像文件boot.img的数据量较小。而在目标版本(如V2.0版本)的操作系统中，镜像文件boot.img中增加了新特征，导致镜像文件boot.img的数据量变大。那么，镜像文件boot.img的数据所需的存储空间也相应增加。例如，镜像文件boot.img的数据所需的boot_a子分区的存储空间由空间301变为空间303，以及，所需的boot_b子分区的存储空间由302变为空间304。

应理解，镜像数据占用更大的存储空间，则可能会覆盖掉在后的存储空间。仍以图3为例，镜像文件boot.img的数据所需的boot_a子分区的存储空间从空间301变为空间303，则可能会覆盖掉位于boot_a子分区之后的boot_b子分区的数据，如图3中的竖线阴影区域所示。又如，镜像文件boot.img的数据所需的boot_b子分区的存储空间从空间302变为空间304，则可能会覆盖掉位于boot_b子分区之后的vendor_boot_a子分区的数据，如图3中的斜线阴影区域所示。

然而，现有的Virtual A/B OTA升级方案主要关注如何将升级包中的升级数据(如镜像数据)写入静态分区和动态分区(Super)，而无法解决图3所示镜像文件扩大后，会覆盖掉在后的存储空间中的数据的问题。

也就是说，现有的Virtual A/B OTA升级方案只能在现有的分区部署的限制下，如图3中的左边所示的分区部署的限制下，完成操作系统升级。而通常情况下，当面对图3所示的问题时，只能通过发布新产品来满足需求。例如，发布新手机，并在新手机中划分合适的分区部署。

基于此，本申请实施例提供了一种操作系统的升级方法，电子设备130可以在恢复(rcovery)模式下调节分区部署，使调节后的分区部署满足目标版本的操作系统对存储空间的新需求。其中，调节分区部署包括增加分区、删除分区、修改分区的名称以及调节分区的分区大小和/或地址(包括起始地址和/或结束地址)中的一项或多项操作。

以调节分区的分区大小为例，boot_a子分区和boot_b子分区用于存储操作系统中镜像文件boot.img的数据。参见图4，在调节前，boot_a子分区和boot_b子分区中存储当前版本(如V1.0版本)的操作系统中镜像文件boot.img的数据。并且，boot_a子分区的起始地址为A1，结束地址为B1，即boot_a子分区的分区大小为B1-A1；boot_b子分区的起始地址为A2，结束地址为B2，即boot_b子分区的分区大小为B2-A2；以及，vendor_boot_a子分区的起始地址为A3，结束地址为B3，即vendor_boot_a子分区的分区大小为B3-A3……。

而目标版本(如V2.0版本)的操作系统中，在镜像文件boot.img中增加了新特性，因此镜像文件boot.img的数据需要更大的存储空间，如需要增大△的存储空间。那么，可以调节分区部署，继续参见图4，在调节后，boot_a子分区的起始地址仍为A1，结束地址调节为B1+△，则boot_a子分区的分区大小为B1-A1+△。即，boot_a子分区的分区大小增大△，从而可以容纳增加新特性后的镜像数据。boot_b子分区的起始地址调节为A2+△，避免boot_a子分区和boot_b子分区重叠；boot_b子分区的结束地址调节为B2+2*△，则boot_a子分区的分区大小为(B2+2*△)-(A2+△)＝B2-A2+△。即，boot_b子分区的分区大小增大△，从而也可以容纳增加新特性后的镜像数据。以及，vendor_boot_a子分区的起始地址调节为A3+2*△，避免boot_b子分区和vendor_boot_a子分区重叠；vendor_boot_a子分区的结束地址调节为B3+2*△，则vendor_boot_a子分区的分区大小依然保持(B3+2*△)-(A3+2*△)＝B3-A3。即，vendor_boot_a子分区的分区大小保持不变，从而可以保证容纳vendor_boot_a子分区中当前存储的镜像文件。

在完成分区部署调节后，电子设备130可以退出rcovery模式，并在正常运行的情况下，基于升级包将升级数据存储到调节分区部署后的各个子分区中，完成操作系统升级。其中，升级包用于将操作系统升级到目标版本的操作系统。如此，各个分区可以存储目标版本的操作系统中的镜像数据，并且相邻子分区的数据也不会互相覆盖。

继续参见图4，在调节后，可以将V2.0版本的操作系统中的镜像文件boot.img(即扩大的镜像文件boot.img)的数据存储到boot_a子分区和boot_b子分区。并且，由于boot_a子分区、boot_b子分区以及vendor_boot_a子分区中相邻两者的存储空间都不重叠，因此，不会出现数据覆盖的问题。

当然，需要说明的是，在一些场景中，调节分区部署仅仅是为了优化存储空间。例如，缩小分区的分区大小，从而释放闲置的存储空间给用户数据分区(Userdata)。在这些场景中，并不是为了满足目标版本(如V2.0版本)的操作系统对存储空间的需求，才调节分区部署的。因此，针对这些场景，本申请实施例提供的操作系统的升级方法中，可以仅包括调节分区部署的过程，而不包括基于升级包将操作系统升级到目标版本的过程。下文中，主要以调节分区部署后，紧接着就基于升级包将操作系统升级到目标版本为例来说明。

示例性的，本申请实施例的电子设备130包括但不限于可以安装操作系统的手机、耳机、平板电脑、智能冰箱、智能音箱等设备。或者，电子设备130也可以是指电子设备130内部可以安装操作系统的控制板。并且，本申请实施例中，操作系统包括但不限于iOS、Android、Harmony、Windows、Linux或者其它操作系统。

参见图5，为本申请实施例提供的一种电子设备130的硬件结构图。如图5所示，以电子设备130是手机为例，电子设备可以包括处理器310，外部存储器接口320，内部存储器321，通用串行总线(universal serial bus，USB)接口330，充电管理模块340，电源管理模块341，电池342，天线1，天线2，移动通信模块350，无线通信模块360，音频模块370，扬声器370A，受话器370B，麦克风370C，耳机接口370D，传感器模块380、按键390，马达391，指示器392，摄像头393，显示屏394，以及用户标识模块(subscriber identification module，SIM)卡接口395等。

可以理解的是，本实施例示意的结构并不构成对电子设备的具体限定。在另一些实施例中，电子设备可以包括比图示更多或更少的部件，或者组合某些部件，或者拆分某些部件，或者不同的部件布置。图示的部件可以以硬件，软件或软件和硬件的组合实现。

处理器310可以包括一个或多个处理单元，例如：处理器310可以包括应用处理器(application processor，AP)，调制解调处理器，图形处理器(graphics processingunit，GPU)，图像信号处理器(image signal processor，ISP)，控制器，存储器，视频编解码器，数字信号处理器(digital signal processor，DSP)，基带处理器，和/或神经网络处理器(neural-network processing unit，NPU)等。其中，不同的处理单元可以是独立的器件，也可以集成在一个或多个处理器中。

可以理解的是，本实施例示意的各模块间的接口连接关系，只是示意性说明，并不构成对电子设备的结构限定。在另一些实施例中，电子设备也可以采用上述实施例中不同的接口连接方式，或多种接口连接方式的组合。

充电管理模块340用于从充电器接收充电输入。其中，充电器可以是无线充电器，也可以是有线充电器。在一些有线充电的实施例中，充电管理模块340可以通过USB接口330接收有线充电器的充电输入。在一些无线充电的实施例中，充电管理模块340可以通过电子设备的无线充电线圈接收无线充电输入。充电管理模块340为电池342充电的同时，还可以通过电源管理模块341为电子设备供电。

电源管理模块341用于连接电池342，充电管理模块340与处理器310。电源管理模块341接收电池342和/或充电管理模块340的输入，为处理器310，内部存储器321，外部存储器，显示屏394，摄像头393，和无线通信模块360等供电。电源管理模块341还可以用于监测电池容量，电池循环次数，电池健康状态(漏电，阻抗)等参数。在其他一些实施例中，电源管理模块341也可以设置于处理器310中。在另一些实施例中，电源管理模块341和充电管理模块340也可以设置于同一个器件中。

电子设备的无线通信功能可以通过天线1，天线2，移动通信模块350，无线通信模块360，调制解调处理器以及基带处理器等实现。

无线通信模块360可以提供应用在电子设备上的包括无线局域网(wirelesslocal area networks，WLAN)(如无线保真(wireless fidelity，Wi-Fi)网络)，蓝牙(bluetooth，BT)，全球导航卫星系统(global navigation satellite system，GNSS)，调频(frequency modulation，FM)，近距离无线通信技术(near field communication，NFC)，红外技术(infrared，IR)等无线通信的解决方案。无线通信模块360可以是集成至少一个通信处理模块的一个或多个器件。无线通信模块360经由天线2接收电磁波，将电磁波信号调频以及滤波处理，将处理后的信号发送到处理器310。无线通信模块360还可以从处理器310接收待发送的信号，对其进行调频，放大，经天线2转为电磁波辐射出去。

电子设备通过GPU，显示屏394，以及应用处理器等实现显示功能。GPU为图像处理的微处理器，连接显示屏394和应用处理器。GPU用于执行数学和几何计算，用于图形渲染。处理器310可包括一个或多个GPU，其执行程序指令以生成或改变显示信息。

电子设备可以通过ISP，摄像头393，视频编解码器，GPU，显示屏394以及应用处理器等实现拍摄功能。ISP用于处理摄像头393反馈的数据。摄像头393用于捕获静态图像或视频。物体通过镜头生成光学图像投射到感光元件。在一些实施例中，电子设备可以包括1个或N个摄像头393，N为大于1的正整数。

外部存储器接口320可以用于连接外部存储卡，例如Micro SD卡，实现扩展电子设备的存储能力。外部存储卡通过外部存储器接口320与处理器310通信，实现数据存储功能。例如将音乐，视频等文件保存在外部存储卡中。

内部存储器321可以用于存储计算机可执行程序代码，所述可执行程序代码包括指令。处理器310通过运行存储在内部存储器321的指令，从而执行电子设备的各种功能应用以及数据处理。例如，处理器310可以通过执行存储在内部存储器321中的指令，执行操作系统升级的操作。内部存储器321可以包括存储程序区和存储数据区。其中，存储程序区可存储操作系统，至少一个功能所需的应用程序(比如声音播放功能，图像播放功能等)等。存储数据区可存储电子设备使用过程中所创建的数据(比如音频数据，电话本等)等。此外，内部存储器321可以包括高速随机存取存储器，还可以包括非易失性存储器，例如至少一个磁盘存储器件，闪存器件，通用闪存存储器(universal flash storage，UFS)等。应理解，内部存储器321可以设置于处理器310内部，或者内部存储器321可以独立设置于处理器310外。

在具体实现中，内部存储器321可以包括ROM和随机存取存储器(Random AccessMemory，RAM)。在实际应用中，RAM又可以称作“主存”，它可随时读写，而且速度很快，通常作为操作系统或其他正在运行中的程序的临时数据存储媒介，当电源关闭时，RAM不能保留数据，即RAM中通常存储的是电子设备运行时的临时数据。ROM又可以称作“非易失性存储器”，其所存数据一般是装入整机前事先写好的，例如操作系统的镜像数据，以及用户使用电子设备时产生的用户数据，整机工作过程中只能读出，而不能像RAM那样能够快速地、方便地加以改写，因此ROM所存数据稳定，断电后所存数据也不会改变。

本申请中，ROM可以采用类似图1所示的Virtual A/B的数据存储结构。在电子设备中，可以使用总分区表(Ptable，本文中简称分区表)来描述ROM中Virtual A/B的数据存储结构的分区部署。示例性的，分区表保存通用闪存(Universal Flash Storage，UFS)中，在启动电子设备后，可以从UFS中查询分区表，从而获得ROM中数据存储结构的分区部署。分区表中包括基础分区(Common)、静态分区(A)、静态分区(B)和动态分区(Super)和用户数据分区(Userdata)的起始地址和结束地址。示例性的，分区表中的部分数据如下表1所示：

表1

以表1中的x-loader子分区为例，上表1可以表示：静态分区(A)中的x-loader_a子分区的分区大小为256KB，其在存储空间中的起始地址为0x00000100，结束地址为0x00000X₁X₂X₃；静态分区(B)中的x-loader_b子分区的分区大小为256KB，其在存储空间中的起始地址为0x00000 X₄X₅X₆，结束地址为0x00000X₇X₈X₉。

需要说明的是，分区表可以描述分区部署，因此，在本申请中，可以通过调节分区表来实现调节分区部署。例如，通过修改分区表中某个子分区的起始地址和结束地址，来调节该子分区在存储空间中的分区部署。简言之，调分区表就是在调分区部署。

应注意，对于基础分区、静态分区(A)和静态分区(B)，在分区表中描述了各个子分区的分区名称、分区大小、起始地址及结束地址。但是，关于动态分区(Super)，在分区表中只是描述了动态分区(Super)整体的分区大小、起始地址和结束地址。例如，上表1中，动态分区(Super)整体的分区大小为8GB，起始地址为0x00000Q₁Q₂Q₃，结束地址为0x0000Q₄Q₅Q₆Q₇。而动态分区(Super)中各个子分区(如system子分区)的地址信息，则存储在动态分区(Super)头部的元数据(/supermetadata)中。因此，关于动态分区(Super)，本申请中通过调节分区表实现调分区部署，只能针对动态分区(Super)整体来调节。例如，改变动态分区(Super)整体的起始地址和结束地址。

并且，在动态分区(Super)头部的元数据(/supermetadata)中，记录的动态分区(Super)中各个子分区(如system子分区)的地址信息，是采用偏移量表示的。即，地址信息表示的是动态分区(Super)中各个子分区(如system子分区)在动态分区(Super)中的相对位置。因此，在调节动态分区(Super)整体后，动态分区(Super)中各个子分区在ROM上的位置自然可以随之改变。

也就是说，本申请中，调节分区表，包括对基础分区(Common)、静态分区(A)以及静态分区(B)中子分区的调节，还可以包括对动态分区(Super)整体的调节。从而实现调节分区部署。下文中，主要以对静态分区(A)和静态分区(B)中子分区的调节为例说明本申请方案。

为了便于说明，可以将分区名称、分区大小、起始地址及结束地址统称为分区信息。

电子设备可以通过音频模块370，扬声器370A，受话器370B，麦克风370C，耳机接口370D，以及应用处理器等实现音频功能。例如音乐播放，录音等。

按键390包括开机键，音量键等。按键390可以是机械按键。也可以是触摸式按键。电子设备可以接收按键输入，产生与电子设备的用户设置以及功能控制有关的键信号输入。马达391可以产生振动提示。马达391可以用于来电振动提示，也可以用于触摸振动反馈。指示器392可以是指示灯，可以用于指示充电状态，电量变化，也可以用于指示消息，未接来电，通知等。SIM卡接口395用于连接SIM卡。SIM卡可以通过插入SIM卡接口395，或从SIM卡接口395拔出，实现和电子设备的接触和分离。电子设备可以支持1个或N个SIM卡接口，N为大于1的正整数。

下面将进一步结合附图，并以图1所示的升级系统和图5所示的电子设备为例，描述本申请实施例提供的方案。

图6为本申请实施例提供的一种操作系统的升级方法的流程图，如图6所示，以电子设备130当前从静态分区(A)启动为例，即：电子设备130在由静态分区(A)和动态分区(Super)中的镜像文件构成的系统(可称为A系统)下运行为例，操作系统的升级方法包括：

S601、拍包服务器110制作补丁包，补丁包中包括版本号和调表包，调表包中包括分区表。

其中，版本号为中间版本的版本号(也可以称为第一版本号)，中间版本是指利用补丁包对当前版本的操作系统修复后的版本。例如，当前操作系统的版本(可称为当前版本，也可以称为第一版本)为V1.0版本，利用补丁包对当前操作系统修复后的版本为V1.1版本，则中间版本为V1.1版本。

本申请中，补丁包中包括版本号和调表包，用于调节分区表。其中，版本号用于指示中间版本。调表包用于作为调节分区部署的依据。调表包中包括分区表(也可以称为第二分区表)，即包括如前文表1所示的分区表。该分区表可以描述中间版本(也可以称为第二版本)中，Virtual A/B的数据存储结构的分区部署，即基础分区(Common)、静态分区(A)、静态分区(B)、动态分区(Super)以及用户数据分区(Userdata)的分区部署。即，目标版本的操作系统对存储空间的需求。

示例性的，补丁包的数据结构如下所示：

ptablechange.tag；

META-INF；

payload.bin；

payload_properties.txt；

SOFTWARE_VER.mbn；

update_base_ptable_change.zip；

VERSION.mbn。

其中，ptablechange.tag是调分区表的标签，指示该补丁包可用于调节分区部署。payload.bin包括基于补丁包修复操作系统所涉及的子分区的分区信息。update_base_ptable_change.zip为调表包。

示例性的，调表包(即update_base_ptable_change.zip)的数据结构如下所示：

Ptable；

META-INF；

OTA_update.tag；

skipauth_pkg.tag；

vendor_country.mbn；

change_detail.mbn。

其中，Ptable为分区表，其结构如前文表1所示。change_detail.mbn是分区表更改的文件，用于描述中间版本的分区表相较于当前版本的分区表(也可以称为第一分区表)的分区变化，此变化包括但不限于增加分区、删除分区以及修改分区名称中的一项或多项。

例如，change_detail.mbn中包括add：xbl_dump，用于描述中间版本的分区表相较于当前版本的分区表增加了xbl_dump子分区。

为了便于说明，可以将新增分区(如xbl_dump子分区)称为第一分区。即，调表包中的分区表中包括该第一分区的分区信息，但是当前版本的分区表中不包括第一分区的分区信息。并且，可以将change_detail.mbn中指示新增分区的信息(如add：xbl_dump)称为第一指示信息。

又例如，change_detail.mbn中包括delete：abl_test，用于描述中间版本的分区表相较于当前版本的分区表删除了abl_test子分区。

同样，为了方便说明，可以将删除分区(如abl_test子分区)称为第二分区。即，当前版本的分区表中包括该第二分区的分区信息，但是调表包中的分区表中不包括第二分区的分区信息。并且，可以将change_detail.mbn中指示删除分区的信息(如delete：abl_test)称为第二指示信息。

再例如，change_detail.mbn中包括change：abl_reserve，abl，用于描述将当前版本的分区表中子分区的名称abl_reserve修改为中间版本的分区表中子分区的名称abl。

同样，为了方便说明，可以将当前版本的分区表中改名称前的分区(如abl_reserve子分区)称为第三分区，将调表包中的分区表中改名称前的分区(如abl子分区)称为第四分区。即，当前版本的分区表中的第三分区，改名为调表包中的分区表中的第四分区。通常情况下，改变分区名称，不影响分区的功能，因此，第四分区中的作用通常与第三分区的作用相同。示例性的，都是用来存储相同的数据，如存储镜像文件abl_test.img的数据。并且，可以将change_detail.mbn中指示修改名称的信息(如change：abl_reserve，abl)称为第三指示信息。

拍包服务器110可以基于目标版本的操作系统中各个镜像文件的数据大小确定中间版本的分区表，从而制作得到补丁包。

仍以图4为例，在目标版本的操作系统中，镜像文件boot.img的数据增加了△。那么，在中间版本的分区表中，boot_a子分区和boot_b子分区的分区大小都应该增加△。因此，可以确定boot_a子分区的结束地址和boot_b子分区的起始地址均后移△。即，中间版本的分区表中boot_a子分区的结束地址为B1+△，boot_b子分区的起始地址为A2+△。还可以确定boot_b子分区的结束地址以及之后各个子分区的起始地址和结束地址都后移2*△。从而可以得到中间版本的分区表。

S602、拍包服务器110向OTA服务器120上传补丁包。

拍包服务器110在制作出补丁包之后，可以向OTA服务器120发送补丁包，以便OTA服务器120统一管理。

S603、电子设备130从OTA服务器120下载补丁包。

OTA服务器120可以主动向电子设备130推送补丁包的下载地址，供电子设备130下载。或者，电子设备130可以向OTA服务器120发送搜包请求，OTA服务器120基于搜包请求向电子设备130发送补丁包的下载地址。电子设备130在获取到下载地址后，则可以下载得到补丁包。

S604、电子设备130基于补丁包刷新版本号。

本申请中，电子设备130在获取到补丁包后，可以将电子设备130中操作系统的版本号刷新为补丁包中携带的版本号，即中间版本的版本号。例如，从V1.0刷新为V1.1。

示例性的，补丁包中包括payload.bin，payload.bin中包括基于补丁包修复操作系统所涉及的子分区的分区信息。补丁包的主要作用就是打补丁，则涉及的分区自然包括静态分区中的补丁(Patch)子分区。因此，从补丁包的payload.bin中可以获取到Patch子分区的分区信息，如分区名称“Patch”。电子设备130可以将中间版本的版本号写入Patch子分区，实现版本号刷新。

应理解，电子设备130当前从静态分区(A)启动，则需要将中间版本的版本号写入静态分区(B)的Patch_b子分区。从而可以避免对正在运行的A系统的影响。

通过刷新版本号，电子设备130后续可以携带刷新后的版本号向OTA服务120请求补丁包，用于对电子设备130中的操作系统做进一步的修复。或者，电子设备130后续可以携带刷新后的版本号向OTA服务120请求升级包，用于对电子设备130中的操作系统升级。示例性的，刷新后的版本号为V1.1。那么，电子设备130在基于补丁包完成操作系统的修复之后，电子设备130可以携带V1.1向OTA服务器120发送搜包请求。OTA服务器120将搜包请求中携带的V1.1，与OTA服务器120中最新的版本号(如V2.0)比较，发现有比V1.1更新的版本。该情况下，OTA服务器120可以向电子设备130提供V2.0版本的操作系统的升级包的下载地址，以供电子设备130下载更新。

在一些实施例中，参见图7，在S604之前，还可以包括S701。

S701、电子设备130校验补丁包。

示例性地，补丁包中包括补丁包的数字签名(META-INF)。电子设备130可以校验补丁包的META-INF是否合法，从而确认补丁包是否合法。具体实现细节，可参考相关现有技术，在此不再赘述。

如此，可以在确定补丁包合法之后，进一步基于补丁包实现修复操作系统，如在S701确定补丁包合法之后，才执行S604及其后续步骤。从而可以避免针对非法的补丁包完成不当的处理。

S605、电子设备130将启动顺序由从静态分区(A)启动变更为从静态分区(B)启动。

电子设备130当前从静态分区(A)启动，即：电子设备130在由静态分区(A)和动态分区(Super)中的镜像数据构成的系统(即A系统)下运行。同理，电子设备130从静态分区(B)启动，即：电子设备130在由静态分区(B)和动态分区(Super)中的镜像数据构成的系统(可称为B系统)下运行。

电子设备130将启动顺序由从静态分区(A)启动变更为从静态分区(B)启动，可以使电子设备130下次启动时，从静态分区(B)启动，即在操作系统B下运行。并且，从静态分区(B)启动，电子设备130则可以从静态分区(B)的Patch_b子分区中读取最新的版本号，并用于请求升级包。

以采用主引导记录(Master Boot Record，MBR)格式的通用闪存(UniversalFlash Storage，UFS)为例。在UFS的MBR(主引导扇区，UFS的第一个扇区，即C/H/S地址的0柱面0磁头1扇区)中，保存有设备启动顺序描述。例如，启动顺序标志为A，指示从静态分区(A)启动；启动顺序标志为B，指示从静态分区(B)启动。设备启动后首先从UFS的MBR中读取设备启动顺序，从而确定需要从静态分区(A)还是静态分区(B)启动。因此，电子设备130可以将MBR中启动顺序标志从A改写为B。

需要说明的是，将启动顺序由从静态分区(A)启动变更为从静态分区(B)启动，只是指示电子设备130下次从静态分区(B)启动。即，下次启动后在B系统下运动。而不会立即生效。也就是说，在将启动顺序由从静态分区(A)启动变更为从静态分区(B)启动后，电子设备130不会立即从A系统切换为B系统。

应注意，上述S604和S605主要是为了电子设备130可以读取到中间版本的版本号，从而便于后续请求升级包。当然，基于前文说明可知，在一些场景中，补丁包可能仅用于优化分布部署，此后并无需升级操作系统到目标版本，那么，则无需请求升级包。因此，在这些场景中，也可以省去S604和S605的步骤。

S606、电子设备130重启并进入recovery模式。

由于已经将启动顺序由从静态分区(A)启动变更为从静态分区(B)启动，则电子设备130重启时，会从静态分区(B)启动，从而可以在B系统下运行。此次重启也可以称为获取到补丁包之后的第一次重启。

本申请中，电子设备130需要在recovery模式下完成调分区表的操作。因此，此次重启还需要触发进入recovery模式。示例性的，以操作系统是Android为例，电子设备130可以使用如下重启指令控制电子设备130重启并进入recovery模式：

property_set(ANDROID_RB_PROPERTY，“reboot，recovery”)。

电子设备130在进入recovery模式后，则可以执行调节分区表的处理。如下S607-S609所示。

实际中，补丁包可用于修复电子设备130内部的数据或操作系统的漏洞，而不仅仅是用于调节分区表。基于此，在一些实施例中，参见图7，在S606之前，电子设备130首先需要确定补丁包用于调节分区表，即还包括S702a：

S702a、电子设备130确定补丁包用于调分区表。

用于调分区表的补丁包中，通常包括用于指示调节分区表的标签(也可以称为第一标签)，如标签ptablechange.tag。以及，用于调分区表的补丁包中，通常还包括名称为预设的调表包名称的小包(也可以称为预设名称的数据包)，如预设的调表包名称为update_base_ptable_change.zip。其中，预设的调表包名称用于指示调表包。

基于此，电子设备130可以在补丁包中查找用于指示调节分区表的标签和名称为预设的调表包名称的小包。若查找到用于指示调节分区表的标签和名称为预设的调表包名称的小包，可以确定补丁包用于调分区表。反之，若未查找到用于指示调节分区表的标签或者名称为预设的调表包名称的小包，可以确定补丁包不用于调分区表。

当然，电子设备130也可以仅查找用于指示调节分区表的标签，若查找到用于指示调节分区表的标签，则确定补丁包用于调分区表。或者，电子设备130也可以仅查找名称为预设的调表包名称的小包，若查找到名称为预设的调表包名称的小包，则确定补丁包用于调分区表。本申请实施例对此不作具体限定。

采用本实施例，在确定补丁包的作用为调分区表后，才重启进入recovery模式。避免在补丁包用于其他不需要使用recovery模式的作用时，错误的进入到recovery模式。

在一些场景中，电子设备130虽然接收到用于调分区表的补丁包，但是调表包中的分区表可能有误，例如，并不是中间版本的分区表。该情况下，重启进入recovery并进一步执行调分区表的处理显然是不合理的。

基于此，在一些实施例中，参见图7，在S606之前，还包括S702b-S703。

S702b、电子设备130将调表包中的分区表与当前版本的分区表比较。

其中，当前版本的分区表是指电子设备130当前运行的操作系统的分区表。示例性的，电子设备130可从UFS中获取当前版本的分区表。

电子设备130在比较调表包中的分区表与当前版本的分区表时，可以比较两者包括的分区是否相同，各个分区的大小以及起始地址和结束地址是否相同。上述任一项有不同，则确定调表包中的分区表与当前版本的分区表不同。若所有都相同，则确定调表包中的分区表与当前版本的分区表相同。

若调表包中的分区表与当前版本的分区表相同，则表明调表包中的分区表就是当前版本的分区表，而并未发生变化。针对这种情况，则认为出现了异常，无需进入recovery并进一步执行调分区表的处理，即无需执行S606及其后续步骤。

反之，若调表包中的分区表与当前版本的分区表不相同，则表明调表包中的分区表相较于当前版本的分区表有变化。针对这种情况，则需要进入recovery模式并进一步执行调分区表的处理。

相应的，继续参见图7，S606具体为S606a：

S606a、若调表包中的分区表与当前版本的分区表不相同，电子设备130重启并进入recovery模式。

采用本实施例，可以仅在调表包中的分区表相较于当前版本的分区表有更新的情况下，才进入recovery模式。从而可以在有调分区表的需求的情况下才进入recovery模式。

另外，在本实施例中，S605的执行时机并不以图7为限。实际实施，只要在下次启动前，将启动顺序由从静态分区(A)启动变更为从静态分区(B)启动。即，可以在S604至下一次启动电子设备130(如S606a)前之间的任意时刻执行S605。如此，可以确保电子设备130下一次从静态分区(B)启动。

在一些实施例中，参见图7，在进入recovery模式后，即S606之后，还可以包括S703。

S703、电子设备130校验调表包。

示例性地，调表包中包括调表包的数字签名(META-INF)。电子设备130可以校验调表包的META-INF是否合法，从而确认调表包是否合法。具体实现细节，可参考相关现有技术，在此不再赘述。

如此，可以在确定调表包合法之后，进一步基于调表包实现调分区表的相关处理，从而可以避免针对非法的调表包完成不当的处理。

S607、电子设备130将基础分区(Common)、静态分区(A)、静态分区(B)和动态分区(Super)中的系统数据迁移。

如此，电子设备130可以在基础分区(Common)、静态分区(A)、静态分区(B)和动态分区(Super)之外的区域保存系统数据(如镜像数据)，便于后续回迁。例如，可以将系统数据复制一份到用户数据分区(Userdata)。这样，既可以将系统数据迁出，也可以不影响recovery模式的运行。

示例性的，参见图8，以静态分区(A)和静态分区(B)为例。在迁移前，镜像数据11存储在静态分区(A)的bootloader_a子分区中，镜像数据12存储在静态分区(B)的bootloader_b子分区中。镜像数据21存储在静态分区(A)的boot_a子分区中，镜像数据22存储在静态分区(B)的boot_b子分区中。继续参见图8，在迁移后，镜像数据11、镜像数据12、镜像数据21以及镜像数据22都复制一份存储在用户数据分区(Userdata)中。例如，存在用户数据分区(Userdata)的尾部。

并且，为了便于后续回迁数据的过程中，区分不同系统数据存储的分区，可以在迁移系统数据时，可以将系统数据迁移到以子分区的名称命名的文件中。对于静态分区，则可以后缀-a和_b区分。

示例性的，继续参见图8，将bootloader_a中的镜像数据11迁移到用户数据分区(Userdata)中以bootloader_a.img命名的文件中，将bootloader_b中的数镜像据12迁移到用户数据分区(Userdata)中以bootloader_b.img命名的文件中，将boot_a中的镜像数据21迁移到用户数据分区(Userdata)中以boot_a.img命名的文件中，将boot_b中的镜像数据22迁移到用户数据分区(Userdata)中以boot_b.img命名的文件中。

当然，在另一些实施例中，电子设备130也可以其他方式区分不同系统数据的存储分区。示例性的，电子设备130可以将系统数据以及存储其的分区的名称关联迁移到用户数据分区(Userdata)。例如，将bootloader_a与镜像数据11关联存储到用户数据分区(Userdata)中。

实际中，在recovery模式下，可以完成对电子设备130内部的数据或操作系统的多种处理。例如，修改电子设备130的制式。又如，本申请中，使用recovery模式调分区表。

基于此，在一些实施例中，在进入recovery模式后，电子设备130首先需要确定此次进入recovery模式的目的，从而便于执行相应的处理达到目的。那么，在本申请使用recovery模式调分区表的场景中，则主要需要确定是否为调分区表的目的。具体的，参见图7，在进入recovery模式后，还可以包括S704：

S704、电子设备130确定当前是否为调分区表的场景。

补丁包中包括的小包不同，则进入recovery模式后所能实现的目的不同。示例性的，补丁包中的小包为改制包，则在进入recovery模式后，可以基于改制包实现改制的目的，如将演示制式改为商用制式。又示例性的，补丁包中的小包为调表包，则在进入recovery模式后，可以基于调表包实现调分区表的目的。

基于此，在一种具体的实现方式中，电子设备130可以基于补丁包中小包(如改制包、调表包)的名称确定当前是否为调分区表的场景。

若补丁包中小包的名称是预设的调表包名称(也可以称为预设名称)，则确定当前是调分区表的场景。示例性的，预设的调表包名称update_base_ptable_change.zip，补丁包中小包的名称也是update_base_ptable_change.zip，补丁包中小包的名称与预设的调表包名称相同，则可以确定当前是调分区表的场景。

若补丁包中小包的名称不是预设的调表包名称，则确定当前不是调分区表的场景。示例性的，预设的调表包名称update_base_ptable_change.zip，补丁包中小包的名称是update_base_demochange.zip，补丁包中小包的名称与预设的调表包名称不相同，则可以确定当前不是调分区表的场景。

相应的，继续参见图7，在本实施例中，S607具体为S607a：

S607a、若确定当前为调分区表的场景，电子设备130将基础分区(Common)、静态分区(A)、静态分区(B)和动态分区(Super)中的系统数据迁移。

也就是说，在本实施例中，在确定当前为调分区表的场景后，才进一步执行系统数据的迁移。从而避免在非调分区表的场景中，错误的迁移系统数据，最终影响系统运行。

S608、电子设备130利用调表包中的分区表更新电子设备130中当前版本的分区表，得到更新后的分区表。

即，将ROM的分区部署由当前版本的分区表描述的分区部署，更新为调表包中的分区表描述的分区部署。

示例性的，电子设备130中当前版本的分区表如前文表1所示，而调表包中的分区表如下表2所示：

表2

很显然，与表1相比，表2中boot_a子分区和boot_b子分区的分区大小都由32MB扩大到64MB，并且，boot_a子分区及其之后的分区的地址(包括起始地址和/或结束地址)也相应发生了变化。

在一种具体的实现方式中，电子设备130可以修改当前版本的分区表，使其与调表包中的分区表达到一致，则得到更新后的分区表。

在另一种具体的实现方式中，电子设备130也可以使用调表包中的分区表，替换当前版本的分区表，得到更新后的分区表。

在得到更新后的分区表后，电子设备130可以存储更新后的分区表，例如，将更新后的分区表存储到UFS中，以供后续使用。

S609、电子设备130将系统数据回迁到更新后的分区表描述的各个分区中。

如此，在电子设备130升级至目标版本前，各个分区中依然可以存储当前版本的操作系统的镜像数据，从而保证电子设备130可以正常运行。

与当前版本的分区表相比，更新后的分区表中包括如下一种或多种变化类型：第一种，增加分区；第二种，删除分区；第三种，修改名称；以及第四种，除上述第一种-第三种之外的情况。对应上述四种情况，回迁系统数据的具体实现不同。

示例性的，调表包中包括change_detail.mbn文件。change_detail.mbn用于描述中间版本的分区表相较于当前版本的分区表的分区变化。因此，电子设备130可以通过解析change_detail.mbn，确定与当前版本的分区表相比，更新后的分区表包括的变化类型。其中，关于change_detail.mbn，具体可参见前文中的相关说明，此处不再赘述。

下面将分别说明上述四种情况，及其对应的回迁方式。

第一种，增加分区。即，增加第一分区。

在回迁系统数据的过程中，针对新增分区，电子设备130可以从更新后的分区表中查询新增子分区及其对应的分区信息，如分区大小、起始地址以及结束地址等。然后，电子设备130将ROM中新增分区的起始地址和结束地址之间(也可以称为第二目标地址区间)的数据清零。如此，可以保证ROM中新增分区对应的存储空间内没有脏数据，如没有当前版本的操作系统的镜像数据。

示例性的，change_detail.mbn中包括add：xbl_dump，指示增加了xbl_dump子分区。例如，当前版本的分区表描述的分区如图9中左边所示，更新后的分区表描述的分区如图9中右边所示。很显然，与图9左边所示的分区相比，图9右边所示的分区增加了xbl_dump_a和xbl_dump_b两个子分区。

针对图9所示的情况，在回迁系统数据的过程中，电子设备130可以在更新后的分区表中查询change_detail.mbn中指示的新增分区，即xbl_dump子分区，查询到xbl_dump_a和xbl_dump_b两个子分区，以及查询到这两个子分区的起始地址和结束地址。如图9中右边所示，查询到xbl_dump_a子分区的起始地址是A1A1，结束地址是B1B1，xbl_dump_b子分区的起始地址是A2A2，结束地址是B2B2为例，电子设备130可以对ROM中地址A1A1-B2B2之间的数据清零。例如，如图9中右边所示，当前版本的分区表描述的分区中，ROM中地址A1A1-B2B2对应的是boot_a子分区和boot_b子分区的存储空间，分别存储的为镜像数据21和镜像数据22。因此，通过数据清零，可以将当前版本中存储在ROM中地址A1A1-B2B2之间的镜像数据21和镜像数据22删除。

第二种，删除分区。即，删除第二分区。

在回迁系统数据的过程中，针对删除分区，电子设备130无需回迁存储在删除分区中的系统数据。从而避免将多余的系统数据回迁。

示例性的，change_detail.mbn中包括delete：abl_test，表示删除了abl_test子分区。例如，当前版本的分区表描述的分区如图10中左边所示，更新后的分区表描述的分区如图10中右边所示。很显然，与图10左边所示的分区相比，图10右边所示的分区删除了abl_test_a和abl_test_b两个子分区。

针对图10所示的情况，在回迁系统数据的过程中，电子设备130可以查询change_detail.mbn中记录的删除分区，即abl_test子分区，不将用户数据分区(Userdata)中abl_test_a_img文件中的镜像数据31回迁，以及不将用户数据分区(Userdata)abl_test_b_img文件中的镜像数据32回迁。

需要在此说明的是，只有当分区中存储的系统数据删除后完全不影响当前版本的运行时，才能在recovery模式删除下将该分区删除，并且在回迁时不回迁存储该分区中的系统数据。否则，删除该分区会导致在升级至目标版本前，电子设备130无法正常运行。因此，删除分区的情况是极少的。例如，在当前版本的操作系统中某个静态子分区中存储的镜像数据是多余的情况下，才可以通过本申请方案删除掉分区，并且不回迁存储在该分区中的镜像数据。如此，可以释放更多的存储空间。

第三种，修改名称。即，将第三分区改名为第四分区。

在回迁系统数据的过程中，针对修改名称的分区，电子设备130可以从更新后的分区表中查询修改名称后的分区及其对应的分区信息，如分区大小、起始地址以及结束地址等。然后，电子设备130可以将存储在修改名称前的分区(即第三分区)中的镜像数据，回迁到ROM中修改名称后的分区(即第四分区)的起始地址和结束地址之间(也可以称为第三目标地址区间)的位置。如此，可以保证修改名称后的分区中存储的系统数据，与修改名称前的分区中存储的系统数据相同。

示例性的，change_detail.mbn中包括change：abl_test，abl，表示将分区的名称abl_test修改为abl。例如，当前版本的分区表描述的分区如图11中左边所示，更新后的分区表描述的分区可以如图11中右边所示。很显然，图11左边所示的abl_test_a子分区和abl_test_b子分区，依次修改为图11右边所示的abl_a子分区和abl_b子分区。

针对图11所示的情况，在回迁系统数据的过程中，电子设备130可以在更新后的分区表中查询change_detail.mbn中记录的修改名称后的子分区，即abl子分区，查询到abl_a和abl_b两个子分区，以及查询到这两个子分区的起始地址和结束地址。如图11中右边所示，查询到abl_a子分区的起始地址是C1C1，结束地址是D1D1，abl_b子分区的起始地址是C2C2，结束地址是D2D2。以及，change_detail.mbn中记录的修改前的名称为abl_test，那么，电子设备130可以将用户数据分区(Userdata)中abl_test_a.img文件中的镜像数据31回迁到ROM中地址C1C1-D1D1之间的位置，以及将用户数据分区(Userdata)中abl_test_b.img文件中的镜像数据32回迁到ROM中地址C2C2-D2D2之间的位置。

第四种，除上述第一种-第三种之外的情况。

参见图12，当前版本的分区表描述的分区如图12中左边所示，更新后的分区表描述的分区可以如图12中右边所示。除上述第一种-第三种之外的情况包括：未变化、分区大小变化、以及地址变化但分区大小不变三种子情况中的一种或多种。

其中，未变化是指分区大小、起始地址、结束地址和名称都未变化。例如，bootloader_a子分区在图12左边所示的分区大小、起始地址、结束地址和名称，与在图12左边所示的分区大小、起始地址、结束地址和名称都相同。bootloader_b子分区在图12左边所示的分区大小、起始地址、结束地址和名称，与在图12左边所示的分区大小、起始地址、结束地址和名称都相同。

其中，分区大小变化进一步包括分区扩大和分区缩小两种子情况。分区缩小是指分区对应的存储空间变小，分区扩大是指分区对应的存储空间变大。以分区扩大为例，boot_a子分区在图12右边所示的分区大小比在图12左边所示的分区大小要大，boot_b子分区在图12右边所示的分区大小比在图12左边所示的分区大小要大。

需要说明的是，为了使调节后的分区依然可以存储当前操作中对应的系统数据，从而保证在升级至目标版本前，电子设备130依然可以正常运行。对于分区缩小的情况，一定要满足缩小后的分区大小足以存储当前版本中对应分区的系统数据。

应理解，分区大小变化，通常也伴随起始地址和/或结束地址的变化。例如，图12右边所示的boot_a子分区的分区大小比图12左边所示的boot_a子分区的分区大小要大，相应的，图12右边所示boot_a子分区的结束地址B1aB1aB1a比图12左边所示boot_a子分区的结束地址B1B1B1靠后。又如，图12右边所示的boot_b子分区的分区大小比图12左边所示的boot_b子分区的分区大小要大，相应的，图12右边所示boot_b子分区的起始地址A2aA2aA2a比图12左边所示boot_b子分区的起始地址A2A2A2要靠后，以及，图12右边所示boot_b子分区的结束地址B2aB2aB2a比图12左边所示boot_b子分区的结束地址B2B2B2要靠后。

其中，地址变化但分区大小不变通常是由于在前的分区的分区大小之和发生变化造成的。例如，删除了在前的分区或者在前的分区的分区大小缩小了，导致在前的分区的分区大小之和减小。又如，在前的分区发生了新增或者在前的分区的分区大小扩大了，导致在前的分区的分区大小之和增大。再如，改变了各个分区之间的排列顺序，在前的分区发生了变化，导致在前的分区的分区大小之和改变。

以在前的分区的分区大小扩大了为例，参见图12，boot_a子分区和boot_b子分区的分区大小变大了，从而导致其后的各个分区的地址随之发生了后移。例如，vendor_boot_a子分区的起始地址由A3A3A3后移到A3aA3aA3a，以及vendor_boot_a的结束地址由B3B3B3后移到B3aB3aB3a。

为了方便说明，可以将分区大小变化以及地址变化但分区大小不变的小区统称为第五分区。

应理解，前文第一种-第三种情况都在调表包的change_detail.mbn文件中有记录。而第四种情况，通常可以直接从分区表中的分区大小、起始地址和/或结束地址中体现，无需在change_detail.mbn文件中记录。基于此，电子设备130可以解析调表包中的change_detail.mbn文件，对于change_detail.mbn文件中未记录的分区，则认为是第四种情况涉及的分区(也可以称为第六分区)。即，第六分区是除前述第一分区、第二分区和第四分区之外的分区。

继续参见图12，在回迁系统数据的过程中，针对change_detail.mbn文件中未记录的任一分区(即第四种情况涉及的任一分区)，电子设备130可以将需要存储在该分区中的系统数据，回迁到更新后的分区表中记录的该分区的起始地址和结束地址之间(也可以称为第一目标地址区间)的位置。

示例性的，change_detail.mbn文件中未记录boot_a子分区，boot_a需要存储的系统数据为用户数据分区(Userdata)中boot_a.img文件中的镜像数据21，并且，更新后的分区表中boot_a子分区的起始地址为A1A1A1，结束地址为B1B1B1。那么，在回迁系统数据的过程中，电子设备130可以将用户数据分区(Userdata)中boot_a.img文件中的镜像数据21回迁到ROM中地址A1A1A1-B1B1B1的位置。

需要在此说明的是，前述S609中，主要以静态分区为例进行了说明。实际实施时，上述四种情况也可以出现在基础分区(Common)中。此处不再赘述。

另外，对于动态分区(Super)，只能对动态分区(Super)整体进行调节(具体可参见前文表1及其相关文本的说明)。并且，动态分区(Super)整体的调节通常仅适用于地址的变化。具体可参见前文第四种情况中，关于地址变化但分区大小不变的子情况的说明，此处也不再赘述。

在将系统数据回迁到更新后的分区表描述的分区(即回迁到ROM)中后，则迁移出来的系统数据不再有作用，而且还会占用存储空间，浪费存储资源。以将系统数据迁移到用户数据分区(Userdata)为例，则系统数据会占用用户数据分区(Userdata)的存储空间。

基于此，在一些实施例中，参见图7，在S609之后，还包括S705：

S705、电子设备130删除迁移出来的系统数据。如此，可以释放存储空间。

以将系统数据迁移到用户数据分区(Userdata)为例，在回迁完成后，电子设备130可以对用户数据分区(Userdata)格式化，从而删除用户数据分区(Userdata)中的系统数据。

S610、电子设备130重启。

由于已经将启动顺序由从静态分区(A)启动变更为从静态分区(B)启动，则电子设备130依然会从静态分区(B)启动，从而可以继续在B系统下运行。此次重启也可以称为获取补丁包之后的第二次重启。

示例性的，以操作系统是Android为例，电子设备130可以使用如下重启指令控制电子设备130重启：

property_set(ANDROID_RB_PROPERTY，“reboot”)。

需要说明的是，此次重启是正常重启，并未进入recovery模式，因此电子设备130可以正常进入操作系统的模式运行，如进入Android模式下运行。并且，由于当前版本的系统数据文件已经回迁到相应分区中了，那么，当前版本的操作系统依然可以正常运行。

S611、拍包服务器110制作目标版本的升级包。

拍包服务器110可以基于目标版本的系统数据来制作升级包。例如，与当前版本相比，目标版本中增加了某特性，那么，拍包服务器110制作得到的升级包中应该包括实现该新特性的数据。

S612、拍包服务器110向OTA服务器120上传升级包。

S613、电子设备130从OTA服务器120下载升级包。

OTA服务器120可以主动向电子设备130推送升级包的下载地址，供电子设备130下载升级包。或者，电子设备130可以向OTA服务器120发送搜包请求，OTA服务器120基于搜包请求向电子设备130发送升级包的下载地址。示例性的，电子设备130可以从Patch_b子分区中读取中间版本的版本号(如V1.1)，向OTA服务器120发送携带有中间版本的版本号(如V1.1)的搜包请求。OTA服务器120将搜包请求中携带的V1.1，与OTA服务器120中最新的版本号(如V2.0)比较，发现V2.0比V1.1更新。该情况下，OTA服务器120可以向电子设备130提供V2.0版本的操作系统的升级包的下载地址，以供电子设备130下载更新。

电子设备130在获取到下载地址后，则可以下载得到目标版本(如V2.0版本)的升级包。

S614、电子设备130基于升级包执行虚拟(Virtual)A/B升级。

电子设备130在获取到升级包之后，可以解析升级包得到各个分区的升级数据(如镜像文件)，然后，将各个分区的升级数据(如镜像文件)写入更新后的分区表描述的对应分区中，从而实现将操作系统升级到目标版本。

示例性的，参见图13，当电子设备130在系统B下运行(如执行S610实现在B系统下运行)并执行S614时，S614包括：

S1301，电子设备130根据升级包和更新后的分区表针对静态分区(A)进行数据写入操作以升级静态分区。

示例性的，电子设备130将升级包中静态分区的各个子分区的升级数据(如镜像数据)，写入更新后的分区表描述的静态分区(A)的对应子分区中。例如，更新后的分区表中包括boot_a子分区的起始地址1和结束地址2，那么，电子设备130可以将升级包中boot_a子分区的升级数据写入到ROM中起始地址1和结束地址2之间的位置。

S1302，电子设备130根据升级包和更新后的分区表在用户数据分区(Userdata)创建虚拟动态分区，在虚拟动态分区写入动态分区(Super)的升级数据。

示例性的，电子设备130将升级包中动态分区(Super)的各个子分区的升级数据(如镜像数据)，写入更新后的分区表描述的用户数据分区(Userdata)中。例如，更新后的分区表包括用户数据分区(Userdata)的起始地址3和结束地址4，那么，电子设备130可以将升级包中动态分区(Super)的各个子分区的升级数据写入到ROM中起始地址3和结束地址4之间的位置。

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

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

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

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

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

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

进一步的，在S1302中，在将cow文件写入用户数据分区(Userdata)后，还需要对动态分区(Super)+cow文件进行整体校验，校验动态分区(Super)+cow文件的有效性，验证中间版本的动态分区(Super)数据+cow文件的合成结果是否为目标版本的动态分区(Super)数据。

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

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

S1303，电子设备130将启动顺序由从静态分区(B)启动变更为从静态分区(A)启动。

例如，改写MBR的启动顺序标识，将启动顺序标识由B改写为A。在电子设备130上电后，当电子设备130读取到启动顺序标识为A，电子设备130从静态分区(A)启动。

S1304，电子设备130重启。即，退出中间版本的操作系统，切断电子设备130电源，再次开启电子设备130电源。

应注意，此处S1304中的重启，与前文调节分区表阶段的重启(如S606和S610中的重启)不同。S610中的重启是响应于用户的重启操作而重启。而调节分区表阶段的重启(如S606和S610中的重启)是通过软件实现的重启，无需用户操作。

S1305，电子设备130基于更新后的分区表依次加载基础分区(Common)、静态分区(A)，从静态分区(A)启动。

由于启动顺序变更为从静态分区(A)启动，则会加载静态分区(A)。

示例性的，电子设备130可从更新后的分区表中获取基础分区(Common)和静态分区(A)中各个子分区的地址(包括起始地址和结束地址)，然后至ROM中该地址指向的位置处读取系统数据，完成基础分区(Common)和静态分区(A)的加载。

S1306，电子设备130基于更新后的分区表加载动态分区(Super)以及用户数据分区(Userdata)的虚拟动态分区。

示例性的，电子设备130可从更新后的分区表中获取动态分区(Super)的地址(包括起始地址和结束地址)，然后至ROM中该地址指向的位置处读取系统数据。在读取到动态分区(Super)头部的元数据(/supermetadata)后，则可以获取到动态分区(Super)的各个子分区在动态分区(Super)中地址的偏移量。电子设备130基于动态分区(Super)的各个子分区在动态分区(Super)中地址的偏移量，可以读取到动态分区(Super)的各个子分区中的系统数据。

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

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

具体的，在S1306中，当动态分区(Super)的子分区首存在对应的cow文件时，先基于snapshot生成动态分区(Super)各个子分区的目标版本的文件地图。电子设备130根据操作系统运行需求确定需要加载的文件，基于动态分区(Super)子分区的目标版本的文件地图进行文件加载。

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

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

S1307，电子设备130成功启动，进入用户交互界面。

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

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

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

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

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

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

S1309，电子设备130将静态分区(A)中的数据同步给静态分区(B)。

在一些实施例中，在完成落盘后，电子设备130还可以将静态分区(A)中各个子分区存储的数据同步给静态分区(B)中的相应子分区，使静态分区(B)中存储的也是目标版本的数据。那么，此后从静态分区(B)启动时，也可以运行最新的操作系统，即目标版本的操作系统。

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

为了便于对上述Virtual A/B升级方案的理解，下面结合图14的示例对VirtualA/B升级方案作进一步的简化说明。如图14所示，电子设备130在V1.1版本的B系统运行(如图14中的状态1401所示)的情况下，从OTA服务器120获取V2.0版本的升级包(可参见前文S613的说明)。在获取升级包后，电子设备130可以执行“安装”以及“校验”的步骤(可参见前文S1301和S1302的说明)。以及，电子设备130可以“切换系统重启”(可参见前文S1303和S1304的说明)，从而可以从静态分区(A)启动，实现在V2.0版本的A系统运行(如图14中的状态1402所示)。应注意，此时由于未完成落盘，因此图14中的状态1402所示的V2.0版本的A系统，需要通过同时加载虚拟动态分区和动态分区(Super)来实现。此后，电子设备130可以执行“落盘”的步骤(可参见前文S1308的说明)，实现将cow文件落盘到动态分区(Super)。并且，电子设备130还可以进一步进行“静态分区同步”，使得从静态分区(A)或者静态分区(B)启动，都可以运行目标版本的操作系统。此后，电子设备130无需同时加载虚拟动态分区和动态分区(Super)，即可实现运行于V2.0版本的A系统(如图14中的状态1403所示)。在完成上述Virtual A/B升级后，电子设备130还可以向OTA服务器120反馈升级结果，使OAT服务器120明确电子设备130中当前运行的操作系统的版本，便于对电子设备130的操作系统的管理。

前文图6和图7的实施例中，主要以电子设备130为主体，说明了调节分区表的具体过程(如前文S603-S610对应的调节分区表的步骤)。进一步的，参见图15，以电子设备130中的ouc apk(即在线更新客户端工具)、update engine(即升级引擎)以及recovery进程(即恢复进程)为执行主体，并且仍以电子设备130当前从静态分区(A)启动为例，调节分区表的具体过程包括：

S1501、ouc apk下载升级包。可参见前文S603的说明。

S1502、ouc apk向update engine发送补丁包。

S1503、update engine校验补丁包。可参见前文S701的说明。

S1504、update engine基于补丁包刷新版本号。可参见前文S604的说明。

S1505、update engine将启动顺序由从静态分区(A)启动变更为从静态分区(B)启动。可参见前文S605的说明。

S1506、update engine确定补丁包用于调分区表。可参见前文S702a的说明。

S1507、update engine解析补丁包中的调表包，获得调表包的分区表。

S1508、update engine将调表包中的分区表与当前版本的分区表比较。可参见前文S702a的说明。

S1509、若调表包中的分区表与当前版本的分区表不相同，update engine将调表包存储到预设目录下。

其中，预设目录是Recovery进程可以访问的目录。示例性的，预设目录为基础分区(common)中cache子分区下的目录，如/cache/recovery。那么，将调表包解压并存储到预设目录下，可以方便进入recovery模式后，Recovery进程获取到调表包，从而执行调分区表相应的处理。

S1510、update engine写入调表包获取指令，调表包获取指令用于指示recovery进程从预设目录中获取调表包。

其中，调表包获取指令(也可以称为预设指令)中包括预设目录和调表包的名称(即预设名称)。示例性的，调表包获取指令的格式为：更新包(update package)＝预设目录/调表包的名称。

以预设目录是/cache/recovery，调表包的名称为update_base_ptable_change.zip，则调表包获取指令可以是update package＝/cache/recovery/update_base_ptable_change.zip。指示从/cache/recovery目录中读取名称为update_base_ptable_change.zip的调表包。

在一种具体的实现方式中，可以将调表包获取指令写在预设目录下的指令文件中。例如，将调表包获取指令存储在/cache/recovery/command中。从而便于recovery进程访问。

S1511、update engine触发重启并进入recovery模式。可参见前文S606的说明。

S1512、recovery进程基于调表包获取指令从预设目录中获取调表包。

示例性的，在启动recovery进程后，recovery进程则可以从预设目录中读取command文件，从而读取到调表包获取指令。

recovery进程可以至调表包获取指令指示的预设目录中，获取调表包获取指令指示的调表包。

S1513、recovery进程校验调表包。可参见前文S606的说明。

需要说明的是，虽然S1512和S1513中都是以调表包来说明。但是实际中，recovery进程还可能读取到其他更新包(如改制包)的获取指令，从而导致获取的是其他更新包，而并不是调表包。因此，recovery进程还需要执行下述S1514，确定是否为调分区表的场景。

S1514、recovery进程确定当前是否为调分区表的场景。可参见前文S704的说明。

示例性的，若S1512中从调表包获取指令中读取到调表包的名称(即预设名称)，则可以确定当前为调分区表的场景。

S1515、若确定当前为调分区表的场景，recovery进程设置用于指示调节分区表的预设全局变量。

recovery进程通过设置用于指示调节分区表的预设全局变量，如ptable-change，从而可以明确指示当前为调分区表的场景。后续在代码运行的过程中，可以基于该预设全局变量执行对应调分区表的场景的操作，无需每次在执行操作前，都进行场景的判定。

S1516、recovery进程检测到用于指示调表的全局变量，将基础分区(Common)、静态分区(A)、静态分区(B)和动态分区(Super)中的系统数据迁移。可参见前文S607的说明。

示例性的，recovery进程将基础分区(Common)、静态分区(A)、静态分区(B)和动态分区(Super)中的系统数据迁移到用户数据分区(Userdata)的尾部。

S1517、recovery进程利用调表包中的分区表更新电子设备130中当前版本的分区表,得到更新后的分区表。可参见前文S608的说明。

S1518、recovery进程将系统数据回迁到更新后的分区表描述的各个分区中。可参见前文S609的说明。

S1519、recovery进程删除迁移出来的系统数据。可参见前文S705的说明。

S1520、recovery进程触发重启。

应理解，此次重启为正常重启，重启后会进入操作系统的模式，如Android模式，而不会进入recovery模式。

最后，需要在此说明的是，前文主要基于virtual A/B的数据存储结构为例，说明了基于补丁包调节分区表的具体实现。当然，在另一些实施例中，采用非virtual A/B的数据存储结构存储器(如ROM)也可以采用本申请实施例提供的基于补丁包调节分区表的方案，实现分区部署的调节。本申请实施例对此不作具体限定。

示例性的，参见图16，可以应用于数据存储结构(a)。在数据存储结构(a)中，静态分区和动态分区(Super)都只有一套，电子设备130只能在基础分区、静态分区和动态分区(Super)中的数据构成的操作系统中运行。本示例中，电子设备130中记录有当前版本的分区表，用于描述基础分区、静态分区和动态分区(Super)的一种分区部署。电子设备130可以获取用于调节分区表的补丁包，补丁包中包括分区表，用于描述基础分区、静态分区和动态分区(Super)的另一种分区部署。然后，电子设备130重启进入recovery模式，并在recovery模式下，将基础分区、静态分区和动态分区(Super)的数据迁出，如迁出到用户数据分区(Userdata)，将存储器的分区部署由当前版本的分区表描述的分区部署更新为补丁包中的分区表描述的分区部署，最后将迁出的数据回迁到补丁包中的分区表描述的分区部署对应的各个分区中。从而实现针对数据存储结构(a)的分区表调节。

又示例性的，继续参见图16，还可以应用于数据存储结构(b)。在数据存储结构(b)中，静态分区和动态分区(Super)都有两套。电子设备130可以在基础分区、静态分区(A)和动态分区(Super)(A)(也可以称为第一动态分区)中的数据构成的操作系统(如操作系统(A))中运行，也可以在基础分区、静态分区(B)和动态分区(Super)(B)(也可以称为第二动态分区)中的数据构成的操作系统(如操作系统(B))中运行。本示例中，电子设备130中记录有当前版本的分区表，用于描述基础分区、静态分区(A)、静态分区(B)、动态分区(Super)(A)和动态分区(Super)(B)的一种分区部署。电子设备130可以获取用于调节分区表的补丁包，补丁包中包括分区表，用于描述基础分区、静态分区(A)、静态分区(B)、动态分区(Super)(A)和动态分区(Super)(B)的另一种分区部署。然后，电子设备130重启进入recovery模式，并在recovery模式下，将基础分区、静态分区(A)、静态分区(B)、动态分区(Super)(A)和动态分区(Super)(B)的数据迁出，如迁出到用户数据分区(Userdata)，将存储器的分区部署由当前版本的分区表描述的分区部署更新为补丁包中的分区表描述的分区部署，最后将迁出的数据回迁到补丁包中的分区表描述的分区部署对应的各个分区中。从而实现针对数据存储结构(b)的分区表调节。

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

本申请实施例还提供一种芯片系统，该芯片系统可以应用于前述实施例中的电子设备。如图17所示，该芯片系统包括至少一个处理器1701和至少一个接口电路1702。该处理器1701可以是上述电子设备中的处理器。处理器1701和接口电路1702可通过线路互联。该处理器1701可以通过接口电路1702从上述电子设备的存储器接收并执行计算机指令。当计算机指令被处理器1701执行时，可使得电子设备执行上述实施例中的各个步骤。当然，该芯片系统还可以包含其他分立器件，本申请实施例对此不作具体限定。

在一些实施例中，通过以上的实施方式的描述，所属领域的技术人员可以清楚地了解到，为描述的方便和简洁，仅以上述各功能模块的划分进行举例说明，实际应用中，可以根据需要而将上述功能分配由不同的功能模块完成，即将装置的内部结构划分成不同的功能模块，以完成以上描述的全部或者部分功能。上述描述的系统，装置和单元的具体工作过程，可以参考前述方法实施例中的对应过程，在此不再赘述。

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

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

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

Claims

1.一种操作系统的升级方法，其特征在于，应用于电子设备，所述电子设备包括存储器，所述存储器包括基础分区、第一静态分区、第二静态分区以及动态分区，所述电子设备中包括第一分区表，所述第一分区表用于描述所述基础分区、所述第一静态分区、所述第二静态分区以及所述动态分区的一种分区部署，所述方法包括：

所述电子设备获取补丁包，所述补丁包中包括第二分区表，所述第二分区表用于描述所述基础分区、所述第一静态分区、所述第二静态分区以及所述动态分区的另一种分区部署；

在获取到所述补丁包之后，所述电子设备第一次重启，进入恢复模式；

在所述恢复模式下，电子设备将所述基础分区、所述第一静态分区、所述第二静态分区以及所述动态分区中的数据迁出，将所述存储器的分区部署由所述第一分区表描述的分区部署更新为所述第二分区表描述的分区部署，将迁出的数据回迁到所述第二分区表描述的分区部署中对应的各个分区中；

所述电子设备第二次重启。

2.根据权利要求1所述的方法，其特征在于，在所述电子设备第二次重启之后，所述方法还包括：

所述电子设备获取所述电子设备的操作系统的升级包，将所述升级包中的升级数据写入到所述第二分区表描述的分区部署对应的各个分区中，完成所述操作系统升级。

3.根据权利要求1或2所述的方法，其特征在于，所述第一分区表中包括第一版本的操作系统中，所述基础分区、所述第一静态分区以及所述第二静态分区中多个子分区的分区信息，以及，所述动态分区的分区信息；所述第二分区表中包括第二版本的操作系统中，所述基础分区、所述第一静态分区以及所述第二静态分区中多个子分区的分区信息，以及，所述动态分区的分区信息；

其中，所述分区信息包括分区大小、分区名称、起始地址以及结束地址。

4.根据权利要求3所述的方法，其特征在于，所述电子设备第一次重启，进入恢复模式，包括：

如果所述第一分区表与所述第二分区表不同，所述电子设备第一次重启，进入所述恢复模式。

5.根据权利要求4所述的方法，其特征在于，所述第一分区表与所述第二分区表不同，包括以下至少一项：

所述第二分区表中包括第一分区的分区信息，所述第一分区表中不包括所述第一分区的分区信息；

所述第一分区表中包括第二分区的分区信息，所述第二分区表中不包括所述第二分区的分区信息；

所述第一分区表中包括第三分区的分区信息，所述第二分区表中包括第四分区的分区信息，所述第三分区的分区名称和所述第四分区的分区名称不同，但所述第三分区和所述第四分区用于存储相同的数据；以及，

所述第一分区表和所述第二分区表中都包括第五分区的分区信息，但所述第一分区表中、所述第五分区的第一分区信息，与所述第二分区表中、所述第五分区的第一分区信息不同，所述第一分区信息不包括分区名称；

其中，所述第一分区、所述第二分区、所述第三分区、所述第四分区、所述第五分区是所述基础分区、所述第一静态分区以及所述第二静态分区中的一个子分区，或者，所述第一分区、所述第二分区、所述第三分区、所述第四分区、所述第五分区是所述动态分区。

6.根据权利要求5所述的方法，其特征在于，所述将迁出的数据回迁到所述第二分区表描述的分区部署中对应的各个分区中，包括：

所述电子设备将从所述第六分区迁出的数据，回迁到所述存储器中第一目标地址区间内；

其中，所述第六分区是所述第二分区表中除所述第一分区、所述第二分区和所述第四分区之外的分区，所述第六分区是所述基础分区、所述第一静态分区以及所述第二静态分区中的一个子分区，或者，所述第六分区是所述动态分区，所述第一目标地址区间是所述第二分区表中所述第六分区的起始地址和结束地址之间的区间。

7.根据权利要求5或6所述的方法，其特征在于，所述将迁出的数据回迁到所述第二分区表描述的分区部署中对应的各个分区中，包括：

所述电子设备将所述存储器中第二目标地址区间内的数据清零；

其中，所述第二目标地址区间是所述第二分区表中、所述第一分区的起始地址和结束地址之间的区间。

8.根据权利要求7所述的方法，其特征在于，所述补丁包中包括第一指示信息，所述第一指示信息用于指示：与所述第一分区表相比，所述第二分区表中新增了所述第一分区；

在所述电子设备将所述存储器中第二目标地址区间内的数据清零之前，所述方法还包括：

所述电子设备读取所述第一指示信息，基于所述第一指示信息从所述第二分区表中查询所述第一分区的起始地址和结束地址。

9.根据权利要求5-8中任一项所述的方法，其特征在于，所述将迁出的数据回迁到所述第二分区表描述的分区部署中对应的各个分区中，包括：

所述电子设备不回迁从所述第二分区中迁出的数据。

10.根据权利要求9所述的方法，其特征在于，所述补丁包中包括第二指示信息，所述第二指示信息用于指示：与所述第一分区表相比，所述第二分区表中删除了所述第二分区；

所述方法还包括：

所述电子设备读取所述第二指示信息，基于所述第二指示信息确定从所述第二分区中迁出的数据。

11.根据权利要求5-10中任一项所述的方法，其特征在于，所述将迁出的数据回迁到所述第二分区表描述的分区部署中对应的各个分区中，包括：

所述电子设备将从所述第三分区中迁出的数据，回迁到所述存储器的第三目标地址区间内；

其中，所述第三目标地址区间是所述第二分区表中所述第四分区的起始地址和结束地址之间的区间。

12.根据权利要求11所述的方法，其特征在于，所述补丁包中包括第三指示信息，所述第三指示信息用于指示：所述第一分区表中的所述第三分区，更新为所述第二分区表中的所述第四分区；

在所述电子设备将从所述第三分区迁出的数据，回迁到所述存储器的第三目标地址区间内之前，包括：

所述电子设备读取所述第三指示信息，基于所述第三指示信息从所述第二分区表中查询所述第四分区的起始地址和结束地址。

13.根据权利要求1-12中任一项所述的方法，其特征在于，所述在获取到所述补丁包之后，所述电子设备第一重启，包括：

在获取到所述补丁包之后，如果所述补丁包中包括预设名称的数据包，或者，所述补丁包中包括第一标签，所述电子设备第一次重启；

其中，所述预设名称的数据包用于调节分区部署，所述第一标签用于指示调节分区部署。

14.根据权利要求1-13中任一项所述的方法，其特征在于，所述将所述基础分区、所述第一静态分区、所述第二静态分区以及所述动态分区中的数据迁出，包括：

如果所述补丁包中包括预设名称的数据包，将所述基础分区、所述第一静态分区、所述第二静态分区以及所述动态分区中的数据迁出；

其中，所述预设名称的数据包用于调节分区部署。

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

在所述补丁包中包括所述预设名称的数据包的情况下，所述电子设备将所述预设名称的数据包存储到所述电子设备的预设目录下，并在所述电子设备中写入预设指令，所述预设指令中包括所述预设名称；

在获取到所述补丁包之后，所述电子设备第一次重启之后，所述方法还包括：

所述电子设备读取所述预设指令；

如果所述补丁包中包括预设名称的数据包，将所述基础分区、所述第一静态分区、所述第二静态分区以及所述动态分区中的数据迁出，包括：

如果所述预设指令中包括所述预设名称，所述电子设备将所述基础分区、所述第一静态分区、所述第二静态分区以及所述动态分区的数据迁出。

16.根据权利要求14或15所述的方法，其特征在于，如果所述补丁包中包括预设名称的数据包，将所述基础分区、所述第一静态分区、所述第二静态分区以及所述动态分区中的数据迁出，包括：

所述补丁包中包括所述预设名称的数据包，所述电子设备设置用于指示调节分区部署的预设全局变量；

所述电子设备检测到所述预设全局变量，将所述基础分区、所述第一静态分区、所述第二静态分区以及所述动态分区中的数据迁出。

17.根据权利要求15或16所述的方法，其特征在于，所述预设指令中包括预设目录，所述第二分区表存储在所述预设名称的数据包中；

在所述将所述存储器的分区部署由所述第一分区表描述的分区部署更新为所述第二分区表描述的分区部署之前，所述方法还包括：

所述电子设备根据所述预设指令至所述预设目录下获取所述预设名称的数据包，从所述预设名称的数据包中获取所述第二分区表。

18.根据权利要求1-17中任一项所述的方法，其特征在于，所述存储器中还包括用户数据分区，所述将所述基础分区、所述第一静态分区、所述第二静态分区以及所述动态分区中的数据迁出，包括：

所述电子设备将所述基础分区、所述第一静态分区、所述第二静态分区以及所述动态分区中的数据迁出至所述用户数据分区；

所述将迁出的数据回迁到所述第二分区表描述的分区部署中对应的各个分区中，包括：

将所述用户数据分区中所述基础分区、所述第一静态分区、所述第二静态分区以及所述动态分区的数据回迁至所述第二分区表描述的分区部署中对应的各个分区中。

19.根据权利要求1-18中任一项所述的方法，其特征在于，在所述将迁出的数据回迁到所述第二分区表描述的分区部署中对应的各个分区中之后，所述方法还包括：

删除迁出的数据。

20.根据权利要求2-19中任一项所述的方法，其特征在于，所述补丁包中包括第一版本号；

所述电子设备获取补丁包，包括：

在所述电子设备加载所述基础分区、所述第一静态分区以及所述动态分区，运行所述电子设备的情况下，所述电子设备获取所述补丁包；

在所述电子设备获取补丁包之后，所述方法还包括：

所述电子设备将所述第二静态分区中的版本号刷新为所述第一版本号；

所述电子设备设置所述电子设备的启动顺序为从所述第二静态分区启动；

所述电子设备第二次重启之后，所述方法还包括：

所述电子设备加载所述基础分区、所述第二静态分区以及所述动态分区，运行所述电子设备；

所述电子设备从所述第二静态分区中读取所述第一版本号；

所述电子设备获取所述电子设备的操作系统的升级包，包括：

所述电子设备基于所述第一版本号获取所述电子设备的操作系统的升级包。

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

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

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