CN114489813A

CN114489813A - Method, equipment and storage medium for configuring operating system

Info

Publication number: CN114489813A
Application number: CN202110870629.1A
Authority: CN
Inventors: 王艳召; 郝庆涛; 陈超; 张赠辉
Original assignee: Honor Device Co Ltd
Current assignee: Honor Device Co Ltd
Priority date: 2021-07-30
Filing date: 2021-07-30
Publication date: 2022-05-13
Anticipated expiration: 2041-07-30
Also published as: CN114489813B; CN116795438A

Abstract

The method, the equipment, the storage medium and the computer program product for configuring the operating system standard are applied to electronic equipment, and a first standard file is stored in a basic partition of a memory of the electronic equipment; the method comprises the following steps: acquiring an operating system upgrade package comprising a second standard file; modifying the starting sequence; writing the standard content of the second standard file into a temporary standard file; restarting, starting the operating system; writing the standard content of the temporary standard file into a first standard file; restarting to enter a recovery mode; restoring factory settings of the electronic equipment; and restarting, starting the operating system, creating a system configuration file in the user data partition, and writing the system content of the first system file into the system configuration file. According to the method of the embodiment of the application, the remanufacturing process can be greatly simplified, and the remanufacturing difficulty is reduced.

Description

Method, equipment and storage medium for configuring operating system

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 configuring an operating system standard.

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. In the field of wireless communication, according to the location of a wireless communication device (e.g., a mobile phone) and the difference of operators accessed, an operating system of the wireless communication device needs to configure a corresponding standard (VC); for example, all cn (universal chinese system), cmcc cn (china mobile chinese system), etc.

Generally, when an initial operating system is installed before a wireless communication device leaves a factory, an operating system configured with a corresponding standard is installed according to a sales area of the wireless communication device. After the wireless communication equipment leaves a factory, the system of the operating system does not need to be changed. However, in an actual application scenario, there is a case where the standard of the operating system of the wireless communication device needs to be changed. For example, the original vendor _ country of a overseas country is xxxx _ ru (russian system of the operator xxxx), and the mobile phone system needs to be adjusted to a matching system due to overstock of goods or due to goods shortage in another country. Therefore, a method for changing the standard of the operating system of the wireless communication device 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 configuring an operating system format, so as to solve the problem of how to change the operating system format in the prior art.

In a first aspect, an embodiment of the present application provides a method for configuring a system of an operating system, which is applied to an electronic device, where the electronic device includes a processor and a memory, the memory includes a basic partition, a first static partition, a second static partition, a dynamic partition, and a user data partition, a first system file is stored in the basic partition, and a current system content of the first system file is a first system; after the electronic equipment is started, loading data of the basic partition, the first static partition and the dynamic partition so as to start an operating system from the first static partition; the process of starting the operating system by the electronic equipment comprises an initialization link; after the operating system is started, the method comprises the following steps:

acquiring an operating system upgrade package, wherein the operating system upgrade package comprises a second standard file, and standard contents of the second standard file are of a second standard;

modifying the boot sequence of the electronic device to boot from the second static partition;

extracting a second standard file;

creating a temporary system file, and writing the system content of the second system file into the temporary system file;

triggering a first restart of the electronic equipment, and starting an operating system from the second static partition by the electronic equipment after the first restart;

writing the standard content of the temporary standard file into a first standard file;

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

in the recovery mode, recovering factory settings of the electronic equipment, including deleting the system configuration file stored in the user data partition;

triggering a third restart of the electronic device, after the third restart, starting the operating system from the second static partition by the electronic device, wherein an initialization link after the third restart at least comprises: creating a system configuration file in the user data partition, and writing the system content of the first system file into the system configuration file.

According to the method of the first aspect, the tailoring can be achieved for an operating system that employs a virtual A/B upgrade scheme; according to the method of the first aspect, additional remanufacturing tools do not need to be configured, and the device can complete remanufacturing operation by downloading the operating system upgrade package, so that remanufacturing procedures are greatly simplified, and remanufacturing difficulty is reduced.

In an implementation manner of the first aspect, the initialization link further includes a system loading step, where the first system file is loaded in the initialization link before the second restart and the initialization link after the third restart.

In an implementation manner of the first aspect, the initialization step after the third restart further includes:

and confirming whether the system configuration file exists in the user data partition, creating the system configuration file in the user data partition when the system configuration file does not exist in the user data partition, and writing the system content of the first system file into the system configuration file.

In an implementation manner of the first aspect, after writing the system content of the temporary system file into the first system file, the method further includes:

and deleting the temporary standard file.

In an implementation manner of the first aspect, the initializing step further includes a system loading step, where the temporary system file is loaded in the initializing step after the first reboot.

In one implementation manner of the first aspect, the initialization step after the first reboot further includes:

judging whether factory settings need to be restored or not;

and when the factory setting does not need to be restored, continuing the subsequent operation of starting the operating system.

In an implementation manner of the first aspect, determining whether factory settings need to be restored includes:

determining whether a system configuration file stored in a user data partition is matched with a first system file;

if the electronic equipment is matched with the preset electronic equipment, the factory setting of the electronic equipment is determined not to be required to be restored;

and if not, confirming that the factory settings of the electronic equipment need to be restored.

In an implementation manner of the first aspect, the first operating system and the second operating system are operating systems corresponding to different standards, the first operating system corresponds to the first standard, and the second operating system corresponds to the second standard; the operating system upgrading package further comprises static partition upgrading data, and the static partition upgrading data is used for updating the static partition data of the first operating system into the static partition data of the second operating system; before obtaining an operating system upgrade package, after starting the electronic equipment, loading data of a basic partition, a first static partition and a dynamic partition so as to start a first operating system from the first static partition;

before modifying the boot order of the electronic device to boot from the second static partition, the method further comprises: updating data of the second static partition based on the static partition upgrade data;

the process for the electronic device to boot the operating system from the second static partition after the first reboot includes:

and loading the data of the base partition, the second static partition and the dynamic partition to start the second operating system.

According to the method of the implementation manner of the first aspect, the static partition data can be updated while the operating system is modified, so that the operating system is upgraded to the corresponding customized operating system version while the operating system is modified, multiple times of operating system upgrading operations are avoided, the upgrading process of the operating system is greatly simplified, and the user experience is improved.

In one implementation of the first aspect, after the electronic device boots an operating system from the second static partition after the first reboot, data of the second static partition is synchronized to the first static partition.

In an implementation manner of the first aspect, the first operating system and the second operating system are operating systems corresponding to different standards, the first operating system corresponds to the first standard, and the second operating system corresponds to the second standard; the operating system upgrading package also comprises dynamic partition upgrading data, and the dynamic partition upgrading data is used for updating the dynamic partition data of the first operating system into the dynamic partition data of the second operating system; before obtaining an operating system upgrade package, after starting the electronic equipment, loading data of a basic partition, a first static partition and a dynamic partition so as to start a first operating system from the first static partition;

before modifying the boot order of the electronic device to boot from the second static partition, the method further comprises:

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

loading data of the base partition, the second static partition, the dynamic partition and the virtual dynamic partition to start a second operating system;

after the electronic device starts the operating system from the second static partition after the first restart, the data of the virtual dynamic partition is landed to the dynamic partition.

According to the method of the implementation manner of the first aspect, the dynamic partition data can be updated while the operating system is modified, so that the operating system is upgraded to the corresponding customized operating system version while the operating system is modified, multiple times of operating system upgrading operations are avoided, the upgrading process of the operating system is greatly simplified, and the user experience is improved.

In an implementation manner of the first aspect, after writing the system content of the second system file into the first system file, the method further includes:

triggering a fourth restart of the electronic equipment, and starting the operating system from the second static partition by the electronic equipment after the fourth restart;

the initialization step after the fourth reboot further includes:

judging whether factory settings need to be restored or not;

and when the factory setting needs to be restored, interrupting the starting operation of the operating system and triggering a second restart.

and if not, confirming that factory settings of the electronic equipment need to be restored.

In an implementation manner of the first aspect, the initializing step further includes a system loading step, where the first system file is loaded in the initializing step after the fourth restart.

In an implementation manner of the first aspect, before extracting the second format file, the method further includes:

and determining whether the operating system upgrade package is used for rewriting the system, and extracting a second system file when the operating system upgrade package is used for rewriting the system.

In an implementation manner of the first aspect, determining whether the operating system upgrade package is used for rewriting the schema includes determining whether a second schema file exists in the operating system upgrade package.

In an implementation manner of the first aspect, the initialization step further includes a system loading step, where:

when the state of the first system file is not rewritten, loading a temporary system file;

and when the state of the first system file is rewritten, loading the first system file.

In an implementation manner of the first aspect, the initializing step further includes a system loading step, where:

when the disk-dropping state is the disk-dropping-free state and the state of the first system file is not rewritten, loading a temporary system file;

and when the state of the first system file is rewritten or the disk-dropping state is disk-dropping, loading the first system file.

In one implementation of the first aspect:

before extracting the second standard file, the method also comprises the steps of confirming whether the operating system upgrading packet is used for rewriting the standard, and marking the state of the first standard file as not rewritten when the operating system upgrading packet is used for rewriting the standard;

after the system content of the second system file is written into the first system file, the state of the first system file is marked as being rewritten.

In an implementation manner of the first aspect, the operating system includes an upgrade package obtaining tool and an upgrade engine, the first operating system and the second operating system are operating systems corresponding to different standards, the first operating system corresponds to a first standard, and the second operating system corresponds to a second standard; before an operating system upgrade package is acquired, the electronic equipment loads data of a basic partition, a first static partition and a dynamic partition after being started so as to start a first operating system from the first static partition, and a first standard file is loaded in an initialization link of starting the first operating system; after the first operating system is started, the method comprises the following steps:

the upgrade package obtaining tool obtains an operating system upgrade package, wherein the operating system upgrade package comprises a second standard file, static partition upgrade data and dynamic partition upgrade data;

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

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

the upgrading engine creates a virtual dynamic partition in the user data partition, writes the dynamic partition upgrading data into the virtual dynamic partition, and marks that the disk-dropping state is not disk-dropping;

the upgrading engine modifies the starting sequence of the electronic equipment to be started from the second static partition;

the upgrading engine confirms whether the operating system upgrading packet is used for rewriting the system;

when the operating system upgrade package is used for rewriting the system, the upgrade engine creates a temporary system file, writes the system content of the second system file into the temporary system file, and marks the state of the first system file as not being rewritten;

the upgrading engine returns the state information of the completion of the upgrading operation to the upgrading packet acquisition tool;

the upgrade package acquisition tool triggers a first restart of the electronic equipment, and after the first restart, the electronic equipment loads data of the basic partition, the second static partition, the dynamic partition and the virtual dynamic partition to start a second operating system;

in an initialization phase in which the second operating system is started after the first reboot: when the disk-dropping state is the disk-dropping-free state and the state of the first system file is not rewritten, loading a temporary system file; when the standard configuration file stored in the user data partition is matched with the first standard file, confirming that factory settings of the electronic equipment do not need to be restored, and continuing to perform operating system starting operation;

after the second operating system is started after the first restart, triggering an upgrade engine to enter a tray-dropping process by an upgrade package acquisition tool;

in the process of disk dropping, the upgrading engine drops the data of the virtual dynamic partition to the dynamic partition and marks the disk dropping state as the dropped disk; synchronizing data of the second static partition to the first static partition; writing the system content of the temporary system file into a first system file, deleting the temporary system file and marking the state of the first system file as being rewritten;

the upgrading engine triggers fourth restarting of the electronic equipment, and the electronic equipment loads data of the basic partition, the second static partition and the dynamic partition after the fourth restarting so as to start a second operating system;

in an initialization phase in which the second operating system is started after the fourth reboot: when the disk dropping state is the disk dropping state or the state of the first system file is rewritten, loading the first system file; when the system configuration file stored in the user data partition is not matched with the first system file, confirming that factory settings of the electronic equipment need to be restored, interrupting the starting operation of an operating system, and triggering a second restart;

after the second restart, the electronic equipment enters a recovery mode, factory settings of the electronic equipment are recovered, and a third restart is triggered;

after the third restart, the electronic device starts the second operating system from the second static partition, and in an initialization link of starting the second operating system after the third restart: when the disk dropping state is the disk dropping state or the state of the first system file is rewritten, loading the first system file; when the system configuration file does not exist in the user data partition, the system configuration file is established in the user data partition, and the system content of the first system file is written into the system configuration file.

In a second aspect, an embodiment of the present application provides an electronic device, where the electronic device includes a processor and a memory, where the memory includes a base partition, a first static partition, a second static partition, a dynamic partition, and a user data partition, where the base partition stores a first standard file, a current standard content of the first standard file is a first standard, and the processor is configured to execute a software code stored in the memory, so that after the electronic device is started, data of the base partition, the first static partition, and the dynamic partition are loaded to start an operating system from the first static partition; the process of starting the operating system by the electronic equipment comprises an initialization link;

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

In a third aspect, embodiments of the present application provide a computer-readable storage medium, in which a computer program is stored, which, when run on a computer, causes the computer to perform the method according to the first aspect.

In a fourth aspect, embodiments of the present application provide 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 remanufacturing can be realized aiming at the operating system adopting the virtual A/B upgrading scheme; according to the method of the embodiment of the application, the remanufacturing process can be greatly simplified, and the remanufacturing difficulty is reduced.

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 block diagram of an operating system partition architecture according to an embodiment of the present application;

FIG. 2a is a schematic diagram of a remanufacturing system according to an embodiment of the present application;

FIG. 2b is a schematic diagram of a remanufacturing process according to an embodiment of the present application;

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

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

FIG. 5a is a flowchart illustrating an operating system upgrade for the operating system data storage structure of the embodiment shown in FIG. 4;

FIG. 5b is a schematic diagram of a system framework for system burn before equipment leaves a factory in an application scenario;

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

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

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

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

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

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

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

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

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

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

Detailed Description

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

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

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

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

Fig. 1 is a diagram illustrating an operating system partition architecture according to an embodiment of the present application. As shown in FIG. 1, the Common partition is a base partition that holds system data that does not participate in operating system upgrades. The user data partition (Userdata) is used for storing personal data of users, such as personal data of APPs installed by the users, pictures, documents and videos stored by the users. The system partition is used for storing the data of the operating system, and the upgrading of the operating system is carried out aiming at the data in the system partition. The system partition includes multiple sub-partitions, such as bootloader, boot, vendor _ boot, dtbo, vbmeta, Super. Further, the Super partition comprises a plurality of sub-partitions, such as System, System _ ext, vendor, product, Cust, Odm.

In general, the system information VC (e.g., All cn, cmcc cn) of the operating system is stored in a separate sub-partition in the Common partition, for example, the oeminfo sub-partition or nv sub-partition of the Common partition. During the process that the device starts the operating system, the device reads and loads the VC information in the Common partition, and the VC information is also written into the customization information (custom. bin file) stored in the user data partition (Userdata) so as to be called during the process of operating system running.

Since the VC is stored in the Common partition that does not participate in the os upgrade, normal os upgrade operations cannot overwrite VC data. One possible way to rewrite a VC is to rewrite the VC with a computer-based remanufacturing tool.

Fig. 2a is a schematic structural diagram of a remanufacturing system according to an embodiment of the present application. The computer customization tool 200 accesses a device 201 (e.g., a cell phone) and connects to an authorization server (dongle) 210 over a network. When the computer modifying tool 200 accesses the device 201, the device 201 is not operated in the state of the operating system that is normally started, but is in a mode in which data can be written by the computer modifying tool 200, for example, the operating system is not started after the mobile phone is turned on, and the mobile phone enters a debugging mode, and in the debugging mode, the memory on the mobile phone can be written with data by the computer modifying tool with legal authorization.

Fig. 2b is a schematic diagram of a remanufacturing process according to an embodiment of the present application. As shown in fig. 2 b:

s200, the computer modifying tool 200 requests authorization from an authorization server (dongle) 210;

s201, after the request is passed, the computer modifying tool 200 obtains the authorization from the authorization server (dongle) 210.

After the computer modifying tool 200 obtains the authorization, S210 is executed, and the computer modifying tool 200 directly rewrites the VC stored in the Common partition of the memory of the device 201, for example, the VC stored in the Common partition oeminfo sub-partition is rewritten from All cn to cmcc cn.

Before S210, VC stored in the Common partition of the device 201 is All cn; thus, VC is All cn in the custom of the user data partition (Userdata) of the device 201 memory before S210. In S210, the computer engineering tool 200 overwrites only the VC stored in the Common partition, so that after S210, in the custom of the user data partition (Userdata), the VC remains All cn.

S220, the device 201 restarts. Specifically, the restart of the device 201 may be triggered by the computer modifying tool 200, for example, the computer modifying tool 200 sends a restart instruction to the device 201 after rewriting the VC of the device 201. Or the user may restart the device 201 by himself.

After 220, the device 201 normally starts the operating system. In the process of starting the operating system by the device 201, the device executes S230, and the device 201 reads VC (cmcc.cn) saved in the Common partition; check if the VC stored in the Common partition matches the custom of the user data partition (Userdata). The VC in the Custom.bin is still All cn, so the VC in the Custom.bin is not matched with the VC stored in the Common partition;

s240, the device 201 restores the factory settings (clears custom.

In a practical application scenario, the os provider will typically provide different os customized content for different VCs. For example, for china mobile (cmcc), an operating system provider may embed a data connection platform specific to china mobile in the operating system. Therefore, in some application scenarios, while the VC is changed, in order to ensure the integrity of the operating system functions, it is necessary to synchronously rewrite the operating system data (upgrade the operating system version of the current, old VC to the operating system version of the new VC).

Thus, following S240, S250 is executed to program operating system data in the system partition of the memory of device 201 that matches the VC stored in the Common partition, e.g., to overwrite data in the system partition with operating system image data that matches the VC stored in the Common partition.

Further, if the operating system is not customized for a different VC, there is no need to re-write operating system data.

S260, the device 201 restarts, and the new version VC (cmcc cn) takes effect.

Although the VC can be rewritten according to the embodiments shown in fig. 2 and 3, since the rewriting operation must be performed by a computer modification tool, the hardware cost of the modification operation is high; moreover, in some network environments, an authorization server (dongle) node cannot be deployed, so that the difficulty in implementing the remanufacturing operation is high.

Another possible way for VC overwriting is to exit the operating system, enter a Recovery (Recovery) mode, overwrite the common VC data in the device's memory and rewrite the data in the system partition under Recovery.

Specifically, fig. 3 is a flowchart illustrating upgrading an operating system according to an embodiment of the present application. Suppose an operating system of version 1.01 corresponds to a VC of a first standard (e.g., All cn) and an operating system of version 1.02 corresponds to a VC of a second standard (e.g., cmcc cn). As shown in fig. 3, the device performs the following procedure to upgrade the operating system from version 1.01 to version 1.02:

s300, acquiring an operating system upgrade package, and storing the operating system upgrade package into a Userdata partition, wherein the operating system upgrade package comprises VC data of a second system (cmcc cn) and mirror image data of an operating system of version 1.02;

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

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

s321, extracting the mirror image data of the operating system with the version 1.02 in the operating system upgrade package, and restoring the mirror image data to a system partition; s321 aims to upgrade the operating system version of the equipment to the operating system version matched with the second system (cmcc cn), and if the operating system is not customized for all cn and cmcc cn, the operating system upgrade package does not need to contain mirror image data of the operating system;

s322, extracting VC data of a second system (cmcc cn) in the operating system upgrade package, and rewriting VC (e.g. All cn stored in oeminfo sub-partition) stored in a Common partition of the device memory by using the VC data of the second system (cmcc cn);

s323, restoring factory settings of the device (clear custom. bin);

s330, restarting the equipment, starting the operating system, and enabling the new version VC (cmcc cn) to take effect.

Although rewriting of the VC can be achieved based on the flow shown in fig. 3, as data security requirements continue to increase, in some operating systems, access to the user's personal data in the Recovery (Recovery) mode is prohibited, which makes it impossible for the device to rewrite the operating system data in the partition in the Recovery (Recovery) mode.

Taking an android system adopting a virtual a/B upgrade mode as an example, fig. 4 is a schematic diagram of a data storage structure according to an embodiment of the present application. As shown in fig. 4, the android system data storage area includes a basic partition (Common), a static partition (a), a static partition (B), a dynamic partition (Super), and a user data partition (Userdata).

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

The content of the system files oem-vc, oem-vc is saved in the Common partition oeminfo sub-partition as the system of the device, e.g., all cn.

At device boot time, it boots from a static partition. For example, a device starts from a static partition (a): sequentially loading a basic partition (Common), a static partition (A) and a dynamic partition (Super), executing an initialization link in the process of loading the static partition (A), and loading an equipment system (loading oem-vc) in the initialization link; the device starts from the static partition (B): loading a basic partition (Common), a static partition (B) and a dynamic partition (Super) in sequence, executing an initialization link in the process of loading the static partition (B), and loading equipment modes (loading oem-vc) in the initialization link.

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

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

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

S510, the equipment acquires an operating system upgrade package.

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

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

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

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

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

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

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

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

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

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

Start:12222 (data Block Start Address, Start position of upgrade data (differential data Delta1) indicating the child partition boot of static partition is 12222)

size 2410 (data size, size of upgrade data (differential data DELTA1) for the child partition boot representing the static partition is 2410)

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

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

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

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

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

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

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

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

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

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

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

Furthermore, in the virtual A/B upgrading scheme, an incremental upgrading mode is adopted for dynamic partitions (Super). In the upgrading process, all files of the dynamic partition (Super) of the new version after upgrading are not stored in the virtual dynamic partition of the user data partition (Userdata), but the upgrading result of the data which needs to be upgraded in the dynamic partition (Super) of the old version after upgrading is stored in the virtual dynamic partition of the user data partition (Userdata). That is, the virtual dynamic partition of the user data partition (Userdata) stores 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. The upgrade from version 1.1 to version 1.2, no change in data system2 occurred and data system1 was upgraded to system 3. Then, in S530, the device creates a virtual dynamic partition in the user data partition (Userdata), and writes the data system3 in the virtual dynamic partition.

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

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

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

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

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

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

system_b-cow-img.img.0000；

system_ext_b-cow-img.img.0000；

vendor_b-cow-img.img.0000；

product_b-cow-img.img.0000；

cust_b-cow-img.img.0000；

odm_b-cow-img.img.0000。

specifically, the COW file includes a COW file map (snapshot map) of the COW file itself and upgrade data. The COW file map (snapshot) corresponds to a file map of a child partition of 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) and saving addresses of the files of the operating system of the current version (version before the upgrade, for example, version 1.1).

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, 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). Or, when the os upgrade package is created, a file map of a sub-partition of a dynamic partition (Super) may be generated in advance, and the file map may be added to the COW file.

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

/system/app/A0.XXX；

/system/app/A1.XXX；

/system/app/A2.XXX；

/system/B0.XXX；

/system/B1.XXX；

/system/user/C0.XXX；

/system/user/C1.XXX；

/system/user/C2.XXX；

/system/user/C3.XXX。

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

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

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

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

/system/B0.XXX：024021～024026；

/system/B1.XXX：024027～024028；

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

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

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

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

the value after the file name (e.g.,/system/app/A0.XXX: 024010-024013 in 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 portions 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 parts of system2 for 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 system 3. The upgrade target is to update system1 with system 3.

The COW file map of the COW file itself (system _ b-COW-img.img.0000) may be:

/system/app/A2.XXX：

map1 (address of data to be updated in the original super partition): start address start: 024018 (offset from the system start address); offset size:2 (i.e., data of address segments 024018-024020)

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 in address segments 045033-045035);

/system/user/C2.XXX：

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

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 address segments 045036-045040);

the values (045033-045035 and 045036-045040) after the file name are the physical storage addresses (block addresses) of the latest version/system/app/A2.XXX and/system/user/C2.XXX in the user data partition (Userdata) in the COW file (system _ b-COW-img.img.0000).

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

After the COW file is successfully written into the user data partition (Userdata), the disk-dropping status information in the metadata partition (/ metadata) of the base partition (Common) is changed from "dropped" to "not dropped". The disk-drop status information is used to indicate whether there is a COW file that needs to be dropped to a dynamic partition (Super) currently. Specifically, the landing status information includes 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.

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

Specifically, fig. 5b is a schematic structural diagram of a system framework for system burning before the device leaves the factory in an application scenario. 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. 5B, the Slot0 (Slot one data) of the corresponding static partition (a) and the Slot1 (Slot two data) of the static partition (B) are contained in the metadata (/ hypermetadata) of the header of the dynamic partition (Super). Slot0 and Slot1 are used to maintain the partition table for the Super partition.

For example, in the MBR for UFS, the configuration Slot0 corresponds to boot from the static partition (A) and the configuration Slot1 corresponds to boot from the static partition (B) in the device boot order description. At the time of device startup, according to different static partitions of startup, the partition information of the Super partition is selected to be acquired from one of the Slot0 or the Slot 1. For example, when a device is started by static partition a, when loading a Super partition, the device first reads the Slot0 to obtain the sub-partition address of the Super partition; when a device is started by static partition B, when loading the Super partition, the device first reads the 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);

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

In the Name item and the Group item, if the suffix of the value is _ a, the 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, the Slot0 is first read. When the Slot0 is read, the device reads the value of the extensions item in the Name item and/or the Group item suffix with _ a in the Slot0 to obtain the sub-partition address of the Super partition, because the suffix with _ a corresponds to the static partition (a).

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

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

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

Metadata version:10.2

Metadata size:1300bytes

Metadata max size:65536bytes

Metadata slot count:3

Header flags:virtual_ab_device

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

Name:system_b

Group:ry_dynamic_partitions_b

Attributes:readonly,updated

Extents:0..6995967linear super 2048

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

Name:system

Group:ry_dynamic_partitions

Extents:0..699XXXX linear super 2048

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

Metadata version:10.2

Metadata size:1300bytes

Metadata max size:65536bytes

Metadata slot count:3

Header flags:virtual_ab_device

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

Name:system_b

Group:ry_dynamic_partitions_b

Attributes:readonly,updated

Extents:0..699XXXX linear super 2048

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

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

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

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

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

The Update folder of the end user data partition (Userdata) contains the following files:

system_b-cow-img.img.0000；

system_ext_b-cow-img.img.0000；

vendor_b-cow-img.img.0000；

product_b-cow-img.img.0000；

cust_b-cow-img.img.0000；

odm_b-cow-img.img.0000。

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

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

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

Specifically, taking upgrading from the version 1.1 to the version 1.3 as an example, calculating a hash value of a synthesis result of data (data which is not changed from the version 1.1 to the version 1.2) which does not need to be upgraded in the dynamic partition (Super) and upgrading data (data which is required to be upgraded from the version 1.1 to the version 1.2) 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 version 1.3, and if so, indicating that the COW file is valid; if not, indicating that the COW file is invalid and the upgrading fails, interrupting the upgrading process and reporting errors; wherein, the hash value of the complete data of the dynamic partition (Super) in the 1.3 version is stored in the operating system upgrade package.

Specifically, in the checking process, dynamic partition (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 system sub-partition 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：045033～045035；

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

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

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

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

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

(Direction to A1.XXX in dynamic partition (Super)/under 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 zoning (Super) in/under system B0.XXX)

/system/B1.XXX：024027～024028；

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

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

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

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

(Direction dynamic partitioning (Super) Medium/System/user 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 partitioning (Super) Medium/System/user under 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 (Userdata), 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 the dynamic partition (Super).

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

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

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

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

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

And S540, the device loads the basic partition (Common) and the static partition (B) in sequence. Specifically, before loading the static partition (B), the device first confirms whether the static partition (B) can be used for starting the operating system according to the state flag of the static partition (B). For example, when the state flag of the static partition (B) is bootable, it can be used to start the operating system; when the state of the static partition (B) is marked as unbootable, the state cannot be used for starting the operating system;

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

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

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

Specifically, in S541, 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 S530. The device determines files needing to be loaded according to the starting requirements of the operating system, and loads the files based on the new version file map of the dynamic partition (Super) sub-partition.

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

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

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

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

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

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

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

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

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

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

If the disk-dropping status information is 'not-dropped disk (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 upgraded new version data.

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

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

In S520, 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); also, in S530, the data operation of the dynamic partition upgrade is completed on the virtual dynamic partition created in the user data partition (Userdata), which does not affect the currently mounted dynamic partition (Super). Therefore, in the whole process of upgrading the operating system, the user can normally use the equipment; after S531 is completed, the device does not need to be restarted immediately, and a restart time may be selected by the user; 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.

For the modification of the VC by the operating system in the partition structure shown in fig. 4, a logically feasible application scheme is to store an operating system upgrade package in a user data partition (Userdata) based on the flow shown in fig. 3, where the operating system upgrade package includes a new VC and mirror image data of each partition in the data storage structure shown in fig. 4. The device enters a Recovery mode after being restarted, reads an operating system upgrade package stored in a user data partition (Userdata) in the Recovery mode, recovers mirror image data in the operating system upgrade package to each partition, and rewrites VC stored in a Common partition by VC in the operating system upgrade package.

However, in the android system adopting the virtual a/B upgrade mode, in order to ensure the security of the user data, the data stored in the user data partition (Userdata) is encrypted, and the data stored in the user data partition (Userdata) can be accessed only when the android system is normally started. That is, when the device is restarted to enter a Recovery (Recovery) mode, it cannot access the data stored in the user data partition (Userdata). Thus, the device cannot read the operating system upgrade package in a Recovery (Recovery) mode.

In order to solve the above problems, the present application provides an operating system upgrade method based on virtual a/B upgrade. In the upgrading process, a temporary system file tmp-VC is created, a new VC is stored in the tmp-VC firstly, the VC in the tmp-VC is read and loaded in the initialization process of system starting, and the original VC is rewritten by using the VC in the tmp-VC after the system is started.

FIG. 6a is a diagram illustrating a data storage structure according to an embodiment of the present application. Specifically, as shown in fig. 6a, a Common partition oeminfo sub-partition stores a format file oem-vc (first format file), and the format content of oem-vc is a first format, for example, all cn. The device loads oem-vc when the operating system is normally started. When the operating system format needs to be rewritten, a temporary format file tmp-vc is created in the Common partition oeminfo sub-partition, and the content of the tmp-vc is a new format (second format), for example, cmcc cn. And reading and loading the VC in the tmp-VC in the initialization process of system startup, and rewriting oem-VC by using the VC in the tmp-VC after the system startup.

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

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

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

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

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

FIG. 6b is a flowchart illustrating an operating system upgrade according to an embodiment of the present application. The current VC of the device is in a first format, e.g., all cn. Specifically, an oemnvc file is stored in a child partition (e.g., oeminfo child partition) of the Common partition of the device, and the content of the oemnvc is in a first format (all cn). In the process that the device normally starts an operating system, the device executes an initialization (init) link in the process of loading a static partition, and reads and loads VC content in an oemvc in the initialization link; for example, read all cn from oenvc, write all cn to global variable cmdlene). When the VC of the device needs to be rewritten to the second system, for example, cmcc cn; the device needs to rewrite the VC content in the oem VC to cmcc cn. The device performs the flow shown in figure 6b to implement overwriting the VC.

S600, the upgrading server pushes and releases an operating system upgrading packet for modifying the VC.

Specifically, VC data in the os upgrade package is stored in a root directory of the os upgrade package in the form of a target _ vendor _ count.

Specifically, the os upgrade package contains VC data (cmcc cn) of the second format. That is, a target _ vector _ count.mbn file exists under the root directory of the os upgrade package, and the content of the target _ vector _ count.mbn file is "cmcc/cn".

Further, in some application scenarios, when the operating system performs customized processing on different VCs, the operating system upgrade package further includes operating system upgrade data (including static partition upgrade data and dynamic partition upgrade data). And the operating system version corresponding to the operating system upgrading data is matched with the VC data in the operating system upgrading packet.

For example, for All cn (the first standard), the corresponding operating system is a general operating system: operating system version 1.0 (which does not embed any web facilitator's custom applications) (the first operating system); for cmcc cn (second standard), its corresponding operating system is a china mobile customized operating system (second operating system): operating system version 1.01 (which embeds custom applications for chinese mobility). Then, the os upgrade package contains os upgrade data corresponding to the upgrade from os version 1.0 to os version 1.01, and the specific content of the os upgrade data may refer to the content of the os upgrade package in the upgrade process shown in fig. 5 a.

The device loads a basic partition (Common), a static partition (A) and a dynamic partition (Super) in sequence and starts from the static partition (A). S600 may be executed after the device is started or before the device is started. In the state of starting from the static partition (a), the update apk (application profile) executes S610 to obtain the os upgrade package, and the obtaining process of the os upgrade package may refer to S510.

The update apk clock executes S611, and triggers the update engine to enter the upgrading process.

In the upgrade flow, update engine executes S620 to check the operating system upgrade package. Specifically, whether the digital signature of the operating system upgrade package is legal is checked, and whether the operating system upgrade package is a legal upgrade package is confirmed.

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

update engine executes S622 to confirm whether the current os upgrade package is an os upgrade package for modifying the VC.

If the current OS upgrade package is an OS upgrade package for modifying a VC, update engine executes S623 to create a tmp-VC (as shown in FIG. 6 a), and writes the latest version of the VC in the OS upgrade package to the tmp-VC.

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

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

The device boots an operating system (second operating system) from the static partition (B) after the first reboot. Refer to S540 and S541.

During the process of loading the static partition (B) by the device, the device executes an initialization (init) link. In the initialization step, the device performs S640 to determine the VC that needs to be loaded currently. Specifically, the loading tmp-vc or the loading oenvc is confirmed.

After the first restart, the device starts the operating system from the static partition (B), and the started operating system (second operating system) corresponds to the latest version of VC (second standard). Therefore, in order to ensure smooth startup of the operating system, when the device starts the second operating system from the static partition (B), the latest version of VC (second standard) needs to be loaded in the initialization (init) phase of starting the second operating system.

After the first reboot, tmp-VC is the VC (second system) of the latest version in the operating system upgrade package, and oemvc is the VC (first system) of the old version. Therefore, in S640, it is determined that tmp-vc (second system) is currently required to be loaded.

The device executes S641 and loads tmp-vc.

The device then executes S642 to start supervisory initialization (cust _ init).

In the process of starting the operating system by the device, when the vc (oenvc) of the operating system of the device does not match the custom. Therefore, in a supervision initialization (cust _ init) link, it is necessary to verify whether the oenvc of the operating system itself matches the custom.bin stored in the user data, and if not, it is necessary to restore factory settings and reconfigure operating system parameters.

Specifically, in S642, it is checked whether factory reset is required.

Since the current oenvc is an old version of VC (first format), the oenvc is not updated, and the current configuration of the device (stored in custom. Therefore, the device does not need to be factory reset. Therefore, the device may execute S643, continue the subsequent initialization and data loading operations, complete the loading of the static partition (B) and the dynamic partition (Super), and start the operating system from the static partition (B).

After the device is started from the static partition (B), the device executes S650 to transmit a startup broadcast.

Since the disk-drop state information is "not-dropped (wait for merge)" at this time, the update apk client executes S651, and the update apk client triggers the update entry to merge flow.

S652, update engine executes merge process, refer to S551.

After S652 is completed, update engine executes S653 to write tmp-VC VC into oenvc, and completes the rewriting of oenvc.

After completing the overwriting of the oem vc, update engine executes S654 to clear tmp-vc.

After S654, update engine performs S655, which triggers a device restart (second restart) (fourth restart).

And after the equipment is restarted for the second time, sequentially loading a basic partition (Common), a static partition (B) and a dynamic partition (Super), and starting from the static partition (B).

And after the equipment is restarted for the second time, loading an initialization (init) link of the static partition (B) on the equipment. The device again performs S640 to confirm the VC that currently needs to be loaded.

After the second restart, the device starts the operating system from the static partition (B), and the started operating system (second operating system) corresponds to the latest version of VC (second standard). Therefore, in order to ensure smooth startup of the operating system, when the device starts the second operating system from the static partition (B), the latest version of VC (second standard) needs to be loaded in the initialization (init) phase of starting the second operating system. Since after the second reboot, oemvc is the latest version of VC (second standard) in the os upgrade package. Therefore, in S640 executed again, it is determined that the oem vc (second system) needs to be loaded currently.

The device executes S644, loading the oem vc.

Then, the device executes S642 again, starts supervisory initialization (cust _ init), and determines whether factory reset is required.

As the current oenvc is a new version of VC, it is updated and it does not match the current configuration of the device (stored in custom. Therefore, the device needs to be factory reset.

Thus, the device performs S660, triggering a device restart (third restart) (second restart).

And after the equipment is restarted for the third time, entering a Recovery mode, and in the Recovery mode, executing S661 by the equipment to recover factory settings.

After the device is restored to the factory setting, S662 is executed to trigger a device restart (fourth restart) (third restart).

And after the fourth restart, the device loads a basic partition (Common), a static partition (B) and a dynamic partition (Super) in sequence and starts from the static partition (B).

And after the equipment is restarted for the fourth time, loading an initialization (init) link of the static partition (B) on the equipment. The device again performs S640 to confirm the VC that currently needs to be loaded.

After the fourth restart, the device starts the operating system from the static partition (B), and the started operating system (second operating system) corresponds to the latest version of VC (second standard). Therefore, in order to ensure smooth startup of the operating system, when the device starts the second operating system from the static partition (B), the latest version of VC (second standard) needs to be loaded in the initialization (init) phase of starting the second operating system. Since after the fourth reboot, oemvc is the latest version of VC (second standard) in the os upgrade package. Therefore, in S640 executed again, it is determined that the oem vc (second system) needs to be loaded currently.

The device again executes S644, loading the oemvc. Then, the device executes S642 again, starts supervisory initialization (cust _ init), and determines whether factory reset is required.

In the process of determining whether factory settings need to be restored, the device judges whether the oenvc of the operating system is matched with the custom. In this link, since the device is restored to the factory setting in S661, the custom bin stored in Userdata is deleted in the process of restoring the factory setting. Bin is not currently present in Userdata. Bin cannot be read by the device. Bin, the device does not need to be factory reset when the device cannot read the bin.

When the device cannot read the store.bin, the device executes S645, creating the store.bin, writing the oem vc to the store.bin.

Then the device executes S643, continues to perform subsequent initialization and data loading operations, completes the loading of the static partition (B) and the dynamic partition (Super), and starts from the static partition (B).

After the device is started from the static partition (B), the device executes S650 to transmit a startup broadcast. The update apk clock confirms that merge is completed and the operating system completes the upgrade.

According to the method of the embodiment shown in FIG. 6B, a remanufacturing may be implemented for an operating system that employs a virtual A/B upgrade scheme; according to the method shown in fig. 6b, no additional remanufacturing tool needs to be configured, and the device can complete remanufacturing operation by downloading the operating system upgrade package, so that the remanufacturing process is greatly simplified, and the remanufacturing difficulty is reduced.

Further, according to the method shown in fig. 6b, the static partition and the dynamic partition data can be updated while the operating system is modified, so that the operating system is upgraded to the corresponding version of the customized operating system while the operating system is modified, multiple times of operating system upgrading operations are avoided, the upgrading process of the operating system is greatly simplified, and the user experience is improved.

Further, in some application scenarios, when the operating system does not perform customized processing on different VCs, the operating system upgrade package does not include operating system upgrade data (does not include static partition upgrade data and dynamic partition upgrade data).

When the os upgrade package does not contain os upgrade data, in S621, before the first reboot, the operations of S520 and S530 are not performed, but the static partition (a) is synchronized to the static partition (B), the device boot order is modified to be booted from the static partition (B), and the disk-down state information is modified to be "not-dropped (wait for merge").

After the first restart, in S652, the tray landing state information is directly modified to "already-tray (merged)", without performing the tray landing operation.

Specifically, fig. 7 is a partial flowchart illustrating upgrading of an operating system according to an embodiment of the present application. The device executes the flow shown in fig. 7 to implement the operations before the first restart in the flow shown in fig. 6 b.

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

S710, an upgrade package obtaining tool (update apk package) obtains an operating system upgrade package, and the obtaining process of the operating system upgrade package may refer to S510. The specific file structure of the operating system upgrade package may refer to the description in S600.

S711, the upgrade package acquisition tool (update apk tool) starts an upgrade engine (update engine) to enter an upgrade process.

S712, the upgrade engine (update engine) checks whether the signature of the operating system upgrade package is legal.

After the os upgrade package passes the signature verification, the upgrade engine (update engine) executes S720, and upgrades the static partition (B) and the dynamic partition (Super) according to the os upgrade data in the os upgrade package, specifically referring to S520, S530, and S531.

After S720 (after the upgrade engine (update engine) performs S520, S530, and S531), the upgrade engine (update engine) further performs the following steps:

s721, confirm whether the current OS upgrade package is the OS upgrade package for modifying VC. Specifically, it is detected whether a target _ vector _ count.

If the root directory of the operating system upgrade package does not have the target _ vendor _ count.mbn file, the operating system upgrade does not need to rewrite the VC, S722 is executed, the device is restarted, the static partition (B) is started, and the disk-dropping operation is executed, referring to S532-SS 551.

If the root directory of the operating system upgrade package has the target _ vendor _ count.mbn file, it indicates that the operating system upgrade needs to rewrite the VC, S723 is executed, and VC (cmcc cn) in the target _ vendor _ count.mbn file is written into tmp-VC. the tmp-VC may be saved in the metadata (/ metadata) of the Common partition, or may be saved in a sub-partition of the Common partition for saving the VC (e.g., creating the tmp-VC in the oeminfo sub-partition as shown in fig. 6 a).

S724, the system rewrite flag (oem) is set to 1.

The system rewriting flag bit (oem) is used for identifying the state of oem-vc (first system file), so that the equipment can confirm whether tmp-vc needs to be loaded or not according to the state of oemvc (first system file).

Specifically, the system rewrite flag (oem) is set to 1, and the status of oem-vc is not rewritten. When the oem-VC state is not rewritten, it is indicated that the data of the current tmp-VC is not written into oem-VC, oem-VC is an old version of VC (first system), a new version of VC (second system) needs to be loaded at present, and tmp-VC needs to be loaded.

The mode rewriting flag bit (oem) is set to 0, and the status of oem-vc is rewritten. When the oem-VC state is rewritten, it indicates that the data of the current tmp-VC has been written into oem-VC, oem-VC is a new version of VC (second system), the new version of VC (second system) needs to be loaded, and oem-VC needs to be loaded.

In the process of starting an operating system, reading a system rewriting flag bit (oem) in an initialization (init) link, and if oem is 1, loading tmp-vc in the current initialization link; if oem is equal to 0, then the current initialization link loads VC (load oemvc) normally.

Further, the system rewrite flag bit (oem) may be stored in the metadata (/ metadata) of the Common partition, or may be stored in a sub-partition (e.g., oeminfo sub-partition) for storing oem-vc in the Common partition.

Further, in an actual application scenario, the execution sequence between S723 and S724 is not necessarily limited. In another embodiment, S724 may be performed first, and then S723 may be performed.

After S724, the upgrade engine (update engine) executes S725, reporting the current status (oem completed and tmp-vc written) to the upgrade package get tool (update apk client).

After receiving the status report of the upgrade engine (update engine), the upgrade package acquisition tool (update apk) executes S730, and pops up a dialog box to prompt the user that the current operating system needs to restart the device for upgrading.

Specifically, the execution of S711 to S724 may be executed in the background during the normal use of the mobile phone by the user.

Specifically, fig. 8 is a schematic view of a mobile phone operation interface according to an embodiment of the present application. When the mobile phone successfully starts the operating system, the system interface shown as 801 in fig. 8 is entered. When the mobile phone upgrades the operating system, the user can call the interface shown in 802 in fig. 8, so that the upgrading progress of the operating system is shown to the user. The user may close the operation interface shown in 802 of fig. 8, use the mobile phone normally, and after the user closes the interface shown in 802, the execution of S711 to S724 is changed to background execution. Such as the interface shown in

cell phone display

801 or 803.

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

For example, fig. 9 is a schematic view of an operation interface of a mobile phone according to an embodiment of the present application. The mobile phone currently displays an interface as shown by 802 in fig. 8, and displays the operating system upgrade progress to the user. In S730, the handset displays an interface shown as 903 in fig. 9, and the user confirms that the restart is immediate or later.

As another example, the handset currently presents an interface as shown at 803 in fig. 8, and the user uses a chat application. In S730, the mobile phone displays the interface shown as 901 in fig. 9, and pops up a prompt notification. The user clicks on the reminder notification and enters an interface such as 903 in fig. 9, and the user confirms that the restart is immediate or later. Alternatively, the user opens the drop-down notification bar and the handset presents an interface such as that shown at 902 in FIG. 9. In the drop-down notification bar, the user clicks on the reminder notification, enters the interface shown as 903 in FIG. 9, and confirms with the user that the restart is immediate or a restart later.

Further, in S730, if the user clicks the restart button, S731 is performed and the device is immediately restarted.

In S730, if the user clicks the later button, S732 is executed, the device suspends the upgrade process, and restarts the upgrade process at a preset timing upgrade node, and the device restarts after the upgrade process is started.

FIG. 10 is a partial flow diagram illustrating an operating system upgrade according to an embodiment of the present application. The device performs the steps shown in fig. 10 to implement the initialization stage in the flow shown in fig. 6 b.

Specifically, since the upgrade engine (update engine) upgrades the static partition (B) and the dynamic partition (Super) according to the operating system upgrade data in the operating system upgrade package in S720 (S531 is executed), the operating system is started from the static partition (B) after the device is restarted after S731 or S732. The start-up process of the operating system may refer to S540 and S541. During the process of loading the static partition (B), the device executes an initialization (init) link, and in the initialization (init) link, the device executes the following steps shown in fig. 10:

s1000, determining the current status of the disk-down, for example, reading the disk-down status information in the metadata partition (/ metadata) of the base partition (Common). Since the upgrade engine (update engine) upgrades the static partition (B) and the dynamic partition (Super) according to the os upgrade data in the os upgrade package in S720 (the upgrade engine (update engine) performs S530), the disk-down state information is "not-dropped (disk for merge)" in S1000.

When the disk-drop state information is "not-dropped (wait for merge)", executing S1010, and reading a system rewriting flag bit (oem); since the system rewriting flag bit (oem) is set to 1 in S724, the system rewriting flag bit oem is set to 1 in S1010.

When oem is equal to 1, S1020 is executed, tmp-vc is read and loaded. Specifically, tmp-vc (cmcc cn) is written into the global variable cmdline.

S1030, starts supervision initialization (cure _ init).

S1040, judging oem-vc whether it is consistent with the customization information (Data/custom. bin) in the user Data partition (Userdata). Since oem-VC and Data/custom bin stored in the oeminfo sub-partition of the Common partition are not overwritten in the flow shown in fig. 7, in S1040, VC of oem-VC coincides with VC in the custom.

When oem-vc coincides with custom.

And after the equipment finishes loading the static partition (B), the equipment continues to load the dynamic partition and starts the operating system. Refer to S541 and S550.

FIG. 11a is a partial flow diagram illustrating an operating system upgrade according to an embodiment of the present application. The device executes the flow shown in fig. 11a to implement the operations before the second reboot in the flow shown in fig. 6 b. Specifically, after the first reboot, after the operating system is started (after S550 or S643), the system sends a boot broadcast to start an upgrade package acquisition tool (update apk package). Since the disk-drop status information is "not-disk-drop (wait for merge)", the upgrade package acquisition tool (update ack) triggers the execution of the disk-drop operation. The upgrade package acquisition tool (update apk client) starts the upgrade engine (update engine) which performs the following operations as shown in fig. 11 a:

s1100, the disc-dropping operation is performed, referring to S551 (after S551, the disc-dropping state information is "dropped disc (merged)"). S1120, the tmp-vc is written into oem-vc. Specifically, oem-vc was rewritten from All cn to cmcc cn.

S1130, the tmp-vc is erased (e.g., deleted or nulled out of the contents of tmp-vc).

S1140, the system rewrite flag (oem) is set to 0.

After S1140, the upgrade engine (update engine) triggers a device restart (S1150).

Furthermore, in order to smoothly start the equipment from the static partition (A) and the static partition (B) after the operating system is upgraded. Before S1150, the upgrade engine (update engine) also performs S1110, synchronizing data of the static partition (B) to the static partition (a).

Specifically, the present application does not specifically limit the specific implementation manner of S1110, and those skilled in the art may implement S1110 in various feasible implementation manners.

For example, FIG. 11b is a partial flow diagram illustrating an operating system upgrade according to an embodiment of the present application. The device performs the following flow as shown in fig. 11b to implement S1110.

And S1800, reading the description data related to the partition table on the device memory (the parameters are pre-stored in the device when the device leaves the factory), and synthesizing the total partition table of the memory.

For example, Universal Flash Storage (UFS) in Master Boot Record (MBR) format. And reading the size and position information of each partition on the UFS from an MBR (main guide sector, the first sector of the UFS, namely 0 cylinder 0 head 1 sector of a C/H/S address) of the UFS to obtain a partition table (Dpt).

S1810, reading all static sub-partitions with suffix _ B from the total partition table, and generating list 1 for describing each sub-partition of the static partition (B), where the list 1 includes the name and address of each sub-partition in the static partition (B). For example:

numbering	Sub-partition name	Sub-partition address (File Path)	Is selected to be in a selected state
				1	bootloader_b	/dev/block/by-name/bootloader_b	0
2	boot_b	/dev/block/by-name/boot_b	0
				3	vendor_boot_b	/dev/block/by-name/vendor_boot_b	0
4	dtbo_b	/dev/block/by-name/dtbo_b	0
				5	vbmeta_b	/dev/block/by-name/vbmeta_b	0

TABLE 1

S1820, reading all static sub-partitions with suffix names _ a from the total partition table, and generating a list 2 for describing each sub-partition of the static partition (A), wherein the list 2 comprises the name and the address of each sub-partition in the static partition (A). For example:

numbering	Sub-partition name	Sub-partition address (File Path)
			1	bootloader_a	/dev/block/by-name/bootloader_a
2	boot_a	/dev/block/by-name/boot_a
			3	vendor_boot_a	/dev/block/by-name/vendor_boot_a
4	dtbo_a	/dev/block/by-name/dtbo_a
			5	vbmeta_a	/dev/block/by-name/vbmeta_a

TABLE 2

It should be noted that, in table 1 and table 2, the address of the sub-partition is referred to in a file path manner, and in an actual application scenario, a person skilled in the art may use a variety of different manners to describe the address of the sub-partition. For example, a linear address description is used.

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

Specifically, none of the child partitions in list 1 were selected prior to S1830. In S1830, the sub-partitions may be sequentially selected in the order of arrangement (numbering order) of the sub-partitions in list 1, or may be randomly selected from all the sub-partitions that have not been selected.

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

S1840, carrying out suffix removal matching on the selected sub-partition in the S1830 and each sub-partition in the list 2; determining the child partition (second child partition name) in list 2, which is consistent with the name of the child partition selected in S1830 after the suffix is removed, and the address (second file path) of the child partition corresponding to the second child partition name in list 2;

s1841, reading data in the first file path;

s1842, overwriting the read data to the second file path.

S1850, judging whether there is unselected sub-partition in the list 1;

if yes, return to step S1830, reselect the first child partition;

if not, the static partition synchronization ends.

Taking table 1 and table 2 as an example, in an application scenario, the device executes the following processes:

selecting a first sub-partition (bootloader _ b sub-partition with the number 1) with the selected state of 0 in the table 1, and modifying the selected state of the number 1 into 1;

using bootloader _ b to do suffix match in all sub-partition names in table 2, after removing _ a and _ b, bootloader _ a and bootloader _ b are consistent, so, according to bootloader _ b, matching bootloader _ a (second sub-partition);

reading a file path/dev/block/by-name/bootloader _ b (first file path) corresponding to bootloader _ b from the table 1;

reading a file path/dev/block/by-name/bootloader _ a (second file path) corresponding to bootloader _ a from the table 2;

reading data under the/dev/block/by-name/bootloader _ b, and overwriting the read data to the/dev/block/by-name/bootloader _ a;

the sub-partition with the selected state of 0 still exists in table 1, the first sub-partition with the selected state of 0 in table 1 (boot _ b sub-partition with the number of 2) is selected, and the selected state of the number 2 is modified into 1;

suffix removal matching is carried out on all the sub-partition names in the table 2 by using the boot _ b, and the boot _ a and the boot _ b are consistent after the removal of the _ a and the _ b respectively, so that the boot _ a is matched according to the boot _ b;

reading a file path/dev/block/by-name/boot _ b corresponding to boot _ b from the table 1;

reading a file path/dev/block/by-name/boot _ a corresponding to boot _ a from the table 2;

reading data under the/dev/block/by-name/boot _ b, and overwriting the read data to the/dev/block/by-name/boot _ a;

the sub-partition with the selected state of 0 still exists in table 1, the first sub-partition with the selected state of 0 (the vector _ boot _ b sub-partition with the number of 3) in table 1 is selected, and the selected state of the number of 3 is modified into 1;

using the vector _ boot _ b to perform suffix removal matching on all the sub-partition names in the table 2, wherein the vector _ boot _ a and the vector _ boot _ b are consistent after removing the _ a and the _ b respectively, so that the vector _ boot _ a is matched according to the vector _ boot _ b;

reading a file path/dev/block/by-name/vendor _ boot _ b corresponding to the vendor _ boot _ b from the table 1;

reading a file path/dev/block/by-name/vendor _ boot _ a corresponding to the vendor _ boot _ a from the table 2;

reading data under the/dev/block/by-name/video _ boot _ b, and overwriting the read data to the/dev/block/by-name/video _ boot _ a;

the sub-partition with the selected state of 0 still exists in table 1, the first sub-partition with the selected state of 0 in table 1 (dtbo _ b sub-partition with the number 4) is selected, and the selected state of the number 4 is modified to be 1;

suffix removal matching is performed on all sub-partition names in table 2 by using dtbo _ b, and dtbo _ a and dtbo _ b are consistent after removing _ a and _ b respectively, so that dtbo _ a is matched according to dtbo _ b;

reading a file path/dev/block/by-name/dtbo _ b corresponding to dtbo _ b from the table 1;

reading a file path/dev/block/by-name/dtbo _ a corresponding to the vector _ boot _ a from the table 2;

reading data under the/dev/block/by-name/dtbo _ b, and overwriting the read data to the/dev/block/by-name/dtbo _ a;

the sub-partition with the selected state of 0 still exists in table 1, the first sub-partition with the selected state of 0 in table 1 (vbmeta _ b sub-partition with the number 5) is selected, and the selected state of the number 5 is modified to be 1;

suffix matching is performed on all the sub-partition names in the table 2 by using vbmeta _ b, and vbmeta _ a and vbmeta _ b are consistent after removing _ a and _ b respectively, so that vbmeta _ a is matched according to vbmeta _ b;

reading a file path/dev/block/by-name/vbmeta _ b corresponding to vbmeta _ b from the table 1;

reading a file path/dev/block/by-name/vbmeta _ a corresponding to the vector _ boot _ a from the table 2;

reading data under the/dev/block/by-name/vbmeta _ b, and overwriting the read data to the/dev/block/by-name/vbmeta _ a;

in table 1, there is no child partition with a selected state of 0, and the static partition synchronization is completed.

After S1150, since in S720 the upgrade engine (update engine) upgrades the static partition (B) and the dynamic partition (Super) according to the operating system upgrade data in the operating system upgrade package (S531), and in the flows shown in fig. 10 and fig. 11a, the boot order of the device is not modified, after S1150, the device boots the operating system from the static partition (B) after the reboot. The start-up process of the operating system may refer to S540 and S541. In the process of loading the static partition (B), the device executes an initialization (init) link, and in the initialization (init) link, the device executes the steps shown in fig. 10 again.

Specifically, since the tray landing operation is performed in S1100, the tray landing state information is "landed". Therefore, after S1150, in S1000 executed again, the tray landing state information is "already landed".

When the disk-down state information is "merged", S1011 is executed, and oem-vc is read and loaded. Specifically, oem-vc (cmcc cn) is written into the global variable cmdline.

Further, when the disc-dropping status information is "not-dropped (wait for merge)", S1010 is executed, and when oem is equal to 0, S1011 is also executed.

After S1011, S1030, S1040 are executed. Oem-vc stored in the oeminfo sub-partition of the Common partition has been overwritten with cmcc cn, but Data/custom.bin has not been overwritten, so in re-executed S1040, oem-vc does not coincide with custom.bin.

When oem-vc does not coincide with custom.

FIG. 12 is a partial flow diagram illustrating an operating system upgrade according to an embodiment of the present application. In S1051, the apparatus performs the following steps as shown in fig. 12:

s1200, restarting the equipment;

s1210, performing factory reset operation, including:

formatting data/metadata/cache;

deleting data/store.bin;

and S1220, after the factory setting is recovered, restarting the equipment.

After S1220, the device boots the operating system from the static partition (B) after reboot. The start-up process of the operating system may refer to S540 and S541. In the process of loading the static partition (B), the device executes an initialization (init) link, and in the initialization (init) link, the device executes the steps shown in fig. 10 again.

After S1011, S1030, S1040 are performed. Since Data/store.bin has been deleted in S1210, Data/store.bin does not exist in S1040 executed again.

When Data/store.bin does not exist, the device executes S1052, creates Data/store.bin, and writes oem-vc to store.bin.

After S1052, the device performs S1050, performing subsequent initialization operations and static partition (B) load operations. Since the device has completed the disk-down operation in S1100, the device normally loads the dynamic partition (Super) and the operating system normally starts up after the device completes loading the static partition (B).

Further, in the embodiment shown in fig. 6b, in the initialization step after the second restart, it is determined whether the factory settings need to be restored, and it is determined that the factory settings need to be restored. In another possible scheme, the factory reset judgment after the second restart may be skipped, the Recovery (Recovery) mode is directly entered after the second restart, and the factory reset of the device is restored in the Recovery mode.

FIG. 13 is a flowchart illustrating an operating system upgrade according to an embodiment of the present application. The current VC of the device is in a first format, e.g., all cn. Specifically, an oemnvc file is stored in a child partition (e.g., oeminfo child partition) of the Common partition of the device, and the content of the oemnvc is in a first format (all cn). In the process that the device normally starts an operating system, the device executes an initialization (init) link in the process of loading a static partition, and reads and loads VC content in an oemvc in the initialization link; for example, read all cn from oenvc, write all cn to global variable cmdlene). When the VC of the device needs to be rewritten to the second system, for example, cmcc cn; the device needs to rewrite the VC content in the oem VC to cmcc cn. The device performs the flow shown in fig. 13 to implement overwriting the VC.

And S1300, the upgrading server pushes and releases an operating system upgrading packet for modifying the VC, and the step S600 is referred.

The update apk clock executes S1310, obtains the operating system upgrade package, refer to S610.

The update apk clock executes S1311, and triggers the update engine to enter the upgrading process.

In the upgrade process, update engine executes S1320, and checks the os upgrade package, referring to S620.

After the os upgrade package passes the verification, the update engine executes S1321, and upgrades the data of the static partition and the dynamic partition and modifies the device start sequence according to the os upgrade package, specifically referring to S621.

update engine executes S1322 to determine whether the current os upgrade package is an os upgrade package for modifying the VC.

If the current operating system upgrade package is the operating system upgrade package used for modifying the VC, the update engine executes S1323, creates tmp-VC, and writes the VC of the latest version in the operating system upgrade package into the tmp-VC.

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

S1330, update apk clock triggers device restart (first restart), refer to S630.

During the process of loading the static partition (B) by the device, the device executes an initialization (init) link. In the initialization step, the device performs S1340 to determine the VC that needs to be loaded currently, referring to S640.

The device executes S1341, loading tmp-vc, refer to S641.

The device executes S1342, detecting custom. Bin exists in the Userdata, the device may execute S1343, continue to perform subsequent initialization and data loading operations, complete loading of the static partition (B) and the dynamic partition (Super), and start the operating system from the static partition (B).

After the device starts from the static partition (B), the device executes S1350 and transmits a startup broadcast.

Since the disk-drop status information is "not-dropped (wait for merge)" at this time, the update apk clock executes S1351, and the update apk clock triggers the update entry to the merge flow.

S1352, update engine executes merge process, refer to S551.

After S1352 is completed, update engine executes S1353, writes the VC of tmp-VC to the oenvc, and completes the rewriting of the oenvc.

After completing the overwriting of the oem vc, update engine executes S1354, clearing tmp-vc.

After S1354, update engine performs S1355, which triggers device restart (second restart).

After the device is restarted for the second time, the device enters a Recovery mode, and in the Recovery mode, the device executes S1361 to recover factory settings, referring to S661.

After the device is restored to the factory setting, S1362 is executed to trigger the device to restart (restart for the third time) (the third restart).

And after the equipment is restarted for the fourth time, loading an initialization (init) link of the static partition (B) on the equipment. The device again performs S1340 to confirm the VC that currently needs to be loaded.

The device again executes S1344, loading oenvc.

Bin in Userdata is detected by the device, S1342 is executed again, and supervision initialization (cust _ init) is started to determine whether factory reset needs to be performed.

Since the device is restored to the factory setting in S1361, the custom bin stored in the Userdata is deleted in the process of restoring the factory setting. Bin is not currently present in Userdata. Therefore, the device does not need to be factory reset.

The device executes S1342, detecting custom. When there is no custom.bin in the Userdata, the device performs S1345, creates a custom.bin, writes oem vc to the custom.bin.

Then the device executes S1343, continues to perform subsequent initialization and data loading operations, completes the loading of the static partition (B) and the dynamic partition (Super), and starts from the static partition (B).

After the device starts from the static partition (B), the device executes S1350 and transmits a startup broadcast. The update apk clock confirms that merge is completed and the operating system completes the upgrade.

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

Further, in general, improvements to a technology can be clearly distinguished as hardware improvements (e.g., improvements to circuit structures such as diodes, transistors, switches, etc.) or 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 a dedicated integrated circuit chip. Furthermore, nowadays, instead of manually making 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, pl (core universal Programming Language), HDCal (jhdware Description Language), lang, Lola, HDL, laspam, hardward Description Language (vhr Description Language), vhal (Hardware Description Language), and vhigh-Language, which are currently used in most common. It will also be apparent to those skilled in the art that hardware circuitry that implements the logical method flows can be readily obtained by merely slightly programming the method flows into an integrated circuit using the hardware description languages described above.

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

The controller may be implemented in any suitable manner, for example, the controller may take the form of, for example, a microprocessor or processor and a computer-readable medium storing computer-readable program code (e.g., software or firmware) executable by the (micro) processor, logic gates, switches, an Application Specific Integrated Circuit (ASIC), a programmable logic controller, and an embedded microcontroller, examples of which include, but are not limited to, the following microcontrollers: ARC 625D, Atmel AT91SAM, Microchip PIC18F26K20, and Silicone Labs 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 considered a hardware component, and the means included therein for performing the various functions may also be considered as a structure within the hardware component. Or even means for performing the functions may be regarded as being both a software module for performing the method and a structure within a hardware component.

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

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

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

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

Claims

1. A method for configuring the standard of an operating system is characterized in that the method is applied to electronic equipment, the electronic equipment comprises a processor and a memory, the memory comprises a basic partition, a first static partition, a second static partition, a dynamic partition and a user data partition, a first standard file is stored in the basic partition, and the current standard content of the first standard file is a first standard; after the electronic equipment is started, loading data of the base partition, the first static partition and the dynamic partition so as to start an operating system from the first static partition; the process of starting the operating system by the electronic equipment comprises an initialization link; after the operating system is started, the method comprises the following steps:

acquiring an operating system upgrade package, wherein the operating system upgrade package comprises a second standard file, and the standard content of the second standard file is a second standard;

modifying a boot order of the electronic device to boot from the second static partition;

extracting the second standard file;

creating a temporary standard file, and writing the standard content of the second standard file into the temporary standard file;

triggering a first reboot of the electronic device, the electronic device booting an operating system from the second static partition after the first reboot;

writing the system content of the temporary system file into the first system file;

triggering a second reboot of the electronic device, the electronic device entering a recovery mode after the second reboot;

triggering a third reboot of the electronic device, after which the electronic device boots an operating system from the second static partition, an initialization procedure after the third reboot including at least: and creating the system configuration file in the user data partition, and writing the system content of the first system file into the system configuration file.

2. The method according to claim 1, wherein the initialization link further comprises a format loading step, wherein the first format file is loaded in the initialization link before the second reboot and the initialization link after the third reboot.

3. The method of claim 1, wherein the initialization stage after the third restart further comprises:

and determining whether the system configuration file exists in the user data partition, creating the system configuration file in the user data partition when the system configuration file does not exist in the user data partition, and writing the system content of the first system file into the system configuration file.

4. The method as claimed in claim 1, wherein after writing the system content of the temporary system file into the first system file, further comprising:

and deleting the temporary standard file.

5. The method according to claim 1, wherein the initialization link further comprises a system loading step, wherein the temporary system file is loaded in the initialization link after the first reboot.

6. The method of claim 1, wherein the initialization stage after the first reboot further comprises:

judging whether factory settings need to be restored or not;

7. The method of claim 6, wherein the determining whether factory settings need to be restored comprises:

determining whether the system configuration file stored in the user data partition is matched with the first system file;

8. The method according to claim 1, wherein a first operating system and a second operating system are operating systems corresponding to different standards, the first operating system corresponding to the first standard, the second operating system corresponding to the second standard; the operating system upgrade package further comprises static partition upgrade data, and the static partition upgrade data is used for updating the static partition data of the first operating system into the static partition data of the second operating system; before the operating system upgrade package is obtained, the electronic equipment loads the data of the basic partition, the first static partition and the dynamic partition after being started so as to start the first operating system from the first static partition;

before the modifying the boot sequence of the electronic device is the boot from the second static partition, the method further includes: updating data of the second static partition based on the static partition upgrade data;

the process of the electronic device booting an operating system from the second static partition after the first reboot includes:

loading data of the base partition, the second static partition, and the dynamic partition to boot the second operating system.

9. The method of claim 8, wherein after the electronic device boots an operating system from the second static partition after the first reboot, synchronizing data of the second static partition to the first static partition.

10. The method according to claim 3, wherein the first operating system and the second operating system are operating systems corresponding to different standards, the first operating system corresponding to the first standard, the second operating system corresponding to the second standard; the operating system upgrade package further comprises dynamic partition upgrade data, and the dynamic partition upgrade data is used for updating the dynamic partition data of the first operating system into the dynamic partition data of the second operating system; before the operating system upgrade package is obtained, the electronic equipment loads the data of the basic partition, the first static partition and the dynamic partition after being started so as to start the first operating system from the first static partition;

before the modifying the boot sequence of the electronic device is the boot from the second static partition, the method further includes:

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

loading data of the base partition, the second static partition, the dynamic partition, and the virtual dynamic partition to boot the second operating system;

after the electronic device starts an operating system from the second static partition after the first reboot, the data of the virtual dynamic partition is landed to the dynamic partition.

11. The method as recited in claim 1, wherein after said writing the system content of the temporary system file to the first system file, the method further comprises:

triggering a fourth reboot of the electronic device, the electronic device booting an operating system from the second static partition after the fourth reboot;

the initialization step after the fourth reboot further includes:

judging whether factory settings need to be restored or not;

and when the factory setting needs to be restored, interrupting the starting operation of the operating system and triggering the second restart.

12. The method of claim 11, wherein the determining whether factory settings need to be restored comprises:

if the electronic equipment is matched with the preset electronic equipment, confirming that factory settings of the electronic equipment do not need to be restored;

13. The method according to claim 11, wherein the initialization link further comprises a system loading step, wherein the first system file is loaded in the initialization link after the fourth reboot.

14. The method according to claim 1, wherein before the extracting the second-format file, the method further comprises:

and determining whether the operating system upgrade package is used for rewriting the system, and extracting the second system file when the operating system upgrade package is used for rewriting the system.

15. The method of claim 14, wherein confirming whether the operating system upgrade package is used to override the schema comprises confirming whether the second schema file exists in the operating system upgrade package.

16. The method of claim 1, wherein the initialization stage further comprises a system loading step, wherein:

when the state of the first standard file is not rewritten, loading the temporary standard file;

17. The method of claim 1, wherein the initialization stage further comprises a system loading step, wherein:

when the disk falling state is not the disk falling state and the state of the first system file is not rewritten, loading the temporary system file;

18. The method of claim 16, wherein:

after the system content of the temporary system file is written into the first system file, marking the state of the first system file as rewritten.

19. The method according to claim 1, wherein the operating system includes an upgrade package acquisition tool and an upgrade engine, the first operating system and the second operating system are operating systems corresponding to different standards, the first operating system corresponds to the first standard, and the second operating system corresponds to the second standard; before the operating system upgrade package is obtained, the electronic equipment loads the data of the basic partition, the first static partition and the dynamic partition after being started so as to start the first operating system from the first static partition, and the first standard file is loaded in an initialization link of starting the first operating system; after the first operating system is started, the method comprises the following steps:

the upgrade package obtaining tool obtains the operating system upgrade package, wherein the operating system upgrade package comprises the second standard file, static partition upgrade data and dynamic partition upgrade data;

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

the upgrade engine updates data of the second static partition based on the static partition upgrade data;

the upgrading engine creates a virtual dynamic partition in the user data partition, writes the dynamic partition upgrading data into the virtual dynamic partition, and marks that the disk-dropping state is the disk-not-dropping state;

the upgrade engine modifies a boot sequence of the electronic device to boot from the second static partition;

when the operating system upgrade package is used for rewriting systems, the upgrade engine creates a temporary system file, writes the system content of the second system file into the temporary system file, and marks the state of the first system file as not being rewritten;

the upgrading engine returns state information of finishing upgrading operation to the upgrading package acquisition tool;

the upgrade package acquisition tool triggers a first reboot of the electronic device, after which the electronic device loads data of the base partition, the second static partition, the dynamic partition, and the virtual dynamic partition to boot the second operating system;

in an initialization phase in which the second operating system is started after the first reboot: when the tray falling state is the tray falling state and the state of the first system file is not rewritten, loading the temporary system file; when the standard configuration file stored in the user data partition is matched with the first standard file, confirming that factory settings of the electronic equipment do not need to be restored, and continuing to perform operating system starting operation;

after the second operating system is started after the first restart, the upgrade package acquisition tool triggers the upgrade engine to enter a disk-dropping process;

in the disk-dropping process, the upgrading engine drops the data of the virtual dynamic partition to the dynamic partition and marks the disk-dropping state as the dropped disk; synchronizing data of the second static partition to the first static partition; writing the format content of the temporary format file into the first format file, and then deleting the temporary format file and marking the state of the first format file as being rewritten;

the upgrade engine triggers a fourth reboot of the electronic device, after which the electronic device loads data of the base partition, the second static partition, and the dynamic partition to boot the second operating system;

in an initialization phase in which the second operating system is started after the fourth reboot: when the tray falling state is the tray falling state or the state of the first standard file is rewritten, loading the first standard file; when the system configuration file stored in the user data partition is not matched with the first system file, confirming that factory settings of the electronic equipment need to be restored, interrupting an operating system starting operation, and triggering the second restart;

after the second restart, the electronic equipment enters the recovery mode, recovers factory settings of the electronic equipment, and triggers the third restart;

the electronic device boots the second operating system from the second static partition after the third reboot, and in an initialization phase in which the second operating system is booted after the third reboot: when the tray falling state is the tray falling state or the state of the first standard file is rewritten, loading the first standard file; when the system configuration file does not exist in the user data partition, the system configuration file is created in the user data partition, and the system content of the first system file is written into the system configuration file.

20. An electronic device is characterized in that the electronic device comprises a processor and a memory, the memory comprises a basic partition, a first static partition, a second static partition, a dynamic partition and a user data partition, a first system file is stored in the basic partition, the current system content of the first system file is a first system, and the processor is used for executing software codes stored in the memory, so that after the electronic device is started, data of the basic partition, the first static partition and the dynamic partition are loaded to start an operating system from the first static partition; the process of starting the operating system by the electronic equipment comprises an initialization link;

and after the first operating system is started, the electronic equipment is caused to execute the method flow of any one of claims 1-19.

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

22. A computer program product, characterized in that it comprises a computer program which, when run on a computer, causes the computer to carry out the method according to any one of claims 1 to 19.