CN113821234B

CN113821234B - Operating system upgrade method, apparatus, storage medium, and computer program product

Info

Publication number: CN113821234B
Application number: CN202110662020.5A
Authority: CN
Inventors: 王艳召; 陈超; 黄九林; 张赠辉
Original assignee: Honor Device Co Ltd
Current assignee: Honor Device Co Ltd
Priority date: 2021-06-15
Filing date: 2021-06-15
Publication date: 2023-01-03
Anticipated expiration: 2041-06-15
Also published as: CN113821234A

Abstract

The method is applied to electronic equipment, a first operating system is installed on the electronic equipment, the first operating system comprises a first upgrading application, the first upgrading application is an application needing to be operated in the process of upgrading the first operating system, and the method comprises the following steps: acquiring a system upgrading installation package, wherein the system upgrading installation package comprises system upgrading data and a second upgrading application, the system upgrading data is used for upgrading the first operating system, and the second upgrading application is an updated version of the first upgrading application; upgrading the first operating system based on the system upgrade data, wherein: and in the process of upgrading the first operating system, when the first upgrading application needs to be operated, operating the second upgrading application. According to the method, smooth execution of the upgrading operation of the operating system can be ensured when data errors occur in the application for upgrading the operating system, and therefore the running stability of the system is greatly improved.

Description

Operating system upgrading method, operating system upgrading device, operating system storage medium and computer program product

Technical Field

The present application relates to the field of computer technologies, and in particular, to a method, an apparatus, a storage medium, and a computer program product for upgrading an operating system.

Background

In the application scenario of the prior art, the user terminal needs to install the operating system to be available to the user. For example, a mobile phone operating system (e.g., an IOS system, an android system) needs to be installed on the mobile phone to be used by the user.

After the operating system is installed on the terminal device, when the version of the operating system is upgraded, the operating system installed on the terminal device needs to be upgraded. Generally, the process of upgrading the operating system is that an operating system updating program installed on the device obtains an operating system upgrade installation package (network download or copy through a mobile storage medium), and the operating system updating program upgrades the operating system on the device according to the operating system upgrade installation package.

However, in some application scenarios, the operating system update program installed on the device may experience data errors, thereby causing the operating system update program to fail to complete the operating system upgrade. Therefore, there is a need for an operating system upgrade method to ensure smooth execution of an operating system upgrade operation when an operating system update program is faulty.

Disclosure of Invention

In view of this, the present application provides an operating system upgrading method, an operating system upgrading device, a storage medium, and a computer program product, so as to solve the problem that an operating system cannot be upgraded when an operating system updating program fails in the prior art.

In a first aspect, an embodiment of the present application provides a method for upgrading an operating system, which is applied to an electronic device, where a first operating system is installed on the electronic device, the first operating system includes a first upgrade application, and the first upgrade application is an application that needs to be run in a process of upgrading the first operating system, and the method includes:

acquiring a system upgrading installation package, wherein the system upgrading installation package comprises system upgrading data and a second upgrading application, the system upgrading data is used for upgrading the first operating system, and the second upgrading application is an updated version of the first upgrading application;

upgrading the first operating system based on the system upgrade data, wherein:

and in the process of upgrading the first operating system, when the first upgrading application needs to be operated, operating the second upgrading application.

In an implementation manner of the first aspect, the first operating system further includes a third upgrade application, where the first upgrade application is configured to obtain the system upgrade installation package and start the third upgrade application after obtaining the system upgrade installation package, and the third upgrade application is configured to upgrade the first operating system based on the system upgrade installation package;

the obtaining of the system upgrade installation package comprises starting the first upgrade application and obtaining the system upgrade installation package based on the first upgrade application;

the upgrading the first operating system based on the system upgrade data includes:

searching, by the first upgrade application, the system upgrade installation package for the second upgrade application;

when the system upgrading installation package further comprises a second upgrading application, starting the second upgrading application by the first upgrading application;

launching, by the second upgraded application, the third upgraded application;

upgrading, by the third upgrade application, the first operating system based on the system upgrade installation package.

In an implementation manner of the first aspect, the starting, by the first upgraded application, the second upgraded application includes:

the first upgrading application starts the second upgrading application;

and the first upgrading application endows the operation authority of the first upgrading application to the second upgrading application.

In an implementation manner of the first aspect, the first upgraded application starts the second upgraded application, where a process of the first upgraded application duplicates a new sub-process, and the second upgraded application is run on the new sub-process.

In an implementation manner of the first aspect, the first upgrade application is an upgrade package acquisition tool, and the third upgrade application is an upgrade engine.

In an implementation manner of the first aspect, the first operating system further includes a third upgrade application, where the third upgrade application is configured to obtain the system upgrade installation package and start the first upgrade application after obtaining the system upgrade installation package, and the first upgrade application is configured to upgrade the first operating system based on the system upgrade installation package;

the obtaining of the system upgrade installation package comprises starting the third upgrade application and obtaining the system upgrade installation package based on the third upgrade application;

the upgrading the first operating system based on the system upgrade data comprises:

launching, by the third upgraded application, the first upgraded application;

upgrading, by the second upgrade application, the first operating system based on the system upgrade installation package.

starting the first upgrading application;

searching the second upgrading application in the system upgrading installation package when the first upgrading application fails to be started;

when the system upgrading installation package further comprises a second upgrading application, starting the second upgrading application;

In an implementation manner of the first aspect, the third upgrade application is an upgrade package obtaining tool, and the first upgrade application is an upgrade engine.

In a second aspect, the present application further provides an electronic device, where the electronic device includes a processor and a memory, a first operating system is installed on the memory, the first operating system includes a first upgrade application, the first upgrade application is an application that needs to be run in the process of upgrading the first operating system, and the processor is configured to execute a software code stored in the memory, so that the electronic device executes the method flow according to the first aspect.

In a third aspect, the present application also provides a computer readable storage medium having stored thereon a computer program which, when run on a computer, causes the computer to perform the method according to the first aspect.

In a fourth aspect, the present application also provides a computer program product comprising a computer program which, when run on a computer, causes the computer to perform the method according to the first aspect.

According to the technical scheme provided by the embodiment of the application, at least the following technical effects can be realized:

according to the method, smooth execution of the upgrading operation of the operating system can be ensured when data errors occur in the application for upgrading the operating system, and therefore the running stability of the system is greatly improved.

Drawings

In order to more clearly illustrate the technical solutions of the embodiments of the present application, the drawings required to be used in the embodiments will be briefly described below, and it is obvious that the drawings in the following description are only some embodiments of the present application, and it is obvious for those skilled in the art that other drawings can be obtained according to the drawings without creative efforts.

FIG. 1 is a diagram illustrating a data storage structure according to an embodiment of the present application;

FIG. 2 is a flow chart illustrating an operating system upgrade;

FIG. 3 is a schematic diagram of an application scenario for upgrading an operating system according to an embodiment of the present application;

FIG. 4 is a schematic diagram of an application scenario for upgrading an operating system according to an embodiment of the present application;

FIG. 5 is a flow diagram illustrating an operating system upgrade according to an embodiment of the present application;

FIG. 6 is a schematic diagram of an application scenario for upgrading an operating system according to an embodiment of the present application;

FIG. 7 is a flowchart illustrating an operating system upgrade according to an embodiment of the present application;

FIG. 8 is a flowchart illustrating an operating system upgrade according to an embodiment of the present application.

Detailed Description

For better understanding of the technical solutions of the present application, the following detailed descriptions of the embodiments of the present application are provided with reference to the accompanying drawings.

It should be understood that the embodiments described are only a few embodiments of the present application, and not all embodiments. All other embodiments, which can be derived by a person skilled in the art from the embodiments given herein without making any creative effort, shall fall within the protection scope of the present application.

The terminology used in the embodiments of the present application is for the purpose of describing particular embodiments only and is not intended to be limiting of the application. As used in the examples of this application and the appended claims, the singular forms "a", "an", and "the" are intended to include the plural forms as well, unless the context clearly indicates otherwise.

It should be understood that the term "and/or" as used herein is merely one type of associative relationship that describes an associated object, meaning that three types of relationships may exist, e.g., A and/or B, may mean: a exists alone, A and B exist simultaneously, and B exists alone. In addition, the character "/" herein generally indicates that the former and latter related objects are in an "or" relationship.

In the application scenario of the prior art, the user terminal needs to install the operating system to be available to the user. For example, a mobile phone operating system (e.g., an IOS system, an android system) needs to be installed on a mobile phone to be used by a user.

Fig. 1 is a schematic diagram of a data storage structure according to an embodiment of the present application. As shown in FIG. 1, the android system data storage area includes a base partition (Common), a static partition (A), a static partition (B), a dynamic partition (Super), and a user data partition (Userdata).

The user data partition (Userdata) is used for storing personal data of users, such as personal data of APPs installed by the users, pictures, documents and videos stored by the users. The data stored in the base portion is system data that does not participate in the upgrade of the operating system. The static partition (a) and the static partition (B) have structures corresponding to each other, and the subpartition names are distinguished from each other by suffixes _ a and _ B. For example, the static partition (a) includes bootloader _ a, boot _ a, vendor _ boot _ a, dtbo _ a, vbmeta _ a; the static partition (B) includes bootloader _ B, boot _ B, vendor _ boot _ B, dtbo _ B, vbmeta _ B. The dynamic partition (Super) comprises a plurality of sub-partitions (System, system _ ext, vendor, product, cust, odm).

At device boot, it boots from a static partition. For example, the device starts from the static partition (a): sequentially loading a basic partition (Common), a static partition (A) and a dynamic partition (Super); the device starts from the static partition (B): the basic partition (Common), the static partition (B) and the dynamic partition (Super) are loaded in sequence.

Take Universal Flash Storage (UFS) in Master Boot Record (MBR) format as an example. In the MBR of the UFS (main boot sector, first sector of the UFS, i.e. 0 cylinder 0 head 1 sector of the C/H/S address), a device boot sequence description is saved, e.g. booted from the static partition (a) (boot sequence flag is a) or booted from the static partition (B) (boot sequence flag is a). After the device is started, the device start sequence is first read from the MBR of the UFS.

FIG. 2 is a flowchart illustrating an operating system upgrade performed on the operating system data storage structure of the embodiment shown in FIG. 4, where when a device is currently booted from a static partition (A), the device implements the upgrade of the operating system according to the flowchart shown in FIG. 2.

S200, the device loads a basic partition (Common), a static partition (A) and a dynamic partition (Super) in sequence and starts from the static partition (A).

S210, the equipment acquires an operating system upgrade installation package.

For example, in a possible implementation scheme, the device periodically initiates a packet searching request to the packet searching server, where the packet searching request includes a version number (e.g., version 1.1) of an operating system currently running by the device; the packet searching server searches whether an operating system installation packet (such as version 1.2) with an updated version number exists at present according to the operating system version number in the packet searching request; when the operating system installation package with the updated version exists, the package searching server feeds back a download address of the operating system upgrading installation package (for example, a system increment upgrading installation package upgraded from version 1.1 to version 1.2) to the equipment; the equipment downloads the operating system upgrading installation package according to the downloading address of the operating system upgrading installation package, and stores the operating system upgrading installation package into a user data partition (Userdata).

And S220, the equipment performs data writing operation on the static partition (B) according to the operating system upgrading installation package so as to upgrade the static partition.

For example, the system incremental upgrade installation package with version 1.1 upgraded to version 1.2 contains the full amount of data of the static partition of version 1.2, and the device overwrites the data of the static partition of version 1.2 in the static partition (B).

And S230, the equipment creates a virtual dynamic partition in a user data partition (Userdata) according to the operating system upgrading installation package, and writes upgrading data of the dynamic partition (Super) into the virtual dynamic partition. For example, the data of the dynamic partition of version 1.2 is contained in the operating system upgrade installation package, and the device writes the data of the dynamic partition (Super) of version 1.2 in the virtual dynamic partition.

Further, in the virtual A/B upgrade scheme, an incremental upgrade mode is adopted for dynamic partitions (Super). In the upgrading process, all files of the dynamic partition (Super) of the new version after upgrading are not stored in the virtual dynamic partition of the user data partition (Userdata), but the upgrading result of the data which needs to be upgraded in the dynamic partition (Super) of the old version after upgrading is stored in the virtual dynamic partition of the user data partition (Userdata). That is, the virtual dynamic partition of the user data partition (Userdata) stores therein update data of the dynamic partition.

Taking a system sub-partition as an example, suppose that in version 1.1, data in the system sub-partition can be divided into two parts, system1 and system 2. And upgrading from version 1.1 to version 1.2, the data system2 is not changed, and the data system1 is upgraded to system3. Then, in S230, the device creates a virtual dynamic partition in the user data partition (Userdata), and writes the data system3 in the virtual dynamic partition.

For example, a system incremental upgrade installation package with version 1.1 upgraded to version 1.2 contains dynamic partition (Super) update data with version 1.1 upgraded to version 1.2, which contains data system3.

Further, in the virtual a/B upgrade scheme, incremental upgrade of dynamic partitions (Super) is implemented based on snapshot technology (snapshot). Specifically, in a virtual dynamic partition of a user data partition (Userdata), a Copy-On-Write (COW) file is used to store upgrade data of a dynamic partition (Super).

Specifically, the upgrade data of the dynamic partition (Super) stored in the user data partition (Userdata) includes a plurality of COW files, each COW file corresponds to a sub-partition of the dynamic partition (Super), and the name of the COW file corresponds to the sub-partition of the dynamic partition (Super).

In the os upgrade installation package obtained in S210, the COW file of the upgrade data of the dynamic partition (Super) is compressed and stored in the form of binary code. In the operating system upgrade installation package, each COW file is named according to the dynamic partition (Super) child partition to which it is directed. For example, the COW file for the system sub-partition is named system-COW-img.img.0000.

In S230, the device unpacks the os upgrade installation package to obtain all the COW files, and attaches a/B partition flags to each COW file. Specifically, when the device is currently started from the static partition (a), it can be understood that the dynamic partition (Super) loaded by the device currently running the operating system is the dynamic partition (a). When the operating system is upgraded, the virtual dynamic partition created in the user data partition (Userdata) is for the dynamic partition (B). Therefore, the name flag _ B corresponding to the dynamic partition (B) is attached to the COW file. For example, system _ b-cow-img.img.0000 is generated for system-cow-img.0000 to attach _ b.

Further, in S230, an Update folder is created in the user data partition (Userdata), and the renamed COW file is saved under the Update folder. For example, in an application scenario, after writing a COW file into a user data partition (Userdata), the Update folder of the user data partition (Userdata) contains the following files:

system_b-cow-img.img.0000；

system_ext_b-cow-img.img.0000；

vendor_b-cow-img.img.0000；

product_b-cow-img.img.0000；

cust_b-cow-img.img.0000；

odm_b-cow-img.img.0000。

specifically, the COW file includes a COW file map (snapshot map) of the COW file itself and upgrade data. The COW file map (snapshot) corresponds to a file map of a sub-partition of the dynamic partition (Super) to which the COW file is directed. The file map of the sub-partition of the dynamic partition (Super) is used for describing all files in the sub-partition of the dynamic partition (Super) of the operating system of the current version (the version before the upgrade is performed, for example, version 1.1) and the storage addresses of the files.

The upgrading data in the COW file is a file which is updated in the sub-partition data of the new version compared with the sub-partition data of the current version; the COW file map of the COW file is used for describing the corresponding relation between the updated file and the file in the current version of the sub-partition and the storage address of the updated file.

Based on the file map of the sub-partition of the dynamic partition (Super) and the COW file map in the COW file, the upgrade data in the COW file can be used for replacing the corresponding file in the sub-partition of the dynamic partition (Super), so that the upgrade of the data of the dynamic partition (Super) is realized. Specifically, when the file map of the sub-partition of the dynamic partition (Super) needs to be acquired, the snapshot operation may be performed on the data of the sub-partition of the dynamic partition (Super) based on the snapshot to generate the file map of the sub-partition of the dynamic partition (Super). Or, when the operating system upgrade installation package is manufactured, a file map of a sub-partition of a dynamic partition (Super) may be generated in advance, and the file map may be added to the COW file.

Taking a system sub-partition as an example, suppose that the system sub-partition stores data according to the following path:

/system/app/A0.XXX；

/system/app/A1.XXX；

/system/app/A2.XXX；

/system/B0.XXX；

/system/B1.XXX；

/system/user/C0.XXX；

/system/user/C1.XXX；

/system/user/C2.XXX；

/system/user/C3.XXX。

the file map for a system sub-partition may be:

/system/app/A0.XXX：024010～024013；

/system/app/A1.XXX：024014～024017；

/system/app/A2.XXX：024018～024020；

/system/B0.XXX：024021～024026；

/system/B1.XXX：024027～024028；

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

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

/system/user/C2.XXX：024036～024040；

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

the value after the file name (e.g.,/system/app/A0.XXX: 024010-024013 of 024010-024013) is the physical storage address (block address) of the file in the system sub-partition of the dynamic partition (Super).

Assume that the current operating system upgrade requires updating data/system/app/A2. XXX and/system/user/C2. XXX.

Can be regarded as:

system/app/A2.XXX and system/user/C2.XXX are system1 parts of system sub-partition data;

system/app/A0.XXX,/system/app/A1.XXX,/system/B0.XXX,/system/B1.XXX,/system/user/C0.XXX,/system/user/C1.XXX, and/system/user/C3.XXX are the system2 portions of system sub-partition data.

Then the COW file for the system sub-partition (system _ b-COW-img.img.0000) contains the latest version/system/app/A2.XXX and/system/user/C2.XXX.

It can be seen that the latest version/system/app/A2. XXX and/system/user/C2. XXX is system3. The upgrade target is to update system1 with system3.

When the size of the update data in the COW file is consistent with the size of the original data to be updated, and the storage location of the update data in the COW file in the sub-partition after the data update is consistent with the storage location of the original data to be updated in the sub-partition, the COW file map of the COW file (system _ b-COW-img.img.0000) itself may be:

/system/app/A2.XXX：

map1 (address of data to be updated in original super partition): start address start:024018 (offset from system start address); offset size:2 (namely, data of 024018-024020 address field)

Map2 (address of update data stored in cow file): start address start:045033 (offset from the start address of the cow file storage); offset size:2 (i.e., data for address fields 045033-045035);

/system/user/C2.XXX：

map1 (address of data to be updated in original super partition): start address start:024036 (offset from system start address); offset size:4 (namely the data of 024036-024040 address segment)

Map2 (address of update data stored in cow file): start address start:045036 (offset from the start address stored by the cow file); offset size:4 (i.e., data in the 045036 to 045040 address fields).

When the size of the update data in the COW file is not consistent with the size of the original data to be updated, the COW file map of the COW file (system _ b-COW-img.img.0000) itself may be:

/system/app/A2.XXX：

map1.1 (address of data to be updated in original super partition): start address start:024018 (offset from system start address); offset size:2 (namely the data of 024018-024020 address field)

Map2.1 (the address of the update data stored in the cow file that needs to cover the Map1.1 address): start address start:045033 (offset from the start address of the cow file storage); offset size:2 (i.e., data for address fields 045033 to 045035);

map1.2 (address to be written in the original super partition of the part of the update data in the cow file exceeding the size of the data to be updated): start address start:025018 (offset from the system start address); offset size:1 (i.e., data of 025018-025020 address segment)

Map2.2 (the address of the update data stored in the cow file that needs to cover the Map1.2 address): start address start:046033 (offset from the start address stored by the cow file); offset size:2 (i.e., data of address segments 046033-046035).

In the description of the specification that follows, for convenience of description, an application scenario will be illustrated only when the size of the update data in the COW file coincides with the size of the original data to be updated, and the storage location of the update data in the COW file after data update in the sub-partition coincides with the storage location of the original data to be updated in the sub-partition.

In the above example, the address fields (045033 to 045035 and 045036 to 045040) are the physical storage addresses (block addresses) of the latest version/system/app/a 2.Xxx and/system/user/c 2.Xxx in the user data partition (Userdata) in the COW file (system _ b-COW-img.img.0000), respectively.

Thus, if A2.XXX at addresses 024018-024020 is replaced by A2.XXX at addresses 045033-045035, and C2.XXX at addresses 024036-024040 is replaced by C2.XXX at addresses 045036-045040, the data upgrade of the system sub-partition of dynamic partition (Super) can be completed.

Further, in S230, after the COW file is written into the user data partition (Userdata), the dynamic partition (Super) + COW file needs to be integrally checked, validity of the dynamic partition (Super) + COW file is checked, and it is verified whether a synthesis result of the current version of the dynamic partition (Super) data + the COW file is new version of the dynamic partition (Super) data.

Specifically, taking upgrading from the 1.1 version to the 1.2 version as an example, calculating a hash value of a synthesis result of data (data which does not change from the 1.1 version to the 1.2 version) which does not need to be upgraded in the dynamic partition (Super) and upgrading data (data which needs to be upgraded from the 1.1 version to the 1.2 version) in the COW file, judging whether the hash value is consistent with a hash value of complete data of the dynamic partition (Super) in the 1.2 version, and if so, indicating that the COW file is valid; if not, indicating that the COW file is invalid and the upgrading fails, interrupting the upgrading process and reporting errors; wherein, the hash value of the complete data of the dynamic partition (Super) in the 1.2 version is stored in the operating system upgrade installation package.

Specifically, in the checking process, dynamic partitions (Super) + COW files are merged based on snapshot. In the implementation process of the snapshot, the combination of the dynamic partition (Super) and the COW file is not physically combined, but the whole file map of the sub-partition in the COW file is combined with the COW file map of the COW file, so that the file map of the sub-partition data of a new version is generated.

For example, a file map that sub-partitions the system:

/system/app/A0.XXX：024010～024013；

/system/app/A1.XXX：024014～024017；

/system/app/A2.XXX：024018～024020；

/system/B0.XXX：024021～024026；

/system/B1.XXX：024027～024028；

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

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

/system/user/C2.XXX：024036～024040；

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

and COW file map:

/system/app/A2.XXX：

map1: address start:024018; size:2 (namely the data of 024018-024020 address field)

Map2: address start:045033; size:2 (i.e., data for address fields 045033-045035);

/system/user/C2.XXX：

map1: address start:024036; size:4 (namely the data of 024036-024040 address segment)

Map2: address start:045036; size:4 (i.e., data in the 045036 to 045040 address fields).

And (6) merging. Then get the new version of the file map for the system sub-partition:

/system/app/A0.XXX：024010～024013；

(Direction to dynamic partitioning (Super) in/under System/app A0.XXX)

/system/app/A1.XXX：024014～024017；

(Direction to dynamic partitioning (Super) in/under System/app A1.XXX)

/system/app/A2.XXX：045033～045035；

(points to A2.XXX in user data partition (Userdata)/Update/system _ b-cow-img.img.0000)

/system/B0.XXX：024021～024026；

(Direction dynamic partitioning (Super) Medium/under system B0.XXX)

/system/B1.XXX：024027～024028；

(Direction dynamic zoning (Super) in/under system B1. XXX)

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

(C0.XXX in directed dynamic partitioning (Super) in/under system/user)

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

(Direction dynamic partitioning (Super) Medium/System/user under C1.XXX)

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

(points to C2.XXX in user data partition (Userdata)/Update/system _ b-cow-img. 0000)

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

(C3.XXX under Directional dynamic partitioning (Super) Medium/System/user)

In the file map of the new version of the system sub-partition, the save address of/system/app/A2. XXX points not to/system/app/A2. XXX on the dynamic partition on memory (Super), but to A2.XXX in system _ b-cow-img.img.0000 in the user data partition on memory (Userdata); the save address of/system/user/C2. XXX does not point to/system/user/C2. XXX on the dynamic partition (Super) on memory, but to C2.XXX in system _ b-cow-img.img.0000 in the user data partition (Userdata) on memory.

In the verification process, according to the synthesis mode, obtaining new version file maps of all sub-partitions of the dynamic partition (Super) (if the corresponding COW file of a certain sub-partition is not written in the user data partition (user data), directly taking the file map of the sub-partition as the new version file map). And combining the new versions of the file maps of all the sub partitions to generate a new version of a file system of a dynamic partition (Super).

Reading data based on the file system of the new version of the dynamic partition (Super), reading all files contained in the file system of the new version of the dynamic partition (Super) and calculating a hash value.

When the COW file is valid, the disk-down status information in the metadata partition (/ metadata) of the base partition (Common) is changed from "dropped disk (merged)" to "not dropped disk (wait for merge)". The landing status information is used to indicate whether there is a COW file currently requiring landing to a dynamic partition (Super). Specifically, the landing status information includes an overall identification for dynamic partitions (Super) and a sub-partition identification for each sub-partition. When the whole is marked as 'fallen disk (merged'), all the sub-partitions representing the dynamic partition (Super) do not need to carry out the fallen disk operation; when the whole is marked as 'not-dropped-disk (wait for merge'), one or more sub-partitions representing dynamic partitions (Super) need to be subjected to a disk-dropping operation; when the sub-partition is identified as 'fallen disk (merged'), it represents that the sub-partition does not need to carry out the fallen disk operation; when a sub-partition is identified as "wait for merge", it represents that the sub-partition needs to perform a disk-dropping operation.

S231, the starting sequence of the equipment is changed from the starting of the static partition (A) to the starting of the static partition (B).

For example, the Boot sequence flag of the Master Boot Record (MBR) is rewritten, and the Boot sequence flag is rewritten from a to B. After the equipment is powered on, when the equipment reads that the starting sequence identifier is A, the equipment is started from the static partition (A), and the static partition (A) is loaded in the starting process; when the device reads that the starting sequence identifier is B, the device starts from the static partition (B), and the static partition (B) is loaded in the starting process.

And S232, restarting the equipment. And exiting the current operating system, cutting off the power supply of the equipment, and starting the power supply of the equipment again.

S240, the device loads the basic partition (Common) and the static partition (B) in sequence.

S241, the device loads the virtual dynamic partitions of the dynamic partition (Super) and the user data partition (Userdata).

Specifically, the device reads the disk-dropping state information in the metadata (/ metadata), determines whether a COW file needs to be retrieved from a specified path of the user data partition (Userdata) or not based on the disk-dropping state information, and loads a dynamic partition (Super) and the COW file by using snapshot merging.

Further, in S241, the device does not load all COW files in the dynamic partition (Super) and the user data partition (Userdata), but loads corresponding files according to the operating system running requirement. Specifically, in S241, the device determines a file to be loaded according to an operating system operation requirement, and extracts a corresponding file from a COW file in a dynamic partition (Super) or a virtual dynamic partition based on a snapshot to load the file.

Specifically, in S241, when the corresponding COW file first exists in the sub-partition of the dynamic partition (Super), a new version of the file map of each sub-partition of the dynamic partition (Super) is generated based on the snapshot. The process of generating a new version of the file map may refer to S230. The device determines files needing to be loaded according to the operation requirements of the operating system, and loads the files based on a new version file map of a dynamic partition (Super) sub-partition.

For example, an operating system runtime requires loading all data in a directory user (/ system/user) under a system sub-partition. The device reads the disk-dropping state information in the metadata (/ metadata), wherein the child partition identification of the system child partition in the disk-dropping state information is 'disk-not-dropped (merge)', therefore, the device searches the COW file in the user data partition (Userdata)/Update under the Update, searches the COW file system _ b-COW-img.img.0000 under the Update, and generates a new version file map of the system child partition according to the file map of the COW file in the system _ b-COW-img.img.0000 based on the snapshot. And loading data according to the storage addresses of all files in the new version file map of the system sub-partition/under the system/user, for example, according to the storage addresses of all files in the new version file map of the system sub-partition:

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

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

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

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

C0.XXX at the addresses 024029-024032, C1.XXX at the addresses 024033-024035, C2.XXX at the addresses 045036-045040, and C3.XXX at the addresses 024041-024044 are loaded.

Further, when all data in the directory user (/ system/user) under the system sub-partition is loaded, when the sub-partition of the system sub-partition is identified as "landed" in the landing state information, the device does not search the COW file in the user data partition (Userdata)/under Update, but directly loads all data in the directory user (/ system/user) under the system sub-partition.

Further, when all data in a user (/ system/user) under the system sub-partition is loaded, when the sub-partition of the system sub-partition in the disk-down status information is identified as "no disk-down (wait for means)", if the device does not search a COW file of the corresponding system sub-partition in the user data partition (user data)/under the Update, it indicates that the data write error (a COW file write error or a disk-down status information write error) occurs in the upgrade process, and the device rolls back the system and reports the error at this time.

Further, in S241, before loading the file, the device needs to check the loaded file. Unlike S230, in S241, the dynamic partition (Super) + COW file is not verified in its entirety, but only files that need to be loaded are verified. For example, checking is performed based on dmverity (dm-verity is a target (target) of dm (device map), which is a virtual block device, dedicated to checking of a file system). And if the verification is successful, loading the file, and if the verification is failed, restarting the equipment, rolling back the system or trying to load the file again.

And S250, successfully starting the equipment, and entering a user interaction interface.

S251, the device diskettes the data of the virtual dynamic partition to the dynamic partition (Super).

In the description of the present application, the disk-down operation refers to writing a dynamic partition (Super) upgrade file (COW file) stored in a virtual dynamic partition on a user data partition (Userdata) into a dynamic partition (Super) in an upgrade process of an operating system, so that the file of the dynamic partition (Super) completes data upgrade, and the device is not required to load the dynamic partition (Super) and the virtual dynamic partition when being started next time, and the device can be started only by loading the dynamic partition (Super).

Specifically, the device performs a boot broadcast after the device is successfully started, and starts an upgrade process after the boot broadcast. The upgrade process reads the disk-down status information in the metadata (/ metadata) of the base partition (Common), and if the disk-down status information is "fallen disk (merged)", the device enters a normal operation mode.

If the disk-dropping state information is 'no disk-dropping (wait for merge'), the upgrading process drops the COW file in the user data partition (Userdata) into the dynamic partition (Super).

Specifically, the upgrading process writes upgrading data in a COW file in a user data partition (Userdata) into a corresponding address in a dynamic partition (Super), so that all data in the dynamic partition (Super) are upgraded new-version data.

For example,/system/app/a 2.Xxx: 024018-024020 and/system/app/A2. XXX in COW file map: 045033 to 045035, writing the data at 045033 to 045035 to 024017; system/user/c2.Xxx in system sub-partition based file map: 024036-024040, and/system/user/C2.XXX in COW file map: 045036 to 045040, the data at the addresses 045036 to 045040 are written into the addresses 024036 to 024040.

After that, the upgrading process deletes the COW file in the user data partition (Userdata) and returns the storage space to the user data partition (Userdata); and, the disk-drop status information in the metadata (/ metadata) of the base partition (Common) is changed from "not disk-dropped (wait for merge)" to "dropped (merged)".

In S220, the data operation of the static partition upgrade is directed to the operating system data in the static partition (B), and does not affect the operating system data of the currently started static partition (a); in S230, the data operation of the dynamic partition upgrade is performed on the virtual dynamic partition created in the user data partition (Userdata), which does not affect the currently mounted dynamic partition (Super). Therefore, in the whole operating system upgrading process, a user can normally use the equipment; after S231 is completed, the device does not need to be restarted immediately, and a user may select a restart time by himself; therefore, the upgrading process of the operating system does not influence the normal mobile phone operation of the user, and the user experience is greatly improved. Further, for the dynamic partition (Super), a virtual dynamic partition is created on the user data partition (Userdata) only when upgrading is needed, so that the utilization rate of the data storage space is effectively improved.

Further, in a practical application scenario, the upgrade operation is performed by an operating system update program installed on the device. As shown in fig. 3, an upgrade package acquisition tool (update apk) 301 and an upgrade engine (update engine) 302 are two modules in an operating system installed on a device 300, which are installed in a system partition of the device. For example, the system partition including the base partition (Common), the static partition (a), the static partition (B), the dynamic partition (Super), the upgrade package acquisition tool (update apk client) 301, and the upgrade engine (update engine) 302 is installed in the system sub-partition of the dynamic partition (Super).

An upgrade package acquisition tool (update apk package) 301 is used for acquiring an upgrade installation package of an operating system, downloading the upgrade installation package of the operating system, and storing the upgrade installation package of the operating system in a user data partition (Userdata). Refer to S210.

For example, an upgrade package acquisition tool (update apk) 301 periodically initiates a package search request to a package search server 310, where the package search request includes information (e.g., version 1.1) such as a current operating system version number (e.g., version 1.1) of the device, a device SN number, a product model, a system, and the like; the package searching server 310 searches whether an operating system installation package (for example, version 1.2) with an updated version number exists on the installation package server 320 according to the operating system version number in the package searching request; when there is an operating system installation package of an updated version, the package search server 310 feeds back a download address (e.g., a URL address) of an operating system upgrade installation package (e.g., an operating system upgrade package upgraded from version 1.1 to version 1.2) to an upgrade package acquisition tool (update apk package) 301; an upgrade package acquisition tool (update apk package) 301 downloads the operating system upgrade installation package from the installation package server 320 according to the download address of the operating system upgrade installation package.

When the upgrade package acquisition tool (update apk package) 301 acquires the operating system upgrade installation package, it starts an upgrade engine (update engine) 302, and the upgrade engine (update engine) 302 upgrades the operating system according to the operating system upgrade installation package.

Specifically, after the upgrade package acquisition tool (update app package) 301 acquires the operating system upgrade installation package, the upgrade package acquisition tool (update app package) 301 sets a start attribute of the upgrade engine (update engine) 302, and sets the start attribute to true. The service servicemanager resident in the operating system background monitors the start attribute of the upgrade engine (update engine) 302, and when the servicemanager detects that the start attribute of the upgrade engine (update engine) 302 is true, the servicemanager starts the upgrade engine (update engine) 302.

The upgrade package acquisition tool (update apk) 301 acquires the state of the upgrade engine (update engine) 302 through binder communication, and when the upgrade package acquisition tool (update apk) 301 confirms that the upgrade engine (update engine) 302 is successfully started, the upgrade package acquisition tool (update apk) 301 transmits an upgrade parameter (for example, whether the current upgrade operation is a file update operation or a file drop operation) to the upgrade engine (update engine) 302, and triggers the upgrade engine (update engine) 302 to enter an upgrade process. The specific upgrade flow may refer to S220 to S251.

In the above process, when the upgrade package acquisition tool (update apk) 301 downloads the upgrade installation package to the operating system, the upgrade package acquisition tool (update apk) 301 may not start the upgrade engine (update engine) 302.

For example, when the operating system is upgraded last time, the upgrade package acquisition tool (update apk package) 301 and the upgrade engine (update engine) 302 need to be upgraded synchronously, but because the version of the operating system upgrade package is released incorrectly, the upgrade data of the upgrade package acquisition tool (update apk package) 301 is not included in the operating system upgrade package used for upgrading the operating system last time. This causes the upgrade engine (update engine) 302 to be upgraded and the upgrade package capture tool (update apk) 301 to have its version number upgraded, but the data not upgraded, when the last os upgrade was performed. This results in that data interaction between the upgrade package acquisition tool (update apk tool) 301 and the upgrade engine (update engine) 302 cannot be performed correctly, and the upgrade package acquisition tool (update apk tool) 301 cannot start the upgrade engine (update engine) 302.

For another example, when the last operating system is upgraded, the upgrade package acquisition tool (update apk) 301 and the upgrade engine (update engine) 302 need to be upgraded synchronously, but due to a coding error, the upgrade package acquisition tool (update apk) 301 of the new version has a code bug (bug), and after the upgrade package acquisition tool (update apk) 301 and the upgrade engine (update engine) 302 are upgraded, the upgrade package acquisition tool (update apk) 301 of the new version cannot start the upgrade engine (update engine) 302 of the new version.

A straightforward solution to the above situation is to upgrade the upgrade package acquisition tool (update apk clock) 301 to match the version of the upgrade engine (update engine) 302, and upgrade the upgrade package acquisition tool (update apk clock) 301 to repair the bug of the upgrade package acquisition tool (update apk clock) 301. However, since the upgrade package acquisition tool (update apk) 301 is a part of the operating system, the simplest upgrade method of the upgrade package acquisition tool (update apk) 301 downloads the operating system upgrade package according to the flow shown in fig. 2, and starts the upgrade engine (update engine) 302 for upgrading, but since the upgrade package acquisition tool (update apk) 301 cannot start the upgrade engine (update engine) 302, it is necessary for the user to start the upgrade engine (update engine) 302 by himself, and the user starts the upgrade engine (update engine) 302 by himself, which has great difficulty in technical implementation (the user needs to know the operation mechanism of the upgrade engine (update engine) quite, but the ordinary user knows the operation mechanism of the upgrade engine (update engine) quite rarely). Alternatively, an Application (APP) that can replace the upgrade package acquisition tool (update apk) 301 is installed on the device, and the upgrade engine (update engine) 302 is started by the new APP. The code writing and application installation of the new APP inevitably consume a large amount of workload, and the difficulty of upgrade repair of an upgrade package acquisition tool (update APP) 301 is greatly increased.

In view of the foregoing problems, an embodiment of the present application provides an operating system upgrade method, so as to ensure that an operating system upgrade operation is performed smoothly when an upgrade package acquisition tool (update apk client) 301 has an error and an upgrade engine (update engine) 302 cannot be started.

In an embodiment, when a vendor of an operating system finds that an upgrade package acquisition tool (update app package) in an operating system of a certain version cannot smoothly start an upgrade engine (update engine), the vendor additionally puts a complete upgrade package acquisition tool (update app package) in an upgrade installation package of an operating system of a next version.

For example, after the operating system is upgraded according to the operating system upgrade package of the 1.1 version, an upgrade package acquisition tool (update apk package) in the operating system of the 1.1 version has a bug, which cannot start an upgrade engine (update engine). Therefore, in addition to the 1.2 version of the os upgrade data (e.g., static partition upgrade data and dynamic partition upgrade data), the 1.2 version of the os upgrade package additionally includes a complete upgrade package acquisition tool (update apk package), which can smoothly start the 1.1 version of the upgrade engine (update engine).

Specifically, the os upgrade data in the os upgrade package of version 1.2 may also include an upgrade package acquisition tool (update apk package) of version 1.2. The upgrade package acquisition tool (update apk package) additionally included in the 1.2 version of the operating system upgrade package may be the 1.1 version of the upgrade package acquisition tool (update apk package) with the bug repaired, or the 1.2 version of the upgrade package acquisition tool (update apk package), as long as it is ensured that the upgrade package acquisition tool (update apk package) additionally included can start the 1.1 version of the upgrade engine (update engine).

As shown in fig. 4, an upgrade package acquisition tool (update app) 401 and an upgrade engine (update engine) 402 are two modules in an operating system installed on a device 400, which are installed in a system partition of the device. Refer to fig. 3.

FIG. 5 is a flow diagram illustrating an operating system upgrade according to an embodiment of the present application.

S500, an upgrade package obtaining tool (update apk package) 401 obtains an operating system upgrade installation package 403, and the operating system upgrade installation package 403 is saved in a user data partition (Userdata). Refer to the description of the specification of fig. 3 and S210.

S510, the upgrade package obtaining tool (update apk tool) 401 detects whether the operating system upgrade installation package includes the upgrade package obtaining tool (update apk tool).

When the upgrade package acquisition tool (update app tool) is not included in the operating system upgrade installation package, it indicates that the upgrade package acquisition tool (update app tool) 401 of the current version in the operating system currently installed in the device can smoothly start the upgrade engine (update engine), so S520 is executed, and the upgrade package acquisition tool (update app tool) 401 starts the upgrade engine (update engine) 402;

s521, the upgrade engine (update engine) 402 performs an operating system upgrade operation according to the operating system upgrade installation package obtained by the upgrade package obtaining tool (update apk package) 401. Refer to S220 to S251.

When the upgrade installation package of the operating system includes an upgrade package acquisition tool (update apk package), it indicates that the upgrade package acquisition tool (update apk package) 301 of the current version in the operating system currently installed in the device may not successfully start the upgrade engine (update engine). For example, as shown in fig. 4, the operating system upgrade installation package 403 includes operating system upgrade data 404 and an upgrade package acquisition tool (update apk package) 405.

At this time, S530 is executed, and the upgrade package acquisition tool (update apk package) 401 extracts the upgrade package acquisition tool (update apk package) 405 from the operating system upgrade installation package 403.

S531, the upgrade package obtaining tool (update apk tool) 401 starts the upgrade package obtaining tool (update apk tool) 405, and assigns its own operation authority to the upgrade package obtaining tool (update apk tool) 405; for example, the upgrade package acquisition tool (update apk) 401 resets (fork) a process to start the upgrade package acquisition tool (update apk) 405, and the upgrade package acquisition tool (update apk) 405 acquires all the operation rights of the upgrade package acquisition tool (update apk) 401 in an inheritance manner.

S532, the upgrade package acquisition tool (update apk client) 405 starts the upgrade engine (update engine) 402.

S533, the upgrade engine (update engine) 402 performs an os upgrade operation according to the os upgrade data 404 in the os upgrade installation package 403. Refer to S220 to S251.

Furthermore, in some application scenarios, there may be a code error in the upgrade engine (update engine), and after the upgrade engine (update engine) is started, the upgrade engine (update engine) cannot smoothly complete the upgrade operation of the operating system.

For example, when the last operating system is upgraded, the upgrade package acquisition tool (update apk) 301 and the upgrade engine (update engine) 302 need to be upgraded synchronously, but because the version of the operating system upgrade package is released incorrectly, the upgrade data of the upgrade engine (update engine) is not included in the operating system upgrade package used in the last operating system upgrade. This causes the upgrade package capture tool (update apk) 301 to be upgraded the last time the operating system upgrade was performed, and the version number of the upgrade engine (update engine) 302 is upgraded, but the data is not upgraded. This results in that the data of the upgrade engine (update engine) 302 cannot be matched with the system data, and the upgrade engine (update engine) 302 cannot smoothly complete the upgrade operation of the operating system after being started.

For another example, when the operating system is upgraded last time, the upgrade package acquisition tool (update apk) 301 and the upgrade engine (update engine) 302 need to be upgraded synchronously, but due to a coding error, the upgrade engine (update engine) of the new version has a code bug (bug), and after the upgrade package acquisition tool (update apk) 301 and the upgrade engine (update engine) 302 are upgraded, the upgrade engine (update engine) 302 cannot complete the operating system upgrade operation smoothly after being started.

In view of the foregoing problems, an embodiment of the present application provides an operating system upgrade method, so as to ensure that the upgrade operation of the operating system is performed smoothly when an error occurs in an upgrade engine (update engine) 302 and the upgrade operation of the operating system cannot be completed smoothly after the upgrade engine is started.

In an embodiment, when a vendor of an operating system finds that a code error exists in an upgrade engine (update engine) in an operating system of a certain version, and cannot smoothly complete an upgrade operation of the operating system after the vendor starts the upgrade engine, the vendor additionally places a complete upgrade engine (update engine) in an upgrade installation package of an operating system of a next version.

For example, after the operating system is upgraded according to the operating system upgrade package of the 1.1 version, an upgrade engine (update engine) in the operating system of the 1.1 version has a bug, which cannot smoothly complete the operating system upgrade operation after being started. Therefore, in the 1.2 version os upgrade package, in addition to the 1.2 version os upgrade data (e.g., static partition upgrade data and dynamic partition upgrade data), the os upgrade package additionally includes an installation package data of a complete upgrade engine (update engine), which can be successfully started by the 1.1 version upgrade engine (update engine).

Specifically, the os upgrade data in the os upgrade package of version 1.2 may also include an upgrade engine (update engine) of version 1.2. The upgrade engine (update engine) additionally included in the 1.2 version os upgrade package may be the 1.1 version upgrade engine (update engine) in which the bug is repaired, or the 1.2 version upgrade engine (update engine), as long as it is ensured that the additionally included upgrade engine (update engine) can be started by the 1.1 version upgrade engine (update engine), and it is ensured that the additionally included upgrade engine (update engine) can smoothly complete the os upgrade operation after being started.

As shown in fig. 6, an upgrade package acquisition tool (update app) 601 and an upgrade engine (update engine) 602 are two modules in an operating system installed on a device 600, which are installed in a system partition of the device. Refer to fig. 4.

FIG. 7 is a flowchart illustrating an operating system upgrade according to an embodiment of the present application.

S700, an upgrade package obtaining tool (update apk tool) 601 obtains an operating system upgrade installation package 603, and the operating system upgrade installation package 603 is stored in a user data partition (Userdata). Refer to the description of fig. 3 and S210.

S720, the upgrade package acquisition tool (update apk tool) 601 starts the upgrade engine (update engine) 602.

S730, the upgrade engine (update engine) 602 detects whether the operating system upgrade installation package includes an upgrade engine (update engine).

When the upgrade engine (update engine) is not included in the operating system upgrade installation package, it indicates that the upgrade engine (update engine) 602 of the current version in the operating system currently installed in the device can smoothly complete the operating system upgrade operation after being started, and therefore, S731 is executed, and the upgrade engine (update engine) 602 performs the operating system upgrade operation according to the operating system upgrade installation package obtained by the upgrade package obtaining tool (update apk package) 601. Refer to S220 to S251.

When the upgrade installation package of the operating system includes an upgrade engine (update engine), it indicates that the upgrade engine (update engine) 602 of the current version in the operating system currently installed in the device cannot smoothly complete the upgrade operation of the operating system after being started. For example, as shown in fig. 6, the operating system upgrade installation package 603 includes operating system upgrade data 604 and an upgrade engine (update engine) 605.

At this time, S732 is executed, and the upgrade engine (update engine) 602 extracts the upgrade engine (update engine) 605 from the operating system upgrade installation package 603.

S733, the upgrade engine (update engine) 602 starts the upgrade engine (update engine) 605, and gives its own operation right to the upgrade engine (update engine) 605; for example, the upgrade engine (update engine) 602 repeatedly etches (fork) a process to start the upgrade engine (update engine) 605, and the upgrade engine (update engine) 605 acquires all the operation rights of the upgrade engine (update engine) 602 in an inheritance manner.

S734, the upgrade engine (update engine) 605 performs an os upgrade operation according to the os upgrade data 604 in the os upgrade installation package 603. Refer to S220 to S251.

Further, in some application scenarios, when the upgrade package acquisition tool (update apk tool) cannot start the upgrade engine (update engine), the upgrade engine (update engine) cannot be started due to a data error instead of the data error of the upgrade package acquisition tool (update apk tool).

For example, when the last operating system is upgraded, the upgrade package acquisition tool (update apk) 301 and the upgrade engine (update engine) 302 need to be upgraded synchronously, but because the version of the operating system upgrade package is released incorrectly, the upgrade data of the upgrade engine (update engine) is not included in the operating system upgrade package used in the last operating system upgrade. This causes the upgrade package capture tool (update apk) 301 to be upgraded the last time the operating system upgrade was performed, and the version number of the upgrade engine (update engine) 302 is upgraded, but the data is not upgraded. This results in the upgrade engine (update engine) 302 not matching the system data and the upgrade engine (update engine) 302 not being started.

For another example, when the last operating system is upgraded, the upgrade package acquisition tool (update apk) 301 and the upgrade engine (update engine) 302 need to be upgraded synchronously, but due to a coding error, the new version of the upgrade engine (update engine) has a code bug (bug), and after the upgrade package acquisition tool (update apk) 301 and the upgrade engine (update engine) 302 are upgraded, the new version of the upgrade engine (update engine) 302 cannot be started.

In view of the foregoing problems, an embodiment of the present application provides an operating system upgrade method to ensure that an operating system upgrade operation is performed smoothly when an upgrade engine (update engine) 302 has an error and cannot be started or cannot complete the operating system upgrade operation smoothly after being started.

In an embodiment, when a vendor of an operating system finds that a bug exists in an upgrade engine (update engine) in an operating system of a certain version, and the upgrade engine cannot be started successfully or cannot complete the upgrade operation of the operating system successfully after the upgrade engine is started, the vendor additionally puts a complete upgrade engine (update engine) in an upgrade installation package of an operating system of a next version.

For example, after the operating system is upgraded according to the operating system upgrade package of the 1.1 version, a bug exists in an upgrade engine (update engine) in the operating system of the 1.1 version, which cannot be started. Therefore, in the 1.2 version os upgrade package, in addition to the 1.2 version os upgrade data (e.g., static partition upgrade data and dynamic partition upgrade data), a complete upgrade engine (update engine) is additionally included, and the upgrade engine (update engine) can be successfully started by the 1.1 version upgrade package acquisition tool (update apk package).

Specifically, the os upgrade data in the os upgrade package of version 1.2 may also include an upgrade engine (update engine) of version 1.2. The upgrade engine (update engine) additionally included in the 1.2 version os upgrade package may be the upgrade engine (update engine) of the 1.1 version of the bug which is repaired, or the upgrade engine (update engine) of the 1.2 version, as long as it is ensured that the upgrade engine (update engine) additionally included can be smoothly started by the 1.1 version upgrade package acquisition tool (update apk package).

S800, an upgrade package acquiring tool (update apk tool) 601 acquires an operating system upgrade installation package 603, and the operating system upgrade installation package 603 is saved in a user data partition (Userdata). Refer to the description of fig. 3 and S210.

S810, an upgrade package acquisition tool (update apk) 601 starts an upgrade engine (update engine) 602;

s820, an upgrade package acquisition tool (update apk) 601 judges whether an upgrade engine (update engine) 602 is started successfully; as described with reference to fig. 3, the upgrade package acquisition tool (update app client) 601 acquires the state of the upgrade engine (update engine) 602 through binder communication, thereby confirming whether the upgrade engine (update engine) 602 is successfully started;

if the boot is successful, S821 is executed, and the upgrade engine (update engine) 602 performs an operating system upgrade operation according to the operating system upgrade installation package acquired by the upgrade package acquisition tool (update apk package) 601. Refer to S220 to S251.

If the boot fails, S830 is executed, and the upgrade package acquisition tool (update apk tool) 601 extracts the upgrade engine (update engine) 605 from the operating system upgrade installation package 603.

S831, the upgrade package acquisition tool (update apk tool) 601 starts the upgrade engine (update engine) 605.

S832, the upgrade engine (update engine) 605 performs an operating system upgrade operation according to the operating system upgrade data 604 in the operating system upgrade installation package 603. Refer to S220 to S251.

It is to be understood that some or all of the steps or operations in the above embodiments are only examples, and other operations or variations of various operations may be performed by the embodiments of the present application. Further, the various steps may be performed in a different order presented in the above embodiments, and not all of the operations in the above embodiments may be performed.

Further, in general, improvements to a technology can be clearly distinguished as improvements in hardware (e.g., improvements to circuit structures such as diodes, transistors, switches, etc.) or software (improvements to method flows). However, as technology advances, many of today's process flow improvements have been seen as direct improvements in hardware circuit architecture. Designers almost always obtain the corresponding hardware circuit structure by programming an improved method flow into the hardware circuit. Thus, it cannot be said that an improvement in the process flow cannot be realized by hardware physical blocks. For example, a Programmable Logic Device (PLD), such as a Field Programmable Gate Array (FPGA), is an integrated circuit whose Logic functions are determined by programming the Device by an accessing party. A digital device is "integrated" on a PLD by the designer's own programming without requiring the chip manufacturer to design and fabricate specialized integrated circuit chips. Furthermore, nowadays, instead of manually manufacturing an Integrated Circuit chip, such Programming is often implemented by "logic compiler" software, which is similar to a software compiler used in program development and writing, but the original code before compiling is also written by a specific Programming Language, which is called Hardware Description Language (HDL), and HDL is not only one but many, such as ABEL (Advanced Boolean Expression Language), AHDL (alternate Hardware Description Language), traffic, CUPL (core universal Programming Language), HDCal, jhddl (Java Hardware Description Language), lava, lola, HDL, PALASM, rhyd (Hardware Description Language), and vhigh-Language (Hardware Description Language), which is currently used in most popular applications. It will also be apparent to those skilled in the art that hardware circuitry that implements the logical method flows can be readily obtained by merely slightly programming the method flows into an integrated circuit using the hardware description languages described above.

Therefore, the method flow proposed by the embodiment of the present application may be implemented in a hardware manner, for example, by using a controller, and the controller controls the touch screen to implement the method flow proposed by the embodiment of the present application.

The controller may be implemented in any suitable manner, for example, the controller may take the form of, for example, a microprocessor or processor and a computer-readable medium storing computer-readable program code (e.g., software or firmware) executable by the (micro) processor, logic gates, switches, an Application Specific Integrated Circuit (ASIC), a programmable logic controller, and an embedded microcontroller, examples of which include, but are not limited to, the following microcontrollers: ARC 625D, atmel AT91SAM, microchip PIC18F26K20, and Silicone Labs C6051F320, the memory controller may also be implemented as part of the control logic for the memory. Those skilled in the art will also appreciate that, in addition to implementing the controller as pure computer readable program code, the same functionality can be implemented by logically programming method steps such that the controller is in the form of logic gates, switches, application specific integrated circuits, programmable logic controllers, embedded microcontrollers and the like. Such a controller may thus be considered a hardware component, and the means included therein for performing the various functions may also be considered as a structure within the hardware component. Or even means for performing the functions may be regarded as being both a software module for performing the method and a structure within a hardware component.

Corresponding to the embodiment, the application further provides the electronic equipment. The electronic device comprises a memory for storing computer program instructions and a processor for executing the program instructions, wherein the computer program instructions, when executed by the processor, trigger the electronic device to perform the method steps as described in embodiments of the present application.

The present application also provides a computer program product comprising a computer program which, when run on a computer, causes the computer to perform some or all of the steps provided by the embodiments of the present application.

Those skilled in the art will readily appreciate that the techniques of the embodiments of the present invention may be implemented as software plus a required general purpose hardware platform. Based on such understanding, the technical solutions in the embodiments of the present invention may be essentially or partially implemented in the form of a software product, which may be stored in a storage medium, such as ROM/RAM, magnetic disk, optical disk, etc., and includes several instructions for enabling a computer device (which may be a personal computer, a server, or a network device, etc.) to execute the method according to the embodiments or some parts of the embodiments.

The same and similar parts in the various embodiments in this specification may be referred to each other. Especially, as for the device embodiment and the terminal embodiment, since they are basically similar to the method embodiment, the description is relatively simple, and the relevant points can be referred to the description in the method embodiment.

Claims

1. A method for upgrading an operating system is applied to an electronic device, a first operating system is installed on the electronic device, the first operating system comprises a first upgrading application, and the first upgrading application is an operating system updating program installed on the electronic device, and the method comprises the following steps:

acquiring a system upgrading installation package, wherein the system upgrading installation package comprises system upgrading data and a second upgrading application, the system upgrading data is used for upgrading the first operating system, the second upgrading application is an updated version of the first upgrading application, and the second upgrading application is application data which is independent of the system upgrading data and can be directly called and operated by the first operating system;

upgrading the first operating system based on the system upgrade data, wherein:

in the process of upgrading the first operating system, the first upgrading application is not run, the second upgrading application is run to complete the upgrading operation corresponding to the first upgrading application, or the first upgrading application and the second upgrading application are run to complete the upgrading operation corresponding to the first upgrading application.

2. The method of claim 1, wherein the first operating system further comprises a third upgrade application, wherein the first upgrade application is configured to obtain the system upgrade installation package and to start the third upgrade application after obtaining the system upgrade installation package, and wherein the third upgrade application is configured to upgrade the first operating system based on the system upgrade installation package;

launching, by the second upgraded application, the third upgraded application;

3. The method of claim 2, wherein said launching the second upgraded application by the first upgraded application comprises:

the first upgrading application starts the second upgrading application;

4. The method of claim 2, wherein the second upgraded application is launched by the first upgraded application, wherein a process of the first upgraded application is replicated by a new sub-process on which the second upgraded application is running.

5. The method of claim 2, wherein the first upgrade application is an upgrade package acquisition tool and the third upgrade application is an upgrade engine.

6. The method of claim 1, wherein the first operating system further comprises a third upgrade application, wherein the third upgrade application is configured to obtain the system upgrade installation package and to start the first upgrade application after obtaining the system upgrade installation package, and wherein the first upgrade application is configured to upgrade the first operating system based on the system upgrade installation package;

launching, by the third upgraded application, the first upgraded application;

7. The method of claim 1, wherein the first operating system further comprises a third upgrade application, wherein the third upgrade application is configured to obtain the system upgrade installation package and to start the first upgrade application after obtaining the system upgrade installation package, and wherein the first upgrade application is configured to upgrade the first operating system based on the system upgrade installation package;

starting the first upgrading application;

8. The method of claim 6 or 7, wherein the third upgrade application is an upgrade package acquisition tool and the first upgrade application is an upgrade engine.

9. An electronic device, comprising a processor and a memory, wherein a first operating system is installed on the memory, the first operating system includes a first upgrade application, the first upgrade application is an application that needs to be executed during upgrading of the first operating system, and the processor is configured to execute software codes stored in the memory, so that the electronic device executes the method flow according to any one of claims 1 to 8.

10. A computer-readable storage medium, in which a computer program is stored which, when run on a computer, causes the computer to carry out the method according to any one of claims 1 to 8.