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

Abstract

This application provides a method, apparatus, storage medium, and computer program product for controlling upgrade temperature. When the electronic device restarts and enters the Merge phase after the upgrade package is installed, the method reduces the instantaneous temperature rise during the upgrade restart and Merge process by avoiding high-temperature points and performing the Merge operation intermittently. This prevents the electronic device from overheating, thus avoiding the user's perception of heat and improving the user experience. Furthermore, by controlling the temperature, it also prevents hardware pads from cracking due to excessive temperature, which could lead to probabilistic component damage after a commercial product upgrade and ultimately result in product rejection.

Description

Technical Field

[0001] This application relates to the field of computer technology, and in particular to a method, apparatus, storage medium, and computer program product for controlling temperature rise. Background Technology

[0002] Over-the-Air (OTA) upgrades are a method of remotely upgrading electronic devices via their wireless network interfaces. They aim to upgrade the underlying operating system, read-only applications installed on the system partition, and / or timezone rules. Essentially, OTA upgrades can be performed while the user is using the electronic device normally. Currently, in some application scenarios, to ensure the success of OTA upgrades while minimizing the system data's storage footprint and freeing up more storage space for user data, electronic devices supporting virtual A / B testing (AB) modes are becoming increasingly common.

[0003] For electronic devices with a virtual AB data storage structure, since dynamic partitions exist as single partitions, during OTA upgrades, the upgrade files that need to be written to the dynamic partition are temporarily stored in the user data partition. Only after the sub-partitions in the currently unbooted static partition have completed their upgrades and the electronic device restarts and enters the Merge process will the upgrade files temporarily stored in the user data partition be written to the dynamic partition. Because the Merge process requires the simultaneous use of all cores of the electronic device's Central Processing Unit (CPU), this generates a significant instantaneous temperature rise. This causes the electronic device's temperature to continue rising beyond the initial startup temperature, resulting in a noticeable increase in heat for the user and impacting the user experience. Even worse, in extreme scenarios, excessively high temperatures can affect the reliability of internal components, leading to cracked hardware pads and probabilistic component damage after OTA upgrades in commercial products, ultimately resulting in product rejection. Summary of the Invention

[0004] To address the aforementioned technical problems, this application provides a method, apparatus, storage medium, and computer program product for controlling upgrade temperature, aiming to reduce instantaneous temperature rise and prevent overheating in electronic devices with a data storage structure in virtual AB mode during the OTA upgrade and merge process.

[0005] Firstly, this application provides a method for controlling upgrade temperature. The method is applied to an electronic device with a data storage structure in virtual AB mode. The electronic device includes a processor and a memory. The memory includes a base partition, a first static partition, a second static partition, a dynamic partition, and a user data partition. After the electronic device starts, it sequentially loads data from the base partition, the first static partition, and the dynamic partition to run a first operating system. After the first operating system runs, the method includes: obtaining an upgrade package and installing the upgrade package in the electronic device; after the upgrade package is installed, restarting the electronic device and sequentially loading data from the base partition, the second static partition, and the dynamic partition to run a second operating system, and then marking the snapshot nodes recorded in the base partition. The snapshot node is identified as performing a Merge operation, which is the process of writing the upgrade file of the dynamic partition in the user data partition to the dynamic partition. The snapshot node is set to the Merge state and added to the Merge queue. The Merge state is the state of performing a Merge operation. Before performing a Merge operation on the snapshot node in the Merge queue, if the first temperature of the electronic device is not less than a temperature threshold, the snapshot node in the Merge queue that has not performed a Merge operation is changed from the Merge state to the Persistent state. The Persistent state is the state of stopping the Merge operation.

[0006] Therefore, the method provided in this application embodiment, when restarting the electronic device after the upgrade package is installed and entering the Merge stage, checks whether the current temperature of the electronic device is less than a preset temperature threshold. If the current temperature of the electronic device is not less than the temperature threshold, the state of the snapshot node that has not performed the Merge operation is modified to Persistent to stop the Merge operation, thereby preventing the temperature of the electronic device from continuing to rise, thus avoiding the phenomenon of overheating of the electronic device and ensuring the user experience.

[0007] This prevents users from feeling that electronic devices are overheating, thus improving the user experience. In addition, by controlling the temperature, it also prevents the hardware pads from cracking due to excessive temperature, which could lead to probabilistic component damage after commercial product upgrades and result in product returns.

[0008] According to the first aspect, after a first duration, when the second temperature of the electronic device is less than the temperature threshold, the snapshot node at the head of the Merge queue is changed from the Persistent state to the Merge state. Thus, by setting a first duration and then changing the snapshot node from the Persistent state to the Merge state only when the temperature of the electronic device is less than the temperature threshold, the snapshot node can perform a Merge operation. By avoiding high-temperature points and performing Merge operations during gaps, the electronic device in virtual AB mode can successfully complete the Merge operation for all snapshot nodes and reduce the instantaneous temperature rise during the upgrade restart and Merge process, preventing overheating of the electronic device.

[0009] According to the first aspect, or any implementation thereof, the step of obtaining the upgrade package and installing the upgrade package in the electronic device includes: obtaining the upgrade package, the upgrade package including a first upgrade file and a second upgrade file, the first upgrade file corresponding to a first sub-partition, the first sub-partition being a sub-partition of the dynamic partition, the second upgrade file corresponding to a second sub-partition, the second sub-partition being a sub-partition of the second static partition; performing a data writing operation on the second sub-partition according to the second upgrade file; creating a first virtual dynamic sub-partition corresponding to the first sub-partition in the user data partition, 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 to the first virtual dynamic sub-partition, and canceling the mapping with the snapshot node; changing the boot order from booting from the first static partition to booting from the second static partition. In this way, when temporarily storing the upgrade files used to upgrade sub-partitions in the dynamic partition in the upgrade package to the user data partition, a snapshot node corresponding to the sub-partition to be upgraded is first created in the base partition. Then, using snapshot technology, the snapshot file after snapshot processing of the current physical data of the sub-partition and the placeholder data of the virtual dynamic sub-partition without real data is mapped to the corresponding snapshot node. This allows the electronic device to directly determine which sub-partitions in the dynamic partition to write the temporarily stored upgrade files in each virtual dynamic sub-partition of the user data partition to disk when it restarts and enters the Merge stage to perform the Merge operation, based on the snapshot nodes recorded in the base partition. This achieves the ability to quickly and accurately determine the target of the Merge operation. At the same time, since the creation of snapshot nodes and the establishment of mappings do not need to be performed when restarting the electronic device, it can effectively shorten the time spent in the Merge stage and avoid the operation occupying the kernel, thereby avoiding the increase in temperature.

[0010] According to the first aspect, or any implementation of the first aspect above, before performing a merge operation on the snapshot node in the merge queue, if the first temperature of the electronic device is less than the temperature threshold, a merge operation is performed on the snapshot node at the head of the merge queue. In this way, the merge operation is only performed when the temperature is below the temperature threshold, so even if the merge operation causes a momentary temperature rise, the user will not feel that the electronic device is getting hot, even if the merge operation causes a momentary temperature rise.

[0011] According to the first aspect, or any implementation of the first aspect above, performing a merge operation on the snapshot node at the head of the merge queue includes: re-establishing the mapping between the snapshot node and the corresponding snapshot file; 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 writing the first upgrade file to the first sub-partition.

[0012] According to the first aspect, or any implementation of the first aspect above, before modifying the snapshot nodes in the Merge queue that have not performed the Merge operation from the Merge state to the Persistent state, the method further includes: traversing the snapshot nodes recorded in the base partition that correspond to the sub-partitions in the dynamic partition that need to be upgraded, and filtering out the snapshot nodes that have a mapping relationship with the sub-partitions in the dynamic partition that need to be upgraded; deleting the snapshot nodes that have completed the Merge operation from the filtered snapshot nodes, thereby obtaining the snapshot nodes in the Merge queue that have not performed the Merge operation. The solution provided in this application embodiment, through the first filtering, can identify the snapshot nodes that have successfully mapped and need to perform the Merge operation, and then through the second filtering, delete the snapshot nodes that have completed the Merge operation, thus obtaining all snapshot nodes that need to perform the Merge operation but have not yet performed it.

[0013] According to the first aspect, or any implementation of the first aspect above, modifying the snapshot node in the Merge queue that has not performed a Merge operation from the Merge state to the Persistent 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 based on the snapshot file corresponding to the snapshot node, wherein 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 for temporarily storing the third upgrade file written to the third sub-partition; and modifying the second snapshot node from the Merge state to the Persistent state based on the third sub-partition and the second virtual dynamic sub-partition. In this way, configuring the snapshot node to the Persistent state based on the third sub-partition and the second virtual dynamic sub-partition stops the operation of writing the third upgrade file temporarily stored in the second virtual dynamic sub-partition to the third sub-partition, i.e., stops performing the Merge operation on the snapshot node, thereby allowing the electronic device to cool down first and preventing the temperature of the electronic device from continuing to rise.

[0014] According to the first aspect, or any implementation of the first aspect above, after modifying the snapshot nodes in the Merge queue that have not performed Merge operations from the Merge state to the Persistent state, the method further includes: accumulating the total duration for which Merge operations are stopped during the Merge phase; when the total duration is less than a duration threshold and the second temperature of the electronic device is less than the temperature threshold, performing the step of modifying the snapshot node at the head of the Merge queue from the Persistent state to the Merge state; when the total duration is not less than the duration threshold, performing the step of modifying the snapshot node at the head of the Merge queue from the Persistent state to the Merge state. The solution provided in this application, by introducing a timeout mechanism, ensures that when the total duration for which Merge operations are stopped is not less than a preset duration threshold, the Merge operation is not stopped regardless of whether the electronic device is in a high-temperature range, i.e., whether the current temperature of the electronic device is not less than the temperature threshold. This ensures that the electronic device completes the Merge operation within a controllable time, thereby completing the upgrade and maintaining the reliability of the electronic device.

[0015] According to the first aspect, or any implementation of the first aspect above, the method further includes: deleting the snapshot node that has completed the Merge operation from the base partition. In this way, after each Merge operation is performed, the snapshot node that has completed the Merge operation is deleted from the base partition, thereby reducing the number of times the snapshot nodes in the base partition are traversed when determining which snapshot node needs to have its Merge operation stopped.

[0016] According to the first aspect, or any implementation of the first aspect above, the method further includes: during the Merge operation, traversing the snapshot nodes recorded in the base partition corresponding to the sub-partitions to be upgraded in the dynamic partition; determining the progress of the Merge operation for each traversed snapshot node; and refreshing the overall progress bar of the electronic device in the Merge stage according to the progress of the Merge operation corresponding to each snapshot node. In the solution provided by the embodiments of this application, the progress bar of the Merge stage is synthesized based on the progress of the Merge operation corresponding to each snapshot node, thereby enabling users to easily understand the overall completion status of the Merge during this upgrade process.

[0017] Secondly, this application provides an electronic device in a virtual AB mode, comprising a processor and a memory. The memory includes a base partition, a first static partition, a second static partition, a dynamic partition, and a user data partition. After startup, the electronic device sequentially loads data from the base partition, the first static partition, and the dynamic partition to run a first operating system. The memory is coupled to the processor, and the memory stores program instructions. When the program instructions are executed by the processor, the electronic device executes instructions of the first aspect or any implementation thereof.

[0018] Thirdly, this application provides a computer-readable medium for storing a computer program that, when run on an electronic device, causes the electronic device to execute instructions of the method in the first aspect or any implementation thereof.

[0019] Fourthly, this application provides a computer program product comprising a computer program that, when run on an electronic device, causes the electronic device to execute instructions of the method in the first aspect or any implementation thereof.

[0020] Fifthly, this application provides a chip including a processing circuit and transceiver pins. The transceiver pins and the processing circuit communicate with each other via an internal connection path. The processing circuit executes instructions of the method in the first aspect or any implementation thereof to control the receiving pin to receive signals and to control the transmitting pin to transmit signals. Attached Figure Description

[0021] Figure 1 This is a schematic diagram of the hardware structure of an electronic device as an example.

[0022] Figure 2 This is a schematic diagram illustrating the data storage structure of Recovery mode, AB mode, and virtual AB mode;

[0023] Figure 3 This is an exemplary schematic diagram illustrating a scenario where the client and server interact to obtain an OTA upgrade package;

[0024] Figure 4 This is an exemplary diagram illustrating the sequential loading of partitions when an electronic device is started from a first static partition;

[0025] Figure 5 This is an illustrative diagram illustrating the process from downloading the OTA upgrade package to merging during an operating system upgrade.

[0026] Figure 6 This is an exemplary schematic diagram of the temperature rise curve of an electronic device that directly enters the Merge stage after the OTA upgrade package is installed and the electronic device is restarted.

[0027] Figure 7 This is one of the schematic flowcharts illustrating an embodiment of the method for controlling the temperature of an upgrade provided in this application.

[0028] Figure 8 This is an example implementation shown. Figure 7 The diagram shown illustrates the specific process of step S101.

[0029] Figure 9 This is an exemplary diagram illustrating the writing of upgrade files from an OTA upgrade package to a static partition and a user data partition;

[0030] Figure 10 This is an exemplary diagram illustrating the addition of a snapshot node of the Merge state to the Merge queue;

[0031] Figure 11 This is an exemplary diagram illustrating a snapshot node that retrieves the Merge state from the Merge queue;

[0032] Figure 12This is an example implementation shown. Figure 7 The diagram shown illustrates the specific process of step S109.

[0033] Figure 13 This is an exemplary diagram illustrating how, when an electronic device is started from a second static partition, each partition is loaded sequentially and the Merge process is executed.

[0034] Figure 14 This is a schematic diagram of the temperature rise curve of an electronic device during the Merge operation of the method for controlling the upgrade temperature provided in this application embodiment, which is an exemplary illustration.

[0035] Figure 15 This is a second schematic flowchart illustrating an embodiment of the method for controlling the temperature of an upgrade provided in this application.

[0036] Figure 16 This is an exemplary schematic diagram illustrating the acquisition of the boot identifier of the second static partition;

[0037] Figure 17 This is an exemplary diagram illustrating how, when an electronic device is started from a first static partition, each partition is loaded sequentially and the Merge process is executed. Detailed Implementation

[0038] The following will be combined with the drawings in the embodiments of this application to clearly and completely describe the technical solutions in the embodiments of this application. Obviously, the embodiments described are part of the embodiments of this application, not all of them. Based on the embodiments in this application, all other embodiments obtained by ordinary technicians in this field without making creative efforts are within the scope of protection of this application.

[0039] In this article, the term "and / or" is merely a description of the relationship between related objects, indicating that there can be three relationships. For example, A and / or B can represent three situations: A exists alone, A and B exist simultaneously, and B exists alone.

[0040] The terms "first" and "second," etc., used in the specification and claims of this application are used to distinguish different objects, not to describe a specific order of objects. For example, "first target object" and "second target object," etc., are used to distinguish different target objects, not to describe a specific order of target objects.

[0041] In the embodiments of this application, the terms "exemplary" or "for example" are used to indicate that something is an example, illustration, or description. Any embodiment or design that is described as "exemplary" or "for example" in the embodiments of this application should not be construed as being more preferred or advantageous than other embodiments or design. Specifically, the use of the terms "exemplary" or "for example" is intended to present the relevant concepts in a specific manner.

[0042] In the description of the embodiments in this application, unless otherwise stated, "multiple" means two or more. For example, multiple processing units means two or more processing units; multiple systems means two or more systems.

[0043] To better understand the technical solutions provided in the embodiments of this application, before describing the technical solutions in the embodiments of this application, the hardware structure of the electronic devices (such as mobile phones, tablet devices, PC devices, etc.) to which the embodiments of this application are applicable will be described first in conjunction with the accompanying drawings.

[0044] See Figure 1 The electronic device 100 may include: a processor 110, an external memory interface 120, an internal memory 121, a universal serial bus (USB) interface 130, a charging management module 140, a power management module 141, a battery 142, an antenna 1, an antenna 2, a mobile communication module 150, a wireless communication module 160, an audio module 170, a sensor module 180, a button 190, a motor 191, an indicator 192, a camera 193, a display screen 194, and a subscriber identification module (SIM) card interface 195, etc.

[0045] For example, the audio module 170 may include a speaker 170A, a receiver 170B, a microphone 170C, a headphone jack 170D, etc.

[0046] For example, the sensor module 180 may include a pressure sensor, a gyroscope sensor, a barometric pressure sensor, a magnetic sensor, an accelerometer, a distance sensor, a proximity sensor, a fingerprint sensor, a temperature sensor, a touch sensor, an ambient light sensor, a bone conduction sensor, etc.

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

[0048] Understandably, in a practical implementation, different processing units can be independent devices or integrated into one or more processors.

[0049] Furthermore, in some embodiments, the controller may serve as the central nervous system and command center of the electronic device 100. The controller can generate operation control signals based on instruction opcodes and timing signals to control the fetching and execution of instructions.

[0050] Furthermore, the memory in processor 110 is primarily used to store instructions and data. In some embodiments, the memory in processor 110 is a cache memory.

[0051] Furthermore, it is understandable that in practical application scenarios, the executable program code that triggers the electronic device 100 to implement various functional applications and data processing is stored in the internal memory 121. This executable program code includes instructions.

[0052] For example, in the technical solution provided in the embodiments of this application, the startup of the electronic device 100 and the upgrade of the OTA upgrade package mainly involve the internal memory 121. That is, the relevant instructions for implementing the method of controlling the upgrade temperature provided in the embodiments of this application are pre-stored in the internal memory 121. The processor 110 executes the instructions stored in the internal memory 121, thereby enabling the electronic device 100 to execute the method of controlling the upgrade temperature provided in the embodiments of this application.

[0053] Furthermore, it should be noted that in a specific implementation, the internal memory 121 may include a program storage area and a data storage area. The program storage area may store the operating system, at least one application program required for a given function (such as sound playback, image playback, etc.). The data storage area may store data created during the use of the electronic device 100 (such as audio data, phonebook, etc.). Additionally, the internal memory 121 may include high-speed random access memory, and may also include non-volatile memory, such as at least one disk storage device, flash memory device, universal flash storage (UFS), etc.

[0054] For example, regarding the stored program area, in the technical solutions provided in the embodiments of this application, it may be a basic partition (Common), a static partition (Slot), and a dynamic partition (Super); regarding the stored data area, in the technical solutions provided in the embodiments of this application, it may be a user data partition (Userdata).

[0055] For ease of explanation, this application takes the upgrade scenario based on OTA technology as an example, that is, the upgrade package obtained is an OTA upgrade package.

[0056] Furthermore, it is understandable that in practical application scenarios, the basic partition usually stores content that will not be upgraded during OTA upgrades, the static and dynamic partitions store content that may be upgraded during OTA upgrades, and the user data partition stores data created during the use of electronic devices, which is usually not upgraded during OTA upgrades to avoid data loss and impact on user experience after the upgrade.

[0057] For example, in practical applications, the data storage structure of the internal memory 121 of the electronic device 100 may be, for example, Recovery mode, AB mode and virtual AB mode, and the boot mode of the electronic device 100 with different data storage structures is also different.

[0058] It should be noted that in practical applications, the data storage structure and the boot mode are usually consistent. That is, an electronic device with a data storage structure in Recovery mode will also have a boot mode in Recovery mode; an electronic device with a data storage structure in AB mode will also have a boot mode in AB mode; and an electronic device with a data storage structure in virtual AB mode will also have a boot mode in virtual AB mode.

[0059] Specifically, based on the characteristics of the four types of partitions mentioned above, partitions that do not need to be upgraded during operating system upgrades, such as the basic partition and user data partition, are all single partitions regardless of whether they are in Recovery mode, AB mode, or virtual AB mode. However, the partitions that need to be upgraded will be different.

[0060] For example, because OTA upgrades are performed in Recovery mode, other functions of the electronic device are unavailable during the upgrade process. The device remains on the Recovery mode upgrade screen until the OTA upgrade is complete and the device restarts, at which point it can access the user interface and function normally. Therefore, in Recovery mode, both static and dynamic partitions use a single partition. See details... Figure 2 The data storage structure diagram of Recovery mode in the diagram (1) can reduce the memory space occupied, so as to reserve more space for user data partitioning.

[0061] For example, AB mode is designed to allow users to return to the main interface of their electronic device at any time during OTA upgrades, thus not affecting the device's usability. Therefore, in AB mode, static and dynamic partitions are used in a dual-partition manner; see details below. Figure 2The AB mode data storage structure diagram (2) shows that static partitions can be divided into a first static partition (SlotA) and a second static partition (SlotB), and dynamic partitions can be divided into a first dynamic partition (SuperA) and a second dynamic partition (SuperB). Although this partitioning method allows electronic devices to return to the main interface of the electronic device at will during OTA upgrades, it will occupy a large amount of memory space, greatly reducing the available space for user data partitions.

[0062] For example, the virtual AB mode combines the advantages of Recovery mode and AB mode. It divides the static partition (containing smaller files, i.e., occupying less storage space) into a first static partition (Slot A) and a second static partition (Slot B), while the dynamic partition (containing larger files, i.e., occupying more storage space) is treated as a single partition. See details... Figure 2 A schematic diagram of the virtual AB mode data storage structure (3).

[0063] It should be noted that, in practical applications, the partitioning deployment information of the internal memory in electronic devices can be described by the partitioning table shown in Table 1.

[0064] Table 1 Partition Table

[0065]

[0066]

[0067] In this way, by defining the starting address and size of each partition through the partition table, the partition size can be adjusted as needed for different hardware.

[0068] It should be understood that the above description is merely an example provided to better understand the technical solution of this embodiment, and is not intended to be the only limitation of this embodiment.

[0069] In other words, in practical applications, the partitions recorded in the partition table can be configured according to actual business needs.

[0070] Other than regarding Figure 2 (2) and Figure 2 The distribution of partitions in memory using dual partitioning shown in (3) is not limited to Figure 2 (2) and Figure 2 As shown in (3), in practical applications, the location of each partition is determined according to the allocated start address and end address.

[0071] This concludes the introduction to the hardware structure of electronic device 100. It should be understood that... Figure 1The electronic device 100 shown is merely an example. In a specific implementation, the electronic device 100 may have more or fewer components than those shown in the figure, may combine two or more components, or may have different component configurations. Figure 1 The various components shown can be implemented in hardware, software, or a combination of hardware and software, including one or more signal processing and / or application-specific integrated circuits.

[0072] Specifically, in the technical solution of this application embodiment, the upgrade process of the operating system is described in detail using an electronic device with a data storage structure of virtual AB mode as an example.

[0073] It should be noted that in practical applications, with the development of Over-the-Air Technology (OTA), OTA upgrades, which remotely upgrade terminal devices via their wireless network interfaces, are becoming increasingly common. In this application, the temperature control scheme for upgrades described in the embodiments is based on an OTA upgrade scenario. For example, see [link to relevant documentation]. Figure 3 The OTA upgrade package used to upgrade the operating system version is provided by the package acquisition server to the OTA server in the cloud for management. The OTA server will send the corresponding OTA upgrade package to the electronic device based on the request for obtaining the OTA upgrade package initiated by different electronic devices on the end device (such as PC devices, tablet devices, mobile phones, etc.), or the OTA server will actively push the corresponding electronic device after receiving the OTA upgrade package sent by the package acquisition server.

[0074] For example, the OTA upgrade package sent by the package ordering server to the OTA server can be sent proactively by the package ordering server after it has been created, or it can be sent by the OTA server to the OTA server after the package ordering server sends a request to obtain the OTA upgrade package, provided that the package ordering server already has the OTA upgrade package.

[0075] For details on how the packet-selling server creates OTA upgrade package versions, pushes OTA upgrade packages to the OTA server, and how the OTA server pushes OTA upgrade packages to electronic devices, please refer to existing implementation schemes; this application will not elaborate on these aspects.

[0076] For ease of explanation, based on the above hardware structure, the following assumes that the electronic device boots from the first static partition before an OTA upgrade. That is, the electronic device loads data sequentially from the base partition, the first static partition, and the dynamic partition during startup (the specific loading order is as follows). Figure 4 As shown in the figure, the technical solution provided in this application embodiment will be described in detail in the following scenario: after the OTA upgrade package is installed, the system starts from the second static partition.

[0077] Before describing the temperature control scheme provided in the embodiments of this application, let's first combine... Figure 5 and Figure 6 This document provides a brief explanation of the scheme for performing a Merge operation on an electronic device by booting from the second static partition after the existing OTA upgrade package has been installed.

[0078] For example, see Figure 5 The electronic device (e.g., a mobile phone) launched from SlotA is currently running operating system version v1.0. In one specific implementation, after the OTA server obtains the OTA upgrade package for upgrading the operating system of the electronic device from the package server, it can actively push the OTA upgrade package to the electronic device. After the electronic device completes the operation of downloading the OTA upgrade package from the OTA server, it will verify the downloaded OTA upgrade package and install the OTA upgrade package after the verification is successful.

[0079] For example, installing an OTA upgrade package essentially involves writing the upgrade files from the OTA upgrade package used to upgrade the static partition to the currently unbooted static partition, and temporarily storing the upgrade files from the OTA upgrade package used to upgrade the dynamic partition to the user data partition before the electronic device restarts.

[0080] For example, see [link to example]. Figure 5 This involves writing the upgrade files used to upgrade the dynamic partition to the second static partition.

[0081] Understandably, in practical applications, upgrading the second static partition can be done by upgrading one of the sub-partitions, multiple sub-partitions, or all sub-partitions.

[0082] Correspondingly, upgrading a dynamic partition can be done by upgrading one of the subpartitions, multiple subpartitions, or all subpartitions.

[0083] See Figure 5 Taking the upgrade of the System subpartition in a dynamic partition as an example, the virtual dynamic subpartition created in the user data partition corresponds to the System subpartition.

[0084] For example, in one implementation, the upgrade files subsequently written to the virtual dynamic subpartition created in the user data partition are saved as copy-on-write (COW) files. Therefore, the format of the virtual dynamic subpartition is System_COW, and its specific path could be, for example, System_COW. Figure 5 The "... / ota / System_COW" in the text.

[0085] See also Figure 5After the OTA upgrade package is installed, the electronic device will boot from SlotB and perform a Merge operation, which will write the upgrade file temporarily stored in the virtual dynamic subpartition created in the user data partition to the corresponding subpartition of the dynamic partition, thereby completing the OTA upgrade and changing the operating system of the electronic device to version v2.0 running on SlotB.

[0086] for Figure 5 The drawbacks of the proposed upgrade method are combined with Figure 6 It is clear that, under relatively stable ambient temperature conditions, the screen temperature, back cover temperature, and bezel temperature of electronic devices all exhibit a similar trend throughout the OTA upgrade process. From the moment the OTA upgrade package is downloaded and started until its installation, the temperature continuously rises, with the first small peak occurring upon restarting the device. The loading of partitions during the restart process, along with the immediate Merge operation, further increases the temperature, leading to… Figure 6 The second peak in this process. Extensive testing revealed that when the temperature of an electronic device exceeds the normal human body temperature, such as 37°C, continuing to perform the Merge operation will cause the device to rise by more than 2°C from its current temperature. When the temperature of the electronic device exceeds the normal human body temperature, the user will feel that the device is overheating, thus affecting the user experience.

[0087] To address the above problems, the technical solutions provided in the embodiments of this application are proposed. See also Figure 7 The implementation process of the method for controlling the temperature upgrade provided in this application embodiment specifically includes:

[0088] Step S101: Obtain the OTA upgrade package and install the OTA upgrade package in the electronic device.

[0089] For example, regarding the implementation process of step S101 in this embodiment, see [link to documentation]. Figure 8 Provide a specific implementation method, which includes:

[0090] Sub-step S1011: Obtain the OTA upgrade package.

[0091] As described above, electronic devices can obtain OTA upgrade packages either by actively requesting them from the OTA server or by passively receiving them from the OTA server. This embodiment does not impose any restrictions on this.

[0092] Furthermore, for ease of explanation, the OTA upgrade package obtained in this embodiment includes a first upgrade file and a second upgrade file, and the first upgrade file corresponds to a first subpartition, which is a subpartition of the dynamic partition, and the second upgrade file corresponds to a second subpartition, which is a subpartition of the second static partition.

[0093] Understandably, in practical applications, there may be multiple subpartitions that need to be upgraded for static and dynamic partitions. The OTA upgrade package may include multiple first upgrade files for upgrading subpartitions in the dynamic partition, thereby enabling the upgrading of different subpartitions in the dynamic partition based on different first upgrade files.

[0094] Accordingly, the OTA upgrade package may also include multiple second upgrade files for upgrading sub-partitions in the second static partition, thereby enabling the upgrading of different sub-partitions in the second static partition based on different second upgrade files.

[0095] Furthermore, it should be noted that in practical applications, since there is a one-to-one correspondence between the subpartitions in the first static partition and the subpartitions in the second static partition, the first upgrade file mentioned above, which corresponds to the first subpartition in the second static partition, also corresponds to the subpartition in the first static partition that corresponds to the first subpartition. For example, when the first subpartition is patch_b, the subpartition in the first static partition that corresponds to patch_b is patch_a.

[0096] Sub-step S1012: Perform a data writing operation on the second sub-partition according to the second upgrade file.

[0097] For example, in practical applications, after parsing the first upgrade file and the second upgrade file from the OTA upgrade package, the static partition that is not currently being operated on is determined as the static partition to be operated on in this OTA upgrade based on the boot order recorded in the basic partition. Then, the sub-partition corresponding to the second upgrade file in the static partition is determined as the sub-partition to be operated on in this OTA upgrade based on the second upgrade file. Next, the address path of the determined sub-partition is obtained, for example, the start address and end address of the sub-partition recorded in the partition table are obtained. Finally, the second upgrade file is written to the determined sub-partition based on the obtained path address.

[0098] In this specific embodiment, since the boot order starts from the first static partition, the second static partition, which is not currently booted, is determined as the static partition to be operated on in this OTA upgrade.

[0099] Accordingly, based on the second upgrade file, the second subpartition in the second static partition is determined as the subpartition to be operated on in this OTA upgrade.

[0100] Finally, the path address of the second subpartition is obtained from the partition table, and then the second upgrade file is written to the second subpartition according to the obtained path address.

[0101] For example, taking a scenario where both the first and second static partitions include three subpartitions: X-loader, vendor, and dtbo, as follows: Figure 9 The OTA upgrade package includes three second upgrade files: X-loader_a, vendor_a, and dtbo_a in Slot A, and X-loader_b, vendor_b, and dtbo_b in Slot B. These files are used to upgrade the aforementioned three sub-partitions. When it's determined that the static partition to be upgraded is the second static partition, the second upgrade files for upgrading the X-loader_b sub-partition will be written to the X-loader_b sub-partition, the second upgrade files for upgrading the vendor_b sub-partition will be written to the vendor_b sub-partition, and the second upgrade files for upgrading the dtbo_b sub-partition will be written to the dtbo_b sub-partition. See details... Figure 9 The schematic diagram (1) is shown in the figure.

[0102] Accordingly, based on the above methods, in the context of Figure 9 In the schematic diagram (1), after the data writing operation is performed on X-loader_b, vendor_b, and dtbo_b, which are currently all version 1.0 in SlotB, the versions of X-loader_b, vendor_b, and dtbo_b will change to 1.0. Figure 9 Version 2.0 is shown in the schematic diagram (2).

[0103] Sub-step S1013: Create a first virtual dynamic sub-partition in the user data partition corresponding to the first sub-partition, and perform snapshot processing on the first sub-partition and the first dynamic virtual sub-partition to obtain a snapshot file.

[0104] Understandably, because in virtual AB mode, the dynamic partition in the storage is a single partition, the first upgrade file is temporarily stored in the user data partition before the electronic device restarts. After the electronic device restarts, the base partition, the second static partition, and the dynamic partition are loaded sequentially according to the changed boot order. Only when the Merge operation is performed will the first upgrade file be read from the user data partition and written to the corresponding subpartition of the dynamic partition. Therefore, during the installation of the OTA upgrade package, a first virtual dynamic subpartition needs to be created in the user data partition to temporarily store the first upgrade file, based on the size of the first upgrade file, and then the first upgrade file is written to the created first virtual dynamic subpartition.

[0105] Furthermore, it should be noted that when the electronic device restarts after the OTA upgrade package is installed, the Merge operation is typically performed using snapshot technology. This requires a Snapshot node that can establish a mapping between the virtual dynamic subpartition and the corresponding first subpartition. Before the Merge operation, the Snapshot node maps the entity data in the first subpartition before the first upgrade file was written, along with the placeholder data from the corresponding first virtual dynamic subpartition, resulting in a snapshot file after snapshot processing.

[0106] The placeholder data mentioned above in the first virtual dynamic subpartition refers to the "0"s used as placeholders when creating the first virtual dynamic subpartition based on the size of the first upgrade file. That is, before the first upgrade file is written to the first virtual dynamic subpartition, all the contents recorded in the first virtual dynamic subpartition are "0"s, which have no actual meaning.

[0107] Specifically, in the technical solution provided in this embodiment, by taking snapshots of the physical data of the first sub-partition in the dynamic partition before the upgrade and the empty first virtual dynamic sub-partition in the user data partition, and then mapping the obtained snapshot file to the corresponding Snapshot node, it is possible to quickly and accurately determine which virtual dynamic sub-partitions in the user data partition need to be written to which sub-partition in the dynamic partition during the subsequent Merge operation.

[0108] For example, see [link to example]. Figure 9 The diagram (1) shows that when the first subpartition to be upgraded in the dynamic partition is System, the specific path of the first virtual dynamic subpartition created in the user data partition can be, for example, "... / ota / System_COW".

[0109] Understandably, in Figure 9 In the schematic diagram (1), the path is "... / ota / System_COW". The first virtual dynamic subpartition has not yet been written with physical data. At this time, based on the first virtual dynamic subpartition and the snapshot file processed by the snapshot of the first subpartition in the dynamic partition, it can be seen that... Figure 9 The schematic diagram (1) shows System_b.zxid on the left.

[0110] Sub-step S1014: Create a snapshot node in the base partition corresponding to the first sub-partition, and map the snapshot file to the snapshot node.

[0111] For example, in this embodiment, the snapshot nodes created in the base partition that correspond to the sub-partitions in each dynamic partition that needs to be upgraded can be stored in the Snapshot folder in the base partition.

[0112] Taking the System subpartition in the dynamic partition that needs to be upgraded as an example, since the current boot is the first static partition, logically the System subpartition in the dynamic partition is regarded as System_a. However, this upgrade will upgrade both the second static partition and the dynamic partition. When the OTA upgrade package is installed and restarted, it will boot from the second static partition. Therefore, the System subpartition in the dynamic partition after booting will be regarded as System_b.

[0113] Based on this, see Figure 9 In the base partition, the snapshot node created under the Snapshot folder can be named System_b.

[0114] In addition, it should be noted that in practical applications, the node type of the snapshot node of each subpartition that needs to be upgraded in the corresponding dynamic partition can be identified by the name of the subpartition after creation. For example, the node type of the snapshot node of the System subpartition can be System-dm-snapshot.

[0115] In addition, since the Merge operation performed after a subsequent restart requires the use of snapshot nodes, and snapshot nodes can only be used after a successful mapping, a status flag indicating that the mapping was successful needs to be written into the snapshot node after each successful mapping.

[0116] For example, in practical applications, "valid" can usually be used to indicate that the mapping was successful, and "invalid" can be used to indicate that the mapping failed.

[0117] For example, see [link to example]. Figure 9 As described above, this OTA upgrade requires upgrading the System sub-partition in the dynamic partition. Therefore, a Snapshot node corresponding to the System sub-partition needs to be created in the base partition, and then... Figure 9 The Snapshot_b.zxid file, which is processed based on the entity data in the System subpartition and the placeholder data in the empty System_COW subpartition, is mapped to the System_b snapshot node in the Snapshot folder.

[0118] Sub-step S1015: Write the first upgrade file to the first virtual dynamic sub-partition and cancel the mapping with the snapshot node.

[0119] After completing the above sub-steps S1013 and S1014, the first upgrade file used to upgrade different first sub-partitions will be written to the first virtual dynamic sub-partition under the corresponding path.

[0120] For example, the first upgrade file for upgrading the System subpartition is written to the System_COW subpartition under the path "... / ota / System_COW", and the first upgrade file for upgrading the system_ext subpartition is written to the system_ex_COW subpartition under the path "... / ota / system_ex_COW".

[0121] Furthermore, it should be noted that in practical applications, users may not immediately restart their electronic devices after the OTA upgrade package is installed. Therefore, to avoid continuously mapping the Snapshot files obtained from the Snapshot processing of each first subpartition and the corresponding first virtual dynamic subpartition to the corresponding Snapshot node, which would both consume electronic device resources and pose a risk of tampering with the content recorded in the Snapshot node, it is necessary to unmap the Snapshot node after writing each first upgrade file to the corresponding first virtual dynamic subpartition. This prevents operations on the Snapshot node and ensures that the content recorded in the Snapshot node is not tampered with.

[0122] Furthermore, it is understandable that since COW files are compressed and saved in binary code form, the technical solution provided in this embodiment can effectively reduce the occupation of user data partitions and improve subsequent reading speed by writing the first upgrade file into the corresponding first virtual dynamic sub-partition in the form of a COW file.

[0123] For example, see [link to example]. Figure 9 After writing the first upgrade file as a COW file to the first virtual dynamic subpartition created in the user data partition according to the operation of sub-step S1015, the first virtual dynamic subpartition will contain the following: Figure 9 The “System_COW(2.0)” file in the schematic diagram (2) is shown.

[0124] Sub-step S1016: Change the boot order from booting from the first static partition to booting from the second static partition.

[0125] Therefore, by following the sub-steps S1011 to S1016 above, the operation of obtaining the OTA upgrade package and installing the OTA upgrade package in the electronic device in step S101 can be realized.

[0126] Step S102: After the OTA upgrade package is installed, the electronic device is restarted and the data of the basic partition, the second state partition and the dynamic partition are loaded in sequence to run the second operating system. Then, the snapshot node recorded in the basic partition is identified as the snapshot node for performing the Merge operation.

[0127] Understandably, in this embodiment, when the electronic device first starts running the first operating system, it starts from the first static partition, that is, the boot order is from the first static partition. Therefore, the OTA upgrade package is an upgrade of the second static partition that is not currently booted. Therefore, after the OTA upgrade package is installed, in order for the electronic device to run the upgraded second operating system after restarting, it is necessary to change the boot order recorded in the base partition, that is, change the boot order from the first static partition to the second static partition, and then restart the electronic device according to the changed boot order.

[0128] Furthermore, it should be noted that, according to relevant literature on Merge operations based on the virtual AB mode, the Merge operation needs to be implemented based on the Snapshot node created in the above sub-step S1014, and when performing the Merge operation based on the Snapshot node, the node type of the Snapshot node needs to be name-dm-snapshot-target or name-dm-snapshot-merge, that is, the node type needs to be a type that can identify that the snapshot node can perform the Merge operation.

[0129] Understandably, the "name" mentioned above is specifically the name of the first subpartition in the dynamic partition that needs to be upgraded. For example, for the Snapshot node corresponding to the System_b subpartition, the modified type is System_b-dm-snapshot-target, which makes it easier to know which first virtual dynamic subpartition the Merge operation for each Snapshot node reads the first upgrade file from and then writes the first upgrade file to which first subpartition in the dynamic partition.

[0130] Furthermore, it should be understood that OTA (Over-The-Air) upgrade packages upgrade the operating system. Therefore, after installing an OTA upgrade package and restarting the electronic device, the operating system will change from the first operating system to the second operating system. The "first" and "second" here are to distinguish the operating system version, not to change the type of operating system.

[0131] In addition, it should be noted that the Merge operation mentioned in this embodiment specifically refers to the process of writing the upgrade file of the upgrade dynamic partition temporarily stored in the user data partition to the dynamic partition. The Merge state mentioned below refers to the state of executing the Merge operation, and the Persistent state refers to the state of stopping the Merge operation.

[0132] Step S103: Set the state of the snapshot node to Merge state and add it to the Merge queue.

[0133] Understandably, the snapshot nodes added to the Merge queue are snapshot nodes with node types name-dm-snapshot-target or name-dm-snapshot-merge.

[0134] Understandably, in practical applications, a single OTA upgrade may upgrade multiple sub-partitions in a dynamic partition. Therefore, there will be multiple snapshot nodes waiting to perform the Merge operation, for example... Figure 9 If the three sub-partitions System, system_ext, and Product in the dynamic partition shown in the figure all need to be upgraded, then the state of the Snapshot node corresponding to these three sub-partitions needs to be set to Merge state and added to the Merge queue in sequence, waiting to execute the Merge operation.

[0135] For example, before adding a snapshot node with a Merge state to the Merge queue, the Merge queue is as follows: Figure 10 The Merge queue (1) in the image is empty.

[0136] For example, see [link to example]. Figure 10 If the first snapshot node to be added to the Merge queue is a System_b node, based on the characteristics of the queue, it will be added from... Figure 10 The direction the middle arrow points to, i.e., the tail of the queue, is where the System_b node is added to the Merge queue.

[0137] Accordingly, the Merge queue after adding the System_b node will become Figure 10 The Merge queue (2) is shown in the figure.

[0138] See also Figure 10 If the second snapshot node to be added to the Merge queue is a System_ext_b node, based on the characteristics of the queue, it will be selected from... Figure 10 The direction the middle arrow points to, i.e., the tail of the queue, is where the System_ext_b node is added to the Merge queue.

[0139] Accordingly, the Merge queue after adding the System_ext_b node will become Figure 10 The Merge queue (3) is shown in the figure.

[0140] See also Figure 10 If the third snapshot node to be added to the Merge queue is a Product_b node, based on the characteristics of the queue, it will be added from... Figure 10 The direction the middle arrow points to, i.e., the tail of the queue, is where the Product_b node is added to the Merge queue.

[0141] Accordingly, the Merge queue after adding the Product_b node will become Figure 10 The Merge queue (4) is shown.

[0142] Step S104: Before performing the Merge operation on the snapshot nodes in the Merge queue, obtain the first temperature of the electronic device.

[0143] For example, in practical applications, whether a user perceives an electronic device as hot is usually determined based on the temperature of the back cover in contact with the palm of the hand. Therefore, in one implementation, the first temperature obtained is the temperature of the back cover of the electronic device.

[0144] For example, in another implementation, the first temperature obtained may also be the screen temperature of the electronic device or the frame temperature, and this embodiment does not limit this.

[0145] Furthermore, it should be understood that the instantaneous temperature rise of electronic devices is caused by the fact that all CPU cores are occupied during the Merge process. The core temperature is significantly higher than the back cover temperature, screen temperature, and bezel temperature. The user's perception is reflected by the temperatures of these external components (back cover temperature, screen temperature, bezel temperature), while whether internal components will be damaged is determined by the core temperature. Therefore, in order to simultaneously address both issues (electronic device overheating affecting user experience, and internal component damage leading to rejection), the first temperature obtained can include not only the back cover temperature (or screen temperature, bezel temperature) but also the core temperature. For ease of explanation, the back cover temperature, screen temperature, bezel temperature, and other temperatures that can be perceived by the user will be referred to as external temperatures, and the core temperature will be referred to as internal temperatures.

[0146] Step S105: Determine whether the first temperature is less than the temperature threshold.

[0147] Accordingly, when the first temperature includes the aforementioned external temperature and internal temperature, the temperature threshold used for comparison with the first temperature also needs to include two, namely a first temperature threshold corresponding to the external temperature and a second temperature threshold corresponding to the internal temperature.

[0148] Understandably, users will perceive heat from electronic devices when the temperature exceeds normal human body temperature. The Merge process typically causes the temperature rise by more than 2°C on top of the initial startup temperature. Therefore, if normal human body temperature is set to 37°C, the first temperature threshold should not exceed 35°C (37°C - 2°C), for example, set to 35°C. The second temperature threshold can be set based on the temperatures that might damage internal components during actual testing, for example, setting the second temperature threshold to 65°C.

[0149] Accordingly, if it is determined that the first temperature is not less than the preset temperature threshold, then step S106 is executed; otherwise, step S109 is executed.

[0150] Furthermore, in one implementation, if the first temperature only includes the external temperature, then the judgment result only needs to satisfy that the external temperature is less than the first temperature threshold to execute step S109; otherwise, step S106 is executed. When the first temperature also includes the internal temperature, both the external temperature and the internal temperature need to be less than their respective temperature thresholds to execute step S109; otherwise, step S106 is executed.

[0151] It should be understood that the above description is merely an example provided to better understand the technical solution of this embodiment, and is not intended to be the only limitation of this embodiment.

[0152] Step S106: Select the snapshot node in the Merge queue that has not performed the Merge operation as the second snapshot node, and change the second snapshot node from the Merge state to the Persistent state.

[0153] Understandably, a Snapshot node needs to successfully map and refresh its status to "valid" before a Merge operation can be performed on it. Therefore, it is only necessary to traverse the Snapshot nodes recorded in the base partition that correspond to the sub-partitions in the dynamic partition that need to be upgraded, and filter out the Snapshot nodes that can be mapped to the sub-partitions in the dynamic partition that need to be upgraded, i.e., the nodes that can be successfully mapped. Then, delete the Snapshot nodes that have completed the Merge operation from the first filtered Snapshot nodes, i.e., perform the second filtering process, which can filter out the Snapshot nodes in the Merge queue that have not yet performed the Merge operation. For ease of distinction, this embodiment refers to these Snapshots that need to perform the Merge operation but have not yet performed the Merge operation as the second Snapshot nodes.

[0154] After completing the above operations, iterate through all the second Snapshot nodes in the Merge queue, and perform the following operations on each second Snapshot node encountered:

[0155] Based on the snapshot file corresponding to the traversed second Snapshot node, determine the third sub-partition corresponding to the second Snapshot node and the second virtual dynamic sub-partition corresponding to the third sub-partition; then, based on the third sub-partition and the second virtual dynamic sub-partition, change the second Snapshot node from the Merge state to the Persistent state, thereby stopping the Merge operation on the second Snapshot node.

[0156] 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 for temporarily storing the third upgrade file written to the third sub-partition.

[0157] Therefore, through the above operations, all second snapshot nodes in the Merge queue that need to perform Merge operations but have not yet performed Merge operations can be changed from the Merge state to the Persistent state. In this way, all Merge operations will stop, and the temperature of the electronic device will not continue to rise.

[0158] Furthermore, to prevent the second snapshot node, which has been modified to the Persistent state, from automatically reverting to the Merge state due to certain factors, causing the electronic device to continue performing the Merge operation and its temperature to continue to rise, a hibernation lock can be placed on each second snapshot node after it has been modified from the Merge state to the Persistent state, so that the process handling the Merge operation of that second snapshot node can enter a hibernation state.

[0159] Furthermore, it should be noted that in the technical solution provided in this implementation, the reason for obtaining the relevant information of the third sub-partition and the second virtual dynamic sub-partition corresponding to each second Snapshot node that needs to stop performing the Merge operation is to inform the program which second Snapshot node needs to be set to the Persistent state when calling the interface for modifying the state of the Snapshot node.

[0160] For example, an interface for modifying the state of a Snapshot node could be table.Emplace. <dntargetsnapshot>(0,ole_target[0].spec.length,base_device,cow_device,SnapshotStorageMod::Persistent,kSnapshotChunkSize).

[0161] The base_device parameter is the third sub-partition, and the cow_device is the second virtual dynamic sub-partition. The third sub-partition, the second virtual dynamic sub-partition, and the second Snapshot node have a Map relationship, so it can be determined which specific second Snapshot node needs to stop performing the Merge operation.

[0162] Step S107: After the first duration, obtain the second temperature of the electronic device.

[0163] For example, the specific source of the second temperature needs to be the same as the source of the second temperature, so that two judgments can be made based on the same temperature threshold, ensuring the validity of the judgment result.

[0164] Step S108: When the second temperature is less than the temperature threshold, the second snapshot node at the head of the Merge queue is changed from the Persistent state to the Merge state.

[0165] It should be noted that the process of retrieving snapshot nodes from the Merge queue and performing the Merge operation, for example... Figure 11 As shown. That is, when the current temperature is below the temperature threshold and a Merge operation can be performed, the first snapshot node System_b is taken from the head of the Merge queue (arrow direction), and the Merge operation is performed on that node.

[0166] For example, see Figure 11 After retrieving System_b from the Merge queue (4), the snapshot node in the Merge queue becomes Figure 11 The Merge queue (5) is shown in the figure.

[0167] Accordingly, after completing the Merge operation on the System_b node, the temperature of the electronic device is determined according to the above process given in this embodiment. When the current temperature is less than the temperature threshold, the first snapshot node System_ext_b is taken from the head of the Merge queue (5) and the Merge operation is performed on the node.

[0168] For example, see Figure 11 After retrieving System_ext_b from the Merge queue (5), the snapshot nodes in the Merge queue become Figure 11 The Merge queue (6) is shown in the figure.

[0169] Accordingly, after completing the Merge operation on the System_ext_b node, the temperature of the electronic device is determined according to the above process given in this embodiment. When the current temperature is less than the temperature threshold, the first snapshot node Product_b is taken from the head of the Merge queue (6) and the Merge operation is performed on the node.

[0170] For example, see Figure 11 After retrieving Product_b from the Merge queue (6), the snapshot node in the Merge queue becomes Figure 11 The Merge queue (7) is shown.

[0171] In addition, in practical applications, step S108 requires holding a hibernation lock first, that is, waking up the process used to perform the Merge operation on the second snapshot node from the hibernation state, and then changing the second snapshot node from the Persistent state to the Merge state. In this way, the operation of reading data from the virtual dynamic sub-partition corresponding to the user data partition and writing it to the corresponding sub-partition in the dynamic partition can be performed on the second snapshot node.

[0172] Furthermore, it should be understood that in order to avoid prolonged exposure to high temperatures and delay the Merge operation, which could lead to electronic devices remaining in the Merge phase for an extended period and failing to start normally, thus affecting user experience, in practical applications, a total duration for stopping the Merge operation can be set, and then the total duration of stopping the Merge operation can be accumulated each time it is stopped.

[0173] Accordingly, after a first duration, such as 1 minute, if the current accumulated total duration is less than a preset duration threshold, such as 15 minutes, it can be determined whether the current temperature of the electronic device is less than the temperature threshold. That is, the step of obtaining the second temperature of the electronic device is executed. Then, if the second temperature threshold is less than the temperature threshold, step S108 is executed; otherwise, the second snapshot node remains in the Persistent state, and the Merge operation is stopped. Then, after another first duration, it is re-determined whether the current accumulated total duration is less than the preset duration threshold, and the above steps are executed again.

[0174] Conversely, after the first duration, if the current accumulated total duration is not less than the preset duration threshold, then regardless of whether the current second temperature of the electronic device is less than the preset temperature threshold, the step of changing the second snapshot node at the head of the Merge queue from the Persistent state to the Merge state and performing the Merge operation on the second snapshot node will be executed. This ensures that all Merge operations can be completed within a controllable time range, thereby completing this OTA upgrade and enabling users to use the electronic device normally.

[0175] Furthermore, it should be noted that, in one example, the total duration of stopping the Merge operation can be set to be no less than a preset duration threshold. If the kernel temperature does not exceed a certain threshold, such as an upper limit temperature that would damage the device, the steps of changing the second snapshot node at the head of the Merge queue from the Persistent state to the Merge state and performing the Merge operation on the second snapshot node can continue, regardless of whether the increase in external temperature will make the user feel that the electronic device is hot. However, if the kernel temperature exceeds the upper limit temperature, the second snapshot node is kept in the Persistent state, and the Merge operation is stopped.

[0176] It should be understood that the above description is merely an example provided to better understand the technical solution of this embodiment, and is not intended to be the only limitation of this embodiment.

[0177] Step S109: The snapshot node at the head of the Merge queue is taken as the first snapshot node, and the Merge operation is performed on the first snapshot node.

[0178] Specifically, for any snapshot node currently performing a Merge operation, whether it is the first snapshot node or the second snapshot node, the Merge process is roughly divided into two steps: restoring the Map between the snapshot node and the sub-partition, modifying the status flag of the snapshot node, and reading the upgrade file from the corresponding virtual dynamic sub-partition in the user data partition and then writing it to the sub-partition corresponding to the dynamic partition.

[0179] For ease of explanation, this embodiment takes the Merge operation performed on the first snapshot node as an example, combined with... Figure 12 Explanation:

[0180] Sub-step S1091: Re-establish the mapping between the first snapshot node and the corresponding snapshot file.

[0181] Sub-step S1092: After successful mapping, change the status flag to valid.

[0182] Sub-step S1093: Based on the snapshot file mapped to the first snapshot node, read the first upgrade file from the first virtual dynamic sub-partition corresponding to the first sub-partition in the user data partition.

[0183] Sub-step S1094: Write the first upgrade file to the first sub-partition.

[0184] For example, after the OTA upgrade package is installed, the electronic device starts up according to the changed boot order, loads each partition sequentially, and performs the Merge operation after avoiding high temperature using the technical solution provided in this embodiment. The overall process can be found in [reference needed]. Figure 13 As shown.

[0185] Specifically, in practical applications, after obtaining the snapshot file System_b.zxid through snapshot processing, System_b.zxid is stored in the base partition. When a merge operation is required on the snapshot node System_b, the mapping between the snapshot file System_b.zxid and the snapshot node System_b needs to be re-established, that is, System_b.zxid needs to be remapped to the snapshot node System_b.

[0186] Furthermore, after the Map operation is successful, it indicates that the snapshot node System_b is available. Therefore, the status flag recorded in the snapshot node System_b needs to be changed to valid.

[0187] Next, the Merge operation can be completed by following the steps S1093 and S1094.

[0188] Understandably, the above description only applies to the Merge operation for a single snapshot node. In practical applications, when the temperature of the electronic device meets the requirements of this embodiment, the Merge operation for the snapshot node can be implemented by continuing to traverse the Merge queue and performing sub-steps S1091 to S1094 on the snapshot nodes in the Merge queue.

[0189] In addition, it should be noted that the first snapshot node and the second snapshot node mentioned above are only for distinguishing the current snapshot node and for ease of description, and do not constitute any restriction on the snapshot node itself.

[0190] Accordingly, based on the technical solution provided in this embodiment, the system avoids high temperatures and delays the Merge operation. During the entire Merge phase, the Merge operation is performed intermittently according to the temperature and total duration. This prevents the electronic device from experiencing a high temperature during the restart phase and causing the temperature to continue to rise. Instead, the temperature drops first, effectively preventing the electronic device from overheating.

[0191] For example, based on the temperature rise control scheme provided in this embodiment during the upgrade process, from the OTA upgrade package download stage to the completion of Merge, the temperature change is as follows: Figure 14 As shown.

[0192] It should be understood that the above description is merely an example provided to better understand the technical solution of this embodiment, and is not intended to be the only limitation of this embodiment.

[0193] Furthermore, in practical applications, after performing the merge operation on each snapshot node, the snapshot node that has completed the merge operation can be deleted from the base partition. For example, if the first snapshot node is currently performing the merge operation, then the first snapshot node that has completed the merge operation will be deleted from the base partition. If the second snapshot node is currently performing the merge operation, then the second snapshot node that has completed the merge operation will be deleted from the base partition. This reduces the number of times snapshot nodes in the base partition are traversed when determining the second snapshot node that needs to stop the merge operation.

[0194] In addition, in practical applications, in order to display the overall completion status of the Merge process during this OTA upgrade on the display interface for easy viewing by users, the progress bar of the Merge stage can be synthesized based on the progress of the Merge operation corresponding to each snapshot node.

[0195] For example, if there are 5 snapshot nodes that need to perform the Merge operation, and each snapshot node accounts for 20%, then if 2 snapshot nodes have completed the Merge operation and the other 3 have each completed 50%, then the overall progress bar of the Merge stage will be 70% complete.

[0196] It should be understood that the above description is merely an example provided to better understand the technical solution of this embodiment, and is not intended to be the only limitation of this embodiment.

[0197] Therefore, the method provided in this application embodiment checks whether the current temperature of the electronic device is lower than a preset temperature threshold when the electronic device restarts after the OTA upgrade package is installed and enters the Merge stage. The Merge operation is only performed when the temperature is lower than the temperature threshold. Thus, even if the Merge operation causes a momentary temperature rise, the user will not feel that the electronic device is getting hot, even if the Merge operation causes a momentary temperature rise. When the current temperature of the electronic device is not lower than the temperature threshold, the state of the snapshot node that has not performed the Merge operation is changed to Persistent to stop the Merge operation. After setting a first time, when the temperature of the electronic device is lower than the temperature threshold, the snapshot node in the Persistent state is changed to the Merge state so that the snapshot node can perform the Merge operation. By avoiding high temperature points and performing the Merge operation in a gap, the electronic device in virtual AB mode can reduce the momentary temperature rise when restarting after an OTA upgrade and entering the Merge process, thus avoiding overheating of the electronic device.

[0198] This prevents users from feeling that electronic devices are overheating, thus improving the user experience. In addition, by controlling the temperature, it also prevents the hardware pads from cracking due to excessive temperature, which could cause probabilistic component damage after OTA upgrades of commercial products and lead to product returns.

[0199] Furthermore, considering that the second static partition may become unusable during OTA upgrades of electronic devices in virtual AB mode due to physical image damage, bit transitions, or other reasons, if the boot order is changed directly from the first static partition to the second static partition after the OTA upgrade package is installed, and the electronic device is then restarted from the second static partition, the second static partition may not be able to boot at all, leading to upgrade failure. In more serious cases, the phone may not be able to boot. Therefore, to avoid this situation, a further improvement has been made based on the above embodiment. Specifically, when the second static partition is unusable, the OTA upgrade is completed by using the currently booted first static partition.

[0200] See Figure 15 The implementation process of the improved embodiment specifically includes:

[0201] Step S201: Obtain the OTA upgrade package and install the OTA upgrade package in the electronic device.

[0202] Step S202: After the OTA upgrade package is installed, determine whether the second static partition can be started based on the boot identifier corresponding to the second static partition recorded in the basic partition.

[0203] Specifically, in virtual AB mode, both the first and second static partitions have the attributes active, bootable (and corresponding to unBootable), and successful. Active identifies the currently active partition; this is an exclusive attribute, and only one partition can be set to active. During startup, the bootloader selects the active partition for booting. Bootable indicates that the partition is bootable; a partition set to Bootable indicates that it contains a complete bootable system. UnBootable indicates that the partition is not bootable; a partition set to unBootable indicates that it contains an incomplete system. Booting an unBootable static partition might prevent the device from rebooting or cause a rollback to a version prior to the OTA upgrade. Successful indicates that the partition is running successfully; a partition set to Successful indicates that it ran correctly during the previous or current boot. Therefore, by simply determining whether the boot identifier recorded in the base partition is Bootable or unBootable, it is possible to determine whether the second static partition is bootable.

[0204] Therefore, when determining whether the second static partition can be booted, the boot identifier corresponding to the second static partition is obtained from the basic partition, and then the boot identifier can be used to determine whether the second static partition can be booted.

[0205] For example, 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 can be booted. In this case, step S203 is entered, that is, the boot order is upgraded to boot from the second static partition, and then the electronic device is restarted according to the changed boot order.

[0206] Correspondingly, when the boot identifier of the second static partition obtained from the basic partition is unBootable, it is determined that the second static partition cannot boot. In this case, proceed to step S202, that is, use the currently active first static partition to perform OTA upgrade in Recovery mode and restart the electronic device.

[0207] In addition, it should be noted that in practical application scenarios, the boot flag used to identify whether each static partition can be booted can be recorded in the X-loader subpartition of each static partition.

[0208] For example, in the current scenario (the electronic device loads the first static partition upon initial startup, and the OTA upgrade performed after startup is performed on the second static partition), it is necessary to determine whether the second static partition can be started. Therefore, the startup identifier corresponding to the second static partition is obtained from the basic partition.

[0209] For example, in one implementation, the boot identifier corresponding to the second static partition can be obtained from the X-loader sub-partition in the second static partition before the electronic device receives the OTA upgrade package, and then the obtained boot identifier is recorded in the base partition.

[0210] For example, in another implementation, the boot identifier corresponding to the second static partition can be obtained from the X-loader sub-partition in the second static partition after the electronic device receives the OTA upgrade package, and then the obtained boot identifier is recorded in the base partition. See details. Figure 16 As shown.

[0211] Step S203: Change the boot order from booting from the first static partition to booting from the second static partition, restart the electronic device according to the changed boot order, so that the electronic device loads the data of the base partition, the second static partition and the dynamic partition in sequence to run the operating system, and modify the node type of all snapshot nodes recorded in the base partition to name-dm-snapshot-target.

[0212] Understandably, if in practical applications the type identifier used to identify a snapshot node as a snapshot node performing a Merge operation is Merge, then the node type can also be modified to name-dm-snapshot-merge.

[0213] Step S204: Boot the electronic device into Recovery mode. After the electronic device enters Recovery mode, copy the files in the first sub-partition to the second sub-partition. Reboot the electronic device according to the boot order, so that the electronic device loads the data of the base partition, the first static partition and the dynamic partition in sequence to run the operating system. Modify the node type of all snapshot nodes recorded in the base partition to name-dm-snapshot-target.

[0214] Specifically, after determining that the second static partition is not bootable, for example, it might be... Figure 16 If the dtbo_b subpartition in the second static partition is physically corrupted or experiences a byte (bit) jump, or if other subpartitions are physically corrupted or experience a bit jump, the electronic device will write a boot command to start Recovery mode in the misc subpartition in the base partition. This will enable the electronic device to boot in Recovery mode after responding to the boot command.

[0215] For example, the boot command written to the misc subpartition could be "boot-recovery".

[0216] Furthermore, after the electronic device enters Recovery mode, it writes the upgrade command of the subpartition to be upgraded to the second upgrade file into the command file of the cache subpartition in the base partition. This enables the electronic device to copy the second upgrade file from the vendor_b subpartition containing the second upgrade file to the vendor_a subpartition in the first static partition after responding to the upgrade command.

[0217] For example, in this embodiment, the upgrade instruction written to the comand file can be determined based on the filename of the second upgrade file written to the second subpartition.

[0218] For example, when the second upgrade file is the vendor's upgrade file, the upgrade command written to the command file can be "-ota-ab-vendor-update".

[0219] For example, when the second upgrade file is a patch upgrade file, the upgrade command written to the command file can be "-ota-ab-patch-update".

[0220] In this way, once in Recovery mode, the electronic device will know which subpartition in the second static partition to copy the upgrade file to in the corresponding subpartition in the first static partition.

[0221] For example, see Figure 17 The diagram (1) shows that the Recovery mode is triggered by the "boot-recovery" instruction written to the misc subpartition in the base partition. Then, according to the "-ota-ab-vendor-update" instruction written to the comand file in the cache subpartition in the base partition, the vendor_b (2.0) in the second static partition, which has already completed the version upgrade, is copied to the vendor_a subpartition in the first static partition, thereby upgrading the vendor_a subpartition from version 1.0 to version 2.0.

[0222] In addition, it should be noted that, in practical applications, when copying files from the vendor_b subpartition to the vendor_a subpartition, the appropriate file copying method can be selected based on the file size, the number of copies required, and the desired copying speed.

[0223] For example, in one implementation, for scenarios where the size of the subpartition to be copied is less than 256KB, Buffer vs. FileChannel (non-direct mode) can be used for copying, while Buffer (direct mode) can be used for copying if the size is larger.

[0224] For example, in another implementation, for cases that need to be copied a large number of times, such as more than 7 times, the FileChannel.transferTo() and FileChannel.transferFrom() methods can be used for copying.

[0225] For example, in another implementation, a path-to-path approach can be used to quickly complete the copy.

[0226] It should be understood that the above description is merely an example provided to better understand the technical solution of this embodiment, and is not intended to be the only limitation of this embodiment.

[0227] In addition, it should be noted that in order to ensure that the electronic device can still boot in virtual AB mode, after copying the files in the vendor_b subpartition to the vendor_a subpartition, the boot instructions written in the misc subpartition need to be erased. In this way, when the electronic device boots and loads the base partition to read the boot mode recorded in the misc subpartition, it will not read the message to boot in Recovery mode, but will still restart in virtual AB mode.

[0228] For example, in completing Figure 17 After the operation shown in the schematic diagram (1), follow Figure 17 The loading order of the schematic diagram (2) is to load the data of the base partition, the first static partition and the dynamic partition in sequence to run the operating system. After the operating system runs, it can decide whether to perform the Merge operation based on the temperature of the electronic device.

[0229] In addition, it should be noted that in practical applications, when the boot flag of the first or second static partition is unBootable, after the system upgrade is completed and the static partition is synchronized, the unusable static partition can be repaired, and the boot flag can be changed from unBootable to Bootable. This way, subsequent OTA upgrades can proceed normally to step S203.

[0230] Step S205: Set the state of all first-type snapshot nodes to Merge state and add them to the Merge queue, waiting to execute the Merge operation.

[0231] Step S206: Before performing the Merge operation on the snapshot nodes in the Merge queue, obtain the first temperature of the electronic device.

[0232] Step S207: Determine whether the first temperature is less than the temperature threshold.

[0233] Specifically, if the first temperature is less than the temperature threshold, step 211 is executed; otherwise, step 208 is executed.

[0234] Step S208: The snapshot node in the Merge queue that has not performed the Merge operation is designated as the second snapshot node, and the second snapshot node is changed from the Merge state to the Persistent state to stop performing the Merge operation.

[0235] Step S209: After the first duration, obtain the second temperature of the electronic device.

[0236] Step S210: When the second temperature is less than the temperature threshold, change the second snapshot node at the head of the Merge queue from the Persistent state to the Merge state, and perform a Merge operation on the second snapshot node.

[0237] Step S211: Take the snapshot node at the head of the Merge queue as the first snapshot node, and perform the Merge operation on the first snapshot node.

[0238] It is not hard to see that Figure 15 Steps S201, S203, S205 to S211 in the illustrated embodiment are Figure 7 Steps S101 to S109 in the illustrated embodiment are largely similar; for specific implementation details of this embodiment, please refer to [link to relevant documentation]. Figure 7 The description of the illustrated embodiments will not be repeated here.

[0239] Therefore, the method provided in this application embodiment can achieve the effects of the above embodiments, effectively controlling the temperature of electronic devices, and can also achieve the following effects: 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 in the user data partition, the availability of the second static partition is determined according to the boot identifier corresponding to the second static partition, that is, whether the electronic device can be restarted with the second static partition as the boot entry. When the boot identifier is unavailable, the OTA upgrade is completed with the help of the currently running first static partition, thereby improving the upgrade success rate and improving the reliability of the product.

[0240] Furthermore, it should be understood that the above description of the embodiments is only a specific description of the scenario in which the electronic device boots from the first static partition before the OTA upgrade, the upgrade file is written to the second static partition during the OTA upgrade process, and the electronic device boots from the second static partition after the OTA upgrade package is installed. In actual application scenarios, the technical solution provided by the embodiments of this application is also applicable to the scenario in which the electronic device boots from the second static partition before the OTA upgrade, the upgrade file is written to the first static partition during the OTA upgrade process, and the electronic device boots from the first static partition after the OTA upgrade package is installed, and the implementation process is roughly the same as the process shown in the above embodiments, and will not be repeated here.

[0241] Furthermore, the terms "first," "second," "third," and "fourth" appearing in the technical solutions provided in this application are merely examples listed for a better understanding of the technical solutions in this embodiment, and are not intended as the sole limitation of this embodiment.

[0242] Furthermore, it should be noted that in practical application scenarios, the temperature control and upgrading methods provided in the above embodiments, implemented by electronic devices, can also be executed by a chip system included in the electronic device. This chip system may include a processor. The chip system can be coupled to a memory, enabling it to call computer programs stored in the memory during runtime to implement the steps executed by the electronic device. The processor in the chip system can be an application processor or a non-application processor.

[0243] In addition, this application embodiment also provides a computer-readable storage medium storing computer instructions. When the computer instructions are executed on an electronic device, the electronic device performs the above-described related method steps to implement the method for controlling and upgrading the temperature in the above embodiment.

[0244] In addition, this application also provides a computer program product that, when run on an electronic device, causes the electronic device to perform the above-mentioned related steps to achieve the method of controlling and upgrading temperature in the above embodiments.

[0245] In addition, embodiments of this application also provide a chip (which may also be a component or module), the chip may include one or more processing circuits and one or more transceiver pins; wherein, the transceiver pins and the processing circuits communicate with each other through internal connection paths, the processing circuits execute the above-described related method steps to implement the method of controlling the temperature upgrade in the above embodiments, so as to control the receiving pin to receive signals and control the transmitting pin to transmit signals.

[0246] Furthermore, as can be seen from the above description, the electronic devices, computer-readable storage media, computer program products, or chips provided in the embodiments of this application are all used to execute the corresponding methods provided above. Therefore, the beneficial effects they can achieve can be referred to the beneficial effects in the corresponding methods provided above, and will not be repeated here.

[0247] Furthermore, it should be understood that the above embodiments are only used to illustrate the technical solutions of this application, and not to limit them; although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that they can still modify the technical solutions described in the foregoing embodiments, or make equivalent substitutions for some of the technical features; and these modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the technical solutions of the embodiments of this application.< / dntargetsnapshot>

Claims

1. A method for controlling the temperature of an upgrade, characterized in that, An electronic device with a data storage structure in virtual AB mode is provided. The electronic device includes a processor and a memory. The memory includes a base partition, a first static partition, a second static partition, a dynamic partition, and a user data partition. After the electronic device starts, it sequentially loads data from the base partition, the first static partition, and the dynamic partition to run a first operating system. After the first operating system runs, the method includes: Obtain an upgrade package and install the upgrade package on the electronic device; wherein, the upgrade package includes an upgrade file for upgrading the dynamic partition, and during the process of installing the upgrade package on the electronic device, the upgrade file for upgrading the dynamic partition is temporarily stored in the user data partition; After the upgrade package is installed, the electronic device is restarted and the data of the base partition, the second static partition and the dynamic partition are loaded in sequence to run the second operating system. Then, the snapshot node recorded in the base partition is identified as the snapshot node to perform the Merge operation. The Merge operation is the process of writing the upgrade file of the user data partition to the dynamic partition. Set the state of the snapshot node to Merge state and add it to the Merge queue. The Merge state is the state in which a Merge operation is performed. Before performing a merge operation on the snapshot node in the merge queue, if the first temperature of the electronic device is less than a temperature threshold, a merge operation is performed on the snapshot node at the head of the merge queue. Before performing a merge operation on the snapshot node in the merge queue, if the first temperature of the electronic device is not less than a temperature threshold, the snapshot node in the merge queue that has not performed a merge operation is changed from the merge state to the persistent state, and the persistent state is a state in which the merge operation is stopped. The total duration during which Merge operations are stopped during the Merge phase; When the total duration is less than the duration threshold and the second temperature of the electronic device is less than the temperature threshold, the step of modifying the snapshot node at the head of the Merge queue from the Persistent state to the Merge state is executed. When the total duration is not less than the duration threshold, the step of changing the snapshot node at the head of the Merge queue from the Persistent state to the Merge state is executed.

2. The method according to claim 1, characterized in that, The method further includes: After the first duration, when the second temperature of the electronic device is less than the temperature threshold, the snapshot node at the head of the Merge queue is changed from the Persistent state to the Merge state.

3. The method according to claim 1, characterized in that, The process of obtaining the upgrade package and installing the upgrade package in the electronic device includes: Obtain the upgrade package, which includes a first upgrade file and a second upgrade file. The first upgrade file corresponds to a first subpartition, which is a subpartition of the dynamic partition. The second upgrade file corresponds to a second subpartition, which is a subpartition of the second static partition. Perform data writing operations on the second sub-partition according to the second upgrade file; A first virtual dynamic subpartition corresponding to the first subpartition is created in the user data partition, and a snapshot is taken of the first subpartition and the first virtual dynamic subpartition to obtain a snapshot file. Create a snapshot node corresponding to the first sub-partition in the base partition, and map the snapshot file to the snapshot node; Write the first upgrade file to the first virtual dynamic sub-partition and cancel the mapping with the snapshot node; The boot order is changed from booting from the first static partition to booting from the second static partition.

4. The method according to claim 3, characterized in that, The step of performing a merge operation on the snapshot node located at the head of the merge queue includes: Re-establish the mapping between the snapshot node and the corresponding snapshot file; Based on the snapshot file mapped to the snapshot node, the first upgrade file is read from the first virtual dynamic subpartition corresponding to the first subpartition in the user data partition, and the first upgrade file is written to the first subpartition.

5. The method according to claim 3, characterized in that, Before modifying the snapshot nodes in the Merge queue that have not performed a Merge operation from the Merge state to the Persistent state, the method further includes: The snapshot nodes recorded in the base partition that correspond to the sub-partitions that need to be upgraded in the dynamic partition are traversed, and snapshot nodes that have a mapping relationship with the sub-partitions that need to be upgraded in the dynamic partition are selected. Delete the snapshot nodes that have completed the merge operation from the selected snapshot nodes, and obtain the snapshot nodes in the merge queue that have not performed the merge operation.

6. The method according to claim 5, characterized in that, The step of changing the snapshot node in the Merge queue that has not performed a Merge operation from the Merge state to the Persistent state includes: Based on the snapshot file corresponding to the snapshot node, a third sub-partition corresponding to the snapshot node and a second virtual dynamic sub-partition corresponding to the third sub-partition are determined. 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 for temporarily storing the third upgrade file written to the third sub-partition. Based on the third sub-partition and the second virtual dynamic sub-partition, the snapshot node is modified from the Merge state to the Persistent state.

7. The method according to any one of claims 1 to 6, characterized in that, The method further includes: The snapshot node that has completed the Merge operation will be deleted from the base partition.

8. The method according to any one of claims 1 to 6, characterized in that, The method further includes: During the Merge operation, the snapshot nodes recorded in the base partition that correspond to the sub-partitions to be upgraded in the dynamic partition are traversed. For each snapshot node traversed, determine the progress of the Merge operation; The overall progress bar of the electronic device in the Merge phase is refreshed based on the progress of the Merge operation corresponding to each snapshot node.

9. An electronic device, characterized in that, The electronic device is in virtual AB mode, including a processor and a memory. The memory includes a basic partition, a first static partition, a second static partition, a dynamic partition, and a user data partition. After the electronic device starts up, it loads the data in the basic partition, the first static partition, and the dynamic partition in sequence to run the first operating system. The memory and the processor are coupled, and the memory stores program instructions; When the program instructions are executed by the processor, the electronic device performs the method for controlling and upgrading the temperature as described in any one of claims 1 to 8.

10. A computer-readable storage medium comprising a computer program, characterized in that, When the computer program is run on an electronic device, it causes the electronic device to perform the method for controlling the temperature upgrade as described in any one of claims 1 to 8.

11. A computer program product, characterized in that, The computer program product includes a computer program that, when run on an electronic device, causes the electronic device to perform the method for controlling and escalating temperature as described in any one of claims 1 to 8.

Images