CN116069369A

CN116069369A - Method, apparatus, storage medium and computer program product for controlling upgrade temperature

Info

Publication number: CN116069369A
Application number: CN202111274149.5A
Authority: CN
Inventors: 陈超; 张赠辉; 王艳召
Original assignee: Honor Device Co Ltd
Current assignee: Honor Device Co Ltd
Priority date: 2021-10-29
Filing date: 2021-10-29
Publication date: 2023-05-05

Abstract

The application provides a method, apparatus, storage medium and computer program product for controlling upgrade temperature. According to the method, when the electronic equipment is restarted to enter the Merge stage after the upgrade package is installed, the electronic equipment is enabled to reduce instant temperature rise when the electronic equipment is restarted to enter the Merge process by adopting a mode of avoiding high temperature points and gaps, so that overheating phenomenon of the electronic equipment is avoided, a user is prevented from feeling that the electronic equipment heats, user experience is further improved, in addition, the situation that a hardware bonding pad of the electronic equipment is cracked due to overhigh temperature, probability device damage is caused after commercial products are upgraded, and machine withdrawal is further avoided.

Description

Method, apparatus, storage medium and computer program product for controlling upgrade temperature

Technical Field

The present application relates to the field of computer technology, and in particular, to a method, apparatus, storage medium, and computer program product for controlling an upgrade temperature.

Background

An Over-the-Air (OTA) upgrade is an upgrade mode for implementing remote version upgrade of an electronic device through a wireless network interface of the electronic device, and aims to upgrade a basic operating system, a read-only application and/or a time zone rule installed on a system partition, which can be understood as that the OTA upgrade can be performed in a process that a user normally uses the electronic device. Currently, in some application scenarios, in order to ensure the success of OTA upgrade and reduce the occupation of the system data to the storage space as much as possible, so as to leave more storage space for storing user data, electronic devices supporting the virtual AB mode are becoming more and more popular.

For the electronic equipment with the data storage structure in the virtual AB mode, because the dynamic partition exists in a single partition mode, in the OTA upgrading process, an upgrading file which is required to be dropped into the dynamic partition is temporarily stored in the user data partition, and when the upgrading of the sub-partition in the static partition which is not started currently is completed, the upgrading file temporarily stored in the user data partition is written into the dynamic partition when the electronic equipment is restarted to enter the Merge process. Because the Merge process needs to use all cores of the central processing unit (Central Processing Unit, CPU) of the electronic device at the same time, a large instant temperature rise is generated, so that the temperature of the electronic device is continuously raised on the basis of starting the temperature rise, and further, a user obviously feels that the electronic device generates heat, and the user experience is influenced. Furthermore, in an extreme scene, if the temperature of the electronic equipment is too high, the reliability of internal devices of the electronic equipment can be affected, so that a hardware bonding pad is cracked, probability device damage occurs after OTA upgrading of a commercial product, and machine withdrawal is caused.

Disclosure of Invention

In order to solve the technical problems, the application provides a method, equipment, a storage medium and a computer program product for controlling the upgrade temperature, which aim to enable a data storage structure to be an electronic device in a virtual AB mode, and can reduce the instantaneous temperature rise when OTA upgrade enters a Merge process, so that the overheating phenomenon of the electronic device is avoided.

In a first aspect, the present application provides a method of controlling an upgrade temperature. The method is applied to electronic equipment with a data storage structure in a virtual AB mode, the electronic equipment comprises a processor and a memory, the memory comprises a basic partition, a first static partition, a second static partition, a dynamic partition and a user data partition, the electronic equipment sequentially loads data of the basic partition, the first static partition and the dynamic partition after being started to run a first operating system, and the method comprises the following steps of: acquiring an upgrade package, and installing the upgrade package in the electronic equipment; after the upgrade package is installed, restarting the electronic equipment to load the data of the basic partition, the second static partition and the dynamic partition in sequence to run a second operating system, and marking snapshot nodes recorded in the basic partition as snapshot nodes for executing a Merge operation, wherein the Merge operation is a process of landing upgrade files of upgrading the dynamic partition in a user data partition to the dynamic partition; setting the state of the snapshot node as a Merge state, and adding the Merge state into a Merge queue, wherein the Merge state is a state for executing Merge operation; before the operation of the Merge is executed on the snapshot node in the Merge queue, when the first temperature of the electronic equipment is not less than a temperature threshold value, the snapshot node which does not execute the Merge operation in the Merge queue is modified from the Merge state to a persistence state, wherein the persistence state is a state of stopping executing the Merge operation.

Therefore, in the method provided by the embodiment of the application, when the electronic equipment is restarted to enter the Merge stage after the upgrade package is installed, whether the current temperature of the electronic equipment is smaller than the preset temperature threshold is checked, and when the current temperature of the electronic equipment is not smaller than the temperature threshold, the state of the snapshot node which does not execute the Merge operation is changed into a Persistent state to stop executing the Merge operation, so that the temperature of the electronic equipment can be prevented from continuously rising, the heating phenomenon of the electronic equipment is avoided, and the user experience is ensured.

Therefore, the electronic equipment can be prevented from being heated by a user, the user experience is improved, in addition, the phenomenon that the electronic equipment is damaged by probability devices after being upgraded and the electronic equipment is taken off due to the fact that the hardware bonding pad is cracked due to the fact that the temperature is too high is avoided through controlling the temperature.

According to a first aspect, after a first period of time, when the second temperature of the electronic device is less than the temperature threshold, the snapshot node located at the head of the queue in the Merge queue is modified from the persistence state to the Merge state. Therefore, after the first time length is set, when the temperature of the electronic equipment is smaller than the temperature threshold value, the snapshot node in the persistence state is modified to be in the Merge state, so that the snapshot node can perform Merge operation, the Merge operation of all snapshot nodes can be successfully completed by the aid of the mode of avoiding high-temperature points and gaps to execute the Merge operation, and instant temperature rise can be reduced when the Merge process is restarted to avoid overheat of the electronic equipment.

According to the first aspect, or any implementation manner of the first aspect, the obtaining the upgrade package, installing the upgrade package in the electronic device, includes: the upgrade package is obtained, the upgrade package comprises a first upgrade file and a second upgrade file, the first upgrade file corresponds to a first sub-partition, the first sub-partition is a sub-partition of the dynamic partition, the second upgrade file corresponds to a second sub-partition, and the second sub-partition is a sub-partition of the second static partition; performing data writing operation on the second sub-partition according to the second upgrading file; creating a first virtual dynamic sub-partition corresponding to the first sub-partition in the user data partition, and performing snapshot processing on the first sub-partition and the first dynamic virtual sub-partition to obtain a snapshot file; creating a snapshot node corresponding to the first sub-partition in the base partition, and mapping the snapshot file to the snapshot node; writing the first upgrade file into the first virtual dynamic sub-partition, and canceling mapping with the snapshot node; and changing the starting sequence from the starting of the first static partition to the starting of the second static partition. When the upgrade file of the sub-partition in the upgrade package is temporarily stored in the user data partition, a snapshot node corresponding to the sub-partition to be upgraded is created in the base partition, and a snapshot technology is adopted to Map the snapshot file (Map) after snapshot processing is carried out on the current entity data of the sub-partition and the occupied data of the virtual dynamic sub-partition without real data to the corresponding snapshot node, so that when the subsequent electronic equipment is restarted to enter the Merge stage to execute Merge operation, the fact that the update file temporarily stored in each virtual dynamic sub-partition in the user data partition needs to be landed in which sub-partition in the dynamic partition is determined directly according to the snapshot node recorded in the base partition is achieved, namely the object aimed by the Merge operation can be quickly and accurately determined.

According to a first aspect, or any implementation manner of the first aspect, before performing a Merge operation on the snapshot node in the Merge queue, when a first temperature of the electronic device is less than the temperature threshold, performing the Merge operation on the snapshot node in the Merge queue that is located at a queue head. In this way, the Merge operation is performed when the temperature is smaller than the temperature threshold, so that even if the Merge operation causes instantaneous temperature rise, the user cannot feel that the electronic equipment generates heat by adding the temperature increased during the Merge operation on the basis of the current temperature.

According to the first aspect, or any implementation manner of the first aspect, the performing, on the snapshot node located at the head of the queue in the Merge queue, a Merge operation includes: reestablishing mapping between the snapshot node and the corresponding snapshot file; and reading the first upgrade file from the first virtual dynamic sub-partition corresponding to the first sub-partition in the user data partition according to the snapshot file mapped to the snapshot node, and landing the first upgrade file on the first sub-partition.

According to a first aspect, or any implementation manner of the first aspect, before the modifying the snapshot node in the Merge queue that does not perform a Merge operation from the Merge state to a persistence state, the method further includes: traversing snapshot nodes corresponding to the sub-partitions to be upgraded in the dynamic partition, which are recorded in the basic partition, and screening snapshot nodes with mapping relations with the sub-partitions to be upgraded in the dynamic partition; and deleting the snapshot node which has completed the Merge operation from the screened snapshot nodes, and obtaining the snapshot node which does not execute the Merge operation in the Merge queue. According to the scheme provided by the embodiment of the application, the map can be successfully screened for the first time, and the snapshot nodes which need to execute the Merge operation are deleted for the second time, so that all the snapshot nodes which need to execute the Merge operation but do not execute the Merge operation can be obtained.

According to the first aspect, or any implementation manner of the first aspect, the modifying the snapshot node in the Merge queue that does not perform the Merge operation from the Merge state to a persistence state includes: determining a third sub-partition corresponding to the snapshot node and a second virtual dynamic sub-partition corresponding to the third sub-partition according to the snapshot file corresponding to the snapshot node, wherein the third sub-partition is one sub-partition of the dynamic partition, and the second virtual dynamic sub-partition is a sub-partition which is created in the user data partition and is used for temporarily storing a third upgrade file written into the third sub-partition; and modifying the second snapshot node from the Merge state to a persistence state according to the third sub-partition and the second virtual dynamic sub-partition. In this way, the snapshot node is configured to be in a Persistent state according to the third sub-partition and the second virtual dynamic sub-partition, so that the operation of dropping the third upgrade file temporarily stored in the second virtual dynamic sub-partition to the third sub-partition can be stopped, that is, the operation of performing the Merge on the snapshot node is stopped, and therefore the electronic equipment can be cooled first, and the temperature of the electronic equipment is prevented from continuously rising.

According to a first aspect, or any implementation manner of the first aspect, after the modifying the snapshot node in the Merge queue that does not perform a Merge operation from the Merge state to a persistence state, the method further includes: accumulating the total duration of stopping executing the Merge operation in the Merge stage; when the total duration is less than a duration threshold and the second temperature of the electronic device is less than the temperature threshold, executing the step of modifying the snapshot node at the head of the queue in the Merge queue from the persistence state to the Merge state; and when the total duration is not less than the duration threshold, executing the step of modifying the snapshot node which does not execute the Merge operation in the Merge queue from the Merge state to a Persistent state. According to the scheme provided by the embodiment of the application, by introducing the timeout mechanism, when the total duration of stopping executing the Merge operation is not less than the preset duration threshold, the Merge operation is not stopped no matter whether the electronic equipment is in a high temperature range or not, namely, whether the current temperature of the electronic equipment is not less than the temperature threshold or not, so that the Merge operation can be completed in a controllable time by the electronic equipment, and further upgrading is completed, and the reliability of the electronic equipment is maintained.

According to the first aspect, or any implementation manner of the first aspect, the method further includes: and deleting the snapshot node which completes the Merge operation from the basic partition. In this way, after each time the Merge operation is executed, the snapshot node which has completed the Merge operation is deleted from the base partition, so that the number of times of traversing the snapshot node in the base partition when the snapshot node which needs to stop the Merge operation is determined can be reduced.

According to the first aspect, or any implementation manner of the first aspect, the method further includes: traversing snapshot nodes corresponding to sub-partitions to be upgraded in the dynamic partition, which are recorded in the basic partition, in the process of executing the Merge operation; for each traversed snapshot node, determining the progress of the Merge operation; and refreshing the total progress bar of the electronic equipment in the Merge stage according to the progress of the Merge operation corresponding to each snapshot node. In the scheme provided by the embodiment of the application, the progress bar of the Merge stage is synthesized based on the progress of Merge operation corresponding to each snapshot node, so that a user can conveniently know the completion condition of the whole Merge in the current upgrading process.

In a second aspect, the application provides an electronic device, where the electronic device is in a virtual AB mode, and 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, the first static partition, and 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 instructions of the first aspect, or the method in any implementation of the first aspect above.

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

In a fourth aspect, the 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 instructions of the first aspect, or of the method in any implementation of the first aspect above.

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

Drawings

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

FIG. 2 is a schematic diagram of a data storage structure for the Recovery mode, the AB mode, and the virtual AB mode, which are shown by way of example;

fig. 3 is a schematic diagram of a scenario in which an end side and a server side are shown in an exemplary manner to obtain an OTA upgrade package interactively;

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

FIG. 5 is a schematic diagram illustrating a scenario in which an operating system is upgraded from an OTA upgrade package to a Merge process;

fig. 6 is a schematic diagram of a temperature rise curve of an electronic device directly entering a Merge stage after an OTA upgrade package is installed and restarted;

FIG. 7 is one of the flow diagrams of the method for controlling upgrade temperature provided by the exemplary embodiments of the present application;

Fig. 8 is a specific flowchart schematically illustrating implementation of step S101 illustrated in fig. 7;

FIG. 9 is a schematic diagram illustrating writing an upgrade file in an OTA upgrade package to a static partition and a user data partition;

FIG. 10 is a schematic diagram illustrating the addition of a snapshot node of the Merge state to a Merge queue;

FIG. 11 is a schematic diagram of an exemplary snapshot node fetching the Merge state from the Merge queue;

fig. 12 is a specific flowchart schematically illustrating implementation of step S109 illustrated in fig. 7;

FIG. 13 is a schematic diagram illustrating the sequential loading of partitions and execution of a Merge process when an electronic device is booted by a second static partition;

fig. 14 is a schematic diagram of a temperature rise curve of an electronic device during a Merge operation performed by the method for controlling an upgrade temperature according to the embodiment of the present application;

FIG. 15 is a second exemplary flow chart illustrating a method for controlling upgrade temperature provided by embodiments of the present application;

FIG. 16 is a schematic diagram illustrating the acquisition of a boot identification of a second static partition;

fig. 17 is a schematic diagram schematically illustrating loading of partitions in sequence and execution of the Merge process when the electronic device is started by the first static partition.

Detailed Description

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

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

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

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

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

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

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

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

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

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

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

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

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

Further, it is understood that in an actual 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, in particular, in the technical solution provided in the embodiment of the present application, the starting of the electronic device 100 and the upgrading of the OTA upgrade package mainly relate to the internal memory 121, that is, relevant instructions for implementing the method for controlling the upgrade temperature provided in the embodiment of the present application are stored in advance in the internal memory 121, and the processor 110 executes the instructions stored in the internal memory 121, so that the electronic device 100 can execute the method for controlling the upgrade temperature provided in the embodiment of the present application.

In addition, it should be noted that, in a specific implementation, the internal memory 121 may include a storage program area and a storage data area. The storage program area may store an application program (such as a sound playing function, an image playing function, etc.) required for at least one function of the operating system, etc. The storage data area may store data created during use of the electronic device 100 (e.g., audio data, phonebook, etc.), and so on. In addition, the internal memory 121 may include a high-speed random access memory, and may further include a nonvolatile memory such as at least one magnetic disk storage device, a flash memory device, a universal flash memory (universal flash storage, UFS), and the like.

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

For convenience of explanation, the present application takes an upgrade scenario based on an OTA technology as an example, that is, an upgrade package is obtained as an OTA upgrade package.

In addition, it can be understood that in an actual application scenario, the basic partition generally stores content which cannot be upgraded when the OTA is upgraded, the static partition and the dynamic partition store content which is possibly upgraded when the OTA is upgraded, the user data partition stores data created in the using process of the electronic equipment, and the OTA is not upgraded generally, so that user data loss caused by upgrading is avoided, and user experience is affected.

For example, in practical applications, the data storage structure of the internal memory 121 of the electronic device 100 may be, for example, a Recovery mode, an AB mode, and a virtual AB mode, and the startup modes of the electronic device 100 with different data storage structures may also be different.

It should be noted that, in practical application, the mode corresponding to the data storage structure is generally consistent with the mode corresponding to the start mode, that is, the data storage structure is the electronic device in the Recovery mode, and the corresponding start mode is also the Recovery mode; the data storage structure is an electronic device in an AB mode, and the corresponding starting mode is also the AB mode; the data storage structure is an electronic device in a virtual AB mode, and the corresponding starting mode is also the virtual AB mode.

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

For example, since the OTA upgrade is performed in the Recovery mode, other functions of the electronic device cannot be used in the upgrade process, the electronic device can only stay on the upgrade interface in the Recovery mode, and the user interface can be accessed for normal use after the OTA upgrade is completed and the electronic device is restarted. Therefore, in the Recovery mode, the static partition and the dynamic partition are also single partitions, see the schematic diagram (1) of the data storage structure of the Recovery mode in fig. 2, so that the occupation of the memory space can be reduced, and more space is reserved for the user data partition.

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

The virtual AB mode combines the advantages of the Recovery mode and the AB mode, and divides a static partition, which occupies a small memory space, into a first static partition (SlotA) and a second static partition (SlotB), and a dynamic partition, which occupies a large memory space, is a single partition, which is shown in fig. 2 as a virtual AB mode data storage structure diagram (3).

It should be noted that, in practical application, the partition deployment information for the internal memory in the electronic device may be described by a partition table shown in table 1.

TABLE 1 partition Table

/>

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

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

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

In addition, the distribution of the partitions using the double partitions shown in fig. 2 (2) and fig. 2 (3) in the memory is not limited to that shown in fig. 2 (2) and fig. 2 (3), and the positions of the respective partitions are determined according to the assigned start address and end address in practical applications.

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

In the technical scheme of the embodiment of the application, the upgrading process of the operating system is described in detail by taking the electronic equipment with the data storage structure as the virtual AB mode as an example.

It should be noted that, in an actual application scenario, along with development of Over-the-Air Technology (OTA), OTA upgrading for implementing remote version upgrade of a terminal device through a wireless network interface of the terminal device is becoming popular. In combination with an actual service scenario, the scheme for controlling the upgrade temperature described in the embodiments of the present application takes an OTA upgrade scenario as an example. For example, referring to fig. 3, an OTA upgrade package for upgrading an operating system version is managed by an OTA server provided to a cloud end by a package beating server, where the OTA server sends a corresponding OTA upgrade package to an electronic device according to a request for obtaining the OTA upgrade package initiated by different electronic devices (such as a PC device, a tablet device, a mobile phone, etc.) at an end side, or the OTA server actively pushes the OTA upgrade package to the corresponding electronic device after receiving the OTA upgrade package sent by the package beating server.

The OTA upgrade package sent to the OTA server by the package beating server can be actively sent to the OTA server by the package beating server after the OTA upgrade package is manufactured, or can be sent to the OTA when the OTA upgrade package exists by the package beating server after the OTA server sends a request for acquiring the OTA upgrade package to the package beating server.

Regarding the manner in which the clapping server makes the version of the OTA upgrade package, pushes the OTA upgrade package to the OTA server, and pushes the OTA upgrade package to the electronic device, the OTA upgrade package is made by referring to the existing implementation scheme, which is not described in the present application.

For convenience of explanation, the technical solution provided in the embodiments of the present application will be described in detail below by taking, as an example, a scenario that the electronic device is started from the first static partition when started before performing OTA upgrade, that is, when the electronic device is started, data of the base partition, the first static partition, and the dynamic partition are sequentially loaded (specific loading sequence is shown in fig. 4), and after the electronic device is started, the obtained OTA upgrade package is started from the second static partition after being installed.

Before explaining the scheme of controlling the upgrade temperature provided in the embodiment of the present application, a brief description will be given of a scheme of starting the electronic device to execute the Merge operation from the second static partition after the installation of the existing OTA upgrade package is completed with reference to fig. 5 and 6.

For example, referring to fig. 5, the version of the operating system currently running in the electronic device (e.g., a mobile phone) started from SlotA is v1.0, in a specific implementation manner, after the OTA server obtains the OTA upgrade package for upgrading the operating system of the electronic device from the package beating server, the OTA upgrade package may be actively pushed to the electronic device, and after the electronic device finishes the operation of downloading the OTA upgrade package from the OTA server, the electronic device checks the downloaded OTA upgrade package, and installs the OTA upgrade package after the check passes.

The installation essence of the OTA upgrade package is that the upgrade file for upgrading the static partition in the OTA upgrade package is written into the static partition which is not started currently, and the upgrade file for upgrading the dynamic partition in the OTA upgrade package is temporarily stored in the user data partition before the electronic device is restarted.

Illustratively, with continued reference to FIG. 5, an upgrade file for upgrading the dynamic partition is written to the second static partition.

It can be appreciated that in an actual application scenario, the upgrade to the second static partition may be an upgrade to one of the sub-partitions, or may be an upgrade to multiple sub-partitions, or all of the sub-partitions.

Accordingly, the upgrade to the dynamic partition may also be an upgrade to one of the sub-partitions, or an upgrade to multiple sub-partitions, or all of the sub-partitions.

Referring to fig. 5, taking an upgrade of a System sub-partition in a dynamic partition as an example, a virtual dynamic sub-partition created in a user data partition corresponds to the System sub-partition.

Illustratively, in one implementation, the upgrade file that is subsequently written to the virtual dynamic sub-partition created at the user data partition is saved in the form of a Copy-On-Write (COW) file, so the virtual dynamic sub-partition is in the form of a system_cow, the specific pointing path of which may be, for example, "./ ota/system_cow in fig. 5).

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

As can be clearly known from the drawbacks of the upgrade method shown in fig. 5 in conjunction with fig. 6, under the test environment with basically stable ambient temperature, no matter the screen temperature, the back shell temperature or the frame temperature of the electronic device, the change trend is basically the same in the whole OTA upgrade process, the temperature from the start of downloading the OTA upgrade package to the installation of the OTA upgrade package continuously rises, a first small peak appears when restarting the electronic device, the partition is loaded in the restarting process, and the merger operation executed by the stand horse continuously rises the temperature of the electronic device, and then a second peak appears in fig. 6. Through a large number of tests, when the temperature of the electronic equipment exceeds the normal temperature of a human body, for example, 37 ℃, the electronic equipment can be continuously increased by more than 2 ℃ on the basis of the current temperature by continuously executing the Merge operation, and when the temperature of the electronic equipment is higher than the normal temperature of the human body, a user can feel that the electronic equipment generates heat, so that the user experience is influenced.

In order to solve the above problems, a technical solution provided by the embodiments of the present application is provided. Referring to fig. 7, an implementation flow of a method for controlling an upgrade temperature provided in an embodiment of the present application specifically includes:

step S101, an OTA upgrade package is obtained, and the OTA upgrade package is installed in the electronic equipment.

For an example, regarding the implementation procedure of step S101 in this embodiment, a specific implementation manner is given with reference to fig. 8, which specifically includes:

in the substep S1011, the OTA upgrade package is obtained.

As can be seen from the above description, the electronic device may actively initiate the request to obtain the OTA upgrade package to the OTA server, or may passively receive the push from the OTA server, which is not limited in this embodiment.

In addition, for convenience of explanation, the obtained OTA upgrade package in this embodiment includes a first upgrade file and a second upgrade file, where the first upgrade file corresponds to a first sub-partition, the first sub-partition is a sub-partition of the dynamic partition, and the second upgrade file corresponds to a second sub-partition, and the second sub-partition is a sub-partition of the second static partition.

It can be understood that in practical application, for the case that there are multiple sub-partitions to be upgraded in the static partition and the dynamic partition, the OTA upgrade package may include multiple first upgrade files for upgrading the sub-partitions in the dynamic partition, so as to upgrade different sub-partitions in the dynamic partition according to different first upgrade files.

Correspondingly, the OTA upgrade package may further include a plurality of second upgrade files for upgrading the sub-partitions in the second static partition, so as to upgrade different sub-partitions in the second static partition according to different second upgrade files.

In addition, it should be noted that, in practical application, the sub-partitions in the first static partition and the sub-partitions in the second static partition are in one-to-one correspondence, so the first upgrade file corresponding to the first sub-partition in the second static partition also corresponds to the sub-partition corresponding to the first sub-partition in the first static partition. For example, when the first sub-partition is a patch_b sub-partition, the sub-partition corresponding to patch_b in the first static partition is a patch_a.

And step S1012, performing data writing operation on the second sub-partition according to the second upgrade file.

In practical application, after the first upgrade file and the second upgrade file are parsed from the OTA upgrade package, the static partition which is not started currently is determined to be the static partition to be operated by the current OTA upgrade according to the starting sequence recorded in the base partition, then the sub-partition corresponding to the second upgrade file in the determined static partition is determined to be the sub-partition to be operated by the current OTA upgrade according to the second upgrade file, then the address path of the determined sub-partition is obtained, for example, the starting address and the ending address of the sub-partition recorded in the partition table are obtained, and finally the second upgrade file is written into the determined sub-partition according to the obtained path address.

In this embodiment, since the starting sequence is started from the first static partition, the second static partition that is not started currently is determined as the static partition to be operated by the OTA upgrade.

Correspondingly, according to the second upgrade file, the second sub-partition in the second static partition is determined to be the sub-partition to be operated by the OTA upgrade.

Finally, the path address of the second sub-partition is obtained from the partition table, and then the second upgrading file is written into the second sub-partition according to the obtained path address.

Illustratively, taking the example that the first static partition and the second static partition each include 3 sub-partitions of X-loader, vendor and dtbo, such as X-loader_a, vendor_a and dtbo_a in SlotA and X-loader_b, vendor_b and dtbo_b in SlotB in FIG. 9. If the number of the second upgrade files included in the OTA upgrade package is 3, which are used for upgrading the 3 sub-partitions, when it is determined that the static partition currently required to be upgraded is the second static partition, the second upgrade files for upgrading the X-loader_b sub-partition are written into the X-loader_b sub-partition, the second upgrade files for upgrading the vendor_b sub-partition are written into the vendor_b sub-partition, and the second upgrade files for upgrading the dtbo_b sub-partition are written into the dtbo_b sub-partition, as shown in the schematic diagram (1) in fig. 9.

Accordingly, based on the above manner, after the data writing operation is performed on the X-loader_b, the vendor_b, and the dtbo_b, each of which is 1.0 in the current version of SlotB in the schematic diagram (1) in fig. 9, the versions of the X-loader_b, the vendor_b, and the dtbo_b are changed to the 2.0 version shown in the schematic diagram (2) in fig. 9.

Sub-step S1013 includes creating a first virtual dynamic sub-partition corresponding to the first sub-partition in the user data partition, and performing snapshot processing on the first sub-partition and the first dynamic virtual sub-partition to obtain a snapshot file.

It can be understood that, under the virtual AB mode, the dynamic partition in the memory is a single partition, so before the electronic device is restarted, the first upgrade file is temporarily stored in the user data partition, after the electronic device is restarted, the base partition, the second static partition and the dynamic partition are loaded in sequence according to the changed starting sequence, and after the Merge operation is performed, the first upgrade file is read from the user data partition and falls into the sub-partition corresponding to the dynamic partition. Therefore, in the process of installing the OTA upgrade package, a first virtual dynamic sub-partition for temporarily storing the first upgrade file needs to be created in the user data partition according to the size of the first upgrade file, and then the first upgrade file is written into the created first virtual dynamic sub-partition.

In addition, it should be noted that, because the installation of the OTA upgrade package is completed, when the Merge operation is executed after the electronic device is restarted, the execution is generally completed based on a Snapshot (snap shot) technology, and when the Merge operation is implemented based on the snap shot technology, a snap shot node capable of establishing a mapping (Map) with the virtual dynamic sub-partition and the corresponding first sub-partition is required. Before the Merge operation is executed, mapping is carried out on entity data in the first sub-partition before the first upgrade file is written and a Snapshot file after the Snapshot processing of the occupied data of the corresponding first virtual dynamic sub-partition in the snap shot node.

With respect to the above-mentioned occupancy data in the first virtual dynamic sub-partition, it does not have a practical meaning that "0" is used for occupancy when the first virtual dynamic sub-partition is created according to the size of the first upgrade file, that is, the content recorded in the first virtual dynamic sub-partition is all "0" before the first upgrade file is written into the first virtual dynamic sub-partition.

Specifically, in the technical solution provided in this embodiment, the entity data of the first sub-partition in the dynamic partition before upgrading and the first virtual dynamic sub-partition in the user data partition are subjected to Snapshot processing, and then the obtained Snapshot file is mapped to the corresponding snap shot node, so that it can be quickly and accurately known which data in the virtual dynamic sub-partition in the user data partition need to be dropped to which sub-partition in the dynamic partition when the Merge operation is performed subsequently.

By way of example, with continued reference to diagram (1) of fig. 9, where the first sub-partition in the dynamic partition that needs to be upgraded is a System, the specific path of the first virtual dynamic sub-partition created in the user data partition may be "./ ota/system_cow", for example.

It can be appreciated that in the diagram (1) of fig. 9, the path is "./ ota/system_cow" the first virtual dynamic sub-partition has not yet written entity data, and the snappshot file after Snapshot processing according to the first virtual dynamic sub-partition and the first sub-partition in the dynamic partition may be as shown in the system_b.zxid shown on the left side of the diagram (1) of fig. 9.

Sub-step S1014 creates a snapshot node in the base partition corresponding to the first sub-partition, mapping the snapshot file to the snapshot node.

The Snapshot nodes corresponding to the sub-partitions in each dynamic partition to be upgraded, which are created in the base partition in the embodiment, may be stored under a snappshot folder in the base partition.

Taking the sub-partition to be upgraded in the dynamic partition as the System sub-partition for example, because the first static partition is started currently, the System sub-partition in the dynamic partition is logically regarded as the system_a, the upgrade is required to upgrade the second static partition and the dynamic partition, and when the installation of the OTA upgrade package is restarted, the System sub-partition in the started dynamic partition is regarded as the system_b.

Based on this, referring to fig. 9, a Snapshot node created under the snap shot folder in the base partition may be named system_b.

In addition, it should be noted that, in practical application, the node type of the snapshot node corresponding to each sub-partition to be upgraded in the dynamic partition after creation may be identified by the name of the sub-partition, for example, the node type of the snapshot node of the System sub-partition may be System-dm-snapshot.

In addition, since the Merge operation performed after the subsequent restart needs to be performed by means of the snapshot node, the snapshot node can be used only after the mapping is successful, and therefore, after each mapping is successful, a state identifier for identifying that mapping is successful needs to be written in the snapshot node.

For example, in practical application, valid may be used to identify the success of the mapping, and invalid may be used to identify the failure of the mapping.

By way of example, with continued reference to fig. 9, it can be known from the foregoing description that the current OTA upgrade needs to upgrade a System sub-partition in a dynamic partition, so that a Snapshot node corresponding to the System sub-partition needs to be created in a base partition, and then the snapshot_b.zxid file Map in fig. 9 is processed according to entity data in the System sub-partition and occupied data Snapshot of an empty system_cow sub-partition to a system_b Snapshot node under the Snapshot folder.

Substep S1015, writing the first upgrade file into the first virtual dynamic sub-partition, and canceling the mapping with the snapshot node.

After completing the operations of sub-step S1013 and sub-step S1014 described above, the first upgrade file for upgrading the different first sub-partition is written to the first virtual dynamic sub-partition under the corresponding path.

For example, a first upgrade file for upgrading a System sub-partition is written to a system_cow sub-partition under the "./ ota/system_cow" path, and a first upgrade file for upgrading a system_ext sub-partition is written to a system_ex_cow sub-partition under the "./ ota/system_ex_cow" path.

In addition, it should be noted that, in practical application, after the installation of the OTA upgrade package is completed, the user may not immediately start the electronic device Ma Chong, so in order to avoid always processing the snappshot file Map obtained by processing each first sub-partition and the corresponding first virtual dynamic sub-partition to the corresponding snappshot node, not only the electronic device resource is occupied, but also the risk of tampering the content recorded in the snappshot node exists, after each first upgrade file is written into the corresponding first virtual dynamic sub-partition, unMap needs to be performed on the snappshot node, so that operation cannot be performed on the snappshot node, and the content recorded in the snappshot node is ensured not to be tampered.

In addition, it can be understood that, because the COW file is compressed and saved in the form of binary code, in the technical scheme provided by the embodiment, the occupation of the user data partition can be effectively reduced by writing the first upgrade file into the corresponding first virtual dynamic sub-partition in the form of the COW file, and meanwhile, the subsequent reading speed is improved.

For example, with continued reference to FIG. 9, after the first upgrade file is written to the first virtual dynamic sub-partition created in the user data partition in the form of a COW file according to the operation of sub-step S1015, a "System_COW (2.0)" file as in schematic diagram (2) in FIG. 9 may exist in the first virtual dynamic sub-partition.

Sub-step S1016, changing the boot sequence from booting from the first static partition to booting from the second static partition.

Thus, according to the above-mentioned sub-steps S1011 to S1016, the operation of acquiring the OTA upgrade package in step S101 and installing the OTA upgrade package in the electronic device can be achieved.

Step S102, after the installation of the OTA upgrade package is completed, restarting the electronic device to load the data of the base partition, the second state partition and the dynamic partition in sequence to run the second operating system, and then identifying the snapshot node recorded in the base partition as the snapshot node for executing the Merge operation.

It can be understood that, in this embodiment, when the electronic device starts to run the first operating system for the first time, the electronic device starts from the first static partition, that is, the starting sequence is started from the first static partition, so that the OTA upgrade package is an upgrade performed on the second static partition that is not started currently, so after the installation of the OTA upgrade package is completed, in order to enable the electronic device to run the upgraded second operating system after restarting, the starting sequence recorded in the base partition needs to be changed, that is, the starting sequence is changed from the starting from the first static partition to the starting from the second static partition, and then the electronic device is restarted according to the changed starting sequence.

Furthermore, it should be noted that, as known from the related literature for implementing the Merge operation in the virtual AB mode, the Merge operation needs to be implemented based on the snap shot node created in the above sub-step S1014, and when the Merge operation is performed based on the snap shot node, the node type of the snap shot node needs to be name-dm-snap-target, or name-dm-snap-Merge, that is, the node type needs to be a type capable of identifying that the snap shot node can perform the Merge operation.

It can be understood that the name is specifically the name of the first sub-partition to be upgraded in the dynamic partition, for example, for the snappshot node corresponding to the system_b sub-partition, the modified type is the system_b-dm-Snapshot-target type, so that it is convenient to know that the Merge operation performed on each snappshot node specifically reads the first upgrade file from which first virtual dynamic sub-partition, and then the first upgrade file is dropped to which first sub-partition in the dynamic partition.

In addition, it should be understood that the OTA upgrade package is an upgrade to the operating system, so after the electronic device is restarted by installing the OTA upgrade package, the operating system may be changed from the first operating system to the second operating system. The first and second are to distinguish versions of the operating system, and not to change the type of operating system.

In addition, it should be noted that, in this embodiment, the Merge operation refers to a process of dropping an upgrade file of an upgrade dynamic partition temporarily stored in a user data partition into the dynamic partition, and the Merge state appearing below refers to a state in which the Merge operation is performed, and the persistence state refers to a state in which the Merge operation is stopped.

Step S103, setting the state of the snapshot node to be a Merge state, and adding the state to a Merge queue.

It can be understood that the snapshot node added to the Merge queue is the snapshot node with the node type of name-dm-snapshot-target or name-dm-snapshot-Merge.

It can be understood that, in practical application, since one OTA upgrade may upgrade a plurality of sub-partitions in the dynamic partition, there are a plurality of snap shot nodes waiting for performing the Merge operation, for example, 3 sub-partitions, such as System, system _ext and Product in the dynamic partition shown in fig. 9, all need to be upgraded, and states of snap shot nodes corresponding to the 3 sub-partitions need to be set to Merge state, and sequentially added to the Merge queue, waiting for performing the Merge operation.

Illustratively, before adding a snapshot node in the Merge state to the Merge queue, the Merge queue is internally empty, as shown in Merge queue (1) in fig. 10.

Illustratively, with continued reference to FIG. 10, if the first snapshot node to be added to the Merge queue is the System_b node, the System_b node will be added to the Merge queue from the direction pointed by the arrow in FIG. 10, i.e., the end of the queue, based on the characteristics of the queue.

Accordingly, the Merge queue after adding the system_b node becomes the Merge queue (2) shown in fig. 10.

With continued reference to fig. 10, if the second snapshot node to be added to the Merge queue is the system_ext_b node, the system_ext_b node is added to the Merge queue from the end of the queue in the direction pointed by the arrow in fig. 10 based on the characteristics of the queue.

Accordingly, the Merge queue after adding the system_ext_b node becomes the Merge queue (3) shown in fig. 10.

With continued reference to fig. 10, if the third snapshot node to be added to the Merge queue is the product_b node, the product_b node is added to the Merge queue from the direction pointed by the arrow in fig. 10, i.e., the end of the queue, based on the characteristics of the queue.

Accordingly, the Merge queue after adding the product_b node becomes the Merge queue (4) shown in fig. 10.

Step S104, before performing a Merge operation on the snapshot node in the Merge queue, obtaining a first temperature of the electronic device.

For example, in practical applications, the user perception of whether the electronic device is hot is typically determined from the temperature of the back shell in contact with the palm of the hand, so in one implementation, the first temperature obtained is the back shell temperature of the electronic device.

In another implementation, the obtained first temperature may also be a screen temperature of the electronic device, or a frame temperature, which is not limited in this embodiment.

Furthermore, it should be understood that the reason for the instantaneous temperature rise of the electronic device is that all cores of the CPU are occupied during the Merge process, and the core Wen Huiyuan is far higher than the back shell temperature, the screen temperature, the frame temperature, etc., the user perception is reflected by the temperatures of these external devices (back shell temperature, screen temperature, frame temperature), and whether damage to the internal devices is caused is determined by the core temperature, so in order to be able to solve the two problems (heating of the electronic device affects the user experience, damage to the internal devices causes the machine to be removed), the acquired first temperature may include the back shell temperature (or the screen temperature, the frame temperature) and the core temperature. For convenience of explanation, the temperature at which the back case temperature, the screen temperature, the frame temperature, and the like can be perceived by the user will be hereinafter referred to as an external temperature, and the core temperature will be referred to as an internal temperature.

Step S105, determining whether the first temperature is less than a temperature threshold.

Accordingly, when the first temperature includes the above-mentioned external temperature and internal temperature, the temperature threshold value used for comparison with the first temperature also needs to include two, i.e., one first temperature threshold value corresponding to the external temperature and one second temperature threshold value corresponding to the internal temperature.

It will be appreciated that, since the user perceives the electronic device to be hot after the temperature exceeds the normal body temperature, and the Merge process will generally cause the electronic device to continue to rise by more than 2 ℃ based on the start-up temperature rise, if the normal body temperature is set to 37 ℃, the first temperature threshold needs to be no more than 35 ℃ (37 ℃ -2 ℃), for example, set to 35 ℃. The second temperature threshold may be set according to the temperature that may damage the internal device in the actual test, for example, the second temperature threshold is set to 65 ℃.

Correspondingly, if the first temperature is determined to be not less than the preset temperature threshold value through judgment, executing step S106; otherwise, step S109 is performed.

Further, in one implementation, if the first temperature includes only the external temperature, the determination result only needs to satisfy that the external temperature is less than the first temperature threshold to perform step S109, and otherwise, step S106 may be performed. When the first temperature further includes an internal temperature, the external temperature and the internal temperature are required to be simultaneously smaller than the respective corresponding temperature thresholds to perform step S109, and otherwise, step S106 is performed.

Step S106, taking the snapshot node which does not execute the Merge operation in the Merge queue as a second snapshot node, and modifying the second snapshot node from the Merge state to a persistence state.

It can be understood that the snap-shot node needs Map success, and the state identifier is refreshed to be valid identifier, so that the Merge operation can be performed on the snap-shot node. Therefore, only the snap-shot nodes corresponding to the sub-partition to be upgraded in the dynamic partition recorded in the basic partition are traversed, the snap-shot nodes which can be mapped with the sub-partition to be upgraded in the dynamic partition, namely the nodes which can be Map successful, are screened, then the snap-shot nodes which have completed the Merge operation are deleted from the snap-shot nodes screened for the first time, namely the snap-shot nodes which do not execute the Merge operation in the Merge queue are screened out by performing second screening processing, and in order to be convenient for distinguishing the snap-shot nodes which need to execute the Merge operation but do not execute the Merge operation in the embodiment are called second snap-shot nodes.

After the operation is finished, traversing all the second Snapshot nodes in the Merge queue, and executing the following operations on each traversed second Snapshot node:

determining a third sub-partition corresponding to the second snap shot node and a second virtual dynamic sub-partition corresponding to the third sub-partition according to the traversed Snapshot file corresponding to the second snap shot node; and then, according to the third sub-partition and the second virtual dynamic sub-partition, modifying the second Snapshot node from the Merge state to the Persistent state, and further stopping executing Merge operation on the second Snapshot node.

It should be noted that, the third sub-partition is a sub-partition of the dynamic partition, and the second virtual dynamic sub-partition is a sub-partition created in the user data partition and used for temporarily storing a third upgrade file written into the third sub-partition.

Therefore, through the operation, all the second snap shot nodes which need to execute the Merge operation but do not execute the Merge operation in the Merge queue can be changed from the Merge state to the persistence state, so that all the Merge operation is stopped first, and the temperature of the electronic equipment is not continuously increased.

Further, in order to avoid that the second snap-shot nodes modified to the Persistent state automatically recover to the Merge state because of some factors, so that the electronic device continues to execute the Merge operation, the temperature of the electronic device continues to rise, and after each second snap-shot node is modified from the Merge state to the Persistent state, a sleep lock may be further placed for the second snap-shot nodes, so that a process of processing the Merge operation of the second snap-shot nodes enters the sleep state.

In addition, it should be noted that, in the technical solution provided in this embodiment, the related information of the third sub-partition and the second virtual dynamic sub-partition corresponding to each second snap shot node that needs to stop executing the Merge operation is to be obtained, so as to inform the program which second snap shot node needs to be set to the persistence state specifically when an interface for modifying the status of the snap shot node is called.

For example, an interface for modifying the status of the snappshot node may be, for example, table < DnTargetSnappshot > (0, ole_target [0]. Spec.length, base_device, cow_device, snaps hotStorageMod:: persistence, kSnappshotChunkSize).

The base_device parameter is a third sub-partition, the cow_device is a second virtual dynamic sub-partition, and the third sub-partition, the second virtual dynamic sub-partition and the second snap shot node have Map relation, so that it can be known which second snap shot node needs to stop executing the Merge operation.

Step S107, after the first duration, acquiring a second temperature of the electronic equipment.

For example, the specific source of the second temperature needs to be the same as the source of the second temperature, so that two determinations can be made based on the same temperature threshold, and validity of the determination result is ensured.

Step S108, when the second temperature is less than the temperature threshold, modifying the second snapshot node located at the head of the queue in the Merge queue from the Persistent state to the Merge state.

Note that, regarding the process of taking out the snapshot node from the Merge queue, the Merge operation is performed, for example, as shown in fig. 11. That is, when the current temperature is less than the temperature threshold and the Merge operation can be performed, the first snapshot node system_b is fetched from the head of the Merge queue (arrow direction), and the Merge operation is performed on that node.

Illustratively, referring to FIG. 11, after system_b is fetched from the Merge queue (4), the snapshot nodes within the Merge queue become the Merge queue (5) shown in FIG. 11.

Accordingly, after completing the Merge operation on the system_b node, the temperature of the electronic device is continuously determined according to the above procedure provided in the present embodiment, and when the current temperature is less than the temperature threshold, the first snapshot node system_ext_b is taken out from the queue head of the Merge queue (5), and the Merge operation is performed on the node.

Illustratively, referring to FIG. 11, after system_ext_b is fetched from the Merge queue (5), the snapshot nodes within the Merge queue become the ones shown in Merge queue (6) of FIG. 11.

Accordingly, after completing the Merge operation on the system_ext_b node, the temperature of the electronic device is continuously determined according to the above procedure provided in the present embodiment, and when the current temperature is less than the temperature threshold, the first snapshot node product_b is taken out from the head of the Merge queue (6), and the Merge operation is performed on the node.

Illustratively, referring to FIG. 11, after product_b is fetched from the Merge queue (6), the snapshot nodes within the Merge queue become the Merge queue (7) shown in FIG. 11.

In addition, in practical application, step S108 needs to hold the sleep lock first, that is, wake up the process for executing the Merge operation on the second snapshot node from the sleep state, and then modify the second snapshot node from the persistence state to the Merge state, so that the operation of reading the data from the corresponding virtual dynamic sub-partition in the user data partition to drop the data to the corresponding sub-partition in the dynamic partition can be executed on the second snapshot node.

In addition, it should be understood that, in order to avoid high temperature avoidance for a long time, the execution of the Merge operation is delayed, and thus, the conductive electronic device cannot be started normally in the Merge stage for a long time to affect the use of the user, in practical application, a total duration of stopping the execution of the Merge operation may be set, and then, each time the execution of the Merge operation is stopped, the total duration of stopping the Merge operation in the Merge stage is accumulated.

Accordingly, after a first period of time, for example, 1 minute, if the total current accumulated period of time is less than a preset period of time threshold, for example, 15 minutes, it may be determined whether the current temperature of the electronic device is less than a temperature threshold, that is, the step of obtaining the second temperature of the electronic device is performed, and then step S108 is performed when the second temperature threshold is less than the temperature threshold, otherwise, the second snapshot node is kept in a persistence state, and the execution of the Merge operation is stopped. And then, after the first time length is passed, judging whether the total time length accumulated at present is smaller than a preset time length threshold value or not again, namely, executing the steps again.

Otherwise, after the first time period passes, if the total time period accumulated at present is not less than the preset time period threshold, the step of modifying the second snapshot node located at the head of the queue in the Merge queue from the persistence state to the Merge state is executed no matter whether the second temperature at present of the electronic device is less than the preset temperature threshold, and the step of executing Merge operation on the second snapshot node is executed, so that all Merge operations can be completed within a controllable time range, further OTA upgrading is completed, and a user can normally use the electronic device.

In addition, it should be noted that, in an example, when the total duration of stopping performing the Merge operation is not less than the preset duration threshold, and when the kernel temperature does not exceed a certain threshold, for example, the upper limit temperature of a device may be damaged, the step of performing the Merge operation on the second snapshot node in the Merge queue, which is located at the queue head, is continuously performed regardless of whether the user feels the electronic device to generate heat when the external temperature rises; and when the core temperature exceeds the upper limit temperature, keeping the second snapshot node in a Persistent state, and stopping executing the Merge operation.

Step S109, taking the snapshot node located at the head of the queue in the Merge queue as a first snapshot node, and executing Merge operation on the first snapshot node.

Specifically, for any snapshot node currently executing the Merge operation, the Merge process is roughly divided into two steps of recovering the Map between the snapshot node and the sub-partition, modifying the state flag of the snapshot node, reading the upgrade file from the corresponding virtual dynamic sub-partition in the user data partition, and then landing on the sub-partition corresponding to the dynamic partition, regardless of whether the snapshot node is the first snapshot node or the second snapshot node.

For convenience of explanation, this embodiment will be described with reference to fig. 12 by taking the example of performing the Merge operation on the first snapshot node:

substep S1091, reestablishing a mapping between the first snapshot node and the corresponding snapshot file.

In sub-step S1092, the status identifier is modified to valid after the mapping is successful.

And step 1093, reading the first upgrade file from the first virtual dynamic sub-partition corresponding to the first sub-partition in the user data partition according to the snapshot file mapped to the first snapshot node.

Sub-step S1094, landing the first upgrade file on the first sub-partition.

For example, after the installation of the OTA upgrade package is completed, the electronic device starts to load each partition in turn according to the changed starting sequence, and the whole process of executing the Merge operation after avoiding the high temperature by adopting the technical scheme provided by the embodiment may be shown in fig. 13.

Specifically, in practical application, after the snapshot processing obtains the snapshot file of the system_b.zxid, the system_b.zxid is stored in the base partition, and when the Merge operation needs to be performed on the snapshot node of the system_b, the mapping between the snapshot file of the system_b.zxid and the snapshot node of the system_b needs to be re-established, that is, the system_b.zxid needs to be remapped to the snapshot node of the system_b.

Further, after the two maps succeed, it is indicated that the snapshot node system_b is available, so the state identifier recorded in the snapshot node system_b needs to be modified to be valid.

Then, the Merge operation may be completed according to the operations of sub-steps S1093 and S1094.

It can be appreciated that the above description is given only for the Merge operation of one snapshot node, and in practical application, when the temperature of the electronic device meets the requirement of this embodiment, the Merge operation of the snapshot node in the Merge queue can be implemented according to the operations of sub-steps S1091 to S1094 by continuing to traverse the Merge queue.

In addition, it should be noted that, the first snapshot node and the second snapshot node are only shown above to distinguish the current snapshot node, which is convenient for description, and does not limit the snapshot nodes themselves.

Correspondingly, based on the technical scheme provided by the embodiment, the method adopts the avoidance of high temperature and the execution of the Merge after delay, and intermittently executes the Merge operation according to the temperature and the total duration in the whole Merge stage, so that the situation that the temperature of the electronic equipment is continuously increased after the high temperature phenomenon occurs in the restarting stage, but the temperature is dropped first, and the overheat phenomenon of the electronic equipment is effectively avoided.

Illustratively, based on the scheme for controlling temperature rise in the upgrade process provided in this embodiment, the temperature change is shown in fig. 14, for example, from the stage of downloading the OTA upgrade package to the completion of Merge.

In addition, in practical application, after the Merge operation is performed on each snapshot node, the snapshot node currently completing the Merge operation may be deleted from the base partition, for example, for the first snapshot node currently performing the Merge operation, the first snapshot node completing the Merge operation is deleted from the base partition, for the second snapshot node currently performing the Merge operation, the second snapshot node completing the Merge operation is deleted from the base partition, so that the number of times of traversing the snapshot nodes in the base partition when the second snapshot node needing to stop the Merge operation is determined is reduced.

In addition, in practical application, in order to display the completion condition of the whole Merge in the current OTA upgrading process on a display interface, the user can conveniently check, and a progress bar in the Merge stage can be synthesized based on the progress of the Merge operation corresponding to each snapshot node.

For example, when there are 5 snapshot nodes that need to perform the Merge operation, each snapshot node has a 20% ratio, the Merge operation is completed in 2 snapshot nodes, and 50% is completed in 3 snapshot nodes, and the overall progress bar of the Merge stage is 70% completed.

Therefore, in the method provided by the embodiment of the application, when the electronic device is restarted to enter the Merge stage after the installation of the OTA upgrade package is completed, by checking whether the current temperature of the electronic device is smaller than the preset temperature threshold, the Merge operation is executed when the current temperature of the electronic device is smaller than the temperature threshold, so that even if the Merge operation can cause instant temperature rise, a user cannot feel that the electronic device generates heat when the temperature rising in the Merge operation process is added on the basis of the current temperature, when the current temperature of the electronic device is not smaller than the temperature threshold, the state of a snapshot node which does not execute the Merge operation is modified to be persistence so as to stop executing the Merge operation, and after the first time is set, the snapshot node in the persistence state is modified to be Merge state when the temperature of the electronic device is smaller than the temperature threshold, so that the Merge operation can be performed by the snapshot node, the electronic device in the virtual AB mode can be prevented from generating instant temperature rise when the OTA is restarted to enter the Merge process, and the phenomenon of overheat of the electronic device is avoided when the OTA is restarted.

Therefore, the electronic equipment can be prevented from being heated by a user, the user experience is improved, in addition, the phenomenon that the electronic equipment is damaged by probability devices after OTA upgrading of commercial products and is removed is avoided due to the fact that the hardware bonding pad is cracked due to the fact that the temperature is too high through controlling the temperature.

In addition, considering that the second static partition may not be available due to physical damage of the image, bit jump and the like when the electronic device in the virtual AB mode performs OTA upgrade, if the starting sequence is changed from the first static partition to the second static partition after the installation of the OTA upgrade package is completed, then the electronic device may not be started at all after restarting the second static partition, so that upgrade failure is caused, and more serious, the mobile phone may not be started, so that further improvement is made on the basis of the above embodiment, specifically, when the second static partition is unavailable, the OTA upgrade is completed by means of the first static partition started currently.

Referring to fig. 15, the implementation flow of the modified embodiment specifically includes:

step S201, an OTA upgrade package is obtained, and the OTA upgrade package is installed in the electronic device.

Step S202, after the installation of the OTA upgrade package is completed, determining whether the second static partition can be started based on the start identifier corresponding to the second static partition recorded by the base partition.

Specifically, for the virtual AB mode, the first static partition and the second static partition both have several attributes, active, bootable (Bootable corresponding to Bootable) and Successful. The system only has one partition set as the active attribute, and the bootloader selects the partition set as the active for starting; the Bootable is used for marking that the partition can be started, and the partition set as the Bootable indicates that the partition contains a complete system capable of being started; the UnBooable is used for identifying the unavailable start of the partition, and the partition set as the UnBooable indicates that the partition contains an incomplete system, namely if the static partition identified by the UnBooable is started, the electronic equipment cannot be restarted at all or the version before the OTA upgrading operation is rolled back; the success of the partition is identified by the success of the partition, and a partition set to success indicates that the partition may be operating correctly in the last boot or current boot. Based on the method, whether the second static partition can be started or not can be determined by judging whether the starting identifier recorded in the basic partition is Bootable or not.

Based on the starting identification, when determining whether the second static partition can be started, the second static partition can be determined whether to be started or not according to the starting identification by acquiring the starting identification corresponding to the second static partition from the basic partition.

When the boot identifier corresponding to the second static partition obtained from the base partition is Bootable, it is determined that the second static partition may be booted, and step S203 is performed in this case, that is, the boot sequence is updated to boot from the second static partition, and then the electronic device is restarted according to the changed boot sequence.

Correspondingly, when the starting identifier corresponding to the second static partition obtained from the base partition is un-bootable, it is determined that the second static partition cannot be started, and step S202 is performed under the condition that the electronic device is restarted by performing OTA upgrade in a Recovery mode by means of the first static partition which is currently active.

In addition, it should be noted that, in an actual application scenario, a startup identifier for identifying whether each static partition can be started may be recorded in an X-loader sub-partition in each static partition.

For example, for the current scenario (the first boot load of the electronic device is the first static partition, the OTA upgrade performed after the boot is performed on the second static partition), it needs to be determined whether the second static partition can be booted, so the boot identifier corresponding to the second static partition is obtained from the base partition.

In an implementation manner, the boot identifier corresponding to the second static partition may be obtained from the X-loader sub-partition in the second static partition before the electronic device obtains the OTA upgrade packet, and then the obtained boot identifier is recorded in the base partition.

For example, in another implementation, the boot identifier corresponding to the second static partition may be obtained from the X-loader sub-partition in the second static partition after the electronic device obtains the OTA upgrade packet, and then the obtained boot identifier is recorded in the base partition, as shown in fig. 16 in detail.

And step 203, changing the starting sequence from the first static partition to the second static partition, restarting the electronic device according to the changed starting sequence, enabling the electronic device to sequentially load the data of the basic partition, the second static partition and the dynamic partition to run the operating system, and modifying node types of all snapshot nodes recorded in the basic partition into name-dm-snapshot-target.

It will be appreciated that if in actual application the type used to identify a snapshot node as the snapshot node performing the Merge operation is identified as Merge, then the node type may also be modified to name-dm-snapshot-Merge.

Step S204, starting the electronic equipment in a Recovery mode, copying the file in the first sub-partition to a second sub-partition after the electronic equipment enters the Recovery mode, restarting the electronic equipment according to the starting sequence, enabling the electronic equipment to sequentially load data of a basic partition, a first static partition and a dynamic partition to run an operating system, and modifying node types of all snapshot nodes recorded in the basic partition into name-dm-snapshot-target.

Specifically, when it is determined that the second static partition is not bootable, for example, it may be that the dtbo_b sub-partition in the second static partition in fig. 16 has a mirror physical corruption or a byte (bit) jump, or that other sub-partitions have a mirror physical corruption or a bit jump, the electronic device writes a boot instruction for starting the Recovery mode in the risc sub-partition in the base partition, so that after the electronic device responds to the boot instruction, the electronic device can start in the Recovery mode.

For example, the boot instruction written to the MIsc child partition may be "boot-recovery".

In addition, after the electronic device enters the Recovery mode, the electronic device writes an upgrade instruction of a sub-partition to be upgraded of the second upgrade file in a command file of a cache sub-partition in the base partition, so that after the electronic device responds to the upgrade instruction, the electronic device can copy the second upgrade file written in the vendor_b sub-partition of the second upgrade file to the vendor_a sub-partition in the first static partition.

Illustratively, in this embodiment, the upgrade instruction written to the command file may be determined according to the file name of the second upgrade file written to the second sub-partition.

For example, for an upgrade file in which the second upgrade file is a vendor, the upgrade instruction written to the command file may be "-ota-ab-vendor-update".

Also for example, for an upgrade file where the second upgrade file is a patch, the upgrade instruction written to the command file may be "-ota-ab-patch-update".

Thus, after entering the Recovery mode, the electronic device can know which sub-partition in the second static partition is to copy the upgrade file to the corresponding sub-partition in the first static partition.

For example, referring to diagram (1) in fig. 17, according to the "boot-Recovery" instruction written into the misc sub-partition in the base partition, the Recovery mode is triggered, and then according to the "-ota-ab-vendor-update" instruction written into the command file of the cache sub-partition in the base partition, the vendor_b (2.0) copy mode in which the version upgrade has been completed in the second static partition is copied to the vendor_a sub-partition in the first static partition, so that the vendor_a sub-partition is upgraded from version 1.0 to version 2.0.

In addition, in practical application, when the files in the vendor_b sub-partition are copied to the vendor_a sub-partition, a suitable file copying mode may be selected according to the size of the files, the number of times of copying required, and the desired copying speed.

For example, in one implementation, for a scene with a sub-partition size smaller than 256KB that needs to be replicated, a Buffer vs. filechannel (indirect mode) may be used for replication, and vice versa.

For example, in another implementation, for more times than 7 times, for example, the replication may be performed by using filechannel.

Illustratively, in another implementation, a Path-to-Path approach may be employed for fast replication.

In addition, it should be noted that, in order to ensure that the electronic device may still use the virtual AB mode to start, after copying the file in the vendor_b sub-partition to the vendor_a sub-partition is completed, the starting instruction written in the mis sub-partition needs to be erased, so that when the electronic device starts the starting mode that the base partition reads the record of the mis sub-partition, the electronic device will not read the message started according to the Recovery mode, but still restart according to the virtual AB mode.

For example, after the operation shown in the schematic diagram (1) in fig. 17 is completed, the data of the base partition, the first static partition and the dynamic partition are sequentially loaded according to the loading sequence of the schematic diagram (2) in fig. 17 to run the operating system, and after the operating system is run, it may be determined whether to execute the Merge operation according to the temperature of the electronic device.

In addition, it should be noted that, in practical application, when the starting identifier of the first static partition or the second static partition is an un-Bootable, after the system upgrade is completed and the static partition synchronization is achieved, the repair of the unavailable static partition can be completed later, and then the starting identifier is changed from the un-Bootable to the Bootable, so that step S203 can be normally entered during the subsequent OTA upgrade.

In step S205, the states of all the snapshot nodes of the first type are set to be Merge states, and then are added to the Merge queue, waiting for Merge operation.

Step S206, before performing a Merge operation on the snapshot node in the Merge queue, obtaining a first temperature of the electronic device.

Step S207, judging whether the first temperature is less than a temperature threshold.

Specifically, when the first temperature is less than the temperature threshold, step 211 is performed, and otherwise step 208 is performed.

Step S208, taking the snapshot node which does not execute the Merge operation in the Merge queue as a second snapshot node, modifying the second snapshot node from the Merge state to a persistence state, and stopping executing the Merge operation.

Step S209, after the first duration, acquiring a second temperature of the electronic device.

Step S210, when the second temperature is less than the temperature threshold, modifying the second snapshot node located at the head of the queue in the Merge queue from the Persistent state to the Merge state, and executing a Merge operation on the second snapshot node.

Step S211, taking the snapshot node located at the head of the queue in the Merge queue as a first snapshot node, and executing Merge operation on the first snapshot node.

It is not difficult to find that, in the embodiment shown in fig. 15, steps S201, S203, and S205 to S211 are substantially similar to steps S101 to S109 in the embodiment shown in fig. 7, and specific implementation details of this embodiment may be referred to the description of the embodiment shown in fig. 7, which is not repeated herein.

Therefore, the method provided by the embodiment of the application not only can achieve the effects of the embodiment, but also can achieve the following effects by effectively controlling the temperature of the electronic equipment: after writing the upgrade file in the OTA upgrade package into the corresponding sub-partition in the second static partition and the virtual dynamic sub-partition penetrating the piece in the user data partition, determining whether the second static partition is available or not according to the starting identification corresponding to the second static partition, namely, whether the electronic equipment can be restarted by taking the second static partition as a starting inlet or not, and finishing OTA upgrade by means of the first static partition running currently when the starting identification is unavailable, thereby improving the upgrade success rate and the reliability of products.

In addition, it should be understood that, the description of the above embodiment only shows that the electronic device is started from the first static partition before the OTA upgrade, writing of the upgrade file is performed on the second static partition in the process of the OTA upgrade, and specific description is performed in a scenario that the electronic device is started from the second static partition after the installation of the OTA upgrade package is completed.

In addition, the "first", "second", "third", "fourth", etc. appearing in the technical solutions provided in the embodiments of the present application are merely examples listed for better understanding of the technical solutions of the embodiments, and are not the only limitation of the embodiments.

In addition, it should be noted that, in an actual application scenario, the method for controlling the upgrade temperature provided in the foregoing embodiments implemented by the electronic device may also be performed by a chip system included in the electronic device, where the chip system may include a processor. The chip system may be coupled to a memory such that the chip system, when running, invokes a computer program stored in the memory, implementing the steps performed by the electronic device described above. The processor in the chip system can be an application processor or a non-application processor.

In addition, the embodiment of the application further provides a computer readable storage medium, and the computer storage medium stores computer instructions, which when executed on the electronic device, cause the electronic device to execute the related method steps to implement the method for controlling the upgrade temperature in the embodiment.

In addition, the embodiment of the application further provides a computer program product, when the computer program product runs on the electronic device, the electronic device is caused to execute the related steps, so as to realize the method for controlling the upgrade temperature in the embodiment.

In addition, embodiments of the present application also provide a chip (which may also be a component or module) that may include one or more processing circuits and one or more transceiver pins; the transceiver pin and the processing circuit communicate with each other through an internal connection path, and the processing circuit executes the related method steps to implement the method for controlling the upgrade temperature in the above embodiment, so as to control the receiving pin to receive signals and control the transmitting pin to transmit signals.

In addition, as can be seen from the foregoing 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 used to perform the corresponding methods provided above, and therefore, the advantages achieved by the method can refer to the advantages in the corresponding methods provided above, which are not repeated herein.

Furthermore, it should be understood that the above embodiments are merely illustrative of the technical solutions of the present application, and not limiting thereof; 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 scheme described in the foregoing embodiments can be modified or some technical features thereof can be replaced by equivalents; such modifications and substitutions do not depart from the essence of the corresponding technical solutions from the technical solutions of the embodiments of the present application.

Claims

1. The method for controlling the upgrade temperature is characterized by being applied to an electronic device with a data storage structure in a virtual AB mode, wherein the electronic device comprises a processor and a memory, the memory comprises a basic partition, a first static partition, a second static partition, a dynamic partition and a user data partition, the electronic device is started and then loads data of the basic partition, the first static partition and the dynamic partition in sequence to run a first operating system, and after the first operating system is run, the method comprises the following steps:

acquiring an upgrade package, and installing the upgrade package in the electronic equipment;

after the upgrade package is installed, restarting the electronic equipment to load the data of the basic partition, the second static partition and the dynamic partition in sequence to run a second operating system, and marking snapshot nodes recorded in the basic partition as snapshot nodes for executing a Merge operation, wherein the Merge operation is a process of landing upgrade files of upgrading the dynamic partition in a user data partition to the dynamic partition;

Setting the state of the snapshot node as a Merge state, and adding the Merge state into a Merge queue, wherein the Merge state is a state for executing Merge operation;

before the operation of the Merge is executed on the snapshot node in the Merge queue, when the first temperature of the electronic equipment is not less than a temperature threshold value, the snapshot node which does not execute the Merge operation in the Merge queue is modified from the Merge state to a persistence state, wherein the persistence state is a state of stopping executing the Merge operation.

2. The method according to claim 1, wherein the method further comprises:

and after the first time, when the second temperature of the electronic equipment is smaller than the temperature threshold value, modifying the snapshot node at the head of the queue in the Merge queue from the Persistent state to the Merge state.

3. The method of claim 1, wherein the obtaining an upgrade package, installing the upgrade package in the electronic device, comprises:

the upgrade package is obtained, the upgrade package comprises a first upgrade file and a second upgrade file, the first upgrade file corresponds to a first sub-partition, the first sub-partition is a sub-partition of the dynamic partition, the second upgrade file corresponds to a second sub-partition, and the second sub-partition is a sub-partition of the second static partition;

Performing data writing operation on the second sub-partition according to the second upgrading file;

creating a first virtual dynamic sub-partition corresponding to the first sub-partition in the user data partition, and carrying out snapshot processing on the first sub-partition and the first virtual dynamic sub-partition to obtain a snapshot file;

creating a snapshot node corresponding to the first sub-partition in the base partition, and mapping the snapshot file to the snapshot node;

writing the first upgrade file into the first virtual dynamic sub-partition, and canceling mapping with the snapshot node;

and changing the starting sequence from the starting of the first static partition to the starting of the second static partition.

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

and before performing the Merge operation on the snapshot node in the Merge queue, performing the Merge operation on the snapshot node at the head of the Merge queue when the first temperature of the electronic equipment is smaller than the temperature threshold.

5. The method of claim 4, wherein performing a Merge operation on the snapshot node at the head of a queue in the Merge queue comprises:

Reestablishing mapping between the snapshot node and the corresponding snapshot file;

and reading the first upgrade file from the first virtual dynamic sub-partition corresponding to the first sub-partition in the user data partition according to the snapshot file mapped to the snapshot node, and landing the first upgrade file on the first sub-partition.

6. The method of claim 3, wherein prior to said modifying the snapshot node in the Merge queue that did not perform a Merge operation from the Merge state to a Persistent state, the method further comprises:

traversing snapshot nodes corresponding to the sub-partitions to be upgraded in the dynamic partition, which are recorded in the basic partition, and screening snapshot nodes with mapping relations with the sub-partitions to be upgraded in the dynamic partition;

and deleting the snapshot node which has completed the Merge operation from the screened snapshot nodes, and obtaining the snapshot node which does not execute the Merge operation in the Merge queue.

7. The method of claim 6, wherein the modifying the snapshot node in the Merge queue that did not perform Merge operations from the Merge state to a persistence state comprises:

Determining a third sub-partition corresponding to the snapshot node and a second virtual dynamic sub-partition corresponding to the third sub-partition according to the snapshot file corresponding to the snapshot node, wherein the third sub-partition is one sub-partition of the dynamic partition, and the second virtual dynamic sub-partition is a sub-partition which is created in the user data partition and is used for temporarily storing a third upgrade file written into the third sub-partition;

and modifying the snapshot node from the Merge state to a persistence state according to the third sub-partition and the second virtual dynamic sub-partition.

8. The method of any of claims 1-7, wherein after said modifying the snapshot node in the Merge queue that did not perform Merge operations from the Merge state to a persistence state, the method further comprises:

accumulating the total duration of stopping executing the Merge operation in the Merge stage;

when the total duration is less than a duration threshold and the second temperature of the electronic device is less than the temperature threshold, executing the step of modifying the snapshot node at the head of the queue in the Merge queue from the persistence state to the Merge state;

And when the total duration is not less than the duration threshold, executing the step of modifying the snapshot node which does not execute the Merge operation in the Merge queue from the Merge state to a Persistent state.

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

and deleting the snapshot node which completes the Merge operation from the basic partition.

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

traversing snapshot nodes corresponding to sub-partitions to be upgraded in the dynamic partition, which are recorded in the basic partition, in the process of executing the Merge operation;

for each traversed snapshot node, determining the progress of the Merge operation;

and refreshing the total progress bar of the electronic equipment in the Merge stage according to the progress of the Merge operation corresponding to each snapshot node.

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

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

the program instructions, when executed by the processor, cause the electronic device to perform the method of controlling an upgrade temperature as claimed in any one of claims 1 to 10.

12. A computer readable storage medium comprising a computer program, characterized in that the computer program, when run on an electronic device, causes the electronic device to perform the method of controlling an upgrade temperature according to any one of claims 1 to 10.

13. A computer program product, characterized in that the computer program product comprises a computer program which, when run on an electronic device, causes the electronic device to carry out the method of controlling an upgrade temperature according to any one of claims 1 to 10.