CN113900673B

CN113900673B - System installation package management method, device, storage medium and program product

Info

Publication number: CN113900673B
Application number: CN202110662966.1A
Authority: CN
Inventors: 张赠辉; 王艳召; 陈超; 李永潮
Original assignee: Honor Device Co Ltd
Current assignee: Shanghai Glory Smart Technology Development Co ltd
Priority date: 2021-06-15
Filing date: 2021-06-15
Publication date: 2022-10-28
Anticipated expiration: 2041-06-15
Also published as: CN116594639A; CN113900673A

Abstract

The embodiment of the application provides a method, equipment, a storage medium and a computer program product for managing a system installation package, wherein the method comprises the following steps: manufacturing a basic partition mirror image; making a first static partition mirror image of the first static partition and a second static partition mirror image of the second static partition; generating slot one data corresponding to the first static partition based on the name of each sub-partition in the dynamic partition and the corresponding partition size; generating slot two data corresponding to the second static partition based on the slot one data; packing the slot first data, the slot second data and the mirror image of each sub-partition in the dynamic partition into a dynamic partition mirror image; and manufacturing a system installation package containing a basic partition mirror image, a first static partition mirror image, a second static partition mirror image and a dynamic partition mirror image. According to the method of the embodiment of the application, the device can be enabled to support starting from any static partition.

Description

System installation package management method, device, storage medium and program product

Technical Field

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

Background

In the application scenario of the prior art, the user terminal needs to install the operating system to be available to the user. For example, a mobile phone operating system (e.g., an IOS system, an android system) needs to be installed on the mobile phone to be used by the user. Because the installation process of the operating system is complicated, and the operating system of some terminal equipment can be installed only by special equipment, a basic operating system is usually installed in the terminal equipment before the terminal equipment is sold in order to facilitate the user to use the terminal equipment. Therefore, after purchasing the terminal equipment, the user can use the terminal equipment without carrying out complicated operation system installation operation by himself. For example, a basic phone operating system is installed on a mobile phone before the mobile phone is sold to a user. After purchasing the mobile phone, the user can directly use the basic functions of the mobile phone (for example, connecting to a mobile network, making a call).

After the terminal device is sold to the user, in the process of using the terminal device, the device may be operated incorrectly or even cannot be started due to data errors of the operating system. In this case, since the system operation has been wrong, the user can hardly make the system repair itself, and only return the device to the factory to rewrite the operating system, which not only affects the use of the terminal device by the user, but also greatly increases the maintenance cost of the device supplier. Therefore, a method for handling data errors of an operating system is needed.

Disclosure of Invention

In view of this, the present application provides a method, an apparatus, a storage medium, and a computer program product for managing a system installation package, so as to solve the problem in the prior art that an operating system cannot be run due to a static partition data error of the operating system.

In a first aspect, an embodiment of the present application provides a method for managing a system installation package, including:

manufacturing a basic partition mirror image;

making a first static partition mirror image of the first static partition and a second static partition mirror image of the second static partition;

generating slot first data corresponding to a first static partition based on the name of each sub-partition in a dynamic partition and the corresponding partition size, wherein the sub-partitions of the dynamic partition comprise first sub-partitions, the slot first data comprise a first description group and a second description group corresponding to the first sub-partitions, the value of an address item of the first description group is a first value, and the value of an address item of the second description group is a second value;

generating slot second data corresponding to a second static partition based on the slot first data, wherein the slot second data comprises a third description group and a fourth description group, the name item and the value of the group item of the third description group are consistent with the first description group, the name item and the value of the group item of the fourth description group are consistent with the second description group, and the value of the address item of the fourth description group is the first value;

packing the slot one data, the slot two data and the mirror image of each sub-partition in the dynamic partition into a dynamic partition mirror image;

and manufacturing a system installation package comprising the basic partition mirror image, the first static partition mirror image, the second static partition mirror image and the dynamic partition mirror image.

In an implementation manner of the first aspect, the generating, according to the slot one data, slot two data corresponding to a second static partition includes:

copying the data of the slot to be stored as first data;

modifying the first data, including modifying the value of the address entry of the second description group in the first data to the first value;

and saving the modified first data as the slot two data.

In an implementation manner of the first aspect, the modifying the first data further includes modifying a value of an address entry of the second description group in the first data to the second value.

In one implementation form of the first aspect, the second value is a null value.

In one implementation of the first aspect:

the sub-partition of the dynamic partition further comprises a second sub-partition, the slot one data further comprises a fifth description group and a sixth description group corresponding to the second sub-partition, the value of the address entry of the fifth description group is a third value, and the value of the address entry of the sixth description group is a fourth value;

the slot two data further comprises a seventh description group and an eighth description group, wherein the name item and the value of the group item of the seventh description group are consistent with the fifth description group, the name item and the value of the group item of the eighth description group are consistent with the sixth description group, and the value of the address item of the eighth description group is the third value;

in an implementation manner of the first aspect, the modifying the first data includes:

copying the data of the slot one and storing the data as first table data;

deleting the description group with the suffix name of _ b of the value of the name item in the first table data to generate second table data;

modifying the value-worthy suffix name of the name item in the second table data from _ a to _ b to generate third table data;

assigning the values of the address items of all the description groups in the third table data to the address items of the description groups with the same values of the name items in the first data respectively;

and setting the value of an address item in the description group with the name item suffix name of _ a in the assigned first data to be null.

copying the data of the slot one and storing the data as first table data;

the values of address entries in all description groups in the first data are nulled;

and respectively assigning the values of the address items of all the description groups in the third table data to the address items of the description groups with the same values of the name items in the first data after the values of the address items are null.

In an implementation manner of the first aspect, after the system installation package including the base partition image, the first static partition image, the second static partition image, and the dynamic partition image is manufactured, the method further includes:

and performing data burning based on the basic partition mirror image, the first static partition mirror image, the second static partition mirror image and the dynamic partition mirror image in the system installation package, and burning operating system data to a basic partition, a first static partition, a second static partition mirror image and a dynamic partition of equipment.

In a second aspect, the present application provides an electronic device comprising a processor and a memory, wherein the processor is configured to execute software codes stored in the memory, so that the electronic device executes the method flow according to the first aspect.

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

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

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

according to the method of the embodiment of the application, the device can support starting from any static partition, so that starting from another static partition can be performed when data of one static partition has an error, and the operating system can be run smoothly.

Drawings

In order to more clearly illustrate the technical solutions of the embodiments of the present application, the drawings needed to be used in the embodiments will be briefly described below, and it is obvious that the drawings in the following description are only some embodiments of the present application, and it is obvious for those skilled in the art to obtain other drawings based on these drawings without inventive labor.

Fig. 1 is a schematic structural diagram of a burning system framework for system burning before equipment leaves a factory in an application scene;

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

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

FIG. 4 is a schematic diagram of a frame structure of a burning system for system burning before equipment leaves a factory in an application scene;

FIG. 5 illustrates a portion of data held by Slot0 in one embodiment;

FIG. 6 is a block diagram of a data storage architecture for an operating system on a device in an application scenario;

FIG. 7 is a diagram of a data storage structure framework after an operating system is burned before the device leaves a factory in an application scenario;

FIG. 8a is a flowchart illustrating the production of a system installation package for an operating system;

FIG. 8b is a flowchart illustrating the production of a system installation package for an operating system according to one embodiment of the present application;

FIG. 9 is a flowchart illustrating the production of a system installation package for an operating system according to an embodiment of the present application;

FIG. 10 is a diagram illustrating partial data for Slot1 in one embodiment;

FIG. 11 is a flowchart illustrating the production of a system installation package for an operating system according to an embodiment of the present application.

Detailed Description

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

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

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

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

Aiming at the problem that the operation of the equipment is wrong or even the equipment cannot be started due to the wrong data of the operating system after the terminal equipment is sold in the hands of a user, a feasible solution is to construct operating system backup data on the equipment before the equipment leaves a factory. In this way, when an error occurs in the operating system data after the terminal device is sold to the user, it is possible to rollback to the state before the error occurred in the operating system using the backup data. However, the backup data occupies a storage space, which compresses a data space that can be freely used by a user, and causes a waste of the storage space.

In order to solve the problems, the data storage structure of the operating system is analyzed, and the original operating system storage space is used for realizing data backup before equipment leaves a factory, so that the equipment can be ensured to normally operate and smoothly start when the operating system data has errors on the premise that the data space which can be freely used by a user is not compressed.

Specifically, fig. 1 is a schematic diagram of a frame structure of a burning system for performing system burning before the device leaves a factory in an application scenario, as shown in fig. 1, after the device 100 is assembled in hardware, the device 100 is connected to the burning device 110, and the memory 120 is connected to the burning device 110. The installation package creating device 130 is configured to create a system installation package for installing the operating system, where the system installation package contains an image file of the operating system. The prepared system installation package is sent to the storage 120 for storage (the system installation package can be transmitted in various ways such as wired, wireless, or using a mobile hard disk to transfer). The burning device 110 reads the system installation package in the memory 120, analyzes the system installation package to obtain the image file of the operating system, performs data burning based on the image file of the operating system, and burns the operating system data corresponding to the image file of the operating system onto the memory of the device 100, thereby realizing the installation of the operating system on the device 100 before leaving the factory.

The device 100 of the embodiment of the present application includes, but is not limited to, a smart phone, a smart headset, a tablet computer, a smart refrigerator, a smart speaker, etc. to which an operating system can be installed. The device 100 may also be a control board in which an operating system may be installed. Exemplary embodiments of operating systems include, but are not limited to

Linux, or other operating systems.

Taking an android system adopting a virtual a/B upgrade mode as an example, fig. 1 is a schematic diagram of a data storage structure of the android system on a terminal device. After the burning device 110 burns an operating system on the device 100, a file structure of the operating system stored in the device 100 is as shown in fig. 2, and 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 (user data).

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

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

FIG. 3 is a flowchart illustrating an operating system upgrade for the system data storage structure of FIG. 2, where when a device is currently booting from a static partition (A), the device performs the operating system upgrade according to the flowchart illustrated in FIG. 3.

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

S310, the equipment obtains the operating system upgrading installation package.

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

S320, reading the operating system upgrading installation package stored in the S310 from a user data partition (Userdata), and performing data writing operation on the static partition (B) according to the operating system upgrading installation package to upgrade the static partition;

for example, the operating system upgrade installation package contains the data of the static partition of version 1.2, and the device overwrites the data of the static partition of version 1.2 in the static partition (B).

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

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

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

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

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

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

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

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

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

system_b-cow-img.img.0000；

system_ext_b-cow-img.img.0000；

vendor_b-cow-img.img.0000；

product_b-cow-img.img.0000；

cust_b-cow-img.img.0000；

odm_b-cow-img.img.0000。

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

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

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

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

/system/app/A0.XXX；

/system/app/A1.XXX；

/system/app/A2.XXX；

/system/B0.XXX；

/system/B1.XXX；

/system/user/C0.XXX；

/system/user/C1.XXX；

/system/user/C2.XXX；

/system/user/C3.XXX。

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

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

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

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

/system/B0.XXX：024021～024026；

/system/B1.XXX：024027～024028；

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

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

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

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

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

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

Can be regarded as:

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

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

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

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

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

/system/app/A2.XXX：

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

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

/system/user/C2.XXX：

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

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

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

/system/app/A2.XXX：

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

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

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

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

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

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

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

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

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

Specifically, in the checking process, dynamic partitions (Super) + COW files are merged based on snapshot. In the realization process of snapshot, the combination of the dynamic partition (Super) and the COW file is not the combination in the physical sense, but the whole file map of the sub-partition in the COW file and the COW file map of the COW file are combined to generate the file map of the new version of the sub-partition data.

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

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

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

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

/system/B0.XXX：024021～024026；

/system/B1.XXX：024027～024028；

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

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

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

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

and COW file map:

/system/app/A2.XXX：

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

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

/system/user/C2.XXX：

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

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

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

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

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

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

(Point to A1.XXX in dynamic partitioning (Super) Medium/System/app)

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

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

/system/B0.XXX：024021～024026；

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

/system/B1.XXX：024027～024028；

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

For example, the device first loads the base partition (Common). During loading of the base partition (Common), the device reads the start flag in the base partition (Common); when the boot flag (a) in the base partition (Common) is (a), the device loads the static partition (a) after loading the base partition (Common), thereby booting from the static partition (a); when the boot flag in the base partition (Common) is (B), the device loads the static partition (B) after loading the base partition (Common), thereby booting from the static partition (B).

In S340, the device reads the boot flag in the base partition (Common). The boot flag in the base partition (Common) is (B), and the device loads the static partition (B) after loading the base partition (Common), and boots from the static partition (B).

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

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

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

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

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

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

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

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

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

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.

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

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

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

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

S351, the device diskettes the data of the virtual dynamic partition to a dynamic partition (Super) in the background.

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

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

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

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

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

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

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

In the system data storage structure shown in fig. 2, the partition structures of the static partition (a) and the static partition (B) are consistent, and only one static partition needs to be read when the operating system is running, so in theory, when one static partition is unavailable, the other static partition can be used to maintain the normal running of the operating system. However, in an actual application scenario, after the terminal device of the android system adopting the virtual a/B upgrade method completes the installation of the operating system before shipment, the terminal device may only be started from the static partition (a), but cannot be started from the static partition (B). That is to say, after the terminal device of the android system adopting the virtual a/B upgrade mode finishes the installation of the operating system before leaving the factory, if the static partition (a) has a data error, the device cannot be started from the static partition (B), and only can return to the factory to repair the operating system data.

Specifically, fig. 4 is a schematic structural diagram of a burning system framework for system burning before the equipment leaves the factory in an application scene. In the android system adopting the virtual A/B upgrading mode, only the static partition adopts an A/B scheme, and the dynamic partition adopts a scheme of constructing a virtual dynamic partition during upgrading. Therefore, for matching the static partition and the dynamic partition, as shown in fig. 4, the Slot0 of the corresponding static partition (a) and the Slot1 of the static partition (B) are included in the metadata (/ hypermetadata) at the head of the dynamic partition (Super). Slot0 and Slot1 are used for storing the partition table of the Super partition. When the equipment is started, according to the difference of the started static partitions, the partition information of the Super partition is selected to be acquired from one of the Slot0 or the Slot1. For example, when the device is started by the static partition a, when the Super partition is loaded, the device first reads Slot0 to obtain the sub-partition address of the Super partition; when a device is started by the static partition B, when the Super partition is loaded, the device first reads Slot1 to obtain the sub-partition address of the Super partition.

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

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

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

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

address (extensions) entries, whose value is the address of the child partition.

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

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

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

Generally, in Slot0 and Slot1, for each sub-partition of the Super partition, there are two sets of sub-partition descriptions, one set of sub-partition description corresponding to static partition (a) and one set of sub-partition description corresponding to static partition (B). When reading Slot0 or Slot1, the device selects the sub-partition description that needs to be read according to the suffix (_ a or _ b).

FIG. 5 illustrates a portion of data held by Slot0 in one embodiment. As shown in fig. 5, in the partition description Group with the suffix of the values of the Name entry and the Group entry being _ a, the value of the extensions entry is the real address of the child partition. In the partition description Group with the suffix of the values of the Name entry and the Group entry as _ b, the value of the extensions entry is nulled.

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

When the Slot0 is read, because the suffix _ B corresponds to the static partition (B), the device does not need to read the partition description Group in the Slot0, where the suffix _ B is the Name entry and/or the suffix _ B is the Group entry, and therefore, in the partition description Group in which the suffix _ B is the values of the Name entry and the Group entry, the value of the extensions entry is left blank, which does not affect the loading of the Super partition.

Further, in an embodiment, the data stored in Slot1 is similar to the data structure shown in fig. 5, except that in order to ensure that the Super partition is loaded smoothly, in the data in Slot1, in the partition description Group with the suffix _ b of the values of the Name entry and the Group entry, the value of the extensions entry is the real address of the sub-partition. In the partition description Group with the suffix of the values of the Name entry and the Group entry as _ a, the value of the extensions entry is nulled.

FIG. 6 is a block diagram of a data storage structure of an operating system of a device in an application scenario. Taking the System sub-partition of the Super partition as an example, as shown in fig. 6, the data for the System sub-partition in Slot0 is:

Name：system_a

Group：qti_dynamic_partitions_a

Attributes：readonly

Extents：0..6995967 linear super 2048

Name：system_b

Group：qti_dynamic_partitions_b

Attributes：readonly

Extents：

thus, when the device boots from static partition (a), the device reads system _ a sub-partition data suffixed with _ a in Slot0. Based on System _ a data in Slot0, the device can smoothly load the System sub-partition.

As shown in fig. 6, the data for the System sub-partition in Slot1 is:

Name：system_a

Group：qti_dynamic_partitions_a

Attributes：readonly

Extents：

Name：system_b

Group：qti_dynamic_partitions_b

Attributes：readonly

Extents：0..6995967 linear super 2048

thus, when the device boots from static partition (B), the device reads system _ B sub-partition data suffixed with _ B in Slot1. Based on System _ b data in Slot0, the device can smoothly load the System sub-partition.

However, when the operating system is burned before the device leaves the factory, the same data is burned in Slot1 and Slot0. That is, in Slot1, in the partition description Group where the suffix of the values of the Name entry and the Group entry is _ a, the value of the extensions entry is the real address of the child partition. In the partition description Group with the suffix of the values of the Name entry and the Group entry as _ b, the value of the extensions entry is nulled. Thus, after the device is burned by an operating system before being shipped from a factory, if the device is tried to be started from the static partition (B), when the Super partition is loaded, the value of the extensions item is read from the partition description Group with the suffix of _ B in the Name item and the Group item in the Slot1. Since the value of the extensions entry in the partition description Group with the suffix of the values of the Name entry and the Group entry in the Slot1 as _ b is set to be null, an address read failure occurs, and the Super partition cannot be loaded smoothly. Therefore, the static partition (B) cannot boot the device.

For example, fig. 7 is a schematic diagram of a data storage structure framework after the device is burned with an operating system before leaving factory in an application scenario. Taking the System sub-partition of the Super partition as an example, as shown in fig. 7, the data for the System sub-partition in Slot0 is:

Name：system_a

Group：qti_dynamic_partitions_a

Attributes：readonly

Extents：0..6995967 linear super 2048

Name：system_b

Group：qti_dynamic_partitions_b

Attributes：readonly

Extents：

as shown in fig. 7, the data for the System sub-partition in Slot1 is consistent with that in Slot0, and is:

Name：system_a

Group：qti_dynamic_partitions_a

Attributes：readonly

Extents：0..6995967 linear super 2048

Name：system_b

Group：qti_dynamic_partitions_b

Attributes：readonly

Extents：

thus, when the device boots from static partition (B), the device reads system _ B sub-partition data suffixed with _ B in Slot1. Since the extensions entry for System _ b data in Slot1 is nulled, the device cannot load the System sub-partition smoothly.

In order to solve the above problems, the present application provides a method for installing an operating system before factory shipment, which modifies a native manufacturing process of a dynamic partition (Super) image in a system installation package of the operating system and creates a modified image manufacturing process before the operating system is installed before factory shipment. And manufacturing a modified dynamic partition (Super) mirror image by adopting a modified mirror image manufacturing process, so that the Slot0 and the Slot1 of the dynamic partition (Super) in the modified dynamic partition (Super) mirror image are correct configuration data. And installing the operating system before leaving a factory based on the system installation package containing the modified dynamic partition (Super), wherein after the operating system is installed, the static partition (A) and the static partition (B) on the equipment can both start the equipment, so that when the static partition (A) has data errors, a user can start the equipment through the static partition (B), the normal operation of the operating system is maintained, and the data is repaired.

FIG. 8a is a flow chart illustrating native production of a system installation package for an operating system. The installation package producing apparatus 130 executes the flow shown in fig. 8a to generate the operating system installation package.

S810a, manufacturing a Common partition image. Specifically, files of the base partition (Common) are acquired and packaged as a base partition (Common) image.

S820a, a static partition (a) image and a static partition (B) image are created. Specifically, the mirror image of each sub-partition of the static partition is obtained and packaged into the mirror image of the static partition (a) and the mirror image of the static partition (B).

S830a, obtaining the name and the corresponding partition size of each sub-partition in the dynamic partition (Super).

And S831a, generating Slot0 data according to the name and the corresponding partition size of each sub-partition in the dynamic partition (Super). For example, the Slot0 data as shown in fig. 5 is generated.

S832a, the Slot0 data is copied and saved as Slot1 data.

And S833a, acquiring a sub-partition mirror image of each sub-partition in the dynamic partition (Super).

In S833a, the sub-partition image of each sub-partition may be pre-manufactured, and the sub-partition image may be obtained by directly reading from the storage device that stores the sub-partition image. Or, the files of the sub-partitions can be directly acquired, and the files of the sub-partitions are packaged into sub-partition images through an image making tool.

S834a, packaging the sub-partition mirror images of each sub-partition in the dynamic partition (Super) of the Slot0 data and the Slot1 data into a dynamic partition (Super) mirror image.

S840a, a system installation package containing a Common image of a basic partition, a static image of a partition and a Super image of a dynamic partition is manufactured.

In an embodiment of the present application, the dynamic partition mirroring process shown in fig. 8a is modified. FIG. 8b is a flowchart illustrating the production of a system installation package for an operating system according to an embodiment of the present application. The installation package producing apparatus 130 executes the flow shown in fig. 8b to generate the operating system installation package.

S810b to S831b refer to S810a to S831a.

S832B, generating Slot1 data according to the Slot0 data, wherein Super partition sub-partition description data corresponding to the static partition B in the Slot1 data is a real value.

S833b to S840b refer to S833a to S840a.

Specifically, in S832b, the Slot0 data is copied, saved as Slot11 data, and the Slot11 data is corrected to generate Slot1 data. In the process of correcting the Slot11 data, the value of an extensions item in a partition description Group with the suffix of _ b of the values of the Name item and the Group item of the Slot11 data is modified from null to real value.

Further, in S832b, in the process of correcting the Slot11 data, the values of extensions items in the partition description Group with the suffix of the values of the Name item and the Group item in the Slot11 data as _ a are also set to be null.

Or, considering that the static partition (B) starts the device, when reading the Slot1, the partition description Group with the suffix _ a of the values of the Name entry and the Group entry is not read, so in S832B, in the process of correcting the Slot11 data, the values of the extensions entry in the partition description Group with the suffix _ a of the values of the Name entry and the Group entry in the Slot11 data are not modified.

After S840b, the system installation package is completed. The system installation package is sent to the memory 120, the storage burning device 110 reads the system installation package in the memory 120, the system installation package is analyzed to obtain an image file of the operating system, data burning is performed based on the image file of the operating system, and operating system data corresponding to the image file of the operating system is burned to the memory of the device 100, so that the operating system is installed on the device 100 before leaving a factory. At this time, the device 100 may boot from either the static partition (a) or the static partition (B).

Further, the present application does not specifically limit the specific implementation manner of S832b, and those skilled in the art may implement S832b in various feasible implementations. Specific embodiments are described below in conjunction with the accompanying drawings, and a specific implementation flow of the example S832b is illustrated. The following describes a specific implementation procedure of the embodiments of the present application by way of specific examples.

FIG. 9 is a flowchart illustrating the production of a system installation package for an operating system according to an embodiment of the present application. The installation package producing device 130 executes the flow shown in fig. 9 to realize S832b.

S931, copying the Slot0 data and saving the data as the Slot01 data;

the Slot0 data is:

first description group:

Name：system_a

Group：qti_dynamic_partitions_a

Attributes：readonly

extensions: 6995967 Linear super 2048 (first value)

Second description group:

Name：system_b

Group：qti_dynamic_partitions_b

Attributes：readonly

extensions: (second value)

Fifth description group:

Name：system_ext_a

Group：qti_dynamic_partitions_a

Attributes：readonly

extensions: 262143 line super 6998016 (third value)

Sixth description group:

Name：system_ext_b

Group：qti_dynamic_partitions_b

Attributes：readonly

extensions: (fourth value)

S932, deleting the sub-partition description Group with the suffix of the value of the Name item or the Group item in the Slot01 data as _ b to generate the Slot02 data;

for example, assuming that partial data in the Slot0 data is as shown in fig. 10 (partial data of the Slot11 data is as shown in fig. 5), the Slot0 data is copied and saved as Slot01 data, and after Slot02 data is generated from the Slot01 data, data corresponding to the partial data shown in fig. 5 in the Slot02 data is:

Name：system_a

Group：qti_dynamic_partitions_a

Attributes：readonly

Extents：0..6995967 linear super 2048

Name：system_ext_a

Group：qti_dynamic_partitions_a

Attributes：readonly

Extents：0..262143 linear super 6998016

s933, modifying suffixes (_ a) of values of the Name item and the Group item in the Slot02 data into (_ b), and generating Slot03 data;

for example, as shown in fig. 10, the data corresponding to the partial data shown in fig. 5 in the Slot03 data is:

Name：system_b

Group：qti_dynamic_partitions_b

Attributes：readonly

Extents：0..6995967 linear super 2048

Name：system_ext_b

Group：qti_dynamic_partitions_b

Attributes：readonly

Extents：0..262143 linear super 6998016

in S933, the suffix of the value of the Group entry may not be modified.

S934, copying the Slot0 data and storing the Slot0 data as Slot11 data;

s935, selecting an unselected sub-partition description group (a first sub-partition description group) in the Slot03 data;

specifically, before S935, all sub-partition descriptions in the Slot03 data are unselected. In S933, a selected (checked) entry is added to all the sub-partition description groups, and the value of the checked entry of all the sub-partition description groups is 0. In S935, a sub-partition description group that has not been selected (a sub-partition description group whose value of a checked entry is 0) is determined from the value of the checked entry. In S935, when an unselected sub-partition description group is selected, the value of the checked entry in the group is set to 1.

S936, matching the value of the Name item of each sub-partition description group in the Slot11 data with the value of the Name item of the first sub-partition description group, and determining a sub-partition description group (a second sub-partition description group) with the value of the Name item of the first sub-partition description group consistent with the value of the Name item of the first sub-partition description group in the Slot11 data;

s937, configuring the values of extensions in the second sub-partition description group in the Slot11 data as the values of extensions in the first sub-partition description group in the Slot03 data;

s938, judging whether the unselected sub-partition description group exists in the Slot03 data;

if yes, returning to S935;

if not, go to S939;

for example, as shown in fig. 10, the Slot11 data is matched with the Slot0 data immediately before creation (before correction), and after correction, the data corresponding to the partial data shown in fig. 5 in the Slot11 data is:

Name：system_a

Group：qti_dynamic_partitions_a

Attributes：readonly

Extents：0..6995967 linear super 2048

Name：system_b

Group：qti_dynamic_partitions_b

Attributes：readonly

Extents：0..6995967 linear super 2048

Name：system_ext_a

Group：qti_dynamic_partitions_a

Attributes：readonly

Extents：0..262143 linear super 6998016

Name：system_ext_b

Group：qti_dynamic_partitions_b

Attributes：readonly

Extents：0..262143 linear super 6998016

s939, the extension value in the sub-partition description Group with the suffix of the value of the Name item or the Group item in the Slot11 data as _ a is set to be null, and the Slot11 data is saved as the Slot1 data.

For example, as shown in fig. 10, after S941 is executed (after blanking), the data corresponding to the partial data shown in fig. 5 in the Slot1 data is:

third description group:

Name：system_a

Group：qti_dynamic_partitions_a

Attributes：readonly

extensions: (second value)

Fourth description group:

Name：system_b

Group：qti_dynamic_partitions_b

Attributes：readonly

extensions: 6995967 Linear super 2048 (first value)

Seventh description group:

Name：system_ext_a

Group：qti_dynamic_partitions_a

Attributes：readonly

extensions: (fourth value)

Eighth description group:

Name：system_ext_b

Group：qti_dynamic_partitions_b

Attributes：readonly

extensions: 262143 line super 6998016 (third value)

Fig. 11 is a flowchart illustrating a manufacturing process of a system installation package of an operating system according to an embodiment of the application. The installation package producing apparatus 130 executes the flow shown in fig. 11 to generate the operating system installation package.

S1131 to S1134, refer to S931 to S934.

S1135, the values of all extensions entries in the Slot11 are nulled.

S1136 to S1138, refer to S935 to S937.

S1139, judging whether the unselected sub-partition description group exists in the Slot03 data;

if so, return to S1136;

if not, the process ends.

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

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

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

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

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

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

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

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

Claims

1. A management method of a system installation package, wherein the system installation package is used for burning an operating system to a device before the device leaves a factory, comprising:

manufacturing a basic partition mirror image;

manufacturing a first static partition mirror image of a first static partition and a second static partition mirror image of a second static partition, wherein the first static partition mirror image and the second static partition mirror image both contain static partition data capable of starting the equipment;

2. The method of claim 1, wherein generating slot two data corresponding to a second static partition from the slot one data comprises:

copying the data of the slot to be stored as first data;

and saving the corrected first data as the second slot data.

3. The method of claim 2, wherein modifying the first data further comprises modifying a value of an address entry of the second description group in the first data to the second value.

4. The method of claim 3, wherein the second value is a null value.

5. The method of claim 1, wherein:

the sub-partitions of the dynamic partition further comprise a second sub-partition, the slot one data further comprise a fifth description group and a sixth description group corresponding to the second sub-partition, the value of the address entry of the fifth description group is a third value, and the value of the address entry of the sixth description group is a fourth value;

the slot two data further includes a seventh description group and an eighth description group, wherein a name entry and a value of a group entry of the seventh description group are consistent with the fifth description group, a name entry and a value of a group entry of the eighth description group are consistent with the sixth description group, and a value of an address entry of the eighth description group is the third value.

6. The method of claim 3, wherein modifying the first data comprises:

copying the data of the slot one and storing the data as first table data;

modifying the suffix name of the value of the name item in the second table data from _ a to _ b to generate third table data;

and setting the value of the address item in the description group with the name item suffix name as _ a in the assigned first data to be null.

7. The method of claim 3, wherein modifying the first data comprises:

copying the data of the slot one and storing the data as first table data;

deleting the description group with the suffix name of the value of the name item in the first table data as _ b to generate second table data;

and respectively assigning the values of the address items of all the description groups in the third table data to the address items of the description groups with the same name item in the first data after the values of the address items are set to be null.

8. The method of any of claims 1-7, wherein after the making the system installation package comprising the base partition image, the first static partition image, the second static partition image, and the dynamic partition image, the method further comprises:

9. An electronic device, comprising a processor and a memory, wherein the processor is configured to execute software code stored on the memory to cause the electronic device to perform the method flows of any of claims 1-8.

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

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