CN116668285B - 配置制式的方法、设备和存储介质 - Google Patents

Abstract

本申请提供了一种配置制式的方法。实施该方法，手机等电子设备可获取带有制式信息的系统升级包。在利用上述升级包对电子设备的操作系统进行升级操作时，电子设备可依据升级包中的目标制式，执行改制操作，将电子设备的制式修改到目标制式，以适配新的使用场景。这样，电子设备在系统升级的过程中，可以同时完成改制操作，避免了通过传统的改制工具进行改制所存在的硬件成本高、部署改制授权服务器难度大等问题。

Description

配置制式的方法、设备和存储介质

技术领域

本申请涉及终端领域，尤其涉及配置制式的方法、设备和存储介质。

背景技术

在现有技术的应用场景中，用户终端需要安装操作系统才可以被用户使用。例如，手机上需要安装手机操作系统(例如：IOS系统、安卓系统)才可以被用户使用。在无线通信领域，根据无线通信设备(例如手机)所处的位置、接入的运营商的不同，无线通信设备的操作系统需要配置对应的制式(vendor_country，VC)；例如，all cn、cmcc cn等。

一般的，在无线通信设备出厂前进行初始操作系统的安装时，厂商会根据其销售区域安装已配置好对应制式的操作系统。但是，在实际应用场景中，存在更改制式的情况。例如，区域A的设备售罄后，需要从区域B调货。这时，从区域B调来的无线通信设备在投入区域A之前，厂商需要将原来该无线通信设备中配置的制式B(区域B对应的制式)修改为制式A(区域A对应的制式)使其能在区域A内正常使用。因此，需要一种更改无线通信设备制式的方法，能够批量的处理无线通信设备的改制需求。

发明内容

本申请提供了配置制式的方法、设备和存储介质。该方法可应用于手机等无线通信设备上。实施本申请提供的配置制式的方法，这样，手机等无线通信设备可以在系统升级的过程中，同时完成改制操作，方便快捷。

第一方面，本申请提供了一种配置制式的方法，应用于电子设备，电子设备中的第一存储块oem存储有第一制式，第一制式是电子设备当前使用的制式，电子设备还包括定制文件，定制文件也存储有第一制式，该方法包括：获取到第一数据包，第一数据包包括目标操作系统的升级数据和目标制式，目标制式不同于第一制式；将第一数据包中的目标制式写入电子设备的第二存储块tmp；利用第一数据包中的目标操作系统的升级数据将电子设备的操作系统升级为目标操作系统；将tmp中缓存的目标制式写入oem；清除定制文件中存储的第一制式，定制文件在电子设备开机时被写入oem中的目标制式，开机是指在清除之后的开机；其中，清除发生在将电子设备的操作系统升级为目标操作系统之后。

实施第一方面提供的方法，电子设备可以同时获取到目标操作系统的升级数据和目标制式。于是，在利用目标操作系统的升级数据将电子设备的操作系统升级到目标操作系统的过程中，电子设备可同时利用目标制式将电子设备的制式修改为目标制式。

这样，电子设备在系统升级的过程中，可以同时完成改制操作，避免了通过传统的改制工具进行改制所存在的硬件成本高、部署改制授权服务器难度大等问题。

结合第一方面提供的方法，在一些实施例中，定制文件在电子设备的存储器的用户数据分区Userdata，清除定制文件，具体包括：格式化Userdata。

实施上述实施例提供的方法，电子设备可以通过格式化Userdata的方法实现清除定制文件。这样，电子设备无需专门搜索定制文件。

结合第一方面提供的方法，在一些实施例中，该方法还包括：执行重启操作，进入recovery模式；清除定制文件是在recovery模式下完成的。

实施上述实施例提供的方法，电子设备可以重启进入recovery模式，通过recovery模式提供的恢复出厂设置的功能实现格式化Userdata、清除定制文件。

结合第一方面提供的方法，在一些实施例中，电子设备的存储器还包括系统分区，系统分区用于存储与电子设备的操作系统相关的系统数据；系统分区包括第一静态分区、第二静态分区和动态分区，利用第一数据包中的目标操作系统的升级数据将电子设备的操作系统升级为目标操作系统，具体包括：在电子设备从第一静态分区启动的状态下，将第一数据包中的目标操作系统的升级数据写入第二静态分区和虚拟动态分区，虚拟动态分区是Userdata中的一段存储分区；在recovery模式下，将第二静态分区中存储的目标操作系统的升级数据写入第一静态分区；在recovery模式下，将虚拟动态分区中存储的目标操作系统的升级数据写入动态分区；将tmp中缓存的目标制式写入oem是在recovery模式下完成的。

实施上述实施例提供的方法，电子设备在recovery模式下进行升级操作系统的copy操作和merge操作。结合前述在recovery模式下进行改制，这样，电子设备可以在第一次重启时直接进入recovery模式，在recovery模式完成升级操作系统和改制的操作，避免多次重启，切换电子设备的工作模式(安卓模式和recovery模式)，提升改制速度，缩短改制周期。

结合第一方面提供的方法，在一些实施例中，该方法还包括：为电子设备的recovery模式配置第一工具包；在recovery模式下，将虚拟动态分区中存储的目标操作系统的升级数据写入动态分区，具体包括：在recovery模式下，利用第一工具包，将虚拟动态分区中存储的目标操作系统的升级数据写入动态分区。

实施上述实施例提供的方法，基于预置的第一工具包(即snapshot和snapuser)，电子设备可以支持在recovery模式下进行升级操作系统的copy操作和merge操作，从而使得电子设备可以在第一次重启时直接进入recovery模式，在recovery模式完成升级操作系统和改制的操作，避免多次重启，切换电子设备的工作模式(安卓模式和recovery模式)，提升改制速度，缩短改制周期。

结合第一方面提供的方法，在一些实施例中，在执行重启操作，进入recovery模式之前，电子设备工作在安卓模式。

结合第一方面提供的方法，在一些实施例中，在执行重启操作之前，该方法还包括：写入恢复出厂命令；执行重启操作，进入recovery模式，具体包括：执行重启操作，响应于恢复出厂命令，进入recovery模式。

实施上述实施例提供的方法，电子设备可以通过写入特定的命令的方式，指示电子设备在重启时进入recovery模式，而不进入安卓模式。

结合第一方面提供的方法，在一些实施例中，写入恢复出厂命令，具体包括：在电子的存储器的第一路径下写入恢复出厂命令，第一路径是所述电子设备开机的固定挂载路径。

实施上述实施例提供的方法，电子设备可以在开机必须挂载的第一路径下，例如/cache/command下，写入恢复出厂命令。这样，电子设备在重启时，在挂载第一路径时，可获取到上述恢复出厂命令，从而进入recovery模式。

结合第一方面提供的方法，在一些实施例中，将tmp中缓存的目标制式写入oem，和，利用第一数据包中的目标操作系统的升级数据将电子设备的操作系统升级为目标操作系统，是在安卓模式下完成的；执行重启操作，进入recovery模式，具体包括：执行重启操作，在重启时检测到定制文件存储的第一制式与oem中存储的目标制式不一致；响应于不一致，进入recovery模式。

实施上述实施例提供的方法，电子设备可以先重启进入安卓模式，完成升级操作系统的copy操作和merge操作，和改制操作。然后，在再次重启时，电子设备可由重启时检测到定制文件存储的oem中存储的目标制式不一致触发进入recovery模式。这时，电子设备无需写入特定的命令，例如上述恢复出厂命令，控制电子设备进入recovery模式。

结合第一方面提供的方法，在一些实施例中，电子设备当前使用的操作系统为演示机操作系统，目标操作系统为商用机操作系统。

实施上述实施例提供的方法，安装有演示机操作系统的门店演示产品可采用本申请实施提供的改制方法，通过OTA的方式修改制式，并升级到新制式对应的操作系统，然后作为商用产品出售给消费者。

第二方面，本申请提供了一种电子设备，该电子设备包括一个或多个处理器和一个或多个存储器；其中，一个或多个存储器与一个或多个处理器耦合，一个或多个存储器用于存储计算机程序代码，计算机程序代码包括计算机指令，当一个或多个处理器执行计算机指令时，使得电子设备执行如第一方面以及第一方面中任一可能的实现方式描述的方法。

第三方面，本申请提供一种计算机可读存储介质，包括指令，当上述指令在电子设备上运行时，使得上述电子设备执行如第一方面以及第一方面中任一可能的实现方式描述的方法。

可以理解地，上述第二方面提供的电子设备、第三方面提供的计算机存储介质均用于执行本申请所提供的方法。因此，其所能达到的有益效果可参考对应方法中的有益效果，此处不再赘述。

附图说明

图1是本申请实施例提供的电子设备100的存储器的分区表示意图；

图2是本申请实施例提供的一种随系统升级操作更改制式的场景示意图；

图3是本申请实施例提供的一种电子设备100获取升级改制包并执行升级改制操作的流程图；

图4是本申请实施例提供的升级改制过程中电子设备100的分区表的变化示意图；

图5是本申请实施例提供的另一种电子设备100获取升级改制包并执行升级改制操作的流程图；

图6是本申请实施例提供的一种为recovery模式配置图；

图7是本申请实施例提供的另一种升级改制过程中电子设备100的分区表的变化示意图；

图8是本申请实施例提供的电子设备100的结构示意图。

具体实施方式

本申请以下实施例中所使用的术语只是为了描述特定实施例的目的，而并非旨在作为对本申请的限制。

无线通信设备可称为电子设备100。在本申请实施例中，电子设备100可以为手机、平板电脑等无线通信设备。在其他实施例中，电子设备100还可以是桌面型计算机、膝上型计算机、手持计算机、笔记本电脑、超级移动个人计算机(ultra-mobile personalcomputer，UMPC)、上网本，以及蜂窝电话、个人数字助理(personal digital assistant，PDA)、增强现实(augmented reality，AR)设备、虚拟现实(virtual reality，VR)设备、人工智能(artificial intelligence,AI)设备、可穿戴式设备、车载设备、智能家居设备和/或智慧城市设备，本申请实施例对该电子设备的具体类型不作特殊限制。

一般的，在电子设备100出厂前进行初始操作系统的安装时，厂商会根据其销售区域安装已配置好对应制式的操作系统。但是，在实际应用场景中，存在更改制式的情况。

例如，区域A的设备售罄后，需要从区域B调货。这时，从区域B调来的电子设备100在投入区域A(目标地区)之前，厂商需要将原来该电子设备100中配置的制式B(区域B对应的制式，例如“All/cn”)修改为制式A(区域A对应的制式，例如“cmcc/cn”或其他与“All/cn”不同的制式)，使其能在区域A内正常使用。因此，需要一种更改电子设备100的制式的方法，批量的处理电子设备100的改制需求，以提升改制效率。

在一些实施例中，电子设备100可以通过专用的改制工具完成改制。在通过专用的改制工具改制时，厂商需要一一地将需要改制的电子设备100与改制工具连接，进行授权验证使改制工具具备修改电子设备100制式的权限，然后通过改制工具完成改制。上述方法存在的硬件成本高、部署改制授权服务器难度大等问题。

为了避免上述问题，本申请提供的一种随系统升级操作更改制式的方法。实施该方法，电子设备100可获取带有制式信息的系统升级包，称为升级改制包。在利用上述升级改制包升级电子设备100的操作系统的同时，电子设备100可依据升级改制包中的制式信息修改自身的制式，并随开机过程中的初始化操作，完成改制。

这样，电子设备100在系统升级的过程中，可以同时完成改制操作，避免了通过传统的改制工具进行改制所存在的硬件成本高、部署改制授权服务器难度大等问题。

电子设备100中设置有存储器。电子设备100的操作系统、用户数据等数据可存储在存储器中。存储器中设置有分区表，用于描述存储器的分区部署，定义每个分区的起始地址和大小。以采用安卓虚拟A/B升级方式的电子设备100为例，图1是本申请实施例提供的电子设备100的存储器的分区表示意图。

如图1所示，电子设备100的存储器包括基础分区(Common)、系统分区、用户数据分区(Userdata)。基础分区用于存储不参与操作系统升级的系统数据。系统分区用于保存操作系统数据，操作系统升级则是针对系统分区中的数据进行升级操作。用户数据分区用于保存用户的个人数据，例如，用户个人安装的APP、用户个人保存的图片、文档以及视频等个人数据。

在虚拟A/B架构下，系统分区包括静态分区(A)、静态分区(B)和动态分区(Super)。静态分区(A)通常用于存储开机引导程序。静态分区(A)与静态分区(B)的结构相互对应，存储对应的系统镜像文件。静态分区(A)与静态分区(B)子分区命名通过后缀_a以及_b相互区分。例如，静态分区(A)包括bootloader_a、boot_a、vendor_boot_a、dtbo_a、vbmeta_a；静态分区(B)包括bootloader_b、boot_b、vendor_boot_b、dtbo_b、vbmeta_b。静态分区(A)也称第一静态分区，静态分区(B)也称第二静态分区。动态分区(Super)通常用于存储系统运行程序。动态分区包含多个子分区，例如system、system_ext、product、version、preload、vendor、Cust、Odm。

电子设备100从一个静态分区启动。例如，电子设备100从静态分区(A)启动：依次加载基础分区(Common)、静态分区(A)以及动态分区(Super)；电子设备100从静态分区(B)启动：依次加载基础分区(Common)、静态分区(B)以及动态分区(Super)。

制式信息，例如All/cn、cmcc/cn，存储在基础分区(Common)中的一个独立的子分区中，例如Oeminfo子分区。一般的，Oeminfo子分区包括oem。oem中记录的制式为当前电子设备100的正式制式。改制前，oem中记录的电子设备100的当前制式也称为第一制式。示例性的，电子设备100的oem中记录的制式为VC_1。VC_1是与调货前电子设备100所在地区B匹配的制式(制式B)。在改制的过程中，电子设备100可在Oeminfo子分区中创建tmp，用于记录目标制式，例如制式VC_2(制式A)。oem和tmp的本质为一块存储空间，用于存储制式信息。

在启动操作系统的过程中，电子设备100读取并加载oem中的制式信息，并将上述制式信息写入到用户数据分区(Userdata)中的定制文件中，以便在操作系统运行过程中被调用。上述定制文件例如Custom.bin文件。例如，在地区B启用电子设备100时，Custom.bin文件会被写入上述制式VC_1。

在每次电子设备100启动时，电子设备100会检测oem中记录的制式信息与定制文件(Custom.bin)中的制式信息是否匹配。当不匹配时，电子设备100的运行就可能出现错误。因此，在修改电子设备100的制式时，电子设备100需要修改oem中的制式信息，并同步更新定制文件(Custom.bin)中的制式信息，以使得修改后的电子设备100能够正常启动运行。因此，在将oem中的制式VC_1修改为VC_2之后，电子设备100还需更新定制文件(Custom.bin)中的制式，将定制文件(Custom.bin)中的制式由VC_1修改为VC_2。

图2是本申请实施例提供的一种随系统升级操作更改制式的场景示意图。

如图2所示，示例性的，电子设备100当前配置的制式为VC_1(旧制式)，当前使用的操作系统版本记为OS1.0(旧操作系统)。

在确定目标地区后，研发人员可确定与目标地区匹配的制式、操作系统版本。例如，研发人员可确定与目标地区匹配的制式VC_2(即目标制式，也称新制式)、和操作系统OS2.0(即目标操作系统，也称新操作系统)。地区与制式之间存在映射关系，同时，制式与操作系统之间存在映射关系。研发人员可根据上述地区与制式之间的映射关系和制式与操作系统之间的映射关系，确定目标制式和目标操作系统。

然后，研发人员可基于目标操作系统(OS2.0)的系统升级包，构建包含目标制式(VC_2)的升级改制包(即第一数据包)，用于更新电子设备100的制式和操作系统。升级改制包可存放在服务器A中。服务器A也称拍包服务器。在一些示例中，拍包服务器是由多个服务器组成的服务器集群。

在一些示例中，研发人员也可在拍包服务器中建立地区、制式和操作系统版本之间的映射关系。在确定目标地区之后，拍包服务器可根据上述映射关系(地区与制式之间存在映射关系、制式与操作系统之间存在映射关系)确定目标制式和目标操作系统，进而，拍包服务器可自动生成包含目标制式和目标操作系统的升级改制包。

需要更改制式的电子设备100可从拍包服务器中获取升级改制包，并执行升级改制动作。

在获取到升级改制包、并执行升级改制操作之后，电子设备100的制式可更新为目标制式，电子设备100的操作系统升级可升级为目标操作系统。例如，在根据上述升级改制包(VC_2+OS2.0)执行升级改制操作后，电子设备100的制式可由VC_1更新为目标制式VC_2，操作系统可由OS1.0升级为目标操作系统OS2.0。

在将地区B的门店演示设备转为商用设备发往地区A销售的改制场景下，上述旧操作系统OS1.0为演示机操作系统，上述目标操作系统OS2.0为商用机操作系统。

图3是本申请实施例提供的一种电子设备100获取升级改制包并执行升级改制操作的流程图。

S101.准备升级改制包。

拍包服务器内可预置一个或多个升级改制包。升级改制包中包括制式信息和操作系统升级数据。

升级改制包中的制式信息以targe_vendor_country.mbn文件的形式保存在升级改制包的根目录中。targe_vendor_country.mbn文件的内容指示了目标制式。

升级改制包中还包括操作系统升级数据(包含静态分区升级数据和动态分区升级数据)。静态分区升级数据例如目标操作系统的开机引导程序。静态分区升级数据用于升级电子设备100的静态分区。动态分区升级数据例如目标操作系统的系统运行程序。动态分区升级数据用于升级电子设备100的动态分区。参考图2的介绍，升级改制包中的操作系统升级数据(即目标操作系统)与升级改制包中制式信息(目标制式)匹配。

图4是本申请实施例提供的升级改制过程中电子设备100的分区表的变化示意图。图4中的(b)图可表示升级改制包的数据结构。参考图4中的(b)图，升级改制包可包括VC、Bootloader(2.0)、Boot(2.0)、Super等分区。VC分区(targe_vendor_country.mbn文件)记录了目标制式VC_2(例如“cmcc/cn”)。Bootloader(2.0)、Boot(2.0)中记录了目标操作系统OS2.0的静态分区升级数据。Super中记录了目标操作系统OS2.0的动态分区升级数据。

S102.获取升级改制包。

初始时，电子设备100可从静态分区(A)启动：依次加载基础分区(Common)、静态分区(A)以及动态分区(Super)。S101所示的步骤可以在电子设备100启动后执行，也可以在电子设备100启动前执行。

在启动后，电子设备100可通过系统更新代理模块(Update_apk_client)获取操作升级改制包。Update_apk_client是电子设备100中预置的用于从远程镜像源(例如拍包服务器)中获取系统镜像数据(例如OS2.0镜像数据)的工具。

Update_apk_client可定期地向拍包服务器发起搜包请求。同时，Update_apk_client也可基于用户操作发起搜包请求。在本申请实施例中，上述搜包请求中可包括制式信息。拍包服务器可根据搜包请求中的制式信息，检索对应的升级改制包。例如，搜包请求中可包括目标制式VC_2。拍包服务器可根据上述目标制式VC_2确定基于制式VC_2和操作系统OS2.0生成的升级改制包。

可选的，搜包请求中还可包含电子设备100当前运行的操作系统的版本号，例如OS1.0。拍包服务器可根据搜包请求中的操作系统版本号，确定包括更新的操作系统版本的升级改制包。例如，拍包服务器中可包括：基于制式VC_2和操作系统OS1.0生成的升级改制包和基于制式VC_2和操作系统OS2.0生成的升级改制包。根据搜包请求中的指示信息VC_2和当前运行的操作系统的版本号OS1.0，拍包服务器可从上述两个升级改制包中确定操作系统版本OS2.0对应的升级改制包。

拍包服务器可向电子设备100返回升级改制包的下载地址。电子设备100根据拍包服务器返回的下载地址下载对应的升级改制包。

S103.触发Updata_engine进行升级改制。

S104.校验升级改制包。

升级模块(Updata_engine)电子设备100中预置的存储有升级改制处理逻辑的功能模块，可用于执行升级改制操作。在获取到升级改制包之后，首先，Updata_engine可校验升级改制包。具体的，校验升级改制包，包括验证升级改制包的数字签名是否合法。

S105.写入升级改制包中的操作系统升级数据：(1)将静态分区升级数据写入静态分区(B)；(2)将动态分区升级数据写入Userdata的虚拟动态分区。

当升级改制包通过校验后，Updata_engine可利用升级改制包中的操作系统升级数据(静态分区升级数据和动态分区升级数据)，升级系统分区。

(1)将静态分区升级数据写入静态分区(B)：

在从静态分区(A)启动的场景下，Updata_engine可将升级改制包中的静态分区升级数据写入静态分区(B)。写入操作存在写入失败的情况。当出现写入失败时，Updata_engine会中断整个操作系统升级操作，向用户输出升级失败提示(例如，显示升级失败的对话框)，自动重新升级或者由用户确定是否重新升级或放弃升级。

Updata_engine可对执行写入操作后的静态分区(B)进行数据校验，以确认静态分区升级数据是否成功写入静态分区(B)。示例性的，在从OS1.0升级到OS2.0的场景下，升级改制包可包含OS2.0的静态分区升级数据以及OS2.0的静态分区升级数据的哈希值。在执行写入操作之后，Updata_engine可计算静态分区(B)中数据的哈希值，并确定静态分区(B)中数据的哈希值与升级改制包中记录的OS2.0的静态分区升级数据的哈希值是否一致。如果一致，则说明写入成功，Updata_engine可进行后续操作系统升级操作；如果不一致，则说明数据写入失败，升级失败。

参考表1，以一个静态分区子分区boot为例，从OS1.0升级到OS2.0的升级改制包可包含如下数据：

表1

项目	说明
		Name:boot	分区名称，表示当前数据为指向子分区boot的升级数据
Start:12222	数据块起始地址，表示子分区boot的升级数据的起始位置
		size:2410	数据大小，表示子分区boot的升级数据的大小
TargetHash:HASH12	目标哈希值，表示OS2.0的子分区boot的升级数据的哈希值

Updata_engine可从Common分区中读取固定挂载路径，如/dev/block/by-name/misc，确定电子设备100当前从静态分区(A)或静态分区(B)启动。然后，基于从静态分区(A)启动的场景，Updata_engine可确定静态分区(B)的子分区boot的路径，如/dev/block/by-name/boot_b。

在确定子分区boot的路径后，Updata_engine将OS2.0中对应子分区boot的升级数据写入到子分区boot_b中，即/dev/block/by-name/boot_b下。在完成写入操作之后，Updata_engine可计算子分区boot_b(即/dev/block/by-name/boot_b)中写入的数据的哈希值，确定子分区boot_b的哈希值与目标哈希值(TargetHash:HASH12)是否一致。如果一致，则静态分区的子分区boot升级成功，可以针对下一个静态分区子分区进行升级；如果不一致，则升级操作失败。

Updata_engine可按照上述介绍的写入、校验操作，将升级改制包中所包含的各个静态分区子分区的升级数据写入到静态分区(B)中对应子分区，并校验是否写入正确。其中，如果升级改制包不包含某个静态分区子分区升级数据，则Updata_engine可将静态分区(A)中对应子分区的数据同步到静态分区(B)中该子分区中。在升级过程中，当一个子分区出现升级错误，哈希校验失败，则中断升级操作，升级失败；当所有子分区升级成功，则静态分区升级成功，可以执行后续步骤。

进一步的，当某个静态分区升级失败时，静态分区的数据无法用于顺利启动操作系统。这时，为了避免在操作系统启动过程中加载升级失败的静态分区而导致操作系统启动错误，静态分区可携带状态标记：可启动或不可启动。电子设备100在加载静态分区数据之前可首先读取静态分区状态标记。当静态分区的状态标记为可启动时，电子设备100才加载该静态分区的数据。具体的，静态分区的状态标记可保存在Common分区的元数据(/matadata)中。

示例性的，在升级静态分区(B)之前，Updata_engine可将静态分区(B)标记为不可启动，在静态分区(B)升级成功后，Updata_engine可将静态分区标记为可启动。这样，如果静态分区(B)升级失败，则静态分区(B)的状态会保持为不可启动。电子设备100就不会加载升级失败的静态分区的数据。

(2)将动态分区升级数据写入Userdata的虚拟动态分区：

Updata_engine可在用户数据分区(Userdata)中创建虚拟动态分区，并将升级改制包中的动态分区升级数据写入上述虚拟动态分区。例如，在从OS1.0升级到OS2.0的场景下，升级改制包中包括OS2.0的动态分区升级数据。在执行S104之后，Updata_engine可在Userdata中创建虚拟动态分区。然后，Updata_engine可将OS2.0的动态分区的升级数据写入上述已创建的虚拟动态分区中。

通常的，在系统升级过程中，旧操作系统的动态分区中的数据与新操作系统的动态分区中的数据存在重叠，即部分数据是相同的。因此，在虚拟A/B框架下，动态分区(Super)升级可采用增量升级式。具体的，用户数据分区(Userdata)的虚拟动态分区可仅保存旧操作系统中需要升级动态分区升级数据，而并非保存新操作系统的全部动态分区数据。

以system子分区为例，在OS1.0中，system子分区中的数据可以分为system1、system2两部分。其中，在从OS1.0升级到OS2.0时，syetem1需要被升级为system3，system2无需变化。这时，用户数据分区(Userdata)创建虚拟动态分区仅需写入system3。

在虚拟A/B框架下，Updata_engine可通过快照技术(snapshot)实现动态分区(Super)的增量升级。具体的，Updata_engine可在虚拟动态分区中采用写时拷贝(Copy-On-Write，COW)文件保存动态分区(Super)的升级数据。虚拟动态分区中包含多个COW文件。一个COW文件对应一个动态分区(Super)的子分区。COW文件的命名与其所针对的动态分区(Super)子分区相对应。例如，针对system子分区的COW文件被命名为system-cow-img.img.0000。

Updata_engine在获取到升级改制包中的全部COW文件之后，可为每个COW文件附加A/B分区标记。例如，在从静态分区(A)启动的场景下(电子设备100当前运行操作系统所加载的动态分区(Super)为动态分区(A))，Updata_engine在用户数据分区(Userdata)中创建的虚拟动态分区是针对动态分区(B)。这时，Updata_engine可为COW文件附加对应动态分区(B)的分区标记。例如，上述针对system子分区的COW文件system-cow-img.img.0000可标记为system_b-cowimg.img.0000。

COW文件中包含COW文件自身的COW文件地图(快照map)和升级数据。COW文件地图与COW文件所针对的动态分区(Super)子分区的文件地图相对应。动态分区(Super)子分区的文件地图用于描述当前操作系统(OS1.0)中的文件以及各个文件的保存地址。虚拟动态分区中COW文件地图则用于描述目标操作系统(OS2.0)中的文件以及各个文件的保存地址。虚拟动态分区中COW文件地图还可指示目标操作系统(OS2.0)中的文件与前操作系统(OS1.0)中的文件的对应关系。

基于动态分区(Super)子分区的文件地图以及COW文件地图，Updata_engine后续可以使用COW文件替换动态分区(Super)子分区中的对应文件，从而实现动态分区(Super)数据的升级。

参考表2，以动态分区(Super)子分区system为例，Super中的子分区system的文件路径和文件地图可如下表所示：

表2

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

假设当前操作系统OS1.0的动态分区(Super)中待更新数据为/system/app/A2.XXX和/system/user/C2.XXX。示例性的，虚拟动态分区中COW文件可如表3所示：

表3

同样的，表3中文件名后的数值(例如045033～045035以及045036～045040)为COW文件/system/app/A2.XXX、/system/user/C2.XXX在用户数据分区(Userdata)中虚拟动态分区的物理保存地址(块地址)。

表2中的/system/app/A2.XXX、/system/user/C2.XXX可视为system1，表2中的其他文件可视为system2。表3中的COW文件(/system/app/A2.XXX、/system/user/C2.XXX)可视为system3。

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

S106：创建tmp-vc，写入目标制式VC_2。

通常情况下，Updata_engine从拍包服务器下载的升级包不包括制式信息。在执行完S104和S105之后，Updata_engine可向Update_apk_client返回升级操作完成的状态信息。

而在本申请实施例中，电子设备100需要随系统升级操作更改制式，因此，在获取到升级包之后，Updata_engine还需确定从拍包服务器下载的升级包是否用于改制。Updata_engine可根据升级包是否包含制式信息确定是否用于改制。当确定用于改制后，Updata_engine可在Oeminfo子分区中创建tmp-vc，并将升级包中的制式信息写入tmp-vc中。

本申请实施例所例举的升级改制包包括目标操作系统OS2.0的升级数据和目标制式VC_2。因此，在获取到升级改制包之后，Updata_engine可确定该数据还用于改制。这时，Updata_engine可在Oeminfo子分区中创建tmp-vc，并将目标制式VC_2写入上述tmp-vc。

本申请实施例对电子设备100执行步骤S105、S106的先后顺序不作限制。

图4中的(a)图可表示执行升级改制操作之前(即执行步骤S105、S106之前)的电子设备100的分区表示意图。此时，电子设备100的oem中存储的制式为旧制式VC_1。在从静态分区(A)启动的状态下，电子设备100工作在静态分区(A)、动态分区(Super)支持的操作系统OS1.0。此时，定制文件Custom.bin中记录制式与oem一致，为VC_1。

在写入升级改制包中的数据(制式信息、操作系统升级数据)之后，即执行步骤S105、S106之后，电子设备100的分区表示意图可如图4中的(c)图所示。此时，Oeminfo子分区中增加了tmp。tmp中存储了新制式VC_2。静态分区(B)中Bootloader_b、Boot_b等子分区中存储了操作系统OS2.0的静态分区升级数据，表示为Bootloader_b(2.0)、Boot_b(2.0)。Userdata中新增了虚拟动态分区，用于存储操作系统OS2.0的动态分区升级数据，例如System(2.0)。

S107：返回完成升级的状态信息。

在Updata_engine执行S104～S106所示的升级操作时，Update_apk_client可监测S104～S106所示升级操作的进度。电子设备100可根据Update_apk_client检测到的进度，显示对应的进度控件，用于向用户展示升级进度。

在写入升级改制包中的数据(制式信息、操作系统升级数据)之后，即执行步骤S105、S106之后，Updata_engine可向Update_apk_client返回完成升级的状态信息。对应的，进度控件可指示用户展示升级完成。

S108：触发重启(第一次重启)。

在接收到Updata_engine返回完成升级的状态信息之后，Update_apk_client可触发重启(第一次重启)。在本申请实施例中，优选的，在触发重启后，电子设备100可自动进入重启程序。在另一些实施例中，电子设备100也可根据用户操作确定是否立即重启。例如，电子设备100可通过屏幕显示弹窗，提示用户用选择立即重启或稍后重启。若用户选择稍后重启，进一步的，用户可以指定重启的时间，例如当天晚上12点。电子设备100可在用户指定的重启时间到来时进入重启程序，执行重启操作。

电子设备100在执行第一次重启时，可从静态分区(B)启动，运行更新后的操作系统，即上述目标操作系统OS2.0。这时，电子设备100工作在安卓Android模式。Common分区中记录的静态分区(B)的状态标记“可启动”可指示电子设备100从静态分区(B)启动。Common分区中元数据(/metadata)中的落盘状态信息“未落盘”可指示电子设备100在加载静态分区(B)后，采用snapshot合并加载动态分区(Super)和虚拟动态分区。

S109：检测oem中的制式与定制文件(Custom.bin)中的制式是否匹配？

在启动操作系统的过程中，若oem中的制式与Userdata的定制文件(Custom.bin)中的制式不匹配时，操作系统的运行就可能出现错误。

在重启时，电子设备100会执行初始化操作。执行初始化操作的初始化模块中包括监督初始化(cust_init)进程。cust_init可用于检测oem中的制式与定制文件(Custom.bin)中的制式是否匹配。当匹配时，电子设备100可继续进行重启操作；当不匹配时，电子设备100可进入恢复出厂设置(recovery)模式，进行恢复出厂设置操作：格式化定制文件(Custom.bin)。在格式化定制文件(Custom.bin)后，电子设备100可然后根据oem中的新制式更新定制文件(Custom.bin)，从而使oem中的制式与定制文件(Custom.bin)中的制式重新匹配。

在第一次重启时，oem中的制式仍然为旧制式VC_1。此时，用户数据分区(Userdata)中的定制文件(Custom.bin)中记录的制式也是旧版本的制式(VC_1)。这时，电子设备100可继续进行重启操作。

S110：执行merge操作，将虚拟动态分区中的COW文件写入动态分区(Super)。

参考S105的介绍，在将动态分区升级数据写入Userdata的虚拟动态分区之后，Updata_engine可将基础分区(Common)的元数据分区(/metadata)中的落盘状态信息由“已落盘(merged)”改为“未落盘(wait for merge)”，指示当前存在需要落盘到动态分区(Super)的COW文件。

在执行S110时，根据落盘状态信息“未落盘(wait for merge)”，Updata_engine可确定执行落盘(merge)操作。在本申请说明书中，落盘操作指的是：在操作系统升级过程中，将用户数据分区(Userdata)上虚拟动态分区中保存的动态分区(Super)升级数据(COW文件)写入到动态分区(Super)中，使得动态分区(Super)完成数据升级的操作。在完成merge之后再次启动时，电子设备100只需加载动态分区(Super)就可以完成设备启动，而不再需要加载动态分区(Super)和虚拟动态分区。

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

以S105中表2和表3所示的子分区system和COW文件为例，在执行merge操作时，Updata_engine可将虚拟动态分区中的子分区system的升级数据写入动态分区(Super)中的子分区system中。例如，Updata_engine可根据地址045033～045035获取COW文件A2.XXX，并替换地址024018～024020上的待更新数据A2.XXX，根据地址045036～045040COW文件获取C2.XXX，并替换地址024036～024040上的待更新数据C2.XXX。

在将虚拟动态分区的COW文件写入到动态分区(Super)中的对应地址之后，Updata_engine可删除用户数据分区(Userdata)中的COW文件，将对应的存储空间归还给用户数据分区(Userdata)。同时，Updata_engine可将基础分区(Common)的元数据(/metadata)中的落盘状态信息由“未落盘(wait for merge)”改为“已落盘(merged)”。

S111：执行copy操作，将静态分区(B)中的数据写入静态分区(A)中。

Updata_engine可根据静态分区(A)、静态分区(B)中对应子分区的地址，依次将静态分区(B)中各个子分区的数据写入对应的静态分区(A)子分区中，完成静态分区(A)、静态分区(B)的数据同步。

在S110中，merge操作是针对动态分区(Super)中的操作系统数据进行的，并不会影响到当前启动所使用的虚拟动态分区中的操作系统数据。在S111中，copy操作是针对静态分区(A)中的操作系统数据进行的，并不会影响到当前启动所使用的静态分区(B)中的操作系统数据。因此，在整个操作系统升级的过程中，用户可以正常使用设备。

S112：将tmp中的制式信息写入oem中。

Updata_engine可将tmp中缓存的新制式VC_2写入oem中。在写入oem后，电子设备100的正式制式更新为新制式VC_2。随后，Updata_engine可清除tmp。

图4中的(d)图可表示执行merge操作、copy操作以及改制操作时电子设备100的分区表示意图。例如，Userdata中的System(2.0)中的COW文件可通过merge操作，写入到动态分区(Super)中的子分区system(1.0)中；静态分区(B)中Bootloader_b的中的数据可通过copy操作，写入静态分区(A)中对应的子分区Bootloader_a(1.0)中；静态分区(B)中Boot_b的中的数据可通过copy操作，写入静态分区(A)中对应的子分区Boot_a(1.0)中；tmp中存储的新制式VC_2可被写入到oem。在merge操作、copy操作以及改制操作执行完成后，在清除tmp和虚拟动态分区后，电子设备100的分区表示意图可如图4中的(e)图所示。

S113：触发重启(第二次重启)。

在merge操作、copy操作以及改制操作均完成后，Updata_engine可触发重启(第二次重启)。本申请实施例对电子设备100执行S110、S111、S112所示操作的先后顺序不作限制。电子设备100也可先执行copy操作，或改制操作等。

优选的，电子设备100可自动进入重启程序。在执行步骤S110、S111之后，静态分区(A)和静态分区(B)中的数据为互为镜像数据，即一致。电子设备100可从静态分区(A)或静态分区(B)启动。

参考S109，在重启时，电子设备100会执行初始化操作。在初始化过程中，监督初始化进程cust_init会检测oem中的制式与定制文件(Custom.bin)中的制式是否匹配。

S114：触发重启(第三次重启)，进入recovery模式。

参考图4中的(e)图，在第二次重启时，oem中的制式为新制式VC_2，而用户数据分区(Userdata)中的定制文件(Custom.bin)中记录的制式仍然为旧制式VC_1。这时，cust_init可确定oem中的制式与定制文件(Custom.bin)中的制式不匹配。于是，cust_init可触发进入recovery模式。

S115：清除定制文件(Custom.bin)。

进入recovery模式之后，电子设备100可恢复出厂设置的操作。在恢复出厂设置时，电子设备100可格式化Userdata分区，即清除当前Userdata分区全部数据。这时，Userdata分区中的定制文件(Custom.bin)也会一同被清除。

图4中的(f)图可表示执行恢复出厂设置操作后的电子设备100的分区表示意图。此时，Userdata中的定制文件(Custom.bin)为空。

到S115执行完，电子设备100完成系统升级和改制。此时的电子设备100可投入到目标地区发售使用。目标地区的用户在购得电子设备100之后，在开机时，电子设备100可以读取oem中的制式信息(适应目标地区的新制式)，并将上述制式信息写入到用户数据分区(Userdata)中的定制文件(Custom.bin)中，以便在操作系统运行过程中被调用。

实施图3所示的方法，电子设备100可以在升级操作系统的过程中完成改制操作，避免了通过传统的改制工具进行改制所存在的硬件成本高、部署改制授权服务器难度大等问题。

但是，图3所示的方法需要经历3次重启，整个升级改制的周期较长。同时，在第一次重启时，电子设备100工作在Android模式，用户可以执行任意操作。这样容易打断预置的流程，从而导致改制失败以及操作系统更新失败。例如，在执行S110之前，如果检测到用户做出了恢复出厂设置的操作，那么，电子设备100会立即格式化Userdata。这时，S110～S112所示的merge操作、copy操作以及改制操作被打断，电子设备100改制失败、操作系统更新失败。

为例缩短升级改制的周期，同时增强升级改制程序的健壮性，避免由于升级改制中断、进而避免改制失败、操作系统更新失败，本申请实施例提出了另一种随系统升级操作更改制式的方法。图5是本申请实施例提供的另一种电子设备100获取升级改制包并执行升级改制操作的流程图。

S200.配置snapshot和snapuser。

snapshot是关联物理地址和逻辑地址的工具。在执行merge操作时，电子设备100可基于snapshot生成虚拟动态分区中COW文件的文件地图，和动态分区(Super)对应子分区的文件地图。snapuser是压缩和解压缩COW文件，将虚拟动态分区中的COW文件写入动态分区(Super)的工具。

现有技术中，recovery模式不支持snapshot和snapuser。因此，在不改进recovery模式的结构的情况下，电子设备100需要在Android模式下执行merge操作。这也就导致电子设备100第一次重启需要进入Android模式，在Android模式下实施merge操作和copy操作，保证操作系统升级成功。

在本申请实施例中，研发人员可为recovery模式配置snapshot和snapuser，使得电子设备100可以在recovery模式下执行merge操作。上述snapshot和snapuser可称为第一工具包。

具体的，如图6所示，recovery模式的system/bin/路径下可包括recovery、Factory_reset等二进制文件。研发人员可在recovery文件中写入lib_snapshot_utils、lib_snapshot_nobinder函数库。上述lib_snapshot_utils、lib_snapshot_nobinder用于在recovery模式实现snapshot。同时，研发人员还可在system/bin/下创建Snapuserd文件，在recovery文件中写入配置文件Snapuserd.rc。system/bin/下创建Snapuserd文件和recovery文件配置文件Snapuserd.rc用于在recovery模式实现snapuser。

在配置snapshot和snapuser后，电子设备100可以在recovery模式下执行merge操作。这样，电子设备100在第一次重启时，可直接进入recovery模式，在recovery模式下执行merge操作、copy操作和改制操作。然后，电子设备100可紧接着进行恢复出厂设置操作，清除用户数据分区(Userdata)中的数据，清除定制文件(Custom.bin)中的旧制式。

S201.拍包服务器准备升级改制包。

S202.电子设备100通过Update_apk_client从拍包服务器获取升级改制包。

S203.触发Updata_engine进行升级改制。

S204.Updata_engine校验升级改制包。

S205.Updata_engine将升级改制包中的操作系统升级数据写入对应存储器分区：(1)将静态分区升级数据写入静态分区(B)；(2)将动态分区升级数据写入Userdata的虚拟动态分区。

S206.创建tmpvc，写入目标制式VC_2。

具体的，S201～S206所示的步骤可参考S101～S106的介绍，这里不再赘述。本申请实施例对S200和S201发生的先后顺序不作限定。

S207.写入恢复出厂命令。

在确定升级包包括制式信息(即升级包具体为升级改制包)后，Updata_engine可在特定路径中写入恢复出厂命令。上述特定路径是开机时电子设备100的固定挂载路径。这样，在开机时，电子设备100可固定地读取到上述恢复出厂命令。

具体的，Updata_engine可在特定路径/cache/command(也称第一路径)中写入命令："--wipe_data","--reason＝change_vcand_wipe_data"。上述命令即恢复出厂命令。

S208.触发重启(第一次重启)进入recovery模式。

同样的，在Updata_engine执行S204～S206所示的升级操作时，Update_apk_client可监测S204～S206所示升级操作的进度。电子设备100可根据Update_apk_client检测到的进度，显示对应的进度控件，用于向用户展示升级进度。

在升级操作完成之后，且写入恢复出厂命令之后，Updata_engine可向Update_apk_client返回完成升级的状态信息。对应的，进度控件可指示用户展示升级完成。随后，Update_apk_client可触发重启。在图5所示的方法中，此次重启为开始执行升级改制操作后的第一次重启。

在重启过程中，电子设备100会读取第一路径中的命令，执行命令指示的操作。这时，电子设备100可读取到前述(S207)写入第一路径(/cache/command)的恢复出厂命令："--wipe_data","--reason＝change_vcand_wipe_data"。解析上述恢复出厂命令，电子设备100可进入recovery模式。

S209.执行merge操作，将虚拟动态分区中的COW文件写入动态分区(Super)。

基于已经在recovery模式中配置好的snapshot和snapuser，在进入recovery模式后，recovery可将利用snapshot读取动态分区(Super)中元数据(metadata)和虚拟动态分区中COW文件，然后利用snapuser将虚拟动态分区中的COW文件写入动态分区(Super)，具体可参考S110的介绍。

S210.执行copy操作，将静态分区(B)中的数据写入静态分区(A)中。

S211.将tmp中的制式信息写入oem中。

S210～S211所示的步骤可参考S111～S112的介绍，这里不再赘述。

S212.格式化userdata分区清除定制文件(Custom.bin)。

由于当前处于recovery模式下，因此，在执行merge操作、copy操作和改制操作后，即执行S209～S211之后，电子设备100可立即执行恢复出厂设置的操作，格式化Userdata分区。在格式化Userdata分区时，Userdata分区中的定制文件(Custom.bin)也会一同被清除。

图7是本申请实施例提供的另一种升级改制过程中电子设备100的分区表的变化示意图。

图7中的(a)图可表示执行升级改制操作之前的(即执行步骤S205之前的)电子设备100的分区表示意图。图7中的(b)图可表示升级改制包的数据结构示意图。图7中的(c)图可表示升执行升级改制操作之后的电子设备100的分区表示意图。图7中的(a)图～(c)图具体介绍可参考图4中的(a)图～(c)图，这里不再赘述。

在图5所示的方法中，在第一次重启时(S208)，电子设备100可直接进入recovery模式。在recovery模式，电子设备100可依次执行merge操作、copy操作、改制操作和格式化Userdata的操作，而无需在recovery模式、Android模式之前切换。

如图7所示，在第一重启时，根据启动流程中写入的恢复出厂命令，电子设备100可进入recovery模式。参考图7中的(d)图，在recovery模式下，执行merge操作，电子设备100可将Userdata中的虚拟动态分区中的动态分区升级数据写入动态分区(Super)中；执行copy操作，电子设备100可将静态分区(B)中Bootloader_b、Boot_b等子分区存储的静态分区升级数据同步到静态分区(A)中；执行改制操作，电子设备100可将tmp中存储的新制式写入到oem，更新电子设备100的制式。最后，在recovery模式下，电子设备100可随即执行格式化Userdata的操作，清除Userdata的全部用户数据。这时，Userdata中的定制文件(Custom.bin)被清除。

图7中的(e)图可表示执行恢复出厂设置操作后的电子设备100的分区表示意图。此时，Userdata中的定制文件(Custom.bin)为空。

到S212执行完，电子设备100完成系统升级和改制。此时的电子设备100可投入到目标地区发售使用。目标地区的用户在购得电子设备100之后，在开机时，电子设备100可以读取oem中的制式信息(适应目标地区的新制式)，并将上述制式信息写入到用户数据分区(Userdata)中的定制文件(Custom.bin)中，以便在操作系统运行过程中被调用。

相比于图3所示的方法，图5所示的方法可以在recovery模式下执行merge操作、copy操作、改制操作和恢复出厂操作。电子设备100无需多次重启，有利于缩短整个升级改制的周期，提升升级改制的速度。同时，重启进入recovery模式，限制了升级改制操作过程中用户的操作，避免了用户操作中断升级改制流程导致改制失败以及操作系统更新失败。

图8是本申请实施例提供的电子设备100的结构示意图。

电子设备100可以包括处理器110，外部存储器接口120，内部存储器121，通用串行总线(universal serial bus，USB)接口130，天线1，天线2，移动通信模块150，无线通信模块160，传感器模块180，显示屏194等。其中传感器模块180可以包括压力传感器180A，触摸传感器180K等。

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

处理器110可以包括一个或多个处理单元，例如：处理器110可以包括应用处理器(application processor，AP)，调制解调处理器，图形处理器(graphics processingunit，GPU)，图像信号处理器(image signal processor，ISP)，控制器，视频编解码器，数字信号处理器(digital signal processor，DSP)，基带处理器，和/或神经网络处理器(neural-network processing unit，NPU)等。其中，不同的处理单元可以是独立的器件，也可以集成在一个或多个处理器中。控制器可以根据指令操作码和时序信号，产生操作控制信号，完成取指令和执行指令的控制。处理器110中还可以设置存储器，用于存储指令和数据。

在一些实施例中，处理器110可以包括一个或多个接口。接口可以包括集成电路(inter-integrated circuit，I2C)接口，集成电路内置音频(inter-integrated circuitsound，I2S)接口，脉冲编码调制(pulse code modulation，PCM)接口，通用异步收发传输器(universal asynchronous receiver/transmitter，UART)接口，移动产业处理器接口(mobile industry processor interface，MIPI)，通用输入输出(general-purposeinput/output，GPIO)接口，用户标识模块(subscriber identity module，SIM)接口，和/或通用串行总线(universal serial bus，USB)接口等。

示例性的，处理器110可以通过I2C接口耦合触摸传感器180K，使处理器110与触摸传感器180K通过I2C总线接口通信，实现电子设备100的触摸功能。处理器110通过UART接口与无线通信模块160中的蓝牙模块通信，实现蓝牙功能。MIPI接口包括显示屏串行接口(display serial interface，DSI)。处理器110和显示屏194通过DSI接口通信，实现电子设备100的显示功能。GPIO接口可以通过软件配置。GPIO接口可以被配置为控制信号，也可被配置为数据信号。GPIO接口还可以被配置为I2C接口，I2S接口，UART接口，MIPI接口等。

USB接口130是符合USB标准规范的接口，具体可以是Mini USB接口，Micro USB接口，USB Type C接口等。USB接口130可以用于连接充电器为电子设备100充电，也可以用于电子设备100与外围设备之间传输数据。在本申请实施例中，电子设备100可以通过USB接口130连接专用的改制工具，修改电子设备100的制式。

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

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

天线1和天线2用于发射和接收电磁波信号。电子设备100中的每个天线可用于覆盖单个或多个通信频带。不同的天线还可以复用，以提高天线的利用率。例如：可以将天线1复用为无线局域网的分集天线。在另外一些实施例中，天线可以和调谐开关结合使用。

移动通信模块150可以提供应用在电子设备100上的包括2G/3G/4G/5G等无线通信的解决方案。移动通信模块150可以包括至少一个滤波器，开关，功率放大器，低噪声放大器(low noise amplifier，LNA)等。移动通信模块150可以由天线1接收电磁波，并对接收的电磁波进行滤波，放大等处理，传送至调制解调处理器进行解调。移动通信模块150还可以对经调制解调处理器调制后的信号放大，经天线1转为电磁波辐射出去。在一些实施例中，移动通信模块150的至少部分功能模块可以被设置于处理器110中。在一些实施例中，移动通信模块150的至少部分功能模块可以与处理器110的至少部分模块被设置在同一个器件中。

调制解调处理器可以包括调制器和解调器。其中，调制器用于将待发送的低频基带信号调制成中高频信号。解调器用于将接收的电磁波信号解调为低频基带信号。随后解调器将解调得到的低频基带信号传送至基带处理器处理。低频基带信号经基带处理器处理后，被传递给应用处理器。应用处理器通过音频设备(不限于扬声器170A，受话器170B等)输出声音信号，或通过显示屏194显示图像或视频。在一些实施例中，调制解调处理器可以是独立的器件。在另一些实施例中，调制解调处理器可以独立于处理器110，与移动通信模块150或其他功能模块设置在同一个器件中。

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

在本申请实施例中，电子设备100可通过天线1，天线2，移动通信模块150，无线通信模块160，调制解调处理器以及基带处理器提供的无线通信功能从拍包服务器获取升级改制包，进而执行升级改制操作。

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

显示屏194用于显示图像，视频等。显示屏194包括显示面板。显示屏194包括显示面板。显示面板可以采用液晶显示屏(liquid crystal display，LCD)。显示面板还可以采用有机发光二极管(organic light-emitting diode，OLED)，有源矩阵有机发光二极体或主动矩阵有机发光二极体(active-matrix organic light emitting diode，AMOLED)，柔性发光二极管(flex light-emitting diode，FLED)，miniled，microled，micro-oled，量子点发光二极管(quantum dot light emitting diodes，QLED)等制造。在一些实施例中，电子设备可以包括1个或N个显示屏194，N为大于1的正整数。

在本申请实施例中，电子设备100可通过GPU，显示屏194，以及应用处理器等提供的显示功能显示用户界面，例如获取升级改制包的用户界面，进行升级改制过程中显示升级进度的用户界面等，以供用户进行升级改制操作。

内部存储器121可以包括一个或多个随机存取存储器(random access memory，RAM)和一个或多个非易失性存储器(non-volatile memory，NVM)。随机存取存储器可以由处理器110直接进行读写，可以用于存储操作系统或其他正在运行中的程序的可执行程序(例如机器指令)，还可以用于存储用户及应用程序的数据等。非易失性存储器也可以存储可执行程序和存储用户及应用程序的数据等，可以提前加载到随机存取存储器中，用于处理器110直接进行读写。

在本申请实施例中，图1所示的电子设备100的分区表对应的存储器是指上述非易失性存储器。电子设备100的制式信息、开机引导程序、系统运行程序等程序代码存储在非易失性存储器中。在开机运行电子设备100时，电子设备100可将非易失性存储器中存储的程序代码加载到随机存取存储器中，然后发送到处理器110中执行，以实现本申请实施例提供的随系统升级操作更改改制的方法。

外部存储器接口120可以用于连接外部的非易失性存储器，实现扩展电子设备100的存储能力。外部的非易失性存储器通过外部存储器接口120与处理器110通信，实现数据存储功能。

压力传感器180A用于感受压力信号，可以将压力信号转换成电信号。在一些实施例中，压力传感器180A可以设置于显示屏194。当有触摸操作作用于显示屏194，电子设备100根据压力传感器180A检测所述触摸操作强度。电子设备100也可以根据压力传感器180A的检测信号计算触摸的位置。

触摸传感器180K，也称“触控器件”。触摸传感器180K可以设置于显示屏194，由触摸传感器180K与显示屏194组成触摸屏，也称“触控屏”。触摸传感器180K用于检测作用于其上或附近的触摸操作。触摸传感器可以将检测到的触摸操作传递给应用处理器，以确定触摸事件类型。可以通过显示屏194提供与触摸操作相关的视觉输出。在另一些实施例中，触摸传感器180K也可以设置于电子设备100的表面，与显示屏194所处的位置不同。

在本申请实施例中，电子设备100可通过触摸传感器180K提供的触控检测能力，检测用户作用于屏幕的点击、滑动等用户操作，获取升级改制包，显示升级改制进度等等。

本申请的说明书和权利要求书及附图中的术语“用户界面(user interface，UI)”，是应用程序或操作系统与用户之间进行交互和信息交换的介质接口，它实现信息的内部形式与用户可以接受形式之间的转换。应用程序的用户界面是通过java、可扩展标记语言(extensible markup language，XML)等特定计算机语言编写的源代码，界面源代码在终端设备上经过解析，渲染，最终呈现为用户可以识别的内容，比如图片、文字、按钮等控件。控件(control)也称为部件(widget)，是用户界面的基本元素，典型的控件有工具栏(toolbar)、菜单栏(menu bar)、文本框(text box)、按钮(button)、滚动条(scrollbar)、图片和文本。界面中的控件的属性和内容是通过标签或者节点来定义的，比如XML通过<Textview>、<ImgView>、

<VideoView>等节点来规定界面所包含的控件。一个节点对应界面中一个控件或属性，节点经过解析和渲染之后呈现为用户可视的内容。此外，很多应用程序，比如混合应用(hybrid application)的界面中通常还包含有网页。网页，也称为页面，可以理解为内嵌在应用程序界面中的一个特殊的控件，网页是通过特定计算机语言编写的源代码，例如超文本标记语言(hyper text markup language，HTML)，层叠样式表(cascading stylesheets，CSS)，java脚本(JavaScript，JS)等，网页源代码可以由浏览器或与浏览器功能类似的网页显示组件加载和显示为用户可识别的内容。网页所包含的具体内容也是通过网页源代码中的标签或者节点来定义的，比如HTML通过<p>、<img>、<video>、<canvas>来定义网页的元素和属性。

用户界面常用的表现形式是图形用户界面(graphic user interface，GUI)，是指采用图形方式显示的与计算机操作相关的用户界面。它可以是在电子设备的显示屏中显示的一个图标、窗口、控件等界面元素，其中控件可以包括图标、按钮、菜单、选项卡、文本框、对话框、状态栏、导航栏、Widget等可视的界面元素。

在本申请的说明书和所附权利要求书中所使用的那样，单数表达形式“一个”、“一种”、“所述”、“上述”、“该”和“这一”旨在也包括复数表达形式，除非其上下文中明确地有相反指示。还应当理解，本申请中使用的术语“和/或”是指并包含一个或多个所列出项目的任何或所有可能组合。上述实施例中所用，根据上下文，术语“当…时”可以被解释为意思是“如果…”或“在…后”或“响应于确定…”或“响应于检测到…”。类似地，根据上下文，短语“在确定…时”或“如果检测到(所陈述的条件或事件)”可以被解释为意思是“如果确定…”或“响应于确定…”或“在检测到(所陈述的条件或事件)时”或“响应于检测到(所陈述的条件或事件)”。

在上述实施例中，可以全部或部分地通过软件、硬件、固件或者其任意组合来实现。当使用软件实现时，可以全部或部分地以计算机程序产品的形式实现。所述计算机程序产品包括一个或多个计算机指令。在计算机上加载和执行所述计算机程序指令时，全部或部分地产生按照本申请实施例所述的流程或功能。所述计算机可以是通用计算机、专用计算机、计算机网络、或者其他可编程装置。所述计算机指令可以存储在计算机可读存储介质中，或者从一个计算机可读存储介质向另一个计算机可读存储介质传输，例如，所述计算机指令可以从一个网站站点、计算机、服务器或数据中心通过有线(例如同轴电缆、光纤、数字用户线)或无线(例如红外、无线、微波等)方式向另一个网站站点、计算机、服务器或数据中心进行传输。所述计算机可读存储介质可以是计算机能够存取的任何可用介质或者是包含一个或多个可用介质集成的服务器、数据中心等数据存储设备。所述可用介质可以是磁性介质，(例如，软盘、硬盘、磁带)、光介质(例如DVD)、或者半导体介质(例如固态硬盘)等。

本领域普通技术人员可以理解实现上述实施例方法中的全部或部分流程，该流程可以由计算机程序来指令相关的硬件完成，该程序可存储于计算机可读取存储介质中，该程序在执行时，可包括如上述各方法实施例的流程。而前述的存储介质包括：ROM或随机存储记忆体RAM、磁碟或者光盘等各种可存储程序代码的介质。

Claims (8)

1.一种配置制式的方法，应用于电子设备，其特征在于，所述电子设备的存储器包括基础分区、系统分区和用户数据分区，所述基础分区包括第一存储块oem，所述oem中存储有第一制式，所述用户数据分区也存储有所述第一制式，所述系统分区包括第一静态分区、第二静态分区和动态分区，所述电子设备从所述第一静态分区启动，所述方法包括：

获取到第一数据包，所述第一数据包包括目标操作系统的升级数据和目标制式，所述目标制式不同于所述第一制式；

将所述升级数据中的静态分区升级数据写入所述第二静态分区；在所述基础分区中申请第二存储块tmp，将所述目标制式写入所述tmp；写入恢复出厂recovery命令；

执行重启操作，在所述重启过程中，响应于所述recovery命令，进入recovery模式；

在所述recovery模式下，将所述升级数据中的动态分区升级数据落盘到所述系统分区；将所述tmp中缓存的所述目标制式写入所述oem；格式化所述用户数据分区。

2.根据权利要求1所述的方法，其特征在于，所述执行重启操作之前，所述方法还包括：

配置第一工具snapshot和第二工具snapuser，

所述snapshot用于在所述recovery模式下关联物理地址和逻辑地址，所述snapuser用于在所述recovery模式下压缩和解压缩写时拷贝文件；

所述将所述升级数据中的动态分区升级数据落盘到所述系统分区，具体包括：

使用所述snapshot和snapuser将所述用户数据分区中缓存的所述动态分区升级数据落盘到所述系统分区。

3.根据权利要求1或2所述的方法，其特征在于，所述执行重启操作之前，所述电子设备工作在安卓模式。

4.根据权利要求1所述的方法，其特征在于，所述写入恢复出厂recovery命令，具体包括：在所述存储器的第一路径下写入所述recovery命令，所述第一路径是所述电子设备开机的固定挂载路径。

5.根据权利要求4所述的方法，其特征在于，所述第一路径具体为/cache/command。

6.根据权利要求1-5任一项所述的方法，其特征在于，所述电子设备当前使用的操作系统为演示机操作系统，所述目标操作系统为商用机操作系统。

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

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