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

Abstract

本申请提供了一种操作系统的升级方法、电子设备及存储介质。该方法对动态分区中子分区对应的升级文件的安装方式取决于用户数据分区当前的剩余空间和升级文件的大小(压缩大小，非压缩大小)，从而能够在操作系统的升级过程中，根据具体情况决定是否使用cow压缩功能，进而满足不同用户需求。

Description

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

技术领域

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

背景技术

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

对于采用虚拟AB系统分区结构的电子设备，由于动态分区(Surper分区)是以单分区的形式存在的，因此在操作系统升级过程中，需要将动态分区对应的升级文件先写入用户数据分区(Userdata分区)，待电子设备重启时再从用户数据分区读取升级文件落盘到动态分区对应的子分区中，这就导致操作系统升级过程中会占用用户数据分区较多的空间，甚至会因为用户数据分区空间不足导致升级失败。

发明内容

为了解决上述技术问题，本申请提出了一种操作系统的升级方法、电子设备及存储介质，通过根据用户数据分区空间的剩余大小选择对动态分区的升级方式，在不影响用户使用的情况下，保证电子设备能够正常完成操作系统的升级。

第一方面，本申请提供了一种操作系统的升级方法，应用于电子设备，电子设备包括处理器以及存储器，存储器包括基础分区、第一静态分区、第二静态分区、动态分区以及用户数据分区，电子设备启动后依次加载基础分区的数据、第一静态分区的数据以及动态分区的数据以运行第一操作系统，第一操作系统运行之后，方法还包括：获取升级包对应的文件列表描述信息，文件列表描述信息指示了升级包的第一大小、升级包中第一升级文件压缩后的第二大小、第一升级文件未压缩的第三大小，第一升级文件对应于动态分区中的第一子分区；在用户数据分区的第一剩余空间大于第一大小和第三大小之和的情况下，在用户数据分区中创建第一子分区对应的第一写时拷贝cow文件，第一剩余空间为下载升级包前用户数据分区的剩余空间；在用户数据分区的第一剩余空间大于第一大小和第二大小之和，小于第一大小和第三大小之和的情况下，在用户数据分区中创建第一子分区对应的第二cow文件，第一cow文件的大小大于第二cow文件。由此，根据用户数据分区剩余空间的大小和升级包的第一大小，第一升级文件的第二大小和第三大小来确定本次操作系统时间中动态分区的子分区在用户数据分区中占用的虚拟逻辑分区，即cow文件的大小，进而根据cow文件的大小决定是否选择cow文件压缩功能，从而能够根据用户数据分区的剩余空间合理选择升级方式，进而满足不同用户需求。

根据第一方面，第一cow文件的大小等于第一剩余空间减去第二剩余空间和第一大小的值，第二剩余空间为下载升级包并创建第一cow文件后，用户数据分区的剩余空间；第二cow文件的大小等于第一剩余空间减去第三剩余空间和第一大小的值，第三剩余空间为下载升级包并创建第二cow文件后，用户数据分区的剩余空间。

根据第一方面，或者以上第一方面的任意一种实现方式，在用户数据分区的第一剩余空间大于第一大小和第三大小之和的情况下，在用户数据分区中创建第一子分区对应的第一写时拷贝cow文件，包括：在用户数据分区的第一剩余空间大于第一大小和第三大小之和的情况下，设置压缩属性对应的标识为第一标识，第一标识指示第一升级文件不使用cow压缩功能安装；根据第一标识，在用户数据分区中以非压缩形式创建第一子分区对应的第一cow文件。

根据第一方面，或者以上第一方面的任意一种实现方式，在根据第一标识，在用户数据分区中以非压缩形式创建第一子分区对应的第一cow文件之前，方法还包括：获取升级包；在获取到升级包之后，执行根据第一标识，在用户数据分区中以非压缩形式创建第一子分区对应的第一cow文件的步骤。

根据第一方面，或者以上第一方面的任意一种实现方式，在获取到升级包之后，执行根据第一标识，在用户数据分区中以非压缩形式创建第一子分区对应的第一cow文件的之前，方法还包括：在用户数据分区的第四剩余空间大于第三大小的情况下，设置压缩属性对应的标识为第一标识，第四剩余空间为下载完升级包后用户数据分区的剩余空间；在用户数据分区的第四剩余空间大于第二大小，小于第三大小的情况下，设置压缩属性对应的标识为第二标识，第二标识指示第一升级文件使用cow压缩功能安装。

根据第一方面，或者以上第一方面的任意一种实现方式，在根据第一标识，在用户数据分区中以非压缩形式创建第一子分区对应的第一cow文件的之后，方法还包括：以非压缩形式将第一升级文件中的数据写入用户数据分区中以非压缩形式创建第一子分区对应的第一cow文件。

根据第一方面，或者以上第一方面的任意一种实现方式，在用户数据分区的第一剩余空间大于第一大小和第二大小之和，小于第一大小和第三大小之和的情况下，在用户数据分区中创建第一子分区对应的第二cow文件，第一cow文件的大小大于第二cow文件，包括：在用户数据分区的第一剩余空间大于第一大小和第二大小之和，小于第一大小和第三大小之和的情况下，设置压缩属性对应的标识为第二标识，第二标识指示第一升级文件使用cow压缩功能安装；根据第二标识，在用户数据分区中以压缩形式创建第一子分区对应的第二cow文件。

根据第一方面，或者以上第一方面的任意一种实现方式，在根据第二标识，在用户数据分区中以压缩形式创建第一子分区对应的第二cow文件之前，方法还包括：获取升级包；在获取到升级包之后，执行根据第二标识，在用户数据分区中以压缩形式创建第一子分区对应的第二cow文件的步骤。

根据第一方面，或者以上第一方面的任意一种实现方式，在获取到升级包之后，执行根据第二标识，在用户数据分区中以压缩形式创建第一子分区对应的第二cow文件之前，方法还包括：在用户数据分区的第四剩余空间大于第三大小的情况下，设置压缩属性对应的标识为第一标识，第一标识指示第一升级文件不使用cow压缩功能安装，第四剩余空间为下载完升级包后用户数据分区的剩余空间；在用户数据分区的第四剩余空间大于第二大小，小于第三大小的情况下，设置压缩属性对应的标识为第二标识。

根据第一方面，或者以上第一方面的任意一种实现方式，在根据第二标识，在用户数据分区中以压缩形式创建第一子分区对应的第二cow文件的之后，方法还包括：以压缩形式将第一升级文件中的数据写入用户数据分区中以压缩形式创建第一子分区对应的第二cow文件。

根据第一方面，或者以上第一方面的任意一种实现方式，以压缩形式将第一升级文件中的数据写入用户数据分区中以压缩形式创建第一子分区对应的第二cow文件，包括：将第一升级文件中的数据中的0去掉；将去掉0的数据写入用户数据分区中以压缩形式创建第一子分区对应的第二cow文件。

根据第一方面，或者以上第一方面的任意一种实现方式，在用户数据分区的第一剩余空间大于第一大小和第三大小之和的情况下，在对操作系统升级的过程中，电子设备对用户数据分区不执行除操作系统升级之外的读写操作；或者，在用户数据分区的第一剩余空间大于第一大小和第二大小之和，小于第一大小和第三大小之和的情况下，在对操作系统升级的过程中，电子设备对用户数据分区不执行除操作系统升级之外的读写操作。

根据第一方面，或者以上第一方面的任意一种实现方式，在第一剩余空间小于第一大小和第二大小之和的情况下，提示清理用户数据分区。

根据第一方面，或者以上第一方面的任意一种实现方式，提示清理用户数据分区，包括：确定第一大小和第二大小之和与第一剩余空间的第一差值；提示对用户数据分区清理至少第一差值的空间。

根据第一方面，或者以上第一方面的任意一种实现方式，在第四剩余空间小于第二大小的情况下，提示清理用户数据分区。

根据第一方面，或者以上第一方面的任意一种实现方式，提示清理用户数据分区，包括：确定第二大小与第四剩余空间的第二差值；提示对用户数据分区清理至少第二差值的空间。

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

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

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

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

附图说明

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

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

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

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

图5.1是示例性示出的操作系统升级过程中将升级包中的数据写入静态分区的示意图；

图5.2是示例性示出的操作系统升级过程中将升级包中的数据写入动态分区的示意图；

图5.3是示例性示出的升级包中包括的文件的示意图；

图6.1是示例性示出的用户数据分区剩余的空间大于升级包和未压缩的动态分区对应的升级文件之和时在用户数据分区创建cow文件的示意图；

图6.2是示例性示出的用户数据分区剩余的空间小于升级包和未压缩的动态分区对应的升级文件之和，大于升级包和压缩的动态分区对应的升级文件之和时在用户数据分区创建cow文件的示意图；

图7.1是示例性示出的操作系统升级过程中电子设备从OTA服务器下载升级包前和下载升级包后，对静态分区升级中的示意图；

图7.2是示例性示出的操作系统升级过程中电子设备对静态分区升级后，对动态分区升级前的示意图；

图7.3是示例性示出的操作系统升级过程中电子设备将第一升级文件写入System_COW和对dtbo_b子分区校验的示意图；

图7.4是示例性示出的操作系统升级过程中电子设备对System_COW校验和重启电子设备后的示意图；

图7.5是示例性示出的操作系统升级过程中电子设备执行Merge操作和分区同步的示意图；

图7.6是示例性示出的操作系统升级过程中电子设备在完成分区同步后向OTA服务器上报升级结果的示意图；

图8.1是示例性示出的操作系统升级过程中拍包服务器和OTA服务器之间的时序图；

图8.2是示例性示出的操作系统升级过程中电子设备从OTA服务器获取升级包的时序图；

图8.3是示例性示出的操作系统升级过程中将升级文件写入静态分区和动态分区的时序图；

图8.4是示例性示出的操作系统升级过程中将升级文件写入静态分区和动态分区后执行操作的时序图；

图9是示例性示出的操作系统升级过程中根据第一次空间判断结果设置压缩属性的流程示意图；

图10是示例性示出的操作系统升级过程中根据第二次空间判断结果设置压缩属性的流程示意图；

图11是示例性示出的操作系统升级过程中根据不同的压缩属性选择不同的安装方式安装动态分区对应的升级文件的流程示意图；

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

具体实施方式

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

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

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

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

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

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

参见图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等。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

表1分区表

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

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

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

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

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

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

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

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

示例性的，关于拍包服务器根据版本镜像制作的升级包中，例如可以包括启动相关镜像(例如xloader.img、boot.img)、系统镜像(例如super.img)等，此处不再一一例举，本实施例对此不做限制。

此外，在本实施例提供的技术方案中，为了保证在用户数据分区剩余空间充足和不足的情况下，都可以实现操作系统的升级，拍包服务器在制作升级包时，还会制作描述升级包的文件列表描述信息(后续称为filelist.xml)，并再向OTA服务器上传升级包的时候，将描述该升级包的filelist.xml一同上传OTA服务器进行管理。

需要说明的是，在本实施例提供的技术方案中，拍包服务器制作的filelist.xml中至少包括了指示升级包的第一大小(后续称为fileSize)、指示用于升级动态分区的升级文件压缩后的第二大小(后续称为compressCowsize)，以及指示用于升级动态分区的升级文件未压缩的第三大小(后续称为uncompressCowsize)。

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

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

关于电子设备从OTA服务器下载完成升级包，根据升级包对操作系统升级的过程，即将升级包中的数据写入静态分区对应的子分区，动态分区对应的子分区的过程，以下结合图5.1至图5.3进行说明。

示例性的，参见图5.1和图5.2，电子设备从OTA服务器下载到的升级包具体是存放在用户数据分区的，在将升级包中的数据写入静态分区对应的子分区，动态分区对应的子分区的过程中，随机存取存储器RAM会将用户数据分区中存放的升级包中的数据读取到RAM中，即执行图5.1中的步骤(1)，然后RAM再将用于升级静态分区的数据写入静态分区中对应的子分区，即执行图5.1中的步骤(2)，将用于升级动态分区的数据写入动态分区中对应的子分区，即执行图5.2中的步骤(3)。

示例性的，图5.1中以电子设备当前以第一静态分区为启动顺序为例，在需要升级的静态分区中的子分区是dtbo子分区时，RAM会将用于升级dtbo子分区的数据写入当前处于备份分区的第二静态分区中的dtbo_b子分区。

示例性的，图5.2以需要升级的动态分区中的子分区为System子分区为例，则RAM会将升级包中System子分区对应的数据写入用户数据分区中System子分区对应的cow 文件，即图5.2用户数据分区中的System_COW。

关于升级包中通常包括的文件，以下结合图5.3进行说明。

示例性的，在实际应用中，升级包中通常会包括存放密钥验签数据的密钥验签文件、升级包的版本描述文件、payload.bin(是Android OTA镜像打包文件，例如包括system.img、 boot.img和recovery.img等镜像文件)，以及用于描述payload.bin的属性文件。

进一步地，对于payload.bin又可以分为Metadata和Data两部分。其中，Metadata是对Data的描述，用于指示不同分区的升级数据在Data中的具体位置。即，Metadata 用于承担目录索引的左右，同时也承担这签名验证的作用，而Data则承载着用于升级静态分区中子分区和动态分区中子分区的升级数据。

关于根据Metadata定位Data中各个分区的数据的实现方式可以参见现有的标准，此处不再赘述。

具体到本申请实施例提供的操作系统的升级方案中，为了使升级方式与电子设备相匹配，从而既兼顾用户体验，又能保证操作系统可以快速、正常的升级完成，电子设备在进行操作系统升级时会对用户数据分区的剩余空间进行判断，并根据判断结果设置压缩属性，即设置是否使用cow压缩功能。

需要说明的是，本实施例提供的技术方案，在进行剩余空间判断，并根据判断结果设置压缩属性时，具体是根据用户数据分区的剩余空间与上述filelist.xml中的fileSize、 compressCowsize和uncompressCowsize进行判断，然后根据判断结果设置是否使用cow 压缩功能。

示例性的，如果filelist.xml中记录的升级包的fileSize为506M，动态分区中System 子分区对应的升级文件的compressCowsize为1.0G，动态分区中System子分区对应的升级文件的uncompressCowsize为8.7G。参见图6.1，在用户数据分区的剩余空间为10.0G的情况下，由于剩余空间(10.0G)>fileSize(506M)+uncompressCowsize(8.7G)，因此这种情况下设置的压缩属性为不使用cow压缩功能，即后续下载到升级包，在用户数据分区创建的对应System子分区的System_COW是以非压缩形式创建的，RAM在将升级包中对应于System子分区的数据写入非压缩System_COW时，不需要对数据进行压缩处理，直接写入即可。

示例性的，如果filelist.xml中记录的升级包的fileSize为506M，动态分区中System 子分区对应的升级文件的compressCowsize为1.0G，动态分区中System子分区对应的升级文件的uncompressCowsize为8.7G。参见图6.2，在用户数据分区的剩余空间为2.0G的情况下，由于fileSize(506M)+uncompressCowsize(8.7G)>剩余空间(2.0G)>fileSize(506M)+compressCowsize(1.0G)，因此这种情况下设置的压缩属性为使用cow压缩功能，即后续下载到升级包，在用户数据分区创建的对应System子分区的System_COW 是以压缩形式创建的，RAM在将升级包中对应于System子分区的数据写入压缩 System_COW时，需要对数据进行压缩处理。

需要说明的是，在实际应用中，关于设置的压缩属性为使用cow压缩功能的情况，在RAM将升级包中对应于System子分区的数据写入压缩System_COW时，可以根据业需求选择压缩算法对数据进行压缩处理，关于压缩算法的选择，本实施例不做限制。

示例性的，以电子设备进行操作系统升级前，依次加载的是基础分区的数据、第一静态分区的数据、动态分区的数据，以使电子设备运行到第一操作系统(操作系统升级前的版本SlotA(v1.0))，本次系统升级需要对静态分区中的dtbo子分区和动态分区中的System子分区进行升级为例，结合图7.1至图7.6对本申请实施例提供的操作系统的升级方案进行说明。

参见图7.1当需要对操作系统进行升级时，电子设备首先会执行图7.1中的步骤(1)，从OTA服务器获取升级包的第一大小、升级包中第一升级文件压缩后的第二大小，以及第一升级文件未压缩的第三大小，第一升级文件对应于动态分区中的System子分区。

接着，电子设备会执行图7.1中的步骤(2)，在用户数据分区的第一剩余空间大于第一大小和第三大小之和的情况下，将压缩属性设置为 self.virtual_ab.compression.enabled＝false(即不使用cow压缩功能)，并下载升级包；在用户数据分区的第一剩余空间大于第一大小和第二大小之和，小于第一大小和第三大小之和的情况下，将压缩属性设置为self.virtual_ab.compression.enabled＝true(即使用cow 压缩功能)，并下载升级包；在用户数据分区的第一剩余空间小于第一大小和第二大小之和的情况下，在UI界面弹框提醒用户清理用户数据空间。

示例性的，在一些实现方式中，可以设置self.virtual_ab.compression.enabled＝“true”表示使用写时拷贝(Copy-On-Write，COW)文件压缩功能，设置 self.virtual_ab.compression.enabled＝“false”表示不使用cow压缩功能。

示例性的，在self.virtual_ab.compression.enabled＝“true”时，在将动态分区中子分区的升级文件写入用户数据分区时，需要先在用户数据分区以压缩形式创建对应的cow 文件(后续简称为压缩cow文件)，然后以压缩文件的形式将动态分区中子分区对应的升级文件写入压缩cow文件，即动态分区中子分区对应的升级文件是以压缩形式的cow 文件存放在用户数据分区的。

示例性的，在self.virtual_ab.compression.enabled＝“false”时，在将动态分区中子分区的升级文件写入用户数据分区时，需要先在用户数据分区以非压缩的形式创建对应的 cow文件(后续简称为非压缩cow文件)，然后将动态分区中子分区对应的升级文件直接写入非压缩cow文件，即动态分区中子分区对应的升级文件是以非压缩形式的cow文件存放在用户数据分区的。

示例性的，在一些实现方式中，在弹框提醒用户电子设备当前的第一剩余空间不足，需要清理用户数据空间时，还可以提醒用户需清理至少多大的空间，以保证重新触发操作系统升级时，升级包可以下载成功。

示例性的，在一些实现方式中，弹框提醒用户清理的用户数据空间，至少为第一大小和第二大小之和。

示例性的，在一些实现方式中，如果电子设备当前的第一剩余空间不足，在弹框提醒用户清理的用户数据空间后，电子设备可以在预设周期后自动检测当前的第一剩余空间是否大于第一大小和第三大小之和，或者大于第一大小和第二大小之和，小于第一大小和第三大小之和，然后根据检测结果决定是否从OTA服务器下载升级包，即重新执行图7.1中的步骤(2)。

示例性的，在另一些实现方式中，如果电子设备当前的第一剩余空间不足，在弹框提醒用户清理的用户数据空间后，何时重新执行图7.1中的步骤(2)可以是由用户主动触发，例如由用户主动点击升级操作系统的控件。

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

为了便于说明本申请提供的操作系统的升级方案，图7.1中的步骤(2)以用户数据分区的第一剩余空间大于第一大小和第三大小之和的情况为例，即设置的压缩属性为不使用cow压缩功能。

此外，需要说明的是，电子设备从OTA服务器下载的升级包具体是存放在用户数据分区的，本实施例中在用户数据分区中未示出。

接着，电子设备在从OTA服务器下载完成升级包后，会执行图7.1中的步骤(3)，将升级包中对应于静态分区的dtbo子分区的第二升级文件的数据写入第二静态分区中dtbo_b子分区。

示例性的，在将第二升级文件的数据写入第二静态分区中dtbo_b子分区后，dtbo_b 子分区的版本会从图7.1中示出的dtbo_b(1.0)变更为图7.2中示出的dtbo_b(2.0)。

可理解的，如果在实际应用中，升级包中不包括第二升级文件，即不需要对静态分区中的子分区进行升级，则无需执行图7.1中的步骤(3)。

接着参见图7.2，示例性的，电子设备在将第二升级文件中的数据写入第二静态分区的dtbo_b子分区，即对静态分区升级后，为了避免升级包下载过程中，有其他文件占用了电子设备的剩余空间，导致对动态分区升级所需的空间不足，进而无法完成升级，电子设备还会再执行一次空间判断操作，即图7.2中的步骤(4)，在用户数据分区的第四剩余空间(下载升级包后的剩余空间)大于第三大小的情况下，将压缩属性设置为 self.virtual_ab.compression.enabled＝false；在用户数据分区的第四剩余空间大于第二大小，小于第三大小的情况下，将压缩属性设置为self.virtual_ab.compression.enabled＝true，将压缩属性设置为self.virtual_ab.compression.enabled＝false；在用户数据分区的第四剩余空间小于第二大小的情况下，在UI界面弹框提醒用户清理用户数据空间。

示例性的，在一些实现方式中，弹框提醒用户清理的用户数据空间，至少为第二大小。

示例性的，在一些实现方式中，如果电子设备当前的第四剩余空间不足，在弹框提醒用户清理的用户数据空间后，电子设备可以在预设周期后自动检测当前的第四剩余空间是否大于第三大小，或者大于第二大小，小于第三大小，然后根据检测结果决定是否接续升级，即执行图7.2中的步骤(5)，或者在监听到用户的触发操作，例如用户主动点击升级操作系统的控件后再进行接续升级。

示例性的，在另一些实现方式中，电子设备在确定用户清理后的第二用户数据空间大于第三大小，或者小于第三大小，大于第二大小后，重新开始对操作系统的升级时，可以重新从OTA服务器下载升级包，然后依次对静态分区的子分区和动态分区的子分区进行升级，避免升级操作中断后可能导致已经写入的数据因此用户清理用户数据分区导致丢失或异常。

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

为了便于说明本申请提供的操作系统的升级方案，图7.2中的步骤(4)以用户数据分区的第四剩余空间大于第二大小，小于第三大小的情况为例，即第二次空间判断后重新设置的压缩属性为使用cow压缩功能。

可理解的，对于上述步骤(4)中对用户数据分区的二次空间判断操作可以根据业务需求选择是否需要执行，本申请对此不做限制。

此外，需要说明的是，在实际应用中，上述步骤(4)的操作可以是在步骤(3)之前进行，即步骤(3)和步骤(4)可以不区分先后顺序，此处以步骤(4)在步骤(3) 执行之后再执行为例。

接着，在完成图7.2中的步骤(4)后，电子设备会执行图7.2中的步骤(5)，在用户数据分区中以压缩形式创建System子分区对应的cow文件(压缩System_COW)。

可理解的，此时创建的压缩System_COW是一个空的cow文件，即还没有数据写入。

接着参见图7.3，示例性的，在以压缩形式创建System子分区对应的压缩 System_COW后，电子设备会执行图7.3中的步骤(6)，将第一升级文件中的数据以压缩的形式写入以压缩形式创建的压缩System_COW。

示例性的，在将第一升级文件的数据以压缩形式写入以压缩形式创建的压缩System_COW后，压缩System_COW的版本会从图7.2中示出的压缩System_COW变更为图7.3中示出的压缩System_COW(2.0)。

此外，需要说明的是，在完成将升级包中的升级文件写入对应的子分区的操作，即将第二升级文件写入dtbo_b子分区，将第一升级文件以压缩形式写入压缩System_COW 后，需要对完成写入操作的子分区进行校验。

可理解的，根据现有协议标准需要先对静态分区进行校验，在静态分区校验成功后再对动态分区进行校验，如果静态分区校验失败，则直接结束后续操作，向OTA服务器上报升级失败的信息。因此，在对完成写入操作的子分区进行校验时，电子设备会先执行图7.3中的步骤(7)，对dtbo_b子分区进行校验，即对静态分区完成写入操作的子分区进行校验。为了便于说明本申请提供的操作系统的升级方案，以对dtbo_b子分区的校验成功为例。

接着参见图7.4，示例性的，电子设备会执行图7.4中的步骤(8)，在dtbo_b子分区校验成功后，对压缩System_COW中的内容进行校验。为了便于说明本申请提供的操作系统的升级方案，以对压缩System_COW校验成功为例。

相应地，在对压缩System_COW校验成功后，电子设备会执行图7.5中的步骤(9)，在压缩System_COW校验成功后，重启电子设备。

可理解的，在实际应用中，在将升级包中的升级文件写入对应的子分区的操作，并校验成功后，可以直接触发电子设备进入整机重启，也可以在延迟进入整机重启。

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

此外，需要说明的是，如果进行操作系统升级前，电子设备启动后依次加载的是基础分区的数据、第一静态分区的数据和动态分区的数据，运行的是第一操作系统(操作系统升级前的版本)，那么重启后，电子设备依次加载的是基础分区的数据、第二静态分区的数据、动态分区的数据和用户数据分区中压缩System_COW文件中的数据，以使电子设备运行到第二操作系统(操作系统升级后的版本SlotB(v2.0))。

接着，在电子设备重启运行到第二操作系统后，会执行图7.6中的步骤(10)Merge，将压缩System_COW文件中的内容落盘到System子分区。

示例性的，完成Merge操作后，System子分区会从图7.5左侧虚拟AB系统的分区结构示出的System(1.0)变更为图7.5右侧虚拟AB系统的分区结构示出的System(2.0)。

接着，在完成Merge操作后，电子设备还会执行图7.6中的步骤(11)，将dtbo_b 子分区中的数据同步到dtbo_a子分区，即对静态分区进行分区同步操作，具体是将本次操作系统升级过程中进行升级的静态分区中的数据同步到未升级的静态分区中。

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

示例性的，在完成分区同步后，dtbo_a子分区会从图7.5中示出的dtbo_a(1.0)变更为图7.6中示出的dtbo_a(2.0)。

接着，在完成分区同步操作后，电子设备会执行图7.6中的步骤(12)，向OTA服务器上报升级结果。

可理解的，在实际应用中，上述步骤(3)至(11)任一步骤出现异常，导致本次操作系统的升级失败时，电子设备都会中断后续的升级操作，向OTA服务器上报升级结果。

示例性的，如果升级成功，则电子设备向OTA服务器上报的升级结果为指示本次操作系统升级成功的内容，反之则为指示本次操作系统升级失败的内容。

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

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

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

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

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

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

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

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

示例性的，参见图8.1至图8.4，本申请提供的操作系统的升级方案，包括：

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

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

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

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

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

S102，计算升级包的大小fileSize、升级包中动态分区的升级文件压缩后的大小compressCowsize、动态分区的升级文件的未压缩(压缩前)的大小uncompressCowsize，将fileSize、compressCowsize和uncompressCowsize添加到升级包对应的filelist.xml。

也就是说，在本实施例中，拍包服务器在制作升级包时，会将升级动态分区中子分区的升级文件对应的compressCowsize和uncompressCowsize，以及升级包的大小fileSize均添加到升级包对应的filelist.xml，这样电子设备便可以根据filelist.xml中记载的内容和用户数据分区当前的剩余空间确定采用哪种安装方式，将动态分区中子分区对应的升级文件安装到用户数据分区中。

可理解的，在实际应用中，filelist.xml中除了包括fileSize、compressCowsize和 uncompressCowsize，还会包括操作系统升级过程中所需要的其他参数信息，例如“<support>”、“<payloadOffset>”、“<fileHash>”、“<metadataHash>”、“<metadataSize>”、“<powerWash>”、“<switchSlotOnReboot>”、“<runPostInstall>”等，此处不再一一列举，本实施例对此也不作限制。

需要说明的是，在实际应用中，filelist.xml中出现的上述字段通常是成对出现的，即还会“</support>”、“</payloadOffset>”、“</fileHash>”、“</metadataHash>”、“</metadataSize>”、“</powerWash>”、“</switchSlotOnReboot>”、“</runPostInstall>”。

其中，“<support>”和“</support>”之间的内容用于指示是否支持虚拟AB系统分区结构，其中“0”表示不支持，“1”表示支持；<payloadOffset>和“</payloadOffset>”之间的内容用于指示payload.bin的起始位置；“<fileHash>”和“</fileHash>”之间的内容用于校验payload.bin里面的文件主体；“<metadataHash>”和“</metadataHash>”之间的内容用于校验payload.bin里面的文件元数据；“<metadataSize>”和“</metadataSize>”之间的内容用于指示payload.bin里面的文件元数据的大小；“<powerWash>”和“</powerWash>”之间的内容用于指示升级后升级文件是否恢复出厂设置，其中“0”表示恢复，“1”表示不恢复；“<switchSlotOnReboot>”和“</switchSlotOnReboot>”之间的内容指示升级包安装后，电子设备重启前是否切换静态分区，其中“0”表示不切换，“1”表示切换；“<runPostInstall>”和“</runPostInstall>”之间的内容指示是否执行安装后的脚本程序(post-install)的步骤，其中“0”表示不执行，“1”表示执行。

示例性的，post-install的步骤，例如可以是metadata分区状态数据、切换静态分区等。

示例性的，为了便于理解，以下给出一种filelist.xml。

<VirtualAB>

<support>1</support>//表示支持虚拟AB系统分区结构

<uncompressCowsize>87602704384</uncompressCowsize>//表示动态分区的子分区对应的升级文件的非压缩大小为87602704384bytes

<cowsize>7602704384</cowsize>//表示动态分区的子分区对应的升级文件的压缩大小为7602704384bytes

<payloadOffset>887</payloadOffset>//表示偏移887bytes处为payload.bin的起始位置

<fileHash>xobTFJapFXT0LnLFfki6EEgDtGtIMpUmpZpD/9k1aRo＝</fileHash>//用于校验payload.bin里面的文件主体的哈希值

<fileSize>898039335</fileSize>//表示升级包的大小为89803933bytes

<metadataHash>6LcRfiwjdb7DmB/ZFAXSkB3DTEPoW4E4KBXFq+Df5Bo＝</metadataHash>//用于指示payload.bin里面的文件元数据的大小的哈希值

<metadataSize>820940</metadataSize>//表示元数据的大小为820940bytes

<powerWash>0</powerWash>//升级后升级文件恢复出厂设置

<switchSlotOnReboot>1</switchSlotOnReboot>//升级包安装后，电子设备重启前切换静态分区

<runPostInstall>1</runPostInstall>//执行安装后的脚本程序(post-install)的步骤

</VirtualAB>

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

S103，上传升级包和filelist.xml。

示例性的，在一些实现方式中，filelist.xml是存储在升级包中的。

示例性的，在另一些实现方式中，filelist.xml是独立于升级包之外的，这样电子设备在进行空间判断时，无需获取升级包，先获取占用空间较小的filelist.xml即可。

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

此外，需要说明的是，在一些实现方式中，升级包和filelist.xml可以是由拍包服务器在检测到有新版本的升级包和对应的filelist.xml时主动上传到OTA服务器的，也可以是按照预设周期，定时将新发布的升级包和对应的filelist.xml主动上传到OTA服务器。

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

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

S104，保存升级包和filelist.xml。

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

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

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

S105，搜索OTA服务器中是否存在升级包。

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

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

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

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

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

S106，获取filelist.xml。

示例性的，在本实施例提供的操作系统的升级方案中，如果电子设备搜索到OTA服务器中存在新版本的操作系统对应的升级包，先向OTA服务器发起获取升级包对应的filelist.xml请求，而非直接发起获取升级包的请求。

此外，通过上述描述可知，在本实施例提供的操作系统的升级方案中，filelist.xml 中记录了fileSize、compressCowsize和uncompressCowsize，因此电子设备在搜索到OTA 服务器存在新版本的操作系统对应的升级包时，先获取升级包对应的filelist.xml，这样便可以根据filelist.xml中记录的fileSize、compressCowsize和uncompressCowsize，以及电子设备当前的剩余空间确定当前的剩余空间是否能够容纳升级包，以是否使用cow压缩功能对升级包中动态分区对应的升级文件进行安装。

S107，下发filelist.xml。

示例性的，OTA服务器在接收到电子设备发送的请求获取某一操作系统的升级包对应的filelist.xml请求后，便会从指定的存储地址取出filelist.xml，然后下发给对应的电子设备。

S108，根据本机的第一剩余空间、fileSize、compressCowsize、uncompressCowsize 设置压缩属性。

示例性的，根据实际情况，步骤S108可以分为以下三种情况：(1)对于第一剩余空间大于fileSize+uncompressCowsize的情况，设置压缩属性为“false”；(2)对于第一剩余空间大于fileSize+compressCowsize，小于fileSize+uncompressCowsize的情况，设置压缩属性为“true”；(3)其他情况，例如小于fileSize+compressCowsize的情况，弹框提醒用户清理用户数据分区。

为了便于说明，本实施例中步骤S108以设置的压缩属性为“true”为例。

可理解的，由于操作系统升级过程中，升级包是需要先下载到电子设备的用户数据分区的，然后在对升级包进行解压，根据升级包中用于升级静态分区的升级文件对静态分区的子分区进行升级，具体为将对应静态分区中不同子分区的升级文件的数据写入对应的子分区，根据升级包中用于升级动态分区的升级文件对动态分区的子分区进行升级，具体为将对应动态分区中不同子分区的升级文件的数据先写入用户数据分区中创建的 cow文件。因此，在设置压缩属性时，综合考虑了本机剩余空间(具体为用户数据分区的剩余空间)、fileSize、compressCowsize和uncompressCowsize，从而确保设置的压缩属性更加合理。

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

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

S201，OUC搜索到OTA服务器中存在升级包。

关于OUC搜索OTA服务器中是否存在升级包的实现方式，详见上述针对步骤S105的描述，此处不再赘述。

S202，OUC从OTA服务器中获取升级包对应的filelist.xml。

可理解的，在本实施例中filelist.xml是用来记录与升级包相关的描述信息的，故而在一些实现方式中可以将其称为文件列表描述信息。

示例性的，在本实施例中，文件列表描述信息(filelist.xml)指示了升级包的第一大小(fileSize)、升级包中第一升级文件的第二大小(compressCowsize)、第一升级文件的第三大小(uncompressCowsize)。

可理解的，第一升级文件对应于动态分区中的第一子分区，第二大小为压缩后的大小，第三大小为未压缩的大小。

示例性的，在动态分区中需要升级的子分区为一个时，第一子分区例如可以是图7.1 至图7.6中动态分区(Super)中的System子分区、system_ext子分区、Product子分区、Cust子分区、Odm子分区中的任意一个。

示例性的，在动态分区中需要升级的子分区为多个时，第一子分区例如可以是图7.1 至图7.6中动态分区(Super)中的System子分区、system_ext子分区、Product子分区、Cust子分区、Odm子分区中的任意几个。

应当理解的是，上述说明仅是为了更好的理解本实施例的技术方案而列举的示例，不作为对本实施例的唯一限制。上述实施例中所说的“第一子分区”仅仅是为了表示子分区为动态分区中的子分区，并作为对动态分区中子分区的数量和具体子分区的限定。

同理，上述所说的“第一升级文件”仅仅时为了表示该升级文件是用于升级动态分区中的子分区的，并不作为对升级动态分区中的子分区的升级文件的数量和该升级文件具体对应的子分区的限定。

S203，OUC从filelist.xml中获取fileSize、compressCowsize、uncompressCowsize。

示例性的，根据上述列举出的filelist.xml的内容可知，“<fileSize>”和“</fileSize>”之间的内容指示的是fileSize，因此从“<fileSize>”和“</fileSize>”这两个字段之间获取fileSize即可。

相应地，由于“<cowsize>”和“</cowsize>”之间的内容指示的是compressCowsize，因此从“<cowsize>”和“</cowsize>”这两个字段之间获取compressCowsize即可。

相应地，由于“<uncompressCowsize>”和“</uncompressCowsize>”之间的内容指示的是uncompressCowsize，因此从“<uncompressCowsize>”和“</uncompressCowsize>”这两个字段之间获取uncompressCowsize即可。

S204，OUC获取用户数据分区的第一剩余空间available spaceA。

可理解的，本实施例中所说的第一剩余空间为下载升级包之前，用户数据分区的剩余空间。

S205，OUC判断available spaceA>fileSize+uncompressCowsize？

即，OUC会计算fileSize和uncompressCowsize之和(本实施例将其称为第一总和)，然后判断第一剩余空间是否大于第一总和。

相应地，如果第一剩余空间大于第一总和，则执行步骤S206；否则执行步骤S207。

S206，OUC设置压缩属性self.virtual_ab.compression.enabled＝false。

示例性的，在本实施例中，当第一剩余空间大于第一总和时，OUC会将压缩属性对应的标识设置为第一标识，即self.virtual_ab.compression.enabled＝false。

需要说明的是，上述所说的第一标识，例如本实施例中给出的“false”是用于指示第一升级文件不使用cow压缩功能安装的。

示例性的，在实际应用中，还可以约定用“0”指示第一升级文件不使用cow压缩功能安装的。

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

示例性的，在第一剩余空间大于第一总和时，表明用户数据分区可用的空间充足，这种情况下OUC可以直接向OTA服务器发起获取升级包的请求，即执行步骤S210。

S207，OUC设置压缩属性self.virtual_ab.compression.enabled＝true。

示例性的，在本实施例中，当第一剩余空间不大于第一总和时，OUC会将压缩属性对应的标识设置为第二标识，即self.virtual_ab.compression.enabled＝true。

需要说明的是，上述所说的第二标识，例如本实施例中给出的“true”是用于指示第一升级文件使用cow压缩功能安装的。

示例性的，在实际应用中，还可以约定用“1”指示第一升级文件使用cow压缩功能安装的。

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

示例性的，在第一剩余空间不大于第一总和时，表明用户数据分区可用的空间不足，这种情况下秉持空间优先的原则，通过将压缩属性设置为使用cow压缩功能，从而可以尽可能减少对用户数据分区空间的占用。

S208，OUC判断available spaceA>fileSize+compressCowsize？

示例性的，OUC在将压缩属性对应的标识设置为第二标识，即true后，为了确保电子设备当前可用的用户数据分区能够容纳升级包和压缩的第一升级文件，OUC会再进行一次判断。

具体的，OUC会计算fileSize和compressCowsize之和(本实施例将其称为第二总和)，然后判断第一剩余空间是否大于第二总和。

相应地，如果第一剩余空间大于第二总和，则执行步骤S210；否则执行步骤S209。

也就是说，在用户数据分区的第一剩余空间大于所述第一大小和第二大小之和，小于第一大小和第三大小之和的情况下，后续才会以压缩形式创建第一子分区对应的cow文件(压缩cow文件)。

S209，UI界面弹框提醒清理至少(fileSize+compressCowsize-availablespaceA)Mb用户数据空间。

示例性的，如果通过判断确定即便采用cow压缩功能，用户数据分区当前可用的第一剩余空间也不足以容纳升级包和压缩的第一升级文件，这种情况下为了保证本次操作系统的升级能够顺利进行，OUC会计算第二总和和第一剩余空间的差值(本实施例将其称为第一差值)，即(fileSize+compressCowsize-available spaceA)，然后在UI界面弹框(弹窗)提醒用户需要对用户数据分区清理至少第一差值的空间，这样即便需要用户清理用户数据分区的内容，也可以减少需要删除的文件大小，从而尽可能降低用户使用电子设备时的干扰。

示例性的，在做出步骤S209的提示后，如果检测到满足预设条件，则重新执行步骤S204。关于满足预设条件重新执行步骤S204的实现方式，可以参见图7.1中步骤(2) 中对于用户数据分区空间不足，清理用户数据分区的描述，此处不再赘述。

S210，OUC从OTA服务器获取升级包。

示例性的，在一些实现方式中，OUC可以根据filelist.xml中记录的信息，例如升级包的地址信息，从OTA服务器获取升级包。

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

由此，OUC从OTA服务器获取升级包之前进行的空间判断和压缩属性的描述就介绍到此，以下结合图8.2，在步骤S108设置的压缩属性为“true”的情况下，对本实施例提供的操作系统的升级方案继续进行说明。

S109，获取升级包。

关于电子设备的OUC从OTA服务器获取升级包的具体方式，此处不再赘述。

S110，下发升级包。

即，OTA服务器在接收到OUC发起的获取升级包的请求后，响应于该请求，会向 OUC下发请求的升级包。

此外，需要说明的是，为了避免升级包下载过程中有其他数据、文件占用了第一剩余空间，进而导致第一剩余空间不大于fileSize和uncompressCowsize之和，即不大于第一总和，最终造成根据升级包下载前设置的压缩属性确定的安装方式不合适，使得操作系统的升级无法正常进行。本实施例提供的操作系统的升级方案中，OUC在从OTA服务器获取到升级包之后，根据升级包中的升级文件对静态分区和动态分区进行升级，即将升级包中的数据写入对应的子分区前，可以再进行一次空间判断，并根据判断结果重新设置压缩属性，即执行步骤S111。

S111，根据本机的第四剩余空间(下载升级包后的剩余空间)、compressCowsize、uncompressCowsize设置压缩属性。

示例性的，根据实际情况，步骤S111可以分为以下三种情况：(1)对于第四剩余空间大于uncompressCowsize的情况，设置压缩属性为“false”；(2)对于第四剩余空间大于compressCowsize，小于uncompressCowsize的情况，设置压缩属性为“true”；(3) 其他情况，例如小于compressCowsize的情况，弹框提醒用户清理用户数据分区。

为了便于说明，本实施例中步骤S111以设置的压缩属性为“true”为例。

可理解的，在实际应用中，步骤S111可以根据实际需要选择执行，并且该步骤的执行顺序可以是在下发升级指令前，也可以是在下发升级指令后，对静态分区升级前，还可以是对静态分区升级后，对动态分区升级前，此处不作限制，本实施了以下发升级指令前为例进行说明。

示例性的，参见图10，关于操作系统升级过程中根据第二次空间判断结果设置压缩属性的过程，具体包括：

S301，OUC从OTA服务器下载完升级包。

S302，OUC获取用户数据分区的第四剩余空间available spaceB。

示例性的，OUC在从OTA服务器下载完升级包之后，会重新获取用户数据分区当前可用的空间，即第四剩余空间。

S303，OUC判断available spaceB>uncompressCowsize？

可理解的，由于此时升级包已经存储在了用户数据分区，因此本次空间判断OUC只需要判断第四剩余空间是否大于uncompressCowsize。

相应地，如果第四剩余空间大于uncompressCowsize，则表明用户数据分区的可用空间充足，本次操作系统的升级可以不使用cow压缩功能，这样就可以效率优先，快速完成升级操作。

S304，OUC设置压缩属性self.virtual_ab.compression.enabled＝false。

示例性的，在本实施例中，当第四剩余空间大于uncompressCowsize时，OUC会将压缩属性对应的标识设置为第一标识，即self.virtual_ab.compression.enabled＝false。

通过上述描述可知，上述所说的第一标识，例如本实施例中给出的“false”是用于指示第一升级文件不使用cow压缩功能安装的。

示例性的，在实际应用中，还可以约定用“0”指示第一升级文件不使用cow压缩功能安装的。

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

示例性的，在第四剩余空间大于uncompressCowsize时，表明用户数据分区可用的空间充足，这种情况下OUC可以直接将下载到的升级包传送给update_engine，即执行步骤S308。

S305，OUC设置压缩属性self.virtual_ab.compression.enabled＝true。

示例性的，在本实施例中，当第四剩余空间不大于uncompressCowsize时，OUC会将压缩属性对应的标识设置为第二标识，即self.virtual_ab.compression.enabled＝true。

通过上述描述可知，上述所说的第二标识，例如本实施例中给出的“true”是用于指示第一升级文件使用cow压缩功能安装的。

示例性的，在实际应用中，还可以约定用“1”指示第一升级文件使用cow压缩功能安装的。

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

示例性的，在第四剩余空间不大于uncompressCowsize时，表明用户数据分区可用的空间不足，这种情况下秉持空间优先的原则，通过将压缩属性设置为使用cow压缩功能，从而可以尽可能减少对用户数据分区空间的占用。

S306，OUC判断available spaceB>compressCowsize？

示例性的，OUC在将压缩属性对应的标识设置为第二标识，即true后，为了确保电子设备当前可用的用户数据分区能够容纳压缩的第一升级文件，OUC会再进行一次判断。即OUC会判断第四剩余空间是否大于compressCowsize。

相应地，如果第四剩余空间大于compressCowsize，则执行步骤S308；否则执行步骤S307。

S307，UI界面弹框提醒清理至少(compressCowsize-available spaceB)Mb用户数据空间。

示例性的，如果通过判断确定即便采用cow压缩功能，用户数据分区当前可用的第四剩余空间也不足以容纳压缩的第一升级文件，这种情况下为了保证本次操作系统的升级能够顺利进行，OUC会计算compressCowsize和第四剩余空间的差值(本实施例将其称为第二差值)，即(fcompressCowsize-available spaceB)，然后在UI界面弹框(弹窗) 提醒用户需要对用户数据分区清理第二差值的空间，这样即便需要用户清理用户数据分区的内容，也可以减少需要删除的文件大小，从而尽可能降低用户使用电子设备时的干扰。

示例性的，在做出步骤S307的提示后，如果检测到满足预设条件，则重新执行步骤S302。关于满足预设条件重新执行步骤S302的实现方式，可以参见图7.2中步骤(4) 中对于用户数据分区空间不足，清理用户数据分区的描述，此处不再赘述。

S308，OUC向update_engine下发升级指令。

由此，OUC在下载完升级包，通知update_engine安装升级包中的升级文件之前进一步判断用户数据分区的剩余空间，并根据判断结果重新设置压缩属性，进一步保证了后续根据压缩属性确定的安装方式的合理性，从而保证了操作系统的升级能够正常完成。

由此，OUC从OTA服务器下载到升级包，进行安装之前进行的空间判断和压缩属性的描述就介绍到此，以下结合图8.2至图8.4，在步骤S111设置的压缩属性为“true”的情况下，对本实施例提供的操作系统的升级方案继续进行说明。

S112，下发升级指令。

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

S113，根据升级包中对应于静态分区的升级文件对静态分区升级。

关于静态分区的升级描述，可以参见图7.1中步骤(3)的描述，此处不再赘述。

另外，需要说明的是，在实际应用中，该步骤对于本实施例提供的技术方案而言是一个可选步骤，即在升级包中包括升级静态分区的升级文件时，才会执行步骤S113。

S114，确定设置的压缩属性为“ture”，调用snap进程创建压缩cow文件。

示例性的，update_engine接收到升级指令后，会读取OUC设置的压缩属性，例如通过getprop语句读取压缩属性。

具体的，如果读取的压缩属性对应的标识为上述所说的第一标识(如false)时，确定第一升级文件(升级动态分区中子分区的升级文件)对应的安装方式为不使用cow压缩功能安装的第一安装方式；如果读取的压缩属性对应的标识为上述所说的第二标识 (true)时，确定第一升级文件(升级动态分区中子分区的升级文件)对应的安装方式为使用cow压缩功能安装的第二安装方式。

S115，在用户数据分区中以压缩形式创建压缩cow文。

示例性的，由于本实施例是以设置的压缩属性为“true”为例，故而update_engine确定的压缩属性为“true”，因此snap进程会在用户数据分区中以压缩形式创建第二cow 文件(后续称为压缩cow文件)，即根据第二标识，在用户数据分区中以压缩形式创建压缩cow文件。

可理解的，本实施例是以压缩属性为上述所说的第二标识为例进行的说明，如果在实际应用中，读取的压缩属性对应的标识为上述所说的第一标识(如false)时，确定第一升级文件(升级动态分区中子分区的升级文件)对应的安装方式为不使用cow压缩功能安装的第一安装方式，这种情况下，snap进程会根据第一标识，在用户数据分区中以非压缩形式创建第一子分区对应的第一cow文件(后续称为非压缩cow文件)，以使 update_engine将第一升级文件以非压缩形式写入非压缩cow文件。

可理解的，在本实施例中，第一cow文件的大小大于第二cow文件，即非压缩cow 文件的uncompressCowsize大于压缩cow文件的compressCowsize。

S116，反馈压缩cow文件创建成功。

可理解的，为了使update_engine获知何时开始向用户数据分区中第一子分区对应的压缩cow文件中以压缩形式写入第一升级文件的数据，snap进程在创建成功压缩cow文件后会向update_engine反馈压缩cow文件创建成功的消息。

相应地，update_engine在接收到snap进程反馈的压缩cow文件创建成功的消息后，便会执行步骤S117。

S117，将升级包中对应于动态分区的升级文件中的数据，以压缩形式写入压缩cow文件。

可理解的，如果在实际应用中，update_engine调用snap进程在用户数据分区是以非压缩形式创建的非压缩cow文件，那么snap进程创建成功非压缩cow文件后，向 update_engine反馈的便于非压缩cow创建成功的消息，这样update_engine在接收到snap 进程反馈的非压缩cow文件创建成功的消息后，便会将升级包中对应于动态分区的升级文件中的数据，以非压缩形式写入非压缩cow文件。

示例性的，在本实施例中，上述所说的将升级包中对应于动态分区的升级文件(后续称为第一升级文件)中的数据，以压缩形式写入压缩cow文件是指根据预设的压缩算法，将第一升级文件中的数据中的0全部去掉，然后将去掉0的数据写入压缩cow文件。

示例性的，本实施例中所说的预设的压缩算法例如可以是冗余压缩法或无损压缩法，即去掉冗余不会减少信息量，而且仍可原样恢复数据的方法。

此外，需要说明的是，如果在实际应用中，snap进程创建cow文件(不论是压缩cow文件，还是非压缩cow文件)失败，snap进程会向update_engine反馈cow文件创建失败的消息，这样update_engine在接收到snap进程反馈的cow文件创建失败的消息后，便会结束本次操作系统的升级操作，直接向OTA服务器上报升级失败的信息。

此外，关于将动态分区对应的升级文件以压缩形式写入压缩cow文件，或者以非压缩形式写入非压缩cow文件的方式，可以参见现有标准，此处不再赘述。

为了更好的理解本实施例中S114至S117描述的内容，以下结合图11进行具体说明。

示例性的，参见图11，具体包括：

S401，update_engine判断self.virtual_ab.compression.enabled＝true？

即，update_engine在接收到OUC下发的升级指令后，会读取OUC设置的压缩属性。

相应地，如果读取的压缩属性对应的标识为上述所说的第二标识(true)时，确定第一升级文件(升级动态分区中子分区的升级文件)对应的安装方式为使用cow压缩功能安装的第二安装方式，update_engine通知snap进程在用户数据分区中以压缩形式创建压缩cow文件，即执行步骤S402；如果读取的压缩属性对应的标识为上述所说的第一标识 (如false)时，确定第一升级文件(升级动态分区中子分区的升级文件)对应的安装方式为不使用cow压缩功能安装的第一安装方式，update_engine通知snap进程在用户数据分区中以非压缩形式创建非压缩cow文件，即执行步骤S404。

S402，snap进程在用户数据分区中创建压缩cow文件。

S403，update_engine将动态分区对应的升级文件以压缩形式写入压缩cow文件。

示例性的，在安装方式为第二安装方式，即压缩属性指示使用cow压缩功能时，update_engine会将第一升级文件以压缩形式写入压缩cow文件，这样便可以尽可能降低对用户数据分区的空间的占用。

S404，snap进程在用户数据分区中创建非压缩cow文件。

S405，update_engine将动态分区对应的升级文件以非压缩形式写入非压缩cow文件。

示例性的，在安装方式为第一安装方式，即压缩属性指示不使用cow压缩功能时，update_engine会将第一升级文件以非压缩形式写入非压缩cow文件，这样操作系统的升级过程便会以效率优先，由于不需要对第一升级文件进行压缩，之间写入非压缩的cow 文件，因此写入速度快，这样就会缩短操作系统的升级时长，也会将对电子设备电量的消耗。

由此，OUC从OTA服务器获取升级包之前进行的空间判断和压缩属性的描述就介绍到此，以下结合图8.4对本实施例提供的操作系统的升级方案继续进行说明。

S118，对写入的升级文件进行校验。

示例性的，在对写入的升级文件进行校验时，按照现有的升级逻辑，需要先根据升级包对静态分区进行升级，在静态分区升级完毕后，再根据升级包对动态分区进行升级，在动态分区升级完毕后，再依次对静态分区和动态分区进行校验。

为了便于与上述所说的针对动态分区中第一子分区的第一升级文件区别，本实施例将用于升级静态分区中子分区的升级文件称为第二升级文件。

示例性的，在操作系统的升级过程中，升级引擎会从升级包中获取第二升级文件，然后根据第二升级文件升级当前闲置的静态分区的数据。

例如，在启动是由第一静态分区启动时，在电子设备启动后进行的操作系统的升级过程中具体是根据第二升级文件升级第二静态分区的数据。

关于对静态分区中完成升级的子分区的校验和动态分区中完成升级的子分区(具体是用户数据分区中对应的cow文件)的校验过程，可以参见现有标准，此处不再赘述。

示例性的，在校验成功后，update_engine会向OUC上报校验成功信息，即执行步骤S119。

需要说明的是，在实际应用中，校验失败，update_engine也会向OUC上报校验信息，这种情况下上报的是校验失败的信息。

为了便于后续升级流程的说明，本实施例以update_engine向OUC上报的是校验成功的信息为例。

相应地，update_engine在向OUC上报校验成功的信息后，OUC会执行步骤S120。

S120，触发整机重启。

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

需要说明的是，OUC触发整机重启的操作具体是snap进程完成的。故而，OUC触发整机重启后，snap进程会执行步骤S121的操作。

S121，重启过程中，对压缩cow文件进行解压缩，加载压缩cow文件中的数据，运行到升级后的操作系统。

由于本实施例是以使用cow压缩功能，即针对动态分区的子分区的升级文件是以压缩形式写入到压缩cow文件的。因此，在重启电子设备，依次加载基础分区的数据、第二静态分区的数据、动态分区的数据和用户数据分区中压缩cow文件中的数据时，需要解压缩cow文件，这样才能将压缩cow文件中的压缩数据处理为非压缩格式，进而加载使电子设备运行到升级后的操作系统(后续称为第二操作系统)。

相应地，如果针对动态分区的升级文件是以非压缩形式写入非压缩cow文件的，则在重启电子设备，依次加载基础分区的数据、第二静态分区的数据、动态分区的数据和用户数据分区中非压缩cow文件中的数据时，无需对非压缩cow文件进行解压缩操作，直接从中读取数据即可。

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

示例性的，在将电子设备重启运行到第二操作系统后，snap进程会通知内核执行Merge操作，即步骤S122。

相应地，内核在收到snap进程发送的执行Merge操作的通知后，会执行步骤S123。

S123，执行Merge操作，将压缩cow文件的数据落盘到动态分区对应的子分区。

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

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

S124，上报Merge成功的信息。

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

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

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

为了便于说明，本实施例以Merge成功为例。

S125，对静态分区进行分区同步。

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

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

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

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

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

首先，计算第二子分区的数据的哈希值和第三子分区的数据的哈希值。

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

示例性的，继续参见图7.1至图7.6，如果第二静态分区中的第二子分区为X-loader_b，则第一静态分区中与第二子分区对应的第三子分区为X-loader_a。

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

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

S126，上报升级成功的信息。

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

此外，需要说明的是，关于图8.4中示出的步骤S118，步骤S119和步骤S125是否执行可以根据业务需求设置，是否执行对本实施例提供的技术方案不造成影响，本实施例以执行为例进行说明。

此外，需要说明的是，在采用本实施例提供的技术方案对操作系统进行升级时，为了获知电子设备对操作系统的升级过程是使用了cow压缩功能，还是未使用cow压缩功能，可以规定在用户数据分区的第一剩余空间大于第一大小和第三大小之和的情况下，在对操作系统升级的过程中，电子设备对用户数据分区不执行除操作系统升级之外的读写操作。相应地，在用户数据分区的第一剩余空间大于第一大小和第二大小之和，小于第一大小和第三大小之和的情况下，在对操作系统升级的过程中，电子设备对用户数据分区不执行除操作系统升级之外的读写操作。这样，在电子设备进行操作系统升级前，记录用户数据分区的剩余空间(即上述所说的第一剩余空间，具体为下载升级包前用户数据分区的剩余空间)，在采用本实施例提供的技术方案将动态分区的数据写入用户数据分区的cow文件后执行重启前，获取用户数据分区的剩余空间，通过升级前、重启前用户数据分区的剩余空间的差值便可以确定cow文件的大小，基于cow文件的大小，遵循本实施例中规定的第一cow文件的大小大于第二cow的大小前提，便可以确定本次升级是使用了cow压缩功能，还是未使用cow压缩功能。

示例性的，为了便于说明第一cow文件的大小和第二cow文件的大小，本实施例将下载升级包并创建第一cow文件后，用户数据分区的剩余空间称为第二剩余空间，将下载升级包并创建第二cow文件后，用户数据分区的剩余空间称为第三剩余空间。

相应地，第一cow文件的大小等于第一剩余空间减去第二剩余空间和第一大小的值，第二cow文件的大小等于第一剩余空间减去第三剩余空间和第一大小的值。

为了便于理解，以下结合实例进行说明。假设用户数据分区的第一剩余空间为10.0G，下载升级包，并创建cow文件后的剩余空间为825.2M，升级包的第一大小为506M，基于上述给出的第一cow文件和第二cow文件的计算方式可知创建的cow文件占用了用户数据分区8.7G(10.0G-825.2M-506M)。

相应地，如果用户数据分区的第一剩余空间为2.0G，下载升级包，并创建cow文件后的剩余空间为518M，升级包的第一大小为506M，基于上述给出的第一cow文件和第二cow文件的计算方式可知创建的cow文件占用了用户数据分区1.0G (2.0G-518M-506M)。

基于第一cow文件(以非压缩形式创建的cow文件)的大小大于第二cow文件(以压缩形式创建的cow文件)的原理可知，对于升级包均为506M的操作系统的升级场景，在下载升级包前用户数据分区的第一剩余空间为10.0G，下载升级包，并创建cow文件后的剩余空间为825.2M时，操作系统的升级没有使用cow压缩功能，在下载升级包前用户数据分区的第一剩余空间为2.0G，下载升级包，并创建cow文件后的剩余空间为 518M时，操作系统的升级使用了cow压缩功能。

此外，在上述场景的基础上，通过记录电子设备从下载升级包到完成升级所需的时间，也可以确定本次升级是使用了cow压缩功能，还是未使用cow压缩功能。

不难发现，本实施例提供的操作系统的升级方案中，对动态分区中子分区对应的升级文件的安装方式取决于用户数据分区当前的剩余空间和升级文件的大小(压缩大小，非压缩大小)，从而能够在操作系统的升级过程中，根据具体情况决定是否使用cow压缩功能，进而满足不同用户需求。

为了更加直观的了解使用cow压缩功能和不使用cow压缩功能对操作系统升级的影响，以下罗列出了使用差分升级包和全量升级包进行操作系统的升级的对比。

表2差分升级包

表3全量升级包

为了对表2和表3例举的数据内容更加清楚，以表2为例，对于安装、校验、Merge 等涉及动态分区的操作，不使用cow压缩功能的升级方式中，安装需要的时间为142s，使用cow压缩功能的升级方式中，安装需要的时间为145s，因此使用cow压缩功能的升级方式中安装操作比不使用cow文件压缩功能的方式中安装操作花费的时间增加了2％。

相应地，校验操作花费的时间增加了315％，Merge操作花费的时间增加了459％，安装、校验、Merge花费的时间总计增加了108％。这就导致升级过程电子设备的整体功耗增加了6％。

但是，通过表2和表3记录的数据，使用cow压缩功能，在电子设备重启前占用用户数据分区(userdata)的大小明显比不使用cow压缩功能的占用的小，对于差分升级包减少了89％，全量升级包减少了44％。

因此，通过表2和表3可知，对于空间敏感的用户，空间优先，使用cow压缩功能，牺牲升级时间、功耗和热的体验，但无需用户删除用户数据分区中的原有数据；对于空间不敏感的用户，效率优先，不使用cow压缩功能，保证操作系统的升级能够快速完成。

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

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

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

S502，电子设备中的OUC获取升级包对应的filelist.xml。

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

S503，OUC获取用户数据分区的第一剩余空间。

S504，OUC根据第一剩余空间和filelist.xml中的fileSize、compressCowsize、uncompressCowsize，设置压缩属性。

关于步骤S501至步骤S504的实现细节，详见上文针对图7.1至图9的文字描述，此处不再赘述。

为了便于说明，本实施例以设置的压缩属性为“false”，即第一剩余空间大于fileSize 和uncompressCowsize之和的情况为例。

S505，OUC从OTA服务器获取升级包。

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

S506，OUC获取用户数据分区的第四剩余空间。

S507，OUC根据第四剩余空间和compressCowsize、uncompressCowsize，设置压缩属性。

关于步骤S506和步骤S507的实现细节，详见上文针对图7.2至图10的文字描述，此处不再赘述。

为了便于说明，本实施例仍以设置的压缩属性为“false”，即第四剩余空间大于uncompressCowsize的情况为例。

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

例如，版本1.1升级到版本1.2的系统增量升级包包含版本1.2的静态分区的全量数据，电子设备将版本1.2的静态分区的数据覆写到第二静态分区中。

S509，升级引擎读取OUC设置的压缩属性，确定动态分区的安装方式。

S510，snap进程根据确定的安装方式在用户数据分区中创建对应的cow文件(压缩cow或者非压缩cow文件)。

例如System子分区对应的cow文件为System_COW。可理解的，如果确定的安装方式为使用cow压缩功能，则步骤S510中创建的System_COW为压缩cow文件；如果确定的安装方式为不使用cow压缩功能，则步骤S510中创建的System_COW为非压缩cow 文件。

S511，升级引擎根据确定的安装方式，将升级包中对应于动态分区的升级文件写入对应的cow文件。

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

可理解的，如果cow文件为压缩cow文件，则在将升级包中包含版本1.2的动态分区的数据写入压缩cow文件时，采用压缩形式进行写入；反之则无需压缩，之间写入非压缩的cow文件中。

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

为了便于说明，以下以对动态分区的升级不需要使用cow文件为例，对动态分区的升级进行具体说明。

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

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

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

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

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

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

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

system_b-cow-img.img.0000；

system_ext_b-cow-img.img.0000；

vendor_b-cow-img.img.0000；

product_b-cow-img.img.0000；

cust_b-cow-img.img.0000；

odm_b-cow-img.img.0000。

具体的，cow文件中包含cow文件自身的cow文件地图(快照map)以及升级数据。cow文件地图(快照)与cow文件所针对的动态分区(Super)的子分区的文件地图相对应。动态分区(Super)的子分区的文件地图用于描述当前版本的操作系统(本次升级之前的版本，例如，版本1.1)动态分区(Super)的子分区中的所有文件以及各个文件的保存地址。

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

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

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

/system/app/A0.XXX；

/system/app/A1.XXX；

/system/app/A2.XXX；

/system/B0.XXX；

/system/B1.XXX；

/system/user/C0.XXX；

/system/user/C1.XXX；

/system/user/C2.XXX；

/system/user/C3.XXX。

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。

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

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

可以视为：

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

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

那么，针对System子分区的cow文件(system_b-cow-img.img.0000)就包含最新版的/system/app/A2.XXX以及/system/user/C2.XXX。

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

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

/system/app/A2.XXX：

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

Map2(cow文件中存储的更新数据的地址)：起始地址address start：045033(相对于cow文件存储的起始地址的偏移量)；偏移量大小size：2(即045033～045035地址段的数据)；

/system/user/C2.XXX：

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

Map2(cow文件中存储的更新数据的地址)：起始地址address start：045036(相对于cow文件存储的起始地址的偏移量)；偏移量大小size：4(即045036～045040地址段的数据)。

当cow文件中的更新数据的大小与其所要更新的原始数据的大小不一致时，cow文件(system_b-cow-img.img.0000)自身的cow文件地图可以为：

/system/app/A2.XXX：

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

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

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

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

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

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

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

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

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

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

例如，将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子分区的新版本的文件地图：

/system/app/A0.XXX：024010～024013(指向动态分区(Super)中/system/app下的 A0.XXX)；

/system/app/A1.XXX：024014～024017(指向动态分区(Super)中/system/app下的 A1.XXX)；

/system/app/A2.XXX：045033～045035(指向用户数据分区(Userdata)中 /Update/system_b-cow-img.img.0000中的A2.XXX)；

/system/B0.XXX：024021～024026(指向动态分区(Super)中/system下的B0.XXX)；

/system/B1.XXX：024027～024028(指向动态分区(Super)中/system下的B1.XXX)；

/system/user/C0.XXX：024029～024032(指向动态分区(Super)中/system/user下的 C0.XXX)；

/system/user/C1.XXX：024033～024035(指向动态分区(Super)中/system/user下的 C1.XXX)；

/system/user/C2.XXX：045036～045040(指向用户数据分区(Userdata)中/Update/system_b-cow-img.img.0000中的C2.XXX)；

/system/user/C3.XXX：024041～024044(指向动态分区(Super)中/system/user下的 C3.XXX)。

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

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

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

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

S512，升级引擎依次对第二静态分区和动态分区对应的cow文件进行校验。

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

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

S514，OUC触发电子设备进行重启。

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

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

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

在S515中，电子设备读取基础分区(Common)中的启动标记。基础分区(Common) 中的启动标记为(B)，电子设备在加载基础分区(Common)之后加载第二静态分区，从第二静态分区启动。

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

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

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

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

/system/user/C0.XXX：024029～024032；

/system/user/C1.XXX：024033～024035；

/system/user/C2.XXX：045036～045040；

/system/user/C3.XXX：024041～024044。

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

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

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

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

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

S517，内核执行Merge操作。

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

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

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

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

例如，基于System子分区的文件地图中的/system/app/A2.XXX：024018～024020以及cow文件地图中的/system/app/A2.XXX：045033～045035，将地址045033～045035上的数据写入到地址024014～024017上；基于System子分区的文件地图中的 /system/user/C2.XXX：024036～024040以及cow文件地图中的/system/user/C2.XXX： 045036～045040，将地址045036～045040上的数据写入到地址024036～024040上。

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

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

S518，内核l将第二静态分区的数据同步到第一静态分区。

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

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

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

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

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

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

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

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

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

Claims (18)

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

获取升级包对应的文件列表描述信息，所述文件列表描述信息指示了所述升级包的第一大小、所述升级包中第一升级文件压缩后的第二大小、所述第一升级文件未压缩的第三大小，所述第一升级文件对应于所述动态分区中的第一子分区；

在所述用户数据分区的第一剩余空间大于所述第一大小和所述第三大小之和的情况下，在所述用户数据分区中创建所述第一子分区对应的第一写时拷贝cow文件，所述第一剩余空间为下载所述升级包前所述用户数据分区的剩余空间；

在所述用户数据分区的第一剩余空间大于所述第一大小和所述第二大小之和，小于所述第一大小和所述第三大小之和的情况下，在所述用户数据分区中创建所述第一子分区对应的第二cow文件，所述第一cow文件的大小大于所述第二cow文件。

2.根据权利要求1所述的方法，其特征在于，

所述第一cow文件的大小等于所述第一剩余空间减去第二剩余空间和所述第一大小的值，所述第二剩余空间为下载所述升级包并创建所述第一cow文件后，所述用户数据分区的剩余空间；

所述第二cow文件的大小等于所述第一剩余空间减去第三剩余空间和所述第一大小的值，所述第三剩余空间为下载所述升级包并创建所述第二cow文件后，所述用户数据分区的剩余空间。

3.根据权利要求1或2所述的方法，其特征在于，在所述用户数据分区的第一剩余空间大于所述第一大小和所述第三大小之和的情况下，在所述用户数据分区中创建所述第一子分区对应的第一写时拷贝cow文件，包括：

在所述用户数据分区的第一剩余空间大于所述第一大小和所述第三大小之和的情况下，设置压缩属性对应的标识为第一标识，所述第一标识指示所述第一升级文件不使用cow压缩功能安装；

根据所述第一标识，在所述用户数据分区中以非压缩形式创建所述第一子分区对应的所述第一cow文件。

4.根据权利要求3所述的方法，其特征在于，在根据所述第一标识，在所述用户数据分区中以非压缩形式创建所述第一子分区对应的所述第一cow文件之前，所述方法还包括：

获取所述升级包；

在获取到所述升级包之后，执行所述根据所述第一标识，在所述用户数据分区中以非压缩形式创建所述第一子分区对应的所述第一cow文件的步骤。

5.根据权利要求4所述的方法，其特征在于，在获取到所述升级包之后，执行所述根据所述第一标识，在所述用户数据分区中以非压缩形式创建所述第一子分区对应的所述第一cow文件的之前，所述方法还包括：

在所述用户数据分区的第四剩余空间大于所述第三大小的情况下，设置压缩属性对应的标识为第一标识，所述第四剩余空间为下载完所述升级包后所述用户数据分区的剩余空间；

在所述用户数据分区的第四剩余空间大于所述第二大小，小于所述第三大小的情况下，设置压缩属性对应的标识为第二标识，所述第二标识指示所述第一升级文件使用cow压缩功能安装。

6.根据权利要求5所述的方法，其特征在于，在所述根据所述第一标识，在所述用户数据分区中以非压缩形式创建所述第一子分区对应的所述第一cow文件的之后，所述方法还包括：

以非压缩形式将所述第一升级文件中的数据写入所述用户数据分区中以非压缩形式创建所述第一子分区对应的所述第一cow文件。

7.根据权利要求1至6任一项所述的方法，其特征在于，在所述用户数据分区的第一剩余空间大于所述第一大小和所述第二大小之和，小于所述第一大小和所述第三大小之和的情况下，在所述用户数据分区中创建所述第一子分区对应的第二cow文件，所述第一cow文件的大小大于所述第二cow文件，包括：

在所述用户数据分区的第一剩余空间大于所述第一大小和所述第二大小之和，小于所述第一大小和所述第三大小之和的情况下，设置压缩属性对应的标识为第二标识，所述第二标识指示所述第一升级文件使用cow压缩功能安装；

根据所述第二标识，在所述用户数据分区中以压缩形式创建所述第一子分区对应的所述第二cow文件。

8.根据权利要求7所述的方法，其特征在于，在根据所述第二标识，在所述用户数据分区中以压缩形式创建所述第一子分区对应的所述第二cow文件之前，所述方法还包括：

获取所述升级包；

在获取到所述升级包之后，执行所述根据所述第二标识，在所述用户数据分区中以压缩形式创建所述第一子分区对应的所述第二cow文件的步骤。

9.根据权利要求8所述的方法，其特征在于，在获取到所述升级包之后，执行所述根据所述第二标识，在所述用户数据分区中以压缩形式创建所述第一子分区对应的所述第二cow文件之前，所述方法还包括：

在所述用户数据分区的第四剩余空间大于所述第三大小的情况下，设置压缩属性对应的标识为第一标识，所述第一标识指示所述第一升级文件不使用cow压缩功能安装，所述第四剩余空间为下载完所述升级包后所述用户数据分区的剩余空间；

在所述用户数据分区的第四剩余空间大于所述第二大小，小于所述第三大小的情况下，设置压缩属性对应的标识为第二标识。

10.根据权利要求9所述的方法，其特征在于，在所述根据所述第二标识，在所述用户数据分区中以压缩形式创建所述第一子分区对应的所述第二cow文件的之后，所述方法还包括：

以压缩形式将所述第一升级文件中的数据写入所述用户数据分区中以压缩形式创建所述第一子分区对应的所述第二cow文件。

11.根据权利要求1至10任一项所述的方法，其特征在于，所述以压缩形式将所述第一升级文件中的数据写入所述用户数据分区中以压缩形式创建所述第一子分区对应的所述第二cow文件，包括：

将所述第一升级文件中的数据中的0去掉；

将去掉0的数据写入所述用户数据分区中以压缩形式创建所述第一子分区对应的所述第二cow文件。

12.根据权利要求1至11任一项所述的方法，其特征在于，所述方法还包括：

在所述用户数据分区的第一剩余空间大于所述第一大小和所述第三大小之和的情况下，在对所述操作系统升级的过程中，所述电子设备对所述用户数据分区不执行除所述操作系统升级之外的读写操作；

或者，

在所述用户数据分区的第一剩余空间大于所述第一大小和所述第二大小之和，小于所述第一大小和所述第三大小之和的情况下，在对所述操作系统升级的过程中，所述电子设备对所述用户数据分区不执行除所述操作系统升级之外的读写操作。

13.根据权利要求1至12任一项所述的方法，其特征在于，所述方法还包括：

在所述第一剩余空间小于所述第一大小和所述第二大小之和的情况下，提示清理所述用户数据分区。

14.根据权利要求13所述的方法，其特征在于，所述提示清理所述用户数据分区，包括：

确定所述第一大小和所述第二大小之和与所述第一剩余空间的第一差值；

提示对所述用户数据分区清理至少所述第一差值的空间。

15.根据权利要求1至12任一项所述的方法，其特征在于，所述方法还包括：

在所述第四剩余空间小于所述第二大小的情况下，提示清理所述用户数据分区。

16.根据权利要求15所述的方法，其特征在于，所述提示清理所述用户数据分区，包括：

确定所述第二大小与所述第四剩余空间的第二差值；

提示对所述用户数据分区清理至少所述第二差值的空间。

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

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

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

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

Images