CN117873511A

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

Info

Publication number: CN117873511A
Application number: CN202311674113.5A
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: 2024-04-12
Also published as: CN115686584A; WO2023005370A1; CN115686584B; EP4202649A4; EP4202649A1; US20230229424A1

Abstract

The embodiment of the application provides a method, equipment, a storage medium and a computer program product for upgrading an operating system, which comprise the following steps: acquiring an operating system upgrade package, wherein the operating system upgrade package comprises a second partition table and operating system upgrade data, and address configuration of partitions with the same name in the second partition table and the first partition table is consistent; triggering the first restarting of the electronic equipment, and after the first restarting, entering a recovery mode by the electronic equipment; updating the partition table of the electronic equipment into a second partition table in a recovery mode; triggering a second restart of the electronic device, and after the second restart, loading data of the basic partition, the first static partition and the dynamic partition by the electronic device 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 into 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 invention relates to the field of computer technology, and in particular, to an operating system upgrade method, apparatus, storage medium, and computer program product.

Background

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

After the terminal equipment installs the operating system, when the version of the operating system is updated, the operating system installed on the terminal equipment needs to be updated. Generally, the partition architecture of the operating system of the terminal device is planned in advance on the memory of the terminal device. The upgrade of the operating system is mainly to update the operating system data under the original operating system partition architecture. However, in making certain, more widely changed version upgrades, it is necessary to change the partition architecture of the operating system, e.g., add partitions or delete partitions. Thus, there is a need for an operating system upgrade method that supports an adjusted partition architecture.

Disclosure of Invention

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

In a first aspect, an embodiment of the present application provides a method for upgrading an operating system, applied to 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, a current partition table of the electronic device is a first partition table corresponding to a first operating system, after the electronic device is started, data of the base partition, the first static partition, and the dynamic partition are loaded to run the first operating system, and after the first operating system is run, the method includes:

acquiring 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, the operating system upgrade data are used for upgrading the first operating system to the second operating system, and the operating system upgrade data comprise dynamic partition upgrade data, wherein address configurations of partitions with the same names are consistent 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 to the second partition table in the recovery mode;

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

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

triggering a third restart of the electronic equipment;

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

and after the second operating system operates, the data of the virtual dynamic partition is dropped to the dynamic partition.

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 equipment memory is updated in the upgrading process; according to the scheme of the first aspect of the application, the equipment can automatically complete updating of the partition table based on the downloaded operating system upgrade package without preparing a burning tool; 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 one implementation manner of the first aspect, the operating system upgrade data further includes static partition upgrade data;

the method further includes, prior to creating a virtual dynamic partition in the user data partition, upgrading data of the second static partition based on the static partition upgrade data.

In an implementation manner of the first aspect, before the triggering the third reboot of the electronic device, the method further includes modifying a boot sequence of the electronic device from being started from the first static partition to being started from the second static partition.

In one implementation of the first aspect, the method further includes generating the second partition table.

In an implementation manner of the first aspect, the first partition table includes a first reserved partition; the generating the second partition table includes:

leaving the other partitions in the first partition table except the first reserved partition unchanged, and creating a new partition based on all or part of the space of the first reserved partition.

In an implementation manner of the first aspect, the generating the second partition table includes:

keeping other partitions except the first partition in the first partition table unchanged, deleting the first partition, and creating a space of the first partition as a second reserved partition;

Or,

and keeping other partitions except the first partition and the first reserved partition in the first partition table unchanged, and merging the first partition and the first reserved partition into a second reserved partition.

In an implementation manner of the first aspect, before restarting the electronic device and entering the recovery mode, the method further includes:

and executing a partition table update preparation operation, wherein the partition table update 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:

saving 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.

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 checked, verifying whether address configurations of the partitions with the same names 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 an implementation manner of the first aspect, in the recovery mode, updating the partition table of the electronic device to the second partition table includes:

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

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 operation flow.

In an implementation manner of the first aspect, before the performing a 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, confirming whether the partition table of the electronic equipment is updated based on the second partition table;

and executing the partition table update preparation operation when the partition table of the electronic device is not updated based on the second partition table.

In an implementation manner of the first aspect, the determining whether the operating system upgrade package is used to update a partition includes:

And analyzing a 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 a partition upgrade package mark.

In one implementation of the first aspect:

determining whether the partition table of the electronic device has been updated based on the second partition table, wherein determining, according to a state of a partition update flag bit, whether the partition table of the electronic device has been updated based on the second partition table, and before the operating system upgrade package is obtained, determining that the state of the partition update flag bit is not updated;

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

and after the second operating system runs and the data of the virtual dynamic partition is dropped to the dynamic partition, the method further comprises setting the state of the partition update flag bit as not updated.

In an implementation manner of the first aspect, before the creating a virtual dynamic partition in the user data partition, the method further includes:

After the second restart, after the first operating system is running, again confirming 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 device is confirmed to be updated based on the second partition table, executing the steps of creating a virtual dynamic partition in the user data partition and writing the dynamic partition upgrading data into the virtual dynamic partition.

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

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 a partition;

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

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

The first upgrade package acquisition tool records a first upgrade process breakpoint corresponding to whether the partition table of the electronic equipment is updated based on the second partition table;

the first upgrade package acquisition tool triggers the first restart;

after the first restart, the electronic device enters the recovery mode, in which 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;

triggering the second restart in the recovery mode;

after the second restart, the electronic device loads the data of the basic 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 breakpoint of the first upgrade process, and confirms again whether the partition table of the electronic equipment is updated based on the second partition table;

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 create a virtual dynamic partition in the user data partition, and writes the dynamic partition upgrade data into the virtual dynamic partition.

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

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

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

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

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

when the partition table of the electronic device is not updated based on the second partition table, the second upgrade engine executes the partition table update preparation operation;

the second upgrade engine returns the state information of the completion of the execution of the partition table update preparation operation to the second upgrade package acquisition tool;

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

The second upgrade package acquisition tool triggers the first restart of the electronic equipment;

triggering the second restart of the electronic device in the recovery mode;

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

the second upgrade engine again 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 second upgrade engine confirms again whether the partition table of the electronic device has been updated based on the second partition table;

when the partition table of the electronic device has been updated based on the second partition table, the second upgrade engine creates a virtual dynamic partition in the user data partition, writing the dynamic partition upgrade data to the virtual dynamic partition.

In a second aspect, the present application proposes an electronic device, the electronic device comprising a processor and a memory, the memory comprising a base partition, a first static partition, a second static partition, a dynamic partition, and a user data partition, the dynamic partition comprising a plurality of sub-partitions, the processor being configured to execute software code stored on the memory, such that the electronic device loads data of the base partition, the first static partition, and the dynamic partition after boot-up to run a first operating system;

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

In a third aspect, the present application proposes a computer readable storage medium having stored therein a computer program which, when run on a computer, causes the computer to perform the method as in 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 as in the first aspect.

Drawings

In order to more clearly illustrate the technical solutions of the embodiments of the present application, the drawings that are needed in the embodiments will be briefly described below, it being obvious that the drawings in the following description are only some embodiments of the present application, and that other drawings may be obtained according to these drawings without inventive effort for a person skilled in the art.

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

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

FIG. 3 is a flow chart illustrating an upgrade to an operating system according to one embodiment of the present application;

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

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

fig. 6 is a schematic diagram of a burning system frame structure for performing system burning before shipping according to an embodiment of the present application;

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

FIG. 8 is a diagram illustrating a partition architecture for reconfiguring a partition architecture according to one embodiment of the present application;

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

FIG. 9b is a diagram illustrating an internal file configuration of an OS upgrade package according to one embodiment of the present application;

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

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

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

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

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

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

FIG. 16 is a partial flow chart illustrating an operating system upgrade according to one embodiment of the present application.

Detailed Description

For a better understanding of the technical solutions of the present application, embodiments of the present application are described in detail below with reference to the accompanying drawings.

It should be understood that the described embodiments are merely some, but not all, of the embodiments of the present application. All other embodiments, based on the embodiments herein, which would be apparent to one of ordinary skill in the art without making any inventive effort, are intended to be within the scope of the present application.

The terminology used in the embodiments of the application is for the purpose of describing particular embodiments only and is not intended to be limiting of the application. As used in 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 way of describing an association of associated objects, meaning that there may be three relationships, e.g., a and/or b, which may represent: the first and second cases exist separately, and the first and second cases exist separately. In addition, the character "/" herein generally indicates that the front and rear associated objects are an "or" relationship.

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

Generally, partition tables are used to describe the partition deployment of memory in a device, defining the starting address and size of each partition. Partition tables are typically maintained at the disk head of the memory of the device, and each partition on the memory may be located by reading the partition table at device start-up.

Take a disk with a globally unique identification partition table (GUID 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 the 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. The partition table is stored in the GPT partition; the Userdata is used for storing personal data of a user, such as APP personally installed by the user, pictures, documents, videos and the like personally stored by the user; the x-loader partition, bootloader partition, boot partition, vendor-boot partition and Super partition are used for storing operating system data.

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

TABLE 1

In table 1, AD1 to AD6 represent different address strings, respectively. The address string is 16 digits, and the address string plus 1 represents an offset of one memory bit (bit), one Byte (Byte) per 8 memory bits, 1KB per 1024 bytes, and 1MB per 1024 KB. For example:

AD1 is a 0x000000FF offset 256KB of memory bits, namely 0x002000FF;

the addresses of the x-loader are 0x 00000100-0 x002000FF, and the sizes of the 0x 00000100-0 x002000FF are 256KB;

the AD1+1 is 0x000200FF offset by one storage bit, namely 0x00200100;

AD2 is AD1 (0 x002000 FF) offset by 600KB, i.e. 0x006B00FF; the addresses of bootloader are 0x 00200100-0 x006B00FF, and the sizes of 0x 00200100-0 x006B00FF are 600KB.

Suppose that after the operating system is upgraded 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 present application. Assume that the partition architecture of the version 2.0 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 the AD3 offset 32MB of storage bits; AD22 is the storage bit of AD21 offset 32MB. In the partition structure of table 2, the size of Super is reduced by 32MB as 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, and the partition architecture of the operating system of version 2.0 corresponds to the partition architecture shown in fig. 2, the partition architecture shown in fig. 1 is not the same as the partition architecture shown in fig. 2, and therefore, in the process of upgrading the operating system on the device from version 1.0 to version 2.0, it is first necessary to reconfigure the partition architecture on the device memory from the partition architecture shown in fig. 1 to the partition architecture shown in fig. 2. That is, the partition table stored in the GPT is updated from table 1 to table 2.

It will be appreciated that the start address-end address of the vendor-boot partition and the Super partition shown in table 2 are changed compared with the respective partition start address-end addresses shown in table 1, and thus, if the partition table is refreshed from table 1 to table 2 (the partition architecture is reconfigured), the data on 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, the data in the vendor-boot partition and the Super partition is unchanged, and after the partition table is updated from table 1 to table 2, the data needs to be rewritten for 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 data re-write to all operating system data partitions after refreshing the partition table.

Specifically, fig. 3 is a flowchart illustrating an upgrade of 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 into 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 an operating system with version 2.0;

s310, restarting the device to enter a Recovery mode;

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

s321, extracting a partition table in an operating system upgrade package, and replacing a partition table in a GPT partition of a device memory by using the partition table in the operating system upgrade package; prior to S321, the partition table in the GPT partition is shown in Table 1;

s322, respectively extracting mirror image data of a bootloader partition, a boot partition, an A partition, a vendor-boot partition and a Super partition in an operating system upgrade package, and recovering the mirror image data to the mirror image data of the bootloader partition, the boot partition, the A partition, the vendor-boot partition and the Super partition according to partition start addresses-stop addresses shown in the table 2;

S330, restarting the device and starting the operating system.

Although the adjustment of the partition architecture of the operating system may be implemented based on the flow shown in fig. 3, with the increasing data security requirements, in some operating systems, access to user personal data in a Recovery mode is prohibited, which makes it impossible for a device to re-write operating system data in a partition in the Recovery mode.

Taking an android system adopting a virtual a/B upgrade mode 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 base partition (Common), a static partition (a), a static partition (B), a dynamic partition (Super), and a user data partition (Userdata).

The user data partition (Userdata) is used to store personal data of the user, such as APP installed by the user, pictures, documents, and videos stored by the user. The data stored in the base portion is system data that does not participate in an operating system upgrade. The static partition (a) and the static partition (B) are structurally corresponding to each other, and the sub-partition naming is 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 start-up, it starts from a static partition. For example, the device boots from static partition (a): sequentially loading a basic partition (Common), a static partition (A) and a dynamic partition (Super); the device boots from static partition (B): the base partition (Common), the static partition (B), and the dynamic partition (Super) are loaded in sequence.

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

FIG. 5 is a flow chart illustrating an operating system upgrade for the operating system data storage structure of the embodiment of FIG. 4, the device implementing the operating system upgrade according to the flow chart shown in FIG. 5 when the device is currently booted from the static partition (A).

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

S510, the device acquires an operating system upgrade package.

For example, in one possible implementation, the device periodically initiates a search request to the search server, where the search request contains the version number (e.g., version 1.1) of the operating system currently running by the device; the packet searching server searches whether an operating system installation packet (for example, version 1.2) with an updated version number exists currently according to the version number of the operating system in the packet searching request; when an operating system installation package of an updated version exists, the package searching server feeds back a download address of an operating system upgrade package (for example, a system increment upgrade installation package upgraded from version 1.1 to version 1.2) to the device; and the equipment downloads the operating system upgrade package according to the download address of the operating system upgrade package.

S520, the device performs data writing operation on the static partition (B) according to the operating system upgrade package to upgrade the static partition.

In the execution 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 that the upgrade failed), automatically re-upgrade or determine by the user whether to re-upgrade or abort the upgrade.

To detect whether the static partition upgrade fails in S520, data verification is performed on the static partition (B) after the data writing to confirm whether the static partition data is successfully written.

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

For another example, in an application scenario, a system upgrade installation package for version 1.1 to version 1.2 includes differential data for version 1.1 to version 1.2 static partition, hash values for the full amount of data for version 1.1 static partition, and hash values for the full amount of data for version 1.2 static partition.

Before writing data into a 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 a system upgrade installation package of version 1.1 to version 1.2, and if so, indicates that 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 to version 1.2 is available; if not, the differential data of the static partition of the version 1.1 to the version 1.2 is not available and the upgrade fails.

After the device determines that the differential data of the static partition of the version 1.1 is updated to the version 1.2 is available, reading the data in the static partition (A), performing reduction by using the differential data of the static partition of the version 1.1 updated to the version 1.2 and the data in the static partition (A) to obtain the total data of the static partition of the version 1.2, and overwriting the total data of the static partition of the version 1.2 into the static partition (B). After the data is written, the device calculates the hash value of the data in the static partition (B), and verifies whether the hash value of the data in the static partition (B) is consistent with the hash value of the total data of the static partition of the version 1.2 in the system upgrade installation package of the version 1.1 to the version 1.2. If the data is consistent, the data is written successfully, and the subsequent operation system upgrading operation can be performed; if the data is inconsistent, 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 from version 1.1 to version 1.2 includes the following data:

name boot (partition Name, representing the current data as upgrade data pointing to a child partition boot of a static partition)

Start 12222 (data block Start Address, starting position 12222 of upgrade data (differential data DELTA 1) representing child partition boot of static partition)

size 2410 (data size, size of upgrade data (differential data DELTA 1) representing child partition boot of static partition) is 2410

HASH11 (HASH value of data of child partition boot of static partition of version 1.1)

Mirror target HASH value HASH12 (HASH value of data of child partition boot of static partition of version 1.2)

DELTA1 (version 1.1 upgrade to version 1.2 static partition differential data)

In S520, the device reads the device' S fixed mount path, e.g.,/dev/block/by-name/mis, through the mis partition in the common partition. And reading a slot bit (slot-b) from the UFS device, and replacing to obtain a sub-partition path, such as/dev/block/by-name/boot_b.

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

When the HASH value of the data under the/dev/block/by-name/boot_a is consistent with the HASH value HASH11, the device reads DELTA1 based on the Start:12222 and the size:2410, and uses the data under DELTA1 and/dev/block/by-name/boot_a to perform reduction to obtain the total data of the sub-partition boot of the static partition of the version 1.2. The device writes the full amount of data of the child partition boot of the static partition of version 1.2 under/dev/block/by-name/boot_b.

After the data is written, the device calculates the HASH value of the data under the condition of/dev/block/by-name/boot_b, checks whether the HASH value of the data under the condition of/dev/block/by-name/boot_b is consistent with the HASH value HASH12, if so, the boot upgrading 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-partition of the static partition according to the upgrade data of the sub-partition of the static partition included in the system upgrade installation package, specifically, if the system upgrade installation package includes upgrade data of a certain sub-partition of the static partition, the sub-partition of 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 upgrade data of a certain sub-partition of the static partition, the data of the sub-partition of the static partition (a) is directly synchronized to the sub-partition of the static partition (B). In the upgrading process, when one sub-partition has upgrading errors and hash check fails, the upgrading operation is interrupted and the upgrading fails; when all the sub-partitions are successfully upgraded, the static partition is successfully upgraded, and the subsequent steps can be executed.

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

For example, in S520, before upgrading the data of the static partition (B), the static partition (B) is marked as not bootable. Specifically, the status flag of the static partition is stored in the Common partition. In S520, slot-B in the status flags of the static partitions in the Common partition are marked as unbootable before upgrading the data of the static partition (B). After S520 is successfully performed (all hash checks are successful), the static partition (B) is marked as bootable. For example, after S520, slot-b in the status flags of the static partitions in the Common partition is marked as bootable.

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

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

Taking the system sub-partition as an example, assume that in version 1.1, the data in the system sub-partition can be divided into two parts, system1 and system 2. The data system2 is updated from version 1.1 to version 1.2, and the data system1 is updated 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, the system delta upgrade installation package for version 1.1 to version 1.2 contains the dynamic partition (Super) update data for version 1.1 to version 1.2, which contains data system3.

Further, in the virtual A/B upgrade scheme, incremental upgrades of dynamic partitions (Super) are implemented based on snapshot technology (snapshot). Specifically, in a virtual dynamic partition of a user data partition (Userdata), upgrade data of the dynamic partition (Super) is saved by using Copy-On-Write (COW) files.

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) to which the COW file is directed.

In the operating system upgrade package acquired in S510, the COW file of the upgrade data of the dynamic partition (Super) is compressed and saved in the form of binary code. In the operating system upgrade package, each COW file is named according to the dynamic partition (Super) sub-partition for which it is intended. For example, a COW file for a system sub-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 appends an A/B partition flag to each COW file. Specifically, when the device is currently started from the static partition (a), it can be understood that the dynamic partition (Super) loaded by the device currently running the operating system is the dynamic partition (a). When the operating system is upgraded, the virtual dynamic partition created in the user data partition (Userdata) is for the dynamic partition (B). Therefore, the name tag_b of the corresponding dynamic partition (B) is attached to the COW file. For example, system_b-cow-img.img.0000 is generated for system-cow-img.img.0000 with the addition of_b.

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 to 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 child partition of a dynamic partition (Super) for which the COW file is directed. The file map of the sub-partition of the dynamic partition (Super) is used to describe all files in the sub-partition of the dynamic partition (Super) and the save addresses of the respective files of the operating system of the current version (version before the current upgrade, e.g., version 1.1).

The upgrade data in the COW file is updated files in the new version of sub-partition data compared with the current version of sub-partition data; the COW file map of the COW file itself is used for describing the correspondence between the updated file and the files 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 corresponding file in the sub-partition of the dynamic partition (Super) can be replaced by the upgrade data in the COW file, so that the upgrade of the dynamic partition (Super) data is realized. Specifically, when the file map of the sub-partition of the dynamic partition (Super) needs to be acquired, 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). When an operating system upgrade package is created, a file map of a sub-partition of a dynamic partition (Super) may be created in advance, and the file map may be added to a COW file.

Taking the system sub-partition as an example, assume that data is saved in the system sub-partition according to the following path:

/system/app/A0.XXX；

/system/app/A1.XXX；

/system/app/A2.XXX；

/system/B0.XXX；

/system/B1.XXX；

/system/user/C0.XXX；

/system/user/C1.XXX；

/system/user/C2.XXX；

/system/user/C3.XXX。

the file map for the 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 in 024010 ～ 024013) is the physical save address (block address) of the file in the system sub-partition of the dynamic partition (Super).

Suppose that a current operating system upgrade requires update data/system/app/a 2.Xxx and/system/user/c 2.Xxx.

It can be considered that:

System/app/A2.XXX and/system/user/C2. XXX are the system1 portion of the 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 part of system2 of the system sub-partition data.

Then the COW file for the system sub-partition (system_b-COW-img. 0000) contains the latest version of/system/app/a 2.Xxx and/system/user/c 2.Xxx.

It can be seen that the latest version of/system/app/a 2.Xxx and/system/user/c 2.Xxx is system3. The goal of the upgrade is to update system1 using 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): the starting address start:024018 (offset from system start address); offset size:2 (i.e. 024018 ～ 024020 address field data)

Map2 (address of update data stored in cow file): the starting address start:045033 (offset from the start address of the cow file store); offset size:2 (i.e., 045033 ～ 045035 address field data);

/system/user/C2.XXX：

Map1 (address of data to be updated in original super partition): the starting address start:024036 (offset from system start address); offset size:4 (i.e. 024036 ～ 024040 address field data)

Map2 (address of update data stored in cow file): the starting address start:045036 (offset from the start address of the cow file store); offset size:4 (i.e., 045036 ～ 045040 address field data);

the values (045033 ～ 045035 and 045036 ～ 045040) after the file names are the physical save addresses (block addresses) of the latest version of the system/app/a2.Xxx and/system/user/c 2.Xxx in the COW file (system_b-COW-img. 0000) in the user data partition (Userdata), respectively.

Thus, if A2.XXX at address 045033 ～ 045035 is used to replace A2.XXX at address 024018 ～ 024020 and C2.XXX at address 024036 ～ 024040 is used to replace C2.XXX at address 045036 ～ 045040, a data upgrade of the system sub-partition of the dynamic partition (Super) may be accomplished.

After the COW file is successfully written into the user data partition (Userdata), the dropped state information in the metadata partition (/ metadata) of the base partition (Common) is changed from "dropped (merge)" to "not dropped (wait for merge)". The landing status information is used to indicate whether there is a COW file currently that needs landing to a dynamic partition (Super). Specifically, the drop status information includes an overall identification for a dynamic partition (Super) and a sub-partition identification for each sub-partition. When the whole mark is 'dropped', all sub-partitions representing the dynamic partition (Super) do not need to be dropped; when the overall identifier is "no disk for merge", one or more sub-partitions representing dynamic partitions (Super) need to perform a disk-drop operation; when the sub-partition is identified as "dropped (merge)", it is representative that the sub-partition does not need to perform a drop operation; when a child partition is identified as "not dropped (wait for merge)", it represents that the child partition needs to be dropped.

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

Specifically, fig. 6 is a schematic diagram of a burning system frame structure for performing system burning before leaving the factory of the device in an application scenario. In the android system adopting the virtual A/B upgrading mode, only the static partition adopts the A/B scheme, and the dynamic partition adopts the scheme for constructing the virtual dynamic partition during upgrading. Therefore, for matching the static partition and the dynamic partition, as shown in fig. 6, the metadata (/ supermetadata) of the header of the dynamic partition (Super) includes Slot0 (Slot one data) corresponding to the static partition (a) and Slot1 (Slot two data) corresponding to the static partition (B). Slot0 and Slot1 are used to store the partition table for the Super partition.

For example, in the MBR of UFS, in the device boot sequence description, 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 the different static partitions started, selecting to acquire partition information of the Super partition from one of Slot0 or Slot 1. For example, when the device is started by the static partition a, when loading the Super partition, 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, the device first reads Slot1 to obtain the child partition address of the Super partition when loading the Super partition.

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

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

a Group (Group) entry whose value is a child partition type;

an attribute (Attributes) item whose value is a partition read-write attribute, for example, a read-only attribute (read only);

an 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 the static partition (A); the suffix of the value is B, then it corresponds to static partition (B).

When the Super partition is loaded, starting with static partition A, slot0 is read first. When the Slot0 is read, because the suffix is that the_a corresponds to the static partition (A), the device reads the value of the names item in the Slot0 and/or the values of the extensions item in the partition description Group of which the Group item suffix is that the_a so as to acquire the sub-partition address of the Super partition.

When the Super partition is loaded, starting with static partition B, slot1 is read first. When the Slot1 is read, because the suffix is_b, the device reads the value of the Name item in the Slot0 and/or the value of the extensions item in the partition description Group of which the suffix is_b, so as to obtain the sub-partition address of the Super partition.

In S510, the obtained operating system upgrade package contains partition information of a dynamic partition (Super) of version 1.2, and in S530, the device extracts partition information of the dynamic partition (Super) of version 1.2 from the operating system upgrade package, and refreshes partition information in Slot1 corresponding to the static partition (B) using the partition information of the dynamic partition (Super) of version 1.2.

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

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 operating system upgrade package acquired in S510, partition information of the dynamic partition (Super) of version 1.2 includes the following:

Name:system

Group:ry_dynamic_partitions

Extents:0..699XXXX linear super 2048

in S530, the device locates, for the static partition (B), the Slot1 of the dynamic partition (Super) corresponding to the static partition (B) by the static partition that is currently in need of upgrade, and refreshes the content in the Slot1 using partition information of the dynamic partition (Super) of version 1.2. After S530, the Slot1 of the dynamic partition (Super) and/or supermetadata includes 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 that S530 execution 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 that the upgrade failed), automatically re-upgrade or determine by the user whether to re-upgrade or abort the upgrade. (referring to static partition data write failure in S520)

Specifically, S530 may fail to execute when the storage space of the user data partition (Userdata) is insufficient. In S530, in the process of creating a virtual dynamic partition in a user data partition (Userdata) according to the operating system 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 operating system upgrade package. S530 execution fails when the free space on the user data partition (Userdata) is insufficient to create a virtual dynamic partition.

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 includes 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 the COW file name and COW file size in the 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 the system sub-partition as an example, in the operating system upgrade package, the COW file for the system sub-partition is named system-COW-img.img.0000, and the size of 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 creation is completed, the device can extract system_cow-img.img.0000 from the system upgrade installation package, write system_b-cow and rename system_b-cow-img.img.0000.

The device creates an empty COW file system_b-COW, system_ext_b-COW, vendor_b-COW, product_b-COW, cure_b-COW, 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 and rename the same.

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 at a time, and creates the next one after the creation of one empty COW file is successful. In this process, when an empty COW file fails to be created, it indicates that the storage space of the user data partition (Userdata) is insufficient, and S530 fails to execute, and the operating system upgrade fails.

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

Further, in S530, the write failure of the COW file may also result in the execution failure of S530. In order to detect whether writing of the COW file is successful, in S530, after writing the COW file into the user data partition (Userdata), it is further necessary to perform overall verification on the dynamic partition (Super) +cow file, verify the validity of the dynamic partition (Super) +cow file, and verify whether the result of synthesizing the dynamic partition (Super) data of the current version and the COW file is the dynamic partition (Super) data of the new version.

Specifically, taking upgrading from version 1.1 to version 1.3 as an example, calculating a hash value of a synthetic result of data (unchanged data from version 1.1 to version 1.2) which does not need to be upgraded in the dynamic partition (Super) and upgrading data (data which needs to be upgraded from version 1.1 to version 1.2) in the COW file, judging whether the hash value is consistent with the hash value of the complete data of the dynamic partition (Super) in version 1.3, and if so, indicating that the COW file is valid; if the COW files are inconsistent, the COW files are invalid, the upgrading is failed, the upgrading process is interrupted, and errors are reported; wherein, the hash value of the complete data of the dynamic partition (Super) in version 1.3 is saved in the operating system upgrade package.

Specifically, during the verification process, dynamic partition (Super) +cow files are merged based on snapshot. In the implementation process of the snapshot, the combination of the dynamic partition (Super) and the COW file is not combination in a physical sense, but the whole file map of the system sub-partition is combined with the COW file map of the COW file itself, so as to generate a file map of the new version of sub-partition data.

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

/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 (3) map with the COW file:

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

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

and (5) merging. A new version of the file map for the system child partition is obtained:

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

(A0.XXX pointing to dynamic partition (Super)/system/app)

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

(A1. XXX pointing to dynamic partitioning (Super)/system/app)

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

(A2.XXX in user data partition (Userdata)/Update/system_b-cow-img. 0000)

/system/B0.XXX：024021～024026；

(B0.XXX in dynamic partition (Super)/under system)

/system/B1.XXX：024027～024028；

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

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

(C0.XXX pointing to dynamic partitioning (Super)/system/user)

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

(C1.XXX pointing to dynamic partitioning (Super)/system/user)

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

(directed to C2.XXX in user data partition (Userdata)/Update/system_b-cow-img.img.0000)

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

(C3.XXX pointing to dynamic partitioning (Super)/system/user)

In the new version of the system sub-partition's file map,/system/app/A2. XXX's save address is not directed to/system/app/A2. XXX on the dynamic partition (Super) on memory, but to A2.XXX in system_b-cow-img.img.0000 in the user data partition (Userdata) on memory; the save address of/system/user/C2. XXX is not directed to/system/user/C2. XXX on a dynamic partition (Super) on memory, but to C2.XXX in a system_b-cow-img.img.0000 in a user data partition (Userdata) on memory.

In the verification process, according to the above synthesis method, a new version of the file map of all the sub-partitions of the dynamic partition (Super) is obtained (if the corresponding COW file of a certain sub-partition is not written in the user data partition (Userdata), the file map of the sub-partition is directly used as the new version of the file map). Combining the file maps of the new versions of all the sub-partitions generates a file system of the new version of the dynamic partition (Super).

Based on the file system read data of the new version of the dynamic partition (Super), all files contained in the file system of the new version of the dynamic partition (Super) are read and hash values are calculated.

S531, changing the starting sequence of the device from the starting from the static partition (A) to the starting from the static partition (B).

For example, the boot sequence identifier of the master boot record (Master Boot Record, MBR) is rewritten, and the boot sequence identifier 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 starts from the static partition (A), and the static partition (A) is loaded in the starting process; when the device reads the starting sequence identifier as 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.

S532, restarting the device. 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 a basic partition (Common) and a static partition (B) in sequence.

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

Specifically, the device reads the disk-drop status information in the metadata (/ metadata), determines whether the COW file needs to be retrieved from the specified path of the user data partition (Userdata) based on the disk-drop status information, and loads the dynamic partition (Super) and the COW file by adopting the snapshot merge.

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

Specifically, in S541, when the corresponding COW file exists at the first 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 the new version of the file map may refer to S530. The device determines files to be loaded according to the operation requirement of an operating system, and loads the files based on a file map of a new version of a dynamic partition (Super) sub-partition.

For example, operating system running requirements load all data in a directory user (/ system/user) under a system sub-partition. The device reads the disk-drop status information in the metadata (/ metadata), and the sub-partition of the system sub-partition in the disk-drop status information is identified as "no disk for merge", so the device searches the COW file in the user data partition (Userdata) under Update, and after searching the COW file system_b-COW-img.img.0000 under Update, generates a file map of a new version of the system sub-partition from the file map of the COW file in the system_b-COW-img.img.0000 based on the snapshot. Data loading is performed according to the storage addresses of all files in the file map of the new version of the system sub-partition/under the system/user, for example, according to the file map of the new version 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 address 024029 ～ 024032, c1.xxx at address 024033 ～ 024035, c2.xxx at address 045036 ～ 045040, and c3.xxx at address 024041 ～ 024044 are loaded.

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

Further, when all data in the directory user (/ system/user) under the system sub-partition is loaded, when the sub-partition identifier of the system sub-partition in the drop state information is "no drop (wait for merge)", if the device does not search the COW file of the corresponding system sub-partition in the user data partition (Userdata) or under Update, it indicates a data writing error (COW file writing error or drop state information writing error) in the upgrading process, and at this time, the device rolls back the system and reports the error.

Further, in S541, the device also needs to verify the loaded file before loading the file. Unlike S530, in S541, the dynamic partition (Super) +cow file is not authenticated as a whole, but only the file to be loaded. For example, checking is performed based on dm-quality (dm-quality is a target of dm (device mapper), which is a virtual block device, specifically used for checking of the file system). And if the verification is successful, loading the file, and if the verification is failed, restarting the device, rolling back the system or attempting to load the file again.

S550, the device is successfully started and enters the user interaction interface.

S551, the device drops the data of the virtual dynamic partition to the dynamic partition (Super).

In the description of the present application, the disc-drop operation refers to writing, in an operating system upgrade process, 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), so that the file of the dynamic partition (Super) completes data upgrade, so that the device does not need to load the dynamic partition (Super) and the virtual dynamic partition when being started next time, and only needs to load the dynamic partition (Super) to complete device startup.

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

If the drop status information is "no drop (wait for merge)", the upgrade process drops the COW file in the user data partition (Userdata) into the dynamic partition (Super).

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

For example, in a system sub-partition based file map/system/app/a 2.Xxx:024018 ～ 024020/system/app/a 2.Xxx in COW file map: 045033 ～ 045035 writing the data at address 045033 ～ 045035 to address 024014 ～ 024017; system/user/c2.Xxx in system sub-partition based file map: 024036 ～ 024040/system/user/c 2.Xxx in COW file map: 045036 ～ 045040, the data at address 045036 ～ 045040 is written to address 024036 ～ 024040.

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

In S520, the data operation of the static partition upgrade is for operating system data in the static partition (B) that does not affect operating system data of the currently active 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 operating system upgrading process, the user can normally use the equipment; after S531 is completed, the device does not need to be restarted immediately, and the user can select the restart time by himself; therefore, the upgrading process of the operating system does not influence the normal mobile phone operation of the user, so that 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 the user data partition (Userdata) needs to be updated, so that the data storage space utilization rate 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 added to the static partition (a) and the static partition (B) respectively to obtain the data storage structure shown in fig. 7, the partition table stored in the disk header (for example, the MBR partition or the 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). Because in the upgrade flow shown in fig. 5, the device completes the upgrade of the operating system data in the operating system running state; in the normal operating state of the operating system, the partition table at the disk head of the memory is read-only, so that the refreshing of the partition table cannot be completed according to the upgrading process shown in fig. 5.

Thus, one logically viable application is to store an operating system upgrade package in a user data partition (Userdata) based on the flow shown in fig. 3, the operating system upgrade package containing a partition table of the data storage structure shown in fig. 7 and image data of each partition in the data storage structure shown in fig. 7. After restarting the device, entering a Recovery (Recovery) mode, reading an operating system upgrade package stored in a user data partition (Userdata) in the Recovery (Recovery) mode, refreshing a partition table in a disk MBR by using the partition table in the operating system upgrade package, positioning each partition based on the refreshed partition table, and recovering the mirror image data of each partition in the operating system upgrade package to each partition.

However, in the android system adopting the virtual a/B upgrade mode, in order to ensure user data security, data stored in a user data partition (Userdata) is encrypted, and only when the android system is operating normally, the data stored in the user data partition (Userdata) can be accessed. That is, when the device restarts into Recovery (Recovery) mode, it cannot access the data held in the user data partition (Userdata). Thus, the device cannot reconfigure the partition structure and re-write data for each newly configured partition in Recovery (Recovery) mode.

In view of the above, the present application proposes an operating system upgrade method combining virtual a/B upgrade and Recovery (Recovery) mode upgrade. The partition table is refreshed in a Recovery (Recovery) mode to reconfigure the partition architecture, then the operating system is started, and operating system data is upgraded in a virtual A/B upgrade mode.

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

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

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

TABLE 3 Table 3

In table 3, AD31 to AD38 represent different address strings, respectively. Refer to 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 into the partition architecture shown in fig. 7, and after the partition architecture is reconfigured, a portion of the memory space allocation mapped onto the memory by the partition architecture shown in fig. 7 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 Table 4

Similarly, for the application scenario of deleting the partition, the above flow 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 mode of dividing a single reserve partition and/or combining multiple reserve partitions may be adopted to cut a part of space of one reserve partition to create the new partition, or combine multiple reserve partitions to create the new partition.

FIG. 9a is a flow chart illustrating an operating system upgrade according to one embodiment of the present application. The device executes as shown in FIG. 9a to implement an operating system upgrade that involves partition architecture reconfiguration.

S900, 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).

S910, an operating system upgrade package is acquired, and the process of acquiring the operating system upgrade package may refer to S510.

The operating system upgrade package comprises 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 process shown in fig. 5.

The partition table contained in the operating system upgrade package is the same as the address of the same-name partition on the current partition table on 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 reserved partitions 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 contained in the operating system upgrade package is shown in table 4. And, the operating system upgrade data includes data of the static partition sub-partition a.

In the operating system upgrade package, the operating system upgrade data is typically packaged as update_base. In S910, the device acquires a description file (file) for the operating system upgrade package, where the file is used to describe relevant information of update_base.zip, for example, the file includes an operating system version number for which update_base.zip is aimed, a hash value of update_base.zip, and so on.

In the operating system upgrade package acquired in S910, the update_base.zip includes the partition table of the partition structure corresponding to the latest version of the operating system.

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 an update_pt_able_zip (packaging according to the type of the update_base_zip package), signing the update_pt_able_zip, and then inputting the signed update_base_zip into the integral signature.

FIG. 9b is a diagram illustrating an internal file configuration of an OS upgrade package according to an embodiment of the present application. As shown in FIG. 9b, update_pt.zip packages partition table images (update_pt.zip) in the root directory. In update_pt, pt.img is a partition table image file.

And adding a partition upgrade package mark in a filelist file of the operating system upgrade package, wherein the partition upgrade package mark is used for marking that the update_base.zip in the current operating system upgrade package contains a latest version of partition table.

Further, the operating system upgrade package containing the partition table is configured as a key node package, and during the process of operating system upgrade, the cross-version upgrade operation cannot skip the key node package. That is, the device must first upgrade the operating system (reconfigure the partition structure) based on the critical node package before it can upgrade to a version of the operating system behind the critical node package. For example, the operating system preceding 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 of the operating system of version 2.0 is the critical node package. Assuming that the current operating system version of the device is 1.0, the latest operating system is 2.1, the device cannot be directly upgraded to the operating system of version 2.1, but must be first upgraded to the operating system of version 2.0 based on the operating system upgrade package of version 2.0 (the partition structure is reconfigured to be the partition structure shown in fig. 7) before the upgrade to version 2.1 can be continued.

S911, detecting whether the partition table needs to be updated in the current operation system upgrade. Specifically, it is detected whether the file list file for the os upgrade package includes the partition upgrade package flag, which is acquired in S910.

If not, it is indicated that update_base.zip does not contain the partition table, the partition table is not required to be updated for the current operating system upgrade, and S912 is executed, and 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 a partition upgrade package flag. Then it is indicated that update_base.zip contains the partition table, and the partition table needs to be updated for the current operating system upgrade, and S913 is performed, and the Recovery (Recovery) mode is restarted and entered.

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

s920, restarting the device, loading the basic partition (Common), the static partition (A) and the dynamic partition (Super) in sequence, and starting from the static partition (A).

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

According to the method of the embodiment shown in fig. 9a, an upgrade may be performed for an operating system employing a virtual a/B upgrade scheme and the partition table of the device memory updated during the upgrade. The upgrading scheme of the embodiment of the application greatly simplifies the operation difficulty of updating the device partition table and improves the user experience. According to the method of the embodiment shown in fig. 9a, an operating system employing a virtual a/B upgrade scheme may be upgraded and the partition table of the device memory updated during the upgrade; according to the method of the embodiment shown in fig. 9a, the device can automatically complete updating the partition table based on the downloaded operating system 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 (upgrade apk element) and an upgrade engine (upgrade engine) are two modules in the operating system. The upgrade package acquisition tool (upgrade apk component) is used for acquiring an upgrade installation package of the operating system, and downloading and storing the upgrade package of the operating system to a user data partition (Userdata). Reference S210.

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

After the upgrade package acquisition tool (update apk element) acquires the operating system upgrade package, it starts an upgrade engine (update engine), and the upgrade engine (update engine) upgrades the operating system according to the operating system upgrade package.

Specifically, after the upgrade package obtaining tool (update apk element) obtains the operating system upgrade package, the upgrade package obtaining tool (update apk element) sets a start attribute of the upgrade engine (update engine), and sets the start attribute to true. The service servicemanger, which resides in the operating system background, monitors the startup attribute of the upgrade engine (update engine) 302, and when the servicemanger detects that the startup attribute of the upgrade engine (update engine) is true, the servicemanger starts the upgrade engine (update engine).

The upgrade package acquisition tool (upgrade apk element) acquires the state of the upgrade engine (upgrade engine) through the binder communication, and when the upgrade package acquisition tool (upgrade apk element) confirms that the upgrade engine (upgrade engine) is successfully started, the upgrade package acquisition tool (upgrade apk element) transmits upgrade parameters (such as whether the current upgrade operation is a file update operation or a file landing operation) to the upgrade engine (upgrade engine) to trigger the upgrade engine (upgrade engine) to enter an upgrade flow. Specific upgrade processes can refer to S520 to S551.

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

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

The device loads the base partition (Common), the static partition (a), and the dynamic partition (Super) in sequence, and starts from the static partition (a). S1000 may be performed after the device is started, or may be performed before the device is started. The device, in a state of being started from the static partition (a), updates an agent to S1010, acquires an operating system upgrade package, and the process of acquiring the operating system upgrade package may refer to S910.

S1011, the update apk element detects whether the file aiming at the upgrade package of the operating system contains a partition upgrade package mark. Reference S911.

Because the operating system upgrade package acquired by the update apk element is the operating system upgrade package for updating the partition table, the file aiming at the operating system upgrade package contains a partition upgrade package mark. Executing S1012, the update apk agent determines whether the partition table update operation has been performed using the OS upgrade package. In S1012 currently executed, the update apk element determines that the partition table operation has not been updated using the operating system upgrade package. Thus, S1013 is performed in which the update apk element performs the partition table update preparation operation.

After the update apk element completes the partition table update preparation operation, S1014 is executed, and the update apk element triggers the device to restart (first restart), and the restarted device enters the Recovery mode.

S1020, in the Recovery mode, the device uses the partition table in the operating system upgrade package to update the partition table on the device memory.

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

The device, in a state of being started from the static partition (a), again executes S1012 the update apk event, determining whether the partition table update operation has been performed using the operating system upgrade package. In S1012, which is executed again, the update apk element determines that the partition table update operation has been performed using the operating system upgrade package. Therefore, the update apk event executes S1030, triggering the update event to enter the upgrade procedure.

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

After the os 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 os 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 status information of the completion of the upgrade operation to the update apk element.

S1040, update apk event triggers the device to restart (third restart), e.g., prompting the user to flick the frame, the user to select to restart immediately or later.

After restarting the device, the basic partition (Common), the static partition (B) and the dynamic partition (Super) are sequentially loaded, and the device is started from the static partition (B). Reference is made to S540 and S541.

After the device is started from the static partition (B), the update apk element executes S1041, and the update apk element triggers the update engine to enter the merge flow.

S1042, update Engine executes merge flow, refer to S551. After the merge flow is finished, the operating system of the device is upgraded.

Specifically, FIG. 11 is a partial flow chart illustrating an operating system upgrade according to one embodiment of the present application.

In S1010, an upgrade package acquisition tool (update apk element) 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, an upgrade package acquisition tool (update apk element) analyzes the filelist file and judges whether the filelist file contains a partition upgrade package mark or not;

if the filelist file does not contain the partition upgrade package flag, S1101, the device performs operating system upgrade according to the operating system upgrade package. Specifically, an upgrade package acquisition tool (upgrade apk element) starts an upgrade engine (upgrade engine), the upgrade engine (upgrade engine) upgrades the static partition (B) and the dynamic partition according to the upgrade package of the operating system, a restarting device starts from the static partition (B), and the upgrade package acquisition tool (upgrade apk element) starts the upgrade engine (upgrade engine) to perform a disk-dropping operation. Reference is made to S520 to S551.

If the filelist file contains a partition upgrade package flag, S1102 (i.e. S1012), the upgrade package acquisition tool (update apk element) determines whether the partition table has been updated.

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

When the device has not used the operating system upgrade package to perform the partition table updating operation, and when the available oemiinfo=0, the upgrade package obtaining tool (update apk element) performs the partition table updating preparation operation, and the partition table updating preparation operation (S1013) includes S1110 to S1111:

s1110, extracting the update_ptable. Zip from the update_base. Zip, decompressing the update_ptable. Zip, and storing the decompressed update_ptable. Zip in a cache partition (cache directory).

S1111, write Command (CMD) updated for partition table. Specifically, command commands for instructing the device to execute a flow of updating the partition table are written to the cache partition (cache directory).

For example, update_pt contains the partition table image pt_able_img and hash value H1 of pt_able_img. In S1111, a command is written, which contains an execution flow identifier (Process 1) pointing to flow (1).

The process (1) comprises the following steps:

calculating a hash value H2 of the pt able. Img;

comparing H1 and H2;

unlike, error reporting and restarting the device (loading base partition (Common), static partition (a), and dynamic partition (Super) after device restart, starting from static partition (a);

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

opening the pt.img (assuming pt.img is pt 1 after opening);

verifying whether the partition address starting position-ending position of the partition with the consistent name in the pt 0 and the pt 1 are consistent;

if the partition address starting position-ending position of the partition with the consistent name in the pt able0 and the pt able1 are inconsistent, reporting errors and restarting the device (loading a basic partition (Common), a static partition (A) and a dynamic partition (Super) after restarting the device, starting from the static partition (A);

if the partition address starting position-ending position of the partition with the consistent names in the pt 0 and the pt 1 are consistent, updating the current partition table (updating pt 0 to pt 1) on the device memory by using pt. Img;

Configuring a pt able oemiinfo=1;

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

After S1111, the update apk element completes the partition table update preparation operation. And then the update apk event executes S1112, records the breakpoint, records the current upgrade progress of the operating system, and when the device is restarted to enter the operating system, the operating system upgrade operation starts from S1102.

After S1112, the update apk element completes the partition table update preparation operation, and triggers the device to restart (first restart), specifically, the update apk element executes S1113 to pop up a dialog box, prompting the user that the device needs to be restarted for the current operating system upgrade.

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 diagram of a mobile phone operation interface according to an embodiment of the present application. After the handset successfully starts the operating system, it enters the system interface as shown at 1201 in fig. 12. The mobile phone performs an operating system upgrade (S1010, S1100, S1110, S1111, and S1112 are performed), and the display interface of the mobile phone may be the interface shown in 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 run in the background of the system, and when the mobile phone runs S1010, S1100, S1110, S1111 and S1112, the user may switch to the system interface shown in 1201 and open other applications; alternatively, the user may switch to an application interface of other applications that the system is running when the handset runs 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 diagram of a mobile phone operation interface according to an embodiment of the present application. The handset currently presents an interface as shown at 1202 in fig. 12, showing the user the operating system upgrade progress. In S1113, the handset presents an interface as shown in 1303 in fig. 13, with the user confirming that the restart is immediate or later.

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

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

In S1113, if the user clicks a later button, S1121 is performed, the device pauses the upgrade process, and restarts the upgrade process at a preset timing upgrade node, the device restarts after the upgrade process is started, and the restarted device enters a Recovery mode.

FIG. 14 is a partial flow chart illustrating an operating system upgrade according to one embodiment of the present application. After S1120 or S1121, the device restarts into a 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 (update_pt. Zip decompressed content and command written in S1111) under a cache directory;

s1410, resolving command, specifically resolving command written in S1111;

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

For example, the execution flow identifier (Process 1) pointing to the flow (1) in the command is parsed and acquired. The execution code of the Process (1) is executed to realize the Process (1) by calling the execution code of the pre-stored execution Process (1)) corresponding to the Process1 according to the execution Process identifier (Process 1). Specifically, in S1420, the device performs hash value verification on the mounted pt. Verifying whether the pt is available or not after the verification is passed; refreshing an original partition table on a device memory when the pt 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 element) 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 the available oemiinfo=1 after the partition table is successfully updated. Therefore, in S1102 executed again, the update package acquisition tool (update apk element) reads that the partition table has been updated when the partition update flag bit (ptable oemiinfo) stored in the metadata (/ metadata) of the common partition is ptable oemiinfo=1.

Thus, after S1102 is performed again, S1101 (i.e., S1030) is performed, and the device performs an operating system upgrade according to the operating system upgrade package. Reference is made to S520 to S551. Further, in S1101, after the operating system is successfully upgraded, the upgrade engine (update engine) configures a ptable oemiinfo=0. Specifically, in S531, the upgrade engine (update engine) configures a ptable oemiinfo=0.

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

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

The device loads the base partition (Common), the static partition (a), and the dynamic partition (Super) in sequence, and starts from the static partition (a). S1500 may be performed after the device is started, or may be performed before the device is started. The device performs S1510 to obtain an operating system upgrade package in a state of being started from the static partition (a), and the process of obtaining the operating system upgrade package may refer to S910.

S1511, an update apk element triggers an update engine to enter an upgrade process. In the upgrade process, the update engine executes S1520 to check the os upgrade package. Specifically, whether the digital signature of the operating system upgrade package is legal or not is checked, and whether the operating system upgrade package is legal or not is confirmed.

After the os upgrade package passes the verification, the update engine executes S1521 to detect whether the file for the os upgrade package contains the partition upgrade package flag. Reference S911.

Because the operating system upgrade package acquired by the update apk element is the operating system upgrade package for updating the partition table, the file aiming at the operating system upgrade package contains a partition upgrade package mark. Executing S1522, the update Engine determines whether the partition table update operation has been performed using the OS upgrade package. In S1522 that is currently executed, the update engine determines that the partition table operation has not been updated using the operating system upgrade package. Thus, S1523 is performed, and the update engine performs a partition table update preparation operation.

After the update engine completes the partition table update preparation operation, the update engine executes S1524, returning status information of the completion of the partition table update preparation operation to the update apk element.

After the update apk element confirms that the update engine completes the partition table update preparation operation, the update apk element executes S1530, triggers the device restart (first restart), and the restarted device enters the 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. Reference S1020 is made.

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

And the device executes S1511 again by the update apk event in the state of starting from the static partition (A), and triggers the update engine to enter the upgrading flow. The update engine again executes S1520, checking the operating system upgrade package.

After the os upgrade package passes the verification, the update engine executes S1521 again, to detect whether the file for the os upgrade package contains the partition upgrade package flag.

The update engine again executes S1522 to determine whether the partition table update operation has been performed using the os upgrade package. In S1522 that is currently executed, the update engine determines that the partition table operation has been updated using the operating system upgrade package. Thus, S1525 is performed to upgrade 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 S1525, the update engine executes S1526, and returns status information of the completion of the upgrade operation to the update apk element.

S1550, update apk event triggers the device to restart (third restart), e.g., prompts the user to flick the frame, and the user immediately restarts or restarts later with a choice.

After the device is started from the static partition (B), the update apk element executes S1551, and the update apk element triggers the update engine to enter the merge flow.

S1552, the update Engine executes the merge flow, referring to S551. After the merge flow is finished, the operating system of the device is upgraded.

Specifically, FIG. 16 is a partial flow chart illustrating an operating system upgrade according to one embodiment of the present application.

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

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

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

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

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 upgrades the data of the static partition and the dynamic partition according to the os upgrade package, specifically referring to S520, S530, and S531. The update apk event triggers the device to restart, and after the device is restarted, the basic partition (Common), the static partition (B) and the dynamic partition (Super) are sequentially loaded, and the device is started from the static partition (B). After the device is started from the static partition (B), the update apk element triggers the update engine to enter the merge flow. And the update engine executes a merge flow, and after the merge flow is finished, the operating system of the device finishes upgrading. Reference is made to S520 to S551.

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

s1620, extracting the update_ptable. Zip from the update_base. Zip, decompressing the update_ptable. Zip, and storing the decompressed update_ptable. Zip in a cache partition (cache directory).

S1621, write Command (CMD) for partition table update. Reference S1111.

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

After the update apk element confirms that the update engine completes the partition table update preparation operation, the update apk element executes S1630 to record the breakpoint and the current upgrade progress of the operating system, and when the device is restarted to enter the operating system, the operating system upgrade operation starts from S1600.

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

After S1632 or S1633, the device restarts to enter a Recovery (Recovery) mode in which the device performs a flow as 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 operation of operating system upgrade. As shown in fig. 15, the operating system upgrade operation starts from S1600 to execute the subsequent process again, and in S1610, the upgrade engine (update engine) parses the filelist file to determine that the filelist file contains the partition upgrade package flag.

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

Therefore, after S1612 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 a pt executable oemiinfo=0. Reference S1101.

It is to be understood that some or all of the steps or operations in the above embodiments are merely examples, and embodiments of the present application may also perform other operations or variations of various operations. Furthermore, the various steps may be performed in a different order presented in the above embodiments, and it is possible that not all of the operations in the above 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 the process flow). However, with the development of technology, many improvements of the current method flows can be regarded as direct improvements of hardware circuit structures. Designers almost always obtain corresponding hardware circuit structures by programming improved method flows into hardware circuits. Therefore, an improvement of a method flow cannot be said to be realized by a hardware entity module. For example, a programmable logic device (Programmable Logic Device, PLD) (e.g., field programmable gate array (Field Programmable Gate Array, FPGA)) is an integrated circuit whose logic function is determined by the programming of the device by an accessing party. The designer programs itself to "integrate" a digital device onto a single PLD without having to ask the chip manufacturer to design and fabricate application-specific integrated circuit chips. Moreover, nowadays, instead of manually manufacturing integrated circuit chips, such programming is mostly implemented by using "logic compiler" software, which is similar to the software compiler used in program development and writing, and the original code before the compiling is also written in a specific programming language, which is called hardware description language (Hardware Description Language, HDL), but not just one of the hdds, but a plurality of kinds, such as ABEL (Advanced Boolean Expression Language), AHDL (Altera Hardware Description Language), confluence, CUPL (Cornell University Programming Language), HDCal, JHDL (Java Hardware Description Language), lava, lola, myHDL, PALASM, RHDL (Ruby Hardware Description Language), etc., VHDL (Very-High-Speed Integrated Circuit Hardware Description Language) and Verilog are currently most commonly used. It will also be apparent to those skilled in the art that a hardware circuit implementing the logic method flow can be readily obtained by merely slightly programming the method flow into an integrated circuit using several of the hardware description languages described above.

Thus, the method flow proposed in the embodiments of the present application may be implemented in hardware, for example, using a controller that controls a touch screen to implement the method flow proposed in the embodiments 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, application specific integrated circuits (Application Specific Integrated Circuit, ASIC), programmable logic controllers, and embedded microcontrollers, 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 of the memory. Those skilled in the art will also appreciate that, in addition to implementing the controller in a pure computer readable program code, it is well possible to implement the same functionality by logically programming the method steps such that the controller is in the form of logic gates, switches, application specific integrated circuits, programmable logic controllers, embedded microcontrollers, etc. Such a controller may thus be regarded as a kind of hardware component, and means for performing various functions included therein may also be regarded as structures within the hardware component. Or even means for achieving the various functions may be regarded as either software modules implementing the methods or structures within hardware components.

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

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

It will be apparent to those skilled in the art that the techniques of embodiments of the present invention may be implemented in software plus a necessary general purpose hardware platform. Based on such understanding, the technical solutions in the embodiments of the present invention may be embodied in essence or what contributes to the prior art in the form of a software product, which may be stored in a storage medium, such as a ROM/RAM, a magnetic disk, an optical disk, etc., including several instructions for causing a computer device (which may be a personal computer, a server, or a network device, etc.) to execute the method described in the embodiments or some parts of the embodiments of the present invention.

The same or similar parts between the various embodiments in this specification are referred to each other. In particular, for the device embodiment and the terminal embodiment, since they are substantially similar to the method embodiment, the description is relatively simple, and reference should be made to the description in the method embodiment for relevant points.

Claims

1. A method for upgrading an operating system, the method being applied to an electronic device, the electronic device including 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, a current partition table of the electronic device being a first partition table corresponding to a first operating system, the electronic device loading data of the base partition, the first static partition, and the dynamic partition after being started to run the first operating system, the method comprising, after the first operating system is run:

triggering a third restart of the electronic equipment;

2. The method of claim 1, wherein the operating system upgrade data further comprises static partition upgrade data;

3. The method of claim 1, wherein prior to triggering the third reboot of the electronic device, the method further comprises modifying a boot sequence of the electronic device from booting from the first static partition to booting from the second static partition.

4. The method of claim 1, further comprising generating the second partition table.

5. The method of claim 4, wherein the first partition table includes a first reserved partition therein; the generating the second partition table includes:

6. The method of claim 4, wherein the generating the second partition table comprises:

Or,

7. The method of claim 1, wherein before restarting the electronic device to enter a recovery mode, the method further comprises:

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

saving the second partition table to a cache;

9. The method of claim 8, wherein the first operational flow comprises:

checking the second partition table;

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

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

executing the execution code of the first operation flow.

11. The method of any of claims 7-10, wherein prior to performing the partition table update preparation operation, the method further comprises:

12. The method of claim 11, wherein said confirming whether the operating system upgrade package is used to update a partition comprises:

13. The method according to claim 11, wherein:

14. The method of claim 11, wherein prior to said creating a virtual dynamic partition in said user data partition, said method further comprises:

15. The method of claim 14, wherein the first operating system includes a first upgrade package acquisition tool and a first upgrade engine, the method comprising, after the first operating system is running:

the first upgrade package acquisition tool triggers the first restart;

triggering the second restart in the recovery mode;

16. The method of claim 14, wherein the first operating system includes a second upgrade package acquisition tool and a second upgrade engine, the method comprising, after the first operating system is running:

triggering the second restart of the electronic device in the recovery mode;

17. An electronic device comprising a processor and a memory, the memory comprising a base partition, a first static partition, a second static partition, a dynamic partition, and a user data partition, the dynamic partition comprising a plurality of sub-partitions, the processor configured to execute software code stored on the memory such that the electronic device, upon startup, loads data of the base partition, the first static partition, and the dynamic partition 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 one of claims 1-16.

18. A computer readable storage medium, characterized in that the computer readable storage medium has stored therein a computer program which, when run on a computer, causes the computer to perform the method according to any of claims 1-16.