CN116400938A

CN116400938A - Operating system upgrading method, device and storage medium

Info

Publication number: CN116400938A
Application number: CN202310340403.XA
Authority: CN
Inventors: 张磊; 赵冰清
Original assignee: Honor Device Co Ltd
Current assignee: Honor Device Co Ltd
Priority date: 2023-03-27
Filing date: 2023-03-27
Publication date: 2023-07-07
Anticipated expiration: 2043-03-27
Also published as: CN116400938B

Abstract

The application provides an upgrade method, equipment and storage medium of an operating system, wherein the method is applied to electronic equipment and comprises the following steps: displaying a first interface, wherein the first interface displays a first option for triggering restarting of the electronic equipment; responding to clicking operation of the first option, triggering the electronic equipment to restart so as to run from the first operating system before upgrading to the second operating system after upgrading; acquiring a first restarting attribute value set in an attribute file in the restarting process of the electronic equipment; wherein the attribute file is a global shared file stored in a read-only memory; the first restarting attribute value is a fixed value and is used for indicating that the electronic equipment does not need restarting; and refreshing the first interface according to the first restarting attribute value, canceling the first option displayed in the first interface, and displaying the second option triggering the electronic equipment to search the upgrade package. Therefore, the user interaction interface of the electronic equipment after the upgrade and restart of the operating system can be refreshed in time.

Description

Operating system upgrading method, device and storage medium

Technical Field

The present disclosure relates to the field of computer technologies, and in particular, to an operating system upgrading method, device, and storage medium.

Background

Currently, the operating system of an electronic device may be upgraded in a manner that requires a restart (e.g., cold patch upgrade, over-the-Air Technology (OTA) upgrade, etc.), or in a manner that does not require a restart (e.g., hot patch upgrade).

For an upgrade mode needing restarting, after data in an upgrade package is written into a corresponding partition, after the electronic equipment is restarted, an option for triggering the electronic equipment to restart still exists in a software update interface displayed in a multi-task management interface in a short time, and after the software update interface is started from the multi-task management interface, the option for triggering the restarting in the software update interface can still be triggered by a user, so that the electronic equipment is restarted again.

Disclosure of Invention

In order to solve the technical problems, the application provides an upgrading method, equipment and a storage medium of an operating system, which aim to enable a user interaction interface of electronic equipment after the operating system is upgraded and restarted to be refreshed in time, and an option triggering the electronic equipment to restart is not displayed in a software updating interface displayed in a multi-task management interface, so that better use experience is brought to a user.

In a first aspect, the present application provides an upgrade method of an operating system, which is applied to an electronic device. The method comprises the following steps: displaying a first interface, wherein the first interface displays a first option for triggering restarting of the electronic equipment; responding to clicking operation of the first option, triggering the electronic equipment to restart so as to run from the first operating system before upgrading to the second operating system after upgrading; acquiring a first restarting attribute value set in an attribute file in the restarting process of the electronic equipment; wherein the attribute file is a global shared file stored in a read-only memory; the first restarting attribute value is a fixed value and is used for indicating that the electronic equipment does not need restarting; and refreshing the first interface according to the first restarting attribute value, canceling the first option displayed in the first interface, and displaying the second option triggering the electronic equipment to search the upgrade package.

In the process of updating the first operating system to the second operating system and triggering the restarting, the electronic equipment is instructed to not need to restart the fixed first restarting attribute value set in the globally shared attribute file, and then the first interface is refreshed according to the first restarting attribute value, so that a first option for triggering the restarting of the electronic equipment is not displayed in the first interface, and after the electronic equipment is restarted, a user accesses the first interface immediately from any one of the inlets, the first option is not displayed in the first interface, and better use experience is brought to the user.

According to a first aspect, in a process of restarting the electronic device, acquiring a first restarting attribute value set in an attribute file includes: in the restarting process of the electronic equipment, a first restarting attribute and a first restarting attribute value are read from the attribute file; and writing the first restarting property and the first restarting property value into the shared memory in the form of key value pairs.

The first restarting attribute and the first restarting attribute value stored in the attribute file in the read-only memory are written into the shared memory in the form of key value pairs, so that the first restarting attribute can be quickly acquired from the shared memory in the restarting process of the electronic equipment, the first interface is refreshed in time, and the displayed user interaction interface is ensured to be free from abnormality after the electronic equipment is restarted.

According to the first aspect, or any implementation manner of the first aspect, according to the first restart attribute value, the first interface is refreshed, a first option displayed in the first interface is cancelled, a second option triggering the electronic device to search for an upgrade package is displayed, and the method includes: and acquiring a first restarting attribute value corresponding to the first restarting attribute from the shared memory, refreshing the first interface according to the first restarting attribute value, canceling the first option displayed in the first interface, and displaying a second option triggering the electronic equipment to search the upgrade package.

Therefore, according to the first restarting attribute value which is registered in advance in the global shared attribute file and indicates that the electronic equipment does not need restarting, the first interface is refreshed in time, and the state information carried by the startup broadcast is not relied on, so that the rationality of the display content of the first interface is effectively ensured.

According to the first aspect, or any implementation manner of the first aspect, a first interface is displayed, where the first interface displays a first option for triggering the restart of the electronic device, and the method includes: displaying a second interface, wherein the second interface comprises a first prompt window, and a third option for triggering the electronic equipment to acquire an upgrade package and upgrading an operating system based on the upgrade package is displayed in the first prompt window; responding to clicking operation of the third option, acquiring an upgrade package, and displaying a first interface, wherein the first interface displays downloading progress information of the upgrade package and does not display the first option; after the upgrade package is downloaded successfully, writing an upgrade file in the upgrade package into a corresponding partition; refreshing the first interface in the process of writing the upgrade file in the upgrade package into the corresponding partition, canceling the downloading progress information displayed in the first interface, displaying the installation progress information of writing the upgrade file in the upgrade package into the corresponding partition, and not displaying the first option; after the upgrade file in the upgrade package is installed, refreshing the first interface, canceling the installation progress information displayed in the first interface, and displaying the first option.

Therefore, by means of actively prompting the user to upgrade, the upgrade package is obtained and installed by one key, and the operation of the user is greatly simplified.

According to the first aspect, or any implementation manner of the first aspect, the obtaining an upgrade package includes: acquiring file list description information corresponding to the upgrade package, wherein the file list description information records a download address and a restarting mark of the upgrade package, and the restarting mark is used for indicating that the upgrade of the operating system based on the upgrade package involves a restarting link; acquiring an upgrade package from a download address to a user data partition of the electronic device; and updating the first restarting attribute and the first restarting attribute value stored in the shared memory into a second restarting attribute and a second restarting attribute value according to the restarting mark, wherein the second restarting attribute value indicates that the electronic equipment needs to be restarted.

In the process of upgrading the operating system, whether the electronic equipment needs to be restarted or not and the restarting attribute value in the shared memory are updated according to the restarting mark, for example, the first restarting attribute and the first restarting attribute value which indicate that the electronic equipment does not need to be restarted are updated to the second restarting attribute and the second restarting attribute value which indicate that the electronic equipment needs to be restarted, so that the first interface can be refreshed in time in the upgrading process, a first option for triggering the electronic equipment to be restarted by a user is displayed in the first interface, and the electronic equipment can be restarted conveniently operated by the user.

According to the first aspect, or any implementation manner of the first aspect, after the installation of the upgrade file in the upgrade package is completed, the first interface is refreshed, the installation progress information displayed in the first interface is canceled, and the first option is displayed, including: after the upgrade file in the upgrade package is installed, a second restarting attribute value corresponding to the second restarting attribute is obtained from the shared memory, the first interface is refreshed according to the second restarting attribute value, the installation progress information displayed in the first interface is canceled, and the first option is displayed.

According to the first aspect, or any implementation manner of the first aspect, writing an upgrade file in an upgrade package to a corresponding partition includes: analyzing the upgrade package in the user data partition to obtain an upgrade file in the upgrade package; writing the upgrade file of the corresponding static partition into the static partition, and writing the upgrade file of the corresponding dynamic partition into the dynamic partition.

According to the first aspect, or any implementation manner of the first aspect, a first interface is displayed, where the first interface displays a first option for triggering the restart of the electronic device, and the method includes: displaying a second interface, wherein the second interface comprises a first application, and the first application integrates a first interface inlet; before the upgrade package is not acquired, a first option is not displayed in a first interface started from a first application; responding to clicking operation for starting a first interface entry in the first application, displaying a first interface, wherein the first interface displays a second option and does not display the first option; responding to clicking operation of the second option, searching for an upgrade package; refreshing the first interface when the existence of the upgrade package is searched, canceling the second option displayed in the first interface, displaying a fourth option for triggering the electronic equipment to acquire the upgrade package and upgrading the operating system based on the upgrade package; responding to clicking operation of the fourth option, acquiring an upgrade package, and displaying a first interface, wherein the first interface displays downloading progress information of the upgrade package and does not display the first option; after the upgrade package is downloaded successfully, writing an upgrade file in the upgrade package into a corresponding partition; refreshing the first interface in the process of writing the upgrade file in the upgrade package into the corresponding partition, canceling the downloading progress information displayed in the first interface, displaying the installation progress information of writing the upgrade file in the upgrade package into the corresponding partition, and not displaying the first option; after the upgrade file in the upgrade package is installed, refreshing the first interface, canceling the installation progress information displayed in the first interface, and displaying the first option.

Therefore, the user can conveniently and automatically trigger the upgrade of the operating system according to actual needs by actively searching the upgrade package and triggering the upgrade, thereby meeting the user demands.

According to the first aspect, or any implementation manner of the first aspect, after the electronic device is restarted, the method further includes, after running from the first operating system to the second operating system: after searching an upgrade package corresponding to a third operating system, acquiring file list description information of the upgrade package corresponding to the third operating system; when a restart marker is recorded in file list description information of an upgrade package corresponding to a third operating system, updating a first restart attribute and a first restart attribute value stored in a shared memory into a third restart attribute and a third restart attribute value according to the restart marker, wherein the third restart attribute value indicates that the electronic equipment needs to be restarted.

According to the first aspect, or any implementation manner of the first aspect, the method further includes: after the upgrade files in the upgrade package corresponding to the third operating system are written into the corresponding partition, refreshing the first interface according to the third restarting attribute value, and displaying the first option.

In a second aspect, the present application provides an electronic device. The electronic device includes: a memory and a processor, the memory and the processor coupled; the memory stores program instructions that, when executed by the processor, cause the electronic device to perform the instructions of the first aspect or of the method in any possible implementation of the first aspect.

Any implementation manner of the second aspect and the second aspect corresponds to any implementation manner of the first aspect and the first aspect, respectively. The technical effects corresponding to the second aspect and any implementation manner of the second aspect may be referred to the technical effects corresponding to the first aspect and any implementation manner of the first aspect, which are not described herein.

In a third aspect, the present application provides a computer readable medium for storing a computer program comprising instructions for performing the method of the first aspect or any possible implementation of the first aspect.

Any implementation manner of the third aspect and any implementation manner of the third aspect corresponds to any implementation manner of the first aspect and any implementation manner of the first aspect, respectively. The technical effects corresponding to the third aspect and any implementation manner of the third aspect may be referred to the technical effects corresponding to the first aspect and any implementation manner of the first aspect, which are not described herein.

In a fourth aspect, the present application provides a computer program comprising instructions for performing the method of the first aspect or any possible implementation of the first aspect.

Any implementation manner of the fourth aspect and any implementation manner of the fourth aspect corresponds to any implementation manner of the first aspect and any implementation manner of the first aspect, respectively. Technical effects corresponding to any implementation manner of the fourth aspect may be referred to the technical effects corresponding to any implementation manner of the first aspect, and are not described herein.

In a fifth aspect, the present application provides a chip comprising processing circuitry, a transceiver pin. Wherein the transceiver pin and the processing circuit communicate with each other via an internal connection path, the processing circuit performing the method of the first aspect or any one of the possible implementation manners of the first aspect to control the receiving pin to receive signals and to control the transmitting pin to transmit signals.

Any implementation manner of the fifth aspect and any implementation manner of the fifth aspect corresponds to any implementation manner of the first aspect and any implementation manner of the first aspect, respectively. Technical effects corresponding to any implementation manner of the fifth aspect may be referred to the technical effects corresponding to any implementation manner of the first aspect, and are not described herein.

Drawings

FIG. 1 is a schematic diagram of an apparatus involved in an operating system upgrade, shown schematically;

FIG. 2 is a schematic diagram of an interface for triggering a reboot of an electronic device, shown schematically;

FIG. 3 is a schematic diagram of an exemplary user interaction interface;

FIG. 4 is a schematic diagram illustrating an abnormal interface of the multi-task management interface after an operating system upgrade is restarted;

fig. 5 is a schematic hardware structure diagram of an electronic device for implementing an upgrade method of an operating system according to an embodiment of the present application;

fig. 6 is a schematic software architecture diagram of an electronic device for implementing an upgrade method of an operating system according to an embodiment of the present application;

FIG. 7 is a schematic diagram illustrating functional services involved in an upgrade method of an operating system according to an embodiment of the present application;

FIG. 8 is a schematic diagram illustrating processing involved in upgrading an operating system of an electronic device using an upgrade mode that requires a reboot;

FIG. 9 is a schematic diagram of one type of user interaction interface involved in an exemplary illustrated upgrade process of an operating system;

FIG. 10 is a schematic diagram of yet another user interaction interface involved in an exemplary illustrated upgrade process of an operating system;

FIG. 11 is a schematic diagram of yet another user interaction interface involved in an exemplary illustrated upgrade process of an operating system;

FIG. 12 is a schematic diagram of yet another user interaction interface involved in an exemplary illustrated upgrade process of an operating system;

FIG. 13 is a schematic diagram of yet another user interaction interface involved in an exemplary illustrated upgrade process of an operating system;

FIG. 14 is a schematic diagram of yet another user interaction interface involved in an exemplary illustrated upgrade process of an operating system;

FIG. 15 is a schematic diagram of yet another user interaction interface involved in an exemplary illustrated upgrade process of an operating system;

FIG. 16 is a schematic diagram of yet another user interaction interface involved in an exemplary illustrated upgrade process of an operating system;

FIG. 17 is a schematic diagram of yet another user interaction interface involved in an exemplary illustrated upgrade process of an operating system;

FIG. 18 is a schematic diagram of yet another user interaction interface involved in an exemplary illustrated upgrade process of an operating system;

FIG. 19 is a schematic diagram of yet another user interaction interface involved in an exemplary operating system upgrade process;

FIG. 20 is a timing diagram illustrating interactions between devices, functional modules involved in implementing an upgrade method of an operating system;

Fig. 21 is a flowchart illustrating an upgrade method of an operating system according to an embodiment of the present application.

Detailed Description

The following description of the embodiments of the present application will be made clearly and fully with reference to the accompanying drawings, in which it is evident that the embodiments described are some, but not all, of the embodiments of the present application. All other embodiments, which can be made by one of ordinary skill in the art based on the embodiments herein without making any inventive effort, are intended to be within the scope of the present application.

The term "and/or" is herein merely an association relationship describing an associated object, meaning that there may be three relationships, e.g., a and/or B, may represent: a exists alone, A and B exist together, and B exists alone.

The terms first and second and the like in the description and in the claims of embodiments of the present application are used for distinguishing between different objects and not necessarily for describing a particular sequential order of objects. For example, the first target object and the second target object, etc., are used to distinguish between different target objects, and are not used to describe a particular order of target objects.

In the embodiments of the present application, words such as "exemplary" or "such as" are used to mean serving as examples, illustrations, or descriptions. Any embodiment or design described herein as "exemplary" or "for example" should not be construed as preferred or advantageous over other embodiments or designs. Rather, the use of words such as "exemplary" or "such as" is intended to present related concepts in a concrete fashion.

In the description of the embodiments of the present application, unless otherwise indicated, the meaning of "a plurality" means two or more. For example, the plurality of processing units refers to two or more processing units; the plurality of systems means two or more systems.

Referring to FIG. 1, a schematic diagram of a device involved in an operating system upgrade is shown schematically.

As shown in fig. 1, an upgrade package for upgrading an operating system, and file list description information (file list. Xml) recording information such as the size of the upgrade package, whether the upgrade of the operating system based on the upgrade package needs to be restarted, may be provided by a package server to an upgrade package server of a cloud, where the server may be, for example, an OTA server for management, and the upgrade package server may send, according to a request for obtaining the upgrade package initiated by different electronic devices on an end side, for example, a PC device, a tablet device, a mobile phone, etc., a corresponding upgrade package and a file list. Xml corresponding to the upgrade package to the electronic device, or the upgrade package server actively pushes, after receiving the upgrade package sent by the package server and the file list. Xml corresponding to the upgrade package to the corresponding electronic device.

Regarding to the method that the package beating server makes upgrade packages of different versions and the filelist.xml corresponding to the upgrade package, and pushes the upgrade package and the filelist.xml corresponding to the upgrade package server, and the upgrade package server pushes the upgrade package and the filelist.xml corresponding to the upgrade package to the electronic device, the method is just to see the existing implementation scheme, and the application will not be described.

Correspondingly, after the electronic device, such as a mobile phone, acquires the upgrade package and the filelist corresponding to the upgrade package from the upgrade package server, an upgrade engine in the electronic device reads the upgrade file in the upgrade package, writes the read upgrade file into a corresponding partition, and determines whether the upgrade of the operating system needs to be restarted according to the restart identifier recorded in the filelist.

Accordingly, if the restart is required, after the upgrade files in the upgrade package are all written into the corresponding partitions, i.e. after the installation is completed, the content in the software update interface may be refreshed to the content in the interface 10a shown in fig. 2, i.e. the "restart immediately" option is displayed.

Referring to fig. 2, for example, when the user clicks the "restart immediately" option, the mobile phone responds to the operation action to exit the current operating system (before upgrading, which will be referred to as the first operating system in the following), turn off the mobile phone power, turn on the mobile phone power again, and load the upgraded operating system (which will be referred to as the second operating system in the following).

Accordingly, after the mobile phone is restarted successfully, loading of the second operating system is completed, and after the functional service related to the application program installed in the mobile phone is created, a user interaction interface, such as the interface 10b shown in fig. 3, is entered.

Referring to fig. 3, in an exemplary embodiment, in order to enable a user to quickly start an application program (hereinafter referred to simply as an application) or a user interaction interface accessed before restarting a mobile phone, after the mobile phone is restarted, the user may immediately call up a multitasking management interface by designating a gesture action, such as the gesture action shown in fig. 3, or triggering a certain function option, so as to find the application or the user interaction interface accessed before restarting the mobile phone from the multitasking management interface.

However, at present, the refreshing of the user interaction interface after the electronic device is started is to determine the display and refresh of the function options based on the attribute values (or state values) of the function options received in the start-up broadcast for each application or the user interaction interface. The startup broadcast usually has a delay of 6s to 10s, so if the user calls up the multi-task management interface after restarting the mobile phone, the mobile phone cannot know the attribute value describing the upgrade state because the mobile phone has not received the startup broadcast yet. In this case, the mobile phone may consider that the restart has not been triggered after the upgrade package is installed, so the content in the software update interface displayed in the multitasking interface is still the same as the interface 10a shown in fig. 2 before the restart is triggered, as shown in fig. 4.

Illustratively, when the user interaction interface displayed in the multitasking interface is as the content included in the interface 10c shown in fig. 4, and the user clicks the user interaction interface "software update", the mobile phone will switch the user interaction interface "software update" back to the mobile phone foreground display in response to the operation behavior, i.e. the display screen of the mobile phone will be the interface 10a shown in fig. 2.

In addition, it should be noted that, if the mobile phone has not received the startup broadcast after switching back to the interface 10a, the user clicks the "immediately restart" option again, and the mobile phone still triggers the mobile phone to restart in response to the operation behavior, i.e. to exit the second operating system, cut off the power supply of the mobile phone, then turn on the power supply of the mobile phone again, and reload the second operating system. Therefore, the illusion is caused for the user, the operating system is not upgraded successfully all the time by mistake, and the power consumption of the mobile phone is increased by frequent restarting, so that the use of the user is affected.

In view of this, the present application provides an upgrade method of an operating system, by registering a global shared and permanent restart attribute (hereinafter referred to as a system restart attribute) in a system attribute (systempropertes) using the global shared, and setting a fixed attribute value for the system restart attribute, such as an attribute value "false" identifying that the restart is not required, further, in the process of restarting an electronic device, directly reading the attribute value of the system restart attribute, refreshing function options to be displayed in a software update interface according to the attribute value, so that options for triggering the restart of the electronic device are not displayed in the software update interface displayed in a multitask management interface.

In order to better understand the technical solution provided by the embodiments of the present application, before describing the technical solution of the embodiments of the present application, a hardware structure and a software architecture of an electronic device to which the embodiments of the present application are applicable are first described with reference to the accompanying drawings.

The electronic device to which the embodiment of the present application is applicable may be, for example, a mobile phone, a tablet computer, a smart watch, a PC device, etc., which are not listed here, but the embodiment is not limited thereto. For convenience of explanation, this embodiment will be described with reference to a mobile phone.

Referring to fig. 5, the mobile phone 100 may include: processor 110, external memory interface 120, internal memory 121, universal serial bus (universal serial bus, USB) interface 130, charge management module 140, power management module 141, battery 142, antenna 1, antenna 2, mobile communication module 150, wireless communication module 160, audio module 170, sensor module 180, keys 190, motor 191, indicator 192, camera 193, display 194, and subscriber identity module (subscriber identification module, SIM) card interface 195, among others.

By way of example, the audio module 170 may include a speaker 170A, a receiver 170B, a microphone 170C, an earphone interface 170D, and the like.

By way of example, the sensor module 180 may include a pressure sensor, a gyroscope sensor, a barometric pressure sensor, a magnetic sensor, an acceleration sensor, a distance sensor, a proximity sensor, a fingerprint sensor, a temperature sensor, a touch sensor, an ambient light sensor, a bone conduction sensor, and the like.

Illustratively, the keys 190 include a power key (power on key), a volume key, and the like. The keys 190 may be mechanical keys or touch keys. The handset 100 may receive key inputs, generating signal inputs related to user settings and function control of the handset 100.

In addition, it should be noted that, in practical applications, the processor 110 may include one or more processing units, for example: the processor 110 may include an application processor (application processor, AP), a modem processor, a graphics processor (graphics processing unit, GPU), an image signal processor (image signal processor, ISP), a controller, a memory, a video codec, a digital signal processor (digital signal processor, DSP), a baseband processor, and/or a neural network processor (neural-network processing unit, NPU), etc.

It will be appreciated that in particular implementations, the different processing units may be separate devices or may be integrated in one or more processors.

Further, in some implementations, the controller may be a neural hub and command center of the cell phone 100. The controller can generate operation control signals according to the instruction operation codes and the time sequence signals to finish the control of instruction fetching and instruction execution.

In addition, memory in the processor 110 is primarily used for storing instructions and data. In some implementations, the memory in the processor 110 is a cache memory.

Further, it will be appreciated that in an actual application scenario, executable program code, including instructions, that trigger the handset 100 to implement various functional applications and data processing is stored in the internal memory 121.

For example, in particular, in the technical solution provided in the embodiment of the present application, the starting of the mobile phone 100 and the upgrading of the operating system mainly depend on the related instructions stored in the internal memory 121 in advance, and the processor 110 can enable the mobile phone 100 to execute the upgrading method of the operating system provided in the embodiment of the present application by executing the instructions stored in the internal memory 121.

In addition, it should be noted that, in a specific implementation, the internal Memory 121 may include a Read-Only Memory (ROM) and a random access Memory (Random Access Memory, RAM). The read-only memory can be divided into three different partition structures of a non-AB system, an AB system and a virtual AB system.

It will be appreciated that, in particular for practical applications, a random access memory, also known as "main memory", which is read and written at any time and is fast, is often used as a temporary data storage medium for an operating system or other running program, and when the power is turned off, the RAM is not capable of retaining data, i.e. the random access memory typically stores temporary data when the electronic device is running. The ROM is a read-only memory, which can be called as a nonvolatile memory, and the stored data is generally written in advance before being loaded into the whole machine, such as an image file of an operating system and user data generated when a user uses the electronic equipment, and the data can only be read out in the working process of the whole machine and cannot be quickly and conveniently rewritten like a RAM, so that the data stored in the ROM is stable and the data stored after power failure is not changed. In summary, compared with the RAM and the ROM, the RAM and the ROM have the greatest difference that the data stored on the RAM automatically disappears after the RAM is powered off, but the ROM does not automatically disappear, and the RAM can be powered off for a long time for storage.

The read only memory may be, for example, a disk storage device, a flash memory device, a general purpose flash memory (universal flash storage, UFS), or the like. The random access memory may be, for example, a high-speed random access memory.

In addition, it should be noted that, in a specific implementation, the read-only memory may include a storage program area and a storage data area. The storage program area may store an application program (such as a sound playing function, an image playing function, etc.) required for at least one function of the operating system, etc. The storage data area may store data (e.g., audio data, phonebook, etc.) created during use of the handset 100, etc.

Illustratively, regarding the storage program area, for example, basic partition (Common), static partition (Static partition), and dynamic partition (Super) may be mentioned; with respect to the storage data area, it may be, for example, a user data partition (Userdata).

Based on the storage structure, in the upgrading process of the current operating system, an upgrade package acquired by a mobile phone from an upgrade package server, such as an OTA server, is firstly downloaded to a user data partition located in a read-only memory, after the upgrade package is downloaded, the upgrade package is decompressed, then an upgrade file in the upgrade package is written into a corresponding partition by means of kernel cache of a random access memory, such as writing the upgrade file of a corresponding static partition into the static partition, and writing the upgrade file of a corresponding dynamic partition (Super partition) into the dynamic partition, so that quick reading and writing of the upgrade file are realized.

Furthermore, it should be noted that, based on the characteristics of the above four partitions (the base partition, the static partition, the dynamic partition, and the user data partition), for the partition that does not need to be upgraded in the operating system upgrade, for example, the base partition and the user data partition, a single partition is adopted in the non-AB system, the AB system, or the virtual AB system, and the partition that needs to be upgraded may be different.

For example, since the operating system is upgraded under the non-AB system, other functions of the mobile phone cannot be used in the upgrading process, the mobile phone can only stay on the upgrading interface of the non-AB system, and the upgrading files in the upgrading package are written into the corresponding partitions completely, namely after the installation is completed, and after the mobile phone is restarted, the mobile phone can enter the user interaction interface for normal use. Therefore, under the non-AB system, the static partition and the dynamic partition are also single partitions, so that the occupation of the memory space can be reduced, and more space is reserved for user data partition.

The AB system is exemplified to enable the mobile phone to return to the main interface of the mobile phone or other user interaction interfaces at will in the process of upgrading the operation system, so that the use of the mobile phone is not affected. Thus, under an AB system, a static partition and a dynamic partition adopt double partitions. For example, the static partition may be divided into a first static partition and a second static partition, and the dynamic partition may be divided into a first dynamic partition and a second dynamic partition, for example. The partition dividing mode can enable the mobile phone to return to each user interaction interface of the mobile phone at will in the upgrading process of the operating system, but occupies a large space of the memory, so that the available space of the user data partition is greatly reduced.

The virtual AB system combines the advantages of a non-AB system and an AB system, and divides a static partition which occupies small storage space into a first static partition and a second static partition, and a dynamic partition which occupies large storage space and occupies large storage space into a single partition.

Taking the partition structure of the read-only memory as an example of the partition structure of the virtual AB system, in particular to practical application, the partition deployment information of the read-only memory in the mobile phone can be described by a partition table shown in table 1.

TABLE 1 partition Table

In this way, the starting address and size of each partition are defined by the partition table, so that the corresponding partition size can be adjusted as needed for different hardware.

In addition, it should be noted that, except for the specially reserved partition, basically, each partition has its corresponding image (image) file, where the image file is compiled by software code, and various functional files and configurations related to the starting or running process of the mobile phone are integrated therein. Without the image file, the handset is not operational. A complete system version includes many images, partition table images gpt.img, boot related images (xloader.img, boot. Img), system images super.img (integrating android system cores), user data images userdata.img (storing user data), etc.

It should be understood that the above description is only an example for better understanding of the technical solution of the present embodiment, and is not to be taken as the only limitation of the present embodiment.

That is, in practical applications, the partitions recorded in the partition table may be set in a partition manner according to the actual service requirements.

In addition, it should be noted that, for convenience of description, the following description of the method for upgrading an operating system provided in the embodiment of the present application takes a partition structure of a read-only memory as an example of a virtual AB system partition structure.

As to the hardware architecture of the handset 100, it should be understood that the handset 100 shown in fig. 5 is only one example, and in a specific implementation, the handset 100 may have more or fewer components than shown in the figures, may combine two or more components, or may have a different configuration of components. The various components shown in fig. 5 may be implemented in hardware, software, or a combination of hardware and software, including one or more signal processing and/or application specific integrated circuits.

In order to better understand the software structure of the mobile phone 100 shown in fig. 5, the following describes the software structure of the mobile phone 100. Before explaining the software structure of the mobile phone 100, an architecture that the software system of the mobile phone 100 can employ will be first described.

Specifically, in practical applications, the software system of the mobile phone 100 may adopt a layered architecture, an event-driven architecture, a microkernel architecture, a microservice architecture, or a cloud architecture.

Furthermore, it is understood that software systems currently in use in mainstream electronic devices include, but are not limited to, windows systems, android systems, and iOS systems. For convenience of explanation, the Android system with a layered architecture is taken as an example in the embodiment of the present application to exemplarily illustrate the software structure of the mobile phone 100, however, in practical application, the method for upgrading the operating system provided in the embodiment of the present application is also applicable to other systems.

Referring to fig. 6, a software architecture block diagram of a mobile phone 100 capable of implementing the method for upgrading an operating system provided in the embodiment of the present application is illustrated.

As shown in fig. 6, the layered architecture of the handset 100 divides the software into several layers, each with a clear role and division. The layers communicate with each other through a software interface. In some implementations, the Android system is divided into four layers, from top to bottom, an application layer, an application framework layer, an Zhuoyun row (Android run) and system libraries, and a kernel layer, respectively.

The application layer may include a series of application packages, among other things. As shown in fig. 6, the application package may include applications such as an ota Client (OUC), a setup, bluetooth, WIFI, etc., which are not further listed herein, but are not limited thereto.

For example, in order to implement an upgrade of the operating system, in some implementations, the mobile phone may access, through a WIFI application, a WIFI network available in a nearby area, then obtain, through the OUC, an upgrade package from an upgrade package server, such as an OTA server, that manages the upgrade package, and then implement, by the upgrade engine, writing an upgrade file in the upgrade package into a corresponding partition, after the installation is completed, triggering, by the OUC, the restart of the mobile phone in response to an operation behavior of a user to a restart option.

In addition, in order to implement an upgrade of the operating system, in other implementations, the OUC and WIFI applications may be integrated into the setup application, that is, a corresponding operation portal is provided in the setup application, so as to implement the above operation.

Wherein the application framework layer provides an application programming interface (application programming interface, API) and programming framework for application programs of the application layer. In some implementations, these programming interfaces and programming frameworks can be described as functions. As shown in FIG. 6, the application framework layer may include functions of a system service, a content provider, a resource manager, a window manager, etc., which are not explicitly recited herein, and are not limiting in this application.

It should be noted that, the resource manager is configured to provide various resources, such as localization strings, icons, pictures, layout files, video files, and the like, for the application program, which are not limited in this application.

The content provider is used to store and retrieve data and make such data accessible to applications. By way of example, such data may include video, images, audio, calls made and received, browsing history and bookmarks, phone books, etc., which are not to be limiting in this application.

The window manager is used for managing window programs. The window manager can acquire the size of the display screen, judge whether a status bar exists, lock the screen, intercept the screen and the like.

The system services are used to instantiate corresponding services of applications, components, etc. In particular, in this embodiment, the system service may instantiate an attribute service for reading the system restart attribute.

As shown in fig. 7, in particular, in the embodiment provided in the present application, during the restart process of the mobile phone, a corresponding interface, such as a system Properties file () is called through a property service (property service) instantiated by a system service, and a property value (property file) corresponding to a user-unmodified system restart property (property value) registered in a system global shared file (property file) stored in a read-only memory is read, that is, step S101 is executed, and the read content is loaded into a shared memory corresponding to the system property, that is, step S102 is executed.

It should be noted that, the property service is specifically executed in an initialization process (init process), and it loads all the system properties in the property file and the property values (in the form of key-value) corresponding to the system properties, including the system restart property and the system restart property value, into the shared memory (property_work space) corresponding to the system properties.

With continued reference to fig. 7, for example, after the mobile phone is restarted, the attribute consuming unit (property consumer) in the OUC will immediately load the system restart attribute value from the property_workspace into its corresponding virtual address space, so as to implement reading of the system restart attribute value, i.e. execute step S103.

As can be seen from the above description, the system restart attribute value is "false" by default, i.e. indicates that the upgrade status is no longer required to be restarted. Therefore, the mobile phone directly refreshes the function options required to be displayed in the software updating interface according to the system restarting attribute value, so that the options triggering the electronic equipment to restart are not displayed in the software updating interface displayed in the multi-task management interface.

With continued reference to fig. 7, exemplary, after the mobile phone is restarted, after obtaining the upgrade package from the OTA server again, when a restart identifier (restart attribute value) recorded in a file.

With continued reference to fig. 7, exemplary property consumer periodically loads the system restart attribute value in property_workspace into its corresponding virtual address space, and further implements reading of the system restart attribute value, i.e., performs step S106.

Accordingly, when the system restart attribute value changes, that is, when the mobile phone needs to be restarted, the mobile phone refreshes the function options to be displayed in the software update interface according to the updated system restart attribute value, so that the options for triggering the restart are displayed in the software update interface, such as the interface 10a shown in fig. 2.

The Android run time comprises a core library and a virtual machine. Android run is responsible for scheduling and management of the Android system.

The core library consists of two parts: one part is a function which needs to be called by java language, and the other part is a core library of android.

The application layer and the application framework layer run in a virtual machine. The virtual machine executes java files of the application program layer and the application program framework layer as binary files. The virtual machine is used for executing the functions of object life cycle management, stack management, thread management, security and exception management, garbage collection and the like.

Wherein the system library may comprise a plurality of functional modules. For example: surface manager (surface manager), media Libraries (Media Libraries), three-dimensional (3D) graphics processing Libraries (e.g., openGL ES), two-dimensional (2D) graphics engines (e.g., SGL), etc.

The surface manager is used to manage the display subsystem and provides a fusion of 2D and 3D layers for multiple applications.

Media libraries support a variety of commonly used audio, video formats for playback and recording, still image files, and the like. The media library may support a variety of audio video encoding formats, such as: MPEG4, h.264, MP3, AAC, AMR, JPG, PNG, etc.

The three-dimensional graphic processing library is used for realizing three-dimensional graphic drawing, image rendering, synthesis, layer processing and the like.

It will be appreciated that the 2D graphics engine described above is a drawing engine for 2D drawing.

In this embodiment, after the mobile phone is restarted, the user interaction interface after refreshing based on the attribute value corresponding to the system restart attribute, for example, drawing a software update interface, needs to use a 2D graphics engine and/or a 3D graphics processing library. In particular, when the software update interface to be drawn includes only 2D graphics, the drawing may be implemented using a 2D graphics engine. Accordingly, when the software update interface to be drawn only includes 3D graphics, the drawing may be implemented using a 3D graphics processing library. Correspondingly, when the software updating interface to be drawn comprises both 2D graphics and 3D graphics, the drawing can be realized by adopting a 2D graphics engine and a 3D graphics processing library respectively.

Furthermore, it can be appreciated that the kernel layer in the Android system is a layer between hardware and software. The kernel layer at least comprises a display driver, an upgrade engine, WIFI determination and the like.

By way of example, the display driver may drive the display screen to display a user interaction interface, such as a multitasking interface, rendered by the 2D graphics engine and/or the 3D graphics processing library, as well as a software update interface presented in the multitasking interface.

The WIFI driver may drive the WIFI chip to access the WIFI network, and further obtain the upgrade package from the upgrade package server, such as the OTA server, through the WIFI network.

By way of example, the upgrade engine may implement an upgrade to the operating system based on the upgrade package downloaded locally from the OTA server.

As to the software structure of the mobile phone 100, it will be understood that the layers and the components included in the layers in the software structure shown in fig. 6 do not constitute a specific limitation on the mobile phone 100. In other embodiments of the present application, the handset 100 may include more or fewer layers than shown, and more or fewer components may be included in each layer, as the present application is not limited.

In addition, it should be understood that, for the upgrade mode that needs to be restarted, such as online upgrade and cold patch upgrade, the links involved in the upgrade process of the operating system may be divided into searching, downloading, installing and restarting as shown in fig. 8. The download link is triggered only when the update package with a new version is searched in the package searching link.

For a better understanding of the processing logic in the various links involved in the operating system upgrade process shown in fig. 8, the following description is provided in detail in connection with fig. 9-19.

Regarding the processing logic of the search link, it is exemplary, in some implementations, that the user triggers from a designated entry. In other implementations, the upgrade package server (hereinafter, an OTA server is taken as an example) may be actively pushed.

As for the manner in which the user triggers from the designated portal, for example, the user clicks an icon of the setting application in the interface 10b shown in fig. 3, and then the mobile phone starts the setting application in response to the operation behavior, and the user interaction interface displayed by the mobile phone is switched from the interface 10b to the setting interface, such as the interface 10d shown in fig. 9.

Referring to FIG. 9, for example, at least the "System and update" option may be included in interface 10d. When the user clicks the "System and update" option, the handset will switch from interface 10d to the software update interface in response to this operational behavior. It will be appreciated that the software update interface switched to at this time is different from the display content in the interface 10a shown in fig. 2, and the software update interface switched to from the interface 10d may be represented as the interface 10e shown in fig. 10 for convenience of distinction.

It should be noted that, in this embodiment, the functions provided by the OUC application are integrated into the interfaces corresponding to the "system and update" options of the setting application, and the operations triggered by the function options in these interfaces are still realized by the OUC borrowing.

Referring to fig. 10, for example, a current system version of the handset may be displayed in interface 10e, as shown in fig. 10 for the current version as "2.1.0".

With continued reference to FIG. 10, exemplary, a "check update" option may also be displayed in interface 10e that triggers a search for packages operation.

Correspondingly, after the user clicks the 'check update' option, the mobile phone responds to the operation behavior to generate an upgrade package search request and sends the upgrade package search request to the OTA server, so that the OTA server can search whether the new version of the upgrade package is stored locally according to the upgrade package search request (which can carry the current version).

In addition, it should be noted that, in order to bring a better use experience to the user, before receiving the packet searching result fed back by the OTA server, the mobile phone may display a prompt message of "checking the environment" in the interface 10e, and for convenience of distinction, the software update interface in this process is denoted as the interface 10f shown in fig. 11.

Further, after receiving the packet searching result fed back by the OTA server, the mobile phone further refreshes the software updating interface according to the packet searching result, so that the user can carry out subsequent operation on the refreshed software updating interface.

For example, when the searching result indicates that the OTA server does not have a new upgrade package, that is, the current operating system of the mobile phone is already in the latest version, the software update interface is refreshed, the prompt message of "checking" displayed in the interface 10f is cancelled, and the prompt message of "already in the latest version" may be displayed in the interface, so that for convenience of distinction, the software update interface in the process is represented as the interface 10g shown in fig. 12.

For example, when the searching result indicates that the OTA server has a new upgrade package, the software update interface is refreshed, and the prompt message of "checking" displayed in the interface 10f is cancelled, where the version number of the searched new version fed back by the OTA server may be displayed, for example, in the case that the current version is "2.1.0", the version number of the searched new version of the operating system may be "2.1.1", and an entry for checking the detailed information of the version is provided, so that the software update interface in this process is represented as the interface 10h shown in fig. 13 for convenience of distinction.

Referring to FIG. 13, in an exemplary embodiment, after the handset searches for an upgrade package for a new version of the operating system, the handset may automatically jump from interface 10h to an interface that looks at details of the version, such as interface 10i in FIG. 14. In other implementations, the user may also manually click on an entry provided in the interface 10h for viewing the detailed information of the version, such as an option box where the new version "2.1.1" is located in the interface 10h, or an entry ">" corresponding to the option, so that the mobile phone jumps from the interface 10h to the interface 10i shown in fig. 14 in response to the operation behavior.

Referring to fig. 14, for example, a system version of the current job, such as "2.1.0", and a system version of the new version, such as "2.1.1", and a size of the new version, such as "41.23MB", and update log content describing the operating system of the new version, such as "this update optimizes a partial scene photographing effect, a communication experience, a talk audio effect, optimizes system performance and stability, recommends your update", and "download and install" options for user operation may be displayed in the interface 10i.

With continued reference to fig. 14, exemplary, after the user clicks the "download and install" option, in response to the operation behavior, the mobile phone jumps from the interface 10i to the interface 10j shown in fig. 15, generates an upgrade package acquisition request, and sends the upgrade package acquisition request to the OTA server, so that the OTA server can send the corresponding upgrade package and the filelist. Xml corresponding to the upgrade package to the mobile phone according to the upgrade package acquisition request (which may carry information such as a version number of a new version to be acquired).

It should be noted that, in order to bring better use experience to the user, in the process of downloading the new version of the upgrade package and the filelist. Xml corresponding to the upgrade package from the OTA server, the mobile phone may display the prompt information of "download-in-process" in the interface 10j, and display a specific download progress, such as 70% shown in the interface 10 j.

Further, after the mobile phone downloads the new version of the upgrade package and the filelist. Xml corresponding to the upgrade package from the OTA server, the installation operation is automatically triggered, specifically, the OUC notifies the upgrade engine to install according to the downloaded upgrade package and the downloaded filelist. Xml, and the user interaction interface is refreshed from the interface 10j to the interface 10k in fig. 16.

It should be noted that, in order to bring a better use experience to the user, in the installation process, the mobile phone may display a prompt message of "in installation" in the interface 10k, and display a specific installation progress, such as 70% shown in the interface 10k.

Further, when the upgrade files in the upgrade package are all written into the corresponding partitions, i.e. after the upgrade package is installed, the mobile phone refreshes the current interface, such as the interface 10k, and refreshes the content displayed in the interface 10k into the content displayed in the interface 10a as shown in fig. 2, i.e. the prompt information of "installed" and the installation progress of "100%", and the user operation is performed, so as to trigger the "immediate restart" option of restarting the mobile phone.

Regarding the manner that the OTA server actively pushes the new version of the upgrade package and the filelist information to the mobile phone after receiving the new version of the upgrade package and the filelist.xml corresponding to the operating system provided by the package beating server, for example, the manner that the user previously opens an automatic upgrade function from a related function entry provided in a setting interface can be adopted, so that after receiving the setting instruction, the OTA server actively informs that the mobile phone of the current new version of the upgrade package exists after receiving the new version of the upgrade package and the filelist.xml corresponding to the operating system provided by the package beating server.

For example, in other implementations, after the mobile phone starts the automatic upgrade function, the OUC may also periodically and automatically generate an upgrade package search request, so as to request the OTA server to search for a package. Accordingly, after searching the new version of the upgrade package, the OTA server informs the mobile phone that the new version of the upgrade package exists currently.

For example, after receiving the information of the update package of the new version that is notified by the OTA server, the mobile phone may pop up the prompt window 10b-1 on the current user interaction interface, such as a use interface corresponding to a certain application, or a main interface, such as the interface 10b shown in fig. 17.

Referring to fig. 17, exemplary, the prompt window 10b-1 may display description information of the upgrade package optimization for the new version, such as "including important system optimization, suggesting you's immediate upgrade experience" shown in fig. 17, so as to prompt the user to download the new version of the upgrade package, and further trigger the upgrade operation for the current operating system.

With continued reference to FIG. 17, exemplary prompt window 10b-1 may also include a plurality of function options, such as a "later" option, a "detailed information" option, a "download and install" option.

When the "later" option is triggered, the mobile phone responds to the triggering operation of the option, closes the prompt window 10b-1 displayed on the interface 10b, and pops up the prompt window 10b-1 again after a period of time, so that the user can select whether to download and install the new version of upgrade package, and upgrade the first upgrade system to the second operating system.

Furthermore, it will be appreciated that in some implementations, when a "later" option is triggered, the handset may also pop up a later prompt time selection on the interface 10b, or automatically trigger a later time to automatically download and install, after closing the prompt window 10b-1 displayed on the interface 10b in response to a trigger operation for that option.

It should be understood that the foregoing description is merely an example for better understanding of the method of upgrading an operating system provided in the embodiments of the present application, and is not intended to be the only limitation of the embodiments.

When the "detailed information" option is triggered, the mobile phone responds to the triggering operation of the option and jumps to an interface describing the version, such as an interface 10i shown in fig. 14, or pops up an "update log" window similar to the interface 10i on the interface 10b, and displays the optimizing function of the version, the version number, the size and other information of the version in the window.

In addition, it should be noted that, in some implementation manners, when a new version of the upgrade package exists in the OTA server, the OTA server feeds back a package searching result to the mobile phone, or actively informs that when the new version of the upgrade package exists in the mobile phone currently, the fileist.xml corresponding to the upgrade package can be pushed to the mobile phone first, so that the mobile phone can analyze the size, version number and description information of the optimization function of the upgrade package from the fileist.xml, and then display the description information in an interface or window corresponding to the detailed information option.

When the option of "download and install" is triggered, the mobile phone responds to the triggering operation of the option, and generates an upgrade package acquisition request, and sends the upgrade package acquisition request to the OTA server, so that a new version of upgrade package and corresponding filelist. Xml are acquired from the OTA server, and the prompt window 10b-1 displayed on the interface 10b is closed, and the interface 10b is jumped to the interface 10j shown in fig. 15.

Accordingly, after the mobile phone downloads the new version of the upgrade package and the filelist xml corresponding to the upgrade package from the OTA server, the installation operation is automatically triggered, specifically, the OUC notifies the upgrade engine to install according to the downloaded upgrade package and the downloaded filelist xml, and the user interaction interface is refreshed from the interface 10j to the interface 10k in fig. 16.

Accordingly, when the upgrade files in the upgrade package are all written into the corresponding partitions, i.e. after the upgrade package is installed, the mobile phone refreshes the current interface, such as the interface 10k, and then refreshes the content displayed in the interface 10k into the content displayed in the interface 10a as shown in fig. 2, i.e. the prompt information of "installation completed" and the installation progress of "100%", and the user operation is performed, so as to trigger the "immediate restart" option of restarting the mobile phone.

For example, no matter what package searching mode, after the new version of the upgrade package and the corresponding filelist. Xml are obtained from the OTA server, after the user clicks the "immediate restart" option provided in the interface 10a, the OUC triggers the complete machine to restart, specifically, may notify the kernel to implement power-off, and then re-power up, so as to load the initialization process, instantiate various system services, and services related to application, and the like.

As can be seen from the above description of the software architecture of the mobile phone implementing the method for upgrading an operating system provided in the embodiment of the present application, in the process of restarting the mobile phone, the system service instantiates an attribute service and runs the attribute service into the loaded initialization process.

Accordingly, the attribute service refreshes the software update interface related to OUC, such as the content in the interface 10a triggering the "restart immediately" option after the installation, based on steps S101 to S103 shown in fig. 7.

It will be appreciated that, since the read system restart attribute value is "false", that is, indicates that a restart is not required, the "immediate restart" option in the interface 10a will be updated to the "detect update" option, and the version of the current operating system displayed will be updated to the version of the updated operating system, such as "2.1.1", and the version information corresponding to the current version displayed in the interface will be changed to "2.1.1", so as to facilitate distinction, and the interface after refreshing will be represented as the interface 10L shown in fig. 18.

Furthermore, it will be appreciated that since the handset is restarted, a main interface is typically entered, such as interface 10b shown in fig. 3. Thus, when the user passes a specified gesture, such as the gesture shown in FIG. 3, at interface 10b, or triggers a function option, the multitasking interface is invoked to find the application or user interaction interface accessed before the handset was restarted from the multitasking interface.

Based on the upgrade method of the operating system provided in the embodiment of the present application, since the content in the interface 10a is refreshed directly based on the global shared system restart attribute value in the restart process, and is refreshed as the interface 10L. Therefore, before the boot broadcast is not received, the user invokes the multitasking interface, i.e., the "software update" user interface displayed in the multitasking interface is essentially a thumbnail of the interface 10L, but not the thumbnail of the interface 10a, specifically, the multitasking interface, i.e., the interface 10m shown in fig. 19.

Accordingly, when the user clicks the "software update" user interaction interface in the interface 10m, the mobile phone responds to the operation action and switches the "software update" user interaction interface back to the mobile phone foreground display, i.e. the display screen of the mobile phone will be the interface 10L shown in fig. 18.

Accordingly, after the user clicks the "check update" option in the interface 10L, since the current operating system is already the latest operating system, no new version of the upgrade package is searched, and thus the prompt message "already the latest version" can be displayed in the interface 10 m.

Accordingly, if the new version of the upgrade package is searched again, the above-described processing logic is re-executed.

In order to better understand the upgrade method of the operating system provided by the embodiment of the present application, when implementing the 4 links shown in fig. 8, specific processing logic executed by an OTA server, an electronic device, such as an OUC in a mobile phone, an upgrade engine, an attribute service, a kernel, etc. are specifically related, and the upgrade method of the operating system provided by the embodiment of the present application is specifically described below with reference to fig. 20.

Referring to fig. 20, an illustration of a flow chart of an OUC in an electronic device actively acquiring an upgrade package that needs to be restarted from an upgrade package server, such as an OTA server, and installing and restarting the upgrade package is shown.

Illustratively, the partition structure of the rom of the electronic device is assumed to be the virtual AB system partition structure described above. When the electronic device is started, the data of the basic partition, the data of the first static partition and the data of the dynamic partition are sequentially loaded, and the electronic device is started from the first static partition, so that a first operating system, namely an operating system before upgrading, such as a system version '2.1.0' shown in fig. 10, is used as an example. Specifically, after the electronic device is started and runs to the first operating system, if the user previously starts the automatic upgrade function, the OUC will periodically execute the processing logic of the packet searching link, for example, generate an upgrade packet search request, and send the upgrade packet search request to the OTA server, that is, execute step S201 in fig. 20.

It can be understood that the upgrade package search request generated by the OUC may carry information such as a version number of the first operating system, so that the OTA server can query the operating system after updating and iterating for the first operating system.

With continued reference to fig. 20, after receiving the upgrade package search request sent by the electronic device, the OTA server queries the local database for a new version of the upgrade package, that is, performs update iteration on the first operating system, that is, performs step S202.

Correspondingly, if a new version of the upgrade package exists in the OTA server, the OTA server feeds back a download address of the filist.xml corresponding to the upgrade package of the beacon to the electronic device, that is, step S203 is executed, so that the mobile phone draws a corresponding user interaction interface according to the detailed information of the new version of the upgrade package in the filist.xml, and the user can check and select whether to upgrade the operating system. Otherwise, if no new version of the upgrade package is queried, feeding back to the electronic equipment that no new upgrade package is currently available. In this embodiment, an example is taken in which a new version of the upgrade package exists in the OTA server, that is, the OTA server executes step S203.

With continued reference to fig. 20, the exemplary electronic device receives the download address of the filelist xml fed back by the OTA server, from which the OUC will download the filelist xml to the user data partition, i.e., step S204 is performed.

Illustratively, in some implementations, the OUC may obtain the upgrade package from the OTA server based on information recorded in the filelist. Therefore, after the OUC partitions the user data after downloading the filelist.xml, the OUC may acquire the upgrade package according to the address information of the upgrade package recorded in the filelist.xml, i.e. execute step S205.

With continued reference to fig. 20, when the electronic device downloads the upgrade package from the download address corresponding to the upgrade package, the OUC stores the downloaded upgrade package into the user data partition, i.e. performs step S206.

From the above description, it is known that the upgrade of the operating system is completed by the upgrade engine (update_engine). Therefore, after the OUC downloads the upgrade package from the OTA server, an upgrade instruction is issued to the upgrade engine, that is, step S207 is executed, so as to trigger the upgrade engine to start to execute the upgrade process, that is, the operation of the installation link described above.

In addition, it should be noted that, in order to ensure that the upgrade is successful, after the OUC downloads the upgrade package, the upgrade package may be checked first, for example, according to the size of the upgrade package recorded in the filelist.

Correspondingly, after the verification is successful, an upgrade instruction is sent to the upgrade engine.

It should be understood that the foregoing description is merely an example for better understanding of the method of upgrading an operating system provided in the embodiments of the present application, and is not intended to be the only limitation of the embodiments. The verification of the upgrade package may also be performed by the upgrade engine, which is not limited in this application.

With continued reference to fig. 20, the exemplary upgrade engine, after receiving the upgrade instruction, executes an upgrade procedure, specifically, reads an upgrade file of the upgrade package from the user data partition, and writes the upgrade file to the corresponding partition, that is, executes step S208.

In an exemplary embodiment, in a case where the electronic device is currently the data of the loaded first static partition, the upgrade engine may write the upgrade file of the corresponding static partition into the second static partition. For the dynamic partition, because the virtual AB system partition structure is a single partition, in order not to affect the field of view of the user On the electronic device in the upgrading process, copy-On-Write (COW) files of the sub-partitions in the corresponding dynamic partition can be created in the user data partition, and then the upgrading files of the sub-partitions in the corresponding dynamic partition are written into the corresponding COW files created in the user data partition, so that the installation of the upgrading files in the upgrading package is realized.

With continued reference to fig. 20, after the upgrade engine installs the upgrade file in the upgrade package, the upgrade engine informs that the OUC is installed, that is, executes step S209, so that when the OUC can update the current upgrade recorded in the filelist. Xml to an upgrade that needs to be restarted, the corresponding user interaction interface is refreshed according to the restart identifier (restart attribute value), and an option entry triggering restart is displayed in the interface, that is, executes step S210.

Accordingly, after displaying the option entry triggering the restart, if the user clicks on the option entry, the electronic device responds to the operation behavior and triggers the restart, i.e. step S211 is executed.

It should be noted that, before the upgrade engine informs the OUC that the installation is completed, the upgrade file written into the corresponding partition needs to be checked.

For example, in some implementations, the upgrade file corresponding to the static partition may be written into a sub-partition of the corresponding static partition, and after the upgrade file corresponding to the dynamic partition is written into the COW file corresponding to the user data partition, a verification process is triggered to sequentially verify the upgrade file written into the second static partition and the upgrade file written into the COW file corresponding to the user data partition.

Accordingly, after the upgrade files written into each sub-partition in the second static partition and the upgrade files written into each COW file corresponding to the user data partition are checked successfully, the upgrade engine may execute step S209.

In other implementations, for example, in order to increase the upgrade speed, after the upgrade file corresponding to the static partition is written into the sub-partition corresponding to the second static partition, a process parallel to the upgrade engine may be started, and during the process that the upgrade engine writes the upgrade file corresponding to the dynamic partition into each COW file, the process checks the upgrade file already written into the sub-partition in the second static partition, so that the process that the checksum of the upgrade file in the static partition writes the upgrade file corresponding to the dynamic partition into the corresponding COW file may be executed in parallel, thereby shortening the installation time.

With continued reference to fig. 20, the exemplary electronic device, in response to the restart instruction, the kernel will control the electronic device to be powered off and to be powered on again after the power off, trigger the electronic device to restart, and load an initialization process during the restart, i.e. execute step S212.

It should be noted that, because the electronic device is restarted from the first static partition and is operated to the first operating system, when the upgrade engine is installed, the electronic device will load the data of the base partition, the data of the second static partition, the data of the dynamic partition, and the data in the COW file in the user data partition in sequence after the electronic device is restarted, and then is started from the second static partition to be operated to the upgraded operating system, that is, the second operating system.

As can be seen from the description of the foregoing embodiments, in the method for upgrading an operating system provided in this embodiment, in the process of restarting an electronic device, a system service instantiates an attribute service, and runs the attribute service into an initialization process, that is, step S213 is executed.

In addition, based on steps S101 to S103 shown in fig. 7, the upgrade method of the operating system provided in this embodiment will not rely on the boot broadcast any more, but directly reads the pre-registered system restart attribute and the system restart attribute value (the value defaults to "false") from the global shared attribute file through the attribute service, and writes the read system restart attribute and the read system restart attribute value into the corresponding shared content in the form of a key value pair, that is, execute step S214, so that the OUC can directly execute the user interaction interface corresponding to the attribute according to the system restart attribute value "false" in the shared memory during the restart of the electronic device, and does not display the option entry triggering the restart, that is, execute step S215. The user interaction interface shown in connection with the above embodiment is, for example, to refresh the interface 10a in fig. 2 to the interface 10L in fig. 18, and the "immediately restart" option is not displayed, but the "check update" option is displayed. Therefore, after the electronic equipment is restarted, the refreshed user interaction interface is directly accessed. In this way, even if the user calls up the multi-task management interface after restarting the electronic device, the interface 10a shown in fig. 2 is not displayed in the multi-task management interface, but the interface 10L shown in fig. 18 is displayed, so that the user experience is ensured.

In addition, after the electronic equipment is restarted and the refreshed user interaction interface is entered, the kernel executes the Merge operation. It can be understood that the Merge operation specifically refers to writing an upgrade file corresponding to a dynamic partition stored in each COW file in the user data partition into the dynamic partition in the process of upgrading the operating system, so that the file of the dynamic partition completes data upgrade, and the electronic device can be started only by loading the data in the dynamic partition without loading the data in the dynamic partition and the COW file of the user data partition when the electronic device is started next time.

Correspondingly, after the Merge operation is completed, the upgrading of the operating system is formally finished. And if a new upgrade package is searched again, upgrading the operating system again according to the processing flow. It can be understood that in this process, the restart identifier recorded in the filelist. Xml corresponding to the new version upgrade package is written into the shared content through the attribute service, i.e. executed according to the processing logic of step S104 and step S105 in fig. 7.

Correspondingly, when the restart identifier indicates that the upgrade package is a cold patch butyl upgrade package or an OTA upgrade package, that is, the upgrade based on the new version upgrade package needs to be restarted, after the upgrade file in the new version upgrade package is installed, the OUC will trigger the restart again. Correspondingly, if the restart is not needed, after the upgrade file in the new version upgrade package is installed, the OUC refreshes the user interaction interface according to the restart identifier which does not need to be restarted. In particular, the processing logic of step S106 in fig. 7 may be referred to for execution.

It should be understood that the foregoing description is merely an example for better understanding of the method of upgrading an operating system provided in the embodiments of the present application, and is not intended to be the only limitation of the embodiments. In practical application, the upgrading process based on the upgrading method of the operating system provided by the embodiment of the application mainly focuses on the refreshing drawing part of the user interaction interface, such as the software updating interface, after the upgrading package is installed and the electronic equipment is restarted. For specific processing logic for this portion, reference may be made to the flow diagram of the operating system upgrade method illustrated in FIG. 21.

Referring to fig. 21, the method for upgrading an operating system provided in this embodiment specifically includes:

S301, displaying a first interface, wherein the first interface displays a first option for triggering restarting of the electronic equipment.

The first interface displayed at this time is, for example, the interface 10a in the above embodiment, that is, the electronic device has written the upgrade file in the upgrade package corresponding to the new version operating system obtained from the OTA server into the corresponding partition, where the partition structure of the read-only memory is the virtual AB system partition structure described above, and the electronic device is currently started from the first static partition and operates in the first operating system, where the electronic device processes the upgrade file in the upgrade package, for example, writes the upgrade file corresponding to the static partition into the second static partition, and writes the upgrade file corresponding to the dynamic partition into the corresponding COW file created in the user data partition.

Accordingly, when the interface displayed at this time is the interface 10a described in the above embodiment, the first option is, for example, the "immediately restart" option displayed in the interface 10 a.

In addition, as can be seen from the description of the foregoing embodiment, the display precondition of the interface 10a may be, for example, a manner of actively informing the electronic device that a new upgrade package exists according to the OTA server given in the above-mentioned package searching procedure. Specifically, based on the mode, the electronic equipment pops up a first prompt window in the second interface according to the received information of the new upgrade package, and displays a third option which triggers the electronic equipment to acquire the upgrade package and upgrade the operating system based on the upgrade package in the first prompt window.

Illustratively, in the present embodiment, the second interface is, for example, the interface 10b shown in the above-described embodiment. Accordingly, the first prompt window is, for example, the prompt window 10b-1 popped up in the interface 10b. Accordingly, the third option is, for example, the "download and install" option displayed in the prompt window 10b-1.

Correspondingly, after the user clicks the third option, the electronic equipment responds to clicking operation of the third option, obtains the upgrade package, and displays the first interface. It should be noted that, the first interface at this time may display the download progress information of the upgrade package, but does not display the first option. The first interface at this time can be regarded as the interface 10j described in the above embodiment, for example.

It can be understood that, for example, the file list description information (fileist. Xml) corresponding to the upgrade package may be acquired first. The file list description information records a download address of the upgrade package and a restart mark, wherein the restart mark is used for indicating that the upgrade of the operating system based on the upgrade package involves a restart link.

Accordingly, after the filelist xml is obtained, the electronic device may obtain the upgrade package from the download address recorded in the filelist xml to the user data partition of the electronic device. And then, according to the restart marker, updating the first restart attribute and the first restart attribute value stored in the shared memory into a second restart attribute and a second restart attribute value, wherein the second restart attribute value indicates that the electronic equipment needs to be restarted.

For specific implementation details of updating the first restart attribute and the first restart attribute value stored in the shared memory to the second restart attribute and the second restart attribute value by the electronic device, refer to step S104 and step S105 in the foregoing embodiments, which are not described herein again.

Correspondingly, after the upgrade package is successfully downloaded, the electronic equipment writes the upgrade file in the upgrade package into the corresponding partition, specifically, the upgrade package in the user data partition is analyzed to obtain the upgrade file in the upgrade package; writing the upgrade file of the corresponding static partition into the static partition, and writing the upgrade file of the corresponding dynamic partition into the dynamic partition.

In addition, it should be noted that, in the process of writing the upgrade file in the upgrade package into the corresponding partition, the electronic device will refresh the first interface. The method specifically comprises the steps of canceling downloading progress information displayed in a first interface, displaying installation progress information for writing an upgrade file in an upgrade package into a corresponding partition, and not displaying a first option. Illustratively, the refreshed first interface may be considered as interface 10k described in the above embodiments.

Accordingly, after the upgrade file in the upgrade package is installed, the electronic device will refresh the first interface again. Specifically, the installation progress information displayed in the first interface is canceled, and the first option is displayed. Illustratively, the refreshed first interface may be considered as interface 10a described in the above embodiments. Specific implementation details can be referred to step S106 of the above embodiment, and step S215 of the above embodiment, which are not described herein.

As can be seen from the description of the above embodiment, the restart identifier in the upgrade package indicating that the electronic device needs to be restarted is written into the corresponding shared content to replace the first restart attribute and the first restart attribute value (indicating that the electronic device does not need to be restarted) originally stored in the shared memory, for example, the two parameters are represented as the second restart attribute and the second restart attribute value (indicating that the electronic device needs to be restarted). In this way, after the electronic device executes the processing logic of the downloading link and the installation link, the electronic device acquires the second restarting attribute value corresponding to the second restarting attribute from the shared memory, refreshes the first interface according to the second restarting attribute value, cancels the installation progress information displayed in the first interface, and displays the first option.

The first restart attribute in this embodiment is, for example, a system restart attribute that is registered in advance in the attribute file in the above embodiment. Accordingly, the first restart attribute value is the system restart attribute value described in the above embodiment.

The second restart attribute, the second restart attribute value, and the third restart attribute value appearing below are restart attributes and restart attribute values obtained after updating the first restart attribute and the first restart attribute value in the shared memory according to a restart flag indicating that the electronic device is to be restarted recorded in a file corresponding to a new upgrade package obtained from the OTA server.

In addition, as can be seen from the description of the foregoing embodiment, the display premise of the interface 10a may also be, for example, a manner of manually triggering the searching according to the user given in the searching link, so as to upgrade the operating system. The interface 10b described in the above embodiment is still referred to as a second interface, and the second interface includes a first application, and the first application is integrated to launch the first interface portal.

Illustratively, the first application is, for example, a setup application shown in interface 10a, or an OUC application. For convenience of explanation, taking the first application as an example of the setup application, the above-mentioned start first interface entry is, for example, the "system and update" option displayed in the interface 10d described in the above-mentioned embodiment.

Specifically, based on such a manner of manual triggering by the user, when the user clicks on the first interface entry in the first application, the electronic device will display the first interface in response to the operation behavior. It will be appreciated that the second option is displayed in the first interface displayed at this time, and the first option is not displayed. Illustratively, the refreshed first interface may be considered as interface 10e described in the above embodiments.

Accordingly, when the user clicks on the second option, the electronic device will search for the upgrade package in response to the operation behavior. The specific reference may be made to the descriptions of step S201 to step S203 in the above embodiments, and the descriptions are omitted here.

Accordingly, the electronic device will refresh the first interface when it is searched that an upgrade package exists. The method specifically comprises the steps of canceling the second option displayed in the first interface, displaying a fourth option which triggers the electronic equipment to acquire an upgrade package and upgrades the operating system based on the upgrade package. Illustratively, the refreshed first interface may be considered as interface 10i described in the above embodiments, and the fourth option may be the "download and install" option shown in interface 10 i.

Correspondingly, after the user clicks the fourth option, the electronic device responds to the operation behavior to acquire the upgrade package and display a first interface, wherein the first interface displays the downloading progress information of the upgrade package and does not display the first option. The first interface at this time can be regarded as the interface 10j described in the above embodiment, for example.

Accordingly, after the upgrade package is downloaded successfully, the electronic device writes the upgrade file in the upgrade package into the corresponding partition. Meanwhile, in the process of writing the upgrade file in the upgrade package into the corresponding partition, the electronic equipment further refreshes the first interface, cancels the downloading progress information displayed in the first interface, displays the installation progress information of writing the upgrade file in the upgrade package into the corresponding partition, and does not display the first option. Illustratively, the refreshed first interface may be considered as interface 10k described in the above embodiments.

Correspondingly, after the upgrade file in the upgrade package is installed, the electronic equipment will refresh the first interface again, cancel the installation progress information displayed in the first interface, and display the first option. Illustratively, the refreshed first interface may be considered as interface 10a described in the above embodiments.

For specific implementation details of the electronic device obtaining the filelist.xml and the upgrade package, writing the upgrade file in the upgrade package into the corresponding partition, refreshing the first interface and displaying the first option, refer to step S201 to step S210 in the above embodiment.

S302, in response to clicking operation of the first option, restarting the electronic equipment is triggered to run from the first operating system before upgrading to the second operating system after upgrading.

For the specific implementation logic of the electronic device triggering the restart when the user clicks the first option, refer to step S211 and step S213 in the above embodiment, which are not described herein again.

S303, acquiring a first restarting attribute value set in the attribute file in the restarting process of the electronic equipment.

Specifically, during the restarting process of the electronic device, the first restarting property and the first restarting property value may be read from the property file, and the first restarting property value may be written into the shared memory in the form of a key value pair. For implementation details of this procedure, reference may be made to step S101 and step S102 in the above embodiment, and step S214 in the above embodiment, which are not described here again.

In addition, the attribute file in this embodiment is a global shared file stored in a read only memory. The first restart attribute value is a fixed value for indicating that the electronic device does not need to be restarted, e.g., defaulting to "false".

S304, refreshing the first interface according to the first restarting attribute value, canceling the first option displayed in the first interface, and displaying the second option triggering the electronic equipment to search the upgrade package.

Specifically, the electronic device acquires a first restarting attribute value corresponding to the first restarting attribute from the shared memory, refreshes the first interface according to the first restarting attribute value, cancels the first option displayed in the first interface, and displays the second option triggering the electronic device to search the upgrade package. For the implementation details of this procedure, reference may be made to step S103 in the above embodiment, which is not described herein again, and step S215 in the above embodiment, which is not described herein again.

In addition, after the electronic device is restarted and runs from the first operating system to the second operating system, if the user starts the automatic upgrade function in the automatic package searching mode or the electronic device starts the automatic upgrade function, the upgrade package corresponding to the third operating system is obtained or searched, that is, the upgrade package of the operating system after the update iteration is made for the second operating system, and the electronic device can firstly obtain the file list description information of the upgrade package corresponding to the third operating system according to the mode of obtaining the upgrade package corresponding to the second operating system.

Correspondingly, when the restart marker is recorded in the file list description information of the upgrade package corresponding to the third operating system, the first restart attribute and the first restart attribute value stored in the shared memory are updated to a third restart attribute and a third restart attribute value according to the restart marker, and the third restart attribute value indicates that the electronic equipment needs to be restarted. Specific reference may be made to step S104 and step S105 in the above embodiments, and details are not repeated here.

Correspondingly, after writing the upgrade file in the upgrade package corresponding to the third operating system into the corresponding partition, the electronic device refreshes the first interface according to the third restarting attribute value and displays the first option. The specific reference may be made to step S106 in the above embodiment and step S215 in the above embodiment, which are not described herein.

Therefore, a global shared and permanent restarting attribute is registered by using a global shared system attribute (SystemProperties), a fixed attribute value such as an attribute value "false" for identifying that restarting is not needed is set for the system restarting attribute, and then the attribute value of the system restarting attribute is directly read in the restarting process of the electronic equipment, and the function options to be displayed in the software updating interface are refreshed according to the attribute value, so that the options for triggering the electronic equipment to restart are not displayed in the software updating interface displayed in the multitask management interface, and better use experience is brought to users.

In addition, in order to implement the above-mentioned functions, the electronic device includes hardware and/or software modules that perform the respective functions. The steps of an algorithm for each example described in connection with the embodiments disclosed herein may be embodied in hardware or a combination of hardware and computer software. Whether a function is implemented as hardware or computer software driven hardware depends upon the particular application and design constraints imposed on the solution. Those skilled in the art may implement the described functionality using different approaches for each particular application in conjunction with the embodiments, but such implementation is not to be considered as outside the scope of this application.

In addition, it should be further noted that, in an actual application scenario, the method for upgrading an operating system provided in each embodiment implemented by an electronic device may also be executed by a chip system included in the electronic device, where the chip system may include a processor. The chip system may be coupled to a memory such that the chip system, when running, invokes a computer program stored in the memory, implementing the steps performed by the electronic device described above. The processor in the chip system can be an application processor or a non-application processor.

In addition, the embodiment of the application further provides a computer readable storage medium, and the computer storage medium stores computer instructions, which when executed on the electronic device, cause the electronic device to execute the related method steps to implement the method for upgrading the operating system in the embodiment.

In addition, the embodiment of the application further provides a computer program product, when the computer program product runs on the electronic device, the electronic device is caused to execute the related steps, so as to realize the upgrading method of the operating system in the embodiment.

In addition, embodiments of the present application also provide a chip (which may also be a component or module) that may include one or more processing circuits and one or more transceiver pins; the transceiver pin and the processing circuit communicate with each other through an internal connection path, and the processing circuit executes the related method steps to implement the upgrade method of the operating system in the above embodiment, so as to control the receiving pin to receive signals and control the transmitting pin to transmit signals.

In addition, as can be seen from the foregoing description, the electronic device, the computer-readable storage medium, the computer program product, or the chip provided in the embodiments of the present application are used to perform the corresponding methods provided above, and therefore, the advantages achieved by the method can refer to the advantages in the corresponding methods provided above, which are not repeated herein.

The above embodiments are merely for illustrating the technical solution of the present application, and not for limiting the same; although the present application has been described in detail with reference to the foregoing embodiments, it should be understood by those of ordinary skill in the art that: the technical scheme described in the foregoing embodiments can be modified or some technical features thereof can be replaced by equivalents; such modifications and substitutions do not depart from the spirit of the corresponding technical solutions from the scope of the technical solutions of the embodiments of the present application.

Claims

1. An upgrade method of an operating system, applied to an electronic device, the method comprising:

displaying a first interface, wherein the first interface displays a first option for triggering the restarting of the electronic equipment;

triggering the electronic equipment to restart in response to clicking operation of the first option so as to run from a first operating system before upgrading to a second operating system after upgrading;

acquiring a first restarting attribute value set in the attribute file in the restarting process of the electronic equipment; wherein the attribute file is a global shared file stored in a read-only memory; the first restarting attribute value is a fixed value and is used for indicating that the electronic equipment does not need to be restarted;

And refreshing the first interface according to the first restarting attribute value, canceling the first option displayed in the first interface, and displaying a second option triggering the electronic equipment to search an upgrade package.

2. The method of claim 1, wherein the obtaining, during the rebooting of the electronic device, the first reboot attribute value set in the attribute file comprises:

reading a first restarting attribute and a first restarting attribute value from the attribute file in the restarting process of the electronic equipment;

and writing the first restarting property and the first restarting property value into a shared memory in the form of a key value pair.

3. The method of claim 2, wherein refreshing the first interface, cancelling the first option displayed in the first interface, displaying a second option triggering the electronic device to search for an upgrade package, according to the first restart attribute value, comprises:

and acquiring the first restarting attribute value corresponding to the first restarting attribute from the shared memory, refreshing the first interface according to the first restarting attribute value, canceling the first option displayed in the first interface, and displaying a second option triggering the electronic equipment to search an upgrade package.

4. A method according to claim 2 or 3, wherein the displaying a first interface, the first interface displaying a first option triggering a reboot of the electronic device, comprises:

displaying a second interface, wherein the second interface comprises a first prompt window, and a third option for triggering the electronic equipment to acquire an upgrade package and upgrading an operating system based on the upgrade package is displayed in the first prompt window;

responding to clicking operation of the third option, acquiring the upgrade package, and displaying the first interface, wherein the first interface displays the downloading progress information of the upgrade package and does not display the first option;

after the upgrade package is successfully downloaded, writing an upgrade file in the upgrade package into a corresponding partition;

refreshing the first interface in the process of writing the upgrade file in the upgrade package into the corresponding partition, canceling the downloading progress information displayed in the first interface, displaying the installation progress information of writing the upgrade file in the upgrade package into the corresponding partition, and not displaying the first option;

after the upgrade file in the upgrade package is installed, refreshing the first interface, canceling the installation progress information displayed in the first interface, and displaying the first option.

5. The method of claim 4, wherein the obtaining an upgrade package comprises:

acquiring file list description information corresponding to the upgrade package, wherein the file list description information records a download address and a restarting mark of the upgrade package, and the restarting mark is used for indicating that the upgrade of the operating system based on the upgrade package involves a restarting link;

acquiring the upgrade package from the download address to a user data partition of the electronic equipment;

and updating the first restarting property and the first restarting property value stored in the shared memory into a second restarting property and a second restarting property value according to the restarting mark, wherein the second restarting property value indicates that the electronic equipment needs restarting.

6. The method of claim 5, wherein after the upgrade file in the upgrade package is installed, refreshing the first interface, canceling the installation progress information displayed in the first interface, and displaying the first option, comprises:

and after the installation of the upgrade file in the upgrade package is finished, acquiring the second restarting attribute value corresponding to the second restarting attribute from the shared memory, refreshing the first interface according to the second restarting attribute value, canceling the installation progress information displayed in the first interface, and displaying the first option.

7. The method of claim 5, wherein writing the upgrade file in the upgrade package to the corresponding partition comprises:

analyzing the upgrade package in the user data partition to obtain an upgrade file in the upgrade package;

writing the upgrade files of the corresponding static partition into the static partition, and writing the upgrade files of the corresponding dynamic partition into the dynamic partition.

8. A method according to claim 2 or 3, wherein the displaying a first interface, the first interface displaying a first option triggering a reboot of the electronic device, comprises:

displaying a second interface, wherein the second interface comprises a first application, and the first application integrates the starting of the first interface inlet; before the upgrade package is not acquired, the first option is not displayed in the first interface started by the first application;

responding to clicking operation for starting the first interface entry in the first application, displaying the first interface, wherein the first interface displays the second option and does not display the first option;

searching the upgrade package in response to clicking operation of the second option;

Refreshing the first interface when the presence of the upgrade package is searched, canceling the second option displayed in the first interface, displaying a fourth option triggering the electronic equipment to acquire the upgrade package, and upgrading an operating system based on the upgrade package;

responding to clicking operation of the fourth option, acquiring the upgrade package, and displaying the first interface, wherein the first interface displays the downloading progress information of the upgrade package and does not display the first option;

9. A method according to any one of claims 1 to 3, wherein after the electronic device is restarted, running from the first operating system to the second operating system, the method further comprises:

After searching an upgrade package corresponding to a third operating system, acquiring file list description information of the upgrade package corresponding to the third operating system;

when a restart marker is recorded in file list description information of an upgrade package corresponding to the third operating system, updating the first restart attribute and the first restart attribute value stored in a shared memory into a third restart attribute and a third restart attribute value according to the restart marker, wherein the third restart attribute value indicates that the electronic equipment needs to be restarted.

10. The method according to claim 9, wherein the method further comprises:

after the upgrade files in the upgrade package corresponding to the third operating system are written into the corresponding partition, refreshing the first interface according to the third restarting attribute value, and displaying the first option.

11. An electronic device, the electronic device comprising: a memory and a processor, the memory and the processor coupled; the memory stores program instructions that, when executed by the processor, cause the electronic device to perform the operating system upgrade method of any one of claims 1 to 10.

12. A computer readable storage medium comprising a computer program which, when run on an electronic device, causes the electronic device to perform the method of upgrading an operating system according to any of claims 1 to 10.