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

摘要

本申请提供了一种操作系统的升级方法、电子设备及存储介质。该方法将操作系统升级过程中的安装过程和校验过程，从串行执行修改为并行执行，从而既能够保证操作系统快速升级完成，又缩短了对休眠锁的持有时间，解决了由于操作系统升级导致电子设备整机功耗高的问题。

权利要求

1.一种操作系统的升级方法，其特征在于，应用于电子设备，所述电子设备包括处理器以及存储器，所述存储器包括基础分区、第一静态分区、第二静态分区、动态分区以及用户数据分区，所述电子设备启动后依次加载所述基础分区的数据、所述第一静态分区的数据以及所述动态分区的数据以运行第一操作系统，所述第一操作系统运行之后，所述方法还包括：获取升级包，所述升级包包括第一升级文件和第二升级文件，所述第一升级文件对应于所述第一静态分区和所述第二静态分区，所述第二升级文件对应于所述动态分区；

根据所述第一升级文件升级所述第二静态分区；

在所述第二静态分区升级完后，启动静态分区校验线程，所述静态分区校验线程用于校验所述第二静态分区；

在所述静态分区校验线程校验所述第二静态分区的过程中，根据所述第二升级文件升级所述动态分区；

其中，所述在所述静态分区校验线程校验所述第二静态分区的过程中，根据所述第二升级文件升级所述动态分区，包括：根据所述第二升级文件在用户数据分区创建所述第二升级文件对应的所述动态分区中的子分区的写时拷贝cow文件；

在将所述第二升级文件写入所述cow文件的过程中，判断是否向所述cow文件写入了第一数据，所述第一数据为所述第二升级文件中的部分数据；

在向所述cow文件写入了所述第一数据时，获取所述第二静态分区对应的校验状态；

在所述校验状态为第二状态时，停止向所述cow文件写入所述第二升级文件，所述第二状态用于指示所述第二静态分区中的子分区校验失败。

2.根据权利要求1所述的方法，其特征在于，所述静态分区校验线程校验所述第二静态分区，包括：所述静态分区校验线程对所述第二静态分区中的子分区进行校验；

在对所述子分区校验成功时，所述静态分区校验线程将所述第二静态分区对应的校验状态修改为第一状态，所述第一状态用于指示所述子分区校验成功；

在对所述子分区校验失败时，所述静态分区校验线程将所述第二静态分区对应的校验状态修改为第二状态。

3.根据权利要求2所述的方法，其特征在于，在所述静态分区校验线程将所述第二静态分区对应的校验状态修改为第一状态之后，所述方法还包括：在所述第二静态分区的所有子分区都校验完成后，结束对所述第二静态分区的校验。

4.根据权利要求2所述的方法，其特征在于，所述方法还包括：在所述校验状态为所述第一状态时，判断所述第二升级文件是否全部写入所述cow文件；

在所述第二升级文件全部写入所述cow文件时，对所述动态分区进行校验；

在所述第二升级文件未全部写入所述cow文件时，将所述第二升级文件中未写入所述cow文件的数据写入所述cow文件。

5.根据权利要求4所述的方法，其特征在于，在所述对所述动态分区进行校验之后，所述方法还包括：重启所述电子设备依次加载所述基础分区的数据、所述第二静态分区的数据、所述动态分区的数据和所述cow文件的数据以运行第二操作系统；

将所述cow文件中的数据落盘到所述动态分区中对应子分区中；

将所述第二静态分区的数据同步到所述第一静态分区。

6.根据权利要求1所述的方法，其特征在于，所述方法还包括：在未向所述cow文件写入了所述第一数据时，继续将所述第二升级文件写入所述cow文件。

7.根据权利要求1至6任一项所述的方法，其特征在于，所述方法还包括：在根据所述第一升级文件升级所述第二静态分区，根据所述第二升级文件升级所述动态分区的过程中，向断点记录文件记录断点信息，所述断点信息标识的断点为所述电子设备重启后接续升级的位置；

在所述电子设备掉电重启后，根据所述断点记录文件中记录的断点信息确定接续升级的分区；

在确定接续升级的分区为所述第二静态分区时，根据所述断点信息从所述第一升级文件中所述断点信息标识的断点所在的位置读取数据，根据读取到的数据升级所述第二静态分区；

在所述第二静态分区升级完后，重新启动所述静态分区校验线程；

在所述静态分区校验线程校验所述第二静态分区的过程中，根据所述第二升级文件升级所述动态分区。

8.根据权利要求7所述的方法，其特征在于，所述方法还包括：在确定接续升级的分区为所述动态分区时，重新启动所述静态分区校验线程；

在所述静态分区校验线程校验所述第二静态分区的过程中，根据所述断点信息从所述第二升级文件中所述断点信息标识的断点所在的位置读取数据，根据读取到的数据升级所述动态分区。

9.一种电子设备，其特征在于，所述电子设备包括处理器以及存储器，所述存储器包括基础分区、第一静态分区、第二静态分区、动态分区以及用户数据分区，所述电子设备启动后依次加载所述基础分区的数据、所述第一静态分区的数据以及所述动态分区的数据以运行第一操作系统；

其中，所述存储器和所述处理器耦合，所述存储器存储有程序指令；

当所述程序指令由所述处理器执行时，使得所述电子设备执行如权利要求1至8中任意一项所述的操作系统的升级方法。

10.一种计算机可读存储介质，包括计算机程序，其特征在于，当所述计算机程序在电子设备上运行时，使得所述电子设备执行如权利要求1至8中任意一项所述的操作系统的升级方法。

说明书

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

技术领域

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

背景技术

[0002] 随着电子设备可安装的应用程序越来越多，用户数据对存储空间的占用需求越来越大。目前，为了既保证操作系统升级的成功性，又能够尽可能降低系统数据对存储空间的占用，以留出更多的存储空间存储用户数据，采用虚拟AB系统（Virtual AB）分区结构的电子设备变的越来越普及。

[0003] 目前，对于采用虚拟AB系统分区结构的电子设备，在进行操作系统升级时，为了确操作系统快速完成升级，升级过程中升级引擎（update_engine）会持有休眠锁，即升级过程中电子设备的操作系统不能进入休眠状态，而整个升级过程不仅包括根据升级包对静态分区和动态分区升级的操作，在对分区完成升级后，还包括对升级的分区进行校验的操作。这就需要升级引擎长时间持有休眠锁，而长时间持有休眠锁会导致操作系统不能休眠，进而导致电子设备整机功耗升高。

发明内容

[0004] 为了解决上述技术问题，本申请提出了一种操作系统的升级方法、电子设备及存储介质，旨在缩短操作系统升级过程中对休眠锁的持有时间，以降低电子设备的整机功耗。

[0005] 第一方面，本申请提供了一种操作系统的升级方法，应用于电子设备，电子设备包括处理器以及存储器，存储器包括基础分区、第一静态分区、第二静态分区、动态分区以及用户数据分区，电子设备启动后依次加载基础分区的数据、第一静态分区的数据以及动态分区的数据以运行第一操作系统，第一操作系统运行之后，方法还包括：获取升级包，升级包包括第一升级文件和第二升级文件，第一升级文件对应于第一静态分区和第二静态分区，第二升级文件对应于动态分区；根据第一升级文件升级第二静态分区；在第二静态分区升级完后，启动静态分区校验线程，静态分区校验线程用于校验第二静态分区；在静态分区校验线程校验第二静态分区的过程中，根据第二升级文件升级动态分区。由此，通过将操作系统升级过程中的安装过程和校验过程，从串行执行修改为并行执行，从而既能够保证操作系统快速升级完成，又缩短了对休眠锁的持有时间，解决了由于操作系统升级导致电子设备整机功耗高的问题。

[0006] 根据第一方面，静态分区校验线程校验第二静态分区，包括：静态分区校验线程对第二静态分区中的子分区进行校验；在对子分区校验成功时，静态分区校验线程将第二静态分区对应的校验状态修改为第一状态，第一状态用于指示子分区校验成功；在对子分区校验失败时，静态分区校验线程将第二静态分区对应的校验状态修改为第二状态，第二状态用于指示子分区校验失败。由此，静态分区校验线程通过对静态分区中每一完成升级的子分区进行校验，并根据校验结果设置这些子分区的校验状态，从而能够使得升级引擎在没完成预定数量的数据写入到动态分区的子分区对应的cow文件后，能够及时获取当前完成校验的静态分区的子分区的校验状态，从而根据获取到的校验状态确定是否继续将数据写入cow文件，还是停止操作系统的升级操作，尽可能避免了静态分区存在异常时还继续进行cow文件的写入操作对电子设备功耗的浪费。

[0007] 根据第一方面，或者以上第一方面的任意一种实现方式，在静态分区校验线程将第二静态分区对应的校验状态修改为第一状态之后，方法还包括：在第二静态分区的所有子分区都校验完成后，结束对第二静态分区的校验。由此，静态分区中所有的子分区都校验完成后，静态分区校验线程字段停止对静态分区的校验操作，降低了对电子设备资源的占用，进而降低了对电子设备功耗的浪费。

[0008] 根据第一方面，或者以上第一方面的任意一种实现方式，在静态分区校验线程校验第二静态分区的过程中，根据第二升级文件升级动态分区，包括：根据第二升级文件在用户数据分区创建第二升级文件对应的子分区的写时拷贝cow文件；将第二升级文件写入cow文件。由此，借助用户数据分区，在不影响电子设备使用的情况下，完成了将动态分对应的子分区的升级文件中数据的写入。

[0009] 根据第一方面，或者以上第一方面的任意一种实现方式，将第二升级文件写入cow文件，包括：在将第二升级文件写入cow文件的过程中，判断是否向cow文件写入了第一数据，第一数据为第二升级文件中的部分数据；在向cow文件写入了第一数据时，获取第二静态分区对应的校验状态；在校验状态为第二状态时，停止向cow文件写入第二升级文件。由此，在将升级动态分区的子分区的第二升级文件写入对应的cow文件时，通过按照预设需求，在每写入第一数据后获取一次静态分区当前的校验状态，在校验状态指示静态分区当前校验成功时才继续进行cow文件的写入，从而尽可能避免了对电子设备功耗的浪费。

[0010] 根据第一方面，或者以上第一方面的任意一种实现方式，方法还包括：在校验状态为第一状态时，判断第二升级文件是否全部写入cow文件；在第二升级文件全部写入cow文件时，对动态分区进行校验；在第二升级文件未全部写入cow文件时，将第二升级文件中未写入cow文件的数据写入cow文件。

[0011] 根据第一方面，或者以上第一方面的任意一种实现方式，在对动态分区进行校验之后，方法还包括：重启电子设备依次加载基础分区的数据、第二静态分区的数据、动态分区的数据和cow文件的数据以运行第二操作系统；将cow文件中的数据落盘到动态分区中对应子分区中；将第二静态分区的数据同步到第一静态分区。由此，在电子设备重启运行到升级后的第二操作系统后，通过将用户数据分区中cow文件内的数据落盘到动态分区对应的子分区中，从而完成了本次操作系统的升级。

[0012] 根据第一方面，或者以上第一方面的任意一种实现方式，方法还包括：在未向cow文件写入了第一数据时，继续将第二升级文件写入cow文件。

[0013] 根据第一方面，或者以上第一方面的任意一种实现方式，方法还包括：在根据第一升级文件升级第二静态分区，根据第二升级文件升级动态分区的过程中，向断点记录文件记录断点信息，断点信息标识的断点为电子设备重启后接续升级的位置；在电子设备掉电重启后，根据断点记录文件中记录的断点信息确定接续升级的分区；在确定接续升级的分区为第二静态分区时，根据断点信息从第一升级文件中断点信息标识的断点所在的位置读取数据，根据读取到的数据升级第二静态分区；在第二静态分区升级完后，重新启动静态分区校验线程；在静态分区校验线程校验第二静态分区的过程中，根据第二升级文件升级动态分区。由此，在电子设备断电重启接续升级时采用本申请提供的技术方案，同样能够缩短升级时间，从而降低电子设备的功耗。

[0014] 根据第一方面，或者以上第一方面的任意一种实现方式，在确定接续升级的分区为动态分区时，重新启动静态分区校验线程；在静态分区校验线程校验第二静态分区的过程中，根据断点信息从第二升级文件中断点信息标识的断点所在的位置读取数据，根据读取到的数据升级动态分区。由此，在电子设备断电重启接续升级时采用本申请提供的技术方案，同样能够缩短升级时间，从而降低电子设备的功耗。

[0015] 第二方面，本申请提供了一种电子设备。该电子设备包括处理器以及存储器，存储器包括基础分区、第一静态分区、第二静态分区、动态分区以及用户数据分区，电子设备启动后依次加载基础分区的数据、第一静态分区的数据以及动态分区的数据以运行第一操作系统；其中，存储器和处理器耦合，存储器存储有程序指令；当程序指令由处理器执行时，使得电子设备执行第一方面，或者以上第一方面的任意一种实现方式中的方法的指令。

[0016] 第三方面，本申请提供了一种计算机可读存储介质，用于存储计算机程序，当计算机程序在电子设备上运行时，使得电子设备执行第一方面，或者以上第一方面的任意一种实现方式中的方法的指令。

[0017] 第四方面，本申请提供了一种计算机程序产品，该计算机程序产品包括计算机程序，当其在电子设备上运行时，使得电子设备执行第一方面，或者以上第一方面的任意一种实现方式中的方法的指令。

[0018] 第五方面，本申请提供了一种芯片，该芯片包括处理电路、接收管脚和发送管脚。其中，接收管脚、发送管脚和处理电路通过内部连接通路互相通信，该处理电路执行第一方面，或者以上第一方面的任意一种实现方式中的方法的指令，以控制接收管脚接收信号，控制发送管脚发送信号。

附图说明

[0019] 图1是示例性示出的一种电子设备的硬件结构示意图；

[0020] 图2是示例性示出的内部存储器的类型划分示意图；

[0021] 图3是示例性示出的非AB系统、AB系统和虚拟AB系统的分区结构示意图；

[0022] 图4是示例性示出的操作系统升级过程中拍包服务器、OTA服务器和电子设备之间的交互示意图；

[0023] 图5是示例性示出的操作系统升级过程中电子设备从获取升级包到对静态分区进行升级的示意图；

[0024] 图6是示例性示出的操作系统升级过程中电子设备并行执行静态分区校验和动态分区数据写入的示意图；

[0025] 图7是示例性示出的操作系统升级过程中电子设备重启后执行Merge操作和分区同步的示意图；

[0026] 图8是示例性示出的操作系统升级过程中拍包服务器、OTA服务器和电子设备之间的时序图；

[0027] 图9是示例性示出的操作系统升级过程电子设备并行执行安装和校验的流程示意图；

[0028] 图10是示例性示出的电子设备从启动到进行操作系统升级到重启完成操作系统升级的流程示意图。

具体实施方式

[0029] 下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。

[0030] 本文中术语“和/或”，仅仅是一种描述关联对象的关联关系，表示可以存在三种关系，例如，A和/或B，可以表示：单独存在A，同时存在A和B，单独存在B这三种情况。

[0031] 本申请实施例的说明书和权利要求书中的术语“第一”和“第二”等是用于区别不同的对象，而不是用于描述对象的特定顺序。例如，第一目标对象和第二目标对象等是用于区别不同的目标对象，而不是用于描述目标对象的特定顺序。

[0032] 在本申请实施例中，“示例性的”或者“例如”等词用于表示作例子、例证或说明。本申请实施例中被描述为“示例性的”或者“例如”的任何实施例或设计方案不应被解释为比其它实施例或设计方案更优选或更具优势。确切而言，使用“示例性的”或者“例如”等词旨在以具体方式呈现相关概念。

[0033] 在本申请实施例的描述中，除非另有说明，“多个”的含义是指两个或两个以上。例如，多个处理单元是指两个或两个以上的处理单元；多个系统是指两个或两个以上的系统。

[0034] 为了更好的理解本申请实施例提供的技术方案，在对本申请实施例的技术方案说明之前，首先结合附图对本申请实施例的适用于的电子设备（例如手机、平板、PC机等）的硬件结构进行说明。

[0035] 参见图1，电子设备100可以包括：处理器110，外部存储器接口120，内部存储器121，通用串行总线（universal serial bus，USB）接口130，充电管理模块140，电源管理模块141，电池142，天线1，天线2，移动通信模块150，无线通信模块160，音频模块170，传感器模块180，按键190，马达191，指示器192，摄像头193，显示屏194，以及用户标识模块（subscriber identification module，SIM）卡接口195等。

[0036] 示例性的，音频模块170可以包括扬声器170A、受话器170B、麦克风170C、耳机接口170D等。

[0037] 示例性的，传感器模块180可以包括压力传感器、陀螺仪传感器、气压传感器、磁传感器、加速度传感器、距离传感器、接近光传感器、指纹传感器、温度传感器、触摸传感器、环境光传感器、骨传导传感器等。

[0038] 示例性的，按键190包括电源键（开机键），音量键等。按键190可以是机械按键。也可以是触摸式按键。电子设备100可以接收按键输入，产生与电子设备100的用户设置以及功能控制有关的键信号输入。

[0039] 此外，处理器110可以包括一个或多个处理单元，例如：处理器110可以包括应用处理器（application processor，AP），调制解调处理器，图形处理器（graphics processing unit，GPU），图像信号处理器（image signal processor，ISP），控制器，存储器，视频编解码器，数字信号处理器（digital signal processor，DSP），基带处理器，和/或神经网络处理器（neural‑network processing unit，NPU）等。

[0040] 可理解的，在具体实现中，不同的处理单元可以是独立的器件，也可以集成在一个或多个处理器中。

[0041] 此外，在一些实现方式中，控制器可以是电子设备100的神经中枢和指挥中心。控制器可以根据指令操作码和时序信号，产生操作控制信号，完成取指令和执行指令的控制。

[0042] 此外，处理器110中的存储器主要用于存储指令和数据。在一些实现方式中，处理器110中的存储器为高速缓冲存储器。

[0043] 此外，可理解的，在实际的应用场景中，触发电子设备100实现各种功能应用以及数据处理的可执行程序代码是存储在内部存储器121中的，这些可执行程序代码包括指令。

[0044] 示例性的，具体到本申请实施例提供的技术方案中，电子设备100的启动、操作系统的升级主要依赖于预先存储到内部存储器121中的相关指令，处理器110通过执行内部存储器121中存储的指令，从而能够使得电子设备100执行本申请实施例提供的操作系统的升级方法。

[0045] 示例性的，参见图2，在具体实现中，内部存储器121可以包括只读存储器121A和随机存取存储器121B，而只读存储器121A又可以划分为非AB系统（图3中的（1）所示）、AB系统（图3中的（2）所示）和虚拟AB系统（图3中的（3）所示）这三种不同的分区结构。

[0046] 可理解的，具体到实际应用中，随机存取存储器（Random Access Memory，RAM），又称作“主存”，它可随时读写，而且速度很快，通常作为操作系统或其他正在运行中的程序的临时数据存储媒介，当电源关闭时，RAM不能保留数据，即随机存取存储器121B中通常存储的是电子设备运行时的临时数据；而只读存储器（Read‑Only Memory，ROM），又可以称作“非易失性存储器”，所存数据一般是装入整机前事先写好的，例如操作系统的镜像文件，以及用户使用电子设备时产生的用户数据，整机工作过程中只能读出，而不能像RAM那样能够快速地、方便地加以改写，因此ROM所存数据稳定，断电后所存数据也不会改变。综上所述，RAM和ROM相比，两者最大的区别是RAM在断电以后保存在上面的数据会自动消失，而ROM不会自动消失，可以长时间断电保存。

[0047] 此外，需要说明的是，目前操作系统的升级过程中，在将从空中下载（Over‑the‑Air，OTA）服务器下载到电子设备中用户数据分区（位于只读存储器121A）的升级包中的升级文件解压到对应的静态分区和动态分区时，均会借助随机存取存储器121B的内核缓存，以实现升级文件的快速读写。

[0048] 此外，具体到实际应用中，只读存储器121A例如可以是磁盘存储器件、闪存器件、通用闪存存储器（universal flash storage，UFS）等；随机存取存储器121B例如可以是高速随机存取存储器。

[0049] 此外，需要说明的是，在具体实现中，只读存储器121A可以包括存储程序区和存储数据区。其中，存储程序区可存储操作系统，至少一个功能所需的应用程序（比如声音播放功能，图像播放功能等）等。存储数据区可存储电子设备100使用过程中所创建的数据（比如音频数据，电话本等）等。

[0050] 示例性的，关于存储程序区，具体到本申请实施例提供的技术方案中，例如可以是基础分区（Common）、静态分区（Slot）和动态分区（Super）；关于存储数据区，具体到本申请实施例提供的技术方案中，例如可以是用户数据分区（Userdata）。

[0051] 继续参见图2，电子设备100的内部存储器121的分区结构例如可以是非AB系统、AB系统和虚拟AB系统。具体的说，基于上述四种分区（基础分区、静态分区、动态分区和用户数据分区）的特性，对于操作系统升级中不需要升级的分区，例如基础分区和用户数据分区，不论是在非AB系统、AB系统，还是虚拟AB系统下，均采用的是单分区，而需要升级的分区则会有所不同。

[0052] 示例性的，由于在非AB系统下进行操作系统升级，升级过程中电子设备的其他功能不能使用，电子设备只能停留在非AB系统的升级界面，待操作系统升级完成重启电子设备后才可以进入用户界面正常使用。故而，在非AB系统下，静态分区和动态分区也采用的是单分区，详见图3中的（1）所示，这样就可以降低对存储器空间的占用，以预留更多的空间给用户数据分区。

[0053] 示例性的，AB系统是为了让电子设备在进行操作系统升级过程中，用户可以任意返回电子设备的主界面，从而不影响电子设备的使用。故而，在AB系统下，静态分区和动态分区采用的是双分区，详见图3中的（2）所示，静态分区例如可以被划分为第一静态分区（SlotA）和第二静态分区（SlotB），动态分区例如可以划分为第一动态分区（SuperA）和第二动态分区（SuperB）。虽然这种分区划分方式可以让电子设备在进行操作系统升级过程中，任意返回电子设备的主界面，但是会占用存储器较大的空间，使得用户数据分区可用的空间大大减小。

[0054] 示例性的，虚拟AB系统结合了非AB系统和AB系统的优点，将存储的文件较小，即占用存储空间较小的静态分区划分为第一静态分区（SlotA）和第二静态分区（SlotB），将存储的文件较大，即占用存储空间较大的动态分区采用单分区，详见图3中的（3）所示。

[0055] 以只读存储器121A的分区结构为虚拟AB系统分区结构为例，具体到实际应用中，对于电子设备中只读存储器121A的分区部署信息可以通过表1所示的分区表进行描述。

[0056] 表1 分区表

[0057]

[0058] 这样，通过分区表定义每个分区的起始地址和大小，从而针对不同的硬件可以根据需要调整相应的分区大小。

[0059] 此外，需要说明的是，除了特殊预留的分区，基本上每个分区都有其对应的镜像（image）文件，镜像文件是通过软件代码编译而成，其内集成了电子设备启动或运行过程相关的各种功能文件和配置。没有镜像文件，电子设备就没法运行。一个完整的系统版本包括很多镜像，分区表镜像gpt.img、启动相关镜像（xloader.img、boot.img）、系统镜像super.img（集成了android系统核心）和用户数据镜像userdata.img（用来储存用户数据）等。

[0060] 应当理解的是，上述说明仅是为了更好的理解本实施例的技术方案而列举的示例，不作为对本实施例的唯一限制。

[0061] 也就是说，在实际应用中，分区表中记录的分区可以根据实际的业务需求来进行划分设置。

[0062] 另外，关于AB系统分区结构和虚拟AB系统分区结构中以双分区的形式存在的分区在存储器中的分布情况并不局限于图3中的（2）和图3中的（3）示出的样式，在实际应用中各个分区的位置是根据分配的起始地址和结束地址确定的。

[0063] 关于电子设备100的硬件结构就介绍到此，应当理解的是，图1所示电子设备100仅是一个范例，在具体实现中，电子设备100可以具有比图中所示的更多的或者更少的部件，可以组合两个或多个的部件，或者可以具有不同的部件配置。图1中所示出的各种部件可以在包括一个或多个信号处理和/或专用集成电路在内的硬件、软件、或硬件和软件的组合中实现。

[0064] 此外，需要说明的，在实际的应用场景中，随着空中下载技术（Over‑the‑Air Technology，OTA）的发展，通过电子设备的无线网络接口实现对电子设备进行远程版本升级的OTA升级越来越普及。结合实际的业务场景，为了便于说明本申请实施例所描述的操作系统的升级方案，以下结合图4，以OTA升级场景为例，对本申请实施例提供的操作系统的升级方案中拍包服务器、OTA服务器和电子设备之间的交互进行说明。

[0065] 示例性的，参见图4，用于升级电子设备（如图4中的PC设备、平板设备、手机等）的操作系统的升级包由拍包服务器根据版本镜像制作而成，并由拍包服务器将制作的升级包上传至OTA服务器，由OTA服务器统一管理主动推送给接入的电子设备，或者根据接入的电子设备的请求发送给对应的电子设备。

[0066] 继续参见图4，电子设备在从OTA服务器获取到升级包进行操作系统升级后，会将本次的升级结果上报给OTA服务器，以便OTA服务器获知电子设备本次的操作系统升级是否成功。

[0067] 此外，需要说明的是，在实际应用中，对于升级失败的情况，电子设备上报给OTA服务器的升级结果中还可以包括升级失败的日志信息，以便快速定位操作系统升级失败的原因。

[0068] 具体到本申请实施例提供的操作系统的升级方案中，为了尽可能缩短操作系统升级过程中对休眠锁的持有时间，以降低电子设备在升级过程中的功耗，电子设备在进行操作系统升级时会将操作系统升级过程中的安装过程和校验过程，从串行执行修改为并行执行。

[0069] 示例性的，参见图5可知，在本申请实施例提供的操作系统的升级方案中，电子设备在从OTA服务器获取到升级包（图5中的步骤（1））对操作系统进行升级时，首先会根据升级包对静态分区进行升级，即将升级包中对应于静态分区的子分区的升级文件的数据写入（安装）静态分区中对应的子分区（图5中的步骤（2））。

[0070] 接着，在对静态分区升级成功后，会根据升级包对动态分区进行升级（图6中的步骤（3.1）），即将升级包中对应于动态分区的子分区的升级文件的数据写入（安装）用户数据分区中对应该子分区的cow文件，同时在对动态分区执行升级操作的过程中，会启动静态分区校验线程对静态分区对静态分区进行校验（图6中的步骤（3.2）），这样动态分区的升级过程和静态分区的校验过程就可以并行执行，即图6中的步骤（3.1）和步骤（3.2）是同步进行的。

[0071] 接着，在对静态分区校验成功，同时动态分区也升级完后，需要对动态分区进行校验（图6中的步骤（4）），以确升级后的动态分区可用。

[0072] 接着，在校验成功后，便可以触发电子设备进行整机重启（图6中的步骤（5））。

[0073] 可理解的，在实际应用中，在对升级包中的升级文件安装完成，并校验成功后，可以直接触发电子设备进入整机重启，也可以在延迟进入整机重启。

[0074] 示例性的，关于延迟进入整机重启的条件，在一些实现方式中，可以是在电子设备处于闲时，即用户没有使用，也没有应用占用时，电子设备可以自动触发整机重启；在另一些实现方式中，可以是用户根据需要手动触发电子设备进入整机重启。

[0075] 此外，需要说明的是，如果进行操作系统升级前，电子设备启动后依次加载的是基础分区的数据、第一静态分区的数据和动态分区的数据，运行的是第一操作系统（操作系统升级前的版本），那么在完成图5、图6中所示的步骤（1）至步骤（5）的操作后，电子设备依次加载的是基础分区的数据、第二静态分区的数据、动态分区的数据和用户数据分区中cow文件中的数据，以使电子设备运行到第二操作系统（操作系统升级后的版本）。

[0076] 接着，在电子设备重启运行到第二操作系统后，会执行Merge操作，将cow文件中的数据落盘到动态分区对应的子分区。

[0077] 以图7所示为例，如果操作系统的升级过程中，动态分区的System子分区需要安装升级文件，则在用户数据分区中创建的cow文件便是于System子分区对应的System_COW文件。

[0078] 相应地，在重启后执行的Merge操作，便是将System_COW文件中的内容落盘到System子分区的操作（图7中的步骤（6））。

[0079] 继续参见图7，在一些实现方式中，在完成Merge操作后，电子设备还会执行分区同步操作，具体是将本次操作系统升级过程中进行升级的静态分区进行同步（图7中的步骤（7））。

[0080] 仍以图7所示为例，在本次操作系统的升级是将第二静态分区中的dtbo_b子分区中的文件从1.0版本升级到2.0版本时，在完成Merge操作后，电子设备会将dtbo_b子分区中的文件拷贝到第一静态分区中dtbo_a子分区中，以实现这两个子分区的同步。

[0081] 接着，在完成分区同步操作后，电子设备会向OTA服务器上报升级结果（图7中的步骤（8））。

[0082] 可理解的，在实际应用中，在图6所示的步骤（3.2）、步骤（4）和图7所示的步骤（6）、步骤（7）任一步骤出现异常，导致本次操作系统的升级失败时，电子设备都会中断后续的升级操作，向OTA服务器上报升级结果。

[0083] 此外，应当理解的是，上述说明仅是为了更好的理解本实施例的技术方案而列举的示例，不作为对本实施例的唯一限制。

[0084] 此外，需要说明的是，上述各分区对应的字母，在实际应用中可以不区分大小写，本申请对此不作限制。

[0085] 为了更好的理解本申请提供的操作系统的升级方案，以下结合图8从拍包服务器制作升级包到电子设备从OTA服务器获取拍包服务器制作的升级包，并进行操作系统的升级过程进行详细说明。

[0086] 在结合图8对本申请提供的操作系统的升级方案进行说明之前，首先对电子设备进行操作系统的升级过程中涉及的功能单元/模块/应用进行介绍。为了便于说明，本实施例以电子设备使用的操作系统为Android系统为例，示例性的，在一些实现方式中，升级包例如可以是由系统升级客户端（OTA Update Client，OUC）从OTA服务器获取的。

[0087] 需要说明的是，本实施例中所说的OUC具体是安装于电子设备的应用程序层（Application）中，用于进行操作系统升级管理的应用。

[0088] 此外，在从OTA服务器获取到升级包后，OUC会将获取到的升级包下发给电子设备中的升级引擎（update_engine），由update_engine完成静态分区的升级，由update_engine和快照节点/快照进程（snap进程）完成动态分区的升级。

[0089] 接着，在由update_engine和snap进程完成对升级包中升级文件的安装（升级）后，OUC触发电子设备进入整机重启，在重启后电子设备运行到升级后的操作系统后，内核（kernel）执行Merge操作，将用户数据分区中cow文件中的数据落盘到动态分区中对应的子分区中，update_engine对静态分区进行分区同步。

[0090] 此外，可理解的，在另一些实现方式中，操作系统的升级也可以通过应用程序层中安装的设置应用提供的入口完成，本实施例对此不作限制。

[0091] 示例性的，参见图8，本申请提供的操作系统的升级方案，包括：

[0092] S101，根据版本镜像制作升级包。

[0093] 具体的说，在实际应用中，关于拍包服务器制作的升级包，可以根据业务需求制作为差分升级包和全量升级包。

[0094] 示例性的，关于差分升级包的制作，对于比较小且与启动相关的镜像文件全量打包到升级包中，升级的时候采用全量覆盖的方式；而对于比较大的镜像文件，例如super.img，为了减小升级包的大小，则是通过特定的差分算法提取新、老版本super.img里每个逻辑分区镜像的差异，然后生成独立的补丁（patch）文件打包到升级包，在进行操作系统升级的时候再通过特定的差分算法将升级包里的patch文件合并到电子设备super分区里老版本的super.img，这样就可以生成新版本的super.img，即完成将老版本的super.img升级到新版本的super.img。

[0095] 关于全量包的制作，具体是将新版本例的所有镜像文件都进行全量打包到升级包，即不存在单独的补丁文件。

[0096] 具体到实际应用中，差分升级包和全量升级包的制作，参见现有标准即可，本实施例对此不作说明。

[0097] S102，上传升级包。

[0098] 示例性的，在一些实现方式中，升级包可以是由拍包服务器在检测到有新版本的升级包时主动上传到OTA服务器的，也可以是按照预设周期，定时将新发布的升级包主动上传到OTA服务器。

[0099] 示例性的，在另一些实现方式中，拍包服务器上传升级包的条件可以是在接收到OTA服务器的请求后再将新发布的升级包上传到OTA服务器。

[0100] 应当理解的是，上述说明仅是为了更好的理解本实施例的技术方案而列举的示例，不作为对本实施例的唯一限制。

[0101] S103，保存升级包。

[0102] 示例性的，在一些实现方式中，为了避免冗余版本对OTA服务器空间的占用，OTA服务器可以定期对保存的升级包进行遍历，进而清除冗余版本。

[0103] 示例性的，在另一些实现方式中，为了进一步减少对OTA服务器空间的占用，OTA服务器可以定期清理旧版本的升级版。

[0104] 应当理解的是，上述说明仅是为了更好的理解本实施例的技术方案而列举的示例，不作为对本实施例的唯一限制。

[0105] S104，搜索OTA服务器中是否存在升级包。

[0106] 可理解的，通常情况下，面对海量的用户群体，用于升级电子设备中安装的操作系统的升级包是由拍包服务器制作好后上传到OTA服务器进行管理的。而OTA服务器又会与接入的电子设备进行数据交互，即与电子设备之间建立了通信链路。故而，在一些实现方式中，电子设备可以主动向OTA服务器发起搜索请求，以确定OTA服务器中是否存在新版本的操作系统对应的升级包。

[0107] 示例性的，在另一些实现方式中，OTA服务器也可以在检测到有新版本的操作系统对应的升级包时，主动推送通知信息，以告知电子设备当前有新版本的操作系统的升级包。

[0108] 为了便于说明，本实施例以电子设备主动向OTA服务器发起搜索请求，搜索OTA服务器中是否存在新版本的操作系统对应的升级包为例。

[0109] 相应地，如果搜索到OTA服务器中存在新版本的操作系统对应的升级包，执行步骤S105，反之则按照设置的搜索周期定时向OTA服务器发起搜索请求，或者在用户触发时向OTA服务器发起搜索请求。

[0110] 应当理解的是，上述说明仅是为了更好的理解本实施例的技术方案而列举的示例，不作为对本实施例的唯一限制。

[0111] S105，获取升级包。

[0112] 示例性的，在一种可行的实现方案中，电子设备向OTA包服务器发起获取升级包（例如版本1.2）的请求后，OTA服务器向电子设备反馈升级包（例如，由版本1.1升级到版本1.2的系统增量升级包）的下载地址；电子设备根据升级包的下载地址下载升级包，并将级包保存到用户数据分区（Userdata）。

[0113] S106，下发升级包。

[0114] 即，OTA服务器在接收到OUC发起的获取升级包的请求后，响应于该请求，会向OUC下发请求的升级包对应的下载地址，进而使得电子设备能够根据升级包的下载地址下载升级包。

[0115] S107，下发升级指令。

[0116] 可理解的，对于Android系统的电子设备，操作系统的升级是由升级引擎（update_engine）主导完成的。故而，OUC在从OTA服务器下载到升级包，并完成重新设置压缩属性后，会向update_engine下发升级指令，以触发update_engine开始执行升级流程。

[0117] S108，根据升级包中对应于静态分区的升级文件对静态分区升级。

[0118] 示例性的，以进行操作系统升级前电子设备以第一静态分区为启动分区启动，此时在从OTA服务器获取到升级包后，需要对升级包解压，进而得到升级包中针对静态分区的升级文件，然后将得到的针对静态分区的升级文件中的数据写入第二静态分区中对应的子分区。

[0119] 例如，在升级包中包含版本1.2的静态分区的数据，设备将版本1.2的静态分区的数据覆写到静态分区（B）中。

[0120] S109，在静态分区升级完成后，启动静态分区校验线程对静态分区校验。

[0121] 示例性的，在本实施例中，静态分区安装完毕后，update_engine会启动静态分区校验线程，由静态分区校验线程执行静态分区校验，具体是对第二静态分区进行校验。

[0122] S110，在对静态分区校验的过程中，在用户数据分区中创建cow文件，将升级包中对应于动态分区的升级文件写入cow文件。

[0123] 示例性的，在本实施例中，在启动静态分区校验线程对静态分区校验的过程中，update_engine会对动态分区同步安装，即根据升级包中对应于动态分区的升级文件对动态分区进行升级。

[0124] 此外，需要说明的是，在本实施例提供的技术方案中，如果静态分区校验失败，则打断动态分区安装操作，按升级失败处理，向OTA服务器上报升级失败的信息；如果静态分区校验成功，则继续执行对动态分区进行升级的操作，如果对动态分区升级完成，则执行对动态分区的校验操作。

[0125] S111，在将升级包中对应于动态分区的升级文件中的数据全部写入对应的cow文件后，对动态分区校验。

[0126] 示例性的，在本实施例提供的技术方案中，在将升级包中对应于动态分区的升级文件中的数据全部写入对应的cow文件后，不再校验静态分区，只校验动态分区，这样就缩短了一部分校验时间，从而能够快速完成操作系统的升级。

[0127] 相应地，如果静态分区和动态分区均校验成功，则执行步骤S112；如果静态分区和动态分区任一分区校验失败，按升级失败处理，向OTA服务器上报升级失败的信息。

[0128] 为了更好的理解本实施例中步骤S108至步骤S111描述的内容，以下结合图9进行具体说明。

[0129] 示例性的，参见图9，具体包括：

[0130] S201，升级引擎从升级包中解压缩出对应于第二静态分区中的第一升级文件。

[0131] 示例性的，操作系统升级过程中所依赖的升级包中通常会包括用于升级静态分区的升级文件和用于升级动态分区的升级文件。本实施例中为了便于说明，将用于升级静态分区的升级文件称为第一升级文件，将用于升级动态分区的升级文件称为第二升级文件。

[0132] 此外，通过上述描述可知，静态分区（第一静态分区和第二静态分区）中包括多个子分区，例如图5至图7中第一静态分区中包括的X‑loader_a、vendor_a、dtbo_a等，第二静态分区中包括的X‑loader_b、vendor_b、dtbo_b。

[0133] 可理解的，图5至图7给出的仅为一种示例，是为了更好的理解本实施例的技术方案而列举的，不作为对本实施例的唯一限制。

[0134] 此外，可理解的，在虚拟AB系统分区结构中，第一静态分区和第二静态分区互为备份分区，即两个静态分区中的子分区示相互对应的，例如X‑loader_a对应于X‑loader_b，vendor_a对应于vendor_b，dtbo_a对应于dtbo_b。

[0135] S202，升级引擎根据第一升级文件对第二静态分区升级。

[0136] 示例性的，如果从升级包中获取的第一升级文件时对应于dtbo的，根据第一升级文件对第二静态分区中的dtbo_b子分区进行升级，具体是将第一升级文件中的数据写入dtbo_b子分区。

[0137] S203，在第二静态分区升级完后，升级引擎启动静态分区校验线程。

[0138] 示例性的，在一些实现方式中，静态分区校验线程可以是在第二静态分区升级完后，由升级引擎创建并启动的。

[0139] 示例性的，在另一些实现方式中，静态分区校验线程可以是由升级引擎接收到升级指令后创建，在第二静态分区升级完后再由升级引擎启动。

[0140] 示例性的，关于静态分区校验线程对静态分区校验的过程，详见图9中的步骤S301至步骤S305。

[0141] 示例性的，在一些实现方式中，静态分区校验线程对静态分区校验的操作，具体是对静态分区中所有完成升级的子分区进行校验。

[0142] 示例性的，在另一些实现方式中，静态分区校验线程对静态分区校验的操作，具体是对静态分区中所有的子分区进行校验。

[0143] 示例性的，在实际应用中，拍包服务器在制作升级包时，还会制作对应于该升级包的文件列表描述信息（filelist.xml）。

[0144] 示例性的，在filelist.xml中会记录用于校验文件主体、文件元数据所需的哈希值，因此通过对比升级包中第一升级文件的哈希值和写入第二静态分区中第一升级文件对应于的子分区的哈希值，便可以实现对静态分区中子分区的校验。

[0145] S301，静态分区校验线程判断当前校验的静态分区中的子分区是否成功。

[0146] 以图5至图7示出的第二静态分区包括X‑loader_b、vendor_b、dtbo_b这三个子分区为例，如果本次操作系统的升级（从第一操作系统升级到第二操作系统），对上述三个子分区均进行了升级，则静态分区校验线程对静态分区的校验，需要分别对这三个子分区进行校验。故而，在对每一个子分区进行校验后，静态分区校验线程需要判断当前检验的静态分区中的子分区是否成功。

[0147] 相应地，如果成功，则执行步骤S302，反之则执行步骤S303。

[0148] S302，静态分区校验线程将静态分区对应的校验状态修改为“校验成功”。

[0149] S303，静态分区校验线程将静态分区对应的校验状态修改为“校验成功”。

[0150] 示例性的，在本实施例提供的技术方案中，提供了一个用于记录静态分区对应的校验状态的接口，例如图9中示出的StaticPartitionsChkOK（）。如果通过步骤S301的判断确定当前校验的子分区校验成功，静态分区校验线程调用StaticPartitionsChkOK（）设置校验状态。

[0151] 示例性的，在实际应用中，可以通过SetStaticPartitionsChkOK（）实现将静态分区对应的校验状态修改为“校验成功”。

[0152] 示例性的，如果通过步骤S301的判断确定当前校验的子分区校验失败，可以通过SetStaticPartitionsChkOK（）实现将静态分区对应的校验状态修改为“校验失败”。

[0153] 此外，应当理解的是，上述所说的将校验状态设置为“校验失败”或者“校验成功”是为了更好的理解本实施例的技术方案而列举的示例，不作为对本实施例的唯一限制。在实际应用中，可以约定其他内容来表示校验成功和校验失败，例如约定“1”表示校验成功，“0”表示校验失败，或者约定“true”表示校验成功，“false”表示校验失败。

[0154] 示例性的，基于此，在一些实现方式中可以约定在对第二静态分区中的当前校验的子分区校验成功时，由静态分区校验线程将第二静态分区对应的校验状态修改为第一状态；反之，则将第二静态分区对应的校验状态修改为第二状态。

[0155] 示例性的，上述所说的第一状态用于指示当前校验的子分区校验成功，第二状态则用于指示当前校验的子分区校验失败。

[0156] 通过上述描述可知，在本实施例中，静态分区校验线程每校验完毕静态分区的一个子分区，遍调用SetStaticPartitionsChkOK（）来记录一次静态分区对应的校验状态，这样便可以精准的体现静态分区的校验状态，并能够在静态分区的任一子分区校验失败时，及时向升级引擎反馈，以便及时停止动态分区的升级操作，降低系统功耗。

[0157] S304，静态分区校验线程判断是否所有完成升级的静态分区的子分区都校验完成。

[0158] 示例性的，仍以第二静态分区中的X‑loader_b、vendor_b、dtbo_b这三个子分区均需要进行检验为例，如果首次校验的是X‑loader_b子分区，在经步骤S301的判断后，如果确定对X‑loader_b子分区校验成功，则执行步骤S304。由于还有vendor_b、dtbo_b这两个子分区均需要进行检验，因此静态分区校验线程通过判断确定还有完成升级的子分区没有进行校验，故而会继续执行步骤S301，即依次对vendor_b、dtbo_b这两个子分区按照步骤S301至步骤S304的操作校验。

[0159] 示例性的，如果当前校验的子分区为dtbo_b子分区，静态分区校验线程再次执行步骤S304后确定没有需要校验的子分区，即所有完成升级的子分区都校验完成，此时进入步骤S305，结束对静态分区的校验。

[0160] 应当理解的是，上述说明仅是为了更好的理解本实施例的技术方案而列举的示例，不作为对本实施例的唯一限制。

[0161] S305，静态分区校验线程结束对静态分区的校验。

[0162] 示例性的，如果静态分区校验线程对静态分区中所有的子分区完成校验，并且所有的子分区都校验成功时，动态分区还没有升级完毕，则静态分区校验线程之间结束对静态分区的校验操作即可。

[0163] S204，升级引擎从升级包中解压缩出对应于动态分区的第二升级文件。

[0164] S205，升级引擎通知snap进程在用户数据分区中创建第二升级文件对应的子分区的cow文件。

[0165] 可理解的，在实际应用中，snap进程接收到升级引擎下发的创建第二升级文件对应的子分区的cow文件的指令后，会根据指令创建对应的cow文件。

[0166] 相应地，如果创建成功snap进程便会向升级引擎反馈创建成功的反馈信息，以便升级引擎将第二升级文件写入cow文件，即执行下文的步骤S206。

[0167] 相应地，如果创建失败，比如因为用户数据分区空间不足导致无法创建该cow文件，snap进程便会向升级引擎反馈创建失败的反馈信息，这样升级引擎便会直接结束对动态分区的升级操作，向OTA服务器上报升级失败的信息。

[0168] 为了便于说明，本实施例以创建成功为例进行后续步骤的说明。

[0169] S206，升级引擎将第二升级文件写入cow文件。

[0170] S207，升级引擎判断是否向cow文件写入了1%（增量）的数据。

[0171] 可理解的，由于用于升级动态分区的第二升级文件通常较大，因此升级时间相对较长，为了能够在静态分区校验与动态分区升级并行执行的过程中，根据静态分区的校验结果确定是否进行后续的升级操作，以便在静态分区校验失败时，及时停止对动态分区的升级操作，从而更好的降低电子设备的功耗。本实施例中规定升级引擎对动态分区每完成第一数据，如步骤S207中所说的1%的升级进度就调用一次获取记录了静态分区对应的校验状态的接口，例如约定IsStaticPartitionsChkOK（）接口为获取SetStaticPartitionsChkOK（）接口记录的校验状态的接口，则升级引擎在判断向第二升级文件对应的cow文件写入了1%（增量）的数据后，变调用IsStaticPartitionsChkOK（）接口获取静态分区校验线程通过SetStaticPartitionsChkOK（）接口记录的校验状态，即执行步骤S208；否则，继续执行步骤S206向第二升级文件对应的cow文件写入第二升级文件中的数据。

[0172] 可理解的，上述所说的第一数据实质为第二升级文件中的部分数据。

[0173] 示例性的，在另一些实现方式中，除了按照步骤S207给出的方式获取静态分区的校验状态，还可以规定在每完成一个动态分区中的子分区的数据的写入后调用一次获取记录了静态分区对应的校验状态的接口。

[0174] 示例性的，在另一些实现方式中，还可以规定每完成一个动态分区中的子分区的数据块（block）的写入或几个block的写入后调用一次获取记录了静态分区对应的校验状态的接口。

[0175] 应当理解的是，上述说明仅是为了更好的理解本实施例的技术方案而列举的示例，不作为对本实施例的唯一限制。在实际应用中，升级引擎对动态分区每完成多少增量获取一次静态分区的校验状态可以根据实际业务需求设置，此处不作限制。

[0176] S208，升级引擎获取StaticPartitionsChkOK()中记录的校验状态。

[0177] S209，升级引擎判断校验状态是否为“校验成功”。

[0178] 示例性的，如果通过判断，确定校验状态为“校验成功”或者指示校验成功的其他标识信息，则执行步骤S210；否则，直接停止对动态分区的升级，按升级失败处理，向OTA服务器上报升级失败的信息，即执行步骤S214。

[0179] 需要说明的是，在实际应用中，可能会存在升级引擎已经向cow文件写入了1%的数据，但是静态分区校验线程还没有完成对静态分区中完成升级的任一子分区的校验，因此升级引擎获取StaticPartitionsChkOK()中记录的校验状态时，可能存在获取不到校验状态的情况。对于这种场景，可以约定升级引擎继续执行步骤S216的操作。

[0180] S210，升级引擎判断第二文件的数据是否全部写入了cow文件。

[0181] 示例性的，如果通过判断确定第二升级文件的数据已经全部写入了对应的cow文件（或者说用于升级动态分区的所有升级文件均写入了对应的cow文件，即完成了对动态分区的升级），则执行步骤S211；否则，继续执行步骤S206向第二升级文件对应的cow文件写入第二升级文件中的数据。

[0182] S211，升级引擎对动态分区校验。

[0183] 示例性的，由于升级动态分区的第二升级文件是以增量的形式写入用户数据分区中对应的cow文件，因此在升级引擎对动态分区校验时，需要对动态分区和用户数据分区中对应的cow文件进行整体校验。

[0184] S212，升级引擎判断动态分区是否校验成功。

[0185] 示例性的，如果校验成功，则执行步骤S213；否则，按升级失败处理，向OTA服务器上报升级失败的信息，即执行步骤S214。

[0186] S213，升级引擎向OTA服务器上报升级成功的信息。

[0187] S214，升级引擎向OTA服务器上报升级失败的信息。

[0188] 继续参见图9，示例性的，在本实施例提供的技术方案中，步骤S204至步骤S210，与步骤S301至步骤S305是并行执行的，即步骤S204至步骤S210执行期间，步骤S301和步骤S305是同步执行的，由此，实现了静态分区校验和动态分区升级的并行执行，从而缩短了操作系统整体的升级时间，降低了电子设备的功耗。

[0189] 应当理解的是，上述说明仅是为了更好的理解本实施例的技术方案而列举的示例，不作为对本实施例的唯一限制。

[0190] S112，在静态分区和动态分区均校验成功后，触发整机重启。

[0191] 示例性的，在校验完成后，OUC会触发电子设备进行整机重启。关于OUC触发电子设备进行整机重启的操作，详见上述实施例中关于图6中步骤（5）关于重启部分的描述，此处不再赘述。

[0192] S113，重启过程中，加载cow文件中的数据。

[0193] 示例性的，以电子设备进行操作系统升级前是从第一静态分区启动，即启动时加载的是基础分区的数据、第一静态分区的数据、动态分区的数据运行的操作系统为第一操作系统（升级前的操作系统）为例，在电子设备进行操作系统升级后重启电子设备时，依次加载的是基础分区的数据、第二静态分区的数据、动态分区的数据和用户数据分区中cow文件中的数据，这样在完成上述加载后，电子设备便可以运行到第二操作系统，即升级后的操作系统。

[0194] 此外，需要说明的是，由于本实施例是以电子设备在进行操作系统的升级前是以第一静态分区为启动顺序进行启动，即启动时依次加载的是基础分区的数据、第一静态分区的数据、动态分区的数据，故而上述操作系统的升级方案中升级的是第二静态分区，因此重启时需要加载第二静态分区的数据，即启动顺序从第一静态分区变更为从第二静态分区启动。

[0195] S114，重启后，执行Merge操作，将cow文件中的数据落盘到动态分区对应的子分区。

[0196] 可理解的，本实施例中所说的Merge操作具体是指将用户数据分区中升级动态分区的升级文件落盘到动态分区的过程，即cow文件中的数据落盘到动态分区中对应子分区的过程。

[0197] 关于Merge操作的具体实现流程，参见现有标准即可，本实施例对此不再赘述。

[0198] S115，上报Merge结果。

[0199] 示例性的，在Merge操作执行完成后，内核会向升级引擎上报Merge结果，以便升级引擎获知用户数据分区中升级动态分区的升级文件是否落盘到动态分区。

[0200] 相应地，如果Merge成功，即用户数据分区中升级动态分区的升级文件落盘到动态分区，则执行步骤S116，否则可以直接通过OUC向OTA服务器上报升级失败。

[0201] 示例性的，在一些实现方式中，在Merge操作失败后，OUC可以重启电子设备，控制电子设备从第二操作系统回滚到第一操作系统，这样即便升级失败也可以保证电子设备能够正常使用。

[0202] S116，在Merge成功后，对静态分区进行分区同步。

[0203] 示例性的，仍以根据升级包中对应于静态分区的升级文件升级的是第二静态分区的数据为例，则在Merge成功后，对静态分区进行的分区同步操作，具体是将第二静态分区的数据同步到第一静态分区。

[0204] 关于将第二静态分区的数据同步到第一静态分区的操作，在一些实现方式中，例如可以是由内核读取第二静态分区的各个子分区中的数据；然后将第二静态分区的各个子分区中的数据覆写到第一静态分区对应的子分区中。

[0205] 可理解的，由于实际应用中，操作系统的升级可能仅对静态分区中的某一个或某几个子分区进行了升级，因此在进行分区同步时，为了减少分区同步对电子设备资源的占用，可以先检验第二静态分区中第一子分区内的数据是否与第一静态分区中第二子分区内的数据相同。

[0206] 相应地，如果第一子分区内的数据与第二子分区内的数据相同（一致），则跳过对该子分区的拷贝，继续比对其他子分区；反之则对第一子分区内的数据进行拷贝，然后覆写到第二子分区。

[0207] 示例性的，对于上述所说的先检验第二静态分区中第一子分区内的数据是否与第一静态分区中第二子分区内的数据相同，再根据检验结果决定是否进行分区同步的方案，在具体实现时，处理可以是：

[0208] 首先，计算第一子分区的数据的哈希值和第二子分区的数据的哈希值。

[0209] 具体的说，第一子分区为第二静态分区的一个子分区，第二子分区为第一静态分区的一个子分区，并且，第二子分区与第一子分区相对应。

[0210] 示例性的，继续参见图7，如果第二静态分区中的第一子分区为dtbo_b，则第一静态分区中与第一子分区对应的第二子分区为dtbo_a。

[0211] 应当理解的是，上述说明仅是为了更好的理解本实施例的技术方案而列举的示例，不作为对本实施例的唯一限制。

[0212] 然后，当第一子分区的数据的哈希值与第二子分区的数据的哈希值不一致时，将第一子分区中的数据覆写到第二子分区中。

[0213] 此外，需要说明的是，关于步骤S116中的操作，并不构成对本申请提供的技术方案的限定，在实际应用中，步骤S116可以执行，也可以不执行，此处不作限制。

[0214] S117，上报升级结果。

[0215] 示例性的，在执行完静态分区同步操作后，不论分区同步是否成功，OUC均会向OTA服务器上报升级结果，以便OTA服务器获知本次操作系统的升级是否成功。关于OUC向OTA服务器上报升级结果的操作，详见上述实施例中关于图7中（8）上报升级结果部分的描述，此处不再赘述。

[0216] 不难发现，本实施例提供的操作系统的升级方案中，将操作系统升级过程中的安装过程和校验过程，从串行执行修改为并行执行，从而既能够保证操作系统快速升级完成，又缩短了对休眠锁的持有时间，解决了由于操作系统升级导致电子设备整机功耗高的问题。

[0217] 示例性的，基于本实施例提供的操作系统的升级方案，分别以差分升级包和全量升级包为例对操作系统进行升级，经测试发现采用本实施例提供的操作系统的升级方案，对于差分包升级，升级过程中校验时间大约降低了10%。对于全量包升级，升级过程中校验时间大约降低了20%。

[0218] 应当理解的是，上述说明仅是为了更好的理解本实施例的技术方案而列举的示例，不作为对本实施例的唯一限制。

[0219] 此外，考虑到操作系统的升级过程中，电子设备可能会因为一些外在因素导致掉电重启，例如在升级过程中用户长按电源Power键强制重启了电子设备，为了保证这种场景下，本申请提供的操作系统的升级方案同样可以适用，即能够在电子设备调度重启后，接续升级的过程中继续采用并行执行的方式，以缩短升级时间。在掉电重启，从掉电前的断点接续升级时，并行执行的操作会根据当前的升级进度有所不同。

[0220] 可理解的，强制重启后电子设备进行接续升级需要依赖存储在用户数据分区中的断点记录文件中记录的断点信息，故而在虚拟AB系统分区结构的电子设备进行操作系统升级的过程中，即升级引擎根据第一升级文件升级第二静态分区，根据第二升级文件升级动态分区的过程中，升级引擎会向断点记录文件记录断点信息，从而能够在电子设备掉电重启后，根据断点记录文件中记录的断点信息快速、准确的定位接续升级的位置。

[0221] 示例性的，在本实施例中，断点信息标识的断点为电子设备重启后接续升级的位置。

[0222] 示例性的，在掉电重启后，如果根据断点记录文件中记录的断点信息确定接续升的分区为第二静态分区，即升级引擎检测到静态分区还未升级完，则从掉电前的断点接续升级时，继续根据升级包中对应于静态分区的升级文件对静态分区升级，并在静态分区升级完后，重新启动静态分区校验线程，由静态分区校验线程对静态分区进行校验，即执行图9中步骤S301至步骤S305的操作，同时升级引擎根据升级包中对应于动态分区的升级文件对动态分区升级，即执行图9中步骤S204至步骤S210的操作。

[0223] 关于从掉电前的断点位置，对第二静态分区进行接续升级的过程，例如是根据断点信息从第一升级文件中断点信息标识的断点所在的位置读取数据，根据读取到的数据升级第二静态分区，具体为将读取到的数据写入第二静态分区中第一升级文件对应的子分区。

[0224] 示例性的，在掉电重启后，如果根据断点记录文件中记录的断点信息确定接续升的分区为动态分区，即升级引擎检测到静态分区已经升级完成，但动态分区还没有开始升级，则不论掉电前静态分区校验线程是否完成了对静态分区的校验，为了避免掉电导致静态分区的数据出现异常，在从掉电前的断点接续升级时，重新启动静态分区校验线程对静态分区校验，即执行图9中步骤S301至步骤S305的操作，同时升级引擎根据升级包中对应于动态分区的升级文件对动态分区升级，即执行图9中步骤S204至步骤S210的操作。

[0225] 关于从掉电前的断点位置，对动态分区进行接续升级的过程，例如是根据断点信息从第二升级文件中断点信息标识的断点所在的位置读取数据，根据读取到的数据升级动态分区，具体为将读取到的数据写入用户数据分区中第二升级文件对应的cow文件。

[0226] 示例性的，在掉电重启后，如果升级引擎检测到静态分区已经升级完成，并且动态分区也已经升级完成，为了避免掉电导致静态分区和动态分区的数据出现异常，在从掉电前的断点接续升级时，重新启动静态分区校验线程对静态分区校验，即执行图9中步骤S301至步骤S305的操作，同时升级引擎对动态分区进行校验，即执行图9中步骤S211和步骤S212的操作。

[0227] 由此，即便虚拟AB系统分区结构的电子设备在操作系统的升级过程中出现掉电，在电子设备重启根据断点记录文件中记录的断点信息接续升级时，通过并行执行针对静态分区的操作和动态分区的操作，从而依旧能够缩短操作系统的整体升级时长，从而降低了升级过程中对电子设备的功耗。

[0228] 此外，为了更好的理解基于本实施例提供的技术方案实现操作系统升级的整个流程，以下结合图10进行说明。

[0229] 需要说明的是，图10所示的实现操作系统的升级流程是针对虚拟AB系统分区结构实现的，在电子设备当前是从第一静态分区（上述附图中的SlotA）启动时，电子设备按照如图10所示的流程实现操作系统的升级。

[0230] S401，电子设备依次加载基础分区的数据、第一静态分区的数据以及动态分区的数据，从第一静态分区启动，以运行第一操作系统。

[0231] S402，电子设备中的系统升级客户端在搜索到升级包时，从OTA服务器获取升级包。

[0232] 示例性的，在一种可行的实现方案中，电子设备定期向OTA包服务器发起搜包请求，搜包请求包含电子设备当前运行的操作系统的版本号（例如版本1.1）；OTA服务器根据搜包请求中的操作系统的版本号，检索当前是否存在更新版本号的升级包（例如版本1.2）；当存在更新版本的升级包时，OTA服务器向电子设备反馈升级包（例如，由版本1.1升级到版本1.2的系统增量升级包）的下载地址；电子设备根据升级包的下载地址下载升级包，并将级包保存到用户数据分区（Userdata）。

[0233] S403，电子设备中的升级引擎根据升级包中对应于第二静态分区的升级文件对第二静态分区进行升级。

[0234] 例如，版本1.1升级到版本1.2的系统增量升级包包含版本1.2的静态分区的全量数据，电子设备将版本1.2的静态分区的数据覆写到第二静态分区（上述附图中的SlotB）中。

[0235] S404，在第二静态分区升级完成后，升级引擎启动静态分区校验线程对第二静态分区校验。

[0236] S405，在静态分区校验线程对第二静态分区校验的过程中，升级引擎将升级包中对应于动态分区的升级文件的数据写入用户数据分区中对应该子分区的cow文件。

[0237] 关于和步骤S404步骤S405中，并行执行对第二静态分区的校验和对动态分区的升级的操作，详见上文针对图9中步骤S301至步骤S305的文字描述，以及上文针对图9中步骤S204至步骤S210的文字描述，此处不再赘述。

[0238] S406，在第二静态分区校验成功，且升级包中对应于动态分区的升级文件中的数据全部写入对应该子分区的cow文件后，升级引擎对动态分区校验。

[0239] 示例性的，通过上述描述可知，对于采用虚拟AB系统分区结构的电子设备，在进行操作系统升级时，动态分区的升级需要借助用户数据分区，即需要在用户数据分区创建与需要升级的动态分区中的子分区对应的cow文件，然后将升级文件的数据写入cow文件，以完成对动态分区中需要升级的子分区的升级。

[0240] 为了便于理解，以下结合实例对动态分区的升级以及校验过程进行具体说明。

[0241] 示例性的，升级引擎根据升级包中对应于动态分区的升级文件，在用户数据分区（Userdata）创建对应该子分区的cow文件（也可以理解为在用户数据分区中创建了一个虚拟动态分区，即每一个子分区对应的cow文件是一个虚拟动态分区），进而在该cow文件中写入动态分区（Super）的升级数据。

[0242] 例如，在升级包中包含版本1.2的动态分区的数据，电子设备在用户数据分区中创建的cow文件中写入版本1.2的动态分区（Super）的数据。

[0243] 进一步的，在虚拟AB系统分区结构的电子设备的操作系统的升级方案中，针对动态分区（Super），采用增量升级方式。在升级过程中，用户数据分区（Userdata）的cow文件中保存的并不是升级后新版本的动态分区（Super）的全部文件，而是旧版本的动态分区（Super）中需要升级的数据在升级后的升级结果。即，用户数据分区（Userdata）的cow文件中保存的是动态分区的更新数据。

[0244] 以system子分区为例，假设在版本1.1中，system子分区中的数据可以分为system1、system2两部分。从版本1.1升级到版本1.2，数据system2没有发生变化，数据syetem1被升级为system3。那么，在步骤S405中，电子设备在用户数据分区（Userdata）创建cow文件，在cow文件中写入数据system3。

[0245] 例如，版本1.1升级到版本1.2的系统增量升级包包含版本1.1升级到版本1.2的动态分区（Super）更新数据，该动态分区（Super）更新数据包含数据system3。

[0246] 进一步的，在虚拟AB系统分区结构的电子设备的操作系统的升级方案中，基于快照技术（snapshot）实现动态分区（Super）的增量升级。具体的，用户数据分区（Userdata）的cow文件中，采用写时拷贝（Copy‑On‑Write，cow）文件保存动态分区（Super）的升级数据。

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

[0248] 在步骤S402所获取的升级包中，动态分区（Super）的升级数据的cow文件以二进制代码形式压缩保存。在升级包中，每个cow文件根据其所针对的动态分区（Super）子分区所命名。例如，针对System子分区的cow文件被命名为system‑cow‑img.img.0000。

[0249] 在步骤S405中，电子设备解包升级包以获取所有的cow文件，为每个cow文件附加AB分区标记。具体的，当电子设备当前从第一静态分区（上述附图中的SlotA）启动时，可以理解为电子设备当前运行操作系统所加载的动态分区（Super）为动态分区（A）。在升级操作系统时，用户数据分区（Userdata）中创建的cow文件是针对动态分区（B）。因此，为cow文件附加对应动态分区（B）的名称标记_b。例如，为system‑cow‑img.img.0000附加_b生成system_b‑cow‑img.img.0000。

[0250] 进一步的，在步骤S405中，在用户数据分区（Userdata）中创建Update文件夹，将重命名的cow文件保存到Update文件夹下。例如，在一应用场景中，在向用户数据分区（Userdata）写入cow文件后，用户数据分区（Userdata）的Update文件夹中包含下述文件：

[0251] system_b‑cow‑img.img.0000；

[0252] system_ext_b‑cow‑img.img.0000；

[0253] vendor_b‑cow‑img.img.0000；

[0254] product_b‑cow‑img.img.0000；

[0255] cust_b‑cow‑img.img.0000；

[0256] odm_b‑cow‑img.img.0000。

[0257] 具体的，cow文件中包含cow文件自身的cow文件地图（快照map）以及升级数据。

[0258] cow文件地图（快照）与cow文件所针对的动态分区（Super）的子分区的文件地图相对应。动态分区（Super）的子分区的文件地图用于描述当前版本的操作系统（本次升级之前的版本，例如，版本1.1）动态分区（Super）的子分区中的所有文件以及各个文件的保存地址。

[0259] cow文件中的升级数据为相较于当前版本的子分区数据，新版本的子分区数据中被更新的文件；cow文件自身的cow文件地图则用于描述被更新的文件与当前版本的子分区中的文件间的对应关系以及被更新的文件的保存地址。

[0260] 基于动态分区（Super）的子分区的文件地图以及cow文件中的cow文件地图，就可以使用cow文件中的升级数据替换动态分区（Super）的子分区中的对应文件，从而实现动态分区（Super）数据的升级。具体的，在需要获取动态分区（Super）的子分区的文件地图时，可以基于snapshot对动态分区（Super）的子分区的数据进行快照操作以生成动态分区（Super）的子分区的文件地图。也可以在制作升级包时，预先生成动态分区（Super）的子分区的文件地图，将该文件地图加入到cow文件中。

[0261] 以System子分区为例，假设System子分区中按照以下路径保存数据：

[0262] /system/app/A0.XXX；

[0263] /system/app/A1.XXX；

[0264] /system/app/A2.XXX；

[0265] /system/B0.XXX；

[0266] /system/B1.XXX；

[0267] /system/user/C0.XXX；

[0268] /system/user/C1.XXX；

[0269] /system/user/C2.XXX；

[0270] /system/user/C3.XXX。

[0271] System子分区的文件地图可以是：

[0272] /system/app/A0.XXX：024010 024013；~

[0273] /system/app/A1.XXX：024014 024017；~

[0274] /system/app/A2.XXX：024018 024020；~

[0275] /system/B0.XXX：024021 024026；~

[0276] /system/B1.XXX：024027 024028；~

[0277] /system/user/C0.XXX：024029 024032；~

[0278] /system/user/C1.XXX：024033 024035；~

[0279] /system/user/C2.XXX：024036 024040；~

[0280] /system/user/C3.XXX：024041 024044。~

[0281] 文件名后的数值（例如，/system/app/A0.XXX：024010 024013中的024010~ ~024013）为该文件在动态分区（Super）的System子分区的物理保存地址（块地址）。

[0282] 假设当前操作系统升级需要更新数据/system/app/A2.XXX以及/system/user/C2.XXX。

[0283] 可以视为：

[0284] /system/app/A2.XXX以及/system/user/C2.XXX为system子分区数据的system1部分；

[0285] /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部分。

[0286] 那么，针对System子分区的cow文件（system_b‑cow‑img.img.0000）就包含最新版的/system/app/A2.XXX以及/system/user/C2.XXX。

[0287] 可以视为，最新版的/system/app/A2.XXX以及/system/user/C2.XXX为system3。升级目标是使用system3更新掉system1。

[0288] 当cow文件中的更新数据的大小与其所要更新的原始数据的大小一致，并且，cow文件中的更新数据在数据更新后在子分区中的保存位置与其所要更新的原始数据在子分区中的保存位置一致时，cow文件（system_b‑cow‑img.img.0000）自身的cow文件地图可以为：

[0289] /system/app/A2.XXX：

[0290] Map1（原Super分区中待更新数据的地址）：起始地址address start：024018（相对于System子分区起始地址的偏移量）；偏移量大小size：2（即024018 024020地址段的数据）~

[0291] Map2（cow文件中存储的更新数据的地址）：起始地址address start：045033（相对于cow文件存储的起始地址的偏移量）；偏移量大小size：2（即045033 045035地址段的数~据）；

[0292] /system/user/C2.XXX：

[0293] Map1（原Super分区中待更新数据的地址）：起始地址address start：024036（相对于System子分区起始地址的偏移量）；偏移量大小size：4（即024036 024040地址段的数据）~

[0294] Map2（cow文件中存储的更新数据的地址）：起始地址address start：045036（相对于cow文件存储的起始地址的偏移量）；偏移量大小size：4（即045036 045040地址段的数~据）。

[0295] 当cow文件中的更新数据的大小与其所要更新的原始数据的大小不一致时，cow文件（system_b‑cow‑img.img.0000）自身的cow文件地图可以为：

[0296] /system/app/A2.XXX：

[0297] Map1.1（原Super分区中待更新数据的地址）：起始地址address start：024018（相对于System子分区起始地址的偏移量）；偏移量大小size：2（即024018 024020地址段的数~据）

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

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

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

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

[0302] 在上述例子中，地址段（045033 045035以及045036 045040）分别为cow文件~ ~（system_b‑cow‑img.img.0000）中最新版的/system/app/A2.XXX以及/system/user/C2.XXX在用户数据分区（Userdata）的物理保存地址（块地址）。

[0303] 这样，如果使用地址045033 045035上的A2.XXX替换掉地址024018 024020上的~ ~A2.XXX，并且，使用地址045036 045040上的C2.XXX替换掉地址024036 024040上的C2.XXX，~ ~
就可以完成动态分区（Super）的System子分区的数据升级。

[0304] 进一步的，在步骤S405中，在将cow文件写入用户数据分区（Userdata）后，还需要对动态分区（Super）+cow文件进行整体校验，校验动态分区（Super）+cow文件的有效性，验证当前版本的动态分区（Super）数据+cow文件的合成结果是否为新版本的动态分区（Super）数据。

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

[0306] 具体的，在校验过程中，基于snapshot合并动态分区（Super）+cow文件。在snapshot的实现过程中，动态分区（Super）与cow文件的合并并不是物理意义上的合并，而是将动态分区（Super）中子分区的文件地图与cow文件自身的cow文件地图进行合并，生成新版本的子分区数据的文件地图。

[0307] 例如，将System子分区的文件地图“/system/app/A0.XXX：024010 024013；/~system/app/A1.XXX：024014 024017；/system/app/A2.XXX：024018 024020；/system/~ ~
B0.XXX：024021 024026；/system/B1.XXX：024027 024028；/system/user/C0.XXX：024029~ ~ ~
024032；/system/user/C1.XXX：024033 024035；/system/user/C2.XXX：024036 024040；/~ ~
system/user/C3.XXX：024041 024044。”与cow文件地图“/system/app/A2.XXX：045033~ ~
045035；/system/user/C2.XXX：045036 045040。”合并。则得到System子分区的新版本的文~
件地图：

[0308] /system/app/A0.XXX：024010 024013（指向动态分区（Super）中/system/app下的~A0.XXX）；

[0309] /system/app/A1.XXX：024014 024017（指向动态分区（Super）中/system/app下的~A1.XXX）；

[0310] /system/app/A2.XXX：045033 045035（指向用户数据分区（Userdata）中/Update/~system_b‑cow‑img.img.0000中的A2.XXX）；

[0311] /system/B0.XXX：024021 024026（指向动态分区（Super）中/system下的B0.XXX）；~

[0312] /system/B1.XXX：024027 024028（指向动态分区（Super）中/system下的B1.XXX）；~

[0313] /system/user/C0.XXX：024029 024032（指向动态分区（Super）中/system/user下~的C0.XXX）；

[0314] /system/user/C1.XXX：024033 024035（指向动态分区（Super）中/system/user下~的C1.XXX）；

[0315] /system/user/C2.XXX：045036 045040（指向用户数据分区（Userdata）中/~Update/system_b‑cow‑img.img.0000中的C2.XXX）；

[0316] /system/user/C3.XXX：024041 024044（指向动态分区（Super）中/system/user下~的C3.XXX）。

[0317] 在新版本的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。

[0318] 在校验过程中，按照上述合成方式，获取动态分区（Super）的所有子分区的新版本的文件地图（如果用户数据分区（Userdata）中并未写入某个子分区的对应cow文件，则直接以该子分区的文件地图为新版本的文件地图）。将所有子分区的新版本的文件地图组合生成动态分区（Super）的新版本的文件系统。

[0319] 基于动态分区（Super）的新版本的文件系统读取数据，读取动态分区（Super）的新版本的文件系统所包含的所有文件并计算哈希值。

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

[0321] S407，升级引擎将电子设备的启动顺序由从第一静态分区启动变更为从第二静态分区启动。

[0322] 例如，改写主引导记录（Master Boot Record，MBR）的启动顺序标识，将启动顺序标识由A改写为B。在电子设备上电后，当电子设备读取到启动顺序标识为A，电子设备从第一静态分区（上述附图中的SlotA）启动，启动过程中加载第一静态分区（上述附图中的SlotA）的数据；当电子设备读取到启动顺序标识为B，电子设备从第二静态分区（SlotB）启动，启动过程中加载第二静态分区（SlotB）的数据。

[0323] S408，系统升级客户端触发电子设备进行重启。

[0324] 示例性的，系统升级客户端在触发电子设备进行重启时，会退出当前的第一操作系统，切断电子设备电源，然后再开启电子设备电源。

[0325] S409，电子设备依次加载基础分区的数据、第二静态分区的数据以及动态分区的数据，用户数据分区中cow文件中的数据，从第二静态分区启动，以运行第二操作系统。

[0326] 示例性的，电子设备首先加载基础分区（Common）的数据，在加载基础分区（Common）的过程中，电子设备读取基础分区（Common）中的启动标记；当基础分区（Common）中的启动标记为（A）时，设备在加载基础分区（Common）之后会加载第一静态分区（SlotA），从而从第一静态分区（SlotA）启动；当基础分区（Common）中的启动标记为（B）时，电子设备在加载基础分区（Common）之后会加载第二静态分区（SlotB），从而从第二静态分区（SlotB）启动。

[0327] 在S409中，电子设备读取基础分区（Common）中的启动标记。基础分区（Common）中的启动标记为（B），电子设备在加载基础分区（Common）之后加载第二静态分区（SlotB），从第二静态分区（SlotB）启动。

[0328] 示例性的，电子设备在加载完第二静态分区（SlotB）的数据，加载动态分区（Super）以及用户数据分区（Userdata）的cow文件中的数据时，具体的为：电子设备读取元数据（/metadata）中的落盘状态信息，基于落盘状态信息确定是否需要从用户数据分区（Userdata）的指定路径中检索cow文件，并采用snapshot合并加载动态分区（Super）以及cow文件。

[0329] 进一步的，在步骤S409中，电子设备并不加载动态分区（Super）以及用户数据分区（Userdata）中的全部cow文件，而是根据第二操作系统运行需求加载对应的文件。具体的，在步骤S409中，电子设备根据第二操作系统运行需求确定需要加载的文件，基于snapshot从动态分区（Super）或用户数据分区的cow文件中提取对应的文件进行加载。

[0330] 具体的，在步骤S409中，当动态分区（Super）的子分区首存在对应的cow文件时，先基于snapshot生成动态分区（Super）各个子分区的新版本的文件地图。生成新版本的文件地图的过程可以参照步骤S405。电子设备根据第二操作系统运行需求确定需要加载的文件，基于动态分区（Super）子分区的新版本的文件地图进行文件加载。

[0331] 例如，第二操作系统运行需求加载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子分区的新版本的文件地图中：

[0332] /system/user/C0.XXX：024029 024032；~

[0333] /system/user/C1.XXX：024033 024035；~

[0334] /system/user/C2.XXX：045036 045040；~

[0335] /system/user/C3.XXX：024041 024044。~

[0336] 加载地址024029 024032处的C0.XXX、地址024033 024035处的C1.XXX、地址~ ~045036 045040处的C2.XXX以及地址024041 024044处的C3.XXX。
~ ~

[0337] 进一步的，在加载System子分区下目录user（/system/user）中的所有数据时，当落盘状态信息中System子分区的子分区标识为“已落盘（Merged）”时，电子设备就不会在用户数据分区（Userdata）中/Update下搜索cow文件，而是直接加载System子分区下目录user（/system/user）中的所有数据。

[0338] 进一步的，在加载System子分区下目录user（/system/user）中的所有数据时，当落盘状态信息中System子分区的子分区标识为“未落盘（wait for Merge）”时，如果电子设备在用户数据分区（Userdata）中/Update下未搜索到对应System子分区的cow文件时，则说明升级过程中数据写入错误（cow文件写入错误或者落盘状态信息写入错误），此时电子设备回滚到第一操作系统并向OTA服务器上报升级失败的日志信息。

[0339] 进一步的，电子设备在加载动态分区（Super）以及用户数据分区（Userdata）的cow文件中的数据的过程中，在加载文件之前，电子设备还需要对加载文件进行校验。不同于步骤S406，在步骤S409中，不对动态分区（Super）+cow文件进行整体验证，而是仅对需要加载的文件进行验证。例如，基于dmverity进行校验（dm‑verity是dm（device mapper）的一个目标（target），是一个虚拟块电子设备，专门用于文件系统的校验）。校验成功则加载文件，校验失败则重启电子设备，回滚到第一操作系统或者尝试再次加载文件。

[0340] S410，电子设备成功启动，进入用户交互界面。

[0341] S411，内核执行Merge操作，将cow文件中的数据落盘到动态分区对应的子分区。

[0342] 可理解的，在本申请中，Merge操作具体是指在操作系统升级过程中，将用户数据分区（Userdata）中保存的动态分区（Super）升级文件（cow文件）写入到动态分区（Super）中，使得动态分区（Super）的文件完成数据升级，以便电子设备在下次启动时不需要加载动态分区（Super）和用户数据分区的cow文件，只需加载动态分区（Super）就可以完成电子设备启动。

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

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

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

[0346] 例如，基于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上。
~ ~

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

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

[0349] S412，内核将第二静态分区的数据同步到第一静态分区。

[0350] 基于上述升级流程，假设第一静态分区（SlotA）对应版本1.1的操作系统，电子设备从第一静态分区（SlotA）启动运行版本1.1的操作系统；当操作系统升级到1.2时，电子设备重启后从第二静态分区（SlotB）启动运行版本1.2的操作系统；此时，电子设备运行版本1.2的操作系统。第一静态分区（SlotA）对应版本1.1的操作系统，第二静态分区（SlotB）对应版本1.2的操作系统，第一静态分区（SlotA）与第二静态分区（SlotB）中的数据并不一致。
假设第二静态分区（SlotB）出现错误，第一静态分区（SlotA）无法取代第二静态分区（SlotB）的功能，即第一静态分区（SlotA）无法支持电子设备运行版本1.2的操作系统。然而，如果始终保持第一静态分区（SlotA）与第二静态分区（SlotB）间数据的一致，那么，当第一静态分区（SlotA）或第二静态分区（SlotB）出现错误，就可以使用另一个静态分区。

[0351] 因此，在完成Merge操作后，通过对静态分区进行分区同步，即在第一静态分区（SlotA）与第二静态分区（SlotB）间相互备份数据，从而保持第一静态分区（SlotA）与第二静态分区（SlotB）中数据的一致，这样便可以解决上述技术问题。

[0352] 关于内核将第二静态分区的数据同步到第一静态分区的具体实现细节，详见上文针对图8中步骤S116的文字描述，此处不再赘述。

[0353] 此外，需要说明的是，在实际的应用场景中由电子设备实现的上述各实施例提供的操作系统的升级方法，也可以由电子设备中包括的芯片系统来执行，其中，该芯片系统可以包括处理电路、接收管脚和发送管脚，接收管脚、发送管脚和处理电路通过内部连接通路互相通信。该处理电路与存储器耦合，使得该芯片系统运行时调用该存储器中存储的计算机程序，实现上述电子设备执行的步骤。

[0354] 此外，需要说明的是，该芯片系统中的处理电路可以是应用处理器也可以是非应用处理器。

[0355] 此外，本申请实施例还提供一种计算机可读存储介质，该计算机存储介质中存储有计算机指令，当该计算机指令在电子设备上运行时，使得电子设备执行上述相关方法步骤实现上述实施例中的操作系统的升级方法。

[0356] 此外，本申请实施例还提供了一种计算机程序产品，当该计算机程序产品在电子设备上运行时，使得电子设备执行上述相关步骤，以实现上述实施例中的操作系统的升级方法。

[0357] 此外，通过上述描述可知，本申请实施例提供的电子设备、计算机可读存储介质、计算机程序产品、芯片均用于执行上文所提供的对应的方法，因此，其所能达到的有益效果可参考上文所提供的对应的方法中的有益效果，此处不再赘述。

[0358] 以上所述，以上实施例仅用以说明本申请的技术方案，而非对其限制；尽管参照前述实施例对本申请进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分技术特征进行等同替换；而这些修改或者替换，并不使相应技术方案的本质脱离本申请各实施例技术方案的范围。