CN116737214A

CN116737214A - Upgrade method of operating system, electronic equipment and storage medium

Info

Publication number: CN116737214A
Application number: CN202210915642.9A
Authority: CN
Inventors: 陈超; 张赠辉; 王艳召; 黄九林
Original assignee: Honor Device Co Ltd
Current assignee: Honor Device Co Ltd
Priority date: 2022-03-02
Filing date: 2022-03-02
Publication date: 2023-09-12
Also published as: CN114265616A; CN114265616B

Abstract

The application provides an operating system upgrading method, electronic equipment and a storage medium. The method modifies the installation process and the verification process in the upgrading process of the operating system from serial execution to parallel execution, thereby not only ensuring the rapid upgrading of the operating system to be completed, but also shortening the holding time of the dormant lock and solving the problem of high power consumption of the whole electronic equipment caused by the upgrading of the operating system.

Description

Upgrade method of operating system, electronic equipment and storage medium

The present application is a divisional application, the application number of which is 202210197439.2, the application date of which is 2022, 03, 02, and the entire contents of which are incorporated herein by reference.

Technical Field

The present application relates to the field of computer technologies, and in particular, to an operating system upgrade method, an electronic device, and a storage medium.

Background

As more applications become available for electronic devices, the storage space occupied by user data is increasingly required. At present, in order to ensure the success of the upgrade of the operating system and reduce the occupation of the system data to the storage space as much as possible so as to leave more storage space for storing the user data, electronic devices adopting a Virtual AB (AB) partition structure are becoming more and more popular.

Currently, for an electronic device adopting a virtual AB system partition structure, in order to ensure that an operating system is quickly upgraded, an upgrade engine (update_engine) can hold a sleep lock in an upgrade process, that is, the operating system of the electronic device cannot enter a sleep state in the upgrade process, and the whole upgrade process not only includes operations of upgrading a static partition and a dynamic partition according to an upgrade package, but also includes operations of checking the upgraded partition after the upgrade of the partition is completed. This requires the upgrade engine to hold the sleep lock for a long time, which can cause the operating system to fail to sleep, thereby causing the overall power consumption of the electronic device to increase.

Disclosure of Invention

In order to solve the technical problems, the application provides an operating system upgrading method, electronic equipment and a storage medium, and aims to shorten the holding time of a dormant lock in the operating system upgrading process so as to reduce the overall power consumption of the electronic equipment.

In a first aspect, the present application provides an upgrade method of an operating system, applied to an electronic device, where the electronic device includes a processor and a memory, the memory includes a base partition, a first static partition, a second static partition, a dynamic partition, and a user data partition, after the electronic device is started, data of the base partition, data of the first static partition, and data of the dynamic partition are sequentially loaded to run a first operating system, and after the first operating system runs, the method further includes: acquiring an upgrade package, wherein the upgrade package comprises a first upgrade file and a second upgrade file, the first upgrade file corresponds to a first static partition and a second static partition, and the second upgrade file corresponds to a dynamic partition; upgrading the second static partition according to the first upgrade file; after the second static partition is upgraded, starting a static partition checking thread, wherein the static partition checking thread is used for checking the second static partition; and upgrading the dynamic partition according to the second upgrading file in the process of verifying the second static partition by the static partition verification thread. Therefore, the installation process and the verification process in the upgrading process of the operating system are modified from serial execution to parallel execution, so that the operating system can be ensured to be rapidly upgraded, the holding time of the dormant lock is shortened, and the problem of high overall power consumption of the electronic equipment caused by the upgrading of the operating system is solved.

According to a first aspect, a static partition verification thread verifies a second static partition, comprising: the static partition checking thread checks the sub-partition in the second static partition; when the sub-partition is successfully checked, the static partition checking thread modifies the checking state corresponding to the second static partition into a first state, and the first state is used for indicating that the sub-partition is successfully checked; when the sub-partition verification fails, the static partition verification thread modifies the verification state corresponding to the second static partition into a second state, and the second state is used for indicating the sub-partition verification failure. Therefore, the static partition verification thread verifies each updated sub-partition in the static partition, and sets the verification states of the sub-partitions according to the verification results, so that after the update engine does not complete writing of a preset number of data into the cow file corresponding to the sub-partition of the dynamic partition, the verification states of the sub-partition of the static partition which is currently complete to verify can be timely obtained, whether the data are written into the cow file or the updating operation of the operating system is stopped is determined according to the obtained verification states, and the waste of the write operation of the cow file to the power consumption of the electronic equipment is avoided as far as possible when the static partition is abnormal.

According to the first aspect, or any implementation manner of the first aspect, after the static partition checking thread modifies the checking state corresponding to the second static partition into the first state, the method further includes: and after all the sub-partitions of the second static partition are checked, ending the check of the second static partition. Therefore, after all the sub-partitions in the static partition are checked, the static partition checking thread field stops checking the static partition, so that the occupation of electronic equipment resources is reduced, and the waste of power consumption of the electronic equipment is further reduced.

According to the first aspect, or any implementation manner of the first aspect, in a process that the static partition checking thread checks the second static partition, updating the dynamic partition according to the second update file includes: creating a copy-on-write file of a sub-partition corresponding to the second upgrade file in the user data partition according to the second upgrade file; and writing the second upgrade file into the cow file. Thus, by means of the user data partition, the writing of data in the upgrade file of the sub-partition corresponding to the dynamic partition is completed under the condition that the use of the electronic equipment is not affected.

According to the first aspect, or any implementation manner of the first aspect, writing the second upgrade file into the cow file includes: judging whether first data are written into the cow file or not in the process of writing the second upgrading file into the cow file, wherein the first data are part of data in the second upgrading file; when first data are written into the cow file, a check state corresponding to the second static partition is obtained; and stopping writing the second upgrade file into the cow file when the verification state is the second state. Therefore, when the second upgrade file of the sub-partition of the upgrade dynamic partition is written into the corresponding cow file, the current verification state of the static partition is obtained after the first data is written every time according to the preset requirement, and writing of the cow file is continued when the verification state indicates that the current verification of the static partition is successful, so that the waste of power consumption of the electronic equipment is avoided as much as possible.

According to the first aspect, or any implementation manner of the first aspect, the method further includes: when the verification state is the first state, judging whether the second upgrade file is completely written into the cow file; when the second upgrade file is completely written into the cow file, checking the dynamic partition; and when the second upgrading file is not completely written into the cow file, writing the data which is not written into the cow file in the second upgrading file into the cow file.

According to the first aspect, or any implementation manner of the first aspect, after verifying the dynamic partition, the method further includes: restarting the electronic equipment to sequentially load the data of the basic partition, the data of the second static partition, the data of the dynamic partition and the data of the cow file so as to run a second operating system; the data in the cow file is dropped into the corresponding sub-partition in the dynamic partition; the data of the second static partition is synchronized to the first static partition. Therefore, after the electronic equipment is restarted to run to the updated second operating system, the data in the cow file in the user data partition is dropped into the sub-partition corresponding to the dynamic partition, so that the updating of the operating system is completed.

According to the first aspect, or any implementation manner of the first aspect, the method further includes: and when the first data is not written into the cow file, continuing to write the second upgrading file into the cow file.

According to the first aspect, or any implementation manner of the first aspect, the method further includes: in the process of upgrading the second static partition according to the first upgrading file and the dynamic partition according to the second upgrading file, breakpoint information is recorded in a breakpoint record file, and a breakpoint marked by the breakpoint information is a position of continuous upgrading after restarting the electronic equipment; after the electronic equipment is powered down and restarted, determining a partition which is continuously updated according to breakpoint information recorded in a breakpoint recording file; when the partition which is continuously updated is determined to be the second static partition, reading data from the position of the breakpoint marked by the breakpoint information in the first updating file according to the breakpoint information, and updating the second static partition according to the read data; restarting the static partition checking thread after the second static partition is upgraded; and upgrading the dynamic partition according to the second upgrading file in the process of verifying the second static partition by the static partition verification thread. Therefore, when the electronic equipment is powered off, restarted and continuously upgraded, the technical scheme provided by the application can also shorten the upgrading time, thereby reducing the power consumption of the electronic equipment.

According to the first aspect, or any implementation manner of the first aspect, when determining that a partition updated successively is a dynamic partition, restarting the static partition checking thread; and in the process of checking the second static partition by the static partition checking thread, reading data from the position of the breakpoint marked by the breakpoint information in the second upgrading file according to the breakpoint information, and upgrading the dynamic partition according to the read data. Therefore, when the electronic equipment is powered off, restarted and continuously upgraded, the technical scheme provided by the application can also shorten the upgrading time, thereby reducing the power consumption of the electronic equipment.

In a second aspect, the present application provides an electronic device. The electronic equipment comprises a processor and a memory, wherein the memory comprises a basic partition, a first static partition, a second static partition, a dynamic partition and a user data partition, and after the electronic equipment is started, the data of the basic partition, the data of the first static partition and the data of the dynamic partition are sequentially loaded to run a first operating system; wherein the memory is coupled to the processor, the memory storing program instructions; the program instructions, when executed by a processor, cause an electronic device to perform the instructions of the first aspect, or the method in any implementation of the first aspect above.

In a third aspect, the application provides a computer readable storage medium storing a computer program for causing an electronic device to execute instructions of the first aspect, or of a method in any implementation manner of the first aspect, when the computer program is run on the electronic device.

In a fourth aspect, the application provides a computer program product comprising instructions which, when run on an electronic device, cause the electronic device to perform the method of the first aspect, or any implementation of the first aspect above.

In a fifth aspect, the present application provides a chip comprising processing circuitry, a receive pin, and a transmit pin. Wherein the receive pin, the transmit pin and the processing circuitry communicate with each other via an internal connection path, the processing circuitry executing instructions of the first aspect, or of the method in any of the implementations of the first aspect above, to control the receive pin to receive signals and the transmit pin to transmit signals.

Drawings

Fig. 1 is a schematic diagram of a hardware structure of an electronic device exemplarily shown;

FIG. 2 is a schematic diagram of type partitioning of an exemplary internal memory;

FIG. 3 is a schematic diagram of the partition structure of an exemplary non-AB system, and virtual AB system;

FIG. 4 is a schematic diagram illustrating interactions between a bag server, an OTA server, and an electronic device during an operating system upgrade process;

FIG. 5 is a schematic diagram illustrating an electronic device from acquiring an upgrade package to upgrading a static partition during an operating system upgrade process;

FIG. 6 is a schematic diagram illustrating an electronic device performing static partition verification and dynamic partition data writing in parallel during an operating system upgrade process;

FIG. 7 is a schematic diagram illustrating execution of a Merge operation and partition synchronization after a reboot of an electronic device during an operating system upgrade;

FIG. 8 is a timing diagram between a bag server, an OTA server, and an electronic device during an exemplary illustrated operating system upgrade;

FIG. 9 is a flow diagram illustrating an exemplary operating system upgrade process electronic device performing installation and verification in parallel;

FIG. 10 is a schematic flow diagram illustrating an electronic device from a boot up to an operating system upgrade to a restart to complete an operating system upgrade.

Detailed Description

The following description of the embodiments of the present application will be made clearly and fully with reference to the accompanying drawings, in which it is evident that the embodiments described are some, but not all embodiments of the application. All other embodiments, which can be made by those skilled in the art based on the embodiments of the application without making any inventive effort, are intended to be within the scope of the application.

The term "and/or" is herein merely an association relationship describing an associated object, meaning that there may be three relationships, e.g., a and/or B, may represent: a exists alone, A and B exist together, and B exists alone.

The terms first and second and the like in the description and in the claims of embodiments of the application, are used for distinguishing between different objects and not necessarily for describing a particular sequential order of objects. For example, the first target object and the second target object, etc., are used to distinguish between different target objects, and are not used to describe a particular order of target objects.

In embodiments of the application, words such as "exemplary" or "such as" are used to mean serving as an example, instance, or illustration. Any embodiment or design described herein as "exemplary" or "e.g." in an embodiment should not be taken as preferred or advantageous over other embodiments or designs. Rather, the use of words such as "exemplary" or "such as" is intended to present related concepts in a concrete fashion.

In the description of the embodiments of the present application, unless otherwise indicated, the meaning of "a plurality" means two or more. For example, the plurality of processing units refers to two or more processing units; the plurality of systems means two or more systems.

In order to better understand the technical solution provided by the embodiments of the present application, before describing the technical solution of the embodiments of the present application, a description is first given of a hardware structure of an electronic device (for example, a mobile phone, a tablet, a PC, etc.) applicable to the embodiments of the present application with reference to the accompanying drawings.

Referring to fig. 1, an electronic device 100 may include: processor 110, external memory interface 120, internal memory 121, universal serial bus (universal serial bus, USB) interface 130, charge management module 140, power management module 141, battery 142, antenna 1, antenna 2, mobile communication module 150, wireless communication module 160, audio module 170, sensor module 180, keys 190, motor 191, indicator 192, camera 193, display 194, and subscriber identity module (subscriber identification module, SIM) card interface 195, among others.

By way of example, the audio module 170 may include a speaker 170A, a receiver 170B, a microphone 170C, an earphone interface 170D, and the like.

By way of example, the sensor module 180 may include a pressure sensor, a gyroscope sensor, a barometric pressure sensor, a magnetic sensor, an acceleration sensor, a distance sensor, a proximity sensor, a fingerprint sensor, a temperature sensor, a touch sensor, an ambient light sensor, a bone conduction sensor, and the like.

Illustratively, the keys 190 include a power key (power on key), a volume key, and the like. The keys 190 may be mechanical keys. Or may be a touch key. The electronic device 100 may receive key inputs, generating key signal inputs related to user settings and function controls of the electronic device 100.

Further, the processor 110 may include one or more processing units, such as: the processor 110 may include an application processor (application processor, AP), a modem processor, a graphics processor (graphics processing unit, GPU), an image signal processor (image signal processor, ISP), a controller, a memory, a video codec, a digital signal processor (digital signal processor, DSP), a baseband processor, and/or a neural network processor (neural-network processing unit, NPU), etc.

It will be appreciated that in particular implementations, the different processing units may be separate devices or may be integrated in one or more processors.

Further, in some implementations, the controller may be a neural hub and command center of the electronic device 100. The controller can generate operation control signals according to the instruction operation codes and the time sequence signals to finish the control of instruction fetching and instruction execution.

In addition, memory in the processor 110 is primarily used for storing instructions and data. In some implementations, the memory in the processor 110 is a cache memory.

Further, it is understood that in an actual application scenario, executable program codes that trigger the electronic device 100 to implement various functional applications and data processing are stored in the internal memory 121, and these executable program codes include instructions.

For example, in particular, in the technical solution provided in the embodiment of the present application, the starting of the electronic device 100 and the upgrading of the operating system mainly depend on the related instructions stored in the internal memory 121 in advance, and the processor 110 can enable the electronic device 100 to execute the upgrading method of the operating system provided in the embodiment of the present application by executing the instructions stored in the internal memory 121.

For example, referring to fig. 2, in a specific implementation, the internal memory 121 may include a read-only memory 121A and a random access memory 121B, and the read-only memory 121A may be divided into three different partition structures of a non-AB system (shown in (1) of fig. 3), an AB system (shown in (2) of fig. 3), and a virtual AB system (shown in (3) of fig. 3).

It will be appreciated that, in particular for practical applications, the RAM (Random Access Memory, RAM), also known as "main memory", is ready to read and write, and is fast, and is typically used as a temporary data storage medium for an operating system or other running program, and when the power is turned off, the RAM cannot retain data, i.e. the RAM 121B typically stores temporary data when the electronic device is running; the Read-Only Memory (ROM), which may be referred to as "nonvolatile Memory", generally stores data written in advance before being loaded into the whole machine, such as an image file of an operating system, and user data generated when a user uses the electronic device, and the data can Only be Read out during the working process of the whole machine, but cannot be quickly and conveniently rewritten like a RAM, so that the data stored in the ROM is stable, and the data stored after power failure is not changed. In summary, compared with the RAM and the ROM, the RAM and the ROM have the greatest difference that the data stored on the RAM automatically disappears after the RAM is powered off, but the ROM does not automatically disappear, and the RAM can be powered off for a long time for storage.

In addition, it should be noted that, in the current upgrade process of the operating system, when the upgrade file in the upgrade package downloaded from the Over-the-Air (OTA) server to the user data partition (located in the rom 121A) in the electronic device is decompressed to the corresponding static partition and dynamic partition, the kernel cache of the ram 121B is used to implement fast reading and writing of the upgrade file.

In addition, the read-only memory 121A may be, for example, a magnetic disk storage device, a flash memory device, a general-purpose flash memory (universal flash storage, UFS), or the like, in particular, in practical applications; the random access memory 121B may be, for example, a high-speed random access memory.

In addition, it should be noted that, in a specific implementation, the read only memory 121A may include a storage program area and a storage data area. The storage program area may store an application program (such as a sound playing function, an image playing function, etc.) required for at least one function of the operating system, etc. The storage data area may store data created during use of the electronic device 100 (e.g., audio data, phonebook, etc.), and so on.

Exemplary, regarding the program storage area, specifically, in the technical solution provided in the embodiments of the present application, for example, basic partition (Common), static partition (Slot), and dynamic partition (Super); the storage data area, specifically, in the technical solution provided in the embodiment of the present application, may be, for example, a user data partition (Userdata).

With continued reference to fig. 2, the partition structure of the internal memory 121 of the electronic device 100 may be, for example, a non-AB system, an AB system, and a virtual AB system. Specifically, based on the characteristics of the four partitions (the basic partition, the static partition, the dynamic partition and the user data partition), for the partition that does not need to be upgraded in the operating system upgrade, for example, the basic partition and the user data partition, both in the non-AB system, the AB system and the virtual AB system are single partitions, while the partition that needs to be upgraded is different.

For example, since the operating system is upgraded under the non-AB system, other functions of the electronic device cannot be used in the upgrading process, the electronic device can only stay at the upgrading interface of the non-AB system, and after the operating system is upgraded and the electronic device is restarted, the electronic device can enter the user interface for normal use. Therefore, in the non-AB system, the static partition and the dynamic partition are also single partitions, as shown in (1) in fig. 3, so that the occupation of the memory space can be reduced, and more space is reserved for user data partition.

The AB system is exemplary, so that a user can return to the main interface of the electronic device at will during the upgrade of the operating system of the electronic device, so that the use of the electronic device is not affected. Thus, in the AB system, the static partition and the dynamic partition adopt dual partitions, and detailed in (2) in fig. 3, the static partition may be divided into, for example, a first static partition (SlotA) and a second static partition (SlotB), and the dynamic partition may be divided into, for example, a first dynamic partition (SuperA) and a second dynamic partition (SuperB). The partition dividing mode can enable the electronic equipment to return to the main interface of the electronic equipment at will in the process of upgrading the operating system, but occupies a large space of the memory, so that the available space of the user data partition is greatly reduced.

The virtual AB system combines the advantages of the non-AB system and the AB system by dividing a static partition that occupies a small storage space into a first static partition (SlotA) and a second static partition (SlotB), and a dynamic partition that occupies a large storage space into a single partition, as shown in fig. 3.

Taking the partition structure of the rom 121A as the virtual AB system partition structure as an example, in particular to practical applications, the partition deployment information of the rom 121A in the electronic device may be described by a partition table shown in table 1.

TABLE 1 partition Table

In this way, the starting address and size of each partition are defined by the partition table, so that the corresponding partition size can be adjusted as needed for different hardware.

In addition, it should be noted that, except for the specially reserved partition, basically, each partition has its corresponding image (image) file, where the image file is compiled by software code, and various functional files and configurations related to the starting or running process of the electronic device are integrated therein. Without the image file, the electronic device is not operational. A complete system version includes many images, partition table images gpt.img, boot related images (xloader.img, boot. Img), system images super.img (integrating android system cores), user data images userdata.img (storing user data), etc.

It should be understood that the above description is only an example for better understanding of the technical solution of the present embodiment, and is not to be taken as the only limitation of the present embodiment.

That is, in practical applications, the partitions recorded in the partition table may be set in a partition manner according to the actual service requirements.

In addition, the distribution of the partition in the memory in the form of the double partition in the AB system partition structure and the virtual AB system partition structure is not limited to the pattern shown in fig. 3 (2) and 3, and the position of each partition is determined according to the assigned start address and end address in practical use.

As to the hardware architecture of the electronic device 100, it should be understood that the electronic device 100 shown in fig. 1 is merely an example, and in particular implementations, the electronic device 100 may have more or fewer components than shown, may combine two or more components, or may have different component configurations. The various components shown in fig. 1 may be implemented in hardware, software, or a combination of hardware and software, including one or more signal processing and/or application specific integrated circuits.

In addition, it should be noted that, in an actual application scenario, along with development of Over-the-Air Technology (OTA), an OTA upgrade for remotely upgrading an electronic device through a wireless network interface of the electronic device is becoming more and more popular. In order to facilitate the description of the upgrade scheme of the operating system described in the embodiment of the present application, in conjunction with an actual service scenario, in the following, in conjunction with fig. 4, an OTA upgrade scenario is taken as an example, to describe interactions among the packet capturing server, the OTA server and the electronic device in the upgrade scheme of the operating system provided in the embodiment of the present application.

For example, referring to fig. 4, an upgrade package for upgrading an operating system of an electronic device (such as a PC device, a tablet device, a mobile phone, etc. in fig. 4) is made by a package server according to a version image, and the made upgrade package is uploaded to an OTA server by the package server, and the OTA server uniformly manages and actively pushes the upgrade package to an accessed electronic device, or sends the upgrade package to a corresponding electronic device according to a request of the accessed electronic device.

With continued reference to fig. 4, after the electronic device acquires the upgrade package from the OTA server to upgrade the operating system, the electronic device will report the upgrade result to the OTA server, so that the OTA server can know whether the upgrade of the operating system of the electronic device is successful.

In addition, it should be noted that, in the actual application, for the case of upgrade failure, the upgrade result reported to the OTA server by the electronic device may further include log information of upgrade failure, so as to quickly locate the reason of the upgrade failure of the operating system.

In particular, in the upgrade scheme of the operating system provided by the embodiment of the application, in order to shorten the holding time of the dormant lock in the upgrade process of the operating system as much as possible, so as to reduce the power consumption of the electronic device in the upgrade process, the electronic device modifies the installation process and the verification process in the upgrade process of the operating system from serial execution to parallel execution when the operating system is upgraded.

As shown in fig. 5, in the upgrade scheme of the operating system provided by the embodiment of the present application, when the electronic device obtains the upgrade package from the OTA server (step (1) in fig. 5) to upgrade the operating system, the electronic device will upgrade the static partition according to the upgrade package, that is, write (install) the data of the upgrade file of the child partition corresponding to the static partition in the upgrade package into the corresponding child partition in the static partition (step (2) in fig. 5).

Then, after the static partition is updated successfully, the dynamic partition is updated according to the update package (step (3.1) in fig. 6), namely, the data of the update file corresponding to the sub-partition of the dynamic partition in the update package is written (installed) into the cow file corresponding to the sub-partition in the user data partition, and meanwhile, in the process of executing the update operation on the dynamic partition, the static partition checking thread is started to check the static partition by the static partition (step (3.2) in fig. 6), so that the update process of the dynamic partition and the check process of the static partition can be executed in parallel, namely, the step (3.1) and the step (3.2) in fig. 6 are executed synchronously.

Then, after the static partition is checked successfully and the dynamic partition is upgraded, the dynamic partition needs to be checked (step (4) in fig. 6) to ensure that the upgraded dynamic partition is available.

Then, after the verification is successful, the electronic device may be triggered to restart the whole machine (step (5) in fig. 6).

It can be understood that in practical application, after the upgrade file in the upgrade package is installed and verified successfully, the electronic device can be directly triggered to enter the whole machine for restarting, or can be delayed to enter the whole machine for restarting.

For example, regarding the condition of delaying entering the whole machine restart, in some implementations, the electronic device may automatically trigger the whole machine restart when the electronic device is idle, i.e., when the user is not using, and when the application is not occupied; in other implementations, the user may manually trigger the electronic device to enter the complete machine for restarting as needed.

In addition, it should be noted that, if before the operating system upgrade is performed, the electronic device loads the data of the base partition, the data of the first static partition, and the data of the dynamic partition in sequence after the electronic device is started, and runs the first operating system (the version before the operating system upgrade), then after the operations of steps (1) to (5) shown in fig. 5 and 6 are completed, the electronic device loads the data of the base partition, the data of the second static partition, the data of the dynamic partition, and the data in the cow file in the user data partition in sequence, so that the electronic device runs to the second operating system (the version after the operating system upgrade).

And then, after the electronic equipment is restarted to run to the second operating system, the Merge operation is executed, and the data in the cow file is dropped to the sub-partition corresponding to the dynamic partition.

Taking fig. 7 as an example, if an upgrade file needs to be installed in a System sub-partition of a dynamic partition in an upgrade process of an operating System, a COW file created in a user data partition is a system_cow file corresponding to the System sub-partition.

Accordingly, the Merge operation performed after the restart is an operation of dropping the content in the system_cow file to the System child partition (step (6) in fig. 7).

With continued reference to fig. 7, in some implementations, after completing the Merge operation, the electronic device may further perform a partition synchronization operation, specifically, synchronize the static partition that is updated during the current operating system upgrade (step (7) in fig. 7).

Still referring to fig. 7, when the upgrade of the operating system is to upgrade the file in the dtbo_b sub-partition in the second static partition from version 1.0 to version 2.0, after completing the Merge operation, the electronic device copies the file in the dtbo_b sub-partition to the dtbo_a sub-partition in the first static partition, so as to achieve synchronization of the two sub-partitions.

Next, after the partition synchronization operation is completed, the electronic device reports the upgrade result to the OTA server (step (8) in fig. 7).

It can be understood that in practical application, when any step of step (3.2), step (4) shown in fig. 6, and step (6) and step (7) shown in fig. 7 is abnormal, and the upgrade of the present operating system fails, the electronic device will interrupt the subsequent upgrade operation and report the upgrade result to the OTA server.

Furthermore, it should be understood that the foregoing description is only illustrative for better understanding of the technical solutions of the present embodiment, and is not to be taken as the only limitation of the present embodiment.

In addition, the letters corresponding to the above-mentioned partitions may not be in the case of being in practical use, and the present application is not limited thereto.

In order to better understand the upgrade scheme of the operating system provided by the application, the following is a detailed description of the upgrade process of the operating system from the creation of the upgrade package from the package beating server to the electronic device obtaining the upgrade package created by the package beating server from the OTA server in combination with fig. 8.

Before describing the upgrade scheme of the operating system provided by the present application with reference to fig. 8, a description will be first given of functional units/modules/applications involved in the upgrade process of the operating system of the electronic device. For convenience of explanation, the operating system used by the electronic device is taken as an Android system in this embodiment, and in an exemplary implementation, the upgrade package may be obtained from the OTA server by the system upgrade client (OTA Update Client, OUC), for example.

Note that, in this embodiment, the OUC is specifically an Application installed in an Application layer (Application) of the electronic device, and is used for performing upgrade management of an operating system.

In addition, after the upgrade package is obtained from the OTA server, the OUC sends the obtained upgrade package to an upgrade engine (update_Engine) in the electronic device, the update_Engine completes the upgrade of the static partition, and the update_Engine and the snapshot node/snapshot process (snap process) complete the upgrade of the dynamic partition.

And then, after the update_engine and the snap process finish the installation (upgrading) of the upgrade file in the upgrade package, the OUC triggers the electronic equipment to enter the whole machine for restarting, after the electronic equipment is restarted and runs to the upgraded operating system, a kernel (kernel) executes the Merge operation, data in the cow file in the user data partition is dropped into a corresponding sub-partition in the dynamic partition, and the update_engine performs partition synchronization on the static partition.

Furthermore, it will be appreciated that in other implementations, the upgrade of the operating system may also be accomplished through an entry provided by a setup application installed in the application layer, which is not limited by the present embodiment.

Exemplary, referring to fig. 8, the upgrade scheme of the operating system provided by the present application includes:

S101, making an upgrade package according to the version image.

Specifically, in practical application, the upgrade package manufactured by the package beating server can be manufactured into a differential upgrade package and a full upgrade package according to service requirements.

For example, regarding the production of the differential upgrade package, for the smaller image files related to starting, the image files are packaged into the upgrade package in a full coverage mode during upgrade; for a relatively large image file, such as super. Img, in order to reduce the size of the upgrade package, the difference of each logical partition image in the new and old version super. Img is extracted through a specific differential algorithm, then an independent patch (patch) file is generated and packaged into the upgrade package, and when the operating system is upgraded, the patch file in the upgrade package is merged into the old version super. Img in the electronic device super partition through the specific differential algorithm, so that a new version super. Img can be generated, and the upgrade of the old version super. Img into the new version super. Img is completed.

Regarding the production of the full package, in particular, all image files of the new version are packaged into the upgrade package in a full package, i.e. no separate patch file exists.

In practical application, the manufacturing of the differential upgrade package and the full upgrade package is only needed by referring to the existing standard, and this embodiment will not be described.

S102, uploading an upgrade package.

For example, in some implementations, the upgrade package may be actively uploaded to the OTA server by the package beating server when the new version of the upgrade package is detected, or the newly issued upgrade package may be actively uploaded to the OTA server at regular time according to a preset period.

For example, in other implementations, the condition for the clapping server to upload the upgrade package may be to upload the newly published upgrade package to the OTA server after receiving the request of the OTA server.

S103, storing the upgrade package.

Illustratively, in some implementations, to avoid occupation of the space of the OTA server by the redundancy version, the OTA server may traverse the saved upgrade package periodically to clear the redundancy version.

Illustratively, in other implementations, to further reduce space occupation of the OTA server, the OTA server may periodically clean up upgrades of old versions.

S104, searching whether an upgrade package exists in the OTA server.

It can be appreciated that, in general, an upgrade package for upgrading an operating system installed in an electronic device is made by a package server and then uploaded to an OTA server for management in the face of a massive user population. The OTA server performs data interaction with the accessed electronic equipment, namely, a communication link is established between the OTA server and the electronic equipment. Thus, in some implementations, the electronic device may actively initiate a search request to the OTA server to determine whether an upgrade package corresponding to the new version of the operating system exists in the OTA server.

In other implementations, the OTA server may actively push the notification information to notify the electronic device that the new version of the upgrade package of the operating system currently exists when detecting that the new version of the upgrade package of the operating system corresponds to the new version of the operating system.

For convenience of explanation, in this embodiment, the electronic device actively initiates a search request to the OTA server, and searches whether an upgrade package corresponding to a new version of the operating system exists in the OTA server.

Correspondingly, if it is found that the update package corresponding to the new version of the operating system exists in the OTA server, the step S105 is executed, otherwise, a search request is initiated to the OTA server at regular time according to the set search period, or the search request is initiated to the OTA server when the user triggers.

S105, acquiring an upgrade package.

Illustratively, in one possible implementation, after the electronic device initiates a request to the OTA packet server to obtain an upgrade packet (e.g., version 1.2), the OTA server feeds back to the electronic device a download address of the upgrade packet (e.g., a system delta upgrade packet that is upgraded from version 1.1 to version 1.2); the electronic device downloads the upgrade package according to the download address of the upgrade package, and saves the upgrade package to a user data partition (Userdata).

S106, issuing an upgrade package.

That is, after receiving the request initiated by the OUC to obtain the upgrade package, the OTA server responds to the request and issues a download address corresponding to the requested upgrade package to the OUC, so that the electronic device can download the upgrade package according to the download address of the upgrade package.

S107, issuing an upgrade instruction.

It can be appreciated that for the electronic device of the Android system, the upgrade of the operating system is completed by the upgrade engine (update_engine). Therefore, after the OUC downloads the upgrade package from the OTA server and completes resetting the compression attribute, an upgrade instruction is issued to the update_engine to trigger the update_engine to start executing the upgrade process.

S108, upgrading the static partition according to the upgrade file corresponding to the static partition in the upgrade package.

The method includes the steps that the electronic device is started by taking a first static partition as a starting partition before an operating system is upgraded, at this time, after an upgrade package is obtained from an OTA server, the upgrade package needs to be decompressed, an upgrade file aiming at the static partition in the upgrade package is further obtained, and then data in the obtained upgrade file aiming at the static partition is written into a corresponding sub-partition in a second static partition.

For example, the static partition data of version 1.2 is contained in the upgrade package, and the device overwrites the static partition data of version 1.2 into static partition (B).

S109, after the static partition is upgraded, starting a static partition verification thread to verify the static partition.

For example, in this embodiment, after the static partition is installed, the update_engine may start the static partition checking thread, and the static partition checking thread performs static partition checking, specifically, checking the second static partition.

S110, in the process of checking the static partition, a cow file is created in the user data partition, and an upgrade file corresponding to the dynamic partition in the upgrade package is written into the cow file.

For example, in this embodiment, in the process of starting the static partition checking thread to check the static partition, the update_engine may synchronously install the dynamic partition, that is, upgrade the dynamic partition according to the upgrade file corresponding to the dynamic partition in the upgrade package.

In addition, it should be noted that, in the technical solution provided in this embodiment, if the static partition check fails, the dynamic partition installation operation is interrupted, and the information of the upgrade failure is reported to the OTA server according to the upgrade failure processing; if the static partition is checked successfully, the operation of upgrading the dynamic partition is continuously executed, and if the upgrading of the dynamic partition is completed, the operation of checking the dynamic partition is executed.

S111, after all data in the upgrade files corresponding to the dynamic partitions in the upgrade package are written into the corresponding cow files, the dynamic partitions are checked.

In the technical scheme provided by the embodiment, after the data in the upgrade files corresponding to the dynamic partitions in the upgrade package are all written into the corresponding cow files, the static partitions are not checked any more, and only the dynamic partitions are checked, so that a part of check time is shortened, and the upgrade of the operating system can be completed rapidly.

Accordingly, if the static partition and the dynamic partition are both verified successfully, step S112 is performed; if any one of the static partition and the dynamic partition fails to check, the updating failure is processed according to the updating failure, and information of the updating failure is reported to the OTA server.

In order to better understand the descriptions of steps S108 to S111 in the present embodiment, a specific description will be given below with reference to fig. 9.

Exemplary, referring to fig. 9, specifically includes:

s201, the upgrade engine decompresses the first upgrade file corresponding to the second static partition from the upgrade package.

For example, an upgrade package relied upon in an operating system upgrade process will typically include an upgrade file for upgrading a static partition and an upgrade file for upgrading a dynamic partition. In this embodiment, for convenience of explanation, an upgrade file for upgrading a static partition is referred to as a first upgrade file, and an upgrade file for upgrading a dynamic partition is referred to as a second upgrade file.

Further, as is apparent from the above description, a plurality of sub-partitions are included in the static partition (first static partition and second static partition), for example, X-loader_a, vendor_a, dtbo_a, etc. included in the first static partition in fig. 5 to 7, and X-loader_b, vendor_b, dtbo_b, etc. included in the second static partition.

It will be appreciated that fig. 5 to 7 are given as examples only, and are listed for better understanding of the technical solution of the present embodiment, and are not the only limitation of the present embodiment.

Furthermore, it can be appreciated that in the virtual AB system partition structure, the first static partition and the second static partition are backup partitions to each other, i.e., the sub-partitions in the two static partitions are shown to correspond to each other, e.g., X-loader_a corresponds to X-loader_b, vendor_a corresponds to vendor_b, dtbo_a corresponds to dtbo_b.

S202, the upgrade engine upgrades the second static partition according to the first upgrade file.

For example, if the first upgrade file obtained from the upgrade package corresponds to dtbo, the dtbo_b sub-partition in the second static partition is upgraded according to the first upgrade file, and specifically, the data in the first upgrade file is written into the dtbo_b sub-partition.

S203, after the second static partition is upgraded, the upgrade engine starts a static partition verification thread.

For example, in some implementations, the static partition check thread may be created and started by the upgrade engine after the second static partition is upgraded.

For example, in other implementations, the static partition check thread may be created by the upgrade engine after receiving the upgrade instruction, and then started by the upgrade engine after the second static partition is upgraded.

For example, see step S301 to step S305 in fig. 9 for a procedure of static partition checking by the static partition checking thread.

Illustratively, in some implementations, the static partition checking thread performs a static partition checking operation, specifically checking all child partitions in the static partition that complete the upgrade.

Illustratively, in other implementations, the static partition checking thread performs a static partition checking operation, and in particular, checks all sub-partitions in the static partition.

For example, in practical application, when the clapping server creates the upgrade package, file list description information (filelist. Xml) corresponding to the upgrade package is also created.

For example, hash values required for verifying the file body and the file metadata are recorded in the filelist. Xml, so that verification of the sub-partition in the static partition can be achieved by comparing the hash value of the first upgrade file in the upgrade package with the hash value of the sub-partition corresponding to the first upgrade file written in the second static partition.

S301, the static partition checking thread judges whether the sub-partition in the static partition checked currently is successful or not.

Taking the example that the second static partition shown in fig. 5 to 7 includes three sub-partitions of X-loader_b, vendor_b and dtbo_b, if the operation system is upgraded (from the first operation system to the second operation system) and all the three sub-partitions are upgraded, the static partition checking thread checks the static partition, and needs to check the three sub-partitions respectively. Thus, after each child partition is checked, the static partition check thread needs to determine whether the child partition in the currently checked static partition is successful.

Accordingly, if successful, step S302 is performed, whereas step S303 is performed.

S302, the static partition checking thread modifies the checking state corresponding to the static partition into 'successful checking'.

S303, the static partition checking thread modifies the checking state corresponding to the static partition into 'successful checking'.

In an exemplary embodiment, an interface for recording a verification state corresponding to a static partition is provided, for example, staticpartionschk () shown in fig. 9. If it is determined by the judgment of step S301 that the currently checked sub-partition check is successful, the static partition check thread calls staticproportionchkkok () to set the check state.

For example, in practical application, the correction of the verification state corresponding to the static partition to "verification success" may be achieved through setstaticpartionschkkok ().

For example, if it is determined that the sub-partition currently checked fails to check through the judgment of step S301, the modification of the check state corresponding to the static partition to "check failed" may be implemented through setstaticpartisticgchkkok ().

Further, it should be understood that the above description of setting the verification state to "verification failure" or "verification success" is an example that is enumerated for better understanding of the technical solution of the present embodiment, and is not the only limitation of the present embodiment. In practical applications, other contents may be agreed to indicate the success of the check and the failure of the check, for example, an agreement of "1" indicates the success of the check, a agreement of "0" indicates the failure of the check, or an agreement of "true" indicates the success of the check, and a agreement of "false" indicates the failure of the check.

For example, based on this, in some implementations it may be agreed that when the checking of the currently checked sub-partition in the second static partition is successful, the checking state corresponding to the second static partition is modified to the first state by the static partition checking thread; otherwise, the checking state corresponding to the second static partition is modified to be the second state.

Illustratively, the first state is used for indicating that the currently checked sub-partition is checked successfully, and the second state is used for indicating that the currently checked sub-partition is checked successfully.

As can be seen from the above description, in this embodiment, each time a sub-partition of a static partition is checked by a static partition checking thread, setstatic partition chkkok () is called to record a check state corresponding to the static partition once, so that the check state of the static partition can be accurately reflected, and feedback can be timely sent to an upgrade engine when checking failure of any sub-partition of the static partition occurs, so that upgrade operation of the dynamic partition can be timely stopped, and system power consumption can be reduced.

S304, the static partition checking thread judges whether all the sub-partitions of the static partition which are updated are checked.

For example, taking the example that all three sub-partitions of the X-loader_b, vendor_b, dtbo_b in the second static partition need to be checked, if the first check is the X-loader_b sub-partition, after the determination in step S301, if it is determined that the check on the X-loader_b sub-partition is successful, step S304 is executed. Since the two sub-partitions of the vendor_b and the dtbo_b need to be checked, the static partition checking thread determines that the updated sub-partition is not checked through judgment, and then step S301 is continuously executed, that is, the two sub-partitions of the vendor_b and the dtbo_b are checked sequentially according to the operations from step S301 to step S304.

For example, if the currently checked sub-partition is the dtbo_b sub-partition, after the static partition checking thread executes step S304 again, it is determined that there are no sub-partitions to be checked, that is, all sub-partitions that have completed the upgrade are checked, and step S305 is entered to end the checking of the static partition.

S305, the static partition checking thread ends checking the static partition.

For example, if the static partition checking thread completes checking all the sub-partitions in the static partition, and when all the sub-partitions are checked successfully, the dynamic partition has not been upgraded, the checking operation on the static partition is finished between the static partition checking threads.

S204, the upgrade engine decompresses a second upgrade file corresponding to the dynamic partition from the upgrade package.

S205, the upgrade engine informs the snap process to create a cow file of a sub-partition corresponding to the second upgrade file in the user data partition.

It can be understood that in practical application, after receiving the instruction of creating the cow file of the sub-partition corresponding to the second upgrade file issued by the upgrade engine, the snap process creates the corresponding cow file according to the instruction.

Accordingly, if the snap process is successfully created, feedback information of the success of the creation is fed back to the upgrade engine, so that the upgrade engine writes the second upgrade file into the cow file, i.e., performs step S206 below.

Correspondingly, if the creation fails, for example, the cow file cannot be created due to insufficient space of the user data partition, the snap process feeds back feedback information of the creation failure to the upgrade engine, so that the upgrade engine directly ends the upgrade operation on the dynamic partition and reports the upgrade failure information to the OTA server.

For convenience of explanation, this embodiment will be described with subsequent steps taking success in creation as an example.

S206, the upgrade engine writes the second upgrade file into the cow file.

S207, the upgrade engine judges whether 1% (increment) of data is written to the cow file.

It can be understood that, since the second upgrade file for upgrading the dynamic partition is generally larger, the upgrade time is relatively longer, so that in the process of parallel execution of static partition verification and dynamic partition upgrade, whether to perform subsequent upgrade operation is determined according to the verification result of the static partition, so that when the static partition verification fails, the upgrade operation on the dynamic partition is stopped in time, thereby better reducing the power consumption of the electronic device. In this embodiment, it is specified that, when the upgrade engine completes the first data on the dynamic partition, as in step S207, 1% of the upgrade progress calls an interface that acquires the check state corresponding to the static partition, for example, an interface that agrees to the check state recorded by the iscostaticpartitionchk () interface is an interface that acquires the check state recorded by the setstaticpartisticchk () interface, and after determining that 1% (increment) of data is written into the cow file corresponding to the second upgrade file, the upgrade engine performs step S208 by changing the check state recorded by the iscostaticpartitionchk () interface that acquires the check thread of the static partition through the setstaticpartisticchk () interface; otherwise, the step S206 is continued to write the data in the second upgrade file into the cow file corresponding to the second upgrade file.

It can be understood that the first data is substantially part of the data in the second upgrade file.

For example, in other implementations, in addition to acquiring the check state of the static partition in the manner set forth in step S207, it may be provided that an interface that records the check state corresponding to the static partition is invoked once each time writing of data of a child partition in a dynamic partition is completed.

For example, in other implementations, it may be further specified that an interface that obtains a check state corresponding to a static partition after writing a data block (block) of a sub-partition in a dynamic partition or writing a few blocks is invoked once.

It should be understood that the above description is only an example for better understanding of the technical solution of the present embodiment, and is not to be taken as the only limitation of the present embodiment. In practical application, the upgrade engine may set the verification state of the static partition according to the actual service requirement for how many increments the dynamic partition completes and the verification state is not limited herein.

S208, the upgrade engine acquires the check state recorded in the static partitionChkOK ().

S209, the upgrade engine judges whether the check state is "check successful".

For example, if it is determined that the verification state is "verification success" or other identification information indicating verification success by judgment, step S210 is performed; otherwise, the upgrade to the dynamic partition is directly stopped, and the upgrade failure information is reported to the OTA server according to the upgrade failure processing, namely, the step S214 is executed.

It should be noted that, in practical application, there may be a case where the upgrade engine has written 1% of data into the cow file, but the static partition check thread has not completed checking any child partition that has completed the upgrade in the static partition, and thus when the upgrade engine acquires the check state recorded in the static partitionchkkok (), there may be a case where the check state is not acquired. For this scenario, the contract upgrade engine may continue to perform the operations of step S216.

S210, the upgrade engine judges whether the data of the second file is completely written into the cow file.

For example, if it is determined by the judgment that the data of the second upgrade file has been written to the corresponding cow file (or all upgrade files for upgrading the dynamic partition have been written to the corresponding cow file, that is, the upgrade to the dynamic partition is completed), step S211 is performed; otherwise, the step S206 is continued to write the data in the second upgrade file into the cow file corresponding to the second upgrade file.

S211, checking the dynamic partition by the upgrade engine.

For example, since the second upgrade file of the upgrade dynamic partition is written into the corresponding cow file in the user data partition in the form of increment, when the upgrade engine verifies the dynamic partition, the whole verification needs to be performed on the corresponding cow files in the dynamic partition and the user data partition.

S212, the upgrade engine judges whether the dynamic partition is successfully checked.

Illustratively, if the verification is successful, step S213 is performed; otherwise, according to the upgrade failure processing, reporting the upgrade failure information to the OTA server, that is, executing step S214.

S213, the upgrade engine reports the successful upgrade information to the OTA server.

S214, the upgrade engine reports the upgrade failure information to the OTA server.

With continued reference to fig. 9, in the technical solution provided in this embodiment, steps S204 to S210 are executed in parallel with steps S301 to S305, that is, during the execution of steps S204 to S210, steps S301 and S305 are executed synchronously, thereby implementing parallel execution of static partition check and dynamic partition upgrade, so as to shorten the overall upgrade time of the operating system and reduce the power consumption of the electronic device.

S112, after the static partition and the dynamic partition are successfully checked, the whole machine is triggered to restart.

For example, after the verification is completed, the OUC may trigger the electronic device to restart the whole machine. The operation of the OUC to trigger the electronic device to restart the whole machine is described in detail in the above embodiment with respect to the restart portion in step (5) of fig. 6, which is not repeated here.

S113, in the restarting process, loading the data in the cow file.

For example, before the electronic device performs an operating system upgrade, the electronic device is started from the first static partition, that is, the operating system that is loaded during the starting is the first operating system (the operating system before the upgrade) and is operated by the data of the base partition, the data of the second static partition, the data of the dynamic partition and the data in the cow file in the user data partition, and when the electronic device restarts after the electronic device performs the operating system upgrade, the electronic device can be operated to the second operating system, that is, the operating system after the upgrade, by taking the example that the operating system that is operated by the data of the base partition, the data of the first static partition and the data of the dynamic partition as the first operating system is started.

In addition, it should be noted that, in this embodiment, the electronic device is started with the first static partition as a starting sequence before the operating system is upgraded, that is, the data of the base partition, the data of the first static partition, and the data of the dynamic partition are sequentially loaded during starting, so that the upgrade scheme of the operating system is that the second static partition is upgraded, and therefore, the data of the second static partition needs to be loaded during restarting, that is, the starting sequence is changed from the first static partition to the second static partition.

And S114, after restarting, executing the Merge operation, and landing the data in the cow file to the sub-partition corresponding to the dynamic partition.

It can be understood that, in this embodiment, the Merge operation specifically refers to a process of dropping an upgrade file of an upgrade dynamic partition in a user data partition into the dynamic partition, that is, a process of dropping data in a cow file into a corresponding sub-partition in the dynamic partition.

For the specific implementation flow of the Merge operation, refer to the existing standard, and this embodiment will not be described in detail.

And S115, reporting a Merge result.

Illustratively, after the execution of the Merge operation is completed, the kernel may report the Merge result to the upgrade engine, so that the upgrade engine may learn whether the upgrade file of the upgrade dynamic partition in the user data partition is dropped to the dynamic partition.

Accordingly, if Merge is successful, that is, the upgrade file of the upgrade dynamic partition in the user data partition is dropped to the dynamic partition, step S116 is executed, otherwise, upgrade failure may be directly reported to the OTA server through OUC.

For example, in some implementations, after the Merge operation fails, the OUC may restart the electronic device, and control the electronic device to roll back from the second operating system to the first operating system, so that even if the upgrade fails, normal use of the electronic device may be ensured.

S116, after the Merge is successful, the static partition is subjected to partition synchronization.

For example, taking the case that the data of the second static partition is updated according to the upgrade file corresponding to the static partition in the upgrade package as an example, after the Merge is successful, the partition synchronization operation is performed on the static partition, specifically, the data of the second static partition is synchronized to the first static partition.

Regarding the operation of synchronizing the data of the second static partition to the first static partition, in some implementations, for example, it may be that the data in the various sub-partitions of the second static partition are read by the kernel; and then, the data in each sub-partition of the second static partition is rewritten into the sub-partition corresponding to the first static partition.

It can be understood that, in practical application, the upgrade of the operating system may only upgrade one or some sub-partitions in the static partition, so when partition synchronization is performed, in order to reduce occupation of resources of the electronic device by partition synchronization, whether data in the first sub-partition in the second static partition is the same as data in the second sub-partition in the first static partition may be checked first.

Accordingly, if the data in the first sub-partition is the same as (consistent with) the data in the second sub-partition, skipping the copying of the sub-partition, and continuing to compare with other sub-partitions; and otherwise, copying the data in the first sub-partition, and then overwriting the data in the second sub-partition.

For the above scheme of checking whether the data in the first sub-partition in the second static partition is the same as the data in the second sub-partition in the first static partition, and determining whether to perform partition synchronization according to the checking result, the processing may be, in specific implementation:

first, a hash value of data of a first sub-partition and a hash value of data of a second sub-partition are calculated.

Specifically, the first sub-partition is a sub-partition of the second static partition, the second sub-partition is a sub-partition of the first static partition, and the second sub-partition corresponds to the first sub-partition.

For example, with continued reference to fig. 7, if a first sub-partition in the second static partition is dtbo_b, a second sub-partition in the first static partition corresponding to the first sub-partition is dtbo_a.

Then, when the hash value of the data of the first sub-partition is inconsistent with the hash value of the data of the second sub-partition, the data in the first sub-partition is overwritten into the second sub-partition.

In addition, the operation in step S116 is not limited to the technical solution provided by the present application, and in practical application, step S116 may be performed or not performed, which is not limited herein.

S117, reporting the upgrading result.

For example, after the static partition synchronization operation is performed, the OUC reports the upgrade result to the OTA server, so that the OTA server can know whether the upgrade of the operating system is successful. The operation of the OUC reporting the upgrade result to the OTA server is described in detail in the above embodiment with respect to the reporting the upgrade result portion (8) in fig. 7, which is not repeated here.

It is not difficult to find out that in the upgrade scheme of the operating system provided by the embodiment, the installation process and the verification process in the upgrade process of the operating system are modified from serial execution to parallel execution, so that the operation system is ensured to be quickly upgraded, the holding time of the dormant lock is shortened, and the problem of high overall power consumption of the electronic equipment caused by the upgrade of the operating system is solved.

By way of example, based on the upgrade scheme of the operating system provided in the present embodiment, the operating system is upgraded by taking the differential upgrade package and the full upgrade package as examples, and tests show that the test shows that the test time is reduced by about 10% in the upgrade process for the differential package upgrade. For full package upgrades, the verification time during the upgrade is reduced by about 20%.

In addition, in the upgrading process of the operating system, the electronic equipment may be restarted due to Power failure caused by some external factors, for example, a user presses a Power key for a long time to forcibly restart the electronic equipment in the upgrading process, so that the upgrading scheme of the operating system provided by the application can be applicable in the scene, namely, a parallel execution mode can be continuously adopted in the upgrading process after the electronic equipment is scheduled to restart, so that the upgrading time is shortened. When the power is turned off and restarted, and the breakpoint before the power is turned off is continuously updated, the operations executed in parallel are different according to the current upgrading progress.

It can be understood that the electronic device after forced restarting needs to rely on the breakpoint information recorded in the breakpoint record file stored in the user data partition, so that in the process of upgrading the operating system of the electronic device with the virtual AB system partition structure, that is, the upgrading engine upgrades the second static partition according to the first upgrading file, and upgrades the dynamic partition according to the second upgrading file, the upgrading engine records the breakpoint information to the breakpoint record file, so that after the electronic device is powered down and restarted, the continuously upgraded position can be quickly and accurately positioned according to the breakpoint information recorded in the breakpoint record file.

In this embodiment, the breakpoint identified by the breakpoint information is a location at which the electronic device is continuously updated after restarting.

After the power-down restart, if it is determined that the continuously-ascending partition is the second static partition according to the breakpoint information recorded in the breakpoint record file, that is, if the upgrade engine detects that the static partition has not been upgraded yet, then when the upgrade is continuously performed from the breakpoint before the power-down, the static partition is continuously upgraded according to the upgrade file corresponding to the static partition in the upgrade package, and after the static partition is upgraded, the static partition checking thread is restarted, and the static partition is checked by the static partition checking thread, that is, the operations from step S301 to step S305 in fig. 9 are performed, and meanwhile, the upgrade engine upgrades the dynamic partition according to the upgrade file corresponding to the dynamic partition in the upgrade package, that is, the operations from step S204 to step S210 in fig. 9 are performed.

Regarding the process of continuously upgrading the second static partition from the breakpoint position before power failure, for example, reading data from the breakpoint position identified by the breakpoint information in the first upgrade file according to the breakpoint information, upgrading the second static partition according to the read data, and specifically writing the read data into a sub-partition corresponding to the first upgrade file in the second static partition.

For example, after the power-down restart, if it is determined that the continuously-ascending partition is a dynamic partition according to the breakpoint information recorded in the breakpoint record file, that is, the upgrade engine detects that the static partition has been upgraded, but the dynamic partition has not yet started to be upgraded, in order to avoid an abnormality in data of the static partition caused by the power-down, the static partition verification thread is restarted to verify the static partition when the data of the static partition is continuously upgraded from the breakpoint before the power-down, that is, the operations from step S301 to step S305 in fig. 9 are performed, and meanwhile, the upgrade engine upgrades the dynamic partition according to the upgrade file corresponding to the dynamic partition in the upgrade package, that is, the operations from step S204 to step S210 in fig. 9 are performed.

Regarding the process of continuously upgrading the dynamic partition from the breakpoint position before power failure, for example, reading data from the position of the breakpoint identified by the breakpoint information in the second upgrading file according to the breakpoint information, upgrading the dynamic partition according to the read data, and specifically writing the read data into the cow file corresponding to the second upgrading file in the user data partition.

For example, after the power-down restart, if the upgrade engine detects that the static partition has been upgraded and the dynamic partition has also been upgraded, in order to avoid the occurrence of an exception in the data of the static partition and the dynamic partition caused by the power-down, when the upgrade is continued from the breakpoint before the power-down, the static partition checking thread is restarted to check the static partition, that is, the operations of step S301 to step S305 in fig. 9 are performed, and at the same time, the upgrade engine checks the dynamic partition, that is, the operations of step S211 and step S212 in fig. 9 are performed.

Therefore, even if the electronic equipment with the virtual AB system partition structure is powered down in the upgrading process of the operating system, when the electronic equipment is restarted and continuously upgraded according to the breakpoint information recorded in the breakpoint record file, the operation for the static partition and the operation for the dynamic partition are executed in parallel, so that the whole upgrading time of the operating system can be shortened, and the power consumption of the electronic equipment in the upgrading process is reduced.

In addition, in order to better understand the whole flow of the operating system upgrade realized based on the technical scheme provided in the present embodiment, the following description is made with reference to fig. 10.

It should be noted that, the upgrade process for implementing the operating system shown in fig. 10 is implemented for the virtual AB system partition structure, and when the electronic device is currently started from the first static partition (SlotA in the foregoing drawing), the electronic device implements the upgrade of the operating system according to the process shown in fig. 10.

S401, the electronic device sequentially loads data of the basic partition, data of the first static partition and data of the dynamic partition, and starts from the first static partition to run the first operating system.

S402, when the system upgrade client in the electronic equipment searches the upgrade package, the upgrade package is obtained from the OTA server.

For example, in one possible implementation, the electronic device periodically initiates a packet search request to the OTA packet server, where the packet search request includes a version number (e.g., version 1.1) of the operating system currently running by the electronic device; the OTA server searches whether an upgrade package (for example, version 1.2) with an update version number exists currently according to the version number of the operating system in the package searching request; when the update version of the upgrade package exists, the OTA server feeds back the download address of the upgrade package (e.g., the system delta upgrade package from version 1.1 to version 1.2) to the electronic device; the electronic device downloads the upgrade package according to the download address of the upgrade package, and saves the upgrade package to a user data partition (Userdata).

S403, the upgrade engine in the electronic equipment upgrades the second static partition according to the upgrade file corresponding to the second static partition in the upgrade package.

For example, the system delta upgrade package for version 1.1 to version 1.2 contains the full amount of data for the static partition of version 1.2, and the electronic device overwrites the data for the static partition of version 1.2 into the second static partition (SlotB in the above figures).

S404, after the second static partition is upgraded, the upgrade engine starts a static partition verification thread to verify the second static partition.

S405, in the process of checking the second static partition by the static partition checking thread, the upgrade engine writes the data of the upgrade file corresponding to the dynamic partition in the upgrade package into the cow file corresponding to the sub-partition in the user data partition.

Regarding the operation of performing the checksum on the second static partition and the upgrade on the dynamic partition in parallel with the step S404 and the step S405, the descriptions of the step S301 to the step S305 in fig. 9 and the descriptions of the step S204 to the step S210 in fig. 9 are detailed above, and are not repeated here.

S406, after the second static partition is successfully checked, and the data in the upgrade file corresponding to the dynamic partition in the upgrade package is completely written into the cow file corresponding to the sub-partition, the upgrade engine checks the dynamic partition.

As can be seen from the above description, when an electronic device adopting a virtual AB system partition structure performs an operating system upgrade, the upgrade of a dynamic partition needs to be performed by means of a user data partition, that is, a cow file corresponding to a child partition in the dynamic partition to be upgraded needs to be created in the user data partition, and then data of the upgrade file is written into the cow file, so as to complete the upgrade of the child partition to be upgraded in the dynamic partition.

For ease of understanding, the upgrade and verification process for dynamic partitions is described in more detail below in connection with examples.

For example, the upgrade engine creates a cow file corresponding to the sub-partition in the user data partition (Userdata) according to the upgrade file corresponding to the dynamic partition in the upgrade package (it may also be understood that a virtual dynamic partition is created in the user data partition, that is, the cow file corresponding to each sub-partition is a virtual dynamic partition), and further writes upgrade data of the dynamic partition (Super) in the cow file.

For example, the upgrade package includes data of the dynamic partition of version 1.2, and the electronic device writes data of the dynamic partition (Super) of version 1.2 in a cow file created in the user data partition.

Furthermore, in the upgrade scheme of the operating system of the electronic device with the virtual AB system partition structure, an incremental upgrade mode is adopted for a dynamic partition (Super). In the upgrading process, the cow file of the user data partition (Userdata) stores not all files of the dynamic partition (Super) of the new version after upgrading, but upgrading results of the data to be upgraded in the dynamic partition (Super) of the old version after upgrading. That is, update data of the dynamic partition is stored in the cow file of the user data partition (Userdata).

Taking the system sub-partition as an example, assume that in version 1.1, the data in the system sub-partition can be divided into two parts, system1 and system 2. The data system2 is updated from version 1.1 to version 1.2, and the data system1 is updated to system3. Then, in step S405, the electronic apparatus creates a cow file in a user data partition (Userdata), and writes data system3 in the cow file.

For example, the system delta upgrade package for version 1.1 to version 1.2 contains the dynamic partition (Super) update data for version 1.1 to version 1.2, which contains data system3.

Further, in an upgrade scheme of an operating system of an electronic device of a virtual AB system partition structure, incremental upgrade of a dynamic partition (Super) is implemented based on a snapshot technology (snapshot). Specifically, in a cow file of a user data partition (Userdata), upgrade data of a dynamic partition (Super) is saved by using a Copy-On-Write (cow) file.

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

In the upgrade package acquired in step S402, the cow file of the upgrade data of the dynamic partition (Super) is compressed and saved in the form of binary code. In the upgrade package, each cow file is named according to the dynamic partition (Super) sub-partition for which it is intended. For example, the cow file for System child partition is named System-cow-img.img.0000.

In step S405, the electronic device unpacks the upgrade package to obtain all the cow files, and attaches an AB partition mark to each cow file. Specifically, when the electronic device is currently started from the first static partition (SlotA in the above-mentioned figures), it can be understood that the dynamic partition (Super) loaded by the operating system currently running by the electronic device is the dynamic partition (a). When the operating system is upgraded, the cow file created in the user data partition (Userdata) is for the dynamic partition (B). Therefore, the name tag_b of the corresponding dynamic partition (B) is attached to the cow file. For example, system_b-cow-img.img.0000 is generated for system-cow-img.img.0000 with the addition of_b.

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

system_b-cow-img.img.0000；

system_ext_b-cow-img.img.0000；

vendor_b-cow-img.img.0000；

product_b-cow-img.img.0000；

cust_b-cow-img.img.0000；

odm_b-cow-img.img.0000。

Specifically, the cow file includes a cow file map (snapshot map) of the cow file itself and upgrade data. The cow file map (snapshot) corresponds to a file map of a child partition of a dynamic partition (Super) to which the cow file is directed. The file map of the sub-partition of the dynamic partition (Super) is used to describe all files in the sub-partition of the dynamic partition (Super) and the save addresses of the respective files of the operating system of the current version (version before the current upgrade, e.g., version 1.1).

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

Based on the file map of the sub-partition of the dynamic partition (Super) and the cow file map in the cow file, the corresponding file in the sub-partition of the dynamic partition (Super) can be replaced by the upgrade data in the cow file, so that the upgrade of the dynamic partition (Super) data is realized. Specifically, when the file map of the sub-partition of the dynamic partition (Super) needs to be acquired, snapshot operation may be performed on the data of the sub-partition of the dynamic partition (Super) based on the snapshot to generate the file map of the sub-partition of the dynamic partition (Super). When the upgrade package is manufactured, a file map of a sub-partition of a dynamic partition (Super) may be generated in advance, and the file map may be added to the cow file.

Taking a System sub-partition as an example, assume that data is stored in the System sub-partition according to the following paths:

/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 System sub-partitioned file map may be:

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

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

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

/system/B0.XXX：024021～024026；

/system/B1.XXX：024027～024028；

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

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

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

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

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

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

It can be considered that:

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

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

Then the cow file for the System sub-partition (system_b-cow-img. 0000) contains the latest version of/System/app/A2. XXX and/System/user/C2. XXX.

It can be seen that the latest version of/system/app/a 2.Xxx and/system/user/c 2.Xxx is system3. The goal of the upgrade is to update system1 using system3.

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

/system/app/A2.XXX：

Map1 (address of data to be updated in original Super partition): the starting address start:024018 (offset from System child partition start address); offset size:2 (i.e. 024018 ～ 024020 address field data)

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

/system/user/C2.XXX：

map1 (address of data to be updated in original Super partition): the starting address start:024036 (offset from System child partition start address); offset size:4 (i.e. 024036 ～ 024040 address field data)

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

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

/system/app/A2.XXX：

map1.1 (address of data to be updated in original Super partition): the starting address start:024018 (offset from System child partition start address); offset size:2 (i.e. 024018 ～ 024020 address field data)

Map2.1 (address of update data stored in the cow file, which needs to be overlaid with map1.1 address): the starting address start:045033 (offset from the start address of the cow file store); offset size:2 (i.e., 045033 ～ 045035 address field data);

map1.2 (address to be written in the original super partition for the portion of the cow file where the update data exceeds the size of the data to be updated): the starting address start:025018 (offset from system start address); offset size:1 (i.e. 025018 ～ 025020 address field data)

Map2.2 (address of update data stored in the cow file, which needs to be overlaid with map1.2 address): the starting address start:046033 (offset from the start address of the cow file store); offset size:2 (i.e., 046033 ～ 046035 address field data).

In the following description, for convenience of description, only an application scenario is illustrated in which the size of update data in the cow file is consistent with the size of original data to be updated thereof, and the save position of update data in the cow file in the child partition after data update is consistent with the save position of original data to be updated thereof in the child partition.

In the above example, the address fields (045033 ～ 045035 and 045036 ～ 045040) are the physical save addresses (block addresses) of the latest version of the system/app/a2.Xxx and the system/user/c2.Xxx in the cow file (system_b-cow-img. 0000), respectively.

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

Further, in step S405, after writing the cow file into the user data partition (Userdata), it is further necessary to perform overall verification on the dynamic partition (Super) +cow file, verify the validity of the dynamic partition (Super) +cow file, and verify whether the result of synthesizing the dynamic partition (Super) data+cow file of the current version is the dynamic partition (Super) data of the new version.

Specifically, taking upgrading from version 1.1 to version 1.2 as an example, calculating a hash value of a synthetic result of data (unchanged data from version 1.1 to version 1.2) which does not need to be upgraded in the dynamic partition (Super) and upgrading data (data which needs to be upgraded from version 1.1 to version 1.2) in the cow file, judging whether the hash value is consistent with the hash value of the complete data of the dynamic partition (Super) in version 1.2, and if so, indicating that the cow file is valid; if the update progress is inconsistent, the cow file is invalid, the update fails, the update progress is interrupted, and an error is reported; wherein, the hash value of the complete data of the dynamic partition (Super) in version 1.2 is stored in the upgrade package.

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

For example, a System sub-partition File map "/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. "merge".

A new version of the file map for the System child partition is obtained:

system/app/a0.Xxx:024010 ～ 024013 (A0.XXX pointing to in dynamic partition (Super)/under system/app);

system/app/a1.Xxx:024014 ～ 024017 (A1.XXX pointing to in dynamic partitioning (Super)/under system/app);

System/app/a2.Xxx:045033 ～ 045035 (A2.XXX in user data partition (Userdata)/Update/system_b-cow-img.img.0000);

system/b0.Xxx:024021 ～ 024026 (B0.XXX in the sense of dynamic partitioning (Super)/under system);

system/b1.Xxx:024027 ～ 024028 (directed to b1.Xxx in dynamic partitioning (Super)/under system);

system/user/C0.XXX:024029 ～ 024032 (C0.XXX pointing to dynamic partitioning (Super)/system/user);

system/user/C1.XXX:024033 ～ 024035 (C1.XXX pointing to dynamic partitioning (Super)/system/user);

system/user/c2.Xxx:045036 ～ 045040 (directed to c2.Xxx in user data partition (Userdata)/Update/system_b-cow-img. 0000);

system/user/c3.Xxx:024041 ～ 024044 (directed to C3.XXX in dynamic partitioning (Super)/system/user).

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

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

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

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

S407, the upgrade engine changes the starting sequence of the electronic device from the first static partition starting to the second static partition starting.

For example, the boot sequence identifier of the master boot record (Master Boot Record, MBR) is rewritten, and the boot sequence identifier is rewritten from a to B. After the electronic equipment is powered on, when the electronic equipment reads that the starting sequence identifier is A, the electronic equipment starts from the first static partition (SlotA in the drawing), and the data of the first static partition (SlotA in the drawing) is loaded in the starting process; when the electronic equipment reads the starting sequence identifier as B, the electronic equipment starts from the second static partition (SlotB), and data of the second static partition (SlotB) are loaded in the starting process.

S408, the system upgrade client triggers the electronic equipment to restart.

The system upgrade client may exit the current first operating system when the electronic device is triggered to restart, cut off the power supply of the electronic device, and then turn on the power supply of the electronic device.

S409, the electronic device loads the data of the basic partition, the data of the second static partition and the data of the dynamic partition in sequence, and the data in the cow file in the user data partition is started from the second static partition to run the second operating system.

Illustratively, the electronic device first loads data of a base partition (Common), and in the process of loading the base partition (Common), the electronic device reads a start mark in the base partition (Common); when the boot flag in the base partition (Common) is (a), the device will load the first static partition (SlotA) after loading the base partition (Common), thereby booting from the first static partition (SlotA); when the boot flag in the base partition (Common) is (B), the electronic device loads the second static partition (SlotB) after loading the base partition (Common), thereby booting from the second static partition (SlotB).

In S409, the electronic device reads a start flag in the base partition (Common). The boot-up in the base partition (Common) is labeled (B), and the electronic device loads the second static partition (SlotB) after loading the base partition (Common), from which it boots up.

For example, when the electronic device loads the data in the cow file of the dynamic partition (Super) and the user data partition (Userdata) after loading the data of the second static partition (SlotB), the specific steps are: the electronic device reads the landing status information in the metadata (/ metadata), determines whether a cow file needs to be retrieved from a designated path of a user data partition (Userdata) based on the landing status information, and loads a dynamic partition (Super) and the cow file by adopting a snapshot merge.

Further, in step S409, the electronic device does not load all the cow files in the dynamic partition (Super) and the user data partition (Userdata), but loads the corresponding files according to the running requirement of the second operating system. Specifically, in step S409, the electronic device determines the files to be loaded according to the running requirement of the second operating system, and extracts the corresponding files from the cow files of the dynamic partition (Super) or the user data partition based on the snapshot, and loads the files.

Specifically, in step S409, when the sub-partition header of the dynamic partition (Super) has a corresponding cow file, a new version of the file map of each sub-partition of the dynamic partition (Super) is generated based on the snapshot. The process of generating the new version of the file map may refer to step S405. And the electronic equipment determines the files to be loaded according to the running requirement of the second operating system, and loads the files based on the file map of the new version of the dynamic partition (Super) sub-partition.

For example, the second operating System running requirements load all data in the under-System sub-partition directory user (/ System/user). The electronic device reads the disk-drop status information in the metadata (/ metadata), and the sub-partition of the System sub-partition in the disk-drop status information is identified as "no disk for Merge", so that the electronic device searches the cow file in the user data partition (Userdata) under Update, searches the cow file system_b-cow-img.0000 under Update, and then generates a new version of the file map of the System sub-partition according to the file map of the cow file in the system_b-cow-img.img.0000 based on the snapshot. Data loading is performed according to the storage addresses of all files in the file map of the new version of the System sub-partition/under the System/user, for example, according to the file map of the new version of the System sub-partition:

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

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

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

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

C0.xxx at address 024029 ～ 024032, c1.xxx at address 024033 ～ 024035, c2.xxx at address 045036 ～ 045040, and c3.xxx at address 024041 ～ 024044 are loaded.

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

Further, when all data in the directory user (/ System/user) under the System sub-partition is loaded, when the sub-partition identifier of the System sub-partition in the drop state information is "no drop (wait for Merge)", if the electronic device does not search the cow file corresponding to the System sub-partition in the user data partition (Userdata) or under the Update, it indicates a data writing error (cow file writing error or drop state information writing error) in the upgrading process, and at this time, the electronic device rolls back to the first operating System and reports log information of the upgrading failure to the OTA server.

Furthermore, in the process of loading data in the cow files of the dynamic partition (Super) and the user data partition (Userdata), the electronic device further needs to verify the loaded files before loading the files. Unlike step S406, in step S409, the dynamic partition (Super) +cow file is not authenticated as a whole, but only the file to be loaded. For example, checking is performed based on dm-quality (dm-quality is a target of dm (device mapper), which is a virtual block electronic device, specifically used for checking of file systems). And loading the file if the verification is successful, restarting the electronic equipment if the verification is failed, and rolling back to the first operating system or attempting to load the file again.

S410, the electronic equipment is successfully started and enters a user interaction interface.

S411, the kernel executes the Merge operation, and the data in the cow file is dropped to the sub-partition corresponding to the dynamic partition.

It can be understood that in the present application, the Merge operation specifically refers to writing a dynamic partition (Super) upgrade file (cow file) stored in a user data partition (Userdata) into a dynamic partition (Super) during an upgrade process of an operating system, so that the file of the dynamic partition (Super) completes data upgrade, so that the electronic device does not need to load the dynamic partition (Super) and the cow file of the user data partition when being started next time, and can complete the startup of the electronic device only by loading the dynamic partition (Super).

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

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

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

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

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

In step S403, the data operation of the static partition upgrade is for the operating system data in the second static partition (SlotB), which does not affect the operating system data of the first static partition (SlotA in the above figures) that is currently started; also, in step S405, the data operation of the dynamic partition upgrade is completed on the virtual dynamic partition created in the user data partition (Userdata), which does not affect the currently mounted dynamic partition (Super). Therefore, in the whole operating system upgrading process, the user can normally use the electronic equipment; after step S406 is completed, the electronic device does not need to be restarted immediately, and the user can select the restart time by himself; therefore, the upgrading process of the operating system does not influence the normal mobile phone operation of the user, so that the user experience is greatly improved. Further, for the dynamic partition (Super), a virtual dynamic partition is created on the user data partition (Userdata) only when the user data partition (Userdata) needs to be updated, so that the data storage space utilization rate is effectively improved.

And S412, the kernel synchronizes the data of the second static partition to the first static partition.

Based on the upgrade procedure, assuming that the first static partition (SlotA) corresponds to the operating system of version 1.1, the electronic device starts up to run the operating system of version 1.1 from the first static partition (SlotA); when the operating system is upgraded to 1.2, the electronic equipment starts the operating system with the running version 1.2 from a second static partition (SlotB) after restarting; at this point, the electronic device runs version 1.2 of the operating system. The first static partition (SlotA) corresponds to version 1.1 of the operating system and the second static partition (SlotB) corresponds to version 1.2 of the operating system, the data in the first static partition (SlotA) being inconsistent with the data in the second static partition (SlotB). Assuming that the second static partition (SlotB) has an error, the first static partition (SlotA) cannot replace the function of the second static partition (SlotB), i.e., the first static partition (SlotA) cannot support the electronic device to run the operating system of version 1.2. However, if data is consistently maintained between the first static partition (SlotA) and the second static partition (SlotB), then the other static partition may be used when either the first static partition (SlotA) or the second static partition (SlotB) is in error.

Therefore, after the Merge operation is completed, the partition synchronization is performed on the static partition, that is, the data are mutually backed up between the first static partition (SlotA) and the second static partition (SlotB), so that the data in the first static partition (SlotA) and the data in the second static partition (SlotB) are kept consistent, and the technical problem can be solved.

Details of the specific implementation of the kernel to synchronize the data of the second static partition to the first static partition are described above with respect to the text of step S116 in fig. 8, and are not repeated here.

In addition, it should be noted that, in an actual application scenario, the method for upgrading an operating system provided in each embodiment implemented by an electronic device may also be performed by a chip system included in the electronic device, where the chip system may include a processing circuit, a receiving pin, and a transmitting pin, where the receiving pin, the transmitting pin, and the processing circuit communicate with each other through an internal connection path. The processing circuit is coupled to the memory such that the system-on-chip invokes the computer program stored in the memory to implement the steps performed by the electronic device.

In addition, it should be noted that the processing circuit in the chip system may be an application processor or a non-application processor.

In addition, an embodiment of the present application further provides a computer readable storage medium, where computer instructions are stored, and when the computer instructions are executed on an electronic device, the electronic device is caused to execute the related method steps to implement the method for upgrading an operating system in the foregoing embodiment.

In addition, the embodiment of the application also provides a computer program product, when the computer program product runs on the electronic equipment, the electronic equipment is caused to execute the related steps so as to realize the upgrading method of the operating system in the embodiment.

In addition, as can be seen from the above description, the electronic device, the computer readable storage medium, the computer program product, and the chip provided by the embodiments of the present application are used to execute the corresponding methods provided above, so that the advantages achieved by the method can be referred to the advantages in the corresponding methods provided above, and are not repeated herein.

The above embodiments are only for illustrating the technical solution of the present application, and not for limiting the same; although the application has been described in detail with reference to the foregoing embodiments, it will be understood by those of ordinary skill in the art that: the technical scheme described in the foregoing embodiments can be modified or some technical features thereof can be replaced by equivalents; such modifications and substitutions do not depart from the spirit of the application.

Claims

1. The method for upgrading the operating system is characterized by being applied to electronic equipment, wherein 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, the electronic equipment is started and then loads data of the basic partition, data of the first static partition and data of the dynamic partition in sequence to run a first operating system, and after the first operating system is run, the method further comprises the steps of:

upgrading the second static partition according to the first upgrade file;

after the second static partition is upgraded, in the process of checking the second static partition, upgrading the dynamic partition according to a second upgrading file;

stopping executing the step of upgrading the dynamic partition according to the second upgrading file when the second static partition fails to be checked;

and when the second static partition is successfully checked, continuing to execute the step of upgrading the dynamic partition according to the second upgrading file.

2. The method of claim 1, wherein after the second static partition is upgraded, in the process of verifying the second static partition, upgrading the dynamic partition according to a second upgrade file comprises:

After the second static partition is upgraded, starting a static partition checking thread, wherein the static partition checking thread is used for checking the second static partition;

and upgrading the dynamic partition according to the second upgrading file in the process of verifying the second static partition by the static partition verification thread.

3. The method of claim 2, wherein the static partition verification thread verifies the second static partition, comprising:

the static partition checking thread checks each sub-partition in the second static partition;

for each sub-partition, when the verification is successful, the static partition verification thread modifies the verification state corresponding to the second static partition into a first state, and when the verification is failed, the static partition verification thread modifies the verification state corresponding to the second static partition into a second state, wherein the first state is used for indicating that the sub-partition verification is successful, and the second state is used for indicating that the sub-partition verification is failed.

4. The method of claim 3, wherein after the static partition check thread modifies the check state corresponding to the second static partition to the first state, the method further comprises:

And after all the sub-partitions of the second static partition are checked, ending the check of the second static partition.

5. A method according to claim 3, characterized in that the method further comprises:

acquiring a verification state corresponding to the second static partition in the process of upgrading the dynamic partition according to the second upgrading file;

and stopping executing the step of upgrading the dynamic partition according to the second upgrade file when the second static partition fails to check, wherein the step comprises the following steps:

stopping executing the step of upgrading the dynamic partition according to a second upgrading file when the verification state corresponding to the second static partition is the second state;

and when the second static partition is successfully checked, continuing to execute the step of upgrading the dynamic partition according to a second upgrading file, wherein the step comprises the following steps:

and when the check state corresponding to the second static partition is the first state, continuing to execute the step of upgrading the dynamic partition according to the second upgrading file.

6. The method of claim 5, wherein said updating said dynamic partition according to a second upgrade file during said verifying said second static partition comprises:

Copy the cow file when writing of the sub-partition corresponding to the second upgrade file is created in the user data partition according to the second upgrade file;

and writing the second upgrading file into the cow file.

7. The method of claim 6, wherein the obtaining the check state corresponding to the second static partition during the process of upgrading the dynamic partition according to the second upgrade file comprises:

judging whether first data are written into the cow file or not in the process of writing the second upgrading file into the cow file, wherein the first data are part of data in the second upgrading file;

and when the first data is written into the cow file, acquiring a verification state corresponding to the second static partition.

8. The method of claim 6, wherein the method further comprises:

when the verification state is the first state, judging whether the second upgrade file is completely written into the cow file or not;

when the second upgrade file is completely written into the cow file, checking the dynamic partition;

and when the second upgrading file is not completely written into the cow file, writing the data, which is not written into the cow file, in the second upgrading file into the cow file.

9. The method of claim 8, wherein after said verifying said dynamic partition, said method further comprises:

restarting the electronic equipment to sequentially load the data of the basic partition, the data of the second static partition, the data of the dynamic partition and the data of the cow file so as to run a second operating system;

the data in the cow file is dropped into the corresponding sub-partition in the dynamic partition;

and synchronizing the data of the second static partition to the first static partition.

10. The method of claim 7, wherein the method further comprises:

and when the first data is not written into the cow file, continuing to write the second upgrading file into the cow file.

11. The method according to any one of claims 1 to 10, further comprising:

in the process of upgrading the second static partition according to the first upgrading file and the dynamic partition according to the second upgrading file, breakpoint information is recorded in a breakpoint record file, and a breakpoint identified by the breakpoint information is a position continuously upgraded after restarting the electronic equipment;

After the electronic equipment is powered down and restarted, determining a partition which is continuously updated according to breakpoint information recorded in the breakpoint recording file;

when the partition which is continuously updated is determined to be the second static partition, reading data from the position of the breakpoint marked by the breakpoint information in the first updating file according to the breakpoint information, and updating the second static partition according to the read data;

restarting the static partition checking thread after the second static partition is upgraded;

12. The method of claim 11, wherein the method further comprises:

restarting the static partition checking thread when determining that the partition which is updated continuously is the dynamic partition;

and in the process of checking the second static partition by the static partition checking thread, reading data from the position of the breakpoint marked by the breakpoint information in the second upgrading file according to the breakpoint information, and upgrading the dynamic partition according to the read data.

13. The method according to any one of claims 1 to 10, further comprising:

And after the dynamic partition is upgraded according to the second upgrading file, checking the dynamic partition, and not checking the second static partition.

14. The electronic equipment is characterized by comprising a processor and a memory, wherein the memory comprises a basic partition, a first static partition, a second static partition, a dynamic partition and a user data partition, and the electronic equipment is started and then sequentially loads data of the basic partition, data of the first static partition and data of the dynamic partition to run a first operating system;

wherein the memory is coupled to the processor, the memory storing program instructions;

the program instructions, when executed by the processor, cause the electronic device to perform the method of upgrading an operating system according to any one of claims 1 to 13.

15. A computer readable storage medium comprising a computer program, characterized in that the computer program, when run on an electronic device, causes the electronic device to perform the method of upgrading an operating system according to any of claims 1-13.