WO2022262753A1

WO2022262753A1 - Operating system starting method, device, storage medium, and computer program product

Info

Publication number: WO2022262753A1
Application number: PCT/CN2022/098861
Authority: WO
Inventors: 王艳召; 张赠辉; 陈超; 李永潮
Original assignee: 荣耀终端有限公司
Priority date: 2021-06-15
Filing date: 2022-06-15
Publication date: 2022-12-22
Also published as: CN114116023A; CN114116023B

Abstract

An operating system starting method, a device, a storage medium, and a computer program product provided in embodiments of the present application. The method is applied to an electronic device. The electronic device comprises a basic partition, a first static partition, a second static partition, a dynamic partition, and a user data partition; the first static partition comprises a first sub-partition; the second static partition comprises a second sub-partition; and the first sub-partition and the second sub-partition are sub-partitions corresponding to each other. The method comprises: loading data of the basic partition; loading data of the static partitions, comprising: performing a first check operation on data of the first sub-partition, and when the first check operation succeeds, loading the data of the first sub-partition, and when the first check operation fails, performing a second check operation on data of the second sub-partition, and when the second check operation succeeds, loading the data of the second sub-partition; and loading data of the dynamic partition to run a first operating system.

Description

Operating system startup method, device, storage medium and computer program product

technical field

The present application relates to the field of computer technology, and in particular to an operating system startup method, device, storage medium and computer program product.

[Correction 11.07.2022 under Rule 26] Background technology

In an application scenario of the prior art, a user terminal needs to be installed with an operating system before it can be used by the user. For example, a mobile phone operating system (for example: IOS system, Android system) needs to be installed on the mobile phone before it can be used by the user.

In the process of using a terminal device installed with an operating system, there are cases where the device cannot be started due to incorrect operating system data. Therefore, a device starting method for operating system data errors is needed to ensure that the device can be started smoothly.

Contents of the invention

In view of this, the present application provides an operating system startup method, device, storage medium and computer program product, so as to help solve the problem in the prior art that the device cannot be started due to an error in operating system data.

In the first aspect, the embodiment of the present application provides a method for starting an operating system, which is applied to an electronic device, and the electronic device includes a processor and a memory, and the memory includes a basic partition, a first static partition, a second static partition, a dynamic partitions and user data partitions, the first static partition includes a first sub-partition, the second static partition includes a second sub-partition, the first sub-partition and the second sub-partition are sub-partitions corresponding to each other, The methods include:

Load the data of the basic partition;

Loading static partition data includes: performing a first verification operation on the data of the first sub-partition, and loading the data of the first sub-partition when the first verification operation is successful; When the verification operation fails, perform a second verification operation on the data of the second sub-partition, and when the second verification operation succeeds, load the data of the second sub-partition;

The data of the dynamic partition is loaded to run the first operating system.

In an implementation manner of the first aspect, the method further includes:

When the second verification operation fails, restart the electronic device, or output a prompt message that the operating system fails to start.

In an implementation manner of the first aspect, the first static partition further includes a third sub-partition, the second static partition further includes a fourth sub-partition, and the third sub-partition and the fourth sub-partition For sub-partitions corresponding to each other, the loading of static partition data also includes:

Performing a third verification operation on the data of the third sub-partition, when the third verification operation is successful, loading the data of the third sub-partition; when the third verification operation fails, performing a third verification operation on all Perform a fourth verification operation on the data of the fourth sub-partition, and load the data of the fourth sub-partition when the fourth verification operation is successful.

In an implementation manner of the first aspect, after the data of the dynamic partition is loaded, the method further includes:

When the first verification operation fails, modify the boot order of the electronic device from booting from the first static partition to booting from the second static partition.

Modify the data of the second static partition.

In an implementation manner of the first aspect, the modifying the data of the second static partition includes:

Synchronizing data of other sub-partitions in the first static partition except the first sub-partition to corresponding sub-partitions in the second static partition.

In an implementation manner of the first aspect, before loading the static partition data, the method further includes: synchronizing the data of the first static partition to the second static partition.

In an implementation manner of the first aspect, before loading the data of the basic partition, the method further includes:

loading data of the basic partition, the second static partition and the dynamic partition to run a second operating system;

Obtain an upgrade installation package, the upgrade installation package includes a static partition upgrade file;

upgrading data of the first static partition based on the static partition upgrade file;

Restart the electronic device, and confirm that the current startup sequence is to start from the first static partition;

loading data of the basic partition, the first static partition, and the dynamic partition to run the first operating system;

Wherein, after restarting the electronic device and confirming that the current boot sequence is booting from the first static partition, performing the synchronizing the data of the first static partition to the second static partition.

In an implementation manner of the first aspect, during the process of loading the data of the first static partition, after the data of the static partition is successfully verified, the synchronization of the data of the first static partition to the Second static partition.

In an implementation manner of the first aspect, during the process of loading the data of the dynamic partition, after the verification of the dynamic partition file to be loaded is successful, the synchronization of the data of the first static partition to the Second static partition.

In an implementation of the first aspect:

The upgrade installation package also includes a dynamic partition upgrade file, the restart of the electronic device confirms that the current startup sequence is before starting from the first static partition, and the method further includes creating a file in the user data partition. A virtual dynamic partition, storing the dynamic partition upgrade file in the virtual dynamic partition;

The loading of dynamic partition data includes loading the data of the dynamic partition and the dynamic partition upgrade file;

After the dynamic partition data is loaded, the method further includes: placing the dynamic partition upgrade file in the user data partition to the dynamic partition;

After the described dynamic partition upgrade file in the user data partition is placed on the disk to the dynamic partition, the data synchronization of the first static partition to the second static partition is executed.

In a second aspect, the present application also provides an electronic device, the electronic device includes a processor and a memory, and the memory includes a basic partition, a first static partition, a second static partition, a dynamic partition and a user data partition, the The first static partition includes a first sub-partition, the second static partition includes a second sub-partition, the first sub-partition and the second sub-partition are sub-partitions corresponding to each other, and the processor is configured to execute the A software code stored in the memory, so that the electronic device executes the method flow described in the first aspect.

In a third aspect, the present application also provides a computer-readable storage medium, where a computer program is stored in the computer-readable storage medium, and when the computer program is run on a computer, the computer executes the method described in the first aspect. method.

In a fourth aspect, the present application further provides a computer program product, the computer program product includes a computer program, and when running on a computer, causes the computer to execute the method as described in the first aspect.

According to the above technical solutions proposed in the embodiments of the present application, at least the following technical effects can be achieved:

According to the method of the embodiment of the application, when the currently loaded static partition data is wrong, the data of another static partition can be loaded, so as to ensure that the device starts up smoothly and runs the operating system; according to the method of the embodiment of the application, the device startup can be greatly improved. The success rate and improve the stability of equipment operation.

Description of drawings

In order to more clearly illustrate the technical solutions of the embodiments of the present application, the following will briefly introduce the accompanying drawings that need to be used in the embodiments. Obviously, the accompanying drawings in the following description are only some embodiments of the present application. Those of ordinary skill in the art can also obtain other drawings based on these drawings without paying creative labor.

Figure 1 shows a schematic diagram of the data storage structure of the Android system on the terminal device;

FIG. 2 is a flow chart of starting a device according to an embodiment of the present application;

FIG. 3 is a schematic diagram of a device startup and loading process according to an embodiment of the present application;

FIG. 4 is a flow chart showing an operating system upgrade according to an embodiment of the present application;

FIG. 5 shows a flow chart of static partition synchronization according to an embodiment of the present application;

FIG. 6 shows a flow chart of static partition synchronization according to an embodiment of the present application;

FIG. 7 shows a flow chart of static partition synchronization according to an embodiment of the present application;

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

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

FIG. 10 is a flow chart showing device startup and loading according to an embodiment of the present application;

FIG. 11 is a schematic diagram of a device startup and loading process according to an embodiment of the present application;

Fig. 12 shows a flow chart of device startup and loading according to an embodiment of the present application;

FIG. 13 is a flow chart showing data correction for a static partition (A) according to a solution of an embodiment of the present application;

Fig. 14 is a flow chart of device startup and loading according to an embodiment of the present application.

detailed description

In order to better understand the technical solutions of the present application, the embodiments of the present application will be described in detail below in conjunction with the accompanying drawings.

It should be clear that the described embodiments are only some of the embodiments of the present application, not all of the embodiments. Based on the embodiments in this application, all other embodiments obtained by persons of ordinary skill in the art without creative efforts fall within the protection scope of this application.

Terms used in the embodiments of the present application are only for the purpose of describing specific embodiments, and are not intended to limit the present application. The singular forms "a", "said" and "the" used in the embodiments of this application and the appended claims are also intended to include plural forms unless the context clearly indicates otherwise.

It should be understood that the term "and/or" used herein is only an association relationship describing associated objects, which means that there may be three relationships, for example, A and/or B, which may mean that A exists alone, and A and B exist simultaneously. B, there are three situations of B alone. In addition, the character "/" in this article generally indicates that the contextual objects are an "or" relationship.

For the problem that the device cannot be started due to incorrect operating system data, a feasible solution is to build operating system backup data on the device. During the device startup process, when the operating system data is loaded incorrectly, the backup operating system can be loaded data to ensure smooth startup of the device. However, backup data will occupy storage space, which will compress the data space that users can use freely, resulting in waste of storage space.

In order to solve the above problems, the present application determines the mutually replaceable data in the operating system data by analyzing the storage file structure of the operating system. In the process of device startup, when the operating system data is loaded incorrectly, the data that can replace the wrong data is called to load, so as to ensure the smooth startup of the device.

Specifically, taking an Android system adopting a virtual A/B upgrade method as an example, FIG. 1 shows a schematic diagram of a data storage structure of the Android system on a terminal device. As shown in Figure 1, the Android system data storage area includes a basic partition (Common), a static partition (A), a static partition (B), a dynamic partition (Super), and a user data partition (Userdata).

The user data partition (Userdata) is used to store the user's personal data, for example, personal data such as apps installed by the user, pictures, documents, and videos saved by the user. The data saved in the basic part is system data that does not participate in the operating system upgrade. The structures of static partition (A) and static partition (B) correspond to each other, and sub-partition names are distinguished from each other by suffixes _a and _b. Static partition (A) includes bootloader_a, boot_a, vendor_boot_a, dtbo_a, vbmeta_a; static partition (B) includes bootloader_b, boot_b, vendor_boot_b, dtbo_b, vbmeta_b. A dynamic partition (Super) contains multiple subpartitions.

When the device boots, it starts from a static partition. For example, if the device starts from the static partition (A): load the basic partition (Common), static partition (A) and dynamic partition (Super) in sequence; the device starts from the static partition (B): load the basic partition (Common), static partition in sequence (B) and dynamic partition (Super).

In the system storage structure shown in Figure 1, the static partition (A) and the static partition (B) have the same partition structure, when the data programmed in the static partition (A) and the static partition (B) are consistent ( For example, in some application scenarios, after the system is installed on the device before leaving the factory, the data burned in the static partition (A) and the static partition (B) are consistent), the data in the static partition (A) and the static partition (B) , the corresponding subdivisions can replace each other.

To sum up, the embodiment of this application proposes a method for starting an operating system. For an Android system that adopts a virtual A/B upgrade method, when the device starts and loads a static partition (A), when a sub-partition fails to load, the Try to load the subpartition corresponding to the subpartition in the static partition (B), so as to ensure that the device starts smoothly.

Figure 2 is a flow chart of starting the device for the system data storage structure shown in Figure 1. When the device starts from the static partition (A) (generally, after the operating system is installed on the device before leaving the factory, the default device starts from the static partition (A) ) start), the device starts according to the process shown in Figure 2.

S200. The device obtains a partition table from a file system (for example, UFS) of the device, and generates a device node of a partition to be loaded, where the device node is path information of the partition.

For example, take Universal Flash Storage (UFS) in Master Boot Record (MBR) format. Read the size and location information of each partition on UFS from the MBR of UFS (master boot sector, the first sector of UFS, that is, 0 cylinder 0 head 1 sector of C/H/S address), and obtain the partition Table (Dpt).

Taking the static partition as an example, the device starts from the static partition (A). The subpartitions to be loaded in the static partition include bootloader_a, boot_a, vendor_boot_a, dtbo_a, and vbmeta_a. The device nodes to be loaded include:

/dev/block/by-name/bootloader_a;

/dev/block/by-name/boot_a;

/dev/block/by-name/vendor_boot_a;

/dev/block/by-name/dtbo_a;

/dev/block/by-name/vbmeta_a.

It should be noted here that the above device node description is only an example description of an actual application scenario. The solution of this application does not limit the specific form and specific content of the device node in detail.

Based on the device node of the partition to be loaded obtained by S200, the partition is loaded. S202, loading a basic partition (Common).

Based on the device node /dev/block/by-name/bootloader_a (first sub-partition) to be loaded obtained by S200, the bootloader sub-partition of the static partition is loaded.

S210, verify the data under the device node /dev/block/by-name/bootloader_a (the first verification operation).

Specifically, read the data under the device node /dev/block/by-name/bootloader_a, and perform image integrity and legality verification on the read data.

If the verification is successful, execute S211 to load the data under /dev/block/by-name/bootloader_a, and execute S220 after the data loading is completed.

If the verification fails, S212, modify the device node to be loaded, and modify the device node to be loaded from /dev/block/by-name/bootloader_a to /dev/block/by-name/bootloader_b (second sub-partition) ( Modify the suffix of the device node, change _a to _b).

S213, verify the data under the device node /dev/block/by-name/bootloader_b (second verification operation).

If the verification is successful, execute S214 to load the data under /dev/block/by-name/bootloader_b, and execute S220 after the data loading is completed.

If the verification fails, perform S201 to restart the device, or output a prompt message that the device cannot be started.

Based on the device node /dev/block/by-name/boot_a (third sub-partition) to be loaded obtained by S200, the boot sub-partition of the static partition is loaded.

S220, verify the data under the device node /dev/block/by-name/boot_a.

Specifically, read the data under the device node /dev/block/by-name/boot_a, and perform image integrity and legality verification on the read data.

If the verification is successful, execute S221 to load the data under /dev/block/by-name/boot_a, and execute S230 after the data loading is completed.

If the verification fails, execute S222, modify the device node to be loaded, and modify the device node to be loaded from /dev/block/by-name/boot_a to /dev/block/by-name/boot_b (the fourth sub-partition) ( Modify the suffix of the device node, change _a to _b).

S223, verify the data under the device node /dev/block/by-name/boot_b.

If the verification is successful, execute S224 to load the data under /dev/block/by-name/boot_b, and execute S230 after the data loading is completed.

Load the vendor_boot subpartition of the static partition based on the device node /dev/block/by-name/vendor_boot_a obtained by the S200 to be loaded.

S230, verify the data under the device node /dev/block/by-name/vendor_boot_a.

Specifically, read the data under the device node /dev/block/by-name/vendor_boot_a, and check the image integrity and validity of the read data.

If the verification is successful, execute S231, load the data under /dev/block/by-name/vendor_boot_a, and execute S240 after the data loading is completed.

If the verification fails, perform S232 to modify the device node to be loaded, and change the device node to be loaded from /dev/block/by-name/vendor_boot_a to /dev/block/by-name/vendor_boot_b (modify the suffix of the device node, Change _a to _b).

S233, verify the data under the device node /dev/block/by-name/vendor_boot_b.

If the verification is successful, execute S234 to load the data under /dev/block/by-name/vendor_boot_b, and execute S240 after the data loading is completed.

Based on the device node /dev/block/by-name/dtbo_a to be loaded obtained by the S200, load the dtbo sub-partition of the static partition.

S240, verify the data under the device node /dev/block/by-name/dtbo_a.

Specifically, read the data under the device node /dev/block/by-name/dtbo_a, and check the image integrity and validity of the read data.

If the verification is successful, execute S241 to load the data under /dev/block/by-name/dtbo_a, and execute S250 after the data loading is completed.

If the verification fails, execute S242, modify the device node to be loaded, and modify the device node to be loaded from /dev/block/by-name/dtbo_a to /dev/block/by-name/dtbo_b (modify the suffix of the device node, Change _a to _b).

S243, verify the data under the device node /dev/block/by-name/dtbo_b.

If the verification is successful, execute S244 to load the data under /dev/block/by-name/dtbo_b, and execute S250 after the data loading is completed.

Based on the device node /dev/block/by-name/vbmeta_a to be loaded obtained by S200, load the vbmeta sub-partition of the static partition.

S250, verifying data under the device node /dev/block/by-name/vbmeta_a.

Specifically, read the data under the device node /dev/block/by-name/vbmeta_a, and perform image integrity and legality verification on the read data.

If the verification is successful, execute S251 to load the data under /dev/block/by-name/vbmeta_a, and execute S260 after the data loading is completed.

If the verification fails, execute S252, modify the device node to be loaded, and modify the device node to be loaded from /dev/block/by-name/vbmeta_a to /dev/block/by-name/vbmeta_b (modify the suffix of the device node, Change _a to _b).

S253. Verify the data under the device node /dev/block/by-name/vbmeta_a.

If the verification is successful, execute S254 to load the data under /dev/block/by-name/vbmeta_a, and execute S260 after the data loading is completed.

If the verification fails, perform S201 to restart the device, or output a prompt message that the device cannot be started. S260, load the dynamic partition (Super); S270, start the device successfully.

Based on the method flow of the embodiment shown in Figure 2, when the sub-partition in the static partition (A) fails to be loaded, the device can be started smoothly by loading the corresponding sub-partition in the static partition (B), thereby greatly increasing the time for device startup. Success rate.

For example, FIG. 3 is a schematic diagram of a device startup and loading process according to an embodiment of the present application. In an application scenario, there are data errors in vendor_boot_a and vbmeta_a in the static partition (A). Start the device based on the method flow of the embodiment shown in Figure 2, as shown in Figure 3:

Load the basic partition (Common);

Verify bootloader_a subpartition (success), load bootloader_a subpartition;

Verify boot_a subpartition (success), load boot_a subpartition (success);

Verify vendor_boot_a subpartition (failure);

Verify vendor_boot_b subpartition (successful), load vendor_boot_b subpartition;

Verify dtbo_a subpartition (successful), load dtbo_a subpartition;

Verify vbmeta_a subpartition (failure);

Verify vbmeta_b subpartition (successful), load vbmeta_b subpartition;

Load dynamic partition (Super).

Finally, the operating system data loaded by the device from the static partition (A) is: basic partition (Common), bootloader_a subpartition, boot_a subpartition, vendor_boot_b subpartition, dtbo_a subpartition, vbmeta_b subpartition and dynamic partition (Super).

Furthermore, after the equipment leaves the factory, in actual application scenarios, the equipment still needs to be upgraded. FIG. 4 is a flow chart of upgrading the operating system for the system data storage structure shown in FIG. 1. When the device is currently started from the static partition (A), the device implements the operating system upgrade according to the process shown in FIG. 4.

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

S410, the device acquires an operating system upgrade installation package;

For example, in a feasible implementation solution, the device periodically initiates a packet search request to the packet search server, and the packet search request includes the version number (such as version 1.1) of the operating system currently running on the device; The version number of the operating system, and retrieve whether there is an operating system installation package with a newer version number (for example, version 1.2); Version 1.1 is upgraded to the download address of the operating system upgrade package) of version 1.2; the device downloads the operating system upgrade installation package according to the download address of the operating system upgrade installation package, and saves the operating system upgrade installation package to the user data partition (Userdata).

S420, the device reads the operating system upgrade installation package stored in S410 from the user data partition (Userdata), and performs a data writing operation on the static partition (B) according to the operating system upgrade installation package to upgrade the static partition;

For example, the operating system upgrade installation package includes data of the static partition of version 1.2, and the device overwrites the data of the static partition of version 1.2 into the static partition (B).

S430. The device creates a virtual dynamic partition in the user data partition (Userdata) according to the operating system upgrade installation package, and writes upgrade data of the dynamic partition (Super) in the virtual dynamic partition. For example, the operating system upgrade installation 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 solution, an incremental upgrade method is adopted for the dynamic partition (Super). During the upgrade process, the virtual dynamic partition of the user data partition (Userdata) does not save all the files of the new version of the dynamic partition (Super) after the upgrade, but the data that needs to be upgraded in the old version of the dynamic partition (Super). The result of the upgrade after the upgrade. That is, what is stored in the virtual dynamic partition of the user data partition (Userdata) is the updated data of the dynamic partition.

Taking the system subpartition as an example, assume that in version 1.1, the data in the system subpartition can be divided into two parts: system1 and system2. From version 1.1 to version 1.2, the data system2 has not changed, and the data syetem1 has been upgraded to system3. Then, in S430, the device creates a virtual dynamic partition in the user data partition (Userdata), and writes data system3 into the virtual dynamic partition.

For example, the system incremental upgrade installation package from version 1.1 to version 1.2 includes dynamic partition (Super) update data from version 1.1 to version 1.2, and the dynamic partition (Super) update data includes data system3.

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

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

In the operating system upgrade installation package acquired by S410, 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 installation package, each COW file is named according to the sub-partition of the dynamic partition (Super). For example, the COW file for the system subpartition is named system-cow-img.img.0000.

In S430, the device unpacks the operating system upgrade installation package to obtain all COW files, and attaches an A/B partition mark 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 operating system currently running on the device is the dynamic partition (A). When upgrading the operating system, the virtual dynamic partition created in the user data partition (Userdata) is for the dynamic partition (B). Therefore, the name mark _b corresponding to the dynamic partition (B) is appended to the COW file. For example, append_b for system-cow-img.img.0000 generates system_b-cow-img.img.0000.

Further, in S430, an Update folder is created in the user data partition (Userdata), and the renamed COW file is saved in the Update folder. For example, in an application scenario, after writing a COW file to the 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) and upgrade data of the COW file itself.

The COW file map (snapshot) corresponds to the file map of the sub-partition of the dynamic partition (Super) targeted by the COW file. The file map of the sub-partition of the dynamic partition (Super) is used to describe all the files in the sub-partition of the dynamic partition (Super) and the storage address of each file in the current version of the operating system (the version before this upgrade, for example, version 1.1) .

The upgrade data in the COW file is the updated file in the sub-partition data of the new version compared with the sub-partition data of the current version; the COW file map of the COW file itself is used to describe the updated file and the sub-partition of the current version The correspondence between the files in and the storage address of the updated files.

Based on the file map of the sub-partition of the dynamic partition (Super) and the COW file map in the COW file, the upgrade data in the COW file can be used to replace the corresponding file in the sub-partition of the dynamic partition (Super), thereby realizing the dynamic partition (Super) ) data upgrade. Specifically, when the file map of the sub-partition of the dynamic partition (Super) needs to be obtained, a 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). It is also possible to pre-generate the file map of the sub-partition of the dynamic partition (Super) when making the operating system upgrade installation package, and add the file map to the COW file.

Taking the system subpartition as an example, assume that data is saved in the system subpartition 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 of the system subpartition can 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 (for example, 024010-024013 in /system/app/A0.XXX: 024010-024013) is the physical storage address (block address) of the file in the system sub-partition of the dynamic partition (Super).

Assume that the current operating system upgrade needs to update the data /system/app/A2.XXX and /system/user/C2.XXX.

Can be viewed as:

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

Then, the COW file (system_b-cow-img.img.0000) for the system subpartition contains the latest versions of /system/app/A2.XXX and /system/user/C2.XXX.

It can be considered that the latest versions of /system/app/A2.XXX and /system/user/C2.XXX are system3. The upgrade goal is to use system3 to update system1.

When the size of the updated data in the COW file is the same as the size of the original data to be updated, and the storage position of the updated data in the COW file in the sub-partition after the data update is the same as the storage position of the original data to be updated in the sub-partition When the location is consistent, the COW file map of the COW file (system_b-cow-img.img.0000) itself can be:

/system/app/A2.XXX:

Map1 (the address of the data to be updated in the original super partition): start address address start: 024018 (the offset relative to the system start address); offset size: 2 (that is, the data in the address segment of 024018 ~ 024020)

Map2 (the address of the updated data stored in the cow file): start address address start: 045033 (the offset relative to the start address stored in the cow file); offset size: 2 (that is, the address segment of 045033 to 045035 The data);

/system/user/C2.XXX:

Map1 (the address of the data to be updated in the original super partition): start address address start: 024036 (the offset relative to the system start address); offset size: 4 (that is, the data in the address segment 024036~024040)

Map2 (the address of the update data stored in the cow file): start address address start: 045036 (offset relative to the start address stored in the cow file); offset size: 4 (that is, the address segment of 045036 ~ 045040 The data).

When the size of the updated data in the COW file is inconsistent with the size of the original data to be updated, the COW file map of the COW file (system_b-cow-img.img.0000) itself can be:

/system/app/A2.XXX:

Map1.1 (the address of the data to be updated in the original super partition): start address address start: 024018 (the offset relative to the system start address); data)

Map2.1 (stored in the cow file, the address of the updated data that needs to cover the address of Map1.1): start address address start: 045033 (offset relative to the start address stored in the cow file); offset size size: 2 (that is, the data in the address segment of 045033~045035);

Map1.2 (the address to be written in the original super partition of the part of the cow file where the updated data exceeds the size of the data to be updated): start address address start: 025018 (offset relative to the start address of the system); offset Volume size size: 1 (that is, the data in the 025018~025020 address segment)

Map2.2 (stored in the cow file, the address of the updated data that needs to cover the address of Map1.2): start address address start: 046033 (offset relative to the start address stored in the cow file); offset size size: 2 (that is, the data in the 046033~046035 address segment).

In the following specification description, for the convenience of description, only when the size of the updated data in the COW file is consistent with the size of the original data to be updated, and the updated data in the COW file is stored in the sub-partition after the data is updated An example is given for an application scenario where the storage location is consistent with the storage location of the original data to be updated in the sub-partition.

In the above example, the address segments (045033~045035 and 045036~045040) are the latest versions of /system/app/A2.XXX and /system/user/C2 in the COW file (system_b-cow-img.img.0000) respectively The physical storage address (block address) of .XXX in the user data partition (Userdata).

In this way, if A2.XXX at addresses 045033-045035 is used to replace A2.XXX at addresses 024018-024020, and C2.XXX at addresses 045036-045040 is used to replace C2.XXX at addresses 024036-024040, then The data upgrade of the system sub-partition of the dynamic partition (Super) can be completed.

Further, in S430, after the COW file is written into the user data partition (Userdata), it is also necessary to perform an overall check on the dynamic partition (Super)+COW file to verify the validity of the dynamic partition (Super)+COW file , to verify whether the synthesis result of the current version of the dynamic partition (Super) data + the COW file is the new version of the dynamic partition (Super) data.

Specifically, taking the upgrade from version 1.1 to version 1.3 as an example, calculate the data that does not need to be upgraded in the dynamic partition (Super) (the data that has not changed from version 1.1 to version 1.2) and the upgraded data in the COW file (from version 1.1 to Version 1.2 The hash value of the synthetic result of the data that needs to be upgraded), and judge whether the hash value is consistent with the hash value of the complete data of the dynamic partition (Super) in version 1.3. If they are consistent, it means that the COW file is valid; if they are inconsistent , it means that the COW file is invalid, the upgrade fails, the upgrade process is interrupted and an error is reported; among them, the hash value of the complete data of the dynamic partition (Super) in version 1.3 is saved in the operating system upgrade installation package.

Specifically, during the verification process, the dynamic partition (Super)+COW file is merged based on the snapshot. In the process of snapshot implementation, the merging of dynamic partitions (Super) and COW files is not a physical merging, but the overall file map of the sub-partitions in the COW file is merged with the COW file map of the COW file itself to generate a new A file map of versioned subpartition data.

For example, the file map of the system subpartition:

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

Maps with COW files:

/system/app/A2.XXX:

Map1: address start: 024018; size: 2 (that is, the data in the address segment from 024018 to 024020)

Map2: address start: 045033; size: 2 (that is, the data in the address segment from 045033 to 045035);

/system/user/C2.XXX:

Map1: address start: 024036; size: 4 (that is, the data in the address segment from 024036 to 024040)

Map2: address start: 045036; size: 4 (that is, the data in the address range from 045036 to 045040).

merge. Then get the file map of the new version of the system sub-partition:

/system/app/A0.XXX: 024010~024013;

(Point to A0.XXX under /system/app in the dynamic partition (Super))

/system/app/A1.XXX: 024014～024017;

(Point to A1.XXX under /system/app in the dynamic partition (Super))

/system/app/A2.XXX: 045033～045035;

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

/system/B0.XXX: 024021~024026;

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

/system/B1.XXX: 024027～024028;

(Point to B1.XXX under /system in the dynamic partition (Super))

/system/user/C0.XXX: 024029～024032;

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

/system/user/C1.XXX: 024033~024035;

(Point to C1.XXX under /system/user in the dynamic partition (Super))

/system/user/C2.XXX: 045036~045040;

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

/system/user/C3.XXX: 024041~024044.

(Point to C3.XXX under /system/user in the dynamic partition (Super))

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

During the verification process, according to the above synthesis method, the new version of the file map of all 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), directly Use the filemap of the subpartition as the new version's filemap). Combine the new version of the file map of all subpartitions to generate the new version of the file system of the dynamic partition (Super).

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

When the COW file is valid, change the merge status information in the metadata partition (/metadata) of the basic partition (Common) from "merged" to "wait for merge". The flush status information is used to indicate whether there are currently COW files that need to be flushed to the dynamic partition (Super). Specifically, the disk placement status information includes an overall identifier for the dynamic partition (Super) and a sub-partition identifier for each sub-partition. When the overall flag is "merged", it means that all sub-partitions of the dynamic partition (Super) do not need to be merged; when the overall flag is "not merged (wait for merge)", it means dynamic One or more sub-partitions of a partition (Super) need to be merged; when the sub-partition is marked as "merged", it means that the sub-partition does not need to be merged; when the sub-partition is marked as "merged Disk (wait for merge)" means that the sub-partition needs to be moved to disk.

S431. Change the boot sequence of the device from booting from the static partition (A) to booting from the static partition (B).

For example, rewrite the boot sequence identifier of the Master Boot Record (MBR), and rewrite the boot sequence identifier from A to B. After the device is powered on, when the device reads the boot sequence ID as A, the device starts from the static partition (A), and loads the static partition (A) during startup; when the device reads the boot sequence ID as B, the device starts from the static partition (A). Partition (B) starts, and static partition (B) is loaded during startup.

S432, restarting the device. Exit the current operating system, cut off the power of the device, and turn on the power of the device again.

S440, the device sequentially loads a basic partition (Common) and a static partition (B).

In S440, the device reads the boot flag in the basic partition (Common). The boot mark in the basic partition (Common) is (B), and the device loads the static partition (B) after loading the basic partition (Common), and starts from the static partition (B).

S441. The device loads the dynamic partition (Super) and the virtual dynamic partition of the user data partition (Userdata).

Specifically, the device reads the storage status information in the metadata (/metadata), determines whether to retrieve the COW file from the specified path of the user data partition (Userdata) based on the storage status information, and uses snapshot to merge and load the dynamic partition ( Super) and COW files.

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

Specifically, in S441, when there is a corresponding COW file in the sub-partition of the dynamic partition (Super), first generate a new version of the file map of each sub-partition of the dynamic partition (Super) based on the snapshot. For the process of generating a file map of a new version, reference may be made to S430. The device determines the files to be loaded according to the operation requirements of the operating system, and loads the files based on the file map of the new version of the dynamic partition (Super) sub-partition.

For example, the operating system needs to load all the data in the directory user (/system/user) under the system subpartition. The device reads the migration status information in the metadata (/metadata), and the subpartition of the system subpartition in the migration status information is marked as "wait for merge". Therefore, the device is in the user data partition (Userdata) Search for COW files under Medium/Update. After searching for the COW file system_b-cow-img.img.0000 under Update, generate a system sub-partition based on the snapshot and according to the file map of the COW file in system_b-cow-img.img.0000 The new version of the file map. Load data according to the storage addresses of all files under /system/user in the new version of the file map of the system subpartition, for example, according to the new version of the file map of the system subpartition:

/system/user/C0.XXX: 024029～024032;

/system/user/C1.XXX: 024033~024035;

/system/user/C2.XXX: 045036~045040;

/system/user/C3.XXX: 024041~024044.

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

Furthermore, when loading all the data in the directory user (/system/user) under the system subpartition, when the subpartition of the system subpartition in the storage status information is marked as "merged", the device will not Search for COW files under /Update in the user data partition (Userdata), but directly load all the data in the directory user (/system/user) under the system subpartition.

Further, when loading all the data in the directory user (/system/user) under the system sub-partition, when the sub-partition of the system sub-partition in the storage status information is marked as "wait for merge", if the device If the COW file corresponding to the system sub-partition is not found under /Update in the user data partition (Userdata), it means that the data was written incorrectly during the upgrade process (the COW file was written incorrectly or the disk status information was written incorrectly). The device rolls back the system and reports an error.

Further, in S441, before loading the file, the device needs to verify the loaded file. Different from S430, in S441, the dynamic partition (Super)+COW file is not verified as a whole, but only the files to be loaded are verified. For example, verify based on dmverity (dm-verity is a target of dm (device mapper), which is a virtual block device, specially used for file system verification). If the verification is successful, load the file; if the verification fails, restart the device, roll back the system or try to load the file again.

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

S451. The device transfers the data of the virtual dynamic partition to the dynamic partition (Super) in the background.

In the description of this specification, the disk operation refers to writing the dynamic partition (Super) upgrade file (COW file) stored in the virtual dynamic partition on the user data partition (Userdata) into the In the dynamic partition (Super), the files of the dynamic partition (Super) are upgraded, so that the device does not need to load the dynamic partition (Super) and the virtual dynamic partition at the next startup, and only needs to load the dynamic partition (Super) to complete the device. start up.

Specifically, after the device is successfully started, it performs a power-on broadcast, and starts an upgrade process after the power-on broadcast. The upgrade process reads the migration status information in the metadata (/metadata) of the basic partition (Common). If the migration status information is "merged", the device enters the normal operation mode.

If the disk status information is "wait for merge", the upgrade process will put the COW files in the user data partition (Userdata) to the dynamic partition (Super).

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

For example, based on /system/app/A2.XXX: 024018-024020 in the file map of the system subpartition and /system/app/A2.XXX: 045033-045035 in the COW file map, the data at addresses 045033-045035 Write to addresses 024014-024017; based on /system/user/C2.XXX: 024036-024040 in the file map of the system subpartition and /system/user/C2.XXX: 045036-045040 in the COW file map, the Data at addresses 045036 to 045040 are written to addresses 024036 to 024040.

After that, the upgrade process deletes the COW file in the user data partition (Userdata), returns the storage space to the user data partition (Userdata); Changed from "wait for merge" to "merged".

In S420, the data operation of the static partition upgrade is aimed at the operating system data in the static partition (B), and it will not affect the operating system data of the currently started static partition (A); and, in S430, the dynamic The data operation of partition upgrade is completed on the virtual dynamic partition created in the user data partition (Userdata), which will not affect the currently mounted dynamic partition (Super). Therefore, during the whole process of upgrading the operating system, the user can use the device normally; and, after the completion of S431, the device does not need to be restarted immediately, and the user can choose the restarting time; in this way, the upgrading process of the operating system will not affect the The user's normal mobile phone operation is affected, thereby greatly improving the user experience. Further, for the dynamic partition (Super), a virtual dynamic partition will be created on the user data partition (Userdata) only when an upgrade is required, thus effectively improving the utilization rate of data storage space.

Based on the system upgrade process shown in Figure 4, after the system version is upgraded, there is a system version difference between the data in the static partition (A) and the static partition (B). For example, assume that the static partition (A) corresponds to version 1.1 of the operating system, and the device starts the operating system of version 1.1 from the static partition (A); ) is upgraded to version 1.2 operating system, and after the device is restarted, the operating system running version 1.2 is started from the static partition (B); at this time, the device is running version 1.2 operating system, and the static partition (A) corresponds to the version Partition (B) corresponds to version 1.2 of the operating system.

Generally, when the operating system is upgraded from one version to another, the data of the operating system will not be changed as a whole, but only a certain part of the data will be changed. That is to say, when the operating system is upgraded from one version to another, the data in the static partition may not be modified, that is, the data in the static partition in the version 1.1 operating system is different from the data in the static partition in the version 1.2 operating system. data, may be the same. Or, when the operating system is upgraded from one version to another, only part of the data in the static partition may be modified, that is, part of the data in the static partition in the version 1.1 operating system is different from the Some data may be the same.

In the system storage structure shown in FIG. 1 , the partition structures of the static partition (A) and the static partition (B) are consistent. Then, when the static partition (A) corresponds to the version 1.1 operating system, and the static partition (B) corresponds to the version 1.2 operating system, there may be one or more sub-partitions in the static partition (A), which are different from those in the static partition (B). The corresponding one or more sub-partitions have the same data. At this time, between the static partition (A) and the static partition (B), there is a situation that one or more sub-partitions can replace each other.

Further, because in the system storage structure shown in Figure 1, the partition structure of static partition (A) and static partition (B) is consistent; the corresponding sub-partition of static partition (A) and static partition (B) is in the device The functions implemented during startup are the same. Therefore, even if the data between the corresponding subpartitions of the static partition (A) and the static partition (B) are not consistent due to the upgrade of the operating system, when the data change does not cause a change in function, the data achieved when loading the subpartition The functionality is similar, therefore, the sub-partitions can be approximately substituted for each other.

Therefore, in an application scenario, the device initially starts from the static partition (A), and then the device upgrades the operating system based on the process shown in Figure 4, upgrades the data of the static partition (B) and starts from the static partition (B).

After that, after the device has been used for a period of time (during which the device keeps booting from the static partition (B)), if the static partition (B) is damaged, one or more subpartitions in the static partition (B) have data Error, at this time, still refer to the embodiment shown in Figure 2, in the process of starting the device from the static partition (B), by loading one or more sub-partitions in the static partition (A) to achieve smooth startup of the device, thus Improve the success rate of device startup.

Furthermore, in order to further improve the success rate of device startup, in an application scenario, the device initially starts from the static partition (A), and then the device upgrades the operating system based on the process shown in Figure 4, upgrades the data of the static partition (B) and starts from the static Partition (B), and then (after S451) the device will synchronize the data of the static partition (B) to the static partition (A), thus ensuring the data between the static partition (A) and the corresponding sub-partitions in the static partition (B) Consistent, so that sub-partitions corresponding to each other can replace each other. At this time, the data in the static partition (B) and the static partition (A) can support the smooth startup of the device.

After that, after the device has been used for a period of time (during which the device keeps booting from the static partition (B)), if the static partition (B) is damaged, one or more subpartitions in the static partition (B) have data mistake. In the process of starting the device from the static partition (B), referring to the embodiment shown in FIG. 2, the device can be started smoothly by loading one or more sub-partitions in the static partition (A), thereby improving the success rate of device startup.

Further, the present application does not specifically limit the specific implementation manner of synchronizing the data of the static partition (B) to the static partition (A), and those skilled in the art may implement data synchronization in various feasible implementation manners. The specific implementation process of synchronizing the data of the static partition (B) to the static partition (A) is illustrated below through specific embodiments.

In S420, the device writes the data of the static partition in the operating system upgrade installation package to the static partition (B). Therefore, if the same operating system is used to upgrade the installation package, and the data of the static partition in the operating system upgrade installation package is written into the static partition (A), the data in the static partition (A) will be different from the data in the static partition (B). ) are consistent with the data.

Therefore, in one embodiment, synchronizing the data of the static partition (B) to the static partition (A) includes: obtaining and reading the operating system upgrade installation package stored in S410 from the user data partition (Userdata), and upgrading the operating system The data of the static partition in the installation package is written to the static partition (A).

Further, the static partition (A) and the static partition (B) are completely consistent in partition structure and partition size. Therefore, the data of the static partition (A) can be directly mirrored to the static partition (B), or the data of the static partition (B) can be mirrored to the static partition (A).

FIG. 5 is a flowchart of an implementation manner of static partition synchronization. The terminal device executes the following process as shown in FIG. 4 to synchronize the data of the static partition (B) to the static partition (A).

S500 reads out all the data in the static partition (B), packs and compresses it and makes it a mirror image file B;

S510, recover the image file B to the static partition (A) after unpacking, so as to realize overwriting the data of the static partition (B) to the static partition (A).

Further, the static partition (A) and the static partition (B) are consistent in partition structure, and include the same sub-partitions. Therefore, by overwriting the files of each sub-partition in the static partition (B) to the corresponding sub-partition in the static partition (A), the data in the static partition (B) can be synchronized to the static partition (A).

FIG. 6 is a flowchart of an implementation manner of static partition synchronization. The terminal device executes the following process as shown in FIG. 6 to synchronize the data of the static partition (B) to the static partition (A).

S600. Read the parameters related to the partition table on the device memory (the parameters are pre-stored in the device when the device leaves the factory), and synthesize the total partition table of the memory.

S610, read all static subpartitions with the suffix name _b from the total partition table, and generate a list 1 for describing each subpartition of the static partition (B), and list 1 includes the names of each subpartition in the static partition (B) and address. E.g:

[Correction 11.07.2022 in accordance with Rule 26]

Table 1

S620, read all static subpartitions with the suffix name _a from the total partition table, and generate a list 2 for describing each subpartition of the static partition (A), and list 2 includes the names of each subpartition in the static partition (A) and address. E.g:

[Correction 11.07.2022 in accordance with Rule 26]

Table 2

What needs to be explained here is that in Table 1 and Table 2, the address of the sub-partition is referred to in the form of a file path. In actual application scenarios, those skilled in the art can describe the address of the sub-partition in a variety of different ways . For example, a linear address description is used.

S630, select an unselected sub-partition (first sub-partition) in list 1, and acquire the name (first sub-partition name) and address (first file path) of the sub-partition.

Specifically, before S630, none of the sub-partitions in List 1 is selected. In S630, the sub-partitions may be sequentially selected according to the arrangement order (numbering order) of the sub-partitions in List 1, or may be randomly selected from all unselected sub-partitions.

Further, after a sub-partition is selected, the sub-partition is marked so as to confirm whether the sub-partition has been selected subsequently. For example, as shown in Table 1, the selected state column is added in Table 1, and the initial value of the selected state is 0, and if the sub-partition is selected, the selected state is changed to 1.

S640, performing desuffix matching on the sub-divisions selected in S630 and each sub-division in list 2; in determining list 2, after removing the suffix, the sub-division (the second sub-division) consistent with the sub-division name selected in S630 name) and in list 2, the sub-division address (second file path) corresponding to the second sub-division name;

S641, read the data under the first file path;

S642. Overwrite the read data to the second file path.

S650, judging whether there are unselected sub-partitions in the list 1;

If it exists, return to step S630, and reselect the first sub-region;

If it does not exist, the static partition synchronization ends.

Taking Table 1 and Table 2 as examples, in an application scenario, the device performs the following process:

Select the first subpartition (bootloader_b subpartition number 1) whose selected state is 0 in table 1, and modify the selected state of number 1 to 1;

Use bootloader_b to perform suffix matching in all sub-partition names in Table 2. Bootloader_a and bootloader_b are consistent after removing _a and _b respectively. Therefore, bootloader_a is matched according to bootloader_b;

Read the file path /dev/block/by-name/bootloader_b corresponding to bootloader_b from Table 1;

Read the file path /dev/block/by-name/bootloader_a corresponding to bootloader_a from Table 2;

Read the data under /dev/block/by-name/bootloader_b, and overwrite the read data to /dev/block/by-name/bootloader_a;

There is still a selected subpartition in table 1 whose state is 0, select the first subpartition in table 1 whose selected state is 0 (boot_b subpartition number 2), and modify the selected state of number 2 is 1;

Use boot_b to perform suffix matching in all sub-partition names in Table 2. Boot_a and boot_b are consistent after removing _a and _b respectively. Therefore, boot_a is matched according to boot_b;

Read the file path /dev/block/by-name/boot_b corresponding to boot_b from Table 1;

Read the file path /dev/block/by-name/boot_a corresponding to boot_a from Table 2;

Read the data under /dev/block/by-name/boot_b, and overwrite the read data to /dev/block/by-name/boot_a;

There are still subpartitions whose selected status is 0 in Table 1, select the first subpartition (vendor_boot_b subpartition number 3) in Table 1 whose selected status is 0, and modify the selected status of No. 3 is 1;

Use vendor_boot_b to perform suffix matching in all sub-partition names in Table 2. Vendor_boot_a and vendor_boot_b are consistent after removing _a and _b respectively. Therefore, vendor_boot_a is matched according to vendor_boot_b;

Read the file path /dev/block/by-name/vendor_boot_b corresponding to vendor_boot_b from Table 1;

Read the file path /dev/block/by-name/vendor_boot_a corresponding to vendor_boot_a from Table 2;

Read the data under /dev/block/by-name/vendor_boot_b, and overwrite the read data to /dev/block/by-name/vendor_boot_a;

There are still subpartitions whose selected state is 0 in table 1, select the first subpartition (dtbo_b subpartition number 4) whose selected state is 0 in table 1, and modify the selected state of number 4 is 1;

Use dtbo_b to perform suffix matching in all sub-partition names in Table 2. dtbo_a and dtbo_b are consistent after removing _a and _b respectively. Therefore, dtbo_a is matched according to dtbo_b;

Read the file path /dev/block/by-name/dtbo_b corresponding to dtbo_b from Table 1;

Read the file path /dev/block/by-name/dtbo_a corresponding to vendor_boot_a from Table 2;

Read the data under /dev/block/by-name/dtbo_b, and overwrite the read data to /dev/block/by-name/dtbo_a;

There are still subpartitions whose selected status is 0 in Table 1, select the first subpartition (vbmeta_b subpartition number 5) whose selected status is 0 in Table 1, and modify the selected status of No. 5 is 1;

Use vbmeta_b to perform suffix matching in all sub-partition names in Table 2. vbmeta_a and vbmeta_b are consistent after removing _a and _b respectively. Therefore, vbmeta_a is matched according to vbmeta_b;

Read the file path /dev/block/by-name/vbmeta_b corresponding to vbmeta_b from Table 1;

Read the file path /dev/block/by-name/vbmeta_a corresponding to vendor_boot_a from Table 2;

Read the data under /dev/block/by-name/vbmeta_b, and overwrite the read data to /dev/block/by-name/vbmeta_a;

There is no selected sub-partition in Table 1 whose state is 0, and the synchronization of the static partition is completed.

Further, in the above solution, Table 1 and Table 2 are transitional data, and Table 1 and Table 2 are deleted after the static partition synchronization is completed.

Further, in the process of upgrading the operating system, when the S420 reads and writes the data of the static partition (B) according to the operating system upgrade installation package, it does not necessarily perform all sub-partitions in the static partition (B) to rewrite. That is, if the data in the static partition (A) and the static partition (B) are completely consistent before the operating system is upgraded, then, after the operating system is upgraded using the process shown in Figure 5, the data in the static partition (A) and the static partition (B) It is possible that data for some subpartitions may still be consistent. Therefore, in the process of synchronizing the data of the static partition (B) to the static partition (A), if the sub-partitions with inconsistent data between the static partition (B) and the static partition (A) are identified first, only the sub-partitions with inconsistent data are synchronized, On the basis of achieving data consistency, the amount of data read and write can be greatly reduced.

FIG. 7 is a flowchart of an implementation manner of static partition synchronization. The terminal device executes the following process as shown in FIG. 7 to synchronize the data of the static partition (B) to the static partition (A).

For S710-S740, refer to S610-S640.

S741. Perform hash calculation on the data under the first path to obtain a first hash value;

S742. Perform hash calculation on the data under the second subpath to obtain a second hash value;

S743. Verify whether the first hash value is consistent with the second hash value;

If consistent, jump to S750;

If inconsistent, S745, read the data under the first path;

S746. Overwrite the read data to the second path.

S750, refer to S750;

If it exists, return to step S730, and reselect the first sub-region;

If it does not exist, the static partition synchronization ends.

Further, in the solution of the present application, the execution node for data synchronization between the static partition (A) and the static partition (B) is after any one of the static partition (A) and the static partition (B) is written with upgraded data.

Specifically, after S420, the upgrade data is written in the static partition (B), but since the operating system is running and loading the static partition (A), at this time, the data of the static partition (B) cannot be synchronized to the static partition ( A). After S431, during the execution of S440, the device loads the static partition (B) to run the operating system. The operation of the operating system does not need to load the static partition (A). At this time, the data of the static partition (B) can be synchronized to the static partition ( A). Therefore, in the embodiment of the present application, static partition synchronization can be performed at any time after S431. This application does not specifically limit the execution timing of data synchronization from the static partition (B) to the static partition (A). Those skilled in the art can set the synchronization time of the static partition or the trigger condition for triggering the synchronization of the static partition according to actual needs. The execution timing of synchronizing the data of the static partition (B) to the static partition (A) is described below by way of specific embodiments.

Fig. 8 is a flow chart showing an operating system upgrade according to an embodiment of the present application. When the device is currently started from the static partition (A), the device implements the upgrade of the operating system and the static partition according to the flow shown in Fig. 8 Synchronize.

S800～S832, refer to S400～S432;

S840, the device loads the basic partition (Common);

S850, the device loads a static partition (B);

S851, judging whether the static partition (B) is loaded successfully;

If the static partition (B) fails to load, S852, restart the device and start from the static partition (A);

If the static partition (B) is loaded successfully, S853, synchronize the data of the static partition (B) to the static partition (A).

S860, load dynamic partition (Super)+virtual dynamic partition; refer to S441.

S870, the device starts successfully, and enters the user interaction interface; refer to S450.

S871. The device puts the data of the virtual dynamic partition to the dynamic partition (Super); refer to S451.

Further, in the virtual A/B upgrade solution, after the device is restarted and started from the upgraded static partition, the device will verify the files that need to be loaded for the current system operation in the dynamic partition + virtual dynamic partition, and only after the verification is successful Files that need to be loaded for the current system operation in the dynamic partition + virtual dynamic partition will be loaded. If the verification fails, the system will be restarted and rolled back, and the system upgrade will fail at this time.

Therefore, in order to avoid synchronization of static partitions when the upgrade fails, in one embodiment of the present application, the files that need to be loaded in the dynamic partition + virtual dynamic partition are successfully verified, or the files that need to be loaded in the dynamic partition + virtual dynamic partition After being successfully loaded, the synchronization of the static partition is performed.

Fig. 9 shows a flow chart of operating system upgrade according to an embodiment of the present application. When the device is currently started from the static partition (A), the device implements the upgrade of the operating system and the static partition according to the flow shown in Fig. 9 Synchronize.

S900～S952, refer to S800～S852;

If the static partition (B) is loaded successfully, S953, verify the files to be loaded in the dynamic partition+virtual dynamic partition; for example, use dmverity.

S954, judging whether the verification is successful.

If the verification fails, S960, restart the device and roll back the system, for example, start from the static partition (A).

If the verification is successful, execute S955;

S955, synchronizing the data of the static partition (B) to the static partition (A);

For S956-S958, refer to S860-S871.

Further, in an application scenario, the device initially starts from the static partition (B), if the static partition (B) is damaged, one or more sub-partitions in the static partition (B) have data errors. At this time, although the device can refer to the embodiment shown in FIG. 2, in the process of starting the device from the static partition (B), the smooth startup of the device can be realized by loading one or more sub-partitions in the static partition (A). However, the error data in the static partition (B) is not repaired during the device startup process. When the device starts from the static partition (B) again, it still needs to refer to the embodiment shown in FIG. 2, by loading the static partition (A) One or more subpartitions of the device to achieve smooth booting of the device.

Therefore, in an embodiment of the present application, after the static partition is upgraded, the data of the static partition whose data is upgraded is synchronized to another static partition, so as to ensure that the data of the two static partitions are consistent.

After that, if there is a data error in the static partition used to start the device, during the process of starting the device from the static partition, referring to the embodiment shown in FIG. 2 , load the data in another static partition to start the device smoothly. After the device starts up successfully, modify the startup sequence of the device so that the next time the device starts up from the static partition that does not have data errors.

For example, FIG. 10 shows a flowchart for starting a device for the system data storage structure shown in FIG. 1 . Assuming that the device initially starts from the static partition (A), the operating system is upgraded based on the process shown in Figure 4, the data of the static partition (B) is updated, and the device starts from the static partition (B) after restarting the device. Afterwards, the data of the static partition (B) is synchronized to the static partition (A) to ensure that the data of the two static partitions are consistent.

After that, the device boots from the static partition (B) according to the flow shown in Figure 10.

S1000-S1070, refer to S200-S270, the difference is that in S1014, S1024, S1034, S1044, S1054, in addition to loading the sub-partition data, it is also necessary to mark the data error in the static partition (B).

For example, static partition state information is stored in the metadata of the basic partition (Common), and the static partition state information is used to describe the static partition (A) and whether there is a data error in the static partition (B). For example, static partition status information can be as shown in the following table:

[Correction 11.07.2022 in accordance with Rule 26]

In Table 3, Error_static partition_a corresponds to the static partition (A), Error_static partition_b corresponds to the static partition (B), the value 0 means no data error, and the value 1 means there is a data error. In S1014, S1024, S1034, S1044, and S1054, in addition to loading sub-partition data, it is also necessary to set the value of Error_static partition_b to 1.

After S1070, the device also needs to perform:

S1071. Read static partition status information, and determine whether there is a data error in the static partition (B). Specifically, the device reads the value of Error_static partition_b to determine whether it is 1.

If there is a data error in the static partition (B), execute S1072, and the device modifies the current boot sequence from booting from the static partition (B) to booting from the static partition (A). In this way, when the device starts next time, it will start from the static partition (A), and data errors in the static partition (B) will not interfere with the execution of device startup.

Further, in an actual application scenario, there are situations where data errors exist in both the static partition (B) and the static partition (A). In this case, if the static partition (B) does not correspond to the sub-partition that cannot be successfully loaded in the static partition (A), then, referring to the embodiment shown in FIG. 2 , the device can be started smoothly. For example, FIG. 11 is a schematic diagram of a device startup and loading process according to an embodiment of the present application. In an application scenario, vendor_boot_a in the static partition (A) and vbmeta_b in the static partition (B) have data errors. The device starts from the static partition (B), and the startup process is shown in Figure 11:

Load the basic partition (Common);

Verify bootloader_b subpartition (success), load bootloader_b subpartition;

Verify the boot_b subpartition (successful), load the boot_b subpartition;

Verify dtbo_b subpartition (successful), load dtbo_b subpartition;

Verify vbmeta_b subpartition (failure);

Verify vbmeta_a subpartition (successful), load vbmeta_a subpartition;

Load dynamic partition (Super).

Finally, the operating system data loaded by the device from the static partition (B) is: basic partition (Common), bootloader_b subpartition, boot_b subpartition, vendor_boot_b subpartition, dtbo_b subpartition, vbmeta_a subpartition and dynamic partition (Super). When the device starts from the static partition (B), it needs to load the vbmeta_a subpartition.

If the device starts from the static partition (B), change the boot sequence to start from the static partition (A). Due to data errors in vendor_boot_a in the static partition (A), the device still needs to load the vendor_boot_b sub-partition of the static partition (B) in the process of booting from the static partition (A) to start smoothly. As a result, the device will never be able to boot smoothly based on only one static partition.

In view of the above problems, in one embodiment of the present application, it is assumed that the device is initially started from the static partition (A), and the operating system is upgraded based on the process shown in Figure 4, the data of the static partition (B) is upgraded, and the device is restarted from the static Partition (B) starts. Afterwards, the data of the static partition (B) is synchronized to the static partition (A) to ensure that the data of the two static partitions are consistent.

After this, the device keeps booting from the static partition (B). If there is a data error in the static partition (B), in the process of starting the device from the static partition (B), refer to the embodiment shown in Figure 2 to load the data in the static partition (A) to start the device smoothly. After the device starts up successfully, correct the data in the static partition (A), and change the boot sequence of the device from the static partition (B) to the static partition (A), so that the device can be started from The static partition (A) starts independently.

FIG. 12 is a flow chart of starting a device for the system data storage structure shown in FIG. 1 . In an embodiment of the present application, assuming that the device is initially started from the static partition (A), the operating system is upgraded based on the process shown in Figure 4, the data of the static partition (B) is upgraded, and after restarting the device, the device starts from the static partition (B) start up. Afterwards, the data of the static partition (B) is synchronized to the static partition (A) to ensure that the data of the two static partitions are consistent.

After that, the device boots from the static partition (B) according to the flow shown in Figure 12.

For S1200-S1270, refer to S1000-S1070.

After S1270, the device also needs to execute:

S1271. Read the status information of the static partition, and determine whether there is a data error in the static partition (B). Specifically, the device reads the value of Error_static partition_b to determine whether it is 1.

If there is a data error in the static partition (B), execute:

S1272, modifying the data in the static partition (A);

S1273. The device modifies the current boot sequence from booting from the static partition (B) to booting from the static partition (A). In this way, when the device starts next time, it will start from the static partition (A), and data errors in the static partition (B) will not interfere with the execution of device startup. Moreover, assuming that before S1200, there is also a data error in the static partition (A), in S1272, by performing data correction on the static partition (A), there is no data error in the static partition (A). In this way, after S1273, during the process of booting the device from the static partition (A), there is no need to load the data of the static partition (B).

Further, the present application does not specifically limit the specific implementation manner of S1272, and those skilled in the art may adopt multiple feasible implementations of S1272. The specific implementation process of S1272 is illustrated below through specific embodiments.

Assume that the device initially boots from the static partition (A). The device completes the operating system upgrade based on the embodiment shown in FIG. 4 and synchronizes data from the static partition (B) to the static partition (A). At this time, the boot sequence of the device is to boot from the static partition (B). After that, assume that both the static partition (B) and the static partition (A) of the device have data errors. For example, as shown in Figure 11, vendor_boot_a in the static partition (A) and vbmmeta_b in the static partition (B) exist data error.

FIG. 13 is a flow chart of data correction for a static partition (A) according to an embodiment of the present application. The terminal device executes the following process as shown in FIG. 13 to implement S1272.

S1300, determine the operating system version corresponding to the static partition (B);

S1310, acquiring the static partition installation image of the operating system version corresponding to the static partition (B);

For the execution of S1300 and S1310, refer to S310. After obtaining the full operating system installation package, extract the static partition installation image from the full operating system installation package.

S1320, restore the installation image of the static partition to the static partition (A).

.

FIG. 14 is a flow chart of starting a device for the system data storage structure shown in FIG. 1 . Assuming that the device initially starts from the static partition (A), the operating system is upgraded based on the process shown in Figure 4, the data of the static partition (B) is updated, and the device starts from the static partition (B) after restarting the device. Afterwards, the data of the static partition (B) is synchronized to the static partition (A) to ensure that the data of the two static partitions are consistent.

After that, the device boots from the static partition (B) according to the flow shown in Figure 14.

S1400-S1470, refer to S200-S270, the difference is that in S1414, S1424, S1434, S1444, S1454, in addition to loading the sub-partition data, it is also necessary to mark the sub-partition of the static partition (B) as having data errors.

[Correction 11.07.2022 in accordance with Rule 26]

在表4中，Error_bootloader_a、Error_boot_a、Error_vendor_boot_a、Error_dtbo_a、Error_vbmeta_a分别对应静态分区(A)的bootloader_a子分区、 boot_a子分区、vendor_boot_a子分区、dtbo_a子分区、vbmeta_a子分区；Error_bootloader_b、Error_boot_b、Error_vendor_boot_b、Error_dtbo_b、 Error_vbmeta_b corresponds to the bootloader_b sub-partition, boot_b sub-partition, vendor_boot_b sub-partition, dtbo_b sub-partition, and vbmeta_b sub-partition of the static partition (B). A value of 0 means that there is no data error, and a value of 1 means that there is a data error. In S1414, S1424, S1434, S1444, and S1454, in addition to loading sub-partition data, it is also necessary to set the value of the corresponding parameter to 1.

After S1470, the device also needs to execute:

S1471. Read the status information of the static partition, judge whether there is a data error in the static partition (B), and determine the sub-partition with the data error. Specifically, the device reads the values of Error_bootloader_b, Error_boot_b, Error_vendor_boot_b, Error_dtbo_b, and Error_vbmeta_b, and determines whether each value is 1.

If there is a data error in the static partition (B), execute S1473, and the device performs static partition data synchronization according to the status information of the static partition. The data is synchronized to the corresponding subpartition of the static partition (A).

For example, as shown in FIG. 11 , vendor_boot_a in the static partition (A) and vbmeta_b in the static partition (B) have data errors. After S1470, the static partition status information is shown in the following table:

[Correction 11.07.2022 in accordance with Rule 26]

table 5

In S1473, synchronize the data of the bootloader_b subpartition, boot_b subpartition, vendor_boot_b subpartition, and dtbo_b subpartition to the bootloader_a subpartition, boot_a subpartition, vendor_boot_a subpartition, and dtbo_a subpartition respectively

S1474. Modify the current boot sequence from booting from the static partition (B) to booting from the static partition (A).

It can be understood that some or all of the steps or operations in the foregoing embodiments are only examples, and other operations or modifications of various operations may also be performed in the embodiment of the present application. In addition, various steps may be performed in different orders presented in the above embodiments, and it may not be necessary to perform all operations in the above embodiments.

Further, in general, improvements to a technology can be clearly distinguished as improvements in hardware (for example, improvements to circuit structures such as diodes, transistors, and switches) or improvements in software (improvements to method flow). However, with the development of technology, the improvement of many current method flows can be regarded as the direct improvement of the hardware circuit structure. Designers almost always get the corresponding hardware circuit structure by programming the improved method flow into the hardware circuit. Therefore, it cannot be said that the improvement of a method flow cannot be realized by hardware physical modules. For example, a programmable logic device (Programmable Logic Device, PLD) (such as a field programmable gate array (Field Programmable Gate Array, FPGA)) is such an integrated circuit, the logic function of which is determined by the programming of the device by the accessing party. It is programmed by the designer to "integrate" a digital device on a PLD, instead of asking a chip manufacturer to design and manufacture a dedicated integrated circuit chip. Moreover, nowadays, instead of making integrated circuit chips by hand, this kind of programming is mostly realized by "logic compiler (logic compiler)" software, which is similar to the software compiler used when program development and writing, but before compiling The original code of the computer must also be written in a specific programming language, which is called a hardware description language (Hardware Description Language, HDL), and there is not only one kind of HDL, but many 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., are currently the most commonly used The most popular are VHDL (Very-High-Speed Integrated Circuit Hardware Description Language) and Verilog. It should also be clear to those skilled in the art that only a little logical programming of the method flow in the above-mentioned hardware description languages and programming into an integrated circuit can easily obtain a hardware circuit for realizing the logic method flow.

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

The controller may be implemented in any suitable way, for example the controller may take the form of a microprocessor or processor and a computer readable medium storing computer readable program code (such as 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 controllers include but are not limited to the following microcontrollers: ARC 625D, Atmel AT91SAM, Microchip PIC18F26K20 and Silicone Labs C8051F320, the memory controller can also be implemented as part of the control logic of the memory. Those skilled in the art also know that, in addition to realizing the controller in a purely computer-readable program code mode, it is entirely possible to make the controller use logic gates, switches, application-specific integrated circuits, programmable logic controllers, and embedded The same function can be realized in the form of a microcontroller or the like. Therefore, such a controller can be regarded as a hardware component, and the devices included in it for realizing various functions can also be regarded as structures within the hardware component. Or even, means for realizing various functions can be regarded as a structure within both a software module realizing a method and a hardware component.

Corresponding to the foregoing embodiments, the present application further provides an electronic device. The electronic device includes a memory for storing computer program instructions and a processor for executing the program instructions, wherein when the computer program instructions are executed by the processor, the electronic device is triggered to execute the method steps described in the embodiments of the present application.

The present application also provides a computer program product, the computer program product includes a computer program, and when it is run on a computer, causes the computer to execute some or all of the steps provided in the embodiments of the present application.

Those skilled in the art can clearly understand that the technologies in the embodiments of the present invention can be implemented by means of software plus a necessary general-purpose hardware platform. Based on this understanding, the essence of the technical solutions in the embodiments of the present invention or the part that contributes to the prior art can be embodied in the form of software products, and the computer software products can be stored in storage media, such as ROM/RAM , magnetic disk, optical disk, etc., including several instructions to enable a computer device (which may be a personal computer, server, or network device, etc.) to execute the methods described in various embodiments or some parts of the embodiments of the present invention.

For the same and similar parts among the various embodiments in this specification, refer to each other. In particular, for the device embodiment and the terminal embodiment, since they are basically similar to the method embodiment, the description is relatively simple, and for relevant parts, please refer to the description in the method embodiment.

Claims

A method for starting an operating system, characterized in that it is applied to an electronic device, the electronic device includes a processor and a memory, and the memory includes a basic partition, a first static partition, a second static partition, a dynamic partition, and a user data partition, The first static partition includes a first sub-partition, the second static partition includes a second sub-partition, the first sub-partition and the second sub-partition are sub-partitions corresponding to each other, and the method includes:

Load the data of the basic partition;

Loading static partition data includes: performing a first verification operation on the data of the first sub-partition, and loading the data of the first sub-partition when the first verification operation is successful; When the verification operation fails, perform a second verification operation on the data of the second sub-partition, and when the second verification operation succeeds, load the data of the second sub-partition;

The data of the dynamic partition is loaded to run the first operating system.
The method according to claim 1, wherein the method further comprises:

When the second verification operation fails, restart the electronic device, or output a prompt message that the operating system fails to start.
The method according to claim 1, wherein the first static partition further comprises a third sub-partition, the second static partition further comprises a fourth sub-partition, and the third sub-partition and the fourth sub-partition The partitions are sub-partitions corresponding to each other, and the loading of static partition data also includes:

Performing a third verification operation on the data of the third sub-partition, when the third verification operation is successful, loading the data of the third sub-partition; when the third verification operation fails, performing a third verification operation on all Perform a fourth verification operation on the data of the fourth sub-partition, and load the data of the fourth sub-partition when the fourth verification operation is successful.
The method according to claim 1, wherein after loading the data of the dynamic partition, the method further comprises:

When the first verification operation fails, modify the boot order of the electronic device from booting from the first static partition to booting from the second static partition.
The method according to claim 4, wherein after the data of the dynamic partition is loaded, the method further comprises:

Modify the data of the second static partition.
The method according to claim 5, wherein the modifying the data of the second static partition comprises:

Synchronizing data of other sub-partitions in the first static partition except the first sub-partition to corresponding sub-partitions in the second static partition.
The method according to any one of claims 1-6, characterized in that, before loading the data of the static partition, the method further comprises: synchronizing the data of the first static partition to the second static partition.
The method according to claim 7, wherein before loading the data of the basic partition, the method further comprises:

loading data of the basic partition, the second static partition and the dynamic partition to run a second operating system;

Obtain an upgrade installation package, the upgrade installation package includes a static partition upgrade file;

upgrading data of the first static partition based on the static partition upgrade file;

Restart the electronic device, and confirm that the current startup sequence is to start from the first static partition;

loading data of the basic partition, the first static partition, and the dynamic partition to run the first operating system;

Wherein, after restarting the electronic device and confirming that the current boot sequence is booting from the first static partition, performing the synchronizing the data of the first static partition to the second static partition.
The method according to claim 8, wherein during the process of loading the data of the first static partition, after the data of the static partition is verified successfully, performing the step of synchronizing the data of the first static partition to The second static partition.
The method according to claim 8, characterized in that, in the process of loading the data of the dynamic partition, after the verification of the dynamic partition file to be loaded is successful, performing the synchronization of the data of the first static partition to The second static partition.
The method according to claim 8, characterized in that:

The upgrade installation package also includes a dynamic partition upgrade file, the restart of the electronic device confirms that the current startup sequence is before starting from the first static partition, and the method further includes creating a file in the user data partition. A virtual dynamic partition, storing the dynamic partition upgrade file in the virtual dynamic partition;

The loading of dynamic partition data includes loading the data of the dynamic partition and the dynamic partition upgrade file;

After the dynamic partition data is loaded, the method further includes: placing the dynamic partition upgrade file in the user data partition to the dynamic partition;

After the uploading the dynamic partition upgrade file in the user data partition to the dynamic partition, performing the step of synchronizing the data of the first static partition to the second static partition.
An electronic device, characterized in that the electronic device includes a processor and a memory, and the memory includes a basic partition, a first static partition, a second static partition, a dynamic partition and a user data partition, and the first static partition Including a first sub-partition, the second static partition includes a second sub-partition, the first sub-partition and the second sub-partition are sub-partitions corresponding to each other, and the processor is configured to execute the A software code, so that the electronic device executes the method procedure according to any one of claims 1-11.
A computer-readable storage medium, characterized in that a computer program is stored in the computer-readable storage medium, and when the computer program is run on a computer, the computer is made to execute the computer program described in any one of claims 1-11. described method.
A computer program product, characterized in that the computer program product includes a computer program, which when run on a computer causes the computer to execute the method according to any one of claims 1-11.