CN113868156B

CN113868156B - System upgrade power-down protection method, electronic device and storage medium

Info

Publication number: CN113868156B
Application number: CN202111451284.2A
Authority: CN
Inventors: 武国平; 陈超
Original assignee: Honor Device Co Ltd
Current assignee: Honor Device Co Ltd
Priority date: 2021-12-01
Filing date: 2021-12-01
Publication date: 2022-04-12
Anticipated expiration: 2041-12-01
Also published as: CN113868156A

Abstract

The application provides a system upgrading power failure protection method, electronic equipment and a storage medium. The method comprises the steps of introducing a forced restart detection thread, utilizing the forced restart detection thread to detect whether the electronic equipment is forcibly restarted or not in real time when an upgrade file in a downloaded upgrade installation package is written into a user data partition by means of a kernel cache, and executing forced disk dropping when the electronic equipment is detected to be forcibly restarted, so that continuous upgrade can be successfully carried out after the electronic equipment is restarted.

Description

System upgrade power-down protection method, electronic device and storage medium

Technical Field

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

Background

As the number of applications that can be installed in the electronic device increases, the storage space occupied by the user data is more and more required. At present, electronic devices of a Virtual AB system (Virtual AB) are becoming more and more popular in order to ensure success of system upgrade and reduce occupation of system data on a storage space as much as possible, so as to reserve more storage space for storing user data. Due to the partition structure of the virtual AB system, a dynamic partition (Surper partition) needing to be upgraded in the system upgrading process exists in a single partition mode, so that in the system upgrading process, an upgrade file needs to be written into a user data partition (Userdata partition) first, and when the electronic equipment is restarted, the upgrade file is read from the user data partition and is landed into a first sub-partition corresponding to the dynamic partition. In the process of writing the upgrade file into the user data partition, the kernel cache is needed, that is, the data of the upgrade file is written into the kernel cache in units of blocks (blocks), and then is destaged from the kernel cache to the user data partition in units of blocks.

For the electronic device of the virtual AB system, if a user presses a Power key for a long time to forcibly restart (Power down restart) the electronic device during system upgrade, part of data that needs to be landed in a user data partition may still be stored in a kernel cache, that is, the data is not actually landed in the user data partition. But the progress of the recording in the breakpoint record file indicates that the portion of data has been landed on the user data partition. And after the electronic equipment is restarted, the electronic equipment can be continuously upgraded according to the progress recorded by the breakpoint recording file, so that the data which is not really landed to the user data partition before power failure can be lost. Due to data loss, verification failure occurs when integrity verification is performed after the system upgrade installation package is installed, and system upgrade failure is further caused.

Disclosure of Invention

In order to solve the technical problems, the application provides a system upgrade power-down protection method, an electronic device and a storage medium, and aims to enable the progress recorded in a breakpoint recording file to be consistent with the progress of actual disk-dropping to a user data partition when the electronic device of a virtual AB system is powered down during system upgrade, so that the system upgrade can be normally completed after the electronic device is restarted.

In a first aspect, the present application provides a system upgrade power-down protection method, which is 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, the dynamic partition includes a plurality of sub-partitions, the electronic device loads data of the base partition, data of the first static partition, and data of the dynamic partition in sequence after being started to run a first operating system, and after the operating system runs, the method further includes: downloading an upgrade installation package, wherein the upgrade installation package comprises an upgrade file, the upgrade file corresponds to a first sub-partition, and the first sub-partition is a sub-partition of the dynamic partition; after the upgrade installation package is successfully downloaded, a forced restart detection thread is established, and the forced restart detection thread is used for detecting whether the electronic equipment is forcibly restarted or not; creating a virtual dynamic partition in the user data partition corresponding to the first child partition; and in the process of writing the data of the upgrade file into the virtual dynamic partition, when the forced restart detection thread detects that the electronic equipment is forcibly restarted, forcibly dropping the data. Therefore, when the upgrade file is written into the user data partition by means of the kernel cache, whether the electronic equipment is forcibly restarted or not is detected in real time by using the forced restart detection thread, and forced disk-dropping operation is executed when the electronic equipment is detected to be forcibly restarted, so that continuous upgrade can be successfully carried out after the electronic equipment is restarted.

According to the first aspect, in the writing of the data of the upgrade file to the virtual dynamic partition, the method further includes: recording breakpoint information into a breakpoint recording file; wherein, when the forced restart detection thread detects that the electronic device is forced to be restarted, the method further comprises: and forcibly dropping the disk for the breakpoint information. In this way, in the process of writing the data of the upgrade file into the virtual dynamic partition, the writing operation of the breakpoint information is simultaneously performed on the breakpoint record file stored in the user data partition, and when the forced restart detection thread detects that the electronic device is forcibly restarted, the forced disk-dropping operation is also performed on the breakpoint information, so that the data dropped to the virtual dynamic partition, namely the actual upgrade progress is consistent with the upgrade progress of the breakpoint information identifier recorded by the breakpoint record file, is ensured.

According to the first aspect, or any implementation manner of the first aspect, the writing the data of the upgrade file into the virtual dynamic partition, and recording breakpoint information into a breakpoint record file includes: the kernel sequentially saves the data of the upgrade file to a kernel cache, generates the breakpoint information and saves the breakpoint information to the kernel cache; and when the synchronization condition is met, the kernel synchronizes the data to be landed in the kernel cache to the virtual dynamic partition, and synchronizes the breakpoint information in the kernel cache to the breakpoint record file.

Illustratively, the synchronization condition is a preset time interval, for example, 5 seconds.

Illustratively, the synchronization condition is a preset proportion, for example, the data cached in the kernel cache reaches 50%.

Therefore, data are read from the kernel cache in batch and are landed to the user data partition in a timing or quantitative mode, so that the data of the upgrade file can be written into the user data partition, the reading operation of the kernel cache is reduced, and the occupation and waste of resources of the electronic equipment are avoided.

According to the first aspect, or any implementation manner of the first aspect, the storing, by the kernel, the data of the upgrade file to a kernel cache in sequence, and generating the breakpoint information to store to the kernel cache includes: the kernel sequentially stores the data of the upgrade files to a kernel cache; and after the kernel stores the data of the upgrade file into the kernel cache, the kernel generates breakpoint information for storing the data of the upgrade file into the kernel cache next time, and stores the breakpoint information into the kernel cache. Therefore, after the data of each operation is written into the kernel cache, the breakpoint identified by the breakpoint information is modified to the position of the data needing to be written into the kernel cache corresponding to the next operation, so that the electronic equipment can know the position of the next write data according to the breakpoint information, and the access writing of the upgraded file after the restart is realized.

According to the first aspect, or any implementation manner of the first aspect, when the forcible restart detection thread detects that the electronic device is forcibly restarted, forcibly dropping the disk for the data and forcibly dropping the disk for the breakpoint information includes: when the forced restart detection thread detects that the electronic equipment is forcibly restarted, the forced restart detection thread informs an upgrade engine that the electronic equipment is to be forcibly restarted; the upgrading engine sends a forced disk-dropping instruction to the kernel; and the kernel synchronizes the data to be landed in the kernel cache to the virtual dynamic partition, and synchronizes the breakpoint information in the kernel cache to the breakpoint record file. Therefore, when the electronic equipment is detected to be forcibly restarted, the forced disk-dropping operation is executed no matter whether the synchronization condition is met or not at present, so that the data which are not dropped to the user data partition in the kernel cache and the breakpoint information can be synchronized to the user data before the electronic equipment enters the forced restart mode, and further the data which are not dropped to the user data partition after the power-off restart and the breakpoint information are lost, and the subsequent continuous upgrading failure is caused.

According to the first aspect, or any implementation manner of the first aspect, the electronic device is forcibly restarted through a power key; the forced restart detection thread detects that the electronic device is forced to be restarted, and comprises the following steps: when the forced restart detection thread detects that the power key is pressed, recording a first duration of the pressed power key; when the first time length is larger than a first time length threshold value, the forced restart detection thread determines that the electronic equipment is forcibly restarted; and when the first time length is not larger than a first time length threshold value, continuing to execute the step of writing the data of the upgrade file into the virtual dynamic partition. Therefore, the data writing to the kernel cache is stopped when the pressed time length of the power key is greater than the preset first time length threshold value, and the operation of forcibly dropping the data in the kernel cache to the user data partition is executed, so that the situation that a user mistakenly touches the power key and the electronic equipment is considered to be restarted by mistake when the power key is pressed instantly, and then the operation of forcibly dropping the data cached in the kernel cache to the user data partition is frequently executed is avoided, the unnecessary reading operation of the kernel cache is further reduced, and the occupation and waste of resources of the electronic equipment are reduced.

According to the first aspect, or any implementation manner of the first aspect, in the writing of the data of the upgrade file into the virtual dynamic partition, after the forced restart detection thread detects that the electronic device is forcibly restarted, and the data is forcibly landed, the method further includes: when the forced restart detection thread detects that the pressing of the power key is stopped, determining a second duration for which the power key is pressed; when the second duration is smaller than a second duration threshold, continuing to execute the step of writing the data of the upgrade file into the virtual dynamic partition; and restarting the electronic equipment when the second duration is not less than the second duration threshold.

Illustratively, the second duration threshold is a duration of pressing required when the electronic device is restarted after forced power-off, for example, 5 seconds.

Therefore, when the pressing time of the power key is less than the second time threshold value, namely the electronic equipment cannot execute the restarting operation, the residual data in the upgrading file is continuously written into the user data partition by means of the kernel cache, so that the protection of the electronic equipment when the power failure occurs is achieved, and the upgrading operation can be continuously carried out when the power failure does not occur.

According to a first aspect or any one of the above implementation manners of the first aspect, after the restarting the electronic device, the method further includes: reading data from the position of the breakpoint identified by the breakpoint information in the upgrade file according to the breakpoint information recorded in the breakpoint recording file, storing the read data to the kernel cache, and generating and storing the breakpoint information to the kernel cache; and when the synchronization condition is met, the kernel synchronizes the data to be landed in the kernel cache to the virtual dynamic partition, and synchronizes the breakpoint information in the kernel cache to the breakpoint record. Since the data in the kernel cache is forcibly landed to the user data partition before power failure, the upgrading progress recorded by the breakpoint recording file is consistent with the actual upgrading progress, and therefore, after the electronic equipment is restarted, the operation of writing the data of the upgrading file into the user data partition by means of the kernel cache is executed from the breakpoint identified by the breakpoint information recorded by the breakpoint recording file, so that the data of the upgrading file finally written into the user data partition can be ensured not to be missed, and the success of continuous upgrading is ensured.

According to the first aspect as such or any one of the above implementations of the first aspect, the method further comprises: after all the data in the upgrade file are written into the virtual dynamic partition, carrying out integrity check on the data in the virtual dynamic partition; after the verification is successful, the starting sequence of the electronic equipment is changed from starting from the first static partition to starting from the second static partition; restarting the electronic equipment, and sequentially loading the data of the basic partition, the data of the second static partition and the data of the dynamic partition to run a second operating system; wherein the loading the data of the dynamic partition comprises: loading data of other sub-partitions except the first sub-partition in the dynamic partition, and loading an upgrade file stored in the virtual dynamic partition in the user data partition; and the upgrading file is landed to a first sub-partition of the dynamic partition.

According to the first aspect, or any implementation manner of the first aspect, before creating a forced restart detection thread after the upgrade installation package is successfully downloaded, the method further includes: carrying out integrity check on the upgrade installation package; and after the verification is successful, executing the step of creating the forced restart detection thread. Therefore, the electronic equipment is restarted after the integrity verification is successful by introducing the integrity verification step, so that the electronic equipment can be successfully operated to the second operating system after being restarted.

In a second aspect, the present application provides an electronic device, where the electronic device includes a processor and a memory, where the memory includes a base partition, a first static partition, a second static partition, a dynamic partition, and a user data partition, and 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; 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 first aspect or the instructions of the method in any of the implementations of the first aspect above.

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

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

In a fifth aspect, the present application provides a chip comprising a processing circuit, a transceiver pin. Wherein the transceiver pin and the processing circuit are in communication with each other via an internal connection path, and the processing circuit executes instructions of the method of the first aspect or any one of the above implementations of the first aspect to control the receiving pin to receive signals and to control the sending pin to send signals.

Drawings

Fig. 1 is a schematic diagram illustrating a hardware configuration of an electronic device;

FIG. 2 is a schematic diagram illustrating the structural division of the internal memory [121 ];

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

FIG. 4 is a schematic diagram of a software architecture of an exemplary electronic device;

FIG. 5 is a schematic diagram illustrating sequential loading of partitions when an electronic device is booted by a first static partition;

FIG. 6 is one of schematic flowcharts schematically illustrating a system upgrade power-down protection method provided by an embodiment of the present application;

fig. 7 is a second schematic flowchart illustrating a system upgrade power-down protection method provided by an embodiment of the present application;

FIG. 8 is an exemplary interaction diagram illustrating a side-to-side and server-to-side interaction in obtaining an upgrade installation package;

FIG. 9 is a schematic diagram illustrating a variation of data partitioning of the read-only memory [121B ] after implementing step S201 illustrated in FIG. 7;

FIG. 10 is a diagram illustrating a variation of the data partition of the read-only memory [121B ] after implementing step S204 shown in FIG. 7;

FIG. 11 is a schematic diagram illustrating the writing of data and breakpoint information of an upgrade file to a user data partition via kernel caching;

FIG. 12 is a schematic diagram illustrating changes of a kernel cache, a virtual dynamic partition in a user data partition, and a breakpoint record file when an upgrade file is written into the user data partition via the kernel cache;

FIG. 13 is a second schematic diagram illustrating changes of the kernel cache, the virtual dynamic partition in the user data partition, and the breakpoint record file when the upgrade file is written into the user data partition by the kernel cache;

FIG. 14 is a third exemplary diagram illustrating changes of the kernel cache, the virtual dynamic partition in the user data partition, and the breakpoint record file when the upgrade file is written into the user data partition via the kernel cache;

FIG. 15 is a fourth exemplary diagram illustrating changes of the kernel cache, the virtual dynamic partition in the user data partition, and the breakpoint record file when the upgrade file is written into the user data partition via the kernel cache;

FIG. 16 is a fifth exemplary diagram illustrating changes of a kernel cache, a virtual dynamic partition in a user data partition, and a breakpoint record file when an upgrade file is written into the user data partition via the kernel cache;

fig. 17 is a sixth schematic diagram illustrating changes of the kernel cache, the virtual dynamic partition in the user data partition, and the breakpoint record file when the upgrade file is written into the user data partition by the kernel cache;

FIG. 18 is a seventh exemplary diagram illustrating changes of the kernel cache, the virtual dynamic partition in the user data partition, and the breakpoint record file when the upgrade file is written into the user data partition via the kernel cache;

FIG. 19 is an eighth exemplary diagram illustrating changes in the kernel cache, the virtual dynamic partition in the user data partition, and the breakpoint record file when the upgrade file is written into the user data partition via the kernel cache;

FIG. 20 is a schematic diagram illustrating an exemplary scenario for a download from upgrade installation package to Merge process when an operating system is upgraded;

FIG. 21 is a diagram illustrating sequential loading of partitions when an electronic device is booted from a second static partition when the electronic device is rebooted after successful installation of an upgrade installation package;

FIG. 22 is a diagram illustrating an example of sequentially loading partitions and performing a Merge process when an electronic device is booted by a second static partition;

FIG. 23 is a schematic diagram of an exemplary illustrated Merge process;

FIG. 24 is a diagram illustrating an example dynamic partition after a change after a Merge operation has been performed;

fig. 25 is a third exemplary flowchart illustrating a system upgrade power-down protection method provided in an embodiment of the present application;

fig. 26 is a fourth schematic flowchart illustrating a system upgrade power down protection method provided by an embodiment of the present application;

fig. 27 is a fifth exemplary flowchart illustrating a system upgrade power down protection method according to an embodiment of the present application.

Detailed Description

The technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the drawings in the embodiments of the present application, and it is obvious that the described embodiments are some, but not all, embodiments of the present application. All other embodiments, which can be derived by a person skilled in the art from the embodiments given herein without making any creative effort, shall fall within the protection scope of the present application.

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

The terms "first," "second," and the like in the description and in the claims of the embodiments of the present application are used for distinguishing between different objects and not for describing a particular order of the objects. For example, the target object and the second target object, etc. are specific sequences for distinguishing different target objects, rather than describing the target objects.

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

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

In order to better understand the technical solutions provided by the embodiments of the present application, before describing the technical solutions of the embodiments of the present application, first, a hardware structure of an electronic device (e.g., a mobile phone, a tablet electronic device, a PC electronic device, etc.) applicable to the embodiments of the present application is described with reference to the drawings.

Referring to fig. 1, the electronic device 100 may include: the mobile terminal includes a processor 110, an external memory interface 120, an internal memory 121, a Universal Serial Bus (USB) interface 130, a charging management module 140, a power management module 141, a battery 142, an antenna 1, an antenna 2, a mobile communication module 150, a wireless communication module 160, an audio module 170, a sensor module 180, a button 190, a motor 191, an indicator 192, a camera 193, a display screen 194, a Subscriber Identity Module (SIM) card interface 195, and the like.

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

For example, the sensor module 180 may include a pressure sensor, a gyroscope sensor, an air pressure sensor, a magnetic sensor, an acceleration sensor, a distance sensor, a proximity light 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 touch keys. The electronic apparatus 100 may receive a key input, and generate a key signal input related to user setting and function control of the electronic apparatus 100.

Specifically, in the technical solution provided in the embodiment of the present application, whether to stop writing the data of the upgrade file into the kernel cache (in the random access memory), and to force the data written into the kernel cache to be landed in the user data partition is determined by a detection result of an introduced forced restart detection thread on whether the electronic device is forcibly restarted.

Further, processor 110 may include one or more processing units, such as: the processor 110 may include an Application Processor (AP), a modem processor, a Graphics Processing Unit (GPU), an Image Signal Processor (ISP), a controller, a memory, a video codec, a Digital Signal Processor (DSP), a baseband processor, and/or a neural-Network Processing Unit (NPU), etc.

It is to be appreciated that in particular implementations, the various processing units may be stand-alone devices or may be integrated into one or more processors.

Further, in some embodiments, the controller may be a neural hub and a command center of the electronic device 100. The controller can generate an operation control signal according to the instruction operation code and the timing signal to complete the control of instruction fetching and instruction execution.

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

Furthermore, it will be appreciated that in a practical application scenario, executable program code, including instructions, that trigger the electronic device 100 to implement various functional applications and data processing is stored in the internal memory 121.

For example, specifically, in the technical solution provided in the embodiment of the present application, the starting of the electronic device 100 and the upgrading of the upgrade installation package mainly involve the internal memory 121, that is, relevant instructions for implementing the system upgrade power-down protection method provided in the embodiment of the present application are stored in the internal memory 121 in advance, and the processor 110 executes the instructions stored in the internal memory 121, so that the electronic device 100 can execute the system upgrade power-down protection method provided in the embodiment of the present application.

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 partition structure of the read-only memory 121A may be divided into three different partitions, i.e., a non-AB system, an AB system, and a virtual AB system.

It can be understood that, in practical applications, a Random Access Memory (RAM), also called "main Memory", can be read and written at any time, is fast, and is usually used as a temporary data storage medium for an operating system or other programs in operation, and when the power is turned off, the RAM cannot retain data, that is, temporary data during the operation of the electronic device is usually stored in the Random Access Memory 121B; the Read-Only Memory (ROM), which may also be referred to as a "nonvolatile Memory," is used to store data that is written in advance before being loaded into the whole device, such as an image file of an operating system and user data generated when a user uses an electronic device.

In summary, the biggest difference between RAM and ROM is that data stored in RAM will disappear automatically after power is off, while ROM will not disappear automatically, and can be stored for a long time after power is off. In the upgrading process of the existing operating system, the upgrading file needs to be written by means of kernel cache, so that when the electronic equipment is powered off, data which is not written into the ROM in the RAM is lost, and the upgrading file which is continuously written after the electronic equipment is restarted is incomplete, so that the upgrading of the operating system fails. Therefore, the technical scheme provided by the embodiment of the application is provided for solving the problem caused by power failure/power failure in the existing upgrading process.

In practical applications, the read-only memory 121A may be, for example, a magnetic disk storage device, a flash memory device, a universal flash memory (UFS), or the like; 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 program storage area and a data storage area. The storage program area may store an operating system, an application program (such as a sound playing function, an image playing function, etc.) required by at least one function, and the like. The storage data area may store data (such as audio data, phone book, etc.) created during use of the electronic device 100, and the like.

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

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, and the partition structure of different systems may be different in practical applications.

Specifically, based on the characteristics of the above four partitions, for the partitions that do not need to be upgraded in the operating system upgrade, such as the base partition and the user data partition, a single partition is adopted in both the non-AB system, the AB system, and the virtual AB system, and the partitions that need to be upgraded are different.

For example, since the operating system is upgraded in the non-AB system, other functions of the electronic device cannot be used in the upgrading process, the electronic device can only stay on the upgrading interface of the non-AB system, and the user interface can be accessed for normal use after the electronic device is restarted after the operating system is upgraded. Therefore, in the non-AB system, the static partition and the dynamic partition also adopt a single partition, and in detail, see the structural diagram of the non-AB system partition shown in (1) in fig. 3, so that the occupation of the memory space can be reduced to reserve more space for the user data partition.

The AB system is for the user to return to the main interface of the electronic device at will during the process of upgrading the operating system of the electronic device, so as not to affect the use of the electronic device. Therefore, under the AB system, the static partition and the dynamic partition adopt dual partitions, and see the AB system partition structure diagram shown in (2) in fig. 3 in detail, the static partition may be divided into a first static partition (SlotA) and a second static partition (SlotB), for example, and the dynamic partition may be divided into a first dynamic partition (SuperA) and a second dynamic partition (SuperB), for example. Although the partition partitioning mode can enable the electronic device to return to the main interface of the electronic device arbitrarily in the process of upgrading the operating system, the partition partitioning mode occupies a large space of a memory, so that the available space of a user data partition is greatly reduced.

Illustratively, the virtual AB system combines the advantages of the non-AB system and the AB system, divides a static partition with a small storage size, i.e. occupying a small memory space, into a first static partition (SlotA) and a second static partition (SlotB), and adopts a single partition with a dynamic partition with a large storage size, i.e. occupying a large memory space, as shown in the schematic diagram of the partition structure of the virtual AB system shown in (3) in fig. 3.

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

TABLE 1 Subdivision table

Partitioning	Name (Name)	Size (Size)	start address-End address（Start address-end address)
				0	GPT (general area of electronic equipment)		0x0000 0000-0x000000FF
1	x-loader	256KB	0x00000100-0x0000XXX
				2	Bootloader (starting loading program)	600KB	0x00000XXX-0x0000XXXX
3	Boot (starting program)	32MB	0x0000 XXXX -0x0000 XXXX
				4	SlotA (first static partition)	128MB	0x0000 XXXX -0x0000 XXXX
5	SlotB (second static partition)	128M	0x0000 XXXX -0x0000 XXXX
				5	Super (dynamic zone)	8GB	0x0000 XXXX -0x0000 XXXX
6	Userdata (user data partition)	128GB	0x0000 XXXX -0x0000 XXXX

Therefore, the starting address and the size of each partition are defined through the partition table, so that the corresponding partition size can be adjusted according to the requirement aiming at different hardware.

In addition, it should be noted that, except for the specially reserved partitions, each partition basically has its corresponding image (image) file, the image file is compiled by software codes, and various function files and configurations related to the starting or operating process of the electronic device are integrated therein. Without the image file, the electronic device may not operate. A complete system version includes many images, partition table image gpt.img, boot.img, system image super.img (integrated with android system core), user data image userdata.img (used for storing user data), and so on.

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 according to actual service requirements.

In addition, the distribution of the partition using the double partition in the memory shown in (2) in fig. 3 and (3) in fig. 3 is not limited to the distribution shown in (2) in fig. 3 and (3) in fig. 3, and the position of each partition in practical application is determined according to the allocated start address and end address.

While the description is made with respect to the hardware configuration 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 a different configuration of components. 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, in order to enable the electronic device to perform system upgrade power failure protection according to the technical scheme provided by the embodiment of the application, the software structure of the electronic device is adjusted.

For example, referring to fig. 4, a system upgrade Client (OTA Update Client), a setup Application, and the like for system upgrade management may be included in an Application layer (Application).

The development of OTA, that is, Over-the-Air Technology (OTA), is a way to implement remote version upgrade of terminal electronic devices through wireless network interfaces of the terminal electronic devices. Thus, an OUC at the application layer can be understood as an application that specifically supervises an operating system upgrade.

Further, it is understood that in particular implementations, upgrades to the operating system may also be accomplished by setting up a portal provided by the application.

Illustratively, with continued reference to FIG. 4, a patch engine, a notification manager, etc. are included in the application Framework layer (Framework).

It can be understood that, in the actual application, the patch engine may repair the problem existing in the operating system of the current version according to the downloaded patch package, and the notification manager may notify whether there is a new patch package, an upgrade installation package, or the like.

Illustratively, with continued reference to FIG. 4, an upgrade engine, namely update-engine, is included in the system library.

It can be understood that, in the technical solution provided in the embodiment of the present application, the implementation process of the system upgrade power down protection scheme is completed by the update-engine.

Illustratively, with continued reference to FIG. 4, the Kernel layer (Kernel) includes a cold patch engine, i.e., an engine for repairing problems with the current version of the operating system in a cold patch manner.

The software structure of the electronic device is described here, and it is understood that the layers in the software structure shown in fig. 4 and the components included in each layer do not constitute a specific limitation on the electronic device. In other embodiments of the present application, the electronic device may include more or fewer layers than those shown, and more or fewer components may be included in each layer, which is not limiting.

For convenience in describing the technical solution provided in the embodiment of the present application, the following takes an electronic device of a virtual AB system as an example, and based on the above hardware structure and software structure, a scenario in which a first static partition is loaded during a first boot of the electronic device, and an upgrade installation package performed after the boot is a second static partition and a dynamic partition is taken as an example, and the technical solution provided in the embodiment of the present application is explained in detail.

Illustratively, referring to fig. 5, the first static partition and the second static partition each include a plurality of sub-partitions, and the sub-partitions in the first static partition and the second static partition correspond, for example, the data stored in the X-loader _ a and the data stored in the X-loader _ b come from the same upgrade file, the data stored in the boot _ a and the data stored in the boot _ b come from the same upgrade file, and the data stored in dtbo _ a and the data stored in dtbo _ b come from the same upgrade file.

With continued reference to FIG. 5, the dynamic partition also includes a plurality of sub-partitions, such as a System sub-partition, a System _ ext sub-partition, a Product sub-partition, a Vendor sub-partition, a Cust sub-partition, and an Odm sub-partition.

Accordingly, before the electronic device performs upgrading of the operating system, if the boot sequence is from the first static partition, the data of the base partition, the data of the first static partition, and the data of the dynamic partition are sequentially loaded to run the first operating system when the electronic device boots as shown in fig. 5.

For example, after the electronic device is started according to the loading sequence shown in fig. 5 and is operated to the first operating system, the electronic device may implement the system upgrade power-down protection method provided in the embodiment of the present application according to the flow shown in fig. 6.

And step S101, downloading the upgrade installation package.

Illustratively, the upgrade installation package includes an upgrade file, where the upgrade file corresponds to a first sub-partition, and the first sub-partition is a sub-partition of the dynamic partition.

And step S102, after the upgrade installation package is downloaded successfully, a forced restart detection thread is established.

Step S103, a virtual dynamic partition corresponding to the first sub-partition is created in the user data partition.

And step S104, in the process of writing the data of the upgrade file into the virtual dynamic partition, when the forced restart detection thread detects that the electronic equipment is forced to restart, forcibly dropping the data.

It should be noted that, in practical applications, the electronic device needs to rely on the breakpoint information recorded in the breakpoint record file stored in the user data partition for performing the subsequent upgrade after the forced restart, so that the breakpoint information needs to be recorded in the breakpoint record file in the process of writing the data of the upgrade file into the virtual dynamic partition.

Accordingly, when the forced restart detection thread detects that the electronic device is forcibly restarted, the breakpoint information needs to be forcibly landed in addition to the data.

Illustratively, the breakpoint identified by the breakpoint information is a location where the electronic device is continuously upgraded after being restarted.

Therefore, according to the technical scheme provided by the embodiment, when the upgrade file is written into the user data partition by means of the kernel cache, whether the electronic equipment is forcibly restarted or not is detected in real time by using the forced restart detection thread, and forced disk-dropping operation is executed when the electronic equipment is detected to be forcibly restarted, so that the upgrade progress of the breakpoint information identifier recorded in the breakpoint recording file after the electronic equipment is restarted is consistent with the actually completed upgrade progress, and further the continuous upgrade can be successfully carried out.

In order to better understand the technical solution provided by this embodiment, the following upgrade installation package is obtained by an OUC application installed in an electronic device, and the installation of the upgrade installation package is implemented by an upgrade engine and a kernel, which are used as examples, and the technical solution provided by this embodiment is described in detail.

Referring to fig. 7, the technical solution provided by this embodiment includes:

step S201, the OUC application downloads an upgrade installation package to the user data partition, and the upgrade installation package comprises upgrade files corresponding to the sub-partitions in the upgraded dynamic partition.

In order to better fit an actual service scenario, the system upgrade power-down protection scheme described in the embodiment of the present application takes a system upgrade scenario as an example.

For example, referring to fig. 8, an upgrade installation package (also referred to as a system upgrade installation package) for upgrading an operating system version is managed by an OTA server provided in a cloud by an end-side electronic device (e.g., a PC electronic device, a tablet electronic device, a mobile phone, etc.), and the OTA server may send a corresponding upgrade installation package to the electronic device according to a request for obtaining the upgrade installation package initiated by a different electronic device on an end side (e.g., the PC electronic device, the tablet electronic device, the mobile phone, etc.), or the OTA server may actively push the upgrade installation package sent by the end-side electronic device to the corresponding electronic device after receiving the upgrade installation package sent by the end-side electronic device.

For example, the upgrade installation package issued by the package-shooting server to the OTA server may be actively issued by the package-shooting server to the OTA server after the upgrade installation package is made, or may be issued by the OTA server to the OTA server when the package-shooting server has the upgrade installation package after the OTA server initiates a request for acquiring the upgrade installation package to the package-shooting server.

Since the electronic device in the virtual AB system is taken as an example for explanation in this embodiment, the upgrade installation package downloaded during the system upgrade process of the electronic device in the virtual AB system can be divided into a differential package and a full package.

Regarding the manufacture of the differential package, for the minor image files related to starting, the image files are packaged into an upgrade installation package in a full-amount mode, and a full-amount covering mode is adopted during upgrading; for a relatively large image file, such as super.img, in order to reduce the size of the upgrade installation package, the difference of each logical partition image in the new version super.img and the old version super.img is extracted through a specific difference algorithm, then an independent patch (patch) file is generated and packaged into the upgrade installation package, and the patch file in the upgrade installation package is merged into the old version super.img in the super partition of the electronic device through the specific difference algorithm when the operating system is upgraded, so that the new version super.img can be generated, that is, the upgrade of the old version super.img to the new version super.img is completed.

Regarding the production of the full package, specifically, all the image files of the new version of the embodiment are packaged into the upgrade installation package in full, that is, no separate patch file exists.

In addition, it should be noted that, with respect to the ways in which the package shooting server makes the upgrade installation package version, pushes the upgrade installation package to the OTA server, and pushes the upgrade installation package to the electronic device, the existing implementation scheme is referred to, and this is not described in this application.

As can be seen from the above description, the upgrade installation package includes upgrade files, such as the patch file and the image file, regardless of whether the upgrade installation package is a differential package or a full package. Specifically, in the technical solution provided in this embodiment, the upgrade file included in the upgrade installation package corresponds to the first sub-partition, and the first sub-partition is a sub-partition of the dynamic partition.

In addition, it should be noted that, specifically in an actual application scenario, the upgrade installation package may include, in addition to the upgrade file for upgrading the sub-partition of the dynamic partition, an upgrade file for upgrading the sub-partition of the static partition.

Illustratively, in an example, if the upgrade of the operating System needs to upgrade the dtbo sub-partition of the static partition and the System sub-partition of the dynamic partition, the downloaded upgrade installation package may include a dtbo upgrade file for upgrading the dtbo sub-partition and a System upgrade file for upgrading the System sub-partition.

Furthermore, it should be noted that when the current boot sequence of the electronic device is booting from the first static partition, the dtbo upgrade file in the upgrade installation package is used to upgrade the dtbo _ b sub-partition in the second static partition.

In addition, it should be noted that, in practical application, if the sub-partition of the static partition of the operating system also needs to be upgraded, the upgrade installation package downloaded from the OTA server through the OUC application includes, in addition to the upgrade file corresponding to the sub-partition in the dynamic partition to be upgraded, the upgrade file corresponding to the sub-partition to be upgraded in the static partition.

That is to say, when both the static partition and the dynamic partition of the operating system need to be upgraded, the upgrade file that needs to be included in the upgrade installation package to upgrade the static partition and the upgrade file that needs to be included in the upgrade dynamic partition are acquired.

Correspondingly, if the static partition of the operating system needs to be upgraded and the dynamic partition does not need to be upgraded, the obtained upgrade installation package needs to include the upgrade file for upgrading the static partition but does not need to include the upgrade file for upgrading the dynamic partition.

In order to upgrade only the System sub-partition in the dynamic partition by the upgrade of the operating System, the upgrade installation package downloaded from the OTA server to the user data partition by the OUC application needs to include the upgrade file for upgrading the System sub-partition.

Illustratively, after upgrading the user data partition after the installation package is downloaded, the user data partition is changed from that shown in fig. 5 to that shown in fig. 9.

Step S202, after the upgrade installation package is downloaded successfully, the OUC application informs the upgrade engine to install the upgrade installation package.

Step S203, the upgrade engine creates a forced restart detection thread and starts the forced restart detection thread.

Specifically, the forced restart detection thread created in this embodiment is specifically used to detect whether the electronic device is forcibly restarted.

Illustratively, in some examples, whether the electronic device is forcibly restarted may be determined, for example, by detecting whether a power key (power-on key) is pressed.

In addition, as can be seen from the above description of the software structure of the electronic device, the technical solution provided by this embodiment is implemented by an upgrade engine (update-engine) in the system library. Therefore, after the upgrade installation package is downloaded successfully, the upgrade installation package starts to be installed, that is, when the upgrade process is executed, the electronic device starts the update-engine.

Accordingly, when the upgrade procedure is executed after the update-engine is started, a forced restart detection thread, which may be named as DetectPowerKeyPress, is created first, and then the operations of step S204 and step S205 are executed after the forced restart detection thread is created and started.

For example, the start mode of the forced restart detection thread may be implemented by calling a start () method of the thread object.

In addition, it should be noted that, in some examples, the creation and the starting of the forced restart detection thread may be performed synchronously, that is, the forced restart detection thread is started directly after being created; in other examples, the creation and launching of the forced restart detection thread may be in steps, i.e., created first, and then waiting for the launch to be performed.

For example, in a scenario of creating and initiating synchronous progress, the two operations may be implemented by the following procedures:

new DetectPowerKeyPress (down). Start ()// create a thread with the name DetectPowerKeyPress and start

In the scenario of creating and initiating a step progression, these two operations may be implemented, for example, by the following procedures:

thread DetectPowerKeyPress = new DetectPowerKeyPress (down)// creating a Thread with a Thread name DetectPowerKeyPress

DetecPowerKeyPress. start ()/thread with DetecPowerKeyPress name

In addition, it should be noted that, in the two manners of creating and starting the forced restart detection thread given above, as for the manner of performing the creation and the starting step by step, there may be a case that the processor (CPU) of the electronic device is preempted by other threads first, that is, after the forced restart detection thread is created, other threads are started first, and then the forced restart detection thread is started. Specifically, in an actual application scenario, a proper manner is selected according to a service requirement to create and start a forced restart detection thread, which is not limited in this embodiment.

In addition, the system upgrading failure is avoided in order to avoid incomplete upgrading files or errors in the upgrading installation package. Therefore, after the upgrade installation package is downloaded, the upgrade installation package is installed, that is, before the upgrade files in the upgrade installation package are written into the corresponding partitions, whether the upgrade files in the upgrade installation package are complete and correct needs to be checked.

In addition, it can be understood that if the upgrade file in the upgrade installation package is incomplete or has an error, the update-engine does not need to perform system upgrade operation according to the current upgrade installation package, and therefore the forced restart detection thread does not need to be created. Therefore, after the upgrade installation package is successfully downloaded and before the forced restart detection thread is created, integrity verification needs to be performed on the upgrade installation package which is successfully downloaded.

Correspondingly, after the verification is successful, the step of creating the forced restart detection thread is executed again.

Therefore, the system upgrading failure caused by incomplete upgrading files or errors can be effectively avoided, and the success rate of the system upgrading is ensured.

Furthermore, it is understood that if the upgrade installation package is incomplete or has errors, i.e., the integrity check fails, the step of re-downloading the upgrade installation package, i.e., re-executing step S201, may be performed in some examples.

For example, in other examples, the system upgrade may also be directly exited.

Step S204, after the forced restart detection thread is started, the upgrade engine creates a virtual dynamic partition corresponding to the sub-partition in the dynamic partition to be upgraded in the user data partition.

It should be noted that, for upgrading the operating system of the electronic device in the virtual AB system, according to the partition structure, the static partition existing in the form of a dual partition is upgraded directly to the target partition, that is, the static partition currently in idle (or not started).

For example, when the current boot sequence is to boot from a first static partition, the target partition is the second static partition.

For the dynamic partition, because the dynamic partition exists in a form of a single partition, the dynamic partition cannot be directly covered, and a corresponding virtual dynamic partition, specifically a COW file, needs to be created for each sub-partition (actually, a logical partition) which needs to be upgraded in the dynamic partition in the user data partition.

For example, referring to fig. 10, if the sub-partition to be upgraded in the dynamic partition is a System sub-partition, a COW file corresponding to the System sub-partition needs to be created in the user data partition, which may be named as System _ COW.

Accordingly, if all sub-partitions in the dynamic partition in fig. 10 need to be upgraded, in addition to the System _ COW file corresponding to the System sub-partition, a System _ ext _ COW file corresponding to the System _ ext sub-partition, a Product _ COW file corresponding to the Product sub-partition, a Vendor _ COW file corresponding to the Vendor sub-partition, a host _ COW file corresponding to the host sub-partition, and a Odm _ COW file corresponding to the Odm sub-partition need to be created in the user data partition.

For example, after creating a COW file corresponding to a required sub-partition in a user data partition, the mirror image of each sub-partition may be upgraded in units of blocks (blocks), that is, as long as a block is related to updating, the updated block may be saved in a corresponding COW file.

For example, in a specific implementation, the upgrade to the first sub-partition may include, for example, move (move), modify (diff), delete (del), add (add), and the like.

Note that, the move mentioned above may be, for example, moving a block originally located at the 4 th position to the 5 th position; diff may be, for example, modifying a certain block by using a differential modification method, del may be, for example, deleting a block originally located at the 4 th position, and add may be, for example, adding a block in the first sub-partition.

In addition, it should be noted that, since the data of the upgrade file written into the corresponding virtual dynamic partition (COW file) in the user data partition needs to be completed by the kernel cache, in the process of writing the data of the upgrade file into the corresponding virtual dynamic partition in the user data partition by the kernel cache, a breakpoint record file recording the upgrade progress needs to be used, and the breakpoint record file is stored in the user data partition. Therefore, before writing the data of the upgrade file into the corresponding virtual dynamic partition in the user data partition by means of the kernel, a breakpoint record file needs to be created in the user data partition.

Therefore, the operation of creating the breakpoint record file can be performed in synchronization with the operation of creating the virtual dynamic partition corresponding to the System sub-partition.

Accordingly, after step S204 is completed, the content stored in the user data partition is changed to that shown in fig. 10.

Specifically, in this embodiment, the breakpoint recording file is used for recording breakpoint information, and the breakpoint identified by the breakpoint information points to a location where data to be written into the kernel cache in the upgrade file is located.

In addition, it should be noted that after the breakpoint record file is created, before the update-engine starts writing the upgrade file into the virtual dynamic partition in the user data partition by using the kernel cache, the breakpoint identified by the breakpoint information recorded in the breakpoint record file is specifically 1, that is, the block that needs to perform the write operation for the first time.

And step S205, writing the data of the upgrade file into the virtual dynamic partition, and recording breakpoint information into the breakpoint recording file.

Specifically, in the technical solution provided in this embodiment, the implementation of step S205 may include, for example, the following 5 sub-steps:

and in the substep S2051, the kernel sequentially stores the data of the upgrade file into the kernel cache, generates breakpoint information and stores the breakpoint information into the kernel cache.

And a substep S2052, when the synchronization condition is met, the kernel synchronizes the data to be destaged in the kernel cache to the virtual dynamic partition, and synchronizes the breakpoint information in the kernel cache to the breakpoint record file.

And a substep S2053, when the forced restart detection thread detects that the power key is pressed for a certain time, the forced restart detection thread informs the upgrade engine that the electronic equipment is to be forcibly restarted.

In sub-step S2054, the upgrade engine sends a force-down instruction to the kernel.

And a substep S2055, synchronizing the data to be landed in the kernel cache to the virtual dynamic partition by the kernel, and synchronizing the breakpoint information in the kernel cache to the breakpoint record file.

For convenience of description, in this embodiment, the sub-partition to be updated in the dynamic partition is taken as a System sub-partition, the upgrade file included in the upgrade installation package is an upgrade file for upgrading the System sub-partition, and the virtual dynamic partition created in the user data partition is a System _ COW file corresponding to the System sub-partition, which is taken as an example, and the implementation process in step S205 is specifically described.

Illustratively, in implementing the above operation, the upgrade engine session core sends an instruction to execute step S205.

Correspondingly, after receiving the instruction of executing step S205, the kernel reads data from the upgrade file of the upgrade System sub-partition in the upgrade installation package to the kernel cache in the random access memory 121B, generates breakpoint information, and saves the breakpoint information to the kernel cache; then, when the synchronization condition is satisfied, the kernel synchronizes the data of the upgrade file stored in the kernel cache to the virtual dynamic partition, and synchronizes the generated breakpoint information to the breakpoint record file, as shown in fig. 11.

In addition, it should be understood that, in practical application, there are two ways for the data cached by the kernel to be truly landed, that is, written/synchronized to the virtual dynamic partition, one of which is the way given by step S2053 in this embodiment, that is, a forced landing instruction is actively issued to the kernel, so that the kernel forcibly landes the data in the kernel cache to the virtual dynamic partition, and forcibly landes the breakpoint information recorded in the kernel cache to the breakpoint record file; the other is that when the kernel checks that the synchronization condition is satisfied, the data in the kernel cache is landed to the virtual dynamic partition, and the breakpoint information recorded in the kernel cache is forcibly landed to the breakpoint record file, that is, in step S2052.

Correspondingly, when the preset synchronization condition is met, reading the data of the written upgrade file from the kernel cache shown in fig. 11, specifically taking block as a unit, then synchronizing to the corresponding virtual dynamic partition, namely the System _ COW file in fig. 11, reading the recorded breakpoint information from the kernel cache, and then synchronizing to the breakpoint record file; and when the preset synchronization condition is not met, continuing to write the data which is not written with the System _ COW file in the upgrade file into the kernel cache, and generating new breakpoint information, specifically the position of the next block, after each block is written into the kernel cache.

Illustratively, in some examples, the synchronization condition is a time interval, such as 5 seconds. That is, every 5 seconds, the operation of reading data is performed on the core cache, and the read data is written in the System _ COW file shown in fig. 11.

Illustratively, in other examples, the synchronization condition is that a certain percentage, e.g., 50%, of the data written in the core cache is reached. That is, each time the proportion of data written in the core cache reaches 50%, the operation of reading data is performed once for the core cache, and the read data is written in the System _ COW file shown in fig. 11.

For better understanding of the process of writing the upgrade file to the virtual dynamic partition via the kernel cache, the following description is provided in conjunction with fig. 12 to 18.

Suppose that the upgrade file corresponds to a System sub-partition, and it is known through analysis of the upgrade file that the data that needs to be written into the System _ COW file corresponding to the System sub-partition at this time can be divided into 5 operations, and specifically, the 5 operations may correspond to one block respectively in the actual application.

Referring to (1) in fig. 12, when data of the upgrade file is written into the System _ COW file for the first time, the kernel reads the data in the upgrade file in order, for example, when the upgrade file of the upgrade System sub-partition shown in (1) in fig. 12 has 5 data blocks of block1 to block5, the data (data of operation 1) that needs to be written into block1 in the System _ COW file is read for the first time. When the data of the operation 1 is written into the block1 in the System _ COW file, the kernel writes the data of the operation 1 into the kernel cache, and the data is not immediately updated into the block1 in the System _ COW file in the user data partition, but the kernel is uniformly scheduled by the operating System, for example, when a special flush kernel thread meets a certain synchronization condition, for example, when a certain time interval is met and the data in the kernel cache reaches a certain proportion, the data in the kernel cache is synchronized into the corresponding block in the System _ COW file.

In addition, it should be noted that, after the read data, for example, the data of operation 1 shown in (1) in fig. 12, is written into the kernel cache, the kernel further modifies the breakpoint identified by the breakpoint information to a location where the data of the upgrade file is written into the kernel cache next time, for example, the location of block2 shown in (2) in fig. 12, that is, the breakpoint information is modified to "breakpoint: 2".

For example, referring to (2) in fig. 12, if it is detected that the synchronization condition is satisfied, the kernel reads the breakpoint information and the data of operation 1 from the kernel cache, and changes the breakpoint identified by the breakpoint information recorded in the breakpoint recording file in the user data partition from "breakpoint: 1 "change to" breakpoint: 2 ", the data of operation 1 is written into block1 in the System _ COW file, and after the above operation is completed, the contents in the System _ COW file and the breakpoint record file in the user data partition are changed to (3) in fig. 12.

In addition, before the electronic device is restarted after a power failure, if data in the upgrade file is not written into the System _ COW file, the kernel may continuously write data into the kernel cache in a manner of writing data of operation 1 into the kernel cache and updating breakpoint information, and simultaneously, in the process of writing data into the kernel cache, the operations shown in 12 (2) may also be executed synchronously when it is detected that the synchronization condition is satisfied.

Illustratively, referring to fig. 13, if the kernel has finished writing the data of operation 1 and the data of operation 2 into the corresponding block in the System _ COW file in the manner described above. At this time, the data of operation 3 is being written into the kernel cache, but after the data of operation 3 is written into the kernel cache, the forced restart detection thread detects that the electronic device is to be forced to restart, for example, a power key of the electronic device is pressed, and the electronic device enters a restart state.

Specifically, in the existing scheme, it is not possible to sense that the electronic device is about to be restarted before the electronic device is restarted, so that the kernel continues to write data of operation 4 into the kernel cache, and at this time, data of operation 3 that has been written into the kernel cache may not yet perform an operation of dropping the disk to block3 in the System _ COW file, as shown in (3) in fig. 13, so that after the electronic device is powered off, data of operation 3 that has not yet dropped the disk to block3 in the System _ COW file is lost.

For example, referring to fig. 14, when the electronic device is restarted after power failure and restarted, and the update-engine continues to write the data of the unwritten operation into the System _ COW file, since the breakpoint identified by the breakpoint information recorded in the breakpoint record file is 4, that is, the data of the operation 4 read from the upgrade file is written into the kernel cache.

Accordingly, after the data of operation 4 is written into the kernel cache, the kernel generates breakpoint information of the location where operation 5 is performed, and records the breakpoint information into the kernel cache, and the content in the kernel cache after the operation is completed is as shown in (2) in fig. 14.

For example, referring to (2) in fig. 14, if it is detected that the synchronization condition is satisfied, the kernel reads the breakpoint information and the data of operation 4 from the kernel cache, and changes the breakpoint identified by the breakpoint information recorded in the breakpoint record file in the user data partition from "breakpoint: 4 "change to" breakpoint: 5 ", the data of operation 4 is written into block4 in the System _ COW file, and after the above operation is completed, the contents in the System _ COW file and the breakpoint record file in the user data partition are changed to (3) in fig. 14.

Since there is data not written in the System _ COW file in the upgrade file, that is, data of operation 5, the kernel may continuously write data in the kernel cache in a manner of writing data of operation 4 in the kernel cache and updating breakpoint information, and meanwhile, in the process of writing data in the kernel cache, the operation shown in (2) in fig. 14 may also be synchronously executed when it is detected that the synchronization condition is satisfied.

After the data in operation 5 is written into the kernel cache, the upgrade file does not have data that needs to be written into the System _ COW file, and in this case, the breakpoint information may be modified to null according to an agreement, that is, the kernel is informed that there is no data that needs to be written currently.

Accordingly, when the synchronization condition is satisfied, the data of operation 5 is landed in the System _ COW file block5, and the breakpoint information "breakpoint: null "is dropped into the breakpoint record file, and after the above operation is completed, the contents in the System _ COW file and the breakpoint record file in the user data partition are changed to (3) in fig. 15. In this way, the data of the upgrade file written in the System _ COW file is incomplete, and the electronic device cannot be upgraded to the operating System2, that is, the System upgrade fails.

Therefore, in order to solve the above problem of the existing system upgrade, in the technical scheme provided in this embodiment, in the process of writing the data of the upgrade file into the virtual dynamic partition through the kernel cache, the started forced restart detection thread may monitor whether the electronic device is forcibly restarted, for example, whether a power key is pressed, so as to predict in advance whether the electronic device is forcibly turned off.

Accordingly, the forced restart detection thread notifies the upgrade engine that the electronic device is to be forcibly restarted after detecting that the power key is pressed.

Accordingly, the upgrade engine may send an instruction to the kernel to force a disk-down to cause the kernel to perform the operation of substep S2055.

Referring to fig. 16, for example, if the forced restart detection thread detects the operation of the forced restart electronic device in the state shown in (1) in fig. 16, the kernel may perform forced destaging on the kernel cache, that is, destaging the content that has not been destaged currently in the kernel cache to the user data partition, as shown in (2) in fig. 16.

Illustratively, when the forced restart detection thread shown in (2) in fig. 16 detects that the electronic device is forcibly restarted, the breakpoint information in the kernel cache is already synchronized into the breakpoint record file of the user data partition, and at this time, only the data of operation 3 remains in the kernel cache and is not synchronized into block3 of the System _ COW file in the user data partition. Therefore, in this scenario, the forced disk-dropping operation performed by the kernel is to synchronize the data of operation 3 in the kernel cache to the block3 of the System _ COW file in the user data partition, the System _ COW file and the breakpoint record file after the forced disk-dropping is successful, and the schematic diagram of the kernel cache is shown in (3) in fig. 16.

Illustratively, in some examples, when the forced restart detection thread detects the operation of the forced restart electronic device, both the data of the upgrade file saved in the kernel cache and the breakpoint information are synchronized to the user data partition, for example, as shown in (1) in fig. 17.

Accordingly, for the scenario shown in (1) in fig. 17, the forced disk-down operation performed by the kernel is to synchronize the data of operation 3 in the kernel cache into the block3 of the System _ COW file in the user data partition, and to send the breakpoint information "breakpoint: 4 ″ synchronization to the breakpoint record file in the user data partition, System _ COW file and breakpoint record file after forced disk-down is successful, and a schematic diagram of kernel cache is shown as (3) in fig. 17.

In addition, it should be noted that, in order to ensure that the data and breakpoint information written into the kernel cache are truly landed to the corresponding virtual dynamic partition and breakpoint record file, the UNIX system provides three functions, namely sync, fsync and fdatasync.

Specifically, the sync function only arranges all the modified blocks into a write queue and then returns, and does not wait for the end of the actual disk writing operation; the fsync function only acts on a single file specified by the file descriptor files, and returns after the disk writing operation is finished, and besides data, the fsync also synchronously updates the attributes of the file; the fdatasync function is similar to fsync, but it only affects the data portion of the file.

Based on the characteristics of the three functions for executing the landing operation, the present embodiment is specifically implemented by calling the fsync function.

For example, referring to fig. 16 to the technical solution provided in this embodiment, the operation of the step S2055 implemented by invoking the fsync function may specifically be: firstly, the kernel stops writing the data of operation 4 into the kernel cache; then, the data of operation 3 that has been written into the kernel cache is landed into block3 of the System _ COW file, so that the upgrade progress of the breakpoint information identifier recorded in the breakpoint record file coincides with the actually completed upgrade progress, and therefore after the electronic device is restarted, the electronic device continues to upgrade according to the breakpoint information identifier recorded in the breakpoint record file, that is, the data of operation 4 is written into the kernel cache, as shown in (1) in fig. 18, and then when the synchronization condition is satisfied, the data of operation 4 is landed into block4 of the System _ COW file, and the breakpoint information "breakpoint: 4' synchronization to the breakpoint record file of the user data partition, as shown in (2) of FIG. 18.

Accordingly, the System _ COW file and the breakpoint record file after the above operations are completed, and the schematic diagram of the kernel cache is shown in (3) in fig. 18.

Because data in the upgrade file is not written into the System _ COW file, that is, data of operation 5, the kernel can write data of operation 4 into the kernel cache and continuously write data into the kernel cache in a manner of updating breakpoint information, and meanwhile, in the process of writing data into the kernel cache, the data of operation 5 and the breakpoint information can be synchronized when a synchronization condition is detected to be met.

Illustratively, the data of operation 5 that has not been written into the System _ COW file is written into the block5 of the System _ COW file according to the flow from (1) in fig. 19 to (3) in fig. 19.

Accordingly, when the synchronization condition is satisfied, the data of operation 5 is landed in the System _ COW file block5, and the breakpoint information "breakpoint: null "is dropped into the breakpoint record file, and after the above operation is completed, the contents in the System _ COW file and the breakpoint record file in the user data partition are changed to (3) in fig. 19.

Illustratively, according to the above technical solution provided in this embodiment, after all the upgrade files in the upgrade installation package are written into the corresponding virtual dynamic partition in the user data partition, that is, after the installation of the upgrade installation package is completed, the electronic device may be restarted, and then the Merge operation is performed, so as to upgrade the first operating system to the second operating system.

For a complete understanding of the system upgrade of the electronic device of the virtual AB system, it is described in detail below with reference to fig. 20.

Illustratively, referring to fig. 20, after an OTA server obtains an upgrade installation package for upgrading an operating system of an electronic device (e.g., a mobile phone) from a package server, the OTA server may actively push the upgrade installation package to the electronic device, after the OTA server obtains the upgrade installation package for upgrading the operating system of the electronic device from the package server, the electronic device may perform integrity check on the downloaded upgrade installation package after completing the operation of downloading the upgrade installation package from the OTA server, create a forced restart detection thread by the update-engine after the check passes the update-engine start, start the forced restart detection thread, write an upgrade file for upgrading a dtbo sub-partition in a static partition in the upgrade installation package into a dtbo _ B sub-partition in a second static partition that is not currently started, and cache the upgrade file with the help of a kernel, that is, after the random access memory 121B is accessed, and writing the upgrade file used for upgrading the System sub-partition in the upgrade installation package into a System _ COW file corresponding to the System sub-partition and created in the user data partition.

Further, specifically in practical applications, after all data in the upgrade file is written into the virtual dynamic partition through the kernel cache, integrity check of the data in the virtual dynamic partition is required.

Correspondingly, after the verification is successful, the starting sequence of the electronic device is changed from starting from the first static partition to starting from the second static partition, and then the restarting phase shown in fig. 20 is entered.

Therefore, the electronic equipment is restarted after the integrity verification is successful, so that the electronic equipment can be ensured to be successfully operated to the second operating system after being restarted, and the system is ensured to be successfully upgraded.

Illustratively, in one implementation, the upgrade file subsequently written to the virtual dynamic partition created by the user data partition is stored as a Copy-On-Write (COW) file, so the format of the virtual dynamic partition is System _ COW, and its specific pointing path may be ". multidot./ota/System _ COW", for example.

With reference to fig. 20, after the installation of the upgrade installation package is completed, the electronic device starts from the SlotB, and executes a Merge operation after the start, that is, the upgrade file temporarily stored in the virtual dynamic partition created in the user data partition is landed in the sub-partition corresponding to the dynamic partition, so that the system upgrade is completed this time, and the operating system of the electronic device is changed to the v2.0 version running in the SlotB.

For example, referring to fig. 21, when the electronic device is restarted according to the changed boot sequence, the data of the base partition, the data of the second static partition, and the data of the dynamic partition are sequentially loaded to run the second operating system.

Continuing with fig. 21, exemplarily, after writing the upgrade file in the form of the COW file into the virtual dynamic partition created in the user data partition, the version of the System _ COW file in the virtual dynamic partition may become the 2.0 version, that is, the version to be upgraded this time.

In addition, it should be noted that the loading the data of the dynamic partition includes: loading data of other sub-partitions except the System sub-partition in the dynamic partition, and loading an upgrade file stored in a System _ COW file in the user data partition; and simultaneously, the upgrading file is landed to the System sub-partition of the dynamic partition.

It should be noted that, the above System sub-partition process of dropping the upgrade file to the dynamic partition is called Merge operation in the operating System upgrade process, as shown in fig. 22.

Furthermore, it should be understood that the upgrade installation package is an upgrade to the operating system, and thus the operating system may be changed from the first operating system to the second operating system after the electronic device is restarted by installing the upgrade installation package. The first and second are to distinguish the version of the operating system, but the type of the operating system is not changed.

In addition, it should be noted that the Merge operation in this embodiment specifically refers to a process of dropping an upgrade file for upgrading a dynamic partition temporarily stored in a user data partition to the dynamic partition.

For example, referring to fig. 23, it is assumed that the upgrade file of version 1.0 written in the System sub-partition includes 7 blocks of block1 through block7, and the upgrade file of version 2.0 written in the System _ COW file includes 5 blocks of block1 through block 5. Therefore, when a System sub-partition in a dynamic partition is upgraded from a 1.0 version to a 2.0 version, that is, when data of each block in a System _ COW file in a user data partition is landed to a corresponding block in the System sub-partition, specifically, data of block1 in the System _ COW file is landed to block1 in the System sub-partition, data of block2 in the System _ COW file is landed to block2 in the System sub-partition, data of block3 in the System _ COW file is landed to block3 in the System sub-partition, data of block4 in the System _ COW file is landed to block4 in the System sub-partition, and data of block5 in the System _ COW file is landed to block5 in the System sub-partition, thereby completing a Merge operation.

Accordingly, after the Merge operation shown in fig. 23 is completed, the System of version 1.0 in the dynamic partition is changed to version 2.0 shown in fig. 24.

Therefore, the system upgrade power-down protection method provided by this embodiment detects whether the electronic device is forcibly restarted in real time by using the forcible restart detection thread when the upgrade file is written into the user data partition by means of the kernel cache, and forcibly drops the data and the breakpoint information of the upgrade file, which has been written into the kernel cache but has not dropped to the user data partition, to the user data partition when it is detected that the power key is pressed, thereby ensuring that the upgrade progress of the breakpoint information identifier recorded in the breakpoint recording file after the electronic device is restarted is consistent with the actually completed upgrade progress, and further enabling the continuous upgrade to be successfully performed.

In addition, in order to avoid that the user mistakenly touches the power key and causes the power key to be instantly pressed, the electronic device is mistakenly considered to be about to restart and further frequently executes the operation of forcibly dropping the data cached by the kernel to the user data partition, a further improvement is made on the basis of the above embodiment.

Referring to fig. 25, the implementation procedure of the improved embodiment specifically includes:

step S301, the OUC application downloads an upgrade installation package to the user data partition, wherein the upgrade installation package comprises upgrade files corresponding to the sub-partitions in the dynamic partition to be upgraded.

Step S302, after the upgrade installation package is downloaded successfully, the OUC informs the upgrade engine to install the upgrade installation package.

Step S303, the upgrade engine creates a forced restart detection thread and starts the forced restart detection thread.

Step S304, after the detection thread is forcibly restarted, the upgrading engine creates a virtual dynamic partition corresponding to the sub-partition in the dynamic partition to be upgraded in the user data partition.

It is easy to find that steps S301 to S304 in the embodiment shown in fig. 25 are substantially similar to steps S201 to S204 in the embodiment shown in fig. 7, and specific implementation details of this embodiment may refer to the description of the embodiment shown in fig. 7, which is not described herein again.

Step S305, in the process of writing the data of the upgrade file into the virtual dynamic partition through the kernel cache, when the forced restart detection thread is pressed, recording a first duration of the pressed power key.

In step S306, the kernel determines whether the first duration is greater than a first duration threshold.

Specifically, if the first duration is greater than a first duration threshold, for example, 2 seconds, step S307 is executed; otherwise, the step S305 is continuously executed.

Therefore, the data writing to the kernel cache is stopped when the pressed time length of the power key is greater than the preset first time length threshold value, and the operation of forcibly dropping the data in the kernel cache to the user data partition is executed, so that the situation that a user mistakenly touches the power key and the electronic equipment is considered to be restarted by mistake when the power key is pressed instantly, and then the operation of forcibly dropping the data cached in the kernel cache to the user data partition is frequently executed is avoided, the unnecessary reading operation of the kernel cache is further reduced, and the occupation and waste of resources of the electronic equipment are reduced.

In step S307, the kernel stops writing the data of the upgrade file into the kernel cache.

Step S308, the kernel writes the data of the upgrade file written in the kernel cache into the virtual dynamic partition.

Step S309, the kernel synchronizes the breakpoint information recorded in the kernel cache to the breakpoint record file located in the user data partition.

It is to be understood that step S308 and step S309 in the embodiment shown in fig. 25 are substantially similar to sub-step S2055 in the embodiment shown in fig. 7, and specific implementation details of this embodiment may refer to the description of the embodiment shown in fig. 7, which is not described herein again.

In step S310, when the power key depression detection thread detects that the depression of the power key is stopped, a second duration for which the power key is depressed is determined.

In step S311, the kernel determines whether the second duration is greater than the second duration threshold.

Specifically, if the second duration is greater than the second duration threshold, step S312 is executed; otherwise, step S313 is performed.

Step S312, the electronic device is restarted, and the kernel writes the data in the upgrade file into the virtual dynamic partition through the kernel cache according to the breakpoint information recorded in the breakpoint record file.

Specifically, the step S312 is specifically implemented by reading data from the position of the breakpoint identified by the breakpoint information in the upgrade file according to the breakpoint information recorded in the breakpoint recording file, and writing the read data into the kernel cache; meanwhile, in the process of writing the data of the upgrade file into the kernel cache, if the synchronization condition is detected to be met, the kernel diskettes the data of the upgrade file written into the kernel cache to the virtual dynamic partition.

Since the data in the kernel cache is forcibly landed to the user data partition before power failure, the upgrading progress recorded by the breakpoint recording file is consistent with the actual upgrading progress, and therefore, after the electronic equipment is restarted, the operation of writing the data of the upgrading file into the user data partition by means of the kernel cache is executed from the breakpoint identified by the breakpoint information recorded by the breakpoint recording file, so that the data of the upgrading file finally written into the user data partition can be ensured not to be missed, and the success of continuous upgrading is ensured.

Step 313, whether all the data of the upgrade file is written into the first sub-partition.

Specifically, when the upgrade installation package only includes the upgrade file for the first sub-partition in the dynamic partition, if all the data of the upgrade file is written into the virtual dynamic partition corresponding to the first sub-partition, step S314 is executed, otherwise, step S305 is executed.

Step S314, restart the electronic device, and execute the Merge operation.

Regarding the process of restarting the electronic device after the upgrade installation package is installed, and executing the Merge operation, details are given in the description part with respect to fig. 20 to fig. 24, and are not described herein again.

Further, specifically in an actual application scenario, when there are a plurality of sub-partitions that need to be upgraded in the dynamic partition, based on the system upgrade power-down protection scheme provided in this embodiment, a flow for implementing system upgrade may be as shown in fig. 26, for example.

For example, referring to fig. 26, after the upgrade installation package is downloaded, the electronic device may first perform the operation of step S401, i.e., start the upgrade engine update-engine located in the system library, and then perform step S402, i.e., create the forced restart detection thread.

In addition, as can be seen from the above description of the embodiment, in order to avoid that the system upgrade fails due to incompleteness or errors of the upgrade file in the upgrade installation package, before installing the upgrade installation package, step S403 needs to be performed first, that is, whether the upgrade installation package is complete is checked.

Accordingly, when the verification fails, step S404 is executed to quit the installation; otherwise, step S405 is executed.

Next, according to the upgrade file analyzed in step S405, the data update message and the upgrade progress of each sub-partition in the dynamic partition can be known, and step S406 is executed according to the analysis result of step S405 to sequentially open the sub-partitions that need to be upgraded, for example, the System sub-partition is opened first, and after the write operation on the System _ COW file corresponding to the System sub-partition is completed, the System _ ext _ COW file corresponding to the System _ ext sub-partition is opened to perform the data write operation.

Illustratively, for each sub-partition needing data writing, the operation of step S407 is performed, and in the process of performing a data updating operation on the opened sub-partition, the updating progress of the sub-partition is recorded to the breakpoint recording file, that is, step S408 is performed.

For example, in the process of executing step S407 and step S408, the started forced restart detection thread may consistently detect whether the electronic device is forced to be restarted.

Accordingly, when it is detected that the power key is pressed, step S409 is executed to determine whether the pressing time period of the power key exceeds 2 seconds.

It can be understood that the 2 seconds mentioned above is the first time period threshold in the first and second embodiments. In practical application, the first time threshold is specifically set to be several seconds, and may be set according to a restart time of the electronic device when the power key is pressed for a long time and a size of data written in the kernel cache, which is not limited in this embodiment.

Accordingly, when it is determined that the pressing time period of the power key exceeds 2 seconds, step S410 is performed, otherwise step S413 is performed.

For example, with continued reference to fig. 26, after the operation of step 410 is performed, it may be determined whether the pressing time period of the power key is less than 5 seconds.

It can be understood that the above-mentioned 5 seconds are the second duration threshold in the first and second embodiments. In practical application, the second duration threshold is a press threshold for triggering the electronic device to restart.

Accordingly, when it is determined that the pressing time of the power key is not less than 5 seconds, step S412 is executed, that is, the electronic device is restarted; otherwise, step S413 is executed.

For example, with continued reference to fig. 26, in step S413, it may be detected whether the opened sub-partition, i.e., the sub-partition currently performing data writing, is updated.

Accordingly, if the opened sub-partition has been updated, step 414 is executed, i.e. the opened sub-partition is closed, and then step 415 is executed; otherwise, the operations of step S407 to step S413 are repeatedly executed until the opened sub-partition is updated.

For example, with reference to fig. 26, in step S415, it is determined whether all the child partitions that need to be updated are updated, and if the update is completed, step S416 is executed; otherwise, the operations from step S406 to step S415 are repeatedly executed until all the sub-partitions are updated.

For example, with continued reference to fig. 26, after all the sub-partitions are updated, step S416 is performed, the data integrity of each sub-partition is checked, and it is determined whether the sub-partition fails to be checked, i.e., step S417 is performed.

Correspondingly, if the integrity check of the sub-partition fails, executing step S419 to prompt the upgrade to fail; otherwise, step S418 is executed to complete the installation operation of the upgrade installation package.

Therefore, based on the technical scheme provided by the embodiment of the application, even if the power failure phenomenon occurs in the process of installing the upgrade installation package by the electronic equipment, the write-in operation of unwritten data can be normally continued to be completed after the electronic equipment is restarted, so that the success of continuous upgrade is ensured.

In addition, in order to better understand the whole process of implementing the operating system upgrade based on the technical solution provided in this embodiment, the following description is made with reference to fig. 27.

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

In step S501, the electronic device loads the basic partition (Common in the above-mentioned figure), the first static partition, and the dynamic partition in sequence, and starts up from the first static partition.

Step S502, an OUC application in the electronic equipment acquires an upgrade installation package of the operating system to the user data partition, wherein the upgrade installation package comprises an upgrade file for upgrading the static partition and an upgrade file for upgrading the dynamic partition.

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

Step S503, the OUC application notifies the upgrade engine that the upgrade installation package is downloaded.

Step S504, the upgrade engine creates a forced restart detection thread.

Step S505, the upgrade engine performs data write operation on the second static partition according to the upgrade file for upgrading the static partition in the upgrade installation package to upgrade the second static partition.

For example, the system incremental upgrade installation package with version 1.1 upgraded to version 1.2 contains the full amount of data of the static partition of version 1.2, and the electronic device overwrites the data of the static partition of version 1.2 in the second static partition (SlotB in the above-mentioned figure).

Step S506, the upgrade engine creates a virtual dynamic partition corresponding to the sub-partition in the dynamic partition to be upgraded (Super in the above-mentioned figure) in the user data partition (Userdata in the above-mentioned figure).

For example, the virtual dynamic partition corresponding to the System sub-partition is System _ COW.

Step S507, the upgrading engine informs the kernel to write the upgrading file of the sub-partition in the upgrading dynamic partition in the upgrading installation package into the virtual dynamic partition.

For example, the upgrade installation package contains 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 the virtual dynamic partition.

For details about the process of writing the data of the upgrade file into the virtual dynamic partition, see the description part of the embodiments shown in fig. 7 to fig. 25, which is not described herein again.

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

Taking a system sub-partition as an example, suppose that in version 1.1, data in the system sub-partition can be divided into two parts, system1 and system 2. The upgrade from version 1.1 to version 1.2, no change in data system2 occurred and data system1 was upgraded to system 3. Then, in step S507, the electronic device creates a virtual dynamic partition in the user data partition (Userdata), and writes the data system3 in the virtual dynamic partition.

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

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

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

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

In step S507, the electronic device unpacks the upgrade installation package to obtain all the COW files, and attaches an AB partition flag to each COW file. Specifically, when the electronic device is currently booted from the first static partition (SlotA in the above-mentioned drawing), it can be understood that the dynamic partition (Super) loaded by the operating system currently running on the electronic device is the dynamic partition (a). When the operating system is upgraded, the virtual dynamic partition created in the user data partition (Userdata) is for dynamic partition (B). Therefore, the name flag _ B of the corresponding dynamic partition (B) is attached to the COW file. For example, system _ b-cow-img.img.0000 is generated for system-cow-img.0000 to attach _ b.

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

system_b-cow-img.img.0000；

system_ext_b-cow-img.img.0000；

vendor_b-cow-img.img.0000；

product_b-cow-img.img.0000；

cust_b-cow-img.img.0000；

odm_b-cow-img.img.0000。

specifically, the COW file includes a COW file map (snapshot map) of the COW file itself and upgrade data.

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

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

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

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

/system/app/A0.XXX；

/system/app/A1.XXX；

/system/app/A2.XXX；

/system/B0.XXX；

/system/B1.XXX；

/system/user/C0.XXX；

/system/user/C1.XXX；

/system/user/C2.XXX；

/system/user/C3.XXX。

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

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

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

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

/system/B0.XXX：024021~024026；

/system/B1.XXX：024027~024028；

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

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

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

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

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

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

Can be regarded as:

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

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

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

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

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

/system/app/A2.XXX：

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

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

/system/user/C2.XXX：

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

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

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

/system/app/A2.XXX：

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

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

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

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

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

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

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

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

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

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

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

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

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

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

/system/B0.XXX：024021~024026；

/system/B1.XXX：024027~024028；

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

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

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

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

and COW file map:

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

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

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

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

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

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

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

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

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

/system/B0.XXX：024021~024026；

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

/system/B1.XXX：024027~024028；

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

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

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

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

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

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

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

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

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

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

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

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

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

And step S508, after the installation of the upgrade installation package is completed, changing the starting sequence of the electronic equipment from the first static partition to the second static partition.

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

In step S509, the electronic device is restarted. And exiting the current operating system, cutting off the power supply of the electronic equipment, and starting the power supply of the electronic equipment again.

Step S510, the electronic device loads the base partition and the second static partition in sequence, and starts from the second static partition.

Step S511, the electronic device loads the dynamic partition and the virtual dynamic partition of the user data partition.

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

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

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

For example, an operating system runtime requirement loads all data in a directory user (/ system/user) under a system sub-partition. The electronic device reads the disk-dropping status information in the metadata (/ metadata), wherein the sub-partition of the system sub-partition is identified as 'not-dropped for merge' in the disk-dropping status information, so that the electronic device searches the COW file in the user data partition (Userdata)/Update under the Update, searches the COW file system _ b-COW-img.img.0000 under the Update, and generates a new version 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. And loading data according to the storage addresses of all files in the new version file map of the system sub-partition/under the system/user, for example, according to the storage addresses of all files in the new version file map of the system sub-partition:

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

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

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

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

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

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

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

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

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

In step S513, the electronic device drops the data of the virtual dynamic partition to the dynamic partition (Super).

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

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

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

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

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

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

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

In addition, it should be noted that, in an actual application scenario, the system upgrade power down protection method provided by the foregoing embodiments implemented by the electronic device may also be executed by a chip system included in the electronic device, where the chip system may include a processor. The system-on-chip may be coupled to the memory, such that the computer program stored in the memory is called when the system-on-chip is run to implement the steps performed by the electronic device. The processor in the system on chip may be an application processor or a processor other than an application processor.

In addition, an embodiment of the present application further provides a computer-readable storage medium, where the computer storage medium stores a computer instruction, and when the computer instruction runs on an electronic device, the electronic device is caused to execute the above related method steps to implement the system upgrade power failure protection method in the above embodiment.

In addition, an embodiment of the present application further provides a computer program product, which, when running on an electronic device, causes the electronic device to execute the above related steps, so as to implement the system upgrade power failure protection method in the above embodiment.

In addition, embodiments of the present application also provide a chip (which may also be a component or a module), which may include one or more processing circuits and one or more transceiver pins; the receiving pin and the processing circuit are communicated with each other through an internal connecting channel, and the processing circuit executes the related method steps to realize the system upgrading power-down protection method in the embodiment so as to control the receiving pin to receive signals and control the sending pin to send signals.

In addition, as can be seen from the above description, the electronic device, the computer-readable storage medium, the computer program product, or the chip provided in the embodiments of the present application are all configured to execute the corresponding method provided above, so that the beneficial effects achieved by the electronic device, the computer-readable storage medium, the computer program product, or the chip can refer to the beneficial effects in the corresponding method provided above, and are not repeated herein.

The above embodiments are only used for illustrating the technical solutions of the present application, and not for limiting the same; although the present application has been described in detail with reference to the foregoing embodiments, it should be understood by those of ordinary skill in the art that: the technical solutions described in the foregoing embodiments may still be modified, or some technical features may be equivalently replaced; and the modifications or the substitutions do not make the essence of the corresponding technical solutions depart from the scope of the technical solutions of the embodiments of the present application.

Claims

1. The system upgrading power-fail protection method is applied to electronic equipment, the electronic equipment comprises a processor and an internal memory, the internal memory comprises a read-only memory and a random access memory, the read-only memory is of a virtual AB system partition structure and comprises a basic partition, a first static partition, a second static partition, a dynamic partition and a user data partition, the dynamic partition comprises a plurality of sub-partitions, the electronic equipment loads data of the basic partition, data of the first static partition and data of the dynamic partition in sequence after being started so as to run a first operating system, and after the operating system runs, the method further comprises the following steps:

downloading an upgrade installation package, wherein the upgrade installation package comprises an upgrade file, the upgrade file corresponds to a first sub-partition, and the first sub-partition is a sub-partition of the dynamic partition;

after the upgrade installation package is successfully downloaded, a forced restart detection thread is established, and the forced restart detection thread is used for detecting whether the electronic equipment is forcibly restarted or not;

creating a virtual dynamic partition in the user data partition corresponding to the first child partition;

in the process of writing the data of the upgrade file into the virtual dynamic partition, when the forced restart detection thread detects that the electronic equipment is forcibly restarted, forcibly dropping the data;

and in the process of writing the data of the upgrade file into the virtual dynamic partition, the operating system operates normally, and the electronic equipment can be used normally by a user.

2. The method of claim 1, wherein during the writing of the data of the upgrade file to the virtual dynamic partition, the method further comprises:

recording breakpoint information into a breakpoint recording file, wherein the breakpoint identified by the breakpoint information is a position where the electronic device is continuously upgraded after being restarted;

wherein, when the forced restart detection thread detects that the electronic device is forced to be restarted, the method further comprises:

and forcibly dropping the disk for the breakpoint information.

3. The method of claim 2, wherein writing the data of the upgrade file into the virtual dynamic partition, and recording breakpoint information into a breakpoint record file comprises:

the kernel sequentially saves the data of the upgrade file to a kernel cache, generates the breakpoint information and saves the breakpoint information to the kernel cache;

and when the synchronization condition is met, the kernel synchronizes the data to be landed in the kernel cache to the virtual dynamic partition, and synchronizes the breakpoint information in the kernel cache to the breakpoint record file.

4. The method of claim 3, wherein the kernel sequentially saves the data of the upgrade file to a kernel cache, generates the breakpoint information, and saves the breakpoint information to the kernel cache, including:

the kernel sequentially stores the data of the upgrade files to a kernel cache;

and after the kernel stores the data of the upgrade file into the kernel cache, the kernel generates breakpoint information for storing the data of the upgrade file into the kernel cache next time, and stores the breakpoint information into the kernel cache.

5. The method according to claim 4, wherein when the forced restart detection thread detects that the electronic device is forcibly restarted, forcibly dropping the disk for the data and forcibly dropping the disk for the breakpoint information includes:

when the forced restart detection thread detects that the electronic equipment is forcibly restarted, the forced restart detection thread informs an upgrade engine that the electronic equipment is to be forcibly restarted;

the upgrading engine sends a forced disk-dropping instruction to the kernel;

and the kernel synchronizes the data to be landed in the kernel cache to the virtual dynamic partition, and synchronizes the breakpoint information in the kernel cache to the breakpoint record file.

6. The method of claim 2, wherein the electronic device is forced to reboot through a power key;

the forced restart detection thread detects that the electronic device is forced to be restarted, and comprises the following steps:

when the forced restart detection thread detects that the power key is pressed, recording a first duration of the pressed power key;

when the first time length is larger than a first time length threshold value, the forced restart detection thread determines that the electronic equipment is forcibly restarted;

and when the first time length is not larger than a first time length threshold value, continuing to execute the step of writing the data of the upgrade file into the virtual dynamic partition.

7. The method according to claim 6, wherein after the forced reboot of the electronic device is detected by the forced reboot detection thread during the writing of the data of the upgrade file into the virtual dynamic partition, the method further comprises:

when the forced restart detection thread detects that the pressing of the power key is stopped, determining a second duration for which the power key is pressed;

when the second duration is smaller than a second duration threshold, continuing to execute the step of writing the data of the upgrade file into the virtual dynamic partition;

and restarting the electronic equipment when the second duration is not less than the second duration threshold.

8. The method of claim 7, wherein after the rebooting the electronic device, the method further comprises:

reading data from the position of the breakpoint identified by the breakpoint information in the upgrade file according to the breakpoint information recorded in the breakpoint recording file, storing the read data to a kernel cache, generating the breakpoint information and storing the breakpoint information to the kernel cache;

and when the synchronization condition is met, the kernel synchronizes the data to be landed in the kernel cache to the virtual dynamic partition, and synchronizes the breakpoint information in the kernel cache to the breakpoint record.

9. The method according to any one of claims 1 to 8, further comprising:

after all the data in the upgrade file are written into the virtual dynamic partition, carrying out integrity check on the data in the virtual dynamic partition;

after the verification is successful, the starting sequence of the electronic equipment is changed from starting from the first static partition to starting from the second static partition;

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

wherein the loading the data of the dynamic partition comprises:

loading data of other sub-partitions except the first sub-partition in the dynamic partition, and loading an upgrade file stored in the virtual dynamic partition in the user data partition;

and the upgrading file is landed to a first sub-partition of the dynamic partition.

10. The method according to any one of claims 1 to 8, wherein before creating a forced restart detection thread after the upgrade installation package is successfully downloaded, the method further comprises:

carrying out integrity check on the upgrade installation package;

and after the verification is successful, executing the step of creating the forced restart detection thread.

11. An electronic device, comprising a processor and an internal memory, wherein the internal memory comprises a read only memory and a random access memory, the read only memory is a virtual AB system partition structure and comprises a base partition, a first static partition, a second static partition, a dynamic partition and a user data partition, and 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;

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

the program instructions, when executed by the processor, cause the electronic device to perform a system upgrade power down protection method as claimed in any one of claims 1 to 10;

in the process of system upgrading, the operating system runs normally, and the electronic equipment can be used normally by a user.

12. A computer-readable storage medium comprising a computer program, which, when run on an electronic device, causes the electronic device to perform a system upgrade power down protection method according to any one of claims 1 to 10.