最新中国发明专利
/
2023-05-23

一种操作系统升级方法及电子设备转让专利

申请号 : CN202210143150.2

文献号 : CN115543368B

文献日 :

基本信息:

PDF:

法律信息:

相似专利:

发明人 : 张赠辉 , 黄九林 , 王艳召 , 陈超

申请人 : 荣耀终端有限公司

摘要 :

本申请提供一种操作系统升级方法及电子设备，涉及终端技术领域。解决了演示制式的电子设备的改制问题。具体方案为：获取系统升级包；将第二静态分区中的系统数据更新为第一升级数据；修改电子设备的启动顺序标识，其中，修改后的启动顺序标识指示从第二静态分区启动；在电子设备完成第一次重启之后，将动态分区中的系统数据更新为第二升级数据；将第一制式信息修改为第二制式信息；在电子设备第二次重启之后，进入恢复模式；在恢复模式下，将第一数据的起始物理地址从第一地址迁移至第二地址；将第一分区表修改为第二分区表。这样，可支持远程升级，实现演示到商用的切换，避免样机回收投递、节省刷机人力成本。

权利要求 :

1.一种操作系统升级方法，其特征在于，应用于电子设备，所述电子设备包括存储器，所述存储器包括基础分区、第一静态分区、第二静态分区、动态分区以及用户数据分区；所述动态分区包括第一子分区，所述动态分区内保存有第一分区表，所述第一分区表包括第一地址，所述第一地址指示所述第一子分区在所述存储器中的起始物理地址；所述基础分区中保存有第一制式文件，所述第一制式文件包括第一制式信息，所述电子设备中配置有启动顺序标识，所述电子设备包括第一操作系统和第二操作系统，在所述启动顺序标识指示从第一静态分区启动时，所述电子设备运行之后，加载所述基础分区、所述第一静态分区以及动态分区的数据，以启动所述第一操作系统；所述第一操作系统启动之后，所述方法包括：获取系统升级包，所述系统升级包用于升级操作系统；所述系统升级包中包括第一升级数据、第二升级数据、第二分区表和第二制式文件，所述第二制式文件包括第二制式信息，所述第二制式信息与所述第一制式信息不同；所述第二分区表包括第二地址，所述第二地址指示完成升级后所述第一子分区在所述存储器中的起始物理地址；

将所述第二静态分区中的系统数据更新为所述第一升级数据；

修改所述电子设备的启动顺序标识，其中，修改后的启动顺序标识指示从所述第二静态分区启动；

在所述电子设备完成第一次重启之后，将所述动态分区中的系统数据更新为所述第二升级数据；

将所述第一制式信息修改为所述第二制式信息；

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

在恢复模式下，将第一数据的起始物理地址从所述第一地址迁移至所述第二地址；其中，所述第一数据包括所述第一子分区中存储的数据；

将所述第一分区表修改为所述第二分区表。

2.根据权利要求1所述的方法，其特征在于，所述第一数据还包括所述动态分区中的第二数据，所述第二数据是存储于所述第一子分区之后，所述基础分区中保存有第三分区表，所述第三分区表中包括第三地址，所述第三地址用于指示当前所述动态分区在所述存储器中的结束物理地址；所述将第一数据的起始物理地址从所述第一地址迁移至所述第二地址，包括：从所述第一地址与所述第三地址之间，读取所述第一数据；

将读取到的所述第一数据写入所述用户数据分区的空白存储区域；

在完成写入之后，以所述第二地址为起始物理地址，将所述用户数据分区中的所述第一数据，写入所述动态分区。

3.根据权利要求1所述的方法，其特征在于，所述第二地址位于所述第一地址之后。

4.根据权利要求3所述的方法，其特征在于，所述基础分区中保存有第三分区表，所述第三分区表中包括第四地址，所述第四地址用于指示所述用户数据分区在所述存储器中的起始物理地址；所述系统升级包还包括第四分区表，所述第四分区表还包括第五地址，所述第五地址用于指示完成升级后所述用户数据分区在所述存储器中的起始物理地址，所述第五地址位于所述第四地址之前；在将第一数据的起始物理地址从所述第一地址迁移至所述第二地址之后，所述方法还包括：利用所述第四分区表更新所述第三分区表。

5.根据权利要求1‑4任意一项所述的方法，其特征在于，在利用所述第二分区表更新所述第一分区表之后，所述方法还包括：确定所述第一制式文件中已包括所述第二制式信息；

格式化所述用户数据分区。

6.根据权利要求1‑4任意一项所述的方法，其特征在于，在利用所述第二分区表更新所述第一分区表之后，所述方法还包括：确定所述第一制式文件中不包括所述第二制式信息；

再次读取所述第二制式信息，并写入所述第一制式文件，用于替代所述第一制式文件中的第一制式信息。

7.根据权利要求1‑4任意一项所述的方法，其特征在于，在所述电子设备第一次重启之前，所述方法还包括：在解析所述系统升级包之后，确定所述系统升级包中包含改制小包；其中，所述第二分区表被压缩于所述改制小包；

将所述第二制式文件，以临时文件的形式存储于所述基础分区；

将所述改制小包解压于第一存储区域；其中，所述第一存储区域是所述恢复模式下，所述电子设备可访问的存储区域；

在所述将第一数据的起始物理地址从所述第一地址迁移至所述第二地址之前，所述方法还包括：从所述第一存储区域中的所述第二分区表，获取所述第二地址。

8.根据权利要求7所述的方法，其特征在于，在进入恢复模式之后，所述方法还包括：在所述第一存储区域中存储所述改制小包的情况下，在第二存储区域中写入第一指示信息；

所述将第一数据的起始物理地址从第一地址迁移至所述第二地址，包括：在检测到所述第一指示信息之后，将所述第一数据的起始物理地址从第一地址迁移至所述第二地址。

9.根据权利要求1‑4任意一项所述的方法，其特征在于，在将所述第二静态分区中的系统数据更新为所述第一升级数据之后，所述方法还包括：在所述用户数据分区创建虚拟分区；将所述第二升级数据写入所述虚拟分区中；

所述将所述动态分区中的系统数据更新为所述第二升级数据，包括：将所述虚拟分区中的第二升级数据，合并到所述动态分区中。

10.根据权利要求1‑4任意一项所述的方法，其特征在于，在修改所述电子设备的启动顺序标识之后，所述方法还包括：在第一次重启的过程中，加载所述基础分区、所述第二静态分区、所述动态分区及虚拟分区中的数据；

在完成第一次重启之后，将所述第二静态分区中的数据镜像至所述第一静态分区。

11.一种电子设备，其特征在于，电子设备包括一个或多个处理器和存储器；所述存储器与处理器耦合，存储器用于存储计算机程序代码，计算机程序代码包括计算机指令，当一个或多个处理器执行计算机指令时，所述一个或多个处理器，用于执行如权利要求1‑10中任一项所述的方法。

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

说明书 :

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

[0001] 本申请要求于2022年01月10日提交国家知识产权局、申请号为202210023826.4、申请名称为“一种操作系统升级方法及电子设备”的中国专利申请的优先权，其全部内容通过引用结合在本申请中。

技术领域

[0002] 本申请涉及终端设备领域，尤其涉及一种操作系统升级方法及电子设备。

背景技术

[0003] 在现有技术的应用场景中，用户终端需要安装操作系统才可以被用户使用。例如，手机上需要安装手机操作系统(例如：IOS系统、安卓系统)才可以被用户使用。
[0004] 然而，操作系统具有不同的制式，不同制式下系统分区存在差异。比如，演示样机对应的制式为demo cn，商用机对应的制式为all cn，演示样机的定制(version)子分区远大于商用机的version定制子分区，差异高达8G。在手机下市之后，演示样机也需要面向用户销售，显然，演示样机转商用机就十分重要。

发明内容

[0005] 本申请实施例提供一种操作系统升级方法及电子设备，用于提高电子设备制式变更的刷机人机效率。
[0006] 第一方面，本申请实施例提供的一种操作系统升级方法，应用于电子设备，电子设备包括存储器，存储器包括基础分区、第一静态分区、第二静态分区、动态分区以及用户数据分区；动态分区包括第一子分区，动态分区内保存有第一分区表，第一分区表包括第一地址，第一地址指示第一子分区在存储器中的起始物理地址；基础分区中保存有第一制式文件，第一制式文件包括第一制式信息，电子设备中配置有启动顺序标识，电子设备包括第一操作系统和第二操作系统，在启动顺序标识指示从第一静态分区启动时，电子设备运行之后，加载基础分区、第一静态分区以及动态分区的数据，以启动第一操作系统；第一操作系统启动之后，方法包括：获取系统升级包，系统升级包用于升级操作系统；系统升级包中包括第一升级数据、第二升级数据、第二分区表和第二制式文件，第二制式文件包括第二制式信息，第二制式信息与第一制式信息不同；第二分区表包括第二地址，第二地址指示完成升级后第一子分区在存储器中的起始物理地址；将第二静态分区中的系统数据更新为第一升级数据；修改电子设备的启动顺序标识，其中，修改后的启动顺序标识指示从第二静态分区启动；在电子设备完成第一次重启之后，将动态分区中的系统数据更新为第二升级数据；将第一制式信息修改为第二制式信息；在电子设备第二次重启之后，进入恢复模式；在恢复模式下，将第一数据的起始物理地址从第一地址迁移至第二地址；其中，第一数据包括第一子分区中存储的数据；将第一分区表修改为第二分区表。
[0007] 另外，电子设备包括两套彼此备份的操作系统，也即，第一操作系统和第二操作系统，电子设备通过加载不同的静态分区实现运行不同的操作系统。
[0008] 在上述实施例中，以电子设备运行第一操作系统的场景为例，在收到的系统升级包中包括第二制式文件，且第二制式文件与第一制式文件不同的情况下，电子设备可以利用该系统升级包，在升级的过程中，更改电子设备的制式类型，此类升级可称为改制升级。
[0009] 示例性地，上述第一子分区可以是指改制后起始物理地址变化的系统子分区。以将电子设备改制为商用版本为例，第一子分区可以是预装子分区，该预装子分区位于定制子分区之后。可以理解的，演示样机的定制子分区与商用样机的定制子分区的大小不同。这样，演示样机的预装子分区的位置与商用样机的定制子分区也不同。
[0010] 在电子设备基于系统升级包进行虚拟AB升级的过程中，可以将第一制式信息更换为第二制式信息，此外，在merge，也即，利用第二升级数据更新动态分区之后，电子设备迁移第一数据至存储位置。该第一数据包括merge之后第一子区域中的数据。在第一数据的存储位置迁移之后，第一数据的起始物理地址与第二分区表中第二地址相同，该第二地址是商用制式的电子设备中第一子分区的起始物理地址。之后，再变更指示第一子分区的起始物理地址的分区表，也即，将第一分区表修改为第二分区表。这样，在自动升级的过程中，还可以完成制式变更，无需返厂刷机，提高电子设备制式变更的刷机人机效率。
[0011] 在一些可能的实施例中，第一数据还包括动态分区中的第二数据，第二数据是存储于第一子分区之后，基础分区中保存有第三分区表，第三分区表中包括第三地址，第三地址用于指示当前动态分区在存储器中的结束物理地址；将第一数据的起始物理地址从第一地址迁移至第二地址，包括：从第一地址与第三地址之间，读取第一数据；将读取到的第一数据写入用户数据分区的空白存储区域；在完成写入之后，以第二地址为起始物理地址，将用户数据分区中的第一数据，写入动态分区。
[0012] 在上述实施例中，在迁移第一数据的过程中，保障系统数据的安全性，避免出现意外，导致系统数据受损。
[0013] 在一些可能的实施例中，第二地址位于第一地址之后。
[0014] 在一些可能的实施例中，基础分区中保存有第三分区表，所述第三分区表中包括第四地址，第四地址用于指示用户数据分区在存储器中的起始物理地址；系统升级包还包括第四分区表，第四分区表还包括第五地址，第五地址用于指示完成升级后用户数据分区在存储器中的起始物理地址，第五地址位于第四地址之前；在将第一数据的起始物理地址从第一地址迁移至第二地址之后，方法还包括：利用第四分区表更新第三分区表。
[0015] 在上述实施例中，可以增加用户数据分区的大小，提高电子设备的存储空间利用率。
[0016] 在一些可能的实施例中，在利用第二分区表更新第一分区表之后，方法还包括：确定第一制式文件中已包括第二制式信息；格式化用户数据分区。
[0017] 在一些可能的实施例中，在利用第二分区表更新第一分区表之后，方法还包括：确定第一制式文件中不包括第二制式信息；再次读取第二制式信息，并写入第一制式文件，用于替代第一制式文件中的第一制式信息。
[0018] 在上述实施例中，通过检测制式信息，可以提高改制的成功率。
[0019] 在一些可能的实施例中，在电子设备第一次重启之前，方法还包括：在解析系统升级包之后，确定系统升级包中包含改制小包；其中，第二分区表被压缩于改制小包；将第二制式文件，以临时文件的形式存储于基础分区；将改制小包解压于第一存储区域；其中，第一存储区域是恢复模式下，电子设备可访问的存储区域；在将第一数据的起始物理地址从第一地址迁移至第二地址之前，方法还包括：从第一存储区域中的第二分区表，获取第二地址。
[0020] 在一些可能的实施例中，在进入恢复模式之后，方法还包括：在第一存储区域中存储改制小包的情况下，在第二存储区域中写入第一指示信息；将第一数据的起始物理地址从第一地址迁移至第二地址，包括：在检测到第一指示信息之后，将第一数据的起始物理地址从第一地址迁移至第二地址。
[0021] 在一些可能的实施例中，在将第二静态分区中的系统数据更新为第一升级数据之后，方法还包括：在用户数据分区创建虚拟分区；将第二升级数据写入虚拟分区中；将动态分区中的系统数据更新为第二升级数据，包括：将虚拟分区中的第二升级数据，合并到动态分区中。
[0022] 在一些可能的实施例中，在修改电子设备的启动顺序标识之后，方法还包括：在第一次重启的过程中，加载基础分区、第二静态分区、动态分区及虚拟分区中的数据；在完成第一次重启之后，将第二静态分区中的数据镜像至第一静态分区。
[0023] 第二方面，本申请实施例提供的一种电子设备，电子设备包括一个或多个处理器和存储器；所述存储器与处理器耦合，存储器用于存储计算机程序代码，计算机程序代码包括计算机指令，当一个或多个处理器执行计算机指令时，所述一个或多个处理器，用于：获取系统升级包，系统升级包用于升级操作系统；系统升级包中包括第一升级数据、第二升级数据、第二分区表和第二制式文件，第二制式文件包括第二制式信息，第二制式信息与第一制式信息不同；第二分区表包括第二地址，第二地址指示完成升级后第一子分区在存储器中的起始物理地址；将第二静态分区中的系统数据更新为第一升级数据；修改电子设备的启动顺序标识，其中，修改后的启动顺序标识指示从第二静态分区启动；在电子设备完成第一次重启之后，将动态分区中的系统数据更新为第二升级数据；将第一制式信息修改为第二制式信息；在电子设备第二次重启之后，进入恢复模式；在恢复模式下，将第一数据的起始物理地址从第一地址迁移至第二地址；其中，第一数据包括第一子分区中存储的数据；将第一分区表修改为第二分区表。
[0024] 在一些可能的实施例中，第一数据还包括动态分区中的第二数据，第二数据是存储于第一子分区之后，基础分区中保存有第三分区表，第三分区表中包括第三地址，第三地址用于指示当前动态分区在存储器中的结束物理地址；一个或多个处理器，还用于：从第一地址与第三地址之间，读取第一数据；将读取到的第一数据写入用户数据分区的空白存储区域；在完成写入之后，以第二地址为起始物理地址，将用户数据分区中的第一数据，写入动态分区。
[0025] 在一些可能的实施例中，第二地址位于第一地址之后。
[0026] 在一些可能的实施例中，基础分区中保存有第三分区表，第三分区表中包括第四地址，第四地址用于指示用户数据分区在存储器中的起始物理地址；系统升级包还包括第四分区表，第四分区表还包括第五地址，第五地址用于指示完成升级后用户数据分区在存储器中的起始物理地址，第五地址位于第四地址之前；在将第一数据的起始物理地址从第一地址迁移至第二地址之后，一个或多个处理器，还用于：利用第四分区表更新第三分区表。
[0027] 在一些可能的实施例中，在利用第二分区表更新第一分区表之后，一个或多个处理器，还用于：确定第一制式文件中已包括第二制式信息；格式化用户数据分区。
[0028] 在一些可能的实施例中，在利用第二分区表更新第一分区表之后，一个或多个处理器，还用于：确定第一制式文件中不包括第二制式信息；再次读取第二制式信息，并写入第一制式文件，用于替代所述第一制式文件中的第一制式信息。
[0029] 在一些可能的实施例中，在电子设备第一次重启之前，一个或多个处理器，还用于：在解析系统升级包之后，确定系统升级包中包含改制小包；其中，第二分区表被压缩于改制小包；将第二制式文件，以临时文件的形式存储于基础分区；将改制小包解压于第一存储区域；其中，第一存储区域是恢复模式下，电子设备可访问的存储区域；从第一存储区域中的第二分区表，获取第二地址。
[0030] 在一些可能的实施例中，在进入恢复模式之后，一个或多个处理器，还用于：在第一存储区域中存储改制小包的情况下，在第二存储区域中写入第一指示信息；将第一数据的起始物理地址从第一地址迁移至第二地址，包括：在检测到第一指示信息之后，将第一数据的起始物理地址从第一地址迁移至第二地址。
[0031] 在一些可能的实施例中，在将第二静态分区中的系统数据更新为第一升级数据之后，一个或多个处理器，还用于：在用户数据分区创建虚拟分区；将第二升级数据写入虚拟分区中；将虚拟分区中的第二升级数据，合并到动态分区中。
[0032] 在一些可能的实施例中，在修改电子设备的启动顺序标识之后，一个或多个处理器，还用于：在第一次重启的过程中，加载基础分区、第二静态分区、动态分区及虚拟分区中的数据；在完成第一次重启之后，将第二静态分区中的数据镜像至第一静态分区。
[0033] 第三方面，本申请实施例提供的一种计算机存储介质，包括计算机指令，当所述计算机指令在电子设备上运行时，使得电子设备执行上述第一方面及其可能的实施例中所述的方法。
[0034] 第四方面，本申请提供一种计算机程序产品，当计算机程序产品在上述电子设备上运行时，使得电子设备执行上述第一方面及其可能的实施例中所述的方法。
[0035] 可以理解地，上述各个方面所提供的电子设备、计算机可读存储介质以及计算机程序产品均应用于上文所提供的对应方法，因此，其所能达到的有益效果可参考上文所提供的对应方法中的有益效果，此处不再赘述。

附图说明

[0036] 图1为本申请实施例提供的电子设备中操作系统的数据存储结构示例图之一；
[0037] 图2为本申请实施例提供的演示样机和商用机的系统分区的示例图；
[0038] 图3A为本申请实施例提供的电子设备的结构示例图；
[0039] 图3B为本申请实施例提供的一种操作系统升级方法的流程图之一；
[0040] 图4为本申请实施例提供的执行虚拟A/B升级的流程的流程图；
[0041] 图5为本申请实施例提供的执行merge的流程的流程图；
[0042] 图6为本申请实施例提供的操作系统的数据存储结构示例图之二；
[0043] 图7为本申请实施例提供的数据迁移的示例图；
[0044] 图8为本申请实施例提供的数据迁移的流程图；
[0045] 图9为本申请实施例提供的变更用户数据分区(Userdata)的示例图；
[0046] 图10为本申请实施例提供的操作系统的数据存储结构示例图之三；
[0047] 图11为本申请实施例提供的一种操作系统升级方法的流程图之二；
[0048] 图12为本申请实施例提供的一种芯片系统的组成示意图。

具体实施方式

[0049] 以下，术语“第一”、“第二”仅用于描述目的，而不能理解为指示或暗示相对重要性或者隐含指明所指示的技术特征的数量。由此，限定有“第一”、“第二”的特征可以明示或者隐含地包括一个或者更多个该特征。在本实施例的描述中，除非另有说明，“多个”的含义是两个或两个以上。
[0050] 下面将结合附图对本实施例的实施方式进行详细描述。
[0051] 本申请实施例提供了一种操作系统升级方法，该方法可以应用于电子设备。可以理解地，电子设备需要安装操作系统才可以被用户使用。例如，手机上需要安装手机操作系统(例如：IOS系统、安卓系统)才可以被用户使用。
[0052] 示例性地，上述电子设备包括但不限于可以安装操作系统的智能手机、智能耳机、平板电脑、智能冰箱、智能音箱等。操作系统的示例性实施例包括但不限于或者其它操作系统。
[0053] 以采用虚拟A/B操作系统的安卓系统为例，电子设备中操作系统的数据存储结构如图1所示，该操作系统的数据存储结构包括Common分区、系统分区和用户数据分区(Userdata)。
[0054] 其中，Common分区为基础分区，其保存不参与操作系统升级的系统数据。在一些实施例中，Common分区内可以包括至少一个子分区，例如，oeminfo子分区或者nv子分区。其中，该oeminfo子分区可用于存储操作系统的制式(vendor_country，VC)信息，例如，All cn、demo cn、cmcc cn等。其中，All cn用于指示配置有通用中国制式，cmcc cn用于指示中国移动中国制式，demo cn用于指示演示机制式。
[0055] 可以理解地，电子设备需要根据所处的位置、接入的运营商的不同，在操作系统中配置对应的VC信息。如，配置all cn或配置cmcc cn等。此外，电子设备可以依据不同的用途，在操作系统中配置对应的VC信息。如，放置于卖场的演示样机，可以配置demo cn，再例如，面向用户销售的电子设备，可以配置All cn。
[0056] 这样，在电子设备运行的过程中，需要启动操作系统。在启动操作系统的过程中，电子设备读取并加载Common分区中的VC信息，并且，VC信息可以被写入用户数据分区(Userdata)的定制信息(Custom.bin文件)中，以便在操作系统运行过程中被调用。
[0057] 上述用户数据分区(Userdata)用于保存用户的个人数据，例如，用户个人安装的APP、用户个人保存的图片、文档以及视频等个人数据。
[0058] 上述系统分区用于保存操作系统数据。示例性地，系统分区又分为静态分区和动态分区(Super)。其中，静态分区中包括静态分区(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。
[0059] 在具有两个静态分区的情况下，该电子设备内可以虚拟出两套操作系统，如称为，A操作系统和B操作系统。在该电子设备启动时，需基于任意一个操作系统运行。示例性地，电子设备需基于A操作系统运行的情况下，电子设备从静态分区(A)启动：依次加载基础分区(Common)、静态分区(A)以及动态分区(Super)；又示例性地，电子设备需基于B操作系统运行的情况下，电子设备从静态分区(B)启动：依次加载基础分区(Common)、静态分区(B)以及动态分区(Super)。
[0060] 以采用主引导记录(Master Boot Record，MBR)格式的通用闪存(Universal Flash Storage，UFS)为例。在UFS的MBR(主引导扇区，UFS的第一个扇区，即C/H/S地址的0柱面0磁头1扇区)中，保存有电子设备启动顺序描述，例如，从静态分区(A)启动(启动顺序标志为A)或从静态分区(B)启动(启动顺序标志为A)。电子设备启动后首先从UFS的MBR中读取电子设备启动顺序。然后，依据读取到的启动顺序，电子设备可以加载系统分区中的数据，如，前述示例中描述的依次加载基础分区(Common)、静态分区(A)以及动态分区(Super)或者，依次加载基础分区(Common)、静态分区(B)以及动态分区(Super)。
[0061] 另外，动态分区(Super)也可以包含多个子分区，例如，preas、preavs、System、system_ext、vendor、product、Cust、Odm、version、preload。
[0062] 值得注意的是，同款电子设备的动态分区(Super)包括的子区间类型相同，但是，同款的电子设备，在采用不同制式的情况下，动态分区(Super)中各子分区的大小存在差异。例如，对于演示样机(VC信息为demo cn的设备)而言，version子分区，又可称为version定制子分区需用于存放大量的操作演示样片，但是，商用机(VC信息为All cn或cmcc cn的设备)中的version却不需要。这样，演示样机和商用机的version子分区、preload子分区均存在差异。例如，图2所示，演示样机和商用机的version子分区大小不同，preload子分区的起始地址不同。该preload子分区又称为第一子分区。另外，起始地址又可称为是存储器中的起始物理地址。
[0063] 通常在新一代电子设备上市之后，上一代电子设备的演示样机也需要面向用户销售。由于动态分区结构上的差异，即使销售给用户，演示样机依然需要针对演示样机的系统升级包。这样，升级之后，演示样机的version子分区中依然存在演示样片，然而，已销售的演示样机实际上不再需要存放操作演示样片，但是对应的version子区域所占空间依然很大，不合理的存储区域划分，显然会影响到存储空间利用率。
[0064] 为了改善上述问题，本申请实施例提供了一种操作系统升级方法，针对需要出售的演示样机，通过一次操作系统升级，变更演示样机的制式的同时，调整操作系统分区，以使演示样机升级后与商用机无差异，提升设备的存储空间利用率，也增加升级操作系统的效率。
[0065] 在后续实施例中，可以将需要出售的演示样机统称为电子设备。在电子设备的Common分区中，oeminfo子分区中包括指示第一制式(demo cn)的VC信息。
[0066] 请参考图3A，为本申请实施例提供的一种电子设备100的结构示意图。如图3A所示，电子设备100可以包括：处理器110，外部存储器接口120，内部存储器121，通用串行总线(universal serial bus，USB)接口130，充电管理模块140，电源管理模块141，电池142，天线1，天线2，移动通信模块150，无线通信模块160，音频模块170，扬声器170A，受话器170B，麦克风170C，耳机接口170D，传感器模块180，按键190，马达191，指示器192，摄像头193，显示屏194，以及用户标识模块(subscriber identification module，SIM)卡接口195等。
[0067] 其中，上述传感器模块180可以包括压力传感器，陀螺仪传感器，气压传感器，磁传感器，加速度传感器，距离传感器，接近光传感器，指纹传感器，温度传感器，触摸传感器，环境光传感器和骨传导传感器等传感器。
[0068] 可以理解的是，本实施例示意的结构并不构成对电子设备100的具体限定。在另一些实施例中，电子设备100可以包括比图示更多或更少的部件，或者组合某些部件，或者拆分某些部件，或者不同的部件布置。图示的部件可以以硬件，软件或软件和硬件的组合实现。
[0069] 处理器110可以包括一个或多个处理单元，例如：处理器110可以包括应用处理器(application processor，AP)，调制解调处理器，图形处理器(graphics processing unit，GPU)，图像信号处理器(image signal processor，ISP)，控制器，存储器，视频编解码器，数字信号处理器(digital signal processor，DSP)，基带处理器，和/或神经网络处理器(neural‑network processing unit，NPU)等。其中，不同的处理单元可以是独立的器件，也可以集成在一个或多个处理器中。
[0070] 控制器可以是电子设备100的神经中枢和指挥中心。控制器可以根据指令操作码和时序信号，产生操作控制信号，完成取指令和执行指令的控制。
[0071] 处理器110中还可以设置存储器，用于存储指令和数据。在一些实施例中，处理器110中的存储器为高速缓冲存储器。该存储器可以保存处理器110刚用过或循环使用的指令或数据。如果处理器110需要再次使用该指令或数据，可从存储器中直接调用。避免了重复存取，减少了处理器110的等待时间，因而提高了系统的效率。
[0072] 在一些实施例中，处理器110可以包括一个或多个接口。接口可以包括集成电路(inter‑integrated circuit，I2C)接口，集成电路内置音频(inter‑integrated circuit sound，I2S)接口，脉冲编码调制(pulse code modulation，PCM)接口，通用异步收发传输器(universal asynchronous receiver/transmitter，UART)接口，移动产业处理器接口(mobile industry processor interface，MIPI)，通用输入输出(general‑purpose input/output，GPIO)接口，用户标识模块(subscriber identity module，SIM)接口，和/或通用串行总线(universal serial bus，USB)接口等。
[0073] 可以理解的是，本实施例示意的各模块间的接口连接关系，只是示意性说明，并不构成对电子设备100的结构限定。在另一些实施例中，电子设备100也可以采用上述实施例中不同的接口连接方式，或多种接口连接方式的组合。
[0074] 电子设备的无线通信功能可以通过天线1，天线2，移动通信模块250，无线通信模块260，调制解调处理器以及基带处理器等实现。在一些实施例中，电子设备的天线1和移动通信模块250耦合，天线2和无线通信模块260耦合，使得电子设备可以通过无线通信技术与网络以及其他设备通信，如与可穿戴设备通信。
[0075] 天线1和天线2用于发射和接收电磁波信号。电子设备中的每个天线可用于覆盖单个或多个通信频带。不同的天线还可以复用，以提高天线的利用率。例如：可以将天线1复用为无线局域网的分集天线。在另外一些实施例中，天线可以和调谐开关结合使用。
[0076] 移动通信模块250可以提供应用在电子设备上的包括2G/3G/4G/5G等无线通信的解决方案。移动通信模块250可以包括至少一个滤波器，开关，功率放大器，低噪声放大器(low noise amplifier，LNA)等。移动通信模块250可以由天线1接收电磁波，并对接收的电磁波进行滤波，放大等处理，传送至调制解调处理器进行解调。
[0077] 移动通信模块250还可以对经调制解调处理器调制后的信号放大，经天线1转为电磁波辐射出去。在一些实施例中，移动通信模块250的至少部分功能模块可以被设置于处理器210中。在一些实施例中，移动通信模块250的至少部分功能模块可以与处理器210的至少部分模块被设置在同一个器件中。
[0078] 无线通信模块260可以提供应用在电子设备上的包括WLAN(如(wireless fidelity，Wi‑Fi)网络)，蓝牙(bluetooth，BT)，全球导航卫星系统(global navigation satellite system，GNSS)，调频(frequency modulation，FM)，近距离无线通信技术(near field communication，NFC)，红外技术(infrared，IR)等无线通信的解决方案。
[0079] 其中，GNSS可以包括北斗卫星导航系统(beidou navigation satellite system，BDS)，全球定位系统(global positioning system，GPS)，全球导航卫星系统(global navigation satellite system，GLONASS)，准天顶卫星系统(quasi‑zenith satellite system，QZSS)和/或星基增强系统(satellite based augmentation systems，SBAS)。
[0080] 无线通信模块260可以是集成至少一个通信处理模块的一个或多个器件。无线通信模块260经由天线2接收电磁波，将电磁波信号调频以及滤波处理，将处理后的信号发送到处理器210。无线通信模块260还可以从处理器210接收待发送的信号，对其进行调频，放大，经天线2转为电磁波辐射出去。
[0081] 电子设备100通过GPU，显示屏194，以及应用处理器等实现显示功能。GPU为图像处理的微处理器，连接显示屏194和应用处理器。GPU用于执行数学和几何计算，用于图形渲染。处理器110可包括一个或多个GPU，其执行程序指令以生成或改变显示信息。
[0082] 显示屏194用于显示图像，视频等。该显示屏194包括显示面板。显示面板可以采用液晶显示屏(liquid crystal display，LCD)，有机发光二极管(organic light‑emitting diode，OLED)，有源矩阵有机发光二极体或主动矩阵有机发光二极体(active‑matrix organic light emitting diode，AMOLED)，柔性发光二极管(flex light‑emitting diode，FLED)，Miniled，MicroLed，Micro‑oLed，量子点发光二极管(quantum dot light emitting diodes，QLED)等。
[0083] NPU为神经网络(neural‑network，NN)计算处理器，通过借鉴生物神经网络结构，例如借鉴人脑神经元之间传递模式，对输入信息快速处理，还可以不断的自学习。通过NPU可以实现电子设备100的智能认知等应用，例如：图像识别，人脸识别，语音识别，文本理解等。
[0084] 音频模块170用于将数字音频信息转换成模拟音频信号输出，也用于将模拟音频输入转换为数字音频信号。音频模块170还可以用于对音频信号编码和解码。在一些实施例中，音频模块170可以设置于处理器110中，或将音频模块170的部分功能模块设置于处理器110中。扬声器170A，也称“喇叭”，用于将音频电信号转换为声音信号。这样，电子设备100可以播放音频数据，如，视频音乐等。
[0085] 压力传感器用于感受压力信号，可以将压力信号转换成电信号。在一些实施例中，压力传感器可以设置于显示屏194。陀螺仪传感器可以用于确定电子设备100的运动姿态。当电子设备100静止时可检测出重力的大小及方向。还可以用于识别电子设备100姿态，应用于横竖屏切换等应用。触摸传感器，也称“触控面板”。触摸传感器可以设置于显示屏194，由触摸传感器180K与显示屏194组成触摸屏，也称“触控屏”。触摸传感器用于检测作用于其上或附近的触摸操作。触摸传感器可以将检测到的触摸操作传递给应用处理器，以确定触摸事件类型。
[0086] 下面结合附图，继续以该电子设备采用虚拟A/B操作系统为例，描述本申请实施例提供的操作系统升级方法。
[0087] 在一些实施例中，上述操作系统升级可以由电子设备上安装的操作系统更新程序执行。示例性地，在线更新客户端工具(online update client apk，ouc apk)以及升级引擎(update engine)是操作系统更新程序中的两个模块。online update client apk用于获取操作系统的升级安装包，升级引擎(update engine)，用于驱动执行操作系统的升级。
[0088] 图3B所示为针对图1所示操作系统的数据存储结构进行操作系统升级的流程图。在电子设备是从静态分区(A)启动的场景下，也即，基于A操作系统运行时，电子设备按照如图3B所示的流程实现操作系统的升级。
[0089] S101，升级服务器发布系统升级包。
[0090] 在一些实施例中，上述系统升级包是用于指示将操作系统升级至目标版本的数据。目标版本与当前电子设备中运行的系统版本不同。在一些实施例中，系统升级包是全量升级包，同时系统升级包也是指示升级至节点版本的数据。
[0091] 另外，系统升级包中包括改制小包。该改制小包用于指示将电子设备的操作系统由第一制式更新为第二制式(all cn或cmcc cn)。该改制小包在电子设备进入恢复(Recovery)模式的情况下被使用。
[0092] 示例性地，该系统升级包的数据结构如下：
[0093] demochange.tag；
[0094] META‑INF；
[0095] payload.bin；
[0096] payload_properties.txt；
[0097] SOFTWARE_VER.mbn；
[0098] update_base_demochange.zip；
[0099] vendor_country.mbn；
[0100] VERSION.mbn；
[0101] 其中，上述demochange.tag是改制标签，用于指示该系统升级包可用于将演示样机改制为商用机。上述META‑INF是签名信息，用于对系统升级包进行签名校验。上述payload.bin包括能将操作系统升级至目标版本的数据。上述payload_properties.txt是携带FILE_HASH、FILE_SIZE、METADATA_HASH等参数的文件。上述SOFTWARE_VER.mbn为软件版本文件。目标版本的VC信息(如，all cn)以vendor_country.mbn文件的形式保存在系统升级包的根目录中。上述update_base_demochange.zip为改制小包。
[0102] 示例性地，该改制小包，也即update_base_demochange.zip的数据结构如下：
[0103] Ptable；
[0104] Image；
[0105] super_metadata.img；
[0106] META‑INF；
[0107] OTA_update.tag；
[0108] PTABLE_SUPER.mbn；
[0109] skipauth_pkg.tag；
[0110] vendor_country.mbn；
[0111] 其中，Ptable是目标版本的总分区表，用于描述升级到目标版本后，存储器件(ROM)的分区部署。定义每个分区的起始地址和大小。示例性地，Ptable包括Common分区、系统分区和用户数据分区(Userdata)在存储空间中的起始地址和结束地址。例如下表1所示：
[0112] 表1
[0113]
[0114] 另外，Image包括super_metadata.img，该super_metadata.img是目标版本对应的super子分区表，用于描述升级到目标版本后，super中各子分区的起始地址和结束地址。该改制小包中也包括META‑INF，同样可用于签名校验。目标版本的VC信息(如，all cn)还可以采用vendor_country.mbn文件的形式保存于改制小包的根目录下。
[0115] 另外，改制小包中还可以包括userdata.img，metadata.img等空镜像。
[0116] 在一些实施例中，电子设备依次加载基础分区(Common)、静态分区(A)以及动态分区(Super)，从静态分区(A)启动。S101可以在电子设备启动后执行，也可以在电子设备启动前执行。电子设备在从静态分区(A)启动的状态下，online update client apk执行S102。
[0117] S102，online update client apk获取系统升级包，该系统升级包中包括改制小包、目标版本的VC信息。
[0118] 示例性地，在一种可行的实现方案中，电子设备定期向升级服务器发起搜包请求，搜包请求包含电子设备当前运行的操作系统的版本号(例如版本1.1)；升级服务器根据搜包请求中的操作系统版本号，检索当前是否存在更新版本号的系统升级包(例如版本1.2)；当存在更新版本的系统升级包时，升级服务器向电子设备反馈系统升级包(例如，版本1.2的全量系统升级包)的下载地址；电子设备根据系统升级包的下载地址进行下载。
[0119] 又示例性地，在另一种可行的实现方案中，升级服务器也可在得到新版本的系统升级文件之后，主动向电子设备推送。
[0120] 在本申请实施例中，online update client apk获取到的系统升级包，可以指示将电子设备从演示版本改制为商用版本，也即，该系统升级包中包括改制小包及目标版本的VC信息(如，all cn)。
[0121] 在一些实施例中，S102之后，online update client apk可以将系统升级包下载并保存到用户数据分区(Userdata)。例如，online update client apk定期向升级服务器发起搜包请求，搜包请求包含设备当前操作系统版本号(例如版本1.1)、设备SN号、产品型号、制式等信息(例如版本1.1)；升级服务器根据搜包请求中的操作系统版本号，检索安装包服务器上是否存在更新版本号的系统升级包(例如版本1.2)；当存在更新版本的系统升级包时，升级服务器向online update client apk反馈系统升级包(例如，由版本1.1升级到版本1.2的系统升级包)的下载地址(例如，URL地址)以及系统升级安装包对应的filelist文件；online update client apk根据系统升级包的下载地址从安装包服务器下载系统升级包。
[0122] 当online update client apk获取到系统升级包后，其启动升级引擎(update engine)，由升级引擎(update engine)根据系统升级包进行操作系统的升级。
[0123] 也即，online update client apk执行S103，触发update engine进入升级流程。
[0124] 作为一个示例，当online update client apk获取到系统升级包后，online update client apk设置升级引擎(update engine)的启动属性，将启动属性设置为true。常驻操作系统后台的服务servicemanger会监控升级引擎(update engine)的启动属性，当servicemanger检测到升级引擎(update engine)的启动属性为true时，servicemanger启动升级引擎(update engine)。
[0125] online update client apk通过binder通信获取升级引擎(update engine)的状态，当online update client apk确认升级引擎(update engine)成功启动时，online update client apk向升级引擎(update engine)传递升级参数(例如，当前的升级操作是文件更新操作还是文件落盘操作)，触发升级引擎(update engine)进入升级流程。
[0126] 在升级流程中，update engine执行S104，校验操作系统升级包。
[0127] 示例性地，可以是校验系统升级包中的META‑INF(也即，数字签名)是否合法，确认系统升级包是否为合法的升级包。具体实现细节，可参考相关技术，在此不再赘述。
[0128] 在校验成功的情况下，update engine执行S105，在运行A系统的情况下，基于系统升级包，启动针对B系统的升级。
[0129] 在一些实施例中，升级电子设备的B系统(又称为第二操作系统)，是虚拟A/B升级流程的一部分。换句话说，在电子设备运行A系统(又称为第一操作系统)的情况下，上述S105也可以是启动执行虚拟A/B升级流程。
[0130] 示例性地，执行虚拟A/B升级的流程如图4所示。如图4所示，其包括步骤：
[0131] S401，电子设备从用户数据分区(Userdata)读取已保存的系统升级包，根据系统升级包针对静态分区(B)进行数据写入操作以升级静态分区。
[0132] 例如，在系统升级包中包含版本1.2的静态分区的数据，又称为第一升级数据，update engine将版本1.2的静态分区的数据覆写到静态分区(B)中。
[0133] S402，电子设备根据系统升级包在用户数据分区(Userdata)创建虚拟动态分区，在虚拟动态分区写入动态分区(Super)的升级数据。
[0134] 例如，在系统升级包中包含版本1.2的动态分区的数据，又称为第二升级数据，设备在虚拟动态分区中写入版本1.2的动态分区(Super)的数据。在其他可能的实施例中，在虚拟A/B升级方案中，针对动态分区(Super)，采用增量升级方式。在升级过程中，用户数据分区(Userdata)的虚拟动态分区中保存的并不是升级后新版本的动态分区(Super)的全部文件，而是旧版本的动态分区(Super)中需要升级的数据在升级后的升级结果。即，用户数据分区(Userdata)的虚拟动态分区中保存的是动态分区的更新数据。
[0135] 以system子分区为例，假设在版本1.1中，system子分区中的数据可以分为system1、system2两部分。从版本1.1升级到版本1.2，数据system2没有发生变化，数据syetem1被升级为system3。那么，在S402中，设备在用户数据分区(Userdata)创建虚拟动态分区，在虚拟动态分区中写入数据system3。
[0136] 例如，版本1.1升级到版本1.2的系统增量升级安装包包含版本1.1升级到版本1.2的动态分区(Super)更新数据，该动态分区(Super)更新数据包含数据system3。
[0137] 进一步的，在虚拟A/B升级方案中，基于快照技术(snapshot)实现动态分区(Super)的增量升级。具体的，用户数据分区(Userdata)的虚拟动态分区中，采用写时拷贝(Copy‑On‑Write，COW)文件保存动态分区(Super)的升级数据。
[0138] 具体的，用户数据分区(Userdata)中保存的动态分区(Super)的升级数据包含多个COW文件，每个COW文件对应一个动态分区(Super)的子分区，COW文件的命名与其所针对的动态分区(Super)子分区相对应。
[0139] 在系统升级包中，动态分区(Super)的升级数据的COW文件以二进制代码形式压缩保存。在系统升级包中，每个COW文件根据其所针对的动态分区(Super)子分区所命名。例如，针对system子分区的COW文件被命名为system‑cow‑img.img.0000。
[0140] 在S402中，电子设备解包系统升级包以获取所有的COW文件，为每个COW文件附加A/B分区标记。具体的，当电子设备当前从静态分区(A)启动时，可以理解为电子设备当前运行操作系统所加载的动态分区(Super)为动态分区(A)。在升级操作系统时，用户数据分区(Userdata)中创建的虚拟动态分区是针对动态分区(B)。因此，为COW文件附加对应动态分区(B)的名称标记_b。例如，为system‑cow‑img.img.0000附加_b生成system_b‑cow‑img.img.0000。
[0141] 进一步的，在S402中，在用户数据分区(Userdata)中创建Update文件夹，将重命名的COW文件保存到Update文件夹下。例如，在一应用场景中，在向用户数据分区(Userdata)写入COW文件后，用户数据分区(Userdata)的Update文件夹中包含下述文件：
[0142] system_b‑cow‑img.img.0000；
[0143] system_ext_b‑cow‑img.img.0000；
[0144] vendor_b‑cow‑img.img.0000；
[0145] product_b‑cow‑img.img.0000；
[0146] cust_b‑cow‑img.img.0000；
[0147] odm_b‑cow‑img.img.0000。
[0148] 具体的，COW文件中包含COW文件自身的COW文件地图(快照map)以及升级数据。
[0149] COW文件地图(快照)与COW文件所针对的动态分区(Super)的子分区的文件地图相对应。动态分区(Super)的子分区的文件地图用于描述当前版本的操作系统(本次升级之前的版本，例如，版本1.1)动态分区(Super)的子分区中的所有文件以及各个文件的保存地址。
[0150] COW文件中的升级数据为相较于当前版本的子分区数据，新版本的子分区数据中被更新的文件；COW文件自身的COW文件地图则用于描述被更新的文件与当前版本的子分区中的文件间的对应关系以及被更新的文件的保存地址。
[0151] 基于动态分区(Super)的子分区的文件地图以及COW文件中的COW文件地图，就可以使用COW文件中的升级数据替换动态分区(Super)的子分区中的对应文件，从而实现动态分区(Super)数据的升级。具体的，在需要获取动态分区(Super)的子分区的文件地图时，可以基于snapshot对动态分区(Super)的子分区的数据进行快照操作以生成动态分区(Super)的子分区的文件地图。也可以在制作系统升级包时，预先生成动态分区(Super)的子分区的文件地图，将该文件地图加入到COW文件中。
[0152] 以system子分区为例，假设system子分区中按照以下路径保存数据：
[0153] /system/app/A0.XXX；
[0154] /system/app/A1.XXX；
[0155] /system/app/A2.XXX；
[0156] /system/B0.XXX；
[0157] /system/B1.XXX；
[0158] /system/user/C0.XXX；
[0159] /system/user/C1.XXX；
[0160] /system/user/C2.XXX；
[0161] /system/user/C3.XXX。
[0162] system子分区的文件地图可以是：
[0163] /system/app/A0.XXX：024010～024013；
[0164] /system/app/A1.XXX：024014～024017；
[0165] /system/app/A2.XXX：024018～024020；
[0166] /system/B0.XXX：024021～024026；
[0167] /system/B1.XXX：024027～024028；
[0168] /system/user/C0.XXX：024029～024032；
[0169] /system/user/C1.XXX：024033～024035；
[0170] /system/user/C2.XXX：024036～024040；
[0171] /system/user/C3.XXX：024041～024044。
[0172] 文件名后的数值(例如，“/system/app/A0.XXX：024010～024013”中的024010～024013)为该文件在动态分区(Super)的system子分区的物理保存地址(块地址)。
[0173] 假设当前操作系统升级需要更新数据/system/app/A2.XXX以及/system/user/C2.XXX。
[0174] 可以视为：
[0175] /system/app/A2.XXX以及/system/user/C2.XXX为system子分区数据的system1部分；
[0176] /system/app/A0.XXX、/system/app/A1.XXX、/system/B0.XXX、/system/B1.XXX、/system/user/C0.XXX、/system/user/C1.XXX以及/system/user/C3.XXX为system子分区数据的system2部分。
[0177] 那么，针对system子分区的COW文件(system_b‑cow‑img.img.0000)就包含最新版的/system/app/A2.XXX以及/system/user/C2.XXX。
[0178] 可以视为，最新版的/system/app/A2.XXX以及/system/user/C2.XXX为system3。升级目标是使用system3更新掉system1。
[0179] 当COW文件中的更新数据的大小与其所要更新的原始数据的大小一致，并且，COW文件中的更新数据在数据更新后在子分区中的保存位置与其所要更新的原始数据在子分区中的保存位置一致时，COW文件(system_b‑cow‑img.img.0000)自身的COW文件地图可以为：
[0180] /system/app/A2.XXX：
[0181] Map1(原super分区中待更新数据的地址)：起始地址address start：024018(相对于system起始地址的偏移量)；偏移量大小size：2(即024018～024020地址段的数据)[0182] Map2(cow文件中存储的更新数据的地址)：起始地址address start：045033(相对于cow文件存储的起始地址的偏移量)；偏移量大小size：2(即045033～045035地址段的数据)；
[0183] /system/user/C2.XXX：
[0184] Map1(原super分区中待更新数据的地址)：起始地址address start：024036(相对于system起始地址的偏移量)；偏移量大小size：4(即024036～024040地址段的数据)[0185] Map2(cow文件中存储的更新数据的地址)：起始地址address start：045036(相对于cow文件存储的起始地址的偏移量)；偏移量大小size：4(即045036～045040地址段的数据)。
[0186] 当COW文件中的更新数据的大小与其所要更新的原始数据的大小不一致时，COW文件(system_b‑cow‑img.img.0000)自身的COW文件地图可以为：
[0187] /system/app/A2.XXX：
[0188] Map1.1(原super分区中待更新数据的地址)：起始地址address start：024018(相对于system起始地址的偏移量)；偏移量大小size：2(即024018～024020地址段的数据)[0189] Map2.1(cow文件中存储的，需要覆盖Map1.1地址的更新数据的地址)：起始地址address start：045033(相对于cow文件存储的起始地址的偏移量)；偏移量大小size：2(即045033～045035地址段的数据)；
[0190] Map1.2(cow文件中更新数据超出待更新数据大小的那一部分在原super分区中的待写入地址)：起始地址address start：025018(相对于system起始地址的偏移量)；偏移量大小size：1(即025018～025020地址段的数据)
[0191] Map2.2(cow文件中存储的，需要覆盖Map1.2地址的更新数据的地址)：起始地址address start：046033(相对于cow文件存储的起始地址的偏移量)；偏移量大小size：2(即046033～046035地址段的数据)。
[0192] 在接下来的说明书描述中，为便于描述，仅以当COW文件中的更新数据的大小与其所要更新的原始数据的大小一致，并且，COW文件中的更新数据在数据更新后在子分区中的保存位置与其所要更新的原始数据在子分区中的保存位置一致的应用场景进行举例说明。
[0193] 在上述例子中，地址段(045033～045035以及045036～045040)分别为COW文件(system_b‑cow‑img.img.0000)中最新版的/system/app/A2.XXX以及/system/user/C2.XXX在用户数据分区(Userdata)的物理保存地址(块地址)。
[0194] 这样，如果使用地址045033～045035上的A2.XXX替换掉地址024018～024020上的A2.XXX，并且，使用地址045036～045040上的C2.XXX替换掉地址024036～024040上的C2.XXX，就可以完成动态分区(Super)的system子分区的数据升级。
[0195] 进一步的，在S402中，在将COW文件写入用户数据分区(Userdata)后，还需要对动态分区(Super)+COW文件进行整体校验，校验动态分区(Super)+COW文件的有效性，验证当前版本的动态分区(Super)数据+COW文件的合成结果是否为新版本的动态分区(Super)数据。
[0196] 在一些示例中，以从1.1版本升级到1.2版本为例，计算动态分区(Super)中不需要升级的数据(从版本1.1到版本1.2未发生变化的数据)与COW文件中升级数据(从版本1.1到版本1.2需要升级的数据)的合成结果的哈希值，判断该哈希值与1.2版本中动态分区(Super)的完整数据的哈希值是否一致，如果一致，则说明COW文件有效；如果不一致，则说明COW文件无效，升级失败，中断update engine对应的进程并报错；其中，1.2版本中动态分区(Super)的完整数据的哈希值被保存在系统升级包中。
[0197] 具体的，在校验过程中，基于snapshot合并动态分区(Super)+COW文件。在snapshot的实现过程中，动态分区(Super)与COW文件的合并并不是物理意义上的合并，而是将COW文件中子分区的整体文件地图与COW文件自身的COW文件地图进行合并，生成新版本的子分区数据的文件地图。
[0198] 例如，将system子分区的文件地图：
[0199] /system/app/A0.XXX：024010～024013；
[0200] /system/app/A1.XXX：024014～024017；
[0201] /system/app/A2.XXX：024018～024020；
[0202] /system/B0.XXX：024021～024026；
[0203] /system/B1.XXX：024027～024028；
[0204] /system/user/C0.XXX：024029～024032；
[0205] /system/user/C1.XXX：024033～024035；
[0206] /system/user/C2.XXX：024036～024040；
[0207] /system/user/C3.XXX：024041～024044。
[0208] 与COW文件地图：
[0209] /system/app/A2.XXX：
[0210] Map1：address start：024018；size：2(即024018～024020地址段的数据)[0211] Map2：address start：045033；size：2(即045033～045035地址段的数据)；
[0212] /system/user/C2.XXX：
[0213] Map1：address start：024036；size：4(即024036～024040地址段的数据)[0214] Map2：address start：045036；size：4(即045036～045040地址段的数据)。
[0215] 合并。则得到system子分区的新版本的文件地图：
[0216] /system/app/A0.XXX：024010～024013；
[0217] (指向动态分区(Super)中/system/app下的A0.XXX)
[0218] /system/app/A1.XXX：024014～024017；
[0219] (指向动态分区(Super)中/system/app下的A1.XXX)
[0220] /system/app/A2.XXX：045033～045035；
[0221] (指向用户数据分区(Userdata)中/Update/system_b‑cow‑img.img.0000中的A2.XXX)
[0222] /system/B0.XXX：024021～024026；
[0223] (指向动态分区(Super)中/system下的B0.XXX)
[0224] /system/B1.XXX：024027～024028；
[0225] (指向动态分区(Super)中/system下的B1.XXX)
[0226] /system/user/C0.XXX：024029～024032；
[0227] (指向动态分区(Super)中/system/user下的C0.XXX)
[0228] /system/user/C1.XXX：024033～024035；
[0229] (指向动态分区(Super)中/system/user下的C1.XXX)
[0230] /system/user/C2.XXX：045036～045040；
[0231] (指向用户数据分区(Userdata)中/Update/system_b‑cow‑img.img.0000中的C2.XXX)
[0232] /system/user/C3.XXX：024041～024044。
[0233] (指向动态分区(Super)中/system/user下的C3.XXX)
[0234] 在新版本的system子分区的文件地图中，/system/app/A2.XXX的保存地址并不是指向存储器上动态分区(Super)上的/system/app/A2.XXX，而是指向存储器上用户数据分区(Userdata)中system_b‑cow‑img.img.0000中的A2.XXX；/system/user/C2.XXX的保存地址并不是指向存储器上动态分区(Super)上的/system/user/C2.XXX，而是指向存储器上用户数据分区(Userdata)中system_b‑cow‑img.img.0000中的C2.XXX。
[0235] 在校验过程中，按照上述合成方式，获取动态分区(Super)的所有子分区的新版本的文件地图(如果用户数据分区(Userdata)中并未写入某个子分区的对应COW文件，则直接以该子分区的文件地图为新版本的文件地图)。将所有子分区的新版本的文件地图组合生成动态分区(Super)的新版本的文件系统。
[0236] 基于动态分区(Super)的新版本的文件系统读取数据，读取动态分区(Super)的新版本的文件系统所包含的所有文件并计算哈希值。
[0237] 当COW文件有效时，将基础分区(Common)的元数据分区(/metadata)中的落盘状态信息由“已落盘(merged)”改为“未落盘(wait for merge)”。落盘状态信息用于表示当前是否存在需要落盘到动态分区(Super)的COW文件。具体的，落盘状态信息包含针对动态分区(Super)的整体标识以及针对每个子分区的子分区标识。当整体标识为“已落盘(merged)”时，代表动态分区(Super)的所有子分区均不需要进行落盘操作；当整体标识为“未落盘(wait for merge)”时，代表动态分区(Super)的一个或多个子分区需要进行落盘操作；当子分区标识为“已落盘(merged)”时，代表该子分区不需要进行落盘操作；当子分区标识为“未落盘(wait for merge)”时，代表该子分区需要进行落盘操作。
[0238] 在一些实施例中，上述S402之后，电子设备可以进行卡槽切换。该卡槽切换操作不会立即改变当前运行的操作系统，也就是，电子设备不会立即将运行的A系统切换为B系统，在电子设备下次启动时，加载B系统所对应的系统数据，从而，运行于B系统。
[0239] 示例性地，电子设备的Common分区中包括MBR，该MBR中配置有启动顺序标识。电子设备启动操作系统时，可以从MBR中读取启动顺序标识，并依据动顺序标识，确定所需加载的静态分区(静态分区A或静态分区B)，也即，确定启动A系统还是启动B系统。上述卡槽切换可以是电子设备可以改写MBR的启动顺序标识，如，将启动顺序标识由A改写为B，这样，电子设备重启后，可以加载静态分区(B)的数据，可以切换至运行B系统。另外，在其他可能的实施例中，MBR也可以存储于其他分区中，如，静态分区(A)和静态分区(B)中均配置有MBR，两个静态分区内的MBR中所配置的启动顺序标识相同。
[0240] S403，电子设备重启。
[0241] 在一些实施例中，退出当前的操作系统，切断设备电源，再次开启设备电源。
[0242] S404，电子设备依次加载基础分区(Common)、静态分区(B)。
[0243] 在一些实施例中，在重启过程中，电子设备识别到启动顺序标识为B，那么电子设备启动顺序由从静态分区(A)启动变更为从静态分区(B)启动。
[0244] 例如，在重启电子设备之前，改写主引导记录(Master Boot Record，MBR)的启动顺序标识，将启动顺序标识由A改写为B。在电子设备上电后，当电子设备读取到启动顺序标识为A，电子设备从静态分区(A)启动，启动过程中加载静态分区(A)；当电子设备读取到启动顺序标识为B，电子设备从静态分区(B)启动，启动过程中加载静态分区(B)。
[0245] 例如，电子设备首先加载基础分区(Common)。在加载基础分区(Common)的过程中，电子设备读取基础分区(Common)中的启动标记；当基础分区(Common)中的启动标记为(A)时，电子设备在加载基础分区(Common)之后会加载静态分区(A)，从而从静态分区(A)启动；当基础分区(Common)中的启动标记为(B)时，电子设备在加载基础分区(Common)之后会加载静态分区(B)，从而从静态分区(B)启动。
[0246] 在S404中，电子设备读取基础分区(Common)中的启动标记。基础分区(Common)中的启动标记为(B)，电子设备在加载基础分区(Common)之后加载静态分区(B)，从静态分区(B)启动。
[0247] S405，电子设备加载动态分区(Super)以及用户数据分区(Userdata)的虚拟动态分区。
[0248] 具体的，电子设备读取元数据(/metadata)中的落盘状态信息，基于落盘状态信息确定是否需要从用户数据分区(Userdata)的指定路径中检索COW文件，并采用snapshot合并加载动态分区(Super)以及COW文件。
[0249] 进一步的，在S405中，电子设备并不加载动态分区(Super)以及用户数据分区(Userdata)中的全部COW文件，而是根据操作系统运行需求加载对应的文件。具体的，在S405中，电子设备根据操作系统运行需求确定需要加载的文件，基于snapshot从动态分区(Super)或虚拟动态分区中的COW文件中提取对应的文件进行加载。
[0250] 具体的，在S405中，当动态分区(Super)的子分区首存在对应的COW文件时，先基于snapshot生成动态分区(Super)各个子分区的新版本的文件地图。生成新版本的文件地图的过程可以参照S402。电子设备根据操作系统运行需求确定需要加载的文件，基于动态分区(Super)子分区的新版本的文件地图进行文件加载。
[0251] 例如，操作系统运行需求加载system子分区下目录user(/system/user)中的所有数据。电子设备读取元数据(/metadata)中的落盘状态信息，落盘状态信息中system子分区的子分区标识为“未落盘(wait for merge)”，因此，电子设备在用户数据分区(Userdata)中/Update下搜索COW文件，在Update下搜索到COW文件system_b‑cow‑img.img.0000后，基于snapshot，根据system_b‑cow‑img.img.0000中的COW文件的文件地图生成system子分区的新版本的文件地图。按照system子分区的新版本的文件地图中/system/user下所有文件的保存地址进行数据加载，例如，根据system子分区的新版本的文件地图中：
[0252] /system/user/C0.XXX：024029～024032；
[0253] /system/user/C1.XXX：024033～024035；
[0254] /system/user/C2.XXX：045036～045040；
[0255] /system/user/C3.XXX：024041～024044。
[0256] 加载地址024029～024032处的C0.XXX、地址024033～024035处的C1.XXX、地址045036～045040处的C2.XXX以及地址024041～024044处的C3.XXX。
[0257] 在一些示例中，在加载system子分区下目录user(/system/user)中的所有数据时，当落盘状态信息中system子分区的子分区标识为“已落盘(merged)”时，电子设备就不会在用户数据分区(Userdata)中/Update下搜索COW文件，而是直接加载system子分区下目录user(/system/user)中的所有数据。
[0258] 在另一些示例中，在加载system子分区下目录user(/system/user)中的所有数据时，当落盘状态信息中system子分区的子分区标识为“未落盘(wait for merge)”时，如果电子设备在用户数据分区(Userdata)中/Update下未搜索到对应system子分区的COW文件时，则说明升级过程中数据写入错误(COW文件写入错误或者落盘状态信息写入错误)，此时电子设备回滚系统并报错。
[0259] 进一步的，在S405中，在加载文件之前，电子设备还需要对加载文件进行校验。不同于S402，在S405中，不对动态分区(Super)+COW文件进行整体验证，而是仅对需要加载的文件进行验证。例如，基于dmverity进行校验(dm‑verity是dm(device mapper)的一个目标(target)，是一个虚拟块设备，专门用于文件系统的校验)。校验成功则加载文件，校验失败则重启设备，回滚系统或者尝试再次加载文件。
[0260] 上述S401～S405为进行A/B升级方案的一部分。在电子设备执行A/B升级的过程中，电子设备还可以执行S106～S109。
[0261] 比如，可以是电子设备执行了S402之后，流程进入S106。然后，在电子设备执行完S107～S109之后，流程进入S403(也即，S110)，进行重启。在重启成功之后，电子设备执行S404和S405，然后，流程进入S111，触发merge流程，也即，进入A/B升级方案的另一部分。
[0262] 再例如，可以是电子设备执行S401时，异步执行S106～S109，当然，S109需要在S403(也即，S110)之前执行完毕。这样，电子设备重启之后，电子设备执行S404和S405，然后，流程进入S111，触发merge流程。
[0263] 再例如，可以是电子设备执行了S402之后，并执行卡槽切换之后，执行S106，这样，在执行完S109之后，可以触发电子设备重启，也即，执行S403(或称为，S110)。
[0264] S106，update engine检测到系统升级包中存在改制小包。
[0265] 在一些实施例中，update engine从系统升级包中检测出改制小包的包名，如update_base_demochange.zip，可以确定检测到改制小包。在另一些实施例中，update engine从系统升级包中检测到改制标签，如，demochange.tag，可以确定系统升级包中存在改制小包。
[0266] S107，update engine从系统升级包中，读取目标版本的VC信息。
[0267] 在一些实施例中，系统升级包中包括写有VC信息的文件，如vendor_country.mbn文件，又称为第二制式文件，在此场景下，解析系统升级包之后，可以从vendor_country.mbn文件中获取目标版本的VC信息，又称为第二制式信息。
[0268] S108，update engine将读取到的VC信息写入oeminfo_vc_tmp。
[0269] 在一些实施例中，上述oeminfo_vc_tmp是oeminfo子分区中的临时文件，占据oeminfo子分区中的临时存储空间。oeminfo_vc_tmp与oeminfo子分区中的oeminfo_vc文件不同。上述oeminfo_vc文件中包括系统升级前的VC信息(如，版本1.1的VC信息)。可以理解的，oeminfo_vc_tmp与oeminfo_vc文件，在oeminfo子分区中实际占据的物理地址不同。另外，oeminfo_vc文件所对应的存储地址，是电子设备加载VC信息的地址。这样，电子设备加载系统数据时，会加载oeminfo_vc文件而不会加载oeminfo_vc_tmp。
[0270] 另外，可以理解地，上述S108仅为临时存放系统升级包中目标版本的VC信息的一种示例方式，还可以存在其他的实现方式，例如，将目标版本的VC信息写入可被读取到的其他临时存储区等。本申请实施例对此不作限定。
[0271] S109，update engine将改制小包解压到cache/update目录，该改制小包中包括ptable和super_metadata.img。
[0272] 在一些实施例中，上述cache/update目录是cache子分区下的目录，又称为第一存储区域，该cache子分区属于Common分区。另外，该cache子分区是Recovery模式下能够访问存储分区。解压改制小包到cache/update目录之后，该cache/update目录下包括ptable和super_metadata.img。
[0273] S110，update engine触发电子设备重启。
[0274] 在一些实施例中，退出当前的操作系统，切断设备电源，再次开启设备电源，该S110与前述S403为同一步骤，又称为，第一次重启。在重启成功的情况下，电子设备执行S404和S405。在执行完S405之后，确定当前为未落盘状态的情况下，然后流程进入S111。
[0275] S111，update engine触发merge流程。
[0276] 在一些实施例中，重启之后，新系统生效，也即，更新后的B系统生效时，启动merge流程。如图5所示，merge流程包括：
[0277] S501，电子设备成功启动，进入用户交互界面。
[0278] S502，电子设备在后台将虚拟动态分区的数据合并到动态分区(Super)。
[0279] 也就是，电子设备在后台将虚拟动态分区的数据落盘到动态分区(Super)。在本申请实施例中，落盘操作指的是，在操作系统升级过程中，将用户数据分区(Userdata)上虚拟动态分区中保存的动态分区(Super)升级文件(COW文件)写入到动态分区(Super)中，使得动态分区(Super)的文件完成数据升级，以便电子设备在下次启动时不需要加载动态分区(Super)和虚拟动态分区，只需加载动态分区(Super)就可以完成电子设备启动。
[0280] 在一些示例中，电子设备在启动成功后进行开机广播，开机广播后开启update engine对应的进程。update engine对应的进程读取基础分区(Common)的元数据(/metadata)中的落盘状态信息，如果落盘状态信息为“已落盘(merged)”，则设备进入正常运行模式。
[0281] 如果落盘状态信息为“未落盘(wait for merge)”，update engine对应的进程将用户数据分区(Userdata)中的COW文件落盘到动态分区(Super)中。
[0282] 在一些实施例中，update engine对应的进程将用户数据分区(Userdata)中的COW文件中的升级数据写入到动态分区(Super)中的对应地址上，使得动态分区(Super)中的全部数据均为升级后的新版本的数据。
[0283] 例如，基于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上。
[0284] 在此之后update engine对应的进程删除用户数据分区(Userdata)中的COW文件，将存储空间归还给用户数据分区(Userdata)；并且，将基础分区(Common)的元数据(/metadata)中的落盘状态信息由“未落盘(wait for merge)”改为“已落盘(merged)”。
[0285] 在S401中，静态分区升级的数据操作是针对静态分区(B)中的操作系统数据的，其并不会影响到当前启动的静态分区(A)的操作系统数据；并且，在S402中，动态分区升级的数据操作是在用户数据分区(Userdata)中所创建的虚拟动态分区上完成的，其并不会影响到当前挂载的动态分区(Super)。因此，在整个操作系统升级的过程中，用户可以正常使用设备；并且，在S402完成后，设备并不需要立即重启，可以由用户自行选择重启时机；这样，操作系统的升级过程并不会对用户的正常手机操作产生影响，从而大大提高了用户体验。这样，针对动态分区(Super)，仅在需要进行升级时才会在用户数据分区(Userdata)上创建虚拟动态分区，因此有效提高了数据存储空间利用率。
[0286] 在一些实施例中，merge流程结束之后，super分区的version定制子分区内数据所占空间变小，同时，preload预装子分区的位置不变，此时version和preload之间会形成free空间(无法实际利用的存储空间)，merge结束，操作系统的数据结构如图6所示，version子分区的起始地址不变，结束地址变小，这样，version子分区所占的物理存储空间缩小。Preload子分区的起始地址和结束地址不变，这样，version子分区和Preload子分区之间，将会出现闲置的物理存储区域(也即，free空间)。
[0287] S112，update engine将B系统的静态分区复制到A系统的静态分区中。
[0288] 在一些实施例中，上述S112仅为一种更新静态分区(A)的方式示例，本申请实施例中，还可以存在其他可能的实现方式，例如，update engine可以利用系统升级包，更新静态分区(A)中的数据，本申请实施例对此不作具体限定。
[0289] S113，update engine将oeminfo_vc_tmp中的VC信息写入oeminfo子分区中的oeminfo_vc文件。
[0290] 在一些实施例中，oeminfo_vc_tmp中存储的VC信息，是从系统升级包中读取到的目标版本的VC信息(如，all cn)，该VC信息与电子设备中原有的VC信息(也即，demo cn，又称为第一制式信息)不同，也即，oeminfo_vc_tmp中的VC信息与oeminfo_vc文件中记录的VC信息不同。该oeminfo_vc文件可以称为第一制式文件。这样，在将目标版本的VC信息(如，all cn)写入oeminfo_vc文件之后，可以覆盖oeminfo_vc文件中原有的VC信息(也即，demo cn)，从而，实现制式信息的变更。上述过程又称为将第一制式信息修改为第二制式信息。
[0291] 另外，上述oeminfo子分区属于Common分区，操作系统启动的过程中，需从oeminfo子分区的oeminfo_vc文件中读取VC信息。可见，通过改变oeminfo_vc文件中的VC信息，可以实现对电子设备的制式改变。
[0292] 在电子设备完成制式改变之后，还需要进一步改善存储空间利用率较低的问题。
[0293] 在本申请实施例中，如图3B所示，还包括：
[0294] S114，update engine在检测到cache/update目录中包括改制小包的情况下，在cache/recovery/command文件中，写入指示改制升级的数据。
[0295] 示例性地，该指示改制升级的数据可以是指示改制小包存储路径的信息，如，在改制小包存储于cache/update目录的情况下，指示改制小包存储路径的信息可以是“update_package＝/cache/update/update_base_demochange.zip”。这样，电子设备进入Recovery模式之后，便可以依据该存储路径查找到改制小包。
[0296] 在另一些实施例中，还可以通过其他方式，使进入Recovery模式之后，可以获取到改制小包，例如，还可以是在检测到cache/update目录中包括改制小包的情况下，上述指示改制升级的数据还可以是改制小包本身，也即，检测到cache/update目录中包括改制小包之后，将改制小包移动至cache/recovery目录下。
[0297] S115，update engine触发重启，并指示进入Recovery模式。
[0298] 在一些实施例中，上述重启又称为第二次重启，另外，在指示进入Recovery模式之后，启用Recovery进程，流程进入S116。
[0299] S116，Recovery进程校验系统升级包的完整性。
[0300] 在一些实施例中，上述S116可参考相关技术中验证升级包的完整性的实现方式，在此不再赘述。
[0301] S117，Recovery进程依据cache/recovery/command文件，确定当前为改制升级场景时，配置全局变量vcdemo。
[0302] 在一些实施例中，Recovery进程可以解析cache/recovery/目录中的command文件，得到一存储路径，此时，Recovery进程依据该存储路径，访问对应的存储空间。在该存储空间中存在数据包的情况下，如果确定数据包的包名与预定义的改制小包包名相同，确定当前为改制升级场景。又例如，如果确定数据包中存在指示改制的标识的情况下，也可以确定当前为改制升级场景。
[0303] 在一些实施例中，确定当前为改制升级场景时，Recovery进程在指定的存储位置(如，在Recovery进程可访问的缓存，如称为第二存储区域)中，写入全局变量vcdemo(又称为第一指示信息)。
[0304] 可以理解的，配置全局变量vcdemo，指示本次升级为改制升级，仅为一种实现方式。在其他实施例中，还可以通过其他方式，提醒Recovery进程执行改制升级的后续流程，如，由电子设备主动查询cache/update目录中是否有改制小包等。
[0305] S118，在识别到变量vcdemo的情况下，Recovery进程执行preload数据迁移。
[0306] 在一些实施例中，上述preload数据是merge流程结束后，存储于preload子分区内的数据。上述preload数据迁移的原理如图7所示：电子设备先将preload子分区内的数据以及super分区的尾部数据，复制到userdata分区的尾部。其中，super分区的尾部数据是指存储于preload子分区之后的数据，比如，图7中标注的3M尾部数据。然后，再将userdata分区中的preload子分区内的数据以及super分区的尾部数据再次写入super分区。示例性地，可以先获取改制小包中的super_metadata.img，又称为第二分区表。再从super_metadata.img中获取指示的preload子分区的起始地址(又称为第二地址)。可以理解的，super_metadata.img中preload子分区的起始地址与free空间的起始地址相同，也即，与merge之后version定制子分区的结束地址相邻，这样，super分区中的free空间可以被利用上。
[0307] 作为一种实现方式，执行preload数据迁移的过程如图8所示，包括：
[0308] S801，Recovery进程从super分区中读取super头信息。
[0309] 在一些实施例中，上述super头信息可以存储于super分区的顶部1M的存储空间内。上述super头信息包括用于描述当前super分区中各子分区的起始地址及大小的数据。换句话说，super头信息中包括第一分区表，第一分区表包括第一地址，第一地址指示第一子分区在所述存储器中的起始物理地址。例如，merge之前，super头信息指示version子分区和preload子分区的起始地址及大小的数据，如下所示：
[0310] Super：17295360..34072576：version_b(16777216sectors)；
[0311] Super：34072576..37152768：preload_b(3080192sectors)；
[0312] 也就是，merge之前，version子分区的起始地址是“物理地址17295360”，结束地址是“物理地址34072576”，version子分区的大小为16777216sectors，也即，version子分区大约占据了8‑9G的存储空间。preload子分区的起始地址是“物理地址34072576”，结束地址是“物理地址37152768”，version子分区的大小为3080192sectors。
[0313] 另外，merge之后，super头信息指示version子分区和preload子分区的起始地址及大小的数据，如下所示：
[0314] Super：17295360..17360896：version_b(65536sectors)；
[0315] Super：34072576..37152768：preload_b(3080192sectors)；
[0316] 可见，merge之后，version子分区的起始地址是“物理地址17295360”，结束地址是“物理地址17360896”，version子分区的大小为65536sectors。preload子分区的起始地址是“物理地址34072576”，结束地址是“物理地址37152768”，version子分区的大小为3080192sectors。
[0317] 明显地，在version子分区和preload子分区之间，存在free空间，也即，物理地址17360896与物理地址34072576之间的存储空间。该free空间无法不实际利用。
[0318] S802，Recovery进程从super头信息中解析出preload数据的大小(size)及当前的位置属性(currentpos)。
[0319] 接上例，上述preload数据的大小(size)可以是3080192sectors，上述当前的位置属性(currentpos)可以是物理地址34072576。也就是，preload数据是从物理地址34072576开始，读取到大小为3080192sectors的数据。
[0320] S803，Recovery进程依据preload数据的size及currentpos，从super分区中读取preload数据。
[0321] 示例性地，以currentpos指示的物理地址(如，物理地址34072576)为起点，从super分区中读取指定大小(如，3080192sectors)的数据，以作为preload数据。
[0322] S804，Recovery进程将preload数据写入userdata分区中的空白区域。
[0323] 在一些实施例中，可以是将preload数据写入userdata分区尾部的存储空间。
[0324] S805，Recovery进程从改制小包的super_metadata.img中读取目标位置(dstpos)。
[0325] 在一些示例中，上述目标位置(dstpos)是目标版本对应的preload分区的起始地址。可以理解的，上述super_metadata.img中记录有版本改制之后，各分区的起始地址和大小等信息。
[0326] 例如，super_metadata.img中version子分区和preload子分区的起始地址及大小的数据，如下所示：
[0327] Super：17295360..17360896：version(65536sectors)；
[0328] Super：17360896..20441088：preload(3080192sectors)；
[0329] 这样，从super_metadata.img中读取到的目标位置(dstpos)可以是物理地址17360896。
[0330] S806，Recovery进程依据目标位置(dstpos)，将userdata分区中的preload数据再次写入super分区。
[0331] 在一些实施例中，以目标位置(dstpos)指示的存储地址为起始地址，通过覆盖的方式将preload数据再次写入super分区。例如，以物理地址17360896为起始地址，将preload数据再次写入super分区。
[0332] 另外，除了需要迁移preload数据之后，如图7所示，super分区的尾部数据(如称为第二数据)也需要同步迁移。可以理解的，上述super分区的尾部数据是super分区中存储在preload数据之后的数据。为了方面描述，可以将preload数据和super分区的尾部数据，称为数据1或第一数据。示例性地，Recovery进程确定super分区中，位于preload子分区之后的尾部空间还包括3M大小的数据时，在读取到preload数据之后，以preload子分区的结束地址为起点，继续读取3M大小的数据，这样，可读取到数据1。然后，再将读取到的数据1先写入userdata分区中的空白区域，然后，再将以上述目标位置(dstpos)为起始地址，将userdata分区中的数据1再次写入super分区。
[0333] 又或者，在解析出preload子分区的位置属性(currentpos)，如称为地址a或第一地址之后，从Common分区的分区表(又称为第三分区表)中解析出super分区的结束地址(又可称为结束物理地址)，如称为地址b或第三地址。然后，读取地址a和地址b之间写入的所有数据，以作为数据1。然后，再将读取到的数据1先写入userdata分区中的空白区域，然后，再将以上述目标位置(dstpos)为起点，将userdata分区中的数据1再次写入super分区。S119，Recovery进程利用改制小包中的ptable更新Common中的分区表。
[0334] 在一些实施例中，上述ptable包括目标版本下Common分区、系统分区和用户数据分区(Userdata)在存储空间中的起始地址和结束地址，该ptable又称为第四分区表，第四分区表还包括第五地址，所述第五地址用于指示完成升级后所述用户数据分区在所述存储器中的起始物理地址。
[0335] 当然，Common分区中原本也包括一分区表，如称为分区表a或称为第三分区表，该分区表a可用于指示merge之后，电子设备的Common分区、系统分区和用户数据分区(Userdata)在存储空间中的起始地址(又称为第四地址)和结束地址。其中，上述ptable与分区表a相比，所指示的系统分区更小，也即，第五地址在第四地址之前。
[0336] 可理解地，在上述S111之后，也即，电子设备经过merge之后，version子分区和preload子分区之间会出现free空间，之后，经过迁移preload数据和super分区的尾部数据之后，super分区的尾部将出现闲置的空间。此时，利用ptable，替代Common中的分区表a，可以将super分区尾部闲置的空间划分到用户数据分区(Userdata)，如图9所示。在此之前，preload数据的存储位置均前移，电子设备按照Common中更新后的分区表，能够正常加载系统数据，也就是，在不影响系统数据的情况下，可供用户支配的用户数据分区(Userdata)增加，提升用户的使用体验。
[0337] S120，Recovery进程将改制小包中的super_metadata.img更新到super头信息。
[0338] 在一些实施例中，super分区的头部存储区(图9中的1MB所指示的存储空间，又称为super_metadata分区)中存储有头部信息，又称为super头信息。该super头信息中包括子分区表。该子分区表记录有电子设备原super分区的各子分区的起始地址和大小。在本申请实施例中，preload数据的实际位置已前移，且上移过程中参照super_metadata.img。这就意味着，由于升级到目标版本之后，version定制子分区需缩小，preload分区的起始位置也上移。可以理解的，super_metadata.img中记录的version定制子分区大小是缩小后的大小，preload分区的起始位置也是上移后的地址，这样，电子设备将super_metadata.img写入super头信息中，替代原子分区表之后，电子设备启动操作系统之后，可以正常加载preload分区中的数据。
[0339] 接前例，在super_metadata.img更新到super头信息之前，super头信息中记录：version子分区的起始地址为“物理地址17295360”，结束地址是“物理地址17360896”；
preload子分区的起始地址为“物理地址34072576”，结束地址是“物理地址37152768”。
[0340] 在super_metadata.img更新到super头信息之后，super头信息中记录：version子分区的起始地址为“物理地址17295360”，结束地址是“物理地址17360896”；preload子分区的起始地址为“物理地址17360896”，结束地址是“物理地址20441088”。这样，在preload数据前移之后，电子设备也能够准确地读取到数据。
[0341] 作为一个示例性，如图10所示，在采用虚拟A/B升级方式的安卓系统中，由于只有静态分区采用A/B方案，而动态分区采用升级时构造虚拟动态分区的方案。因此，为了静态分区与动态分区的匹配，在super头信息，又称为动态分区(Super)的头部的元数据(/supermetadata)中，包含对应静态分区(A)的Slot0(插槽一数据)以及静态分区(B)的Slot1(插槽二数据)。Slot0以及Slot1用于保存Super分区的分区表。
[0342] 例如，在UFS的MBR中，设备启动顺序描述中，配置Slot0对应从静态分区(A)启动，配置Slot1对应从静态分区(B)启动。在设备启动时，根据启动的静态分区的不同，选择从Slot0或Slot1中的一个中获取Super分区的分区信息。例如，在设备由静态分区A启动时，在加载Super分区时，设备首先读取Slot0，以获取Super分区的子分区地址；在设备由静态分区B启动时，在加载Super分区时，设备首先读取Slot1，以获取Super分区的子分区地址。
[0343] 具体的，Slot0以及Slot1中包含多个子分区描述组，每个子分区描述组对应Super分区的一个子分区。每个子分区描述组包含：
[0344] 名称(Name)项，其值为子分区的名称；
[0345] 组(Group)项，其值为子分区类型；
[0346] 属性(Attributes)项，其值为分区读写属性，例如，只读属性(readonly)；
[0347] 地址(Extents)项，其值为子分区的地址(例如，分区大小、偏移量)。
[0348] 在Name项以及Group项中，值的后缀为_a，则对应静态分区(A)；值的后缀为_b，则对应静态分区(B)。
[0349] 在由静态分区A启动，加载Super分区时，首先读取Slot0。在读取Slot0时，由于后缀为_a对应静态分区(A)，设备读取Slot0中Name项和/或Group项后缀为_a的分区描述组中Extents项的值，以获取Super分区的子分区地址。
[0350] 在由静态分区B启动，加载Super分区时，首先读取Slot1。在读取Slot1时，由于后缀为_b对应静态分区(B)，设备读取Slot0中Name项和/或Group项后缀为_b的分区描述组中Extents项的值，以获取Super分区的子分区地址。
[0351] 改制小包中包含目标版本的动态分区(Super)的分区信息，也即，super_metadata.img，电子设备可以利用super_metadata.img刷新静态分区(B)所对应的Slot1中的分区信息。如，参考S120。
[0352] 以preload子分区为例，动态分区(Super)的/supermetadata的Slot 1中包含如下内容：
[0353] Metadata version:10.2；
[0354] Metadata size:1300bytes；
[0355] Metadata max size:65536bytes；
[0356] Metadata slot count:3；
[0357] Header flags:virtual_abdevice；
[0358] Partition table:‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑；
[0359] Name:preload_b；
[0360] Group:ry_dynamic_partitions_b；
[0361] Attributes:readonly,updated；
[0362] Extents:34072576..37152768；改制小包中的super_metadata.img包含如下内容：
[0363] Name:preload；
[0364] Group:ry_dynamic_partitions；
[0365] Extents:17360896..20441088；设备通过当前需要升级的静态分区为静态分区(B)定位到对应静态分区(B)的动态分区(Super)的/supermetadata的Slot 1，使用super_metadata.img刷新Slot 1中的内容。动态分区(Super)的/supermetadata的Slot 1中包含如下内容：
[0366] Metadata version:10.2；
[0367] Metadata size:1300bytes；
[0368] Metadata max size:65536bytes；
[0369] Metadata slot count:3；
[0370] Header flags:virtual_ab_device；
[0371] Partition table:‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑‑；
[0372] Name:preload_b；
[0373] Group:ry_dynamic_partitions_b；
[0374] Attributes:readonly,updated；
[0375] Extents:17360896..20441088；
[0376] S121，Recovery进程确定oeminfo子分区中的VC信息已变更。
[0377] 在一些实施例中，Recovery进程检测oeminfo子分区中的VC信息是否变更，也即，不再是demo cn。在确定已经变更的情况下，流程进入S122。在确定未变更的情况下，再次执行VC信息变更流程。例如，将改制小包中的vendor_country.mbn写入oeminfo子分区中的oeminfo_vc文件，替代原VC信息。
[0378] S122，格式化Userdata分区，并重启。
[0379] 在一些实施例中，userdata分区需要重置，metadata分区及data分区格式化。
[0380] 这样，电子设备可以支持远程hota升级的方式，实现演示到商用的切换，避免样机回收投递、节省刷机人力成本。
[0381] 作为一种实现方式，以对运行于A系统的电子设备进行操作系统升级为例，上述操作系统升级方法的实现过程，如图11所示：
[0382] A1，升级服务器发布系统升级包。
[0383] 在一些实施例中，上述A1的实现细节可参考S101，在此不再赘述。
[0384] A2，ouc apk获取系统升级包，该系统升级包中包括改制小包、目标版本的VC信息。
[0385] 在一些实施例中，上述A2的实现细节可参考S102，在此不再赘述。
[0386] A3，ouc apk触发update engine进入升级流程。
[0387] 在一些实施例中，上述A3的实现细节可参考S103，在此不再赘述。
[0388] A4，update engine校验系统升级包。
[0389] 在一些实施例中，上述A4的实现细节可参考S104，在此不再赘述。
[0390] A5，update engine在运行A系统的情况下，根据系统升级包针对B系统的静态分区进行数据写入操作。
[0391] 在一些实施例中，上述A4的实现细节可参考S401，在此不再赘述。另外，针对运行于B系统的电子设备进行操作系统升级的场景下，同理，update engine根据系统升级包针对B系统的静态分区进行数据写入操作。
[0392] A6，update engine在用户分区中创建虚拟动态分区。
[0393] A7，update engine将系统升级包中用于升级动态分区的数据写入虚拟动态分区。
[0394] 在一些实施例中，上述A6和A7的实现细节可参考S402，在此不再赘述。
[0395] A8，update engine将指示从A系统的静态分区启动的标识，变更为指示从B系统的静态分区启动。
[0396] 在一些实施例中，update engine可以改写主引导记录(Master Boot Record，MBR)的启动顺序标识，如，将启动顺序标识由A改写为B，这样，电子设备重启后，可以加载静态分区(B)的数据，从而，切换至运行B系统。
[0397] A9，update engine确定系统升级包中包括改制小包。
[0398] 在一些实施例中，上述A9的实现细节可参考S106，在此不再赘述。
[0399] A10，update engine从系统升级包中，读取目标版本的VC信息。
[0400] 在一些实施例中，上述A10的实现细节可参考S107，在此不再赘述。
[0401] A11，update engine将读取到的VC信息写入oeminfo_vc_tmp。
[0402] 在一些实施例中，上述A11的实现细节可参考S108，在此不再赘述。
[0403] A12，update engine将改制小包解压到cache/update目录，该改制小包中包括ptable和super_metadata.img。
[0404] 在一些实施例中，上述A12的实现细节可参考S109，在此不再赘述。
[0405] A13，update engine触发电子设备重启。
[0406] 在一些实施例中，上述A13的实现细节可参考S110，在此不再赘述。另外，重启成功，电子设备可以加载B系统的静态分区，流程进入A14。
[0407] A14，update engine触发merge流程。
[0408] 在一些实施例中，上述A14的实现细节可参考S111，在此不再赘述。
[0409] A15，update engine将B系统的静态分区复制到A系统的静态分区中。
[0410] 在一些实施例中，上述A15的实现细节可参考S112，在此不再赘述。
[0411] A16，update engine将oeminfo_vc_tmp中的VC信息写入oeminfo子分区中的oeminfo_vc文件。
[0412] 在一些实施例中，上述A16的实现细节可参考S113，在此不再赘述。
[0413] A17，update engine在检测到cache/update目录中包括改制小包的情况下，在cache/recovery/command文件中，写入改制小包的存储地址。
[0414] 在一些实施例中，上述A17的实现细节可参考S114，在此不再赘述。
[0415] A18，update engine触发重启，并指示进入Recovery模式。
[0416] 在一些实施例中，上述A18的实现细节可参考S115，在此不再赘述。另外，电子设备可以依据指示进入Recovery模式的信息，启动Recovery进程，这样，流程进入A19。
[0417] A19，Recovery进程校验系统升级包的完整性。
[0418] 在一些实施例中，上述A19的实现细节可参考S116，在此不再赘述。
[0419] A20，Recovery进程依据cache/recovery/command文件查询到改制小包时，配置全局变量vcdemo。
[0420] 在一些实施例中，上述A20的实现细节可参考S117，在此不再赘述。
[0421] A21，在识别到变量vcdemo的情况下，Recovery进程依据super_metadata.img，迁移preload数据。
[0422] 在一些实施例中，上述A21的实现细节可参考S801～S806，在此不再赘述。
[0423] A22，Recovery进程将改制小包中的ptable更新到Common中的分区表。
[0424] 在一些实施例中，上述A22的实现细节可参考S119，在此不再赘述。
[0425] A23，Recovery进程将改制小包中的super_metadata.img更新到super头信息。
[0426] 在一些实施例中，上述A23的实现细节可参考S120，在此不再赘述。
[0427] A24，Recovery进程确定oeminfo子分区中的VC信息已变更。
[0428] 在一些实施例中，上述A24的实现细节可参考S121，在此不再赘述。
[0429] A25，Recovery进程格式化Userdata分区，并重启。
[0430] 在一些实施例中，上述A25的实现细节可参考S122，在此不再赘述。
[0431] 本申请实施例还提供一种电子设备，该电子设备可以包括：存储器和一个或多个处理器。该存储器和处理器耦合。该存储器用于存储计算机程序代码，该计算机程序代码包括计算机指令。当处理器执行计算机指令时，可使得电子设备执行上述实施例中的各个步骤。当然，该电子设备包括但不限于上述存储器和一个或多个处理器，例如，图3A所示。
[0432] 本申请实施例还提供一种芯片系统，该芯片系统可以应用于前述实施例中的电子设备。如图12所示，该芯片系统包括至少一个处理器2201和至少一个接口电路2202。该处理器2201可以是上述电子设备中的处理器。处理器2201和接口电路2202可通过线路互联。该处理器2201可以通过接口电路2202从上述电子设备的存储器接收并执行计算机指令。当计算机指令被处理器2201执行时，可使得电子设备执行上述实施例中的各个步骤。当然，该芯片系统还可以包含其他分立器件，本申请实施例对此不作具体限定。
[0433] 在一些实施例中，通过以上的实施方式的描述，所属领域的技术人员可以清楚地了解到，为描述的方便和简洁，仅以上述各功能模块的划分进行举例说明，实际应用中，可以根据需要而将上述功能分配由不同的功能模块完成，即将装置的内部结构划分成不同的功能模块，以完成以上描述的全部或者部分功能。上述描述的系统，装置和单元的具体工作过程，可以参考前述方法实施例中的对应过程，在此不再赘述。
[0434] 在本申请实施例各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现，也可以采用软件功能单元的形式实现。
[0435] 所述集成的单元如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本申请实施例的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的全部或部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)或处理器执行本申请各个实施例所述方法的全部或部分步骤。而前述的存储介质包括：快闪存储器、移动硬盘、只读存储器、随机存取存储器、磁碟或者光盘等各种可以存储程序代码的介质。
[0436] 以上所述，仅为本申请实施例的具体实施方式，但本申请实施例的保护范围并不局限于此，任何在本申请实施例揭露的技术范围内的变化或替换，都应涵盖在本申请实施例的保护范围之内。因此，本申请实施例的保护范围应以所述权利要求的保护范围为准。