操作系统的升级方法、设备及存储介质与流程

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


背景技术：

2.目前，对电子设备的操作系统进行升级的方式可分为需要进行重启(如冷补丁升级、空中下载技术(over-the-air technology，ota)升级等)的升级方式和不需要进行重启(如热补丁升级)的升级方式。
3.对于需要进行重启的升级方式，当升级包中的数据写入对应分区，电子设备重启后，在短时间内，多任务管理界面中展示的软件更新界面中依旧会存在触发电子设备进行重启的选项，并且从多任务管理界面启动该软件更新界面后，该软件更新界面中触发重启的选项依旧可以被用户触发，进而导致电子设备再次重启。


技术实现要素：

4.为了解决上述技术问题，本技术提供一种操作系统的升级方法、设备及存储介质，旨在使操作系统升级重启后的电子设备的用户交互界面能够及时刷新，多任务管理界面中展示的软件更新界面中不再显示触发电子设备进行重启的选项，以给用户带来更好地使用体验。
5.第一方面，本技术提供一种操作系统的升级方法，应用于电子设备。该方法包括：显示第一界面，第一界面显示了触发电子设备重启的第一选项；响应于对第一选项的点击操作，触发电子设备重启，以从升级前的第一操作系统运行到升级后的第二操作系统；在电子设备重启的过程中，获取属性文件中设置的第一重启属性值；其中，属性文件为存储在只读存储器中的全局共享文件；第一重启属性值为固定值，用于指示电子设备无须重启；根据第一重启属性值，刷新第一界面，取消显示在第一界面中的第一选项，显示触发电子设备搜索升级包的第二选项。
6.由此，在电子设备将第一操作系统升级到第二操作系统，触发重启的过程中，通过访问可全局共享的属性文件中设置的指示电子设备无须重启这一固定的第一重启属性值，进而根据第一重启属性值刷新第一界面，使得第一界面中不再显示触发电子设备重启的第一选项，从而使得电子设备重启后，用户不论从哪一入口立即访问第一界面，第一界面中均不会在显示第一选项，给用户带来了更好地使用体验。
7.根据第一方面，在电子设备重启的过程中，获取属性文件中设置的第一重启属性值，包括：在电子设备重启的过程中，从属性文件中读取第一重启属性和第一重启属性值；将第一重启属性和第一重启属性值以键值对的形式，写入共享内存。
8.通过将只读存储器中属性文件中存储的第一重启属性和第一重启属性值以键值对的形式写入共享内存，从而能够在电设备重启过程中，快速从共享内存获取第一重启属性，及时刷新第一界面，保证电子设备重启后，显示的用户交互界面没有异常。
9.根据第一方面，或者以上第一方面的任意一种实现方式，根据第一重启属性值，刷新第一界面，取消显示在第一界面中的第一选项，显示触发电子设备搜索升级包的第二选项，包括：从共享内存获取第一重启属性对应的第一重启属性值，根据第一重启属性值，刷新第一界面，取消显示在第一界面中的第一选项，显示触发电子设备搜索升级包的第二选项。
10.由此，根据全局共享的属性文件预先注册的指示电子设备无须重启的第一重启属性值，实现了对第一界面的及时刷新，不再依赖开机广播携带的状态信息，从而有效保证了第一界面显示内容的合理性。
11.根据第一方面，或者以上第一方面的任意一种实现方式，显示第一界面，第一界面显示了触发电子设备重启的第一选项，包括：显示第二界面，第二界面中包括第一提示窗口，第一提示窗口中显示了触发电子设备获取升级包，并基于升级包对操作系统进行升级的第三选项；响应于对第三选项的点击操作，获取升级包，并显示第一界面，第一界面显示了升级包的下载进度信息，不显示第一选项；在升级包下载成功后，将升级包中的升级文件写入到对应分区；在将升级包中的升级文件写入到对应分区的过程中，刷新第一界面，取消显示在第一界面中的下载进度信息，显示将升级包中的升级文件写入到对应分区的安装进度信息，不显示第一选项；在升级包中升级文件安装完毕后，刷新第一界面，取消显示在第一界面中的安装进度信息，显示第一选项。
12.由此，通过这种主动提示用户进行升级的方式，实现了一键获取升级包并安装，大大简化了用户的操作。
13.根据第一方面，或者以上第一方面的任意一种实现方式，获取升级包，包括：获取升级包对应的文件列表描述信息，文件列表描述信息记录了升级包的下载地址和重启标记，重启标记用于指示基于升级包对操作系统的升级涉及重启环节；从下载地址获取升级包到电子设备的用户数据分区；根据重启标记，将共享内存中存储的第一重启属性和第一重启属性值更新为第二重启属性和第二重启属性值，第二重启属性值指示电子设备需要重启。
14.由此，在对操作系统升级的过程中，通过根据重启标记，更新共享内存中指示电子设备是否需要重启的重启属性和重启属性值，如将指示无须重启的第一重启属性和第一重启属性值更新为指示需要重启的第二重启属性和第二重启属性值，从而能够在升级过程中，及时刷新第一界面，以在第一界面中显示供用户触发电子设备重启的第一选项，便于用户操作，及时重启电子设备。
15.根据第一方面，或者以上第一方面的任意一种实现方式，在升级包中升级文件安装完毕后，刷新第一界面，取消显示在第一界面中的安装进度信息，显示第一选项，包括：升级包中升级文件安装完毕后，从共享内存获取第二重启属性对应的第二重启属性值，根据第二重启属性值，刷新第一界面，取消显示在第一界面中的安装进度信息，显示第一选项。
16.根据第一方面，或者以上第一方面的任意一种实现方式，将升级包中的升级文件写入到对应分区，包括：对用户数据分区中的升级包进行解析，得到升级包中的升级文件；将对应静态分区的升级文件写入静态分区，将对应动态分区的升级文件写入动态分区。
17.根据第一方面，或者以上第一方面的任意一种实现方式，显示第一界面，第一界面显示了触发电子设备重启的第一选项，包括：显示第二界面，第二界面中包括第一应用，第
一应用集成了启动第一界面入口；其中，在未获取升级包前，从第一应用启动的第一界面中不显示第一选项；响应于对第一应用中启动第一界面入口的点击操作，显示第一界面，第一界面显示了第二选项，不显示第一选项；响应于对第二选项的点击操作，搜索升级包；在搜索到存在升级包时，刷新第一界面，取消显示在第一界面中的第二选项，显示触发电子设备获取升级包，并基于升级包对操作系统进行升级的第四选项；响应于对第四选项的点击操作，获取升级包，并显示第一界面，第一界面显示了升级包的下载进度信息，不显示第一选项；在升级包下载成功后，将升级包中的升级文件写入到对应分区；在将升级包中的升级文件写入到对应分区的过程中，刷新第一界面，取消显示在第一界面中的下载进度信息，显示将升级包中的升级文件写入到对应分区的安装进度信息，不显示第一选项；在升级包中升级文件安装完毕后，刷新第一界面，取消显示在第一界面中的安装进度信息，显示第一选项。
18.由此，通过这种用户主动搜索升级包，触发升级的方式，能够便于用户根据实际需要自行触发对操作系统的升级，满足用户需求。
19.根据第一方面，或者以上第一方面的任意一种实现方式，在电子设备重启，从第一操作系统运行到第二操作系统之后，方法还包括：在搜索到第三操作系统对应的升级包后，获取第三操作系统对应的升级包的文件列表描述信息；在第三操作系统对应的升级包的文件列表描述信息中记录了重启标记时，根据重启标记，将共享内存中存储的第一重启属性和第一重启属性值更新为第三重启属性和第三重启属性值，第三重启属性值指示电子设备需要重启。
20.根据第一方面，或者以上第一方面的任意一种实现方式，方法还包括：将第三操作系统对应的升级包中的升级文件写入对应分区后，根据第三重启属性值，刷新第一界面，显示第一选项。
21.第二方面，本技术提供了一种电子设备。该电子设备包括：存储器和处理器，存储器和处理器耦合；存储器存储有程序指令，程序指令由处理器执行时，使得所述电子设备执行第一方面或第一方面的任意可能的实现方式中的方法的指令。
22.第二方面以及第二方面的任意一种实现方式分别与第一方面以及第一方面的任意一种实现方式相对应。第二方面以及第二方面的任意一种实现方式所对应的技术效果可参见上述第一方面以及第一方面的任意一种实现方式所对应的技术效果，此处不再赘述。
23.第三方面，本技术提供了一种计算机可读介质，用于存储计算机程序，该计算机程序包括用于执行第一方面或第一方面的任意可能的实现方式中的方法的指令。
24.第三方面以及第三方面的任意一种实现方式分别与第一方面以及第一方面的任意一种实现方式相对应。第三方面以及第三方面的任意一种实现方式所对应的技术效果可参见上述第一方面以及第一方面的任意一种实现方式所对应的技术效果，此处不再赘述。
25.第四方面，本技术提供了一种计算机程序，该计算机程序包括用于执行第一方面或第一方面的任意可能的实现方式中的方法的指令。
26.第四方面以及第四方面的任意一种实现方式分别与第一方面以及第一方面的任意一种实现方式相对应。第四方面以及第四方面的任意一种实现方式所对应的技术效果可参见上述第一方面以及第一方面的任意一种实现方式所对应的技术效果，此处不再赘述。
27.第五方面，本技术提供了一种芯片，该芯片包括处理电路、收发管脚。其中，该收发
管脚、和该处理电路通过内部连接通路互相通信，该处理电路执行第一方面或第一方面的任一种可能的实现方式中的方法，以控制接收管脚接收信号，以控制发送管脚发送信号。
28.第五方面以及第五方面的任意一种实现方式分别与第一方面以及第一方面的任意一种实现方式相对应。第五方面以及第五方面的任意一种实现方式所对应的技术效果可参见上述第一方面以及第一方面的任意一种实现方式所对应的技术效果，此处不再赘述。
附图说明
29.图1为示例性示出的一种操作系统升级涉及的设备示意图；
30.图2为示例性示出的一种触发电子设备重启的界面的示意图；
31.图3为示例性示出的一种用户交互界面的示意图；
32.图4为示例性示出的一种操作系统升级重启后多任务管理界面存在异常界面的示意图；
33.图5为示例性示出的一种实现本技术实施例提供的操作系统的升级方法的电子设备的硬件结构示意图；
34.图6为示例性示出的一种实现本技术实施例提供的操作系统的升级方法的电子设备的软件架构示意图；
35.图7为示例性示出的本技术实施例提供的操作系统的升级方法涉及的功能服务的示意图；
36.图8为示例性示出的采用需要进行重启的升级方式对电子设备的操作系统升级涉及的处理环节的示意图；
37.图9为示例性示出的操作系统的升级过程中涉及的一种用户交互界面的示意图；
38.图10为示例性示出的操作系统的升级过程中涉及的又一种用户交互界面的示意图；
39.图11为示例性示出的操作系统的升级过程中涉及的又一种用户交互界面的示意图；
40.图12为示例性示出的操作系统的升级过程中涉及的又一种用户交互界面的示意图；
41.图13为示例性示出的操作系统的升级过程中涉及的又一种用户交互界面的示意图；
42.图14为示例性示出的操作系统的升级过程中涉及的又一种用户交互界面的示意图；
43.图15为示例性示出的操作系统的升级过程中涉及的又一种用户交互界面的示意图；
44.图16为示例性示出的操作系统的升级过程中涉及的又一种用户交互界面的示意图；
45.图17为示例性示出的操作系统的升级过程中涉及的又一种用户交互界面的示意图；
46.图18为示例性示出的操作系统的升级过程中涉及的又一种用户交互界面的示意图；
47.图19为示例性示出的操作系统的升级过程中涉及的又一种用户交互界面的示意图；
48.图20为示例性示出的实现操作系统的升级方法过程中涉及的各设备、功能模块之间交互的时序图；
49.图21为示例性示出的一种本技术实施例提供的操作系统的升级方法的流程示意图。
具体实施方式
50.下面将结合本技术实施例中的附图，对本技术实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例是本技术一部分实施例，而不是全部的实施例。基于本技术中的实施例，本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例，都属于本技术保护的范围。
51.本文中术语“和/或”，仅仅是一种描述关联对象的关联关系，表示可以存在三种关系，例如，a和/或b，可以表示：单独存在a，同时存在a和b，单独存在b这三种情况。
52.本技术实施例的说明书和权利要求书中的术语“第一”和“第二”等是用于区别不同的对象，而不是用于描述对象的特定顺序。例如，第一目标对象和第二目标对象等是用于区别不同的目标对象，而不是用于描述目标对象的特定顺序。
53.在本技术实施例中，“示例性的”或者“例如”等词用于表示作例子、例证或说明。本技术实施例中被描述为“示例性的”或者“例如”的任何实施例或设计方案不应被解释为比其它实施例或设计方案更优选或更具优势。确切而言，使用“示例性的”或者“例如”等词旨在以具体方式呈现相关概念。
54.在本技术实施例的描述中，除非另有说明，“多个”的含义是指两个或两个以上。例如，多个处理单元是指两个或两个以上的处理单元；多个系统是指两个或两个以上的系统。
55.参见图1，示例性示出一种操作系统升级涉及的设备的示意图。
56.如图1所示，用于对操作系统进行升级的升级包，以及记录了升级包大小、基于该升级包进行的操作系统的升级是否需要重启的重启标识等信息的文件列表描述信息(filelist.xml)可由拍包服务器提供给云端的升级包服务器，该服务器例如可以是ota服务器进行管理，而升级包服务器则会根据端侧不同电子设备，例如pc设备、平板设备、手机等发起的获取升级包的请求向电子设备发送对应的升级包和升级包对应的filelist.xml，或者由升级包服务器在接收到拍包服务器发送的升级包和升级包对应的filelist.xml后主动推送给对应的电子设备。
57.关于拍包服务器制作不同版本的升级包，以及该升级包对应的filelist.xml，并向升级包服务器推送升级包和该升级包对应的filelist.xml，以及升级包服务器向电子设备推送升级包和该升级包对应的filelist.xml的方式参见现有实现方案即可，本技术对此不作说明。
58.相应地，电子设备，如手机从升级包服务器获取到升级包和该升级包对应的filelist.xml后，电子设备中的升级引擎将读取该升级包中的升级文件，并将读取到的升级文件写入到对应的分区中，并根据filelist.xml中记录的重启标识确定本次对操作系统的升级是否需要重启。
59.相应地，若需要重启，在将升级包中的升级文件全部写入对应分区，即安装完毕后，软件更新界面中的内容可刷新为图2所示的界面10a中的内容，即会显示“立即重启”选项。
60.参见图2，示例性的，当用户点击“立即重启”选项后，手机响应于该操作行为，将退出当前的操作系统(升级前的，后续将其称为第一操作系统)，切断手机电源，然后再开启手机电源，加载升级后的操作系统(后续将其称为第二操作系统)。
61.相应地，手机重启成功后，即完成对第二操作系统的加载，以及手机中安装的应用程序涉及的功能服务的创建后，将进入用户交互界面，如图3所示的界面10b。
62.参见图3，示例性的，在实际的应用场景中，用户为了能够快速启动手机重启前访问过的应用程序(后续简称：应用)或用户交互界面，在手机重启后，可能会立马通过指定手势动作，如图3所示的手势动作，或者触发某一功能选项后，调出多任务管理界面，以从多任务管理界面中找到手机重启前访问过的应用或用户交互界面。
63.然而，目前电子设备开机后对用户交互界面的刷新，是基于开机广播中接收到针对各应用或用户交互界面中功能选项的属性值(或者说状态值)，来确定功能选项的显示和刷新的。而开机广播通常会有6s～10s的延迟，因此如果用户在手机重启后立马调出多任务管理界面，由于手机还没有接收到开机广播，因此无法获知描述升级状态的属性值。这种情况下，手机会认为对升级包安装完成后，还未触发重启，因此多任务管理界面中显示的软件更新界面中的内容仍然与触发重启前图2示出的界面10a相同，如图4所示。
64.示例性的，当多任务管理界面中显示的用户交互界面如图4所示的界面10c中包括的内容时，用户点击“软件更新”这一用户交互界面时，手机响应于该操作行为，会将该“软件更新”这一用户交互界面切回到手机前台显示，即手机的显示屏将图2示出的界面10a。
65.此外，需要说明的是，如果在切回到界面10a后，手机还未接收到开机广播，则用户再次点击“立即重启”选项，手机响应于该操作行为，依旧会触发手机进行重启，即退出第二操作系统，切断手机电源，然后再开启手机电源，重新加载第二操作系统。这样，不仅会给用户造成错觉，误以为操作系统一直没有升级成功，并且频繁重启也会增加手机的功耗，影响用户使用。
66.有鉴于此，本技术提供了一种操作系统的升级方法，通过在使用全局共享的系统属性(systemproperties)，注册一个全局共享，且永久性的重启属性(后续称为：系统重启属性)，并为该系统重启属性设置固定的属性值，如标识不需要重启的属性值“false”，进而在电子设备重启的过程中，直接读取该系统重启属性的属性值，根据该属性值刷新软件更新界面中需要显示的功能选项，从而使得多任务管理界面中显示的软件更新界面中不再显示触发电子设备进行重启的选项。
67.为了更好的理解本技术实施例提供的技术方案，在对本技术实施例的技术方案说明之前，首先结合附图对本技术实施例适用于的电子设备的硬件结构和软件架构进行说明。
68.关于本技术实施例适用于的电子设备，例如可以是手机、平板电脑、智能手表、pc设备等，此处不再一一列举，本实施例对此不作限制。为了便于说明，本实施例以手机为例进行说明。
69.参见图5，手机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等。
70.示例性的，音频模块170可以包括扬声器170a、受话器170b、麦克风170c、耳机接口170d等。
71.示例性的，传感器模块180可以包括压力传感器、陀螺仪传感器、气压传感器、磁传感器、加速度传感器、距离传感器、接近光传感器、指纹传感器、温度传感器、触摸传感器、环境光传感器、骨传导传感器等。
72.示例性的，按键190包括电源键(开机键)，音量键等。按键190可以是机械按键，也可以是触摸式按键。手机100可以接收按键输入，产生与手机100的用户设置以及功能控制有关的信号输入。
73.此外，还需要说明的是，在实际应用中，处理器110可以包括一个或多个处理单元，例如：处理器110可以包括应用处理器(application processor，ap)，调制解调处理器，图形处理器(graphics processing unit，gpu)，图像信号处理器(image signal processor，isp)，控制器，存储器，视频编解码器，数字信号处理器(digital signal processor，dsp)，基带处理器，和/或神经网络处理器(neural-network processing unit，npu)等。
74.可理解的，在具体实现中，不同的处理单元可以是独立的器件，也可以集成在一个或多个处理器中。
75.此外，在一些实现方式中，控制器可以是手机100的神经中枢和指挥中心。控制器可以根据指令操作码和时序信号，产生操作控制信号，完成取指令和执行指令的控制。
76.此外，处理器110中的存储器主要用于存储指令和数据。在一些实现方式中，处理器110中的存储器为高速缓冲存储器。
77.此外，可理解的，在实际的应用场景中，触发手机100实现各种功能应用以及数据处理的可执行程序代码是存储在内部存储器121中的，这些可执行程序代码包括指令。
78.示例性的，具体到本技术实施例提供的技术方案中，手机100的启动、操作系统的升级主要依赖于预先存储到内部存储器121中的相关指令，处理器110通过执行内部存储器121中存储的指令，从而能够使得手机100执行本技术实施例提供的操作系统的升级方法。
79.此外，需要说明的是，在具体实现中，内部存储器121可以包括只读存储器(read-only memory，rom)和随机存取存储器(random access memory，ram)。其中，只读存储器又可以划分为非ab系统、ab系统和虚拟ab系统这三种不同的分区结构。
80.可理解的，具体到实际应用中，随机存取存储器，又称作“主存”，它可随时读写，而且速度很快，通常作为操作系统或其他正在运行中的程序的临时数据存储媒介，当电源关闭时，ram不能保留数据，即随机存取存储器中通常存储的是电子设备运行时的临时数据。而只读存储器，又可以称作“非易失性存储器”，所存数据一般是装入整机前事先写好的，例如操作系统的镜像文件，以及用户使用电子设备时产生的用户数据，整机工作过程中只能读出，而不能像ram那样能够快速地、方便地加以改写，因此rom所存数据稳定，断电后所存数据也不会改变。综上所述，ram和rom相比，两者最大的区别是ram在断电以后保存在上面的数据会自动消失，而rom不会自动消失，可以长时间断电保存。
81.关于上述所说的只读存储器，例如可以是磁盘存储器件、闪存器件、通用闪存存储器(universal flash storage，ufs)等。关于上述所说的随机存取存储器，例如可以是高速随机存取存储器。
82.此外，还需要说明的是，在具体实现中，只读存储器可以包括存储程序区和存储数据区。其中，存储程序区可存储操作系统，至少一个功能所需的应用程序(比如声音播放功能，图像播放功能等)等。存储数据区可存储手机100使用过程中所创建的数据(比如音频数据，电话本等)等。
83.示例性的，关于存储程序区，例如可以是基础分区(common)、静态分区(static partition)和动态分区(super)；关于存储数据区，例如可以是用户数据分区(userdata)。
84.基于该存储结构，目前操作系统的升级过程中，手机从升级包服务器，比如ota服务器获取的升级包，会先下载到位于只读存储器的用户数据分区，在升级包下载完成后，会对升级包进行解压，然后借助随机存取存储器的内核缓存，将升级包中的升级文件写入对应的分区，比如将对应静态分区的升级文件写入静态分区，将对应动态分区(super分区)的升级文件写入到动态分区，以实现升级文件的快速读写。
85.此外，还需要说明的是，基于上述四种分区(基础分区、静态分区、动态分区和用户数据分区)的特性，对于操作系统升级中不需要升级的分区，例如基础分区和用户数据分区，不论是在非ab系统、ab系统，还是虚拟ab系统下，均采用的是单分区，而需要升级的分区则会有所不同。
86.示例性的，由于在非ab系统下进行的操作系统的升级，升级过程中手机的其他功能不能使用，手机只能停留在非ab系统的升级界面，待升级包中的升级文件全部写对应分区，即安装完毕，并且重启手机后，才可以进入用户交互界面正常使用。故而，在非ab系统下，静态分区和动态分区也采用的是单分区，这样就可以降低对存储器空间的占用，以预留更多的空间给用户数据分区。
87.示例性的，ab系统是为了让手机在进行操作系统的升级过程中，用户可以任意返回手机的主界面，或其他用户交互界面，从而不影响手机的使用。故而，在ab系统下，静态分区和动态分区采用的是双分区。示例性的，静态分区例如可以被划分为第一静态分区和第二静态分区，动态分区例如可以划分为第一动态分区和第二动态分区。虽然这种分区划分方式可以让手机在进行操作系统的升级过程中，任意返回手机的各个用户交互界面，但是会占用存储器较大的空间，使得用户数据分区可用的空间大大减小。
88.示例性的，虚拟ab系统结合了非ab系统和ab系统的优点，将存储的文件较小，即占用存储空间较小的静态分区划分为第一静态分区和第二静态分区，将存储的文件较大，即占用存储空间较大的动态分区采用单分区。
89.以只读存储器的分区结构为虚拟ab系统分区结构为例，具体到实际应用中，对于手机中只读存储器的分区部署信息可以通过表1所示的分区表进行描述。
90.表1分区表
[0091][0092]
这样，通过分区表定义每个分区的起始地址和大小，从而针对不同的硬件可以根据需要调整相应的分区大小。
[0093]
此外，需要说明的是，除了特殊预留的分区，基本上每个分区都有其对应的镜像(image)文件，镜像文件是通过软件代码编译而成，其内集成了手机启动或运行过程相关的各种功能文件和配置。没有镜像文件，手机就没法运行。一个完整的系统版本包括很多镜像，分区表镜像gpt.img、启动相关镜像(xloader.img、boot.img)、系统镜像super.img(集成了android系统核心)和用户数据镜像userdata.img(用来储存用户数据)等。
[0094]
应当理解的是，上述说明仅是为了更好地理解本实施例的技术方案而列举的示例，不作为对本实施例的唯一限制。
[0095]
也就是说，在实际应用中，分区表中记录的分区可以根据实际的业务需求来进行划分设置。
[0096]
此外，还需要说明的是，为了便于说明，下文对本技术实施例提供的操作系统的升级方法的描述，均以只读存储器的分区结构为虚拟ab系统分区结构为例。
[0097]
关于手机100的硬件结构就介绍到此，应当理解的是，图5所示手机100仅是一个范例，在具体实现中，手机100可以具有比图中所示的更多的或者更少的部件，可以组合两个或多个的部件，或者可以具有不同的部件配置。图5中所示出的各种部件可以在包括一个或多个信号处理和/或专用集成电路在内的硬件、软件、或硬件和软件的组合中实现。
[0098]
为了更好地理解图5所示手机100的软件结构，以下对手机100的软件结构进行说明。在对手机100的软件结构进行说明之前，首先对手机100的软件系统可以采用的架构进行说明。
[0099]
具体地，在实际应用中，手机100的软件系统可以采用分层架构，事件驱动架构，微核架构，微服务架构，或云架构。
[0100]
此外，可理解的，目前主流的电子设备使用的软件系统包括但不限于windows系统、android系统和ios系统。为了便于说明，本技术实施例以分层架构的android系统为例，示例性说明手机100的软件结构，然在实际应用，关于本技术实施例提供的操作系统的升级方法，同样适用于其他系统。
[0101]
参见图6，示例性示出一种能够实现本技术实施例提供的操作系统的升级方法的手机100的软件结构框图。
[0102]
如图6所示，手机100的分层架构将软件分成若干个层，每一层都有清晰的角色和分工。层与层之间通过软件接口通信。在一些实现方式中，将android系统分为四层，从上至下分别为应用程序层，应用程序框架层，安卓运行时(android runtime)和系统库，以及内核层。
[0103]
其中，应用程序层可以包括一系列应用程序包。如图6所示，应用程序包可以包括系统升级客户端(otaupdate client，ouc)、设置、蓝牙、wifi等应用程序，此处不再一一列举，本技术对此不作限制。
[0104]
示例性的，为了实现操作系统的升级，在一些实现方式中，手机可通过wifi应用接入附近区域可用的wifi网络，然后通过ouc从管理升级包的升级包服务器，比如ota服务器获取升级包，然后由升级引擎实现将升级包中的升级文件写入到对应的分区，在安装完毕后，响应于用户对重启选项的操作行为，由ouc触发手机进行重启。
[0105]
此外，为了实现操作系统的升级，在另一些实现方式中，ouc和wifi应用可以集成到设置应用中，即在设置应用中提供对应的操作入口，进而实现上述操作。
[0106]
应当理解的是，上述说明仅是为了更好的理解本实施例的技术方案而列举的示例，不作为对本实施例的唯一限制。
[0107]
其中，应用程序框架层为应用程序层的应用程序提供应用编程接口(application programming interface，api)和编程框架。在一些实现方式中，这些编程接口和编程框架可以描述为函数。如图6所示，应用程序框架层可以包括系统服务、内容提供器、资源管理器、窗口管理器等函数，此处不再一一列举，本技术对此不作限制。
[0108]
需要说明的是，资源管理器用于为应用程序提供各种资源，比如本地化字符串，图标，图片，布局文件，视频文件等，此处不再一一列举，本技术对此不作限制。
[0109]
内容提供器用来存放和获取数据，并使这些数据可以被应用程序访问。示例性的，这些数据可以包括视频，图像，音频，拨打和接听的电话，浏览历史和书签，电话簿等，此处不再一一列举，本技术对此不作限制。
[0110]
窗口管理器用于管理窗口程序。窗口管理器可以获取显示屏大小，判断是否有状态栏，锁定屏幕，截取屏幕等。
[0111]
系统服务用于实例化应用程序、组件等对应的服务。具体到本实施例中，系统服务可以实例化用于读取系统重启属性的属性服务。
[0112]
如图7所示，具体到本技术提供的实施例中，手机重启的过程中，会通过系统服务实例化出的属性服务(property service)，调用对应的接口，比如systemproperties.get()，读取存储在只读存储器中的系统全局共享文件(后续称为：属性文件(properties file))中注册的具有永久性，用户不可修改的系统重启属性对应的属性值(后续称为：系统重启属性值)，即执行步骤s101，并将读取到的内容加载到系统属性对应的共享内存中，即执行步骤s102。
[0113]
需要说明的，property service具体是运行在初始化进程(init进程)中，它会将属性文件中的所有系统属性，以及这些系统属性对应的属性值(以key-value的形式)，包括了系统重启属性和系统重启属性值加载到系统属性对应的共享内存(property_workspace)。
[0114]
继续参见图7，示例性的，在手机重启后，ouc中的属性消费单元(property consumer)将立刻从property_workspace中将系统重启属性值加载到其对应的虚拟地址空间中，进而实现对该系统重启属性值的读取，即执行步骤s103。
[0115]
通过上述描述可知，该系统重启属性值默认为“false”，即指示升级状态为不需要再进行重启。因此，手机会直接根据该系统重启属性值刷新软件更新界面中需要显示的功能选项，从而使得多任务管理界面中显示的软件更新界面中不再显示触发电子设备进行重启的选项。
[0116]
继续参见图7，示例性的，当手机重启后，再次从ota服务器获取到升级包后，在该升级包对应的filelist.xml中记录的重启标识(重启属性值)指示基于该升级包升级后，需要重启手机时，ouc中的属性设置单元(property setter)会将该重启属性值发送给属性服务，即执行步骤s104，进而由属性服务调用对应的接口，比如systemproperties.set()，将property_workspace中的系统重启属性值更新为该重启属性值，即执行步骤s105。
[0117]
继续参见图7，示例性的，property consumer定时将property_workspace中的系统重启属性值加载到其对应的虚拟地址空间中，进而实现对该系统重启属性值的读取，即执行步骤s106。
[0118]
相应地，在系统重启属性值发生变化，即指示手机需要重启时，手机会根据更新后的系统重启属性值刷新软件更新界面中需要显示的功能选项，从而使得软件更新界面中显示触发重启的选项，如显示图2所示的界面10a。
[0119]
应当理解的是，上述说明仅是为了更好的理解本实施例的技术方案而列举的示例，不作为对本实施例的唯一限制。
[0120]
其中，android runtime包括核心库和虚拟机。android runtime负责安卓系统的调度和管理。
[0121]
核心库包含两部分：一部分是java语言需要调用的功能函数，另一部分是安卓的核心库。
[0122]
应用程序层和应用程序框架层运行在虚拟机中。虚拟机将应用程序层和应用程序框架层的java文件执行为二进制文件。虚拟机用于执行对象生命周期的管理，堆栈管理，线程管理，安全和异常的管理，以及垃圾回收等功能。
[0123]
其中，系统库可以包括多个功能模块。例如：表面管理器(surface manager)，媒体库(media libraries)，三维(3d)图形处理库(例如：opengl es)，二维(2d)图形引擎(例如：
sgl)等。
[0124]
表面管理器用于对显示子系统进行管理，并且为多个应用程序提供了2d和3d图层的融合。
[0125]
媒体库支持多种常用的音频，视频格式播放和录制，以及静态图像文件等。媒体库可以支持多种音视频编码格式，例如：mpeg4，h.264，mp3，aac，amr，jpg，png等。
[0126]
三维图形处理库用于实现三维图形绘图，图像渲染，合成，和图层处理等。
[0127]
可理解的，上述所说的2d图形引擎是2d绘图的绘图引擎。
[0128]
具体到本实施例中，手机重启后，基于系统重启属性对应的属性值刷新后的用户交互界面，如软件更新界面的绘制，则需要用到2d图形引擎和/或3d图形处理库。具体地，在需要绘制的软件更新界面仅包括2d图形时，可采用2d图形引擎实现绘制。相应地，在需要绘制的软件更新界面仅包括3d图形时，可采用3d图形处理库实现绘制。相应地，在需要绘制的软件更新界面既包括2d图形，又包括3d图形时，则可分别采用2d图形引擎和3d图形处理库实现绘制。
[0129]
应当理解的是，上述说明仅是为了更好的理解本实施例的技术方案而列举的示例，不作为对本实施例的唯一限制。
[0130]
此外，可理解的，android系统中的内核层是硬件和软件之间的层。内核层至少包含显示驱动，升级引擎、wifi确定等。
[0131]
示例性的，显示驱动可以驱动显示屏显示2d图形引擎和/或3d图形处理库绘制的用户交互界面，如多任务管理界面，以及展示在多任务管理界面中的软件更新界面。
[0132]
示例性的，wifi驱动可以驱动wifi芯片接入wifi网络，进而通过wifi网络从升级包服务器，如ota服务器获取升级包。
[0133]
示例性的，升级引擎，则可以根据从ota服务器下载到本地的升级包，实现对操作系统的升级。
[0134]
应当理解的是，上述说明仅是为了更好的理解本实施例的技术方案而列举的示例，不作为对本实施例的唯一限制。
[0135]
关于手机100的软件结构就介绍到此，可以理解的是，图6示出的软件结构中的层以及各层中包含的部件，并不构成对手机100的具体限定。在本技术另一些实施例中，手机100可以包括比图示更多或更少的层，以及每个层中可以包括更多或更少的部件，本技术不作限定。
[0136]
此外，应当理解的是，对于需要进行重启的升级方式，如在线升级和冷补丁升级等，操作系统升级过程中涉及的环节可分为图8示出的搜包、下载、安装、重启。其中，搜包环节搜索到有新版本的升级包时，才会触发下载环节。
[0137]
为了更好的理解图8中示出的操作系统升级过程中涉及的各环节中的处理逻辑，以下结合图9至图19进行具体说明。
[0138]
关于搜包环节进行的处理逻辑，示例性的，在一些实现方式中，可以是用户从指定入口触发的。在另一些实现方式中，也可以是升级包服务器(后续以ota服务器为例)主动推送的。
[0139]
关于用户从指定入口触发的方式，例如可以是用户在图3所示的界面10b中点击了设置应用的图标，进而手机响应于该操作行为，启动设置应用，手机显示的用户交互界面将
从界面10b切换为设置界面，如图9所示的界面10d。
[0140]
参见图9，示例性的，界面10d中至少可包括“系统和更新”选项。当用户点击“系统和更新”选项后，手机响应于该操作行为，用户交互界面将从界面10d切换为软件更新界面。可理解的，此时切换到的软件更新界面与图2中示出的界面10a中显示内容有所差异，为了便于区分可以将从界面10d切换到的软件更新界面表示为图10所示的界面10e。
[0141]
需要说明的是，本实施例是以ouc应用提供的功能集成到设置应用的“系统和更新”选项对应的界面，这些界面中功能选项触发的操作，依旧由ouc借入实现。
[0142]
参见图10，示例性的，在界面10e中可显示手机当前的系统版本，如图10中示出的当前版本为“2.1.0”。
[0143]
继续参见图10，示例性的，界面10e中还可显示触发搜包操作的“检查更新”选项。
[0144]
相应地，当用户点击“检查更新”选项后，手机响应于该操作行为，将生成升级包搜索请求，并将该升级包搜索请求发送给ota服务器，进而使得ota服务器能够根据该升级包搜索请求(可携带当前版本)，搜索本地是否存储了新版本的升级包。
[0145]
此外，需要说明的是，为了给用户带来更好的使用体验，手机在接收到ota服务器反馈的搜包结果前，可在界面10e中显示“正在检查...”的提示信息，为了便于区分，将该过程中的软件更新界面表示为图11所示的界面10f。
[0146]
应当理解的是，上述说明仅是为了更好的理解本实施例的技术方案而列举的示例，不作为对本实施例的唯一限制。
[0147]
进一步地，当手机接收到ota服务器反馈的搜包结果后，根据搜包结果会进一步刷新软件更新界面，以便用户更加刷新后的软件更新界面进行后续操作。
[0148]
示例性的，当搜包结果指示ota服务器不存在新的升级包，即手机当前的操作系统已经是最新版本时，对软件更新界面进行刷新，取消界面10f中显示的“正在检查...”的提示消息，可在该界面中显示“已经是最新版本”的提示信息，为了便于区分，将该过程中的软件更新界面表示为图12所示的界面10g。
[0149]
应当理解的是，上述说明仅是为了更好的理解本实施例的技术方案而列举的示例，不作为对本实施例的唯一限制。
[0150]
示例性的，当搜包结果指示ota服务器存在新的升级包时，对软件更新界面进行刷新，取消界面10f中显示的“正在检查...”的提示消息，可在该界面中显示ota服务器反馈的搜到的新版本的版本号，如在当前版本为“2.1.0”的情况下，搜索到的新版本的操作系统的版本号例如可以为“2.1.1”，并提供查看该版本的详情信息的入口，为了便于区分，将该过程中的软件更新界面表示为图13所示的界面10h。
[0151]
应当理解的是，上述说明仅是为了更好的理解本实施例的技术方案而列举的示例，不作为对本实施例的唯一限制。
[0152]
参见图13，示例性的，在一些实现方式中，手机搜索到新版本的操作系统的升级包后，可自动从界面10h跳转到查看该版本的详情信息的界面，如图14中的界面10i。在另一些实现方式中，也可由用户手动点击界面10h中提供的查看该版本的详情信息的入口，如界10h中新版本“2.1.1”所在的选项框，或者该选项对应的入口“》”，进而手机响应于该操作行为，从界面10h跳转到图14所示的界面10i。
[0153]
应当理解的是，上述说明仅是为了更好的理解本实施例的技术方案而列举的示
例，不作为对本实施例的唯一限制。
[0154]
参见图14，示例性的，在界面10i中可显示当前作业的系统版本，如“2.1.0”，以及该新版本的系统版本，如“2.1.1”，以及该新版本的大小，如“41.23mb”，以及描述该新版本的操作系统的更新日志内容，如“本次更新优化部分场景拍照效果，通信体验，通话音频效果，优化系统性能和稳定性，推荐您进行更新”，以及供用户操作的“下载并安装”选项。
[0155]
应当理解的是，上述说明仅是为了更好的理解本实施例的技术方案而列举的示例，不作为对本实施例的唯一限制。
[0156]
继续参见图14，示例性的，当用户点击“下载并安装”选项后，手机响应于该操作行为，将从界面10i跳转到图15示出的界面10j，并生成升级包获取请求，将该升级包获取请求发送给ota服务器，进而使得ota服务器能够根据该升级包获取请求(可携带要获取的新版本的版本号等信息)，将对应的升级包和该升级包对应的filelist.xml发送给手机。
[0157]
需要说明的是，为了给用户带来更好的使用体验，手机在从ota服务器下载新版本的升级包和该升级包对应的filelist.xml的过程中，可在界面10j中显示“下载中...”的提示信息，并显示具体的下载进度，如界面10j中示出的70％。
[0158]
应当理解的是，上述说明仅是为了更好的理解本实施例的技术方案而列举的示例，不作为对本实施例的唯一限制。
[0159]
进一步地，当手机从ota服务器下载完毕新版本的升级包和升级包对应的filelist.xml后，将自动触发安装操作，具体为ouc通知升级引擎根据下载的升级包和filelist.xml进行安装，而用户交互界面则会从界面10j刷新为图16中的界面10k。
[0160]
需要说明的是，为了给用户带来更好的使用体验，手机在安装过程中，可在界面10k中显示“安装中...”的提示信息，并显示具体的安装进度，如界面10k中示出的70％。
[0161]
应当理解的是，上述说明仅是为了更好的理解本实施例的技术方案而列举的示例，不作为对本实施例的唯一限制。
[0162]
进一步地，当将升级包中的升级文件全部写入对应的分区，即安装完毕后，手机将对当前的界面，如界面10k进行刷新，进而将界面10k中显示的内容刷新为如图2所示的界面10a中显示的内容，即显示“安装完毕”的提示信息和“100％”的安装进度，以及供用户操作，触发手机重启的“立即重启”选项。
[0163]
应当理解的是，上述说明仅是为了更好的理解本实施例的技术方案而列举的示例，不作为对本实施例的唯一限制。
[0164]
关于ota服务器在接收到拍包服务器提供的新版本的操作系统对应的升级包和filelist.xml后，主动向手机推送存在新版本的升级包和filelist.xml信息的方式，例如可以是用户预先从设置界面中提供的相关功能入口开启了自动升级功能，这样ota服务器接收到该设置指令后，就会在接收到拍包服务器提供的新版本的操作系统对应的升级包和filelist.xml后，主动告知手机当前存在新版本的升级包。
[0165]
示例性的，在另一些实现方式中，手机在开启自动升级功能后，ouc也可以周期性的自动生成升级包搜索请求，进而请求ota服务器进行搜包。相应地，ota服务器搜索到新版本的升级包后，便会告知手机当前存在新版本的升级包。
[0166]
示例性的，手机接收到ota服务器告知的当前存在新版本的升级包的信息后，可以在当前的用户交互界面，比如某一应用对应的使用界面，或者主界面，如图17示出的界面
10b上弹出提示窗口10b-1。
[0167]
参见图17，示例性的，提示窗口10b-1中可以显示针对该新版本的升级包优化的描述信息，如图17中示出的“包含重要系统优化，建议您立即升级体验”，以提醒用户下载新版本的升级包，进而触发对当前操作系统的升级操作。
[0168]
继续参见图17，示例性的，提示窗口10b-1中还可包括多个功能选项，如“稍后”选项、“详细信息”选项、“下载并安装”选项。
[0169]
其中，“稍后”选项被触发时，手机响应于对该选项的触发操作，将关闭显示在界面10b上的提示窗口10b-1，在一段时间后再次弹出该提示窗口10b-1，以供用户选择是否下载并安装新版本的升级包，以将第一升级系统升级到第二操作系统。
[0170]
此外，可理解的，在一些实现方式中，当“稍后”选项被触发时，手机响应于对该选项的触发操作，关闭显示在界面10b上的提示窗口10b-1后，还可以在界面10b上弹出稍后提示的时间选择，或者稍后自动触发自动下载并安装的时间。
[0171]
应当理解的是，上述说明仅是为了更好的理解本技术实施例提供的操作系统的升级方法而列举的示例，不作为对本实施例的唯一限制。
[0172]
其中，“详细信息”选项被触发时，手机响应于对该选项的触发操作，将跳转到描述该版本的界面，如图14示出的界面10i，或者在界面10b上弹出类似界面10i中的“更新日志”窗口，并在该窗口中显示该版本的优化功能，以及该版本的版本号，大小等信息。
[0173]
此外，需要说明的是，在一些实现方式中，在ota服务器中存在新版本的升级包时，ota服务器向手机反馈搜包结果，或者主动告知手机当前存在新版本的升级包时，可以将该升级包对应的filelist.xml先推送给手机，以便手机从filelist.xml中解析出该升级包的大小、版本号、优化功能的描述信息，进而显示到“详细信息”选项对应的界面或窗口中。
[0174]
应当理解的是，上述说明仅是为了更好的理解本技术实施例提供的操作系统的升级方法而列举的示例，不作为对本实施例的唯一限制。
[0175]
其中，“下载并安装”选项被触发时，手机响应于对该选项的触发操作，将生成升级包获取请求，并向ota服务器发送给升级包获取请求，进而从ota服务器获取新版本的升级包和对应的filelist.xml，并关闭掉显示在界面10b上的提示窗口10b-1，从界面10b跳转到如图15所示的界面10j。
[0176]
相应地，当手机从ota服务器下载完毕新版本的升级包和升级包对应的filelist.xml后，将自动触发安装操作，具体为ouc通知升级引擎根据下载的升级包和filelist.xml进行安装，而用户交互界面则会从界面10j刷新为图16中的界面10k。
[0177]
相应地，当将升级包中的升级文件全部写入对应的分区，即安装完毕后，手机将对当前的界面，如界面10k进行刷新，进而将界面10k中显示的内容刷新为如图2所示的界面10a中显示的内容，即显示“安装完毕”的提示信息和“100％”的安装进度，以及供用户操作，触发手机重启的“立即重启”选项。
[0178]
应当理解的是，上述说明仅是为了更好的理解本技术实施例提供的操作系统的升级方法而列举的示例，不作为对本实施例的唯一限制。
[0179]
示例性的，不论哪种搜包方式，在从ota服务器获取到新版本的升级包和对应的filelist.xml安装完毕，当用户点击界面10a中提供的“立即重启”选项后，ouc都会触发整机重启，具体可以是通知内核实现断电，然后再重新上电，进而加载初始化进程，以及实例
化各种系统服务，和应用涉及的服务等。
[0180]
通过上述对实现本技术实施例提供的操作系统的升级方法的手机的软件架构的描述可知，在手机重启的过程中，系统服务会实例化出属性服务，并将其运行到加载的初始化进程中。
[0181]
相应地，属性服务会基于图7示出的步骤s101至步骤s103，刷新ouc涉及的软件更新界面，如安装完毕后触发“立即重启”选项的界面10a中的内容。
[0182]
可理解的，由于读取的系统重启属性值为“false”，即指示不需要重启，因此界面10a中的“立即重启”选项将更新为“检测更新”选项，而显示的当前操作系统的版本，则会更新为升级后的操作系统的版本，如“2.1.1”，并且该界面中显示的当前版本对应的版本信息也会变更为“2.1.1”，为了便于区分，将刷新后的界面表示为图18所示的界面10l。
[0183]
此外，可理解的，由于手机重启后，通常进入的是主界面，如图3所示的界面10b。因此，当用户在界面10b通过指定手势，如图3中示出的手势，或者触发某一功能选项后，调出多任务管理界面，以从多任务管理界面中找到手机重启前访问过的应用或用户交互界面。
[0184]
基于本技术实施例提供的操作系统的升级方法，由于重启过程中直接基于全局共享的系统重启属性值来刷新界面10a中的内容，并将其刷新为了界面10l。因此，在未接收到开机广播前，用户调出了多任务管理界面后，多任务管理界面中显示的“软件更新”这一用户交互界面，实质是界面10l的缩略图而非界面10a的缩略图，具体如图19示出的界面10m这一多任务管理界面。
[0185]
相应地，当用户点击界面10m中的“软件更新”这一用户交互界面时，手机响应于该操作行为，会将该“软件更新”这一用户交互界面切回到手机前台显示，即手机的显示屏将图18示出的界面10l。
[0186]
相应地，当用户点击界面10l中的“检查更新”选项后，由于当前的操作系统已经是最新的操作系统，故而不会搜索到新版本的升级包，因此界面10m中可显示“已经是最新版本”的提示信息。
[0187]
相应地，如果再次搜索到新版本的升级包，则会重新执行上述处理逻辑。
[0188]
应当理解的是，上述说明仅是为了更好的理解本技术实施例提供的操作系统的升级方法而列举的示例，不作为对本实施例的唯一限制。
[0189]
为了更好的理解基于本技术实施例提供的操作系统的升级方法，实现图8所示的4个环节时，具体涉及的ota服务器、电子设备如手机中的ouc、升级引擎、属性服务、内核等执行的具体处理逻辑，以下结合图20对本技术实施例提供的操作系统的升级方法进行具体说明。
[0190]
参见图20，示例性示出电子设备中的ouc主动从升级包服务器，如ota服务器获取需要进行重启的升级包，并根据给升级包进行安装、重启的流程示意图。
[0191]
示例性的，假设电子设备的只读存储器的分区结构为上述所说的虚拟ab系统分区结构。电子设备在开机启动时，依次加载基础分区的数据、第一静态分区的数据以及动态分区的数据，从第一静态分区启动，以运行第一操作系统，即升级前的操作系统，如图10中示出的系统版本“2.1.0”为例。具体地，电子设备启动，运行到第一操作系统后，在用户预先开启了自动升级功能的情况下，ouc将周期性执行搜包环节的处理逻辑，如生成升级包搜索请求，并将该升级包搜索请求发送给ota服务器，即执行图20中的步骤s201。
[0192]
可理解的，ouc生成的升级包搜索请求中可携带第一操作系统的版本号等信息，以便ota服务器能够查询针对第一操作系统进行更新迭代后的操作系统。
[0193]
继续参见图20，示例性的，ota服务器接收到电子设备发送的升级包搜索请求后，会在本地数据库中查询新版本的升级包，即针对第一操作系统进行更新迭代后的操作系统，即执行步骤s202。
[0194]
相应地，若ota服务器中存在新版本的升级包，ota服务器将向电子设备反馈信标的升级包对应的filelist.xml的下载地址，即执行步骤s203，以便手机根据filelist.xml中针对该新版本的升级包的详细信息，绘制对应的用户交互界面，供用户查看选择是否对操作系统进行升级。反之，若没有查询到新版本的升级包，则向电子设备反馈当前没有新的升级包。本实施例以ota服务器中存在新版本的升级包，即ota服务器执行步骤s203为例。
[0195]
继续参见图20，示例性的，电子设备接收到ota服务器反馈的filelist.xml的下载地址，ouc将从该下载地址下载filelist.xml到用户数据分区，即执行步骤s204。
[0196]
示例性的，在一些实现方式中，ouc可以根据filelist.xml中记录的信息，例如升级包的地址信息，从ota服务器获取升级包。故而，在ouc将filelist.xml下载后用户数据分区后，ouc可以根据filelist.xml中记录的升级包的地址信息，获取升级包，即执行步骤s205。
[0197]
继续参见图20，示例性的，电子设备从升级包对应的下载地址下载升级包时，ouc会将下载到的升级包存入用户数据分区，即执行步骤s206。
[0198]
通过上述描述可知，操作系统的升级是由升级引擎(update_engine)主导完成的。故而，ouc在从ota服务器下载到升级包后，会向升级引擎下发升级指令，即执行步骤s207，以触发升级引擎开始执行升级流程，即上述所说的安装环节的操作。
[0199]
此外，需要说明的是，为了保证升级成功，ouc在下载完升级包后，可以先对升级包进行校验，比如根据filelist.xml中记录的升级包的大小，对下载的升级包进行完整性校验。
[0200]
相应地，在校验成功后，再向升级引擎发送升级指令。
[0201]
应当理解的是，上述说明仅是为了更好的理解本技术实施例提供的操作系统的升级方法而列举的示例，不作为对本实施例的唯一限制。对升级包的校验，也可交由升级引擎进行校验，本技术对此不作限制。
[0202]
继续参见图20，示例性的，升级引擎在接收到升级指令后，执行的升级流程，具体是从用户数据分区中读取升级包的升级文件，并将升级文件写入到对应的分区，即执行步骤s208。
[0203]
示例性的，在电子设备当前是加载的第一静态分区的数据启动的情况下，本次升级操作，升级引擎可将对应静态分区的升级文件写入到第二静态分区。而对于动态分区，由于虚拟ab系统分区结构，动态分区是单分区，因此为了不影响升级过程中，用户对电子设备的视野，可以通过在用户数据分区创建对应动态分区中各子分区的写时拷贝(copy-on-write，cow)文件，进而将对应动态分区中这些子分区的升级文件写入到用户数据分区中创建的对应cow文件中，从而实现对升级包中升级文件的安装。
[0204]
继续参见图20，示例性的，升级引擎对升级包中升级文件安装完毕后，将告知ouc安装完毕，即执行步骤s209，以使ouc能够在filelist.xml中记录的本次升级为需要进行重
启的升级时，根据该重启标识(重启属性值)，刷新对应的用户交互界面，在该界面中显示触发重启的选项入口，即执行步骤s210.
[0205]
相应地，在显示触发重启的选项入口后，若监听到用户对该选项入口的点击，电子设备响应于该操作行为，将触发重启，即执行步骤s211。
[0206]
需要说明的是，升级引擎告知ouc安装完毕前，需要对写入对应分区的升级文件进行校验。
[0207]
示例性的，在一些实现方式中，可以是将静态分区对应的升级文件写入对应的静态分区的子分区，将动态分区对应的升级文件写入用户数据分区对应的cow文件后，触发校验流程，依次对写入第二静态分区的升级文件和写入用户数据分区对应的cow文件的升级文件进行校验。
[0208]
相应地，在对写入第二静态分区中各子分区的升级文件，以及写入用户数据分区对应的各cow文件的升级文件均校验成功后，升级引擎便可以执行步骤s209。
[0209]
示例性的，在另一些实现方式中，为了加快升级速度，也可以在将静态分区对应的升级文件写入第二静态分区对应的子分区后，启动一个与升级引擎并行的进程，由该进程在升级引擎将动态分区对应的升级文件写入各cow文件的过程中，对已经写入第二静态分区中子分区的升级文件进行校验，从而实现对静态分区中升级文件的校验和将动态分区对应的升级文件写入对应cow文件的过程能够并行执行，进而缩短安装时间。
[0210]
相应地，在对写入第二静态分区中各子分区的升级文件，以及写入用户数据分区对应的各cow文件的升级文件均校验成功后，升级引擎便可以执行步骤s209。
[0211]
应当理解的是，上述说明仅是为了更好的理解本技术实施例提供的操作系统的升级方法而列举的示例，不作为对本实施例的唯一限制。
[0212]
继续参见图20，示例性的，电子设备响应于重启指令，内核将控制电子设备断电，并在断电后重新上电，触发电子设备重启，并在重启过程中加载初始化进程，即执行步骤s212。
[0213]
需要说明的是，由于电子设备重启是从第一静态分区启动，运行到第一操作系统的，故而在升级引擎安装完毕后，电子设备重启时，会依次加载基础分区的数据、第二静态分区的数据、动态分区的数据，以及用户数据分区中cow文件中的数据，从第二静态分区启动，以运行到升级后的操作系统，即第二操作系统。
[0214]
通过上述实施例的描述可知，在本实施例提供的操作系统的升级方法中，电子设备重启的过程中，系统服务会实例化出属性服务，并将属性服务运行到初始化进程中，即执行步骤s213。
[0215]
此外，基于图7中示出的步骤s101至步骤s103，本实施例提供的操作系统的升级方法，将不再依赖开机广播，而是直接通过属性服务从全局共享的属性文件中读取预先注册的系统重启属性和系统重启属性值(该值默认为“false”)，并将读取到的系统重启属性和系统重启属性值以键值对的形式写入对应的共享内容，即执行步骤s214，以便ouc在电子设备重启的过程中，能够直接根据共享内存中的系统重启属性值“false”，属性对应的用户交互界面，不显示触发重启的选项入口，即执行步骤s215。结合上述实施例示出的用户交互界面，例如是将图2中的界面10a刷新为图18中的界面10l，不显示“立即重启”选项，而是显示“检查更新”选项。由此，在电子设备重启后，便会直接进入到刷新后的用户交互界面。这样，
即便用户在电子设备重启后，立马调出多任务管理界面，多任务管理界面中也不会再显示图2示出的界面10a，而是会显示图18示出的界面10l，从而保证用户使用体验。
[0216]
应当理解的是，上述说明仅是为了更好的理解本技术实施例提供的操作系统的升级方法而列举的示例，不作为对本实施例的唯一限制。
[0217]
此外，在电子设备重启，进入刷新后的用户交互界面后，内核将执行merge操作。可理解的，所谓merge操作，具体是指在操作系统升级过程中，将用户数据分区中各cow文件保存的动态分区对应的升级文件，写入到动态分区中，使得动态分区的文件完成数据升级，以便电子设备在下次启动时不需要加载动态分区和用户数据分区的cow文件中的数据，只需加载动态分区中的数据就可以完成电子设备启动。
[0218]
相应地，在完成merge操作后，本次对操作系统的升级便正式结束。后续，若再搜索到新的升级包，便会重新按照上述处理流程实现对操作系统的升级。可理解的，在该过程中，会将新版本的升级包对应的filelist.xml中记录的重启标识通过属性服务写入共享内容，即按照图7中步骤s104和步骤s105的处理逻辑执行。
[0219]
相应地，在该重启标识指示该升级包是冷补丁升级包或ota升级包，即基于该新版本的升级包进行的升级需要进行重启，则在将新版本的升级包中的升级文件安装完毕后，ouc将会再次触发重启。相应地，若不需要重启，则在将新版本的升级包中的升级文件安装完毕后，ouc将根据该不需要重启的重启标识刷新用户交互界面。具体可以参见图7中的步骤s106的处理逻辑执行。
[0220]
应当理解的是，上述说明仅是为了更好的理解本技术实施例提供的操作系统的升级方法而列举的示例，不作为对本实施例的唯一限制。在实际应用中，基于本技术实施例提供的操作系统的升级方法进行的升级过程，主要关注升级包安装完毕，电子设备重启后，用户交互界面，如软件更新界面的刷新绘制部分。针对此部分的具体处理逻辑可参见图21示出的操作系统的升级方法的流程示意图。
[0221]
参见图21，本实施例提供的操作系统的升级方法，具体包括：
[0222]
s301，显示第一界面，第一界面显示了触发电子设备重启的第一选项。
[0223]
示例性的，此时显示的第一界面例如为上述实施例中所说的界面10a，即电子设备已经将从ota服务器获取到的新版本操作系统对应的升级包中的升级文件写入到了对应的分区，如上述所说的在只读存储器的分区结构为上述所说的虚拟ab系统分区结构，电子设备当前是从第一静态分区启动，运行在第一操作系统中的情况下，电子设备对升级包中升级文件的处理，例如为将静态分区对应的升级文件写入到第二静态分区，将动态分区对应的升级文件先写入到用户数据分区中创建的对应cow文件中。
[0224]
相应地，在此时显示的界面为上述实施例中所说的界面10a时，第一选项例如为界面10a中显示的“立即重启”选项。
[0225]
此外，通过上述实施例的描述可知，界面10a的显示前提例如可以是根据上述搜包环节中给出的ota服务器主动告知电子设备存在新的升级包的方式。具体地，基于这种方式，电子设备将根据接收到的存在新的升级包的信息在第二界面中弹出第一提示窗口，并在该第一提示窗口中显示触发电子设备获取升级包，并基于升级包对操作系统进行升级的第三选项。
[0226]
示例性的，在本实施例中，第二界面例如为上述实施例中示出的界面10b。相应地，
第一提示窗口，例如为界面10b中弹出的提示窗口10b-1。相应地，第三选项例如为提示窗口10b-1中显示的“下载并安装”选项。
[0227]
相应地，当用户点击第三选项后，电子设备响应于对第三选项的点击操作，获取升级包，并显示第一界面。需要说明的，此时的第一界面可显示升级包的下载进度信息，但不显示第一选项。示例性的，此时的第一界面可以看作是上述实施例中所说的界面10j。
[0228]
可理解的，关于升级包的获取，例如可以是先获取升级包对应的文件列表描述信息(filelist.xml)。其中，文件列表描述信息记录了升级包的下载地址和重启标记，重启标记用于指示基于升级包对操作系统的升级涉及重启环节。
[0229]
相应地，在获取到filelist.xml后，电子设备便可以从filelist.xml中记录的下载地址获取升级包到电子设备的用户数据分区。然后，根据重启标记，将共享内存中存储的第一重启属性和第一重启属性值更新为第二重启属性和第二重启属性值，第二重启属性值指示电子设备需要重启。
[0230]
关于电子设备将共享内存中存储的第一重启属性和第一重启属性值更新为第二重启属性和第二重启属性值的具体实现细节，可以参见上述实施例中的步骤s104和步骤s105，此处不再赘述。
[0231]
相应地，在升级包下载成功后，电子设备会将升级包中的升级文件写入到对应分区，具体可以是对用户数据分区中的升级包进行解析，得到升级包中的升级文件；将对应静态分区的升级文件写入静态分区，将对应动态分区的升级文件写入动态分区。
[0232]
此外，还需要说明的是，在将升级包中的升级文件写入到对应分区的过程中，电子设备将刷新第一界面。具体为取消显示在第一界面中的下载进度信息，显示将升级包中的升级文件写入到对应分区的安装进度信息，不显示第一选项。示例性的，刷新后的第一界面可以看作是上述实施例中所说的界面10k。
[0233]
相应地，在升级包中升级文件安装完毕后，电子设备将再一次刷新第一界面。具体为取消显示在第一界面中的安装进度信息，显示第一选项。示例性的，刷新后的第一界面可以看作是上述实施例中所说的界面10a。具体的实现细节可以参见上述实施例的步骤s106，以及上述实施例的步骤s215，此处不再赘述。
[0234]
通过上述实施例的描述可知，升级包中指示电子设备需要重启的重启标识，将会写入到对应的共享内容，替换共享内存中原本存储的第一重启属性和第一重启属性值(指示电子设备无须重启)，如将这两个参数表示为第二重启属性和第二重启属性值(指示电子设备要重启)。这样，电子设备在执行完下载环节和安装环节的处理逻辑后，便会从共享内存获取第二重启属性对应的第二重启属性值，根据第二重启属性值，刷新第一界面，取消显示在第一界面中的安装进度信息，显示第一选项。
[0235]
示例性的，本实施例中所说的第一重启属性例如为上述实施例中预先注册存储在属性文件的系统重启属性。相应地，第一重启属性值，即为上述实施例中所说的系统重启属性值。
[0236]
示例性的，第二重启属性、第二重启属性值，以及下文出现的第三重启属性，以及第三重启属性值，即为根据从ota服务器获取到的新的升级包对应的filelist.xml中记录指示电子设备要重启的重启标记，对共享内存中的第一重启属性和第一重启属性值更新后的重启属性和重启属性值。
[0237]
此外，通过上述实施例的描述可知，界面10a的显示前提还例如可以是根据上述搜包环节中给出的用户手动触发搜包，进而实现对操作系统的升级的方式。仍以第二界面上述实施例中所说的界面10b，且第二界面中包括了第一应用，第一应用集成了启动第一界面入口。
[0238]
示例性的，第一应用例如为界面10a中示出的设置应用，或ouc应用。为了便于说明，以第一应用为设置应用为例，则上述所说的启动第一界面入口例如为上述实施例中所说的界面10d中显示的“系统和更新”选项。
[0239]
具体地，基于这种用户手动触发的方式，当用户点击第一应用中启动第一界面入口时，电子设备响应于该操作行为，将显示第一界面。可理解的，此时显示的第一界面中显示了第二选项，不显示第一选项。示例性的，刷新后的第一界面可以看作是上述实施例中所说的界面10e。
[0240]
相应地，当用户点击了第二选项后，电子设备响应于该操作行为，将搜索升级包。具体可以参见上述实施例中步骤s201至步骤s203的描述，此处不再赘述。
[0241]
相应地，在搜索到存在升级包时，电子设备将刷新第一界面。具体为取消显示在第一界面中的第二选项，显示触发电子设备获取升级包，并基于升级包对操作系统进行升级的第四选项。示例性的，刷新后的第一界面可以看作是上述实施例中所说的界面10i，第四选项则可以为界面10i中示出的“下载并安装”选项。
[0242]
相应地，当用户点击了第四选项后，电子设备响应于该操作行为，将获取升级包，并显示第一界面，第一界面显示了升级包的下载进度信息，不显示第一选项。示例性的，此时的第一界面可以看作是上述实施例中所说的界面10j。
[0243]
相应地，在升级包下载成功后，电子设备会将升级包中的升级文件写入到对应分区。同时，在将升级包中的升级文件写入到对应分区的过程中，电子设备还会刷新第一界面，取消显示在第一界面中的下载进度信息，显示将升级包中的升级文件写入到对应分区的安装进度信息，不显示第一选项。示例性的，刷新后的第一界面可以看作是上述实施例中所说的界面10k。
[0244]
相应地，在升级包中升级文件安装完毕后，电子设备将再一次刷新第一界面，取消显示在第一界面中的安装进度信息，显示第一选项。示例性的，刷新后的第一界面可以看作是上述实施例中所说的界面10a。
[0245]
关于电子设备获取filelist.xml、升级包，以及将升级包中的升级文件写入对应分区、刷新第一界面显示第一选项的具体实现细节，可以参见上述实施例中的步骤s201至步骤s210。
[0246]
s302，响应于对第一选项的点击操作，触发电子设备重启，以从升级前的第一操作系统运行到升级后的第二操作系统。
[0247]
关于用户点击第一选项，电子设备触发重启的具体实现逻辑，可以参见上述实施例中步骤s211和步骤s213，此处不再赘述。
[0248]
s303，在电子设备重启的过程中，获取属性文件中设置的第一重启属性值。
[0249]
具体地，在电子设备重启的过程中，可从属性文件中读取第一重启属性和第一重启属性值，并将第一重启属性和第一重启属性值以键值对的形式，写入共享内存。关于该过程的实现细节，可以参见上述实施例中的步骤s101和步骤s102，以及上述实施例中的步骤
s214，此处不再赘述。
[0250]
此外，本实施例中所说的属性文件为存储在只读存储器中的全局共享文件。第一重启属性值为固定值，用于指示所述电子设备无须重启，例如默认为“false”。
[0251]
s304，根据第一重启属性值，刷新第一界面，取消显示在第一界面中的第一选项，显示触发电子设备搜索升级包的第二选项。
[0252]
具体地，电子设备将从共享内存获取第一重启属性对应的第一重启属性值，根据第一重启属性值，刷新第一界面，取消显示在第一界面中的第一选项，显示触发电子设备搜索升级包的第二选项。关于该过程的实现细节，可以参见上述实施例中的步骤s103，此处不再赘述，以及上述实施例中的步骤s215，此处不再赘述。
[0253]
此外，在电子设备重启，从第一操作系统运行到第二操作系统之后，若用户通过上述自动搜包的方式，或者电子设备开启了自动升级功能，获知或者说搜索到第三操作系统对应的升级包，即针对第二操作系统做出更新迭代后的操作系统的升级包，电子设备可按照上述获取第二操作系统对应的升级包的方式，先获取第三操作系统对应的升级包的文件列表描述信息。
[0254]
相应地，在第三操作系统对应的升级包的文件列表描述信息中记录了重启标记时，根据重启标记，将共享内存中存储的第一重启属性和第一重启属性值更新为第三重启属性和第三重启属性值，第三重启属性值指示电子设备需要重启。具体可以参见上述实施例中的步骤s104和步骤s105，此处不再赘述。
[0255]
相应地，电子设备在将第三操作系统对应的升级包中的升级文件写入对应分区后，将根据第三重启属性值，刷新第一界面，显示第一选项。具体可以参见上述实施例中的步骤s106，以及上述实施例中的步骤s215，此处不再赘述。
[0256]
由此，通过在使用全局共享的系统属性(systemproperties)，注册一个全局共享，且永久性的重启属性，如上文所说的系统重启属性，并为该系统重启属性设置固定的属性值，如标识不需要重启的属性值“false”，进而在电子设备重启的过程中，直接读取该系统重启属性的属性值，根据该属性值刷新软件更新界面中需要显示的功能选项，从而使得多任务管理界面中显示的软件更新界面中不再显示触发电子设备进行重启的选项，进而给用户带来了更好地使用体验。
[0257]
此外，需要说明的是，电子设备为了实现上述功能，其包含了执行各个功能相应的硬件和/或软件模块。结合本文中所公开的实施例描述的各示例的算法步骤，本技术能够以硬件或硬件和计算机软件的结合形式来实现。某个功能究竟以硬件还是计算机软件驱动硬件的方式来执行，取决于技术方案的特定应用和设计约束条件。本领域技术人员可以结合实施例对每个特定的应用来使用不同方法来实现所描述的功能，但是这种实现不应认为超出本技术的范围。
[0258]
此外，还需要说明的是，在实际的应用场景中由电子设备实现的上述各实施例提供的操作系统的升级方法，也可以由电子设备中包括的一种芯片系统来执行，其中，该芯片系统可以包括处理器。该芯片系统可以与存储器耦合，使得该芯片系统运行时调用该存储器中存储的计算机程序，实现上述电子设备执行的步骤。其中，该芯片系统中的处理器可以是应用处理器也可以是非应用处理器的处理器。
[0259]
另外，本技术实施例还提供一种计算机可读存储介质，该计算机存储介质中存储
有计算机指令，当该计算机指令在电子设备上运行时，使得电子设备执行上述相关方法步骤实现上述实施例中的操作系统的升级方法。
[0260]
另外，本技术实施例还提供了一种计算机程序产品，当该计算机程序产品在电子设备上运行时，使得电子设备执行上述相关步骤，以实现上述实施例中的操作系统的升级方法。
[0261]
另外，本技术的实施例还提供一种芯片(也可以是组件或模块)，该芯片可包括一个或多个处理电路和一个或多个收发管脚；其中，所述收发管脚和所述处理电路通过内部连接通路互相通信，所述处理电路执行上述相关方法步骤实现上述实施例中的操作系统的升级方法，以控制接收管脚接收信号，以控制发送管脚发送信号。
[0262]
此外，通过上述描述可知，本技术实施例提供的电子设备、计算机可读存储介质、计算机程序产品或芯片均用于执行上文所提供的对应的方法，因此，其所能达到的有益效果可参考上文所提供的对应的方法中的有益效果，此处不再赘述。
[0263]
以上所述，以上实施例仅用以说明本技术的技术方案，而非对其限制；尽管参照前述实施例对本技术进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分技术特征进行等同替换；而这些修改或者替换，并不使相应技术方案的本质脱离本技术各实施例技术方案的范围。

技术特征：
1.一种操作系统的升级方法，其特征在于，应用于电子设备，所述方法包括：显示第一界面，所述第一界面显示了触发所述电子设备重启的第一选项；响应于对所述第一选项的点击操作，触发所述电子设备重启，以从升级前的第一操作系统运行到升级后的第二操作系统；在所述电子设备重启的过程中，获取所述属性文件中设置的第一重启属性值；其中，所述属性文件为存储在只读存储器中的全局共享文件；所述第一重启属性值为固定值，用于指示所述电子设备无须重启；根据所述第一重启属性值，刷新所述第一界面，取消显示在所述第一界面中的所述第一选项，显示触发所述电子设备搜索升级包的第二选项。2.根据权利要求1所述的方法，其特征在于，所述在所述电子设备重启的过程中，获取所述属性文件中设置的第一重启属性值，包括：在所述电子设备重启的过程中，从所述属性文件中读取第一重启属性和所述第一重启属性值；将所述第一重启属性和所述第一重启属性值以键值对的形式，写入共享内存。3.根据权利要求2所述的方法，其特征在于，所述根据所述第一重启属性值，刷新所述第一界面，取消显示在所述第一界面中的所述第一选项，显示触发所述电子设备搜索升级包的第二选项，包括：从所述共享内存获取所述第一重启属性对应的所述第一重启属性值，根据所述第一重启属性值，刷新所述第一界面，取消显示在所述第一界面中的所述第一选项，显示触发所述电子设备搜索升级包的第二选项。4.根据权利要求2或3所述的方法，其特征在于，所述显示第一界面，所述第一界面显示了触发所述电子设备重启的第一选项，包括：显示第二界面，所述第二界面中包括第一提示窗口，所述第一提示窗口中显示了触发所述电子设备获取升级包，并基于所述升级包对操作系统进行升级的第三选项；响应于对所述第三选项的点击操作，获取所述升级包，并显示所述第一界面，所述第一界面显示了所述升级包的下载进度信息，不显示所述第一选项；在所述升级包下载成功后，将所述升级包中的升级文件写入到对应分区；在将所述升级包中的升级文件写入到对应分区的过程中，刷新所述第一界面，取消显示在所述第一界面中的下载进度信息，显示将所述升级包中的升级文件写入到对应分区的安装进度信息，不显示所述第一选项；在所述升级包中升级文件安装完毕后，刷新所述第一界面，取消显示在所述第一界面中的安装进度信息，显示所述第一选项。5.根据权利要求4所述的方法，其特征在于，所述获取升级包，包括：获取所述升级包对应的文件列表描述信息，所述文件列表描述信息记录了所述升级包的下载地址和重启标记，所述重启标记用于指示基于所述升级包对操作系统的升级涉及重启环节；从所述下载地址获取所述升级包到所述电子设备的用户数据分区；根据所述重启标记，将所述共享内存中存储的所述第一重启属性和所述第一重启属性值更新为第二重启属性和第二重启属性值，所述第二重启属性值指示所述电子设备需要重
启。6.根据权利要求5所述的方法，其特征在于，所述在所述升级包中升级文件安装完毕后，刷新所述第一界面，取消显示在所述第一界面中的安装进度信息，显示所述第一选项，包括：所述升级包中升级文件安装完毕后，从所述共享内存获取所述第二重启属性对应的所述第二重启属性值，根据所述第二重启属性值，刷新所述第一界面，取消显示在所述第一界面中的安装进度信息，显示所述第一选项。7.根据权利要求5所述的方法，其特征在于，所述将所述升级包中的升级文件写入到对应分区，包括：对所述用户数据分区中的所述升级包进行解析，得到所述升级包中的升级文件；将对应静态分区的升级文件写入所述静态分区，将对应动态分区的升级文件写入所述动态分区。8.根据权利要求2或3所述的方法，其特征在于，所述显示第一界面，所述第一界面显示了触发所述电子设备重启的第一选项，包括：显示第二界面，所述第二界面中包括第一应用，所述第一应用集成了启动所述第一界面入口；其中，在未获取所述升级包前，从所述第一应用启动的所述第一界面中不显示所述第一选项；响应于对所述第一应用中启动所述第一界面入口的点击操作，显示所述第一界面，所述第一界面显示了所述第二选项，不显示所述第一选项；响应于对所述第二选项的点击操作，搜索所述升级包；在搜索到存在所述升级包时，刷新所述第一界面，取消显示在所述第一界面中的所述第二选项，显示触发所述电子设备获取升级包，并基于所述升级包对操作系统进行升级的第四选项；响应于对所述第四选项的点击操作，获取所述升级包，并显示所述第一界面，所述第一界面显示了所述升级包的下载进度信息，不显示所述第一选项；在所述升级包下载成功后，将所述升级包中的升级文件写入到对应分区；在将所述升级包中的升级文件写入到对应分区的过程中，刷新所述第一界面，取消显示在所述第一界面中的下载进度信息，显示将所述升级包中的升级文件写入到对应分区的安装进度信息，不显示所述第一选项；在所述升级包中升级文件安装完毕后，刷新所述第一界面，取消显示在所述第一界面中的安装进度信息，显示所述第一选项。9.根据权利要求1至3任一项所述的方法，其特征在于，在所述电子设备重启，从所述第一操作系统运行到所述第二操作系统之后，所述方法还包括：在搜索到第三操作系统对应的升级包后，获取所述第三操作系统对应的升级包的文件列表描述信息；在所述第三操作系统对应的升级包的文件列表描述信息中记录了重启标记时，根据所述重启标记，将共享内存中存储的所述第一重启属性和所述第一重启属性值更新为第三重启属性和第三重启属性值，所述第三重启属性值指示所述电子设备需要重启。10.根据权利要求9所述的方法，其特征在于，所述方法还包括：
将所述第三操作系统对应的升级包中的升级文件写入对应分区后，根据所述第三重启属性值，刷新所述第一界面，显示所述第一选项。11.一种电子设备，其特征在于，所述电子设备包括：存储器和处理器，所述存储器和所述处理器耦合；所述存储器存储有程序指令，所述程序指令由所述处理器执行时，使得所述电子设备执行如权利要求1至10任意一项所述的操作系统的升级方法。12.一种计算机可读存储介质，其特征在于，包括计算机程序，当所述计算机程序在电子设备上运行时，使得所述电子设备执行如权利要求1至10任意一项所述的操作系统的升级方法。

技术总结
本申请提供了一种操作系统的升级方法、设备及存储介质，该方法应用于电子设备，包括：显示第一界面，第一界面显示了触发电子设备重启的第一选项；响应于对第一选项的点击操作，触发电子设备重启，以从升级前的第一操作系统运行到升级后的第二操作系统；在电子设备重启的过程中，获取属性文件中设置的第一重启属性值；其中，属性文件为存储在只读存储器中的全局共享文件；第一重启属性值为固定值，用于指示电子设备无须重启；根据第一重启属性值，刷新第一界面，取消显示在第一界面中的第一选项，显示触发电子设备搜索升级包的第二选项。由此，使操作系统升级重启后的电子设备的用户交互界面能够及时刷新。交互界面能够及时刷新。交互界面能够及时刷新。


技术研发人员：张磊 赵冰清
受保护的技术使用者：荣耀终端有限公司
技术研发日：2023.03.27
技术公布日：2023/7/12