CN115686584A

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

Info

Publication number: CN115686584A
Application number: CN202110872080.XA
Authority: CN
Inventors: 王艳召; 郝庆涛; 陈超; 张赠辉
Original assignee: Honor Device Co Ltd
Current assignee: Honor Device Co Ltd
Priority date: 2021-07-30
Filing date: 2021-07-30
Publication date: 2023-02-03
Anticipated expiration: 2041-07-30
Also published as: CN115686584B; WO2023005370A1; CN117873511A; EP4202649A1; US20230229424A1

Abstract

The method, the device, the storage medium and the computer program product for upgrading the operating system provided by the embodiment of the application comprise the following steps: obtaining an operating system upgrading package, wherein the operating system upgrading package comprises a second partition table and operating system upgrading data, and the addresses of partitions with the same name are configured consistently in the second partition table and the first partition table; triggering the first restart of the electronic equipment, and after the first restart, enabling the electronic equipment to enter a recovery mode; updating the partition table of the electronic equipment into a second partition table in the recovery mode; triggering the second restart of the electronic equipment, and after the second restart, loading the data of the basic partition, the first static partition and the dynamic partition by the electronic equipment to run a first operating system; and upgrading the operating system of the electronic equipment according to the operating system upgrading data, and upgrading the first operating system to a second operating system. The upgrading scheme of the embodiment of the application greatly simplifies the operation difficulty of updating the partition table and improves the user experience.

Description

Operating system upgrading method, device, 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 an 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 partition architecture of the operating system of the terminal device is planned in advance on the memory of the terminal device. The upgrading of the operating system is mainly to update the data of the operating system under the partition framework of the original operating system. However, when some version upgrades with larger changes are made, the partition architecture of the operating system needs to be changed, for example, partitions are added or deleted. Therefore, there is a need for an operating system upgrade method that supports adjusting partition architectures.

Disclosure of Invention

In view of the above, the present application provides a method, an apparatus, a storage medium, and a computer program product for upgrading an operating system, so as to solve the problem of how to adjust a partition architecture of an apparatus memory in the prior art.

In a first aspect, an embodiment of the present application provides a method for upgrading an operating system, where the method is applied to an electronic device, the electronic device includes a processor and a memory, the memory includes a base partition, a first static partition, a second static partition, a dynamic partition, and a user data partition, a current partition table of the electronic device is a first partition table corresponding to a first operating system, the electronic device loads data of the base partition, the first static partition, and the dynamic partition after being started to run the first operating system, and after the first operating system runs, the method includes:

obtaining an operating system upgrade package, wherein the operating system upgrade package comprises a second partition table corresponding to a second operating system and operating system upgrade data, and the operating system upgrade data is used for upgrading the first operating system to the second operating system, and the addresses of partitions with the same name are configured consistently in the second partition table and the first partition table;

triggering the first restart of the electronic equipment, and after the first restart, entering a recovery mode by the electronic equipment;

updating the partition table of the electronic equipment into a second partition table in the recovery mode;

triggering the second restart of the electronic equipment, and after the second restart, loading the data of the basic partition, the first static partition and the dynamic partition by the electronic equipment to run a first operating system;

and upgrading the operating system of the electronic equipment according to the operating system upgrading data, and upgrading the first operating system to a second operating system.

According to the scheme of the first aspect of the application, the operating system adopting the virtual A/B upgrading scheme can be upgraded, and the partition table of the device memory is updated in the upgrading process; according to the scheme of the first aspect of the application, a burning tool does not need to be prepared, and the equipment can automatically complete the updating of the partition table based on the downloaded operating system upgrade package; according to the scheme of the first aspect of the application, the operation difficulty of updating the device partition table is greatly simplified, and the user experience is improved.

In an implementation manner of the first aspect, before the electronic device is restarted and enters the recovery mode, the method further includes:

and executing a partition table updating preparation operation, wherein the partition table updating preparation operation is used for configuring the execution flow of the electronic equipment in the recovery mode.

In one implementation manner of the first aspect, the performing a partition table update preparation operation includes:

storing the second partition table into a cache;

and writing a first control command in the cache, wherein the first control command corresponds to a first operation flow, and the first operation flow is used for updating the partition table of the electronic equipment into a second partition table.

In one implementation manner of the first aspect, the first operation flow includes:

checking the second partition table;

after the second partition table is successfully verified, verifying whether the address configurations of the partitions with the same name in the second partition table and the first partition table are consistent;

and when the address configurations of the partitions with the same name in the second partition table and the first partition table are consistent, updating the partition table of the electronic equipment by using the second partition table.

In one implementation manner of the first aspect, in the recovery mode, updating the partition table of the electronic device to a second partition table includes:

loading a second partition table and a first control command in the cache;

analyzing the first control command, and calling an execution code of the first operation flow according to the first control command;

executing the execution code of the first operational flow.

In one implementation manner of the first aspect, before performing the partition table update preparation operation, the method further includes:

confirming whether the operating system upgrade package is used for updating the partition;

when the operating system upgrade package is used for updating the partition, determining whether the partition table of the electronic device is updated based on the second partition table;

and when the partition table of the electronic equipment is not updated based on the second partition table, executing partition table updating preparation operation.

In one implementation manner of the first aspect, confirming whether the operating system upgrade package is used for updating the partition includes:

and analyzing the description file corresponding to the operating system upgrade package, wherein the operating system upgrade package is used for updating the partition when the description file contains the partition upgrade package mark.

In one implementation of the first aspect:

confirming whether the partition table of the electronic equipment is updated based on the second partition table or not, wherein whether the partition table of the electronic equipment is updated based on the second partition table or not is confirmed according to the state of the partition updating zone bit, and the state of the partition updating zone bit is not updated before the operating system upgrade package is obtained;

in a recovery mode, updating a partition table of the electronic device into a second partition table, including setting the state of a partition update flag bit to be updated;

upgrading the operating system of the electronic equipment according to the operating system upgrading data, and upgrading the first operating system to a second operating system, wherein the upgrading method comprises the step of setting the state of the partition updating zone bit to be not updated.

In one implementation form of the first aspect, before upgrading an operating system of the electronic device according to the operating system upgrade data, the method further includes:

after the second restart, after the first operating system runs, confirming whether the partition table of the electronic equipment is updated based on the second partition table again;

and when the first upgrading packet acquisition tool confirms that the partition table of the electronic equipment is updated based on the second partition table, upgrading the operating system of the electronic equipment according to the operating system upgrading data.

In one implementation manner of the first aspect, the first operating system includes a first upgrade package obtaining tool and a first upgrade engine, and after the first operating system runs, the method includes:

a first upgrade package acquisition tool acquires an operating system upgrade package;

a first upgrade package acquisition tool confirms whether an operating system upgrade package is used for updating a partition;

when the operating system upgrade package is used for updating the partition, the first upgrade package acquisition tool confirms whether the partition table of the electronic equipment is updated based on the second partition table;

when the partition table of the electronic equipment is not updated based on the second partition table, the first upgrade package acquisition tool executes partition table updating preparation operation;

a first upgrade package acquisition tool records a first upgrade flow breakpoint, and the first upgrade flow breakpoint correspondingly confirms whether a partition table of the electronic equipment is updated based on a second partition table;

triggering a first restart by a first upgrade package acquisition tool;

after the first restart, the electronic device enters a recovery mode, in the recovery mode, the partition table of the electronic device is updated to be a second partition table, and then the partition table of the electronic device is updated based on the second partition table;

triggering a second restart in a recovery mode;

after the second restart, the electronic equipment loads data of the basic partition, the first static partition and the dynamic partition so as to run a first operating system;

after the first operating system runs, the first upgrading packet acquisition tool reads the breakpoint of the first upgrading flow and confirms whether the partition table of the electronic equipment is updated based on the second partition table again;

when the first upgrade package acquisition tool confirms that the partition table of the electronic equipment is updated based on the second partition table, the first upgrade package acquisition tool triggers the first upgrade engine to upgrade the operating system of the electronic equipment according to the upgrade data of the operating system.

In one implementation manner of the first aspect, the first operating system includes a second upgrade package obtaining tool and a second upgrade engine, and after the first operating system runs, the method includes:

a second upgrade package acquisition tool acquires an operating system upgrade package;

the second upgrading package acquisition tool triggers a second upgrading engine to enter an upgrading process;

the second upgrading engine confirms whether the operating system upgrading packet is used for updating the partition;

when the operating system upgrade package is used for updating the partition, the second upgrade engine confirms whether the partition table of the electronic device is updated based on the second partition table;

when the partition table of the electronic equipment is not updated based on the second partition table, the second upgrading engine executes partition table updating preparation operation;

the second upgrading engine returns state information of the completion of the partition table updating preparation operation to the second upgrading packet acquisition tool;

a second upgrade package acquisition tool records a second upgrade flow breakpoint, and the second upgrade flow breakpoint corresponds to the second upgrade package acquisition tool and triggers a second upgrade engine to enter an upgrade flow;

the second upgrade package acquisition tool triggers a third restart of the electronic device;

after the third restart, the electronic device enters a recovery mode, in the recovery mode, the partition table of the electronic device is updated to be a second partition table, and then the partition table of the electronic device is updated based on the second partition table;

in the recovery mode, triggering a fourth restart of the electronic device;

after the fourth reboot, the electronic device loads data of the base partition, the first static partition, and the dynamic partition to run the first operating system;

after the first operating system runs, the second upgrading package obtaining tool reads a second upgrading flow breakpoint and triggers the second upgrading engine to enter the upgrading flow again;

the second upgrading engine confirms whether the operating system upgrading packet is used for updating the partition again;

when the operating system upgrade package is used for updating the partition, the second upgrade engine confirms whether the partition table of the electronic device is updated based on the second partition table again;

and when the partition table of the electronic equipment is not updated based on the second partition table, the second upgrading engine upgrades the operating system of the electronic equipment according to the operating system upgrading data.

In an implementation manner of the first aspect, the upgrading data of the operating system further includes static partition upgrading data and dynamic partition upgrading data, and upgrading the operating system of the electronic device according to the upgrading data of the operating system includes:

upgrading the data of the second static partition based on the static partition upgrading data;

creating a virtual dynamic partition in a user data partition, and writing dynamic partition upgrading data into the virtual dynamic partition;

the starting sequence of the electronic equipment is changed from starting from the first static partition to starting from the second static partition;

triggering a third restart of the electronic equipment;

after the third restart, the electronic device loads data of the base partition, the second static partition, the dynamic partition and the virtual dynamic partition to run a second operating system;

and after the second operating system runs, the data of the virtual dynamic partition is landed to the dynamic partition.

In a second aspect, the present application provides an electronic device, where the electronic device includes a processor and a memory, the memory includes a base partition, a first static partition, a second static partition, a dynamic partition, and a user data partition, the dynamic partition includes multiple sub-partitions, and the processor is configured to execute software codes stored in the memory, so that the electronic device loads data of the base partition, the first static partition, and the dynamic partition after being started to run a first operating system;

and after the first operating system is run, causing the electronic device to perform the method flow of the first aspect.

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

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

Drawings

In order to more clearly illustrate the technical solutions of the embodiments of the present application, the drawings needed 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 to obtain other drawings based on these drawings without inventive labor.

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

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

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

FIG. 4 is a diagram illustrating a data storage structure 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 structural diagram of a burning system framework for system burning before leaving a factory according to an embodiment of the present application;

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

FIG. 8 is a partition structure diagram illustrating a reconfiguration partition architecture according to an embodiment of the present application;

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

FIG. 9b is a diagram illustrating the configuration of files inside an operating system upgrade package according to an embodiment of the present application;

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

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

FIG. 12 is a schematic view of a mobile phone operation interface according to an embodiment of the present application;

FIG. 13 is a schematic diagram of a mobile phone operating interface according to an embodiment of the present application;

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

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

FIG. 16 is a partial flow diagram 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.

One possible solution to altering the partition architecture of the operating system is to exit the operating system, enter a Recovery (Recovery) mode, perform a global refresh of the device's memory under Recovery, reconfigure the partition structure of the device's memory, and write the operating system program in the reconfigured partition.

In general, a partition table is used to describe the partition deployment of memory in a device, defining the starting address and size of each partition. The partition table is typically stored in a disk header of the memory of the device, and each partition on the memory can be located by reading the partition table at device boot.

Take a disk using a global unique identification Partition Table (GPT) as an example. Fig. 1 is a schematic diagram of a data storage structure according to an embodiment of the present application. Assume that the partition architecture of version 1.0 operating system includes a GPT partition, an x-loader partition, a bootloader partition, a boot partition, a vendor-boot partition, a Super partition, and a Userdata partition. Wherein, the partition table is stored in the GPT partition; the Userdata is used for storing personal data of the user, such as APP installed by the user, pictures, documents, videos and other personal data stored by the user; the x-loader partition, the bootloader partition, the boot partition, the vendor-boot partition and the Super partition are used for storing operating system data.

The partition table stored in the GPT partition is shown in table 1:

TABLE1

In table1, AD1 to AD6 represent different address strings, respectively. The digital string of addresses is 16 digits, with 1 added to the address string representing an offset of one memory bit (bit), one Byte (Byte) for every 8 memory bits, 1KB for every 1024 bytes, and 1MB for every 1024 KB.

For example:

AD1 is 0x000000FF of memory bits offset by 256KB, which is 0x002000FF;

the address of x-loader is 0x 00000100-0x002000FF, and the size of 0x00000100-0 x002000FF is 256KB;

AD1+1 is 0x000200FF offset by one memory bit, which is 0x00200100;

AD2 is AD1 (0 x002000 FF) offset by 600KB of memory bits, i.e., 0x006B00FF; the addresses of bootloaders are 0x 00200100-0x006B00FF, and 0x00200100-0 x006B00FF, and the size is 600KB.

Suppose that after the operating system upgrades to version 2.0, an A partition is added to the partition architecture. Fig. 2 is a schematic diagram of a data storage structure according to an embodiment of the application. Assume that the partition architecture of version 2.0's operating system includes a GPT partition, an x-loader partition, a bootloader partition, a boot partition, an A partition, a vendor-boot partition, a Super partition, and a Userdata partition.

The partition table stored in the GPT partition is shown in table 2:

TABLE 2

In table 2, AD21 and AD22 represent different address strings, respectively. AD21 is a memory bit offset by 32MB from AD 3; AD22 is the memory bit offset by 32MB from AD 21. In the partition structure of table 2, the size of Super is reduced by 32MB compared to the partition structure of table 1. Since the partition architecture of the operating system of version 1.0 corresponds to the partition architecture shown in fig. 1, the partition architecture of the operating system of version 2.0 corresponds to the partition architecture shown in fig. 2, and the partition architecture shown in fig. 1 is different from the partition architecture shown in fig. 2, in the process of upgrading the operating system on the device from version 1.0 to version 2.0, the partition architecture shown in fig. 2 needs to be reconfigured from the partition architecture shown in fig. 1 to the partition architecture on the device memory. That is, the partition table stored in the GPT is refreshed from table1 to table 2.

It is understood that, compared to the start address-end address of each partition shown in table1, the start address-end address of the vendor-boot partition and the Super partition in the partition shown in table 2 are changed, so that if the partition table is refreshed from table1 into table 2 (reconfiguration partition architecture), data in the vendor-boot partition and the Super partition in the memory is not available; then, even if the operating system is upgraded from version 1.0 to version 2.0 and the data in the vendor-boot partition and the Super partition are not changed, after the partition table is refreshed from table1 to table 2, data needs to be rewritten in the vendor-boot partition and the Super partition in the memory.

Thus, for an operating system upgrade from 1.0 to 2.0, one possible upgrade scheme is to perform a data re-write to all operating system data partitions after the partition table is refreshed.

Specifically, fig. 3 is a flowchart illustrating upgrading an operating system according to an embodiment of the present application. As shown in fig. 3, the device performs the following procedure to upgrade the operating system from version 1.0 to version 2.0:

s300, acquiring an operating system upgrade package, and storing the operating system upgrade package to a Userdata partition, wherein the operating system upgrade package comprises a partition table shown in a table 2 and mirror image data of a bootloader partition, a boot partition, an A partition, a vendor-boot partition and a Super partition corresponding to the operating system of version 2.0;

s310, restarting the equipment to enter a Recovery (Recovery) mode;

s320, reading an operating system upgrade package of the Userdata partition in a Recovery mode;

s321, extracting a partition table in the operating system upgrade package, and replacing the partition table in the GPT partition of the device memory with the partition table in the operating system upgrade package; before S321, the partition table in the GPT partition is shown in table 1;

s322, respectively extracting mirror image data of the bootloader partition, the boot partition, the partition A, the vendor-boot partition and the Super partition in the operating system upgrade package, and restoring the mirror image data to the mirror image data of the bootloader partition, the boot partition, the partition A, the vendor-boot partition and the Super partition according to the partition starting address-ending address shown in the table 2;

s330, restarting the equipment and starting the operating system.

Although the partition architecture of the operating system may be adjusted based on the process shown in fig. 3, as the data security requirement is increased, in some operating systems, access to the user's personal data in the Recovery mode is prohibited, which makes it impossible for the device to rewrite the operating system data in the partition in the Recovery mode.

Taking an android system adopting a virtual a/B upgrade manner as an example, fig. 4 is a schematic diagram of a data storage structure according to an embodiment of the present application. As shown in fig. 4, the android system data storage area includes a basic 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) correspond in structure 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 boots 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. 5 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 started from a static partition (A), the device implements the upgrade of the operating system according to the flowchart shown in FIG. 5.

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

S510, the equipment acquires an operating system upgrade package.

For example, in a possible implementation scheme, the device periodically initiates a package searching request to the package searching server, where the package searching request includes a version number (for example, 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 upgrade package (for example, a system increment upgrade installation package upgraded from version 1.1 to version 1.2) to the equipment; and the equipment downloads the operating system upgrade package according to the download address of the operating system upgrade package.

S520, the equipment carries out data writing operation aiming at the static partition (B) according to the operating system upgrading packet so as to upgrade the static partition.

In the execution process of S520, there is a case where S520 execution fails (static partition upgrade fails). For this case, the device may interrupt the entire operating system upgrade operation, output an upgrade failure prompt to the user (e.g., display a dialog box for upgrade failure), automatically re-upgrade, or determine by the user whether to re-upgrade or abort the upgrade.

In order to detect whether there is a failure in upgrading the static partition in S520, data verification is performed on the static partition (B) after data writing to confirm whether the data of the static partition is successfully written.

For example, in an application scenario, the system upgrade installation package for an upgrade of version 1.1 to version 1.2 contains the full amount of data for the static partition of version 1.2 and the hash value of the full amount of data for the static partition of version 1.2. The device overwrites the full amount of data for the static partition of version 1.2 into the static partition (B). After the data is written, the equipment calculates the hash value of the data in the static partition (B), and checks whether the hash value of the data in the static partition (B) is consistent with the hash value of the whole amount of data of the static partition of the version 1.2 in the system upgrade installation package of the version 1.1 upgraded to the version 1.2. If the data are consistent, the data are successfully written, and subsequent operation system upgrading operation can be carried out; if the data is inconsistent with the data, the data writing fails, and the upgrading fails.

For another example, in an application scenario, the system upgrade installation package with version 1.1 upgraded to version 1.2 contains the difference data of the static partition with version 1.1 upgraded to version 1.2, the hash value of the full amount of data of the static partition with version 1.1, and the hash value of the full amount of data of the static partition with version 1.2.

Before writing data into the static partition (B), the device firstly calculates the hash value of the data in the static partition (A), checks whether the hash value of the data in the static partition (A) is consistent with the hash value of the total data of the static partition of version 1.1 in the system upgrade installation package of version 1.1 upgraded to version 1.2, if so, the data in the current static partition (A) is the static partition data of version 1.1, and the differential data of the static partition of version 1.1 upgraded to version 1.2 is available; if not, the differential data of the static partition upgraded from version 1.1 to version 1.2 is unavailable, and the upgrade fails.

After the device determines that the differential data of the static partition with the version 1.1 upgraded to the version 1.2 is available, the device reads the data in the static partition (A), performs restoration by using the differential data of the static partition with the version 1.1 upgraded to the version 1.2 and the data in the static partition (A) to obtain the full data of the static partition with the version 1.2, and overwrites the full data of the static partition with the version 1.2 in the static partition (B). After the data is written, the equipment calculates the hash value of the data in the static partition (B), and checks whether the hash value of the data in the static partition (B) is consistent with the hash value of the full amount of data of the static partition of the version 1.2 in the system upgrade installation package of the version 1.1 upgraded to the version 1.2. If the data are consistent, the data are successfully written, and subsequent operation system upgrading operation can be performed; if the data is inconsistent with the data, the data writing fails, and the upgrading fails.

Taking a sub-partition boot of a static partition as an example, in an application scenario, a system upgrade installation package for upgrading version 1.1 to version 1.2 includes the following data:

boot (partition Name, representing the current data as the upgrade data pointing to the sub-partition boot of the static partition)

Start:12222 (data Block Start Address, start position of upgrade data (differential data Delta 1) indicating boot child of static partition is 12222)

size 2410 (data size, size of upgrade data (differential data DELTA 1) indicating the child partition boot of static partition 2410)

HASH11 (HASH value of data of the sub-partition boot of the static partition of version 1.1)

HASH value of mirror target HASH12 (HASH value of data of boot, a sub-partition of version 1.2 static partition)

DELTA differential data Delta DELTA1 (differential data of static partition upgraded from version 1.1 to version 1.2)

In S520, the device reads a fixed mount path of the device, such as/dev/block/by-name/misc, through the misc partition in the common partition. And reading a slot-b from the UFS device, and replacing to obtain a sub-partition path, such as/dev/block/by-name/boot _ b.

Continuing to take the sub-partition boot as an example, the device first calculates the HASH value of the data under/dev/block/by-name/boot _ a, checks whether the HASH value of the data under/dev/block/by-name/boot _ a is consistent with the HASH value HASH11, if so, DELTA1 is available, and if not, the upgrading operation fails.

When the HASH value of the data under/dev/block/by-name/boot _ a is consistent with the HASH value HASH11, the device reads DELTA1 based on Start:12222 and size:2410, and performs restoration by using the data under DELTA1 and/dev/block/by-name/boot _ a to obtain the full data of the sub-partition boot of the static partition of version 1.2. And writing the total data of the sub-partition boot of the static partition of the version 1.2 into/dev/block/by-name/boot _ b by the equipment.

After data are written in, the equipment calculates the HASH value of the data under the conditions of dev/block/by-name/boot _ b, checks whether the HASH value of the data under the conditions of dev/block/by-name/boot _ b is consistent with the HASH value HASH12 or not, if so, the boot upgrade of the sub-partition of the static partition is successful, and the next sub-partition of the static partition can be upgraded; if not, the upgrade operation fails.

In an application scenario, the device upgrades the sub-partitions of the static partition according to the static partition sub-partition upgrade data included in the system upgrade installation package, specifically, if the system upgrade installation package includes a certain static partition sub-partition upgrade data, the sub-partition in the static partition (B) is upgraded according to the upgrade flow of the boot sub-partition, and if the system upgrade installation package does not include a certain static partition sub-partition upgrade data, the data of the sub-partition in the static partition (a) is directly synchronized into the sub-partition in the static partition (B). In the upgrading process, when one sub-partition has upgrading errors and the Hash check fails, the upgrading operation is interrupted and the upgrading fails; and when all the sub-partitions are upgraded successfully, the static partitions are upgraded successfully, and the subsequent steps can be executed.

Furthermore, when a static partition (a) or static partition (B)) fails to be upgraded, the data of the static partition cannot be used for smoothly starting the operating system, so as to avoid loading the static partition that fails to be upgraded in the starting process of the operating system to cause an operating system starting error, in an application scenario, the static partition has a corresponding status flag (startable or non-startable). The device first reads the static partition status flag before loading the static partition data, and only loads the data of the static partition when the status flag of the static partition is bootable. Before upgrading the data of the static partition, the static partition is marked as non-bootable, and after the data of the static partition is upgraded successfully, the static partition is marked as bootable, so that if the static partition is upgraded unsuccessfully, the state of the static partition is kept in the non-bootable state. The device will not load the data of the static partition that failed the upgrade.

For example, in S520, the static partition (B) is marked as non-bootable before upgrading the data of the static partition (B). In particular, the status flag of the static partition is saved in the Common partition. In S520, before upgrading the data of the static partition (B), marking slot-B in the status mark of the static partition in the Common partition as unbootable. When S520 is successfully executed (all hash checks are successful), the static partition (B) is marked as bootable. For example, after S520, the slot-b in the status flag of the static partition in the Common partition is marked as bootable.

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

Furthermore, in the virtual A/B upgrading scheme, an incremental upgrading 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 the 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. The upgrade from version 1.1 to version 1.2 has not occurred with data system2, and data system1 is upgraded to system3. Then, in S530, 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 package acquired in S510, 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 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 a system child partition is named system-COW-img.img.0000.

In S530, the device unpacks the operating system upgrade 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 may be understood that the dynamic partition (Super) loaded by the operating system currently running on the device is the dynamic partition (a). When the operating system is upgraded, the virtual dynamic partition created in the user data partition (Userdata) is for dynamic partition (B). Therefore, the name flag _ B of the corresponding dynamic partition (B) is attached to the COW file. For example, appending _ b to the system _ cow _ img.img.0000 generates system _ b-cow _ img.img.0000.

Further, in S530, 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 a 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 package is manufactured, a file map of a sub partition of a dynamic partition (Super) is generated in advance, and the file map is added to the COW file.

Taking a system sub-partition as an example, suppose that the following paths are used to store data in the system sub-partition:

/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 portion of the 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/a 2.xxx and/system/user/c 2.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.

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 the 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 to 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 of the cow file storage); offset size:4 (i.e., data in the address fields 045036-045040);

the values after the file names (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 and/system _ b/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.

After the COW file is successfully written into the user data partition (Userdata), the disk-down status information in the metadata partition (/ metadata) of the base partition (Common) is changed from "fallen disk (merged)" to "not fallen disk (wait for merge)". The landing status information is used to indicate whether there is a COW file that needs to be landed to a dynamic partition (Super) currently. Specifically, the landing status information contains an overall identification for the dynamic partition (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 '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.

Further, in some application scenarios, in S530, the device not only writes the COW file to the user data partition (Userdata), but also refreshes the partition information in the metadata of the dynamic partition (Super).

Specifically, fig. 6 is a schematic structural diagram of a burning system framework for system burning before the equipment leaves the factory in an application scene. In the android system adopting the virtual A/B upgrading mode, only the static partition adopts an A/B scheme, and the dynamic partition adopts a scheme of constructing a virtual dynamic partition during upgrading. Therefore, for matching the static partition and the dynamic partition, as shown in fig. 4, slot0 (Slot one data) of the corresponding static partition (a) and Slot1 (Slot two data) of the static partition (B) are included in the metadata (/ hypermetadata) of the header of the dynamic partition (Super). Slot0 and Slot1 are used for storing the partition table of the Super partition.

For example, in the MBR of UFS, the device boot sequence is described in which configuration Slot0 corresponds to boot from static partition (A) and configuration Slot1 corresponds to boot from static partition (B). When the equipment is started, according to different static partitions started, selecting to obtain the partition information of the Super partition from one of the Slot0 or the Slot1. For example, when the device is started by the static partition a, when the Super partition is loaded, the device first reads Slot0 to obtain the sub-partition address of the Super partition; when the device is started by the static partition B, when the Super partition is loaded, the device first reads Slot1 to obtain the sub-partition address of the Super partition.

Specifically, slot0 and Slot1 include a plurality of sub-partition description groups, and each sub-partition description group corresponds to one sub-partition of the Super partition. Each sub-partition description group includes:

a Name (Name) entry whose value is the Name of the child partition;

a Group (Group) entry, the value of which is a sub-partition type;

attribute (Attributes) entries whose values are partition read-write Attributes, e.g., read-only attribute (readonly);

the address (extensions) entry, whose value is the address of the child partition (e.g., partition size, offset).

In the Name item and the Group item, if the suffix of the value is _ a, the value corresponds to a static partition (A); the suffix of the value is B, which corresponds to the static partition (B).

When the Super partition is loaded, initiated by static partition A, slot0 is first read. When the Slot0 is read, the device reads the value of an extensions item in a partition description Group with the suffix of _ a in the Name item and/or the Group item in the Slot0 to obtain the sub-partition address of the Super partition, because the suffix of _ a corresponds to the static partition (a).

When the Super partition is loaded, initiated by static partition B, slot1 is first read. When the Slot1 is read, the device reads the value of an extensions item in a partition description Group with the suffix of _ B in the Name item and/or the Group item in the Slot0 to obtain the sub-partition address of the Super partition, because the suffix of _ B corresponds to the static partition (B).

In S530, the device extracts the partition information of the dynamic partition (Super) of the 1.2 version from the os upgrade package, and refreshes the partition information in the Slot1 corresponding to the static partition (B) by using the partition information of the dynamic partition (Super) of the 1.2 version.

Taking the System sub-partition as an example, before S530, it is assumed that Slot1 of the dynamic partition (Super)/supermetadata contains the following:

Metadata version:10.2

Metadata size:1300bytes

Metadata max size:65536bytes

Metadata slot count:3

Header flags:virtual_ab_device

Partition table:------------------------

Name:system_b

Group:ry_dynamic_partitions_b

Attributes:readonly,updated

Extents:0..6995967linear super 2048

in the os upgrade package obtained in S510, partition information of the dynamic partition (Super) of version 1.2 includes the following contents:

Name:system

Group:ry_dynamic_partitions

Extents:0..699XXXX linear super 2048

in S530, the device locates the static partition (B) to the Slot1 of/hypermetadata of the dynamic partition (Super) corresponding to the static partition (B) through the static partition currently needing to be upgraded, and refreshes the content in the Slot1 using the partition information of the dynamic partition (Super) of version 1.2. After S530, dynamic partition (Super)/supermetadata Slot1 contains the following:

Metadata version:10.2

Metadata size:1300bytes

Metadata max size:65536bytes

Metadata slot count:3

Header flags:virtual_ab_device

Partition table:------------------------

Name:system_b

Group:ry_dynamic_partitions_b

Attributes:readonly,updated

Extents:0..699XXXX linear super 2048

further, in the execution process of S530, there is a case where the execution of S530 fails. In response to this, the device may interrupt the entire operating system upgrade operation, output an upgrade failure prompt to the user (e.g., display a dialog box indicating upgrade failure), automatically re-upgrade, or determine by the user whether to re-upgrade or abort the upgrade. (refer to S520 in which static partition data write failed)

Specifically, the failure of the execution of S530 may be caused when the storage space of the user data partition (Userdata) is insufficient. In S530, in the process of the device creating a virtual dynamic partition in a user data partition (Userdata) according to the os upgrade package, the size of the virtual dynamic partition is determined by the size of the data of the dynamic partition of version 1.2 in the os upgrade package. When the free space on the user data partition (Userdata) is not enough to create a virtual dynamic partition, S530 execution fails.

For example, in an application scenario, a device extracts a COW file from an operating system upgrade package and writes the COW file into an Update folder of a user data partition (Userdata). The operating system upgrade package contains the content of the COW file and the size of the COW file. In S530, the device first creates an empty COW file under an Update folder of a user data partition (Userdata) according to a COW file name and a COW file size in an operating system upgrade package, and then extracts COW file data from the operating system upgrade package and writes the COW file data into the empty COW file.

Taking a system sub-partition as an example, in an operating system upgrade package, a COW file for the system sub-partition is named system-COW-img.img.0000, and the size of the system-COW-img.img.0000 is XXXX. The device creates a system _ b-cow file under the Update folder of the user data partition (Userdata), the size of the system _ b-cow file is XXXX, and the content is empty. After the system _ b-cow file is created, the device can extract the system-cow-img.img.0000 from the system upgrade installation package, write the system _ b-cow and rename the system _ b-cow-img.img.0000.

The device creates empty COW files, system _ b-COW, system _ ext _ b-COW, vendor _ b-COW, product _ b-COW, cut _ b-COW, and odm _ b-COW, under the Update folder of the user data partition (Userdata). After all the empty COW files are created, the device can extract COW file data from the system upgrade installation package, write the empty COW files in and rename the empty COW files.

The Update folder of the end 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。

in the process of creating the empty COW files, the device creates one empty COW file each time, and creates the next COW file after one empty COW file is successfully created. In this process, when an empty COW file is failed to be created, it indicates that the storage space of the user data partition (Userdata) is insufficient, and S530 fails to be executed, and the operating system fails to be upgraded.

Further, in S530, the failure of extracting the COW file also results in the failure of performing S530. Specifically, in the operating system upgrade package, the COW file is stored in the form of binary codes, and when the COW file is written into the user data partition (Userdata), the COW file needs to be extracted from the operating system upgrade package, the COW file is opened, and the COW file data is written into the user data partition (Userdata). In the above process, if the operating system upgrade package has a data error and the COW file cannot be extracted or opened, S530 fails to execute and the operating system upgrade fails.

Further, in S530, the failure of writing the COW file also results in the failure of executing S530. In order to detect whether the writing of the COW file is successful, in S530, after the COW file is written into the user data partition (Userdata), the dynamic partition (Super) + COW file needs to be integrally checked, the validity of the dynamic partition (Super) + COW file is checked, and whether the synthesis result of the current version of the dynamic partition (Super) data + the COW file is the new version of the dynamic partition (Super) data is verified.

Specifically, taking upgrading from the 1.1 version to the 1.3 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.3 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.3 version is stored in the operating system upgrade package.

Specifically, in the checking process, dynamic partitions (Super) + COW files are merged based on snapshot. In the implementation process of snapshot, the combination of a dynamic partition (Super) and a COW file is not physically combined, but an integral file map of a system sub-partition and a COW file map of the COW file are combined to generate a file map of new version sub-partition data.

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：045033～045035；

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

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 zoning (Super) in/under system B0.XXX)

/system/B1.XXX：024027～024028；

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

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

(Direction to dynamic partition (Super) in/under system/user C0.XXX)

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

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

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

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

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

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

In the file map of the new version of the system subpartition, the saved address of/system/app/A2. XXX points not to/system/app/A2. XXX on the dynamic partition (Super) on the memory, but to A2.XXX in system _ b-cow-img.img.0000 in the user data partition (Userdata) on the memory; 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.

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

For example, a Boot sequence flag of a 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.

Further, in S531, slot-b in the status flag of the static partition in the Common partition is also marked as bootable.

And S532, 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.

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

S541, the device loads the virtual dynamic partition 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 S541, 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 S541, 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 S541, when a corresponding COW file first exists in a 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 S530. 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 sub-partition of the system sub-partition is identified as 'not-dropped disk (merge)', so that the device searches the COW file in the user data partition (Upredata)/under Update, searches the COW file under Update, and generates a new version of the file map of the system sub-partition according to the file map of the COW file in the system _ b-COW-img.img.0000 based on the snapshot after searching the COW file under Update. 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 S541, before loading the file, the device needs to check the loaded file. Unlike S530, in S541, the dynamic partition (Super) + COW file is not verified in its entirety, but only the file that needs to be loaded is 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 S550, successfully starting the equipment and entering a user interaction interface.

S551, the device diskettes the data of the virtual dynamic partition to a 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 startup broadcast after being successfully started, and starts an upgrade process after the startup 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 "dropped" the device enters a normal operation mode.

If the disk-dropping status information is "not-dropped (wait for merge)", the upgrading process drops the COW file in the user data partition (Userdata) into the dynamic partition (Super).

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

For example,/system/app/a 2.Xxx:024018 to 024020, and/system/app/A2.XXX in COW file map: 045033-045035, writing the data on 045033-045035 into 024014-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-landing state information in the metadata (/ metadata) of the base partition (Common) is changed from "not-landed (wait for merge)" to "landed (merged)".

In S520, 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); also, in S530, the data operation of the dynamic partition upgrade is completed 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 process of upgrading the operating system, the user can normally use the equipment; moreover, after the step S531 is finished, 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.

Fig. 7 is a schematic diagram of a data storage structure according to an embodiment of the present application. If the partition structure shown in fig. 4 needs to be reconfigured, for example, sub-partitions a _ a and a _ B are respectively added to the static partition (a) and the static partition (B) to obtain the data storage structure shown in fig. 7, the partition table stored in the disk header (e.g., MBR partition or GPT partition) of the memory of the device needs to be refreshed to the partition table corresponding to the data storage structure shown in fig. 7 (the original partition table is the partition table corresponding to the partition structure shown in fig. 4). In the upgrade flow shown in fig. 5, the device completes the upgrade of the operating system data in the operating state of the operating system; however, in the normal operating state of the operating system, the partition table at the head of the disk of the memory is read only, and therefore, according to the upgrade process shown in fig. 5, the partition table cannot be refreshed.

Therefore, a logically feasible application scheme is to save an operating system upgrade package in a user data partition (Userdata) based on the flow shown in fig. 3, where the operating system upgrade package includes a partition table of the data storage structure shown in fig. 7 and mirror image data of each partition in the data storage structure shown in fig. 7. The method comprises the steps of entering a Recovery mode after the equipment is restarted, reading an operating system upgrading package stored in a user data partition (Userdata) in the Recovery mode, refreshing a partition table in a disk MBR (Messaging record) by using the partition table in the operating system upgrading package, positioning each partition based on the refreshed partition table, and recovering mirror image data of each partition in the operating system upgrading package to each partition.

However, in the android system adopting the virtual a/B upgrade mode, in order to ensure the safety of user data, data stored in the user data partition (Userdata) is encrypted, and the data stored in the user data partition (Userdata) can be accessed only when the android system is normally operated. That is, when the device is restarted to enter a Recovery (Recovery) mode, it cannot access the data stored in the user data partition (Userdata). Thus, the device cannot reconfigure the partition structure and rewrite data for the newly configured partitions in a Recovery (Recovery) mode.

In view of the above problems, the present application provides an operating system upgrade method combining virtual a/B upgrade and Recovery (Recovery) mode upgrade. The method comprises the steps of refreshing a partition table in a Recovery mode to reconfigure a partition framework, then starting an operating system, and upgrading operating system data in a virtual A/B upgrading mode.

Since the operating system needs to be started after the partition architecture is reconfigured, it is required that each partition to be loaded when the operating system is started is still available after the partition architecture is reconfigured. That is, before and after reconfiguring the partition architecture, the start address-end address of each partition to be loaded at the time of operating system boot remains unchanged. In response to the above-mentioned requirements, the present application proposes a new partition architecture for an operating system. In the partition architecture of an embodiment of the present application, not all the space of the disk is created as an available partition, but a part of the space is reserved as a reserved (reserve) partition. The reserve partition is an unavailable partition, which is not represented in an available partition of the device when the device runs, that is, assuming that a partition architecture corresponding to the operating system is as shown in fig. 4, if the reserve partition is configured on the memory of the device, the available partition of the device is still as shown in fig. 4 when the device runs the operating system, and the reserve partition is not represented.

When the partition framework is reconfigured, if a new partition needs to be added, a reserve partition is used for creating a new partition; if the partition needs to be deleted, converting the partition needing to be deleted into a reserve partition; other partitions besides the reserve partition remain unchanged before and after reconfiguring the partition architecture.

Taking an application scenario of adding a new partition as an example, fig. 8 is a schematic view of a partition structure of a reconfiguration partition architecture according to an embodiment of the present application. Before reconfiguring the partition architecture, the partition architecture shown in FIG. 4 maps a portion of the memory allocation on memory as shown in the left diagram of FIG. 8. The partition table corresponding to the left graph of fig. 8 is shown in table 3:

TABLE 3

In table 3, AD31 to AD38 represent different address strings, respectively. See AD1 to AD6 in table 1.XX is the partition size, and XX of different partitions can be the same or different.

The partition architecture shown in fig. 4 is reconfigured to partition into the partition architecture shown in fig. 7, and after the partition architecture is reconfigured, a portion of the memory space allocated by the partition architecture shown in fig. 7 mapped to the memory is shown in the right diagram of fig. 8. The partition table corresponding to the right diagram of fig. 8 is shown in table 4:

TABLE 4

Similarly, for the application scenario of deleting a partition, the above procedure is reversed, and the deleted partition is configured as a new reserve partition.

Further, according to the size of the new partition to be created, a part of the space of one reserve partition may be cut to create the new partition, or multiple reserve partitions may be merged to create the new partition by dividing a single reserve partition and/or merging multiple reserve partitions.

FIG. 9a is a flowchart illustrating an operating system upgrade according to an embodiment of the present application. The device performs the operating system upgrade as shown in figure 9a to effect an operating system upgrade that involves a reconfiguration of the partition architecture.

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

S910, an os upgrade package is obtained, and the obtaining process of the os upgrade package may refer to S510.

The operating system upgrade package includes a partition table of a partition structure corresponding to the latest version of the operating system and operating system upgrade data. The specific content of the operating system upgrade data may refer to the content of the operating system upgrade package in the upgrade flow shown in fig. 5.

The address of the same-name partition in the partition table contained in the operating system upgrade package is the same as that in the current partition table in the device memory.

For example, assume that the partition structure corresponding to the current operating system (version 1.0) of the device is shown in fig. 4, and the partition structure corresponding to the latest version of the operating system (version 2.0) is shown in fig. 7. On the device memory, the current partition structure contains a reserve partition in addition to the partitions and sub-partitions shown in fig. 4. A portion of the device's current partition table is shown in table 3. And a portion of the partition table included in the operating system upgrade package is shown in table 4. And, the operating system upgrade data includes data of the static partition child partition a.

Zip, operating system upgrade data is typically packaged as update _ base. In S910, the device acquires, while acquiring the operating system upgrade package, a description file (filelist file) for the operating system upgrade package, where the filelist file is used to describe related information of update _ base.

In the operating system upgrade package obtained in S910, the update _ base.zip includes the partition table of the partition structure corresponding to the operating system of the latest version.

Specifically, in the process of generating the operating system upgrade package and the filelist file corresponding to the operating system upgrade package:

and independently packaging the partition table images into update _ ptable.zip (packaged according to the type of the update _ base.zip), and then, typing the signature into the update _ base.zip, and then integrally signing.

Fig. 9b is a schematic diagram illustrating a configuration of internal files of an os upgrade package according to an embodiment of the present application. Zip wraps the partition table image (update _ ptable. Zip) in the root directory as shown in fig. 9 b. Zip, and can.

Adding a partition upgrade package mark in a filelist file of an operating system upgrade package, wherein the partition upgrade package mark is used for identifying that update _ base.zip in the current operating system upgrade package contains the latest version of the partition table.

Furthermore, the operating system upgrade package containing the partition table is configured as a key node package, and the key node package cannot be skipped by the cross-version upgrade operation in the process of upgrading the operating system. That is, the device must first upgrade the operating system based on the key node package (reconfigure the partition structure) before it can upgrade to the version of the operating system behind the key node package. For example, the operating system prior to version 2.0 corresponds to the partition structure shown in FIG. 4. Version 2.0 begins and the operating system corresponds to the partition structure shown in fig. 7. The operating system upgrade package for version 2.0 operating system is the critical node package. Assuming that the current os version of the device is 1.0 and the latest os is 2.1, the device cannot be upgraded to the os of version 2.1 directly, but must first be upgraded to the os of version 2.0 based on the os upgrade package of version 2.0 (the partition structure is reconfigured to the partition structure shown in fig. 7) to continue upgrading to version 2.1.

And S911, detecting whether the operating system needs to update the partition table or not during the updating of the operating system. Specifically, it is detected whether the filelist file for the os upgrade package acquired in S910 includes a partition upgrade package flag.

If not, it indicates that update _ base.zip does not contain the partition table, the partition table does not need to be updated in the current operating system upgrade, S912 is executed, the operating system upgrade is performed based on the operating system upgrade data (update _ base.zip) in the operating system upgrade package, and S912 is executed with reference to S520 to S551.

If the filelist file contains the partition upgrade package flag. Zip includes partition table, this time the operating system needs to update partition table, execute S913, restart and enter Recovery (Recovery) mode.

S914, in a Recovery mode, updating the partition table on the device memory by using the partition table in update _ base.zip;

and S920, restarting the device, sequentially loading the basic partition (Common), the static partition (A) and the dynamic partition (Super), and starting from the static partition (A).

Step S921, operating system upgrade is performed based on the operating system upgrade data (update _ base. Zip) in the operating system upgrade package, and execution of step S921 refers to step S520 to step S551.

According to the method of the embodiment shown in fig. 9a, an operating system adopting a virtual a/B upgrade scheme may be upgraded and a partition table of a device memory may be updated during the upgrade process. The upgrading scheme of the embodiment of the application greatly simplifies the operation difficulty of updating the equipment partition table and improves the user experience. According to the method of the embodiment shown in fig. 9a, an operating system adopting a virtual a/B upgrade scheme may be upgraded and a partition table of a device memory may be updated during the upgrade process; according to the method shown in fig. 9a, the device can update the partition table by itself based on the downloaded os upgrade package without preparing a burning tool; the method according to the embodiment shown in fig. 9 greatly simplifies the operation difficulty of updating the device partition table, and improves the user experience.

Specifically, the operation upgrade operation is performed by an operating system update program installed on the device. Specifically, an upgrade package acquisition tool (update apk) and an upgrade engine (update engine) are two modules in the operating system. The upgrade package acquisition tool (update apk tool) is used for acquiring an upgrade installation package of the operating system, downloading the upgrade package of the operating system and storing the upgrade package of the operating system into a user data partition (Userdata). Refer to S210.

For example, an upgrade package acquisition tool (update app) periodically initiates a package searching request to a package searching server, where the package searching 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 packet searching server searches whether an operating system installation packet (such as version 1.2) with an updated version number exists on the installation packet server or not according to the operating system version number in the packet searching request; when an operating system installation package with an updated version exists, the package searching server feeds back a download address (for example, a URL (uniform resource locator) address) of an operating system upgrade package (for example, an operating system upgrade package upgraded from version 1.1 to version 1.2) and a filelist file corresponding to the system upgrade installation package to an upgrade package acquisition tool (update app tool); and downloading the operating system upgrade package from the installation package server by an upgrade package acquisition tool (update apk package) according to the download address of the operating system upgrade package.

When the upgrade package acquiring tool (update apk) acquires the operating system upgrade package, it starts an upgrade engine (update engine), and the upgrade engine (update engine) performs the upgrade of the operating system according to the operating system upgrade package.

Specifically, after the upgrade package acquisition tool (update apk) acquires the operating system upgrade package, the upgrade package acquisition tool (update apk) sets a start attribute of an upgrade engine (update engine), 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) is true, the servicemanager starts the upgrade engine (update engine).

The upgrade package obtaining tool (update app client) obtains the state of an upgrade engine (update engine) through binder communication, and when the upgrade package obtaining tool (update app client) confirms that the upgrade engine (update engine) is started successfully, the upgrade package obtaining tool (update app client) transmits upgrade parameters to the upgrade engine (update engine) (for example, the current upgrade operation is a file update operation or a file tray-dropping operation), and triggers the upgrade engine (update engine) to enter an upgrade flow. For a specific upgrade flow, reference may be made to S520 to S551.

In an embodiment of the present application, S911 is implemented based on an upgrade package acquisition tool (update apk tool). Specifically, fig. 10 is a flowchart illustrating upgrading an operating system according to an embodiment of the present application. The device performs the operating system upgrade as shown in fig. 10 to implement the partition architecture reconfiguration.

S1000, the upgrade server pushes and releases an operating system upgrade package which is the latest version and used for updating the partition table.

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). S1000 may be executed after the device is started or before the device is started. In the state where the device is started from the static partition (a), the update apk client executes S1010 to obtain the operating system upgrade package, and the obtaining process of the operating system upgrade package may refer to S910.

S1011, the update apk clock detects whether the filelist file aiming at the operating system upgrade package contains a partition upgrade package mark. Refer to S911.

Because the operating system upgrade package obtained by the update apk client is the operating system upgrade package used for updating the partition table, the filelist file for the operating system upgrade package contains a partition upgrade package mark. Executing S1012, the update apk clock judges whether the partition table updating operation is performed by using the operating system upgrading packet. In currently executing S1012, the update apk clock determines that the partition table update operation has not been performed using the operating system upgrade package. Therefore, S1013 is performed, update apk clock performs the partition table update preparation operation.

And executing S1014 after the update apk clock completes the partition table updating preparation operation, wherein the update apk clock triggers the device to restart (first restart), and the restarted device enters a Recovery mode.

S1020, in the Recovery mode, the device updates the partition table on the device memory using the partition table in the operating system upgrade package.

In the Recovery mode, after the device completes updating of the partition table, S1021 is executed, the device is triggered to restart again (restart for the second time), and the restarted device loads the basic partition (Common), the static partition (a), and the dynamic partition (Super) in sequence and starts from the static partition (a).

When the device is started from the static partition (a), the update apk clock executes S1012 again to determine whether the partition table update operation has been performed using the operating system upgrade package. In re-executed S1012, the update apk client determines that the partition table update operation has been performed using the operating system upgrade package. Therefore, the update apk clock executes S1030, triggering update engine to enter the upgrade flow.

In the upgrading process, update engine executes S1031 to verify the operating system upgrade package. Specifically, whether the digital signature of the operating system upgrade package is legal is checked, and whether the operating system upgrade package is a legal upgrade package is confirmed.

When the operating system upgrade package passes the verification, the update engine executes S1032, and upgrades the data of the static partition and the dynamic partition according to the operating system upgrade package, specifically referring to S520, S530, and S531.

After the update engine completes the upgrade operation of S1032, the update engine executes S1033, and returns the state information of the upgrade operation completion to the update apk client.

S1040, update apk _ clock triggers a device restart (third restart), e.g., a pop-up prompt is presented to the user, who restarts immediately or later with a selection.

After the equipment is restarted, a basic partition (Common), a static partition (B) and a dynamic partition (Super) are loaded in sequence, and the equipment is started from the static partition (B). Refer to S540 and S541.

After the device is started from the static partition (B), the update apk client executes S1041, and triggers the update entry to enter merge process.

S1042, the update engine executes the merge process, refer to S551. And after the merge process is finished, the operating system of the equipment is upgraded.

Specifically, fig. 11 is a partial flowchart illustrating upgrading of an operating system according to an embodiment of the present application.

In S1010, an upgrade package acquisition tool (update apk package) acquires an operating system upgrade package and a filelist file. After that, S1011 to S1014 execute the following steps as shown in fig. 11.

S1100, analyzing the filelist file by an upgrade package acquisition tool (update apk client), and judging whether the filelist file contains a partition upgrade package mark;

if the filelist file does not contain the partition upgrade package mark, S1101, the device upgrades the operating system according to the operating system upgrade package. Specifically, an upgrade package acquisition tool (update app client) starts an upgrade engine (update engine), the upgrade engine (update engine) upgrades the static partition (B) and the dynamic partition according to the upgrade package of the operating system, the restarting device is started from the static partition (B), and the upgrade package acquisition tool (update app client) starts the upgrade engine (update engine) to perform a disk-down operation. Refer to S520 to S551.

If the filelist file includes the partition upgrade package flag, S1102 (i.e., S1012) determines whether the partition table has been updated by an upgrade package acquisition tool (update apk client).

Specifically, in S1102, the upgrade package acquisition tool (update apk) determines whether the partition table has been updated according to the state of the partition update flag bit (ptable oeminfo) stored in the metadata (/ metadata) of the common partition. When ptable oeminfo =0 (status not updated), the partition table is not updated; when ptable oeminfo =1 (state updated), the partition table has been updated; the default initial state of ptable oeminfo is 0.

When the device has not performed the partition table updating operation using the operating system upgrade package and ptable oeminfo =0, the upgrade package acquiring tool (update apk package) performs a partition table updating preparation operation, where the partition table updating preparation operation (i.e., S1013) includes S1110 to S1111:

s1110, extract update _ ptable.zip from update _ base.zip, decompress the update _ ptable.zip, and store the decompressed update _ ptable.zip in a cache partition (cache directory).

S1111, write Command (CMD) for partition table update. Specifically, a command is written into a cache partition (cache directory), and the command is used for instructing the device to execute a process of updating the partition table.

For example, update _ ptable. Zip contains the partition table image ptable. Img and hash value H1 of ptable. In S1111, a command containing an execution flow identifier (Process 1) pointing to the flow (1) is written.

The scheme (1) comprises the following steps:

calculating a hash value H2 of ptable.img;

comparison of H1 with H2;

if different, error reporting and restarting the device (after the device is restarted, loading a basic partition (Common), a static partition (A) and a dynamic partition (Super), and starting from the static partition (A));

if the current partition table of the device is the same, reading the current partition table of the device (assuming that the current partition table of the device is ptable 0);

open ptable.img (assume ptable.img is ptable1 after open);

verifying whether the starting position-ending position of the partition addresses of the partitions with the consistent names in ptable0 and ptable1 are consistent;

if the starting position and the ending position of the partition addresses of the partitions with the consistent names in the ptable0 and the ptable1 are inconsistent, the device is reported to be in error and restarted (a basic partition (Common), a static partition (A) and a dynamic partition (Super) are loaded after the device is restarted, and the device is started from the static partition (A);

if the ptable0 is consistent with the starting position-ending position of the partition addresses of all the partitions with consistent names in the ptable1, updating the current partition table on the device memory by using ptable.img (the updating of ptable0 is ptable 1);

configure ptable oeminfo =1;

restarting the device (device restart followed by loading of the base partition (Common), the static partition (a) and the dynamic partition (Super), starting from the static partition (a)).

After S1111, the update apk clock completes the partition table update preparation operation. And then executing S1112 by the update apk client, recording a breakpoint, recording the current upgrading progress of the operating system, and starting the upgrading operation of the operating system from S1102 after the equipment is restarted and enters the operating system.

After S1112, the update apk clock completes the partition table update preparation operation, and triggers device restart (first restart), specifically, the update apk clock executes S1113, and pops up a dialog box to prompt the user that the device needs to be restarted when the current operating system is upgraded.

Specifically, the execution of S1010, S1100, S1110, S1111, and S1112 may be executed in the background during the normal use of the mobile phone by the user.

Specifically, fig. 12 is a schematic view of a mobile phone operation interface according to an embodiment of the present application. When the mobile phone successfully starts the operating system, the mobile phone enters a system interface 1201 shown in fig. 12. The mobile phone performs the operating system upgrade (performs S1010, S1100, S1110, S1111, and S1112), and the display interface of the mobile phone may be the interface shown at 1202 in fig. 12, so as to show the progress of the operating system upgrade to the user. The execution of S1010, S1100, S1110, S1111, and S1112 may also be executed in the system background, and the user may switch to the system interface shown by 1201 to open another application when the mobile phone executes S1010, S1100, S1110, S1111, and S1112; alternatively, the user may switch to an application interface of another application being run by the system while the mobile phone is running S1010, S1100, S1110, S1111, and S1112, for example, a chat application interface shown at 1203.

In S1113, when the mobile phone needs to be restarted, the mobile phone outputs a restart prompt to the user, and the user confirms whether to restart immediately.

For example, fig. 13 is a schematic view of an operation interface of a mobile phone according to an embodiment of the present application. The mobile phone currently displays an interface shown as 1202 in fig. 12, and displays the operating system upgrade progress to the user. In S1113, the handset displays an interface as shown in 1303 in fig. 13, and the user confirms that the handset is restarted immediately or later.

As another example, the cell phone currently exhibits an interface such as that shown at 1203 in FIG. 12, with the user using a chat application. In S1113, the mobile phone displays the interface shown as 1301 in fig. 13, and pops up a prompt notification. The user clicks on the reminder notification and enters the interface shown in 1303 in fig. 13, and the user confirms that the reboot is immediate or a reboot later. Alternatively, the user opens the drop-down notification bar and the handset presents the interface as shown at 1302 in FIG. 13. In the drop-down notification bar, the user clicks on the reminder notification, and enters the interface shown in 1303 in FIG. 13, and the user confirms that the reboot is immediate or later.

Specifically, in S1113, if the user clicks the restart button, S1120 (i.e., S1014) is executed, the device is restarted, and the restarted device enters a Recovery (Recovery) mode.

In S1113, if the user clicks the later button, S1121 is executed, the device suspends the upgrade process, and restarts the upgrade process at a preset timing, the device restarts after the upgrade process is started, and the restarted device enters a Recovery (Recovery) mode.

FIG. 14 is a partial flow diagram illustrating an operating system upgrade according to an embodiment of the present application. After S1120 or S1121, the device reboots into a Recovery (Recovery) mode in which the device performs the flow shown in fig. 14.

Specifically, S1020 to S1021 include:

s1400, mounting cache data, specifically, mounting data under a cache directory (update _ ptable. Zip decompression content and command written in S1111);

s1410, analyzing the command, specifically, analyzing the command written in the S1111;

s1420, according to the command, calling the execution code of the flow (1).

For example, the parsing acquires an execution flow identifier (Process 1) pointing to the flow (1) in the command. And calling a prestored execution code corresponding to the execution flow (1)) of the Process1 according to the execution flow identifier (Process 1), and executing the execution code of the flow (1) so as to realize the flow (1). Specifically, in S1420, the device performs hash value check on the mounted ptable.img; verifying whether ptable.img is available after passing; img refreshes the original partition table on the device memory when ptable is available; the device is restarted after the refresh is successful (second restart).

The specific execution of S1420 refers to the description of the flow (1) in S1111.

After S1420, the device loads the base partition (Common), the static partition (a), and the dynamic partition (Super), starting from the static partition (a). After the operating system is started, the device loads the breakpoint saved in S1112, continues the operating system upgrade operation from S1102, and executes S1102 again.

S1102, an upgrade package acquisition tool (update apk) determines whether the partition table has been updated.

Specifically, in S1420, the device executes the flow (1) corresponding to the command written in S1111, and configures ptable oeminfo =1 after the partition table is successfully updated. Therefore, in S1102 executed again, when the upgrade package acquisition tool (update apk package) reads that the partition update flag bit (ptable oeminfo) stored in the metadata (/ metadata) of the common partition is ptable oeminfo =1, the partition table is updated.

Therefore, after S1102 is executed again, S1101 (i.e., S1030) is executed, and the device performs the os upgrade according to the os upgrade package. Refer to S520 to S551. Further, in S1101, after the operating system is successfully upgraded, the upgrade engine (update engine) configures ptable oeminfo =0. Specifically, in S531, the upgrade engine (update engine) configures ptable oeminfo =0.

Further, in another embodiment, S911 is implemented based on an upgrade engine (update engine). Specifically, fig. 15 is a flowchart illustrating upgrading an operating system according to an embodiment of the present application. The device performs the operating system upgrade as shown in fig. 15 to implement the partition architecture reconfiguration.

S1500, the upgrade server pushes and releases the operating system upgrade package with the latest version and used for updating the partition table.

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). S1500 may be executed after the device is started, or may be executed before the device is started. In the state where the device is started from the static partition (a), the update apk clock executes S1510 to obtain the os upgrade package, and the obtaining process of the os upgrade package may refer to S910.

S1511, the update apk clock triggers the update engine to enter the upgrading process. In the upgrade flow, update engine executes S1520 to check the operating system upgrade package. Specifically, whether the digital signature of the operating system upgrade package is legal is checked, and whether the operating system upgrade package is a legal upgrade package is confirmed.

And when the operating system upgrade package passes the verification, the update engine executes S1521, and detects whether a partition upgrade package mark is contained in a filelist file for the operating system upgrade package. Refer to S911.

Because the operating system upgrade package obtained by the update apk package is the operating system upgrade package used for updating the partition table, the filelist file for the operating system upgrade package contains a partition upgrade package mark. And S1522 is executed, and the update engine judges whether the partition table updating operation is performed by using the operating system upgrading packet. In S1522 currently executing, the update engine determines that the partition table update operation has not been performed using the operating system upgrade package. Therefore, S1523 is executed, and the update engine performs the partition table update preparation operation.

After the update engine completes the partition table update preparation operation, the update engine executes S1524 to return the state information of the completion of the partition table update preparation operation to the update apk client.

After the update apk clock confirms that the update engine completes the partition table updating preparation operation, the update apk clock executes S1530, the device is triggered to restart (first restart), and the restarted device enters a Recovery mode.

S1540, in Recovery mode, the device updates the partition table on the device memory using the partition table in the operating system upgrade package. Refer to S1020.

In the Recovery mode, after the device completes updating of the partition table, S1541 is executed, the device is triggered to restart again (restart for the second time), and the restarted device loads the basic partition (Common), the static partition (a), and the dynamic partition (Super) in sequence and starts from the static partition (a).

When the device is started from the static partition (a), the update apk clock executes S1511 again, and triggers the update engine to enter the upgrade flow. The update engine again executes S1520, verifying the operating system upgrade package.

And when the operating system upgrade package passes the verification, the update engine executes S1521 again, and detects whether the filelist file for the operating system upgrade package contains a partition upgrade package mark.

The update engine executes S1522 again, and determines whether the partition table update operation has been performed using the operating system upgrade package. In S1522, which is currently executed, update engine determines that the partition table update operation has been performed using the operating system upgrade package. Therefore, S1525 is executed to upgrade the data of the static partition and the dynamic partition according to the os upgrade package, specifically referring to S520, S530, and S531.

After the update engine completes the upgrade operation of S1525, the update engine executes S1526 and returns the status information of the upgrade operation completion to the update apk client.

S1550, update apk _ clock triggers a device restart (third restart), e.g., a pop-up prompt is presented to the user, who may restart immediately or later with a selection.

After the device is started from the static partition (B), the update apk client executes S1551, and triggers the update entry to enter merge process.

S1552, update engine executes merge process, refer to S551. And after the merge process is finished, the operating system of the equipment is upgraded.

Specifically, fig. 16 is a partial flowchart illustrating upgrading of an operating system according to an embodiment of the present application.

In S1510, the upgrade package acquisition tool (update apk tool) acquires the operating system upgrade package and the filelist file. After that, the apparatus performs the following steps to realize S1511 to S1530 as shown in fig. 16.

S1600, the upgrade package acquisition tool (update apk tool) starts an upgrade engine (update engine).

S1601, an upgrade engine (update engine) checks an operating system upgrade package.

After the verification is successful, the upgrade engine (update engine) executes S1610, analyzes the filelist file, and judges whether the filelist file contains a partition upgrade package mark;

if the filelist file does not contain the partition upgrade package flag, S1611 is executed, and the operating system is upgraded according to the operating system upgrade package. Specifically, the update engine updates the data of the static partition and the dynamic partition according to the operating system upgrade package, specifically referring to S520, S530, and S531. And the update apk (event) triggers the equipment to restart, after the equipment is restarted, the basic partition (Common), the static partition (B) and the dynamic partition (Super) are loaded in sequence, and the equipment is started from the static partition (B). After the device is started from the static partition (B), the update apk client triggers the update engine to enter the merge process. And (3) executing the merge process by the update engine, and finishing upgrading the operating system of the equipment after the merge process is finished. Refer to S520 to S551.

If the filelist file includes the partition upgrade package flag, the upgrade engine (update engine) executes S1612, and the upgrade engine (update engine) determines whether the partition table has been updated. Referring to S1102, ptable oeminfo =0, the upgrade engine (update engine) performs a partition table update preparation operation. The partition table update preparation operation includes:

s1620, extract update _ ptable.zip from update _ base.zip, decompress the update _ ptable.zip, and store the decompressed update _ ptable.zip in the cache partition (cache directory).

S1621, a Command (CMD) for the partition table update is written. Refer to S1111.

After the partition table update preparation operation is completed, update engine executes S1622, returning status information of the completion of the partition table update preparation operation to the update apk client.

After the update apk clock confirms that the update engine completes the partition table updating preparation operation, the update apk clock executes S1630, records the breakpoint, records the current upgrading progress of the operating system, and starts from S1600 when the device is restarted and enters the operating system.

S1631, S1632, and S1633 refer to S1113, S1120, and S1121.

After S1632 or S1633, the device reboots into a Recovery (Recovery) mode, in which the device performs the flow shown in fig. 14: s1400 to S1420.

After restarting the device in Recovery mode, the device loads the base partition (Common), the static partition (a) and the dynamic partition (Super), starting from the static partition (a). After the operating system is started, the device loads the breakpoint saved in S1630, and continues the operating system upgrade operation. As shown in fig. 15, the os upgrade operation starts from S1600, and executes the subsequent process again, in S1610, the upgrade engine (update engine) parses the filelist file, and determines that the filelist file includes the partition upgrade package flag.

In the Recovery mode, the device executes the flow (1) corresponding to the command written in S1621, and configures ptable oeminfo =1 after the partition table is successfully updated. Therefore, in S1612 executed again, the partition table is updated when the update engine (update engine) reads that the partition update flag bit (ptable oeminfo) stored in the metadata (/ metadata) of the common partition is ptable oeminfo =1.

Therefore, after S1612 is executed again, S1611 is executed, and the operating system is upgraded according to the operating system upgrade package.

Further, in S1611, after the operating system is successfully upgraded, the upgrade engine (update engine) configures ptable oeminfo =0. Refer to S1101.

It is to be understood that some or all of the steps or operations in the above-described embodiments are merely 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-described embodiments, and it is possible that not all of the operations in the above-described embodiments are 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 a 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 modules. 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, but the original code before compiling is also written in a specific Programming Language, which is called Hardware Description Language (HDL), and the HDL is not only one kind but many kinds, such as abll (Advanced boot Expression Language), AHDL (alternate hard Description Language), traffic, CUPL (computer universal Programming Language), HDCal (Java hard Description Language), lava, lola, HDL, PALASM, software, rhydl (Hardware Description Language), and vhul-Language (vhyg-Language), which is currently used in the field. It will also be apparent to those skilled in the art that hardware circuitry for implementing the logical method flows can be readily obtained by a mere need to program the method flows with some of the hardware description languages described above and into an integrated circuit.

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 C8051F320, 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 in purely computer readable program code means, 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 conceived to be both a software module implementing 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 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. In particular, as for the apparatus embodiment and the terminal embodiment, since they are substantially similar to the method embodiment, the description is relatively simple, and reference may be made to the description in the method embodiment for relevant points.

Claims

1. A method for upgrading an operating system is applied to an electronic device, the electronic device includes a processor and a memory, the memory includes a base partition, a first static partition, a second static partition, a dynamic partition and a user data partition, a current partition table of the electronic device is a first partition table corresponding to a first operating system, the electronic device loads data of the base partition, the first static partition and the dynamic partition after starting to run the first operating system, and after the first operating system runs, the method includes:

obtaining an operating system upgrade package, where the operating system upgrade package includes a second partition table corresponding to a second operating system and operating system upgrade data, and the operating system upgrade data is used to upgrade the first operating system to the second operating system, where addresses of partitions with the same name are configured consistently in the second partition table and the first partition table;

triggering a first reboot of the electronic device, after which the electronic device enters a recovery mode;

updating the partition table of the electronic device to the second partition table in the recovery mode;

triggering a second reboot of the electronic device, after which the electronic device loads data of the base partition, the first static partition, and the dynamic partition to run the first operating system;

and upgrading the operating system of the electronic equipment according to the operating system upgrading data, and upgrading the first operating system to the second operating system.

2. The method of claim 1, wherein before the rebooting the electronic device into the recovery mode, the method further comprises:

and executing a partition table updating preparation operation, wherein the partition table updating preparation operation is used for configuring an execution flow of the electronic equipment in the recovery mode.

3. The method of claim 2, wherein performing a partition table update preparation operation comprises:

storing the second partition table to a cache;

and writing a first control command in the cache, wherein the first control command corresponds to a first operation flow, and the first operation flow is used for updating the partition table of the electronic equipment into the second partition table.

4. The method of claim 3, wherein the first operational flow comprises:

checking the second partition table;

5. The method of claim 3, wherein in the recovery mode, updating the partition table of the electronic device to the second partition table comprises:

loading the second partition table and the first control command in the cache;

executing the execution code of the first operation flow.

6. The method according to any one of claims 2 to 5, wherein before performing the partition table update preparation operation, the method further comprises:

when the operating system upgrade package is used for updating the partition, determining whether the partition table of the electronic device has been updated based on the second partition table;

and when the partition table of the electronic equipment is not updated based on the second partition table, executing the partition table updating preparation operation.

7. The method of claim 6, wherein said ascertaining whether the operating system upgrade package is used to update a partition comprises:

and analyzing the description file corresponding to the operating system upgrading packet, wherein when the description file contains a partition upgrading packet mark, the operating system upgrading packet is used for updating the partition.

8. The method of claim 6, wherein:

the method comprises the steps of confirming whether a partition table of the electronic equipment is updated based on a second partition table or not, wherein the partition table of the electronic equipment is confirmed to be updated based on the second partition table according to the state of a partition updating flag bit, and the state of the partition updating flag bit is not updated before an operating system upgrade package is obtained;

in the recovery mode, updating the partition table of the electronic device to the second partition table, including setting the state of the partition update flag bit to be updated;

and upgrading the operating system of the electronic equipment according to the operating system upgrading data, and upgrading the first operating system to the second operating system, wherein the upgrading method comprises the step of setting the state of the partition updating zone bit to be not updated.

9. The method of any of claims 6-8, wherein prior to said upgrading an operating system of the electronic device in accordance with the operating system upgrade data, the method further comprises:

after the second restart, after the first operating system runs, confirming again whether the partition table of the electronic device is updated based on the second partition table;

and when the partition table of the electronic equipment is confirmed to be updated based on the second partition table, upgrading the operating system of the electronic equipment according to the operating system upgrading data.

10. The method of claim 9, wherein the first operating system comprises a first upgrade package capture tool and a first upgrade engine, and wherein after the first operating system is run, the method comprises:

the first upgrade package acquisition tool acquires the operating system upgrade package;

the first upgrade package acquisition tool confirms whether the operating system upgrade package is used for updating the partition;

when the operating system upgrade package is used for updating the partition, the first upgrade package acquisition tool confirms whether the partition table of the electronic device is updated based on the second partition table;

when the partition table of the electronic equipment is not updated based on the second partition table, the first upgrade package acquisition tool executes the partition table updating preparation operation;

the first upgrade package acquisition tool records a first upgrade flow breakpoint, and the first upgrade flow breakpoint corresponds to the determination of whether the partition table of the electronic device is updated based on the second partition table;

the first upgrade package acquisition tool triggers the first reboot;

after the first reboot, the electronic device enters the recovery mode, in the recovery mode, the partition table of the electronic device is updated to the second partition table, and then the partition table of the electronic device has been updated based on the second partition table;

in the recovery mode, triggering the second restart;

after the second reboot, the electronic device loads data of the base partition, the first static partition, and the dynamic partition to run the first operating system;

after the first operating system runs, the first upgrade package acquisition tool reads the first upgrade flow breakpoint, and confirms whether the partition table of the electronic device is updated based on the second partition table again;

and when the first upgrade package acquisition tool confirms that the partition table of the electronic equipment is updated based on the second partition table, the first upgrade package acquisition tool triggers the first upgrade engine to upgrade the operating system of the electronic equipment according to the operating system upgrade data.

11. The method of claim 9, wherein the first operating system comprises a second upgrade package capture tool and a second upgrade engine, and wherein after the first operating system is run, the method comprises:

the second upgrade package acquisition tool acquires the operating system upgrade package;

the second upgrading package obtaining tool triggers the second upgrading engine to enter an upgrading process;

the second upgrade engine confirms whether the operating system upgrade package is used for updating the partition;

when the partition table of the electronic equipment is not updated based on the second partition table, the second upgrading engine executes the partition table updating preparation operation;

the second upgrading engine returns the state information of the completion of the updating preparation operation of the partition table to the second upgrading packet acquisition tool;

the second upgrade package acquisition tool records a second upgrade flow breakpoint, and the second upgrade flow breakpoint corresponds to the second upgrade package acquisition tool and triggers the second upgrade engine to enter an upgrade flow;

the second upgrade package acquisition tool triggers a third reboot of the electronic device;

after the third restart, the electronic device enters the recovery mode, in the recovery mode, the partition table of the electronic device is updated to the second partition table, and then the partition table of the electronic device is updated based on the second partition table;

in the recovery mode, triggering a fourth reboot of the electronic device;

after the fourth reboot, the electronic device loading data of the base partition, the first static partition, and the dynamic partition to run the first operating system;

after the first operating system runs, the second upgrade package acquisition tool reads the second upgrade flow breakpoint and triggers the second upgrade engine to enter the upgrade flow again;

the second upgrade engine reconfirming whether the operating system upgrade package is used for updating the partition;

12. The method of claim 1, wherein the operating system upgrade data further comprises static partition upgrade data and dynamic partition upgrade data, and wherein upgrading an operating system of the electronic device according to the operating system upgrade data comprises:

creating a virtual dynamic partition in the user data partition, and writing the dynamic partition upgrade data into the virtual dynamic partition;

changing the starting sequence of the electronic equipment from starting from the first static partition to starting from the second static partition;

triggering a third restart of the electronic device;

after the third reboot, the electronic device loading data of the base partition, the second static partition, the dynamic partition, and the virtual dynamic partition to run the second operating system;

13. An electronic device, comprising a processor and a memory, the memory including a base partition, a first static partition, a second static partition, a dynamic partition, and a user data partition, the dynamic partition including a plurality of sub-partitions, the processor configured to execute software code stored on the memory to cause the electronic device to load data of the base partition, the first static partition, and the dynamic partition upon startup to run a first operating system;

and after the first operating system is run, causing the electronic device to perform the method flow of any of claims 1-12.

14. 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 12.

15. A computer program product, characterized in that it comprises a computer program which, when run on a computer, causes the computer to perform the method according to any one of claims 1 to 12.