CN118245075A

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

Info

Publication number: CN118245075A
Application number: CN202211658830.4A
Authority: CN
Inventors: 李亚茹
Original assignee: Honor Device Co Ltd
Current assignee: Honor Device Co Ltd
Priority date: 2022-12-22
Filing date: 2022-12-22
Publication date: 2024-06-25
Also published as: WO2024131151A1

Abstract

一种操作系统的升级方法及电子设备，涉及计算机技术领域。其中，方法包括：加载基础分区、第一静态分区和动态分区，运行第一版本的操作系统。获取第一安装包，第一安装包为第二版本的操作系统的安装包，第二版本低于第一版本，第一安装包中包括第二版本的操作系统的第一系统数据和第二系统数据。向第二静态分区写入第一系统数据，向用户数据分区写入第一系统数据。重启并进入修复模式。在修复模式下，将用户数据分区中的第二系统数据写入到动态分区，格式化用户数据分区。重启，加载基础分区、第二静态分区和动态分区，运行第二版本的操作系统。如此，电子设备可以自动完成回退到低版本的操作系统的处理，无需拿到网点由网点进行回退。

Description

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

技术领域

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

背景技术

在电子设备出厂前，可以将操作系统烧录到电子设备中，从而实现在电子设备出厂前安装操作系统。此后，为了提升用户体验，可能需要对电子设备中的操作系统进行升级。此时，可采用空中下载技术(Over-the-Air Technology，OTA)来实现操作系统升级，从低版本(如V1.0)的操作系统升级到高版本(如V2.0)的操作系统。其中，OTA是通过电子设备的无线网络接口实现远程升级操作系统版本的技术。

但是，实际中，用户可能对升级后高版本的操作系统的使用体验不好。例如，用户习惯了使用某低版本的操作系统，对升级后高版本的操作系统用起来不顺手。那么，用户就可能希望从高版本的操作系统回退到低版本的操作系统。

然而，发明人在实施本申请实施例的过程中发现：在现有技术中，当面对从高版本的操作系统回退到低版本的操作系统的需求时，用户只能将电子设备拿到固定网点。然后，由网点的工作人员进行回退操作，将操作系统回退到低版本。

发明内容

有鉴于此，本申请提供了一种操作系统的升级方法及电子设备，电子设备可以获取高版本回退到低版本的回退包，并自动完成回退到低版本的操作系统的处理，无需拿到网点由网点进行回退。

第一方面，本申请提供了一种操作系统的升级方法，应用于电子设备，电子设备包括存储器，存储器包括基础分区、第一静态分区、第二静态分区、动态分区以及用户数据分区。其中，加载基础分区、第一静态分区和动态分区，运行第一版本的操作系统。获取第一安装包，第一安装包为第二版本的操作系统的安装包，第二版本低于第一版本，第一安装包中包括第二版本的操作系统的第一系统数据和第二系统数据。向第二静态分区写入第一系统数据，向用户数据分区写入第一系统数据。重启并进入修复模式。在修复模式下，将用户数据分区中的第二系统数据写入到动态分区，格式化用户数据分区。重启，加载基础分区、第二静态分区和动态分区，运行第二版本的操作系统。

综上所述，本申请中，在从高版本的操作系统回退到低版本的操作系统时，电子设备在待机状态下将低版本的系统数据写入到静态分区和用户数据分区后，进入修复模式将用户数据分区中的系统数据写入到动态分区，使用户数据分区中支持低版本的操作系统运行的系统数据被读出。然后，在修复模式下对用户数据分区格式化，从而可以清除掉用户数据分区中的数据。最后，电子设备重启，则可以成功加载存储有低版本的系统数据的静态分区和动态分区，以及可以成功加载无需解密的用户数据分区，从而可以成功运行在低版本的操作系统下。

在第一方面一种可能的设计方式中，在重启并进入修复模式之前，上述方法还包括：确定第一安装包用于安装比第一版本更低版本的操作系统。

也就是说，只有在确定需要回退的情况下，才重启进入修复模式。从而避免在不需要回退的情况下，错误的进入到修复模式。

在第一方面一种可能的设计方式中，第一安装包中包括第一版本号，第一版本号是第二版本的版本号，确定第一安装包用于安装比第一版本更低版本的操作系统的安装包，包括：确定第一版本号低于第二版本号，第二版本号是第一版本的版本号。

其中，第一版本号低于第二版本号，则表明安装包中携带的版本号比电子设备当前运行的操作系统的版本号更低，即为回退到低版本的场景。

在第一方面一种可能的设计方式中，在确定第一安装包用于安装比第一版本更低版本的操作系统之后，上述方法还包括：在预设子分区中记录预设标识，预设子分区为修复模式下可访问的子分区。在修复模式下，将用户数据分区中的第二系统数据写入到动态分区，格式化用户数据分区，包括：在修复模式下，如果从预设子分区中读取到预设标识，则将用户数据分区中的第二系统数据写入到动态分区，格式化用户数据分区。

也就是说，只有在回退到低版本的情况下，才进一步执行落盘(merge)及其后续处理。从而避免在不需要回退的场景中，在修复模式下错误的执行落盘等处理，最终影响系统运行。

在第一方面一种可能的设计方式中，在获取第一安装包之前，上述方法还包括：显示第一界面，第一界面中包括第一控件。响应于用户对第一控件的第一操作，向服务器发送搜包请求。接收服务器基于搜包请求反馈的下载地址。相应的，获取第一安装包，包括：基于下载地址下载第一安装包。

也就是说，可以由用户在电子设备上主动触发获取第一安装包。如此，可以在用户有回退到低版本的需求的情况下，获取第一安装包并回退，准确满足用户的需求。

在第一方面一种可能的设计方式中，在获取第一安装包之后，上述方法还包括：显示第二界面，第二界面中包括第二版本的操作系统的版本信息和第二控件，第二控件用于触发安装第二版本的操作系统。向第二静态分区写入第一系统数据，向用户数据分区写入第一系统数据，包括：响应于用户对第二控件的第二操作，向第二静态分区写入第一系统数据，向用户数据分区写入第一系统数据。

也就是说，在获取到第一安装包之后，电子设备可以在用户确认回退到低版本的操作系统时，才执行回退操作。如此，可以准确满足用户的需求

在第一方面一种可能的设计方式中，在将用户数据分区中的第二系统数据写入动态分区之后，上述方法还包括：将第二静态分区中的第一系统数据同步给第一静态分区。如此，可以使第一静态分区中也存储低版本的系统数据。那么，此后从第一静态分区启动时，也可以运行低版本的操作系统。

在第一方面一种可能的设计方式中，在向第二静态分区写入第一系统数据，向用户数据分区写入第一系统数据的过程中，上述方法还包括：显示第三界面，第三界面是电子设备待机状态下的界面。

也就是说，在待机状态下完成低版本的系统数据的写入，则在写入系统数据的过程中，用户可以正常使用电子设备。

在第一方面一种可能的设计方式中，在修复模式下，将用户数据分区中的第二系统数据写入动态分区，格式化用户数据分区的过程中，上述方法还包括：显示第四界面，第四界面中包括进度提示信息，进度提示信息用于提示落盘以及格式化的进度；其中，电子设备不会响应用户在第四界面的操作。

也就是说，在修复模式下，用户是无法正常操作电子设备的。

在第一方面一种可能的设计方式中，重启并进入修复模式，包括：重启并启动修复进程。在修复模式下，将用户数据分区中的第二系统数据落盘到动态分区，包括：修复进程触发启动落盘服务，落盘服务将用户数据分区中的第二系统数据落盘写入到动态分区；

修复进程格式化用户数据分区。

也就是说，在修复模式下，可以通过拉起落盘服务，实现将用户数据分区中的第二系统数据写入到动态分区。

在第一方面一种可能的设计方式中，第二版本满足以下至少一个条件：

第二版本是预设版本。如此，可以保证回退到的不是太久远的、或者漏洞大的版本。第二版本高于电子设备出厂时安装的操作系统的版本。如此，可以保证不会回退到电子设备未安装过的版本，即用户未使用过的版本。

第二版本是电子设备的使用地区允许安装的版本。如此，可以保证回退到电子设备允许安装的版本。

在第一方面一种可能的设计方式中，在加载基础分区、第一静态分区和动态分区，运行第一版本的操作系统之前，上述方法还包括：加载基础分区、第二静态分区和动态分区，运行第三版本的操作系统，第三版本低于第一版本。获取第二安装包，第二安装包用于升级到第一版本的操作系统，第二安装包中包括第一版本的操作系统的第三系统数据和第四系统数据。向第一静态分区写入第三系统数据，向用户数据分区写入第四系统数据。重启。加载基础分区、第一静态分区和动态分区，运行第一版本的操作系统，包括：加载基础分区、第一静态分区、动态分区以及用户数据分区中的第四系统数据，运行第一版本的操作系统。

也就是说，电子设备中第一版本的操作系统是从第三版本的操作系统升级来的。并且，在从低版本的操作系统升级到高版本的操作系统时，在完成系统数据的写入后，通过正常重启，即可运行在高版本的操作系统下。

在第一方面一种可能的设计方式中，在加载基础分区、第一静态分区、动态分区以及用户数据分区，运行第一版本的操作系统之后，上述方法还包括：将用户数据分区中的第四系统数据写入动态分区。

在第一方面一种可能的设计方式中，在重启，加载基础分区、第一静态分区、动态分区以及用户数据分区之前，上述方法还包括：确定第二安装包不用于安装比第三版本更低版本的操作系统。

在第一方面一种可能的设计方式中，第二安装包中包括第二版本号，第二版本号是第一版本的版本号，确定第二安装包不用于安装比第三版本更低版本的操作系统，包括：确定第三版本号低于第二版本号，第三版本号是第三版本的版本号。

在第一方面一种可能的设计方式中，在加载基础分区、第二静态分区和动态分区，运行第二版本的操作系统之后，上述方法还包括：响应于预设事件，重启再次进入修复模式；其中，如果确定再次进入修复模式不是为了安装比第一版本更低版本的操作系统的，则不会将用户数据分区中的数据写入动态分区的处理。如此，可以基于进入修复模式的目的，准确的执行相应的处理。

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

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

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

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

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

附图说明

图1为本申请实施例适用的回退场景的示意图；

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

图3为一种操作系统的升级流程图；

图4为另一种操作系统的升级流程图；

图5为一种操作系统的升级过程的示意图；

图6为本申请实施例提供的操作系统的升级流程的原理图之一；

图7为本申请实施例提供的操作系统的升级流程的原理图之二；

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

图9为本申请实施例提供的电子设备的软件结构图；

图10为本申请实施例提供的操作系统的升级流程图之一；

图11为本申请实施例提供的手机界面的示意图之一；

图12为本申请实施例提供的手机界面的示意图之二；

图13为本申请实施例提供的操作系统的升级流程图之二；

图14为本申请实施例提供的操作系统的升级流程的原理图之三；

图15为本申请实施例提供的手机界面的示意图之三；

图16为本申请实施例提供的操作系统的升级流程的交互图；

图17为本申请实施例提供的操作系统的升级流程图之三；

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

具体实施方式

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

本申请实施例提供了一种操作系统的升级方法，可以应用于需要将电子设备中的操作系统由高版本回退到低版本的场景中。参见图1，以电子设备是手机为例，手机的操作系统可以从V1.0版本升级到V2.0版本。采用本申请实施例，可以将操作系统从V2.0版本回退到V1.0版本。继续参见图1，手机的操作系统还可以继续从V2.0版本升级到V3.0版本。采用本申请实施例，可以将操作系统从V3.0版本回退到V2.0版本，或者从V3.0版本回退到V1.0版本。

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

与此同时，ROM可以采用虚拟A/B(也可以称为Virtual A/B)的数据存储结构，来存储系统数据。图2所示为一种虚拟A/B的数据存储结构的示意图，如图2所示，以安卓(Android)操作系统为例，虚拟A/B的数据存储结构包含基础分区(Common)、静态分区(A)、静态分区(B)、动态分区(Super)以及用户数据分区(Userdata)。

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

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

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

针对图2所示的数据存储结构，当需要从低版本的操作系统升级到高版本的操作系统时，电子设备可以使用虚拟A/B的升级方案来实现升级。参见图3，采用虚拟A/B的升级方案，将电子设备的操作系统由当前运行的低版本(如R版本)升级到高版本(如S版本)，包括：

S300、从静态分区(A)启动，运行在R版本下。

即，电子设备依次加载基础分区(Common)、静态分区(A)以及动态分区(Super)，运行在R版本的操作系统下。

S301、获取S版本的升级包。

其中，升级包中包括升级到S版本的系统数据。

S302、向ROM中写入S版本的系数数据。

电子设备可以向静态分区(B)和用户数据分区(Userdata)中写入升级包中S版本的系统数据，从而避免影响当前R版本的运行。

S303、重启。

即，退出当前S版本的操作系统，切断电子设备的电源，并再次开启电子设备的电源。

S304、从静态分区(B)加载S版本的操作系统。

电子设备可以加载静态分区(B)，从而加载得到版本S所需的一部分系统数据。以及，电子设备可以基于快照技术(snapshot)合并加载动态分区(Super)中的系统数据和用户数据分区(Userdata)中的系统数据，从而加载得到版本S所需的另一部分系统数据。

S305、加载用户数据分区(Userdata)。

通过加载用户数据分区(Userdata)，可以获取到用户的个人数据，如应用、图片、视频等数据。在成功加载用户数据分区(Userdata)后，电子设备才能成功运行。

需要在此说明的是，S302中向用户数据分区(Userdata)写入的S版本的系统数据是明文数据。因此，在S304中，在不解密的情况下，电子设备就可以成功加载用户数据分区(Userdata)中的系统数据。但是，用户数据分区(Userdata)中除S302中写入的S版本的系统数据之外，其余数据都是R版本的操作系统运行过程中产生的个人数据，如图片、文档等，都是需要解密才能访问的。因此，需要有适配的密钥，才能解密用户数据分区(Userdata)中加密的数据，实现成功挂载用户数据分区(Userdata)。

与此同时，通常高版本的操作系统的密钥，可以解密低版本的操作系统中用户数据分区(Userdata)中加密的数据。但是，低版本的操作系统的密钥，无法解密高版本的操作系统中用户数据分区(Userdata)中加密的数据。

也就是说，在从低版本升级到高版本的过程中，可以使用高版本的操作系统的密钥，成功解密用户数据分区(Userdata)中加密的数据。那么，在S305中，则可以使用S版本的操作系统的密钥成功解密用户数据分区(Userdata)中加密的数据，实现成功挂载用户数据分区(Userdata)。

在重启后，经过上述S304和S305，则可以进入用户交互界面，运行在S版本。如此，则实现了从低版本升级到高版本。

然而，如果将图3所示的虚拟A/B的升级方案(可以称为常规升级方案)，应用于从高版本(如S版本)的操作系统回退到低版本(如R版本)的操作系统的场景中，则可能出现回退失败的问题。具体的，参见图4，采用常规升级方案，将电子设备的操作系统由当前运行的高版本(如R版本)回退到低版本(如R版本)，包括：

S400、从静态分区(A)启动，运行在S版本下。

即，电子设备依次加载基础分区(Common)、静态分区(A)以及动态分区(Super)，运行在S版本的操作系统下。

S401、获取R版本的回退包。

其中，回退包即为R版本的操作系统的安装包，其包括R版本的操作系统的全量系统数据。

S402、向ROM中写入R版本的系数数据。

电子设备可以向静态分区(B)和用户数据分区(Userdata)中写入回退包中R版本的系统数据，从而避免影响当前S版本的运行。

S403、重启。

即，退出当前R版本的操作系统，切断电子设备的电源，并再次开启电子设备的电源。

S404、从静态分区(B)加载R版本的操作系统。

电子设备可以加载静态分区(B)，从而加载得到版本R所需的一部分系统数据。以及，电子设备可以基于快照技术(snapshot)合并加载动态分区(Super)中的系统数据和用户数据分区(Userdata)中的系统数据，从而加载得到版本R所需的另一部分系统数据。

S405、加载用户数据分区(Userdata)失败，启动失败。

由于是从高版本回退到低版本，而低版本的操作系统的密钥，无法解密高版本的操作系统中用户数据分区(Userdata)中加密的数据。那么，使用R版本的操作系统的密钥，无法成功解密用户数据分区(Userdata)中加密的数据，导致无法成功挂载用户数据分区(Userdata)。从而启动失败。

并且，在启动失败后，则会触发电子设备将操作系统回滚，即执行下述S406。

S406、回滚到S版本，继续运行在S版本下。

电子设备可以再次加载基础分区(Common)、静态分区(A)以及动态分区(Super)，从而继续运行在S版本的操作系统下。

也就是说，在从高版本的操作系统回滚到低版本的操作系统的场景中，采用常规升级方案，可能会因为重启后挂载用户数据分区(Userdata)失败，触发回滚，导致电子设备继续运行在高版本的操作系统下，无法成功回退到低版本的操作系统。

因此，在常规技术中，当用户有从高版本的操作系统回退到低版本的操作系统的需求时，用户只能将手机拿到网点。然后，由网点的工作人员进行回退操作，完成操作系统回退。

具体的，参见图5，操作系统的供应商可以构建回退包，将构建的回退包可以存入安全数码卡(Secure Digital Memory Card，SD)中(如图5中501所示的构建回退包过程)。其中，可以采用持续集成(continuous integratuin，CI)系统制作回退包。然后，网点的工作人员可以擦除掉电子设备中S版本的操作系统(如图5中502所示的擦版本控制过程)。最后，网点的工作人员可以使用包括R版本的回退包的SD卡，给电子设备安装R版本的操作系统(如图5中503所示的R版本的安装过程)。从而将电子设备中的操作系统，由S版本更新为R版本。

也就是说，常规技术中，采用常规升级方案，无法从S版本的操作系统回退到R版本的操作系统，而只能拿到网点，由网点的工作人员通过刷机装入R版本的操作系统，从而实现操作系统的回退。

基于上述问题，本申请实施例提供了一种操作系统的升级方法，可以应用于需要将S版本(也可以称为第一版本)的操作系统回退到R版本(也可以称为第二版本)的操作系统的电子设备中。在介绍本申请实施例之前，先在此介绍本申请中需要用到的修复模式，修复模式是指可以对电子设备内部的数据或操作系统进行修改的模式。在修复模式下，电子设备可以对操作系统进行备份或升级，也可以恢复出厂设置。例如，修复模式可以是Android系统中的恢复(recovery)模式。又例如，修复模式可以是Windows系统中的预安装环境(Preinstallation Environment，PE)或者磁盘操作系统(Disk Operating System，DOS)。下文主要以Android系统中的recovery模式为例来说明。

下面说明本申请方案：

在需要从S版本的操作系统回退到R版本的操作系统的情况下，电子设备可以下载R版本的操作系统的回退包(也可以称为第一安装包)。在待机状态下，电子设备将回退包中R版本的系统数据写入到ROM中的静态分区和用户数据分区(Userdata)。

示例性的，以电子设备当前从静态分区(A)启动，S版本是V3.0，R版本是V2.0为例，参见图6，在待机状态下，写入V2.0的系统数据，静态分区(A)、静态分区(B)和用户数据分区(Userdata)中存储的都是V3.0的系统数据，用户数据分区中存储的是用户个人数据(如图6中的写入前所示)。由于电子设备当前从静态分区(A)启动，即运行在基础分区(Common)、静态分区(A)以及动态分区(Super)构成的V3.0的操作系统中。那么，电子设备可以向静态分区(B)写入V2.0中需要存储在静态分区的系统数据，使得静态分区(B)中可以存储V2.0的一部分系统数据(如图6中写入后的静态分区(B)所示)；以及，向用户数据分区(Userdata)中写入V2.0中需要存储在动态分区的系统数据，使得用户数据分区(Userdata)中可以存储V2.0的另一部分系统数据(如图6中写入后的用户数据分区(Userdata)所示)。如此，不会改变静态分区(A)以及动态分区(Super)中的数据，从而不会影响当前V3.0版本的操作系统的运行。

在系统数据写入完成后，电子设备可以重启进入recovery模式。在recovery模式下，电子设备将用户数据分区(Userdata)中的系统数据写入到动态分区(Super)中。其中，将用户数据分区(Userdata)中的系统数据写入到动态分区(Super)中的过程，也可以称为落盘过程。这样，可以使动态分区(Super)中存储有R版本的系统数据，使得后续通过加载动态分区(Super)，可以加载得到R版本的系统数据。

示例性的，在向静态分区(B)写入V2.0的一部分系统数据，向用户数据分区(Userdata)中写入V2.0的另一部分系统数据后，在recovery模式下，参见图7，电子设备可以先将用户数据分区(Userdata)中“V2.0的系统数据”落盘到动态分区(Super)中，使动态分区(Super)中存储V2.0的系统数据。

并且，在完成落盘后，电子设备格式化用户数据分区(Userdata)。这样，可以使用户数据分区(Userdata)中不再存有需要解密才能访问的数据。

继续参见图7，在recovery模式下，在完成落盘后，电子设备对用户数据分区(Userdata)格式化，从而可以清除掉用户数据分区中的数据，包括V2.0的系统数据以及用户个人数据。

最后，电子设备重启，则可以成功加载存储有R版本的系统数据的静态分区和动态分区(Super)，以及可以成功加载无需解密的用户数据分区(Userdata)，从而可以成功运行在R版本的操作系统下。继续参见图7，在格式化完成后，电子设备可以从静态分区(B)启动，即运行在基础分区(Common)、静态分区(B)以及动态分区(Super)构成的V2.0的操作系统中，并且还能成功加载用户数据分区(Userdata)。

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

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

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

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

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

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

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

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

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

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

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

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

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

在具体实现中，内部存储器321可以包括ROM和RAM。本申请中，ROM可以采用虚拟A/B的数据存储结构。

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

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

参见图9，为本申请提供的电子设备的软件组成的示意图。如图9所示，电子设备中安装有用于操作系统升级的操作系统更新程序。进一步的，操作系统更新程序包括在线更新客户端工具(online update client apk，ouc apk)以及升级引擎(update engine)两个功能模块。ouc apk用于获取操作系统的升级安装包(包括回退包)。update engine用于执行操作系统的升级流程，如用于向ROM中写入系统数据。

继续参见图9，电子设备中还包括恢复(recovery)进程和落盘(merge)服务。本申请中，recovery进程可用于拉起merge服务，完成动态分区(Super)的落盘。并且，recovery进程还可以触发恢复出厂设置，实现格式化用户数据分区(Userdata)。

下面先结合图9所示的软件组成，对本申请提供的操作系统的升级方法做简单介绍：在需要从S版本的操作系统回退到R版本的操作系统的情况下，ouc apk可以下载R版本的操作系统的回退包。在待机状态下，update engine将回退包中的系统数据写入到ROM中的静态分区和用户数据分区(Userdata)。在系统数据写入完成后，电子设备可以重启进入recovery模式，即启动recovery进程。recovery进程可以拉起merge服务，由merge服务将用户数据分区(Userdata)中的系统数据落盘到动态分区(Super)中。并且，在完成落盘后，recovery进程可以格式化用户数据分区(Userdata)，使用户数据分区(Userdata)中不再存有需要解密才能访问的数据。最后，电子设备重启，则可以成功加载存储有R版本的系统数据的静态分区和动态分区(Super)，以及可以成功加载无需解密的用户数据分区(Userdata)，从而可以成功运行在R版本的操作系统下。

本申请提供的操作系统的升级方法，可以应用于具有上述软硬件结构的电子设备中。下面将结合实际中的升级场景来说明本申请提供的操作系统的回退方案。

场景1，从S版本(即第一版本)的操作系统，回退到R版本(即第二版本)的操作系统，R版本低于S版本。即，从高版本的操作系统回退到低版本的操作系统，也可以称为回退场景。

在场景1中，如前文图6所示，电子设备在待机状态下写入R版本的系统数据；在recovery模式下完成动态分区(Super)的落盘以及用户数据分区(Userdata)的格式化。然后，电子设备重启，则可以成功运行在R版本的操作系统下。

参见图10，以电子设备当前从静态分区(A)启动为例，在场景1中，从S版本的操作系统，回退到R版本的操作系统的过程包括以下步骤：

S1001、电子设备依次加载基础分区(Common)、静态分区(A)以及动态分区(Super)，从静态分区(A)启动，运行在S版本的操作系统下。

其中，为了方便说明，可以将场景1中的静态分区(A)称为第一静态分区，将静态分区(B)称为第二静态分区。

S1002、在需要从S版本的操作系统回退到R版本的操作系统的情况下，电子设备获取R版本的回退包。

当用户需要将电子设备中当前运行的S版本的操作系统回退到R版本的操作系统时，用户可以对电子设备执行请求回退的操作。电子设备响应于请求回退的操作，可以向服务器发送搜包请求，请求获取R版本的回退包(即第一安装包)，即请求获取R版本的操作系统的安装包。

电子设备可以显示包括回退控件(也可以称为第一控件)的第一界面，回退控件用于触发电子设备向服务器请求R版本的回退包。电子设备响应于用户对回退控件的预设操作(如点击操作、长按操作等，也可以称为第一操作)，可以向服务器请求R版本的回退包。即，请求回退的操作是对回退控件的预设操作。

以电子设备是手机为例，手机上安装有预设应用程序(如手机助手应用、设置应用)，预设应用程序可用于管理手机中安装的操作系统，如操作系统的升级、回退等管理。手机可以显示图11所示的界面1101，界面1101是手机助手应用的应用界面。界面1101中包括“极客版”和“更早版本”两个选项。用户选择“极客版”，手机则可向服务器请求极客版本(也可以理解为公测版本)的升级包。用户选择“更早版本”，手机则可向服务器请求R版本的回退包。即，回退控件为“更早版本”，对回退控件的预设操作为对界面1101中“更早版本”的选择操作。手机响应于用户对界面1101中“更早版本”的选择操作，可以向服务器发送搜包请求，请求R版本的回退包。

服务器在接收到搜包请求后，可以基于搜包请求中携带的请求信息确定R版本。其中，请求信息包括S版本(即电子设备当前运行的版本)的版本号；还可以包括设备标识和/或片区信息。下面将说明电子设备基于S版本的版本号、设备标识、片区信息确定R版本的具体实现。

方式一，服务器基于S版本的版本号确定R版本。

服务器可以基于S版本的版本号将低于S版本的版本确定为R版本。例如，S版本为V3.0，V2.0比V3.0低，则可以将V2.0确定为R版本。

在一种具体的实现方式中，为了避免回退到过于久远的操作系统，或者为了避免回退到有漏洞的操作系统等，服务器中可以记录回退前的版本号及其可以回退的版本号之前的对应关系。其中，可以回退的版本号是回退前的版本号之前、与回退前的版本号距离较近、且漏洞较小的操作系统的版本号(也可以称为预设版本的版本号)。示例性的，服务器中记录有如下表1所示的对应关系：

表1

上表1反映出，V1.1可以回退到V1.0，V2.3可以回退到V2.2，V3.2可以回退到V3.1。

因此，服务器在接收到搜包请求后，查询搜包请求中携带的版本号对应的可以回退的版本号，从而可以确定回退版本。例如，搜包请求中携带的版本号为V2.3，查询上表1，确定可以回退的版本号为V2.2，即R版本为V2.2。

采用上述方式一，可以将比S版本更低的版本确定为R版本。

方式二，服务器基于S版本的版本号和设备标识确定R版本。

其中，设备标识包括设备名称、设备型号或者产品序列号(Serial Number，SN)等信息。

具体地，为了避免回退到用户从未使用过的版本，服务器可以基于S版本的版本号和设备标识，将比S版本低、且比电子设备出厂时安装的版本高的版本确定为R版本。其中，服务器基于设备标识可以查询电子设备出厂时安装的版本，比电子设备出厂时安装的版本低的版本被认为是用户未使用过的版本。

示例性的，手机A出厂时安装的操作系统为V2.0，V1.1和V1.0低于V2.0。也就是说，手机A中应该没有安装过V1.1和V1.0的操作系统。并且，电子设备当前运行的S版本为V3.2，V3.2高于V2.0、V1.1、V1.0。那么，服务器可以将低于V3.2，但是高于V2.0的版本确定为R版本，如V2.1、V3.0等版本确定为R版本，而不会将V1.1和V1.0确定为R版本。采用上述方式二，可以将比S版本更低、且用户使用过的版本确定为R版本。

方式三，服务器基于版本号S和片区标识确定目标R版本。

其中，片区信息可以是地区名称、经纬度信息、移动网络代码(MCCMNC)等指示电子设备的使用地区的信息。例如，片区信息可以是C城市、D城市等。其中，使用地区可以是电子设备定位得到的，也可以是用户输入的，本申请实施例对此不作具体限定。

实际中，操作系统的提供方，可能会为不同地区使用的电子设备，提供不同版本的操作系统。例如，国内版、海外版等。基于此，为了避免回退到电子设备的使用地区不能使用的版本，服务器可以基于S版本的版本号和片区信息，将比S版本低、且电子设备的使用地区可以使用的版本确定为R版本。其中，服务器基于片区信息可以查询电子设备的使用地区可以使用的版本。

示例性的，在国内使用的手机可以安装的操作系统的版本包括V3.1和V3.2，在海外使用的手机可以安装的操作系统的版本包括V3.3。也就是说，国内使用的手机不能安装V3.3版本的操作系统，海外使用的手机不能安装V3.1和V3.2的操作系统。并且，电子设备的片区信息显示电子设备在国内使用，且当前运行的S版本为V4.0，V4.0高于V3.1、V3.2、V3.3。那么，服务器可以将低于V4.0，且可以在国内使用的版本确定为R版本，如将V3.1、V3.2等版本确定为R版本，而不会将V13.3确定为R版本。

采用方式三，可以将比S版本更低、且电子设备的使用地区允许安装的版本确定为R版本。

当然，服务器也可以将上述方式二和方式三结合，从而将比S版本更低、用户使用过的、且电子设备的使用地区允许安装的版本确定为R版本。

需要在此说明的是，服务器确定出的R版本可能为一个或多个。如果R版本有多个，服务器可以从中筛选出一个，例如，从多个R版本中选择出最新的版本；或者，服务器可以将多个R版本发送给电子设备，供用户从中选择一个。本申请实施例对此不作具体限定。下文将主要以确定出一个R版本为例来说明。

在确定出R版本之后，服务器可以向电子设备反馈R版本的安装包(即回退包)的下载地址。电子设备根据下载地址可以下载得到回退包，从而获得回退包。

在一些实施例中，回退包中还包括R版本的版本信息。电子设备在获取到回退包之后，可以显示包括R版本的版本信息的第二界面。其中，版本信息包括版本名称、版本大小、版本特色、更新注意事项等信息。如此，方便用户了解R版本，确认是否需要回退。

继续参见图11，手机响应于用户对界面1101中“更早版本”的选择操作，向服务器发送搜包请求，并获取到回退包之后，可以显示图11所示的界面1102，界面1102也是手机助手应用的应用界面。界面1102中包括R版本的版本信息，如版本名称“YYYYYYYYY(正式版)”、版本大小“4.53GB”、版本特色“提升系统稳定性，让您的手机运行更稳定”等信息。

以及，第二界面中包括恢复控件(也可以称为第二控件)，恢复控件用于触发电子设备将操作系统回退到R版本，即用于触发电子设备安装R版本的操作系统。电子设备响应于用户对恢复控件的预设操作(如点击操作、长按操作等，也可以称为第二操作)，可以开始执行回退到R版本的操作，如执行下文S1003及其后续步骤。

继续参见图11，恢复控件是图11所示界面1102中的“恢复”按钮。手机响应于用户对界面1102中“恢复”按钮的点击操作，可以开始执行回退到R版本的操作。即，对恢复控件的预设操作是对界面1102中“恢复”按钮的点击操作。

当然，在另一些实施例中，电子设备在获取到回退包之后，也可以直接开始执行回退到R版本的操作。

S1003、电子设备根据回退包针对静态分区(B)进行数据写入操作以更新静态分区(B)。

回退包中包括R版本的操作系统的全量系统数据，进一步包括需要存储在静态分区的系统数据(也可以称为第一系统数据)和需要存储在动态分区(Super)的系统数据(也可以称为第二系统数据)。

在S1003中，电子设备可以将回退包中，需要存储在静态分区的系统数据写入到静态分区(B)中，使静态分区(B)中存储R版本所需的一部分系统数据。并且，由于电子设备当前从静态分区(A)启动，则向静态分区(B)写入系统数据，不会影响当前S版本的运行。

S1004、电子设备根据回退包在用户数据分区(Userdata)中写入动态分区(Super)的系统数据。

在S1004中，电子设备可以将回退包中，需要存储在动态分区(Super)的系统数据写入到用户数据分区(Userdata)中，使用户数据分区(Userdata)中存储R版本所需的另一部分系统数据。并且，电子设备向用户数据分区(Userdata)，而非动态分区(Super)写入系统数据，不会影响当前S版本的运行。

在一些实施例中，电子设备可以在用户数据分区(Userdata)中创建虚拟动态分区，在虚拟动态分区写入动态分区(Super)的系统数据。

在用户数据分区(Userdata)的虚拟动态分区中，电子设备可以采用写时拷贝(Copy-On-Write，cow)文件保存系统数据。其中，在虚拟动态分区中，可以保存多个cow文件，每个cow文件对应动态分区(Super)的一个子分区。即，一个cow文件中存储动态分区(Super)的一个子分区中需要存储的系统数据。

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

在S1004中，电子设备解析回退包以获取所有的cow文件，为每个cow文件附加A/B分区标记。具体的，当电子设备当前从静态分区(A)启动时，可以理解为电子设备当前运行操作系统所加载的动态分区(Super)为动态分区(A)。那么，虚拟动态分区中存储的系统数据是针对动态分区(B)的。因此，为cow文件附加对应动态分区(B)的名称标记_b。例如，为system-cow-img.img.0000附加_b生成system_b-cow-img.img.0000。

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

在将cow文件写入虚拟动态分区之后，电子设备还可以创建cow文件的索引。其中，cow文件的索引用于指示cow文件的名称和/或cow文件在虚拟动态分区中的存储位置。该cow文件的索引可用于电子设备后续从虚拟动态分区中读取cow文件。示例性的，电子设备可以在metadata子分区中创建cow文件的索引，后续，电子设备可以基于metadata子分区中cow文件的索引来读取cow文件。

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

电子设备当前从静态分区(A)启动，即启动顺序为从静态分区(A)启动。在将启动顺序由从静态分区(A)启动变更为从静态分区(B)启动后，可以使电子设备下次启动时，从静态分区(B)启动。从而可以运行在R版本的操作系统下。

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

应理解，将启动顺序由从静态分区(A)启动变更为从静态分区(B)启动，只是指示电子设备下次从静态分区(B)启动，而不会立即生效。只有在下次启动(如重启)时，才会生效。

另外，S1005的执行时机并不以图10所示为限，实际实施时，只要在下一次启动电子设备前(如S1006中重启前)，变更启动顺序即可。

需要在此说明的是，在执行上述S1003-S1005的过程中，电子设备处于待机状态，即电子设备可以显示供用户正常使用的第三界面。示例性的，在执行上述S1003-S1005的过程中，电子设备可以正常显示图12所示的界面1201，界面1201为视频播放界面，用户可以正常观看视频。

在一些实施例中，在上述S1003-S1005执行完成后，电子设备可以发出提示信息，以提示需要重启电子设备才能回退到R版本。示例性的，在S1003-S1005执行完成后，手机可以显示图12所示的界面1202，界面1202中包括提示信息1203，提示信息1203具体为“手机需要重启才能恢复到YYYYYYYYY(正式版)，是否立即重启！”，从而提示用户需要重启手机才能回退到YYYYYYYYY(正式版)版本。

然后，电子设备在检测到确认重启的操作后，才可以执行下述S1006，以继续完成回退到R版本的操作。示例性的，提示信息为图12所示界面1202中的提示信息1203，提示信息1203中还包括“是”和“否，另选时间重启”两个选项。确认重启的操作可以是用户对“是”选项的选择操作。手机响应于用户对界面1202中提示信息1203中的“是”选项的选择操作，则可以开始执行下述S1006。或者，确认重启的操作也可以是用户选择重启时间的操作。例如，手机响应于用户对界面1202中提示信息1203中的“否，另选时间重启”选项的选择操作，可以显示图12所示的界面1204。界面1204中包括时间选择弹窗1205，时间选择弹窗1205中包括多个时间选项，如1分钟、2分钟、3分钟……。选择重启时间的操作可以是用户对时间选择弹窗1205中任一时间选项(如4分钟)的选择并点击“确认”的操作。电子设备响应于用户选择重启时间的操作，可以在选择的时间到达后，开始执行下述S1006。

采用本实施例，电子设备可以仅在用户确认重启后，才会重启电子设备并继续完成回退到R版本的操作。

当然，在另一些实施例中，电子设备在上述S1003-S1005执行完成后，可以无需用户确认，紧接着执行S1006。本申请实施例对此不作具体限定。

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

本申请中，电子设备需要在recovery模式下将用户数据分区(Userdata)中的系统数据落盘(merge)到动态分区(Super)中。因此，此次重启还需要触发进入recovery模式。示例性的，电子设备可以使用如下重启指令控制电子设备重启并进入recovery模式：

property_set(ANDROID_RB_PROPERTY，“reboot，recovery”)。

并且，由于已经将启动顺序由从静态分区(A)启动变更为从静态分区(B)启动，则电子设备重启时，会从静态分区(B)启动并进入recovery模式。其中，为了保证recovery模式正常运行，电子设备需要加载基础分区(Common)和静态分区(B)中维持recovery模式正常运行所需的子分区，如recovery子分区、boot子分区等。

需要说明的是，电子设备无论是获取到从S版本回退到R版本的回退包，还是获取到从R版本升级到S版本的升级包之后，并不会区分回退包还是升级包，而都会按照前述S1001-S1005的处理流程来处理。

但是，在常规从R版本的操作系统升级到S版本的操作系统的过程中，正常重启后，就可以将用户数据分区(Userdata)中的系统数据落盘(merge)到动态分区(Super)中。而在从R版本的操作系统升级到S版本的操作系统时，则需要重启进入recovery模式，并在recovery模式下，将用户数据分区(Userdata)中的系统数据落盘(merge)到动态分区(Super)中。也就是说，从S版本(S)回退到R版本(R)的场景1中需要重启进入recovery模式。

基于此，在一些实施例中，在执行完上述S1001-S1005之后，电子设备需要确定当前获取到的是否为回退包，并在确定为回退包之后，才执行S1006，以在recovery模式下，将用户数据分区(Userdata)中的系统数据落盘(merge)到动态分区(Super)中。

在一种具体的实现方式中，电子设备可以将安装包中携带的版本号和电子设备当前运行的操作系统的版本号比较。其中，安装包包括从S版本回退到R版本的回退包或者从R版本升级到S版本的升级包。

如果安装包是回退包，则安装包中携带的为R版本的版本号(也可以称为第一版本号)，电子设备当前运行的操作系统的版本号为S版本的版本号(即第二版本号)，R版本低于S版本，相应的，R版本的版本号低于S版本的版本号。也就是说，如果是回退包，则其应该用于安装比电子设备当前运行的版本(即S版本)更低版本的操作系统，则安装包中携带的版本号低于电子设备当前运行的操作系统的版本号。

如果安装包是升级包，则安装包中携带的为S版本的版本号，电子设备当前运行的操作系统的版本号为R版本的版本号，S版本高于R版本，相应的，S版本的版本号高于R版本的版本号。也就是说，如果是升级包，则安装包中携带的版本号高于电子设备当前运行的操作系统的版本号。

因此，在本实现方式中，如果安装包中携带的版本号低于电子设备当前运行的操作系统的版本号，电子设备可以确定安装包为回退包。如果安装包中携带的版本号高于电子设备当前运行的操作系统的版本号，电子设备可以确定安装包为升级包。

另外，如果安装包中携带的版本号等于电子设备当前运行的操作系统的版本号，表明安装包有误，则停止针对该安装包的处理。

当然，实际实施时，并不以上述通过版本号的比较来确定回退包的实现方式为例。本领域技术人员可根据实际需求来区别回退包和升级包。示例性的，服务器可以在回退包中添加回退标记。电子设备可以通过识别安装包中是否包括回退标记来确定安装包是否为回退包。

相应的，参见图13，在S1006之前，还包括S1301：

S1301、电子设备确定当前获取的是回退包。

其中，确定为回退包，即确定为从S版本回退到R版本的场景1。

也就是说，在本实施例中，只有在确定获取的为回退包的情况下，才重启进入recovery模式。从而避免在获取的为升级包的情况下，错误的进入到recovery模式。

在场景1中，电子设备在进入recovery模式后，可以在recovery模式下执行下述S1007-S1009，以继续完成回退到R版本的处理。

S1007、电子设备将用户数据分区(Userdata)中的系统数据落盘到动态分区(Super)。

在本申请实施例的描述中，落盘操作指的是，将用户数据分区(Userdata)中保存的动态分区(Super)的系统数据(cow文件)写入到动态分区(Super)中，使得动态分区(Super)的文件完成数据更新，以便电子设备在下次启动时，通过加载动态分区(Super)就可以完成电子设备启动。

在一些实施例中，在进入recovery模式后，电子设备可以读取落盘状态信息和cow文件的索引，基于落盘状态信息和cow文件的索引来完成落盘处理。

通过读取落盘状态信息，电子设备可以确定是否需要从用户数据分区(Userdata)中检索相应子分区对应的cow文件。具体的，读取到落盘状态信息的整体标识为“已落盘”时，则确定无需从用户数据分区(Userdata)中检索所有子分区对应的cow文件。读取到落盘状态信息的整体标识为“未落盘”时，则可以进一步读取落盘状态信息中针对各个子分区的子分区标识。若子分区标识为“已落盘”，则确定无需从用户数据分区(Userdata)中检索相应子分区对应的cow文件。若子分区标识为“未落盘”，则确定需要从用户数据分区(Userdata)中检索相应子分区对应的cow文件。

然后，通过读取cow文件的索引，电子设备可以获取cow文件的文件名称和/或存储位置，从而从用户数据分区(Userdata)中检索到相应的cow文件。

最后，电子设备将从用户数据分区(Userdata)中检索到的cow文件写入到动态分区(Super)的相应子分区中，完成动态分区(Super)的落盘处理。

采用S1007，可以将用户数据分区(Userdata)中存储的系统数据落盘(merge)到动态分区(Super)，使动态分区(Super)中存储R版本的系统数据，确保后续可以成功运行R版本的操作系统。

实际中，进入recovery模式，可以完成对电子设备内部的数据或操作系统的多种处理。例如，修改电子设备的制式，将演示制式修改为商用制式。又例如，使用recovery模式调分区表。再例如，本申请中使用recovery模式完成S版本回退到R版本的处理。

基于此，在一些实施例中，在进入recovery模式后，电子设备首先需要确定此次进入recovery模式的目的，从而便于准确执行相应的处理来达到目的。那么，在本申请，需要确定当前是否为回退场景，从而便于准确执行S版本回退到R版本的处理。

在一种具体的实现方式中，电子设备在前述S1301中确定出为回退包之后，则可以在子分区A(也可以称为预设子分区)中写入用于指示当前为回退场景的预设标识。其中，子分区A是recovery模式下可以访问的分区。例如，子分区A是基础分区(Common)的Misc子分区。

那么，在进入recovery模式后，电子设备可以从子分区A中读取预设标识。如果读取到预设标识，则确定当前为回退场景。如果没有读取到预设标识，则确定当前不是回退场景。

示例性的，在场景1中，S1301中确定出为回退包后，电子设备可以在子分区A中写入预设标识。相应的，在S1006之后，电子设备从子分区A中读取到预设标识，则可以确定当前是回退场景。

当然，实际实施时，也并不以从子分区A中读取预设标识，确定当前是否为回退场景的方式为限。本领域技术人员可根据实际需求来采用相应的技术识别回退场景。示例性的，电子设备也可以在重启进入recovery模式之前，将安装包存储到recovery模式可以访问的预设目录下。在进入recovery模式之后，可以从预设目录中解析安装包。如果安装包中包括回退表示，则确定当前是回退场景。如果安装包中不包括回退标识，则确定当前不是回退场景。

相应的，继续参见图13，在进入recovery模式后，在S1007之前，还包括S1302：

S1302、电子设备识别到当前为回退场景。

也就是说，在本实施例中，只有在识别到为回退场景的情况下，才进一步执行落盘(merge)及其后续处理。从而避免在不需要回退的场景中，在recovery模式下错误的执行落盘等处理，最终影响系统运行。

S1008、电子设备将静态分区(B)中的系统数据同步给静态分区(A)。

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

示例性的，参见图14，在同步前，静态分区(A)中存储的是V3.0版本的系统数据，静态分区(B)中存储的是V2.0版本的系统数据。通过同步，可以将静态分区(B)中V2.0版本的系统数据，同步到静态分区(A)中，使得静态分区(A)中也存储V2.0版本的系统数据。继续参见图14，在同步后，静态分区(A)和静态分区(B)中都包括v2.0版本的系统数据。

S1009、电子设备恢复出厂设置。

其中，恢复出厂设置包括格式化用户数据分区(Userdata)、基础分区(common)中cache子分区、metadata子分区等。

在完成落盘(merge)处理之后，电子设备恢复出厂设置，可以格式化用户数据分区(Userdata)，从而使用户数据分区(Userdata)中不再存有需要解密才能访问的数据。

至此，需要说明的是，与待机状态不同的是：在recovery模式下，电子设备是无法正常使用的。示例性的，在重启并进入recovery模式之后，手机可以显示图15所示的界面1501(也可以称为第四界面)，界面1501中包括在recovery模式下，回退到R版本的进度(也可以称为进度提示信息)，即S1007-S1009的执行进度。例如，界面1501中显示的进度为0％。并且，当进度达到图15所示界面1502中的100％时，则表明S1007-S1009执行完成。其中，界面1501和界面1502都是不可操作的，用户无法正常使用。

在recovery模式中，当上述S1007-S1009执行完成后，电子设备可以执行下述S1010，使电子设备可以运行在R版本的操作系统下。

S1010、电子设备重启。

示例性的，电子设备可以使用如下重启指令控制电子设备重启：

property_set(ANDROID_RB_PROPERTY，“reboot”)。

需要说明的是，与S1006中的重启不同的是：在S1010中，重启是正常重启，因此重启后电子设备会进入到正常使用的状态，而不会进入到recovery模式。

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

由于启动顺序已经变更为从静态分区(B)启动，则电子设备会从静态分区(B)启动。

S1012、电子设备成功挂载用户数据分区(Userdata)，进入用户交互界面，运行在R版本的操作系统下。

静态分区(B)和动态分区(Super)中都是存储的R版本的系统数据，则加载静态分区(B)以及动态分区(Super)，相当于可以加载R版本的操作系统。同时，用户数据分区(Userdata)中不再存有需要解密才能访问的数据，不会出现无法加载的问题，从而电子设备可以成功启动。最终，电子设备可以成功运行在R版本的操作系统下。示例性的，从静态分区(B)启动后，电子设备可以显示图15所示的界面1503，界面1503为手机桌面。

下面结合电子设备的软件组成，对场景1中下载回退包(如图10和图13中的S1002)至完成回退(如图10和图13中的S1010)的一种具体实现做进一步的说明。

具体的，参见图16，场景1的具体实现包括：

S1601、ouc apk下载回退包，回退包中包括R版本的版本号。具体可参见前文S1002的说明。

S1602、ouc apk向update engine发送回退包。

S1603、update engine根据回退包针对静态分区(B)进行数据写入操作以更新静态分区(B)。具体可参见前文S1003的说明。

S1604、update engine根据回退包在用户数据分区(Userdata)中写入动态分区(Super)的系统数据。具体可参见前文S1004的说明。

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

S1606、update engine将R版本的版本号与当前运行的S版本的版本号比较，确定当前获取的是回退包。具体可参见前文S1301及其上下文的说明。

S1607、update engine在子分区A中写入用于指示当前为回退场景的预设标识。

示例性的，update engine在基础分区(Common)的Misc子分区中写入预设标识，即子分区A是基础分区(Common)的Misc子分区。具体可参见前文S1302及其上下文的说明。

S1608、update engine触发重启并进入recovery模式。具体可参见前文S1006的说明。

也就是说，在确定当前获取到的是回退包的情况下，才重启进入recovery模式。

S1609、recovery进程从子分区A中读取到预设标识。

其中，从子分区A中读取到预设标识，则表示当前为回退场景。具体可参见前文S1302及其上下文的说明。

S1610、recovery进程触发启动落盘(merge)服务。

S1611、merge服务将虚拟动态分区的数据落盘到动态分区(Super)。

也就是说，由merge服务来完成落盘处理。具体可参见前文S1007的说明。

S1612、recovery进程将静态分区(B)中的数据同步给静态分区(A)。具体可参加前文S1008的说明。

S1613、recovery进程格式化用户数据分区(Userdata)。具体可参见前文S1009的说明。

S1614、recovery进程触发重启。具体可参见前文S1010的说明。

场景2，从R版本的操作系统，升级到S版本的操作系统，R版本低于S版本。即，从低版本的操作系统升级到高版本的操作系统的场景，也可以称为升级场景。为了便于说明，可以将场景2中的R版本称为第三版本，S版本称为第一版本。应理解，场景2中的R版本可与场景1中的R版本相同，也可以不同。本申请实施例对此不做具体限定。

在场景2中，电子设备可以在待机状态下写入S版本的操作系统的系统数据。并且，由于是从低版本的操作系统升级到高版本的操作系统，使用高版本的操作系统的密钥可以解密用户数据分区(Userdata)中加密的数据，则在写入S版本的操作系统的系统数据后，可以直接重启电子设备，运行在S版本的操作系统下。而无需在recovery模式下完成落盘处理并格式化用户数据分区(Userdata)后，再启动电子设备运行S版本的操作系统。

参见图17，以电子设备当前从静态分区(A)启动为例，在场景2中，从R版本的操作系统，升级到S版本的操作系统的过程包括以下步骤：

S1701、电子设备依次加载基础分区(Common)、静态分区(A)以及动态分区(Super)，从静态分区(A)启动，运行在R版本的操作系统下。

为了便于说明，可以将场景2中的静态分区(A)称为第二静态分区，静态分区(B)称为第一静态分区。

S1702、电子设备获取S版本的升级包。

其中，S版本的升级包也可以称为第二安装包。与前文回退包类似的，升级包中也包括需要存储在静态分区的系统数据(也可以称为第三系统数据)和需要存储在动态分区(Super)的系统数据(也可以称为第四系统数据)。

示例性的，电子设备可以定期向服务器发起搜包请求，搜包请求包含电子设备当前运行的操作系统的版本号，如版本号V1.0。服务器根据搜包请求中的版本号，检索当前是否存在更新的操作系统的安装包(例如版本2.0的操作系统的安装包，也可以称为升级包)。当存在升级包时，服务器向电子设备反馈升级包的下载地址。电子设备根据下载地址下载安装包。

S1703、电子设备根据升级包针对静态分区(B)进行数据写入操作以升级静态分区(B)。

示例性的，向静态分区(B)写入第三系统数据。

S1704、电子设备根据升级包在用户数据分区(Userdata)中写入动态分区(Super)的系统数据。

示例性的，向用户数据分区(Userdata)写入第四系统数据。

S1703-S1704的具体实现，可参见前文S1003-S1004的说明，此处不再赘述。主要存在区别在于：回退包和升级包中的数据是不同的。

S1705、电子设备将启动顺序由从静态分区(B)启动变更为从静态分区(B)启动。具体可参见前文S1005的说明。

S1706、电子设备确定当前获取到的不是回退包。具体可参见前文S1301及其上下文的说明。

示例性的，安装包中携带的是S版本的版本号，电子设备中当前运行的操作系统的版本号是R版本的版本号(也可以称为第三版本号)，S版本的版本号高于R版本的版本号。即安装包中携带的版本号高于电子设备当前运行的操作系统的版本号。那么，电子设备可以确定当前获取到的不是回退包，即安装包不是用于安装比R版本更低版本的操作系统的。

S1707、电子设备重启。

在场景2中，确定出获取到的不是回退包，因此无需重启并进入recovery模式，而只是正常重启即可。

另外，与前文S1006不同的是：S1707中的重启通常是通过硬件重启。例如，用户长按电源键，触发重启。如此，可以在用户无需使用电子设备时，触发电子设备重启。

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

S1709、电子设备加载动态分区(Super)以及用户数据分区(Userdata)。

示例性的，电子设备采用snapshot合并加载动态分区(Super)以及从用户数据分区(Userdata)中检索到的cow文件(即第四系统数据)。

S1710、电子设备成功挂载用户数据分区(Userdata)，进入用户交互界面，运行在R版本的操作系统下。

由于是从R版本升级到S版本，密钥是兼容的，因此可以成功挂载用户数据分区。

S1711、电子设备将用户数据分区(Userdata)中的系统数据落盘到动态分区(Super)。

示例性的，将用户数据分区中的第四系统数据写入动态分区(Super)。

关于上述S1708-S1711的具体实现，可参见虚拟A/B升级的相关现有技术的说明，此处不再赘述。

S1712、电子设备将静态分区(B)中的数据同步给静态分区(A)。具体可参见前文S1008的说明。

场景3，电子设备当前运行在R版本的操作系统下，并且在非场景1的情况下进入到recovery模式。

为了便于说明，可以将场景3中的R版本称为第二版本。

其中，非场景1的情况(也可以称为预设事件)是指除场景1之外，需要在recovery模式下完成相应处理的情况，其包括但不限于以下任一种情况：用户手动操作进入recovery模式进行刷机、恢复出厂设置等处理的情况；在有改制(从演示制式改为商用制式)需求时进入recovery模式实现改制的情况；以及，在需要修改数据存储结构时进入recovery模式改数据存储结构的情况。

场景3中，电子设备在重启进入recovery模式后，会确定出当前不是回退场景，即确定此次进入修复模式不是为了安装比所述第一版本更低版本的操作系统的。示例性的，由于并不是在获取到回退包之后进入到recovery模式，则子分区A中不会记录预设标识，相应的，在recovery模式下，电子设备从子分区A中不会读取到预设标识，从而确定不是回退场景。那么，在进入recovery模式后，不会执行动态分区(Super)的落盘以及用户数据分区(Userdata)的格式化等处理。而是会基于识别到的其他目的，来完成相应的处理。例如，识别到为修改数据存储结构的场景，则在recovery模式下，电子设备可以执行修改数据存储结构的操作。又例如，识别到为改制场景，则在recovery模式下，电子设备可以执行将演示制式改为商用制式的操作。

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

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

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

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

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

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

Claims

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

加载所述基础分区、所述第一静态分区和所述动态分区，运行第一版本的操作系统；

获取第一安装包，所述第一安装包为第二版本的操作系统的安装包，所述第二版本低于所述第一版本，所述第一安装包中包括所述第二版本的操作系统的第一系统数据和第二系统数据；

向所述第二静态分区写入所述第一系统数据，向所述用户数据分区写入所述第一系统数据；

重启并进入修复模式；

在所述修复模式下，将所述用户数据分区中的所述第二系统数据写入到所述动态分区，格式化所述用户数据分区；

重启，加载所述基础分区、所述第二静态分区和所述动态分区，运行所述第二版本的操作系统。

2.根据权利要求1所述的方法，其特征在于，所述重启并进入修复模式之前，所述方法还包括：

确定所述第一安装包用于安装比所述第一版本更低版本的操作系统。

3.根据权利要求2所述的方法，其特征在于，所述第一安装包中包括第一版本号，所述第一版本号是所述第二版本的版本号，所述确定所述第一安装包用于安装比所述第一版本更低版本的操作系统的安装包，包括：

确定所述第一版本号低于第二版本号，所述第二版本号是所述第一版本的版本号。

4.根据权利要求2或3所述的方法，其特征在于，在所述确定所述第一安装包用于安装比所述第一版本更低版本的操作系统之后，所述方法还包括：

在预设子分区中记录预设标识，所述预设子分区为所述修复模式下可访问的子分区；

所述在所述修复模式下，将所述用户数据分区中的所述第二系统数据写入到所述动态分区，格式化所述用户数据分区，包括：

在所述修复模式下，如果从所述预设子分区中读取到所述预设标识，则将所述用户数据分区中的所述第二系统数据写入到所述动态分区，格式化所述用户数据分区。

5.根据权利要求1-4中任一项所述的方法，其特征在于，在所述获取第一安装包之前，所述方法还包括：

显示第一界面，所述第一界面中包括第一控件；

响应于用户对所述第一控件的第一操作，向服务器发送搜包请求；

接收所述服务器基于所述搜包请求反馈的下载地址；

所述获取第一安装包，包括：

基于所述下载地址下载所述第一安装包。

6.根据权利要求1-5中任一项所述的方法，其特征在于，在所述获取第一安装包之后，所述方法还包括：

显示第二界面，所述第二界面中包括所述第二版本的操作系统的版本信息和第二控件，所述第二控件用于触发安装所述第二版本的操作系统；

所述向所述第二静态分区写入所述第一系统数据，向所述用户数据分区写入所述第一系统数据，包括：

响应于用户对所述第二控件的第二操作，向所述第二静态分区写入所述第一系统数据，向所述用户数据分区写入所述第一系统数据。

7.根据权利要求1-6中任一项所述的方法，其特征在于，在所述将所述用户数据分区中的所述第二系统数据写入所述动态分区之后，所述方法还包括：

将所述第二静态分区中的所述第一系统数据同步给所述第一静态分区。

8.根据权利要求1-7中任一项所述的方法，其特征在于，在所述向所述第二静态分区写入所述第一系统数据，向所述用户数据分区写入所述第一系统数据的过程中，所述方法还包括：

显示第三界面，所述第三界面是所述电子设备待机状态下的界面。

9.根据权利要求1-8中任一项所述的方法，其特征在于，在所述修复模式下，将所述用户数据分区中的所述第二系统数据写入所述动态分区，格式化所述用户数据分区的过程中，所述方法还包括：

显示第四界面，所述第四界面中包括进度提示信息，所述进度提示信息用于提示落盘以及格式化的进度；其中，电子设备不会响应用户在所述第四界面的操作。

10.根据权利要求1-9中任一项所述的方法，其特征在于，所述重启并进入修复模式，包括：

重启并启动修复进程；

所述在所述修复模式下，将所述用户数据分区中的所述第二系统数据写入所述动态分区，包括：

所述修复进程触发启动落盘服务，所述落盘服务将所述用户数据分区中的所述第二系统数据写入到所述动态分区；

所述修复进程格式化所述用户数据分区。

11.根据权利要求1-10中任一项所述的方法，其特征在于，所述第二版本满足以下至少一个条件：

所述第二版本是预设版本；

所述第二版本高于所述电子设备出厂时安装的操作系统的版本；

所述第二版本是所述电子设备的使用地区允许安装的版本。

12.根据权利要求1-11中任一项所述的方法，其特征在于，在所述加载所述基础分区、所述第一静态分区和所述动态分区，运行第一版本的操作系统之前，所述方法还包括：

加载所述基础分区、所述第二静态分区和所述动态分区，运行第三版本的操作系统，所述第三版本低于所述第一版本；

获取第二安装包，所述第二安装包用于升级到所述第一版本的操作系统，所述第二安装包中包括所述第一版本的操作系统的第三系统数据和第四系统数据；

向所述第一静态分区写入所述第三系统数据，向所述用户数据分区写入所述第四系统数据；

重启；

所述加载所述基础分区、所述第一静态分区和所述动态分区，运行第一版本的操作系统，包括：

加载所述基础分区、所述第一静态分区、所述动态分区以及所述用户数据分区中的第四系统数据，运行所述第一版本的操作系统。

13.根据权利要求12所述的方法，其特征在于，在所述加载所述基础分区、所述第一静态分区、所述动态分区以及所述用户数据分区，运行所述第一版本的操作系统之后，所述方法还包括：

将所述用户数据分区中的所述第四系统数据写入所述动态分区。

14.根据权利要求12或13所述的方法，其特征在于，在所述重启，加载所述基础分区、所述第一静态分区、动态分区以及用户数据分区之前，所述方法还包括：

确定所述第二安装包不用于安装比所述第三版本更低版本的操作系统。

15.根据权利要求14所述的方法，其特征在于，所述第二安装包中包括第二版本号，所述第二版本号是所述第一版本的版本号，所述确定所述第二安装包不用于安装比所述第三版本更低版本的操作系统，包括：

确定第三版本号低于所述第二版本号，所述第三版本号是所述第三版本的版本号。

16.根据权利要求1-15中任一项所述的方法，其特征在于，在所述加载所述基础分区、所述第二静态分区和所述动态分区，运行所述第二版本的操作系统之后，所述方法还包括：

响应于预设事件，重启再次进入所述修复模式；其中，如果确定再次进入所述修复模式不是为了安装比所述第一版本更低版本的操作系统的，则不会将所述用户数据分区中的数据写入所述动态分区的处理。

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

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

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