Operating system upgrading method, electronic device, and storage medium

Abstract

The application provides an operating system upgrading method, an electronic device and a storage medium. The method determines the installation mode of the upgrading file corresponding to the sub-partition in the dynamic partition according to the current residual space of the user data partition and the size (compressed size, uncompressed size) of the upgrading file, so that whether to use the cow compression function can be determined according to specific conditions in the operating system upgrading process, thereby meeting different user requirements.

Description

[0001] This application is a divisional application. The original application has the application number 202210243332.7 and the original application date is March 11, 2022. The entire contents of the original application are incorporated herein by reference. Technical Field

[0002] This application relates to the field of computer technology, and in particular to an operating system upgrade method, electronic device, and storage medium. Background Technology

[0003] As electronic devices can install more and more applications, the demand for storage space from user data is increasing. Currently, in order to ensure the success of operating system upgrades while minimizing the storage space occupied by system data, so as to leave more storage space for user data, electronic devices using the Virtual AB system partitioning structure are becoming increasingly popular.

[0004] For electronic devices that use a virtual AB system partition structure, since the dynamic partition (surper partition) exists as a single partition, during the operating system upgrade process, the upgrade file corresponding to the dynamic partition needs to be written to the user data partition first. When the electronic device restarts, the upgrade file is read from the user data partition and written to the sub-partition corresponding to the dynamic partition. This results in the operating system upgrade process occupying a lot of space in the user data partition, and may even cause the upgrade to fail due to insufficient space in the user data partition. Summary of the Invention

[0005] To address the aforementioned technical problems, this application proposes an operating system upgrade method, an electronic device, and a storage medium. By selecting the upgrade method for a dynamic partition based on the remaining size of the user data partition space, the electronic device can ensure that the operating system upgrade is completed normally without affecting user operation.

[0006] In a first aspect, this application provides an operating system upgrade method applied to an electronic device. 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 up, 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 further includes: obtaining file list description information corresponding to the upgrade package, the file list description information indicating a first size of the upgrade package, a second size of the first upgrade file compressed in the upgrade package, and a third size of the first upgrade file uncompressed, the first upgrade file corresponding to a first subpartition in the dynamic partition; if the first remaining space in the user data partition is greater than the sum of the first size and the third size, creating a first COW file corresponding to the first subpartition in the user data partition, the first remaining space being the remaining space of the user data partition before downloading the upgrade package; if the first remaining space in the user data partition is greater than the sum of the first size and the second size, but less than the sum of the first size and the third size, creating a second COW file corresponding to the first subpartition in the user data partition, the size of the first COW file being greater than the size of the second COW file. Therefore, based on the remaining space of the user data partition and the first size of the upgrade package, the second size and the third size of the first upgrade file, the size of the virtual logical partition occupied by the subpartition of the dynamic partition in the user data partition during this operating system time is determined, i.e., the size of the COW file. Then, based on the size of the COW file, it is decided whether to select the COW file compression function, so that the upgrade method can be reasonably selected according to the remaining space of the user data partition, thereby meeting the needs of different users.

[0007] According to the first aspect, the size of the first COW file is equal to the first remaining space minus the second remaining space plus the first size, where the second remaining space is the remaining space in the user data partition after downloading the upgrade package and creating the first COW file; the size of the second COW file is equal to the first remaining space minus the third remaining space plus the first size, where the third remaining space is the remaining space in the user data partition after downloading the upgrade package and creating the second COW file.

[0008] According to the first aspect, or any implementation of the first aspect above, when the first remaining space of the user data partition is greater than the sum of the first size and the third size, a first COW file corresponding to the first subpartition is created in the user data partition, including: when the first remaining space of the user data partition is greater than the sum of the first size and the third size, setting the identifier corresponding to the compression attribute to a first identifier, the first identifier indicating that the first upgrade file is installed without using the COW compression function; and creating the first COW file corresponding to the first subpartition in the user data partition in an uncompressed form according to the first identifier.

[0009] According to the first aspect, or any implementation of the first aspect above, before creating the first COW file corresponding to the first subpartition in the user data partition in uncompressed form according to the first identifier, the method further includes: obtaining an upgrade package; after obtaining the upgrade package, performing the step of creating the first COW file corresponding to the first subpartition in the user data partition in uncompressed form according to the first identifier.

[0010] According to the first aspect, or any implementation of the first aspect above, after obtaining the upgrade package and before executing the creation of the first COW file corresponding to the first subpartition in the user data partition in uncompressed form according to the first identifier, the method further includes: if the fourth remaining space of the user data partition is greater than the third size, setting the identifier corresponding to the compression attribute to the first identifier, where the fourth remaining space is the remaining space of the user data partition after downloading the upgrade package; if the fourth remaining space of the user data partition is greater than the second size but less than the third size, setting the identifier corresponding to the compression attribute to the second identifier, where the second identifier indicates that the first upgrade file is installed using the COW compression function.

[0011] According to the first aspect, or any implementation of the first aspect above, after creating the first COW file corresponding to the first subpartition in the user data partition in an uncompressed form according to the first identifier, the method further includes: writing the data in the first upgrade file into the user data partition in an uncompressed form to create the first COW file corresponding to the first subpartition in an uncompressed form.

[0012] According to the first aspect, or any implementation of the first aspect above, when the first remaining space of the user data partition is greater than the sum of the first and second sizes, but less than the sum of the first and third sizes, a second COW file corresponding to the first subpartition is created in the user data partition, wherein the size of the first COW file is greater than that of the second COW file. This includes: when the first remaining space of the user data partition is greater than the sum of the first and second sizes, but less than the sum of the first and third sizes, setting the identifier corresponding to the compression attribute to a second identifier, wherein the second identifier indicates that the first upgrade file is installed using the COW compression function; and creating the second COW file corresponding to the first subpartition in compressed form in the user data partition according to the second identifier.

[0013] According to the first aspect, or any implementation of the first aspect above, before creating the second COW file corresponding to the first subpartition in compressed form in the user data partition according to the second identifier, the method further includes: obtaining an upgrade package; after obtaining the upgrade package, performing the step of creating the second COW file corresponding to the first subpartition in compressed form in the user data partition according to the second identifier.

[0014] According to the first aspect, or any implementation of the first aspect above, after obtaining the upgrade package and before executing the creation of the second COW file corresponding to the first subpartition in compressed form in the user data partition according to the second identifier, the method further includes: if the fourth remaining space of the user data partition is greater than the third size, setting the identifier corresponding to the compression attribute to the first identifier, the first identifier indicating that the first upgrade file is installed without using the COW compression function, and the fourth remaining space is the remaining space of the user data partition after downloading the upgrade package; if the fourth remaining space of the user data partition is greater than the second size but less than the third size, setting the identifier corresponding to the compression attribute to the second identifier.

[0015] According to the first aspect, or any implementation of the first aspect above, after creating a second COW file corresponding to the first subpartition in compressed form in the user data partition according to the second identifier, the method further includes: writing data from the first upgrade file into the user data partition in compressed form to create a second COW file corresponding to the first subpartition in compressed form.

[0016] According to the first aspect, or any implementation of the first aspect above, the data in the first upgrade file is written into the user data partition in compressed form to create a second COW file corresponding to the first subpartition in compressed form, including: removing 0 from the data in the first upgrade file; and writing the data with 0 removed into the user data partition to create a second COW file corresponding to the first subpartition in compressed form.

[0017] According to the first aspect, or any implementation of the first aspect above, if the first remaining space of the user data partition is greater than the sum of the first size and the third size, the electronic device does not perform read / write operations on the user data partition other than operating system upgrades during the operating system upgrade process; or, if the first remaining space of the user data partition is greater than the sum of the first size and the second size, but less than the sum of the first size and the third size, the electronic device does not perform read / write operations on the user data partition other than operating system upgrades during the operating system upgrade process.

[0018] According to the first aspect, or any implementation of the first aspect above, if the first remaining space is less than the sum of the first size and the second size, a prompt is made to clean up the user data partition.

[0019] According to the first aspect, or any implementation of the first aspect above, prompting for cleanup of the user data partition includes: determining a first difference between the sum of the first size and the second size and the first remaining space; prompting for cleanup of at least the first difference of space in the user data partition.

[0020] Based on the first aspect, or any of the above implementations of the first aspect, if the fourth remaining space is less than the second size, prompt the user data partition to be cleaned up.

[0021] Based on the first aspect, or any implementation of the first aspect above, prompt for cleaning up the user data partition, including: determining a second difference between the second size and the fourth remaining space; prompting for cleaning up at least the second difference of space in the user data partition.

[0022] Secondly, this application provides an electronic device. 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. The memory and processor are coupled, 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.

[0023] Thirdly, this application provides a computer-readable storage 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.

[0024] 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.

[0025] Fifthly, this application provides a chip including a processing circuit, a receiving pin, and a transmitting pin. The receiving pin, the transmitting pin, and the processing circuit communicate with each other via an internal connection path. The processing circuit executes instructions from 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

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

[0027] Figure 2 This is an exemplary schematic diagram illustrating the classification of internal memory types;

[0028] Figure 3 This is a schematic diagram illustrating the partition structure of a non-AB system, an AB system, and a virtual AB system;

[0029] Figure 4 This is an exemplary schematic diagram illustrating the interaction between the OTA server, the OTA server, and the electronic device during the operating system upgrade process;

[0030] Figure 5.1 This is an exemplary diagram illustrating the process of writing data from an upgrade package to a static partition during an operating system upgrade.

[0031] Figure 5.2 This is an exemplary diagram illustrating the process of writing data from an upgrade package to a dynamic partition during an operating system upgrade.

[0032] Figure 5.3 This is an illustrative diagram showing the files included in an upgrade package;

[0033] Figure 6.1 This is an example illustration of creating a COW file in the user data partition when the remaining space in the user data partition is greater than the sum of the upgrade package and the upgrade files corresponding to the uncompressed dynamic partition.

[0034] Figure 6.2 This is an example illustration of creating a COW file in the user data partition when the remaining space in the user data partition is less than the sum of the upgrade package and the upgrade files corresponding to the uncompressed dynamic partition, but greater than the sum of the upgrade package and the upgrade files corresponding to the compressed dynamic partition.

[0035] Figure 7.1 This is an exemplary illustration of the static partition upgrade process during an operating system upgrade, showing the electronic device before and after downloading the upgrade package from the OTA server.

[0036] Figure 7.2 This is an exemplary diagram showing the process of upgrading an electronic device's static partition before upgrading its dynamic partition during an operating system upgrade.

[0037] Figure 7.3 This is an exemplary diagram illustrating how an electronic device writes the first upgrade file to System_COW and verifies the dtbo_b subpartition during the operating system upgrade process.

[0038] Figure 7.4 This is an exemplary diagram illustrating the System_COW checksum and the subsequent restart of the electronic device during the operating system upgrade process.

[0039] Figure 7.5 This is an exemplary diagram illustrating the Merge operation and partition synchronization performed by an electronic device during an operating system upgrade process;

[0040] Figure 7.6This is an exemplary diagram illustrating how an electronic device reports the upgrade result to the OTA server after completing partition synchronization during the operating system upgrade process.

[0041] Figure 8.1 This is an exemplary timing diagram illustrating the interaction between the OTA (Over-The-Air) server and the OTA server during an operating system upgrade process.

[0042] Figure 8.2 This is an exemplary timing diagram illustrating how an electronic device obtains an upgrade package from an OTA server during an operating system upgrade process.

[0043] Figure 8.3 This is an exemplary timing diagram illustrating the writing of upgrade files to static and dynamic partitions during an operating system upgrade process;

[0044] Figure 8.4 This is an exemplary timing diagram illustrating the operations performed after the upgrade files are written to the static and dynamic partitions during the operating system upgrade process.

[0045] Figure 9 This is an exemplary flowchart illustrating the process of setting compression attributes based on the initial space assessment result during an operating system upgrade.

[0046] Figure 10 This is an exemplary flowchart illustrating the process of setting compression attributes based on the results of a second space determination during an operating system upgrade.

[0047] Figure 11 This is an exemplary schematic diagram illustrating the process of installing the upgrade files corresponding to the dynamic partition by selecting different installation methods based on different compression attributes during the operating system upgrade process.

[0048] Figure 12 This is an exemplary schematic diagram illustrating the process of an electronic device from startup to operating system upgrade to reboot and complete the operating system upgrade. Detailed Implementation

[0049] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0050] 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.

[0051] 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.

[0052] 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.

[0053] 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.

[0054] 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, tablets, PCs, etc.) to which the embodiments of this application are applicable will be described first in conjunction with the accompanying drawings.

[0055] 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.

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

[0057] 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.

[0058] For example, button 190 includes a power button (on button), volume buttons, etc. Button 190 can be a mechanical button or a touch button. Electronic device 100 can receive button input and generate button signal inputs related to user settings and function control of electronic device 100.

[0059] 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).

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

[0061] Furthermore, in some implementations, the controller can serve as the nerve center and command center of the electronic device 100. The controller can generate operation control signals based on the instruction opcode and timing signals to control the fetching and execution of instructions.

[0062] In addition, the memory in processor 110 is primarily used to store instructions and data. In some implementations, the memory in processor 110 is a cache memory.

[0063] 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, and this executable program code includes instructions.

[0064] 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 operating system mainly rely on the relevant instructions 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 operating system upgrade method provided in the embodiments of this application.

[0065] For example, see Figure 2 In a specific implementation, the internal memory 121 may include a read-only memory 121A and a random access memory 121B, and the read-only memory 121A may be further divided into a non-AB system ( Figure 3 As shown in (1) of the AB system, Figure 3 (2) shown in the middle) and the virtual AB system ( Figure 3 (3) shows these three different partitioning structures.

[0066] Understandably, in practical applications, Random Access Memory (RAM), also known as "main memory," can be read and written at any time at high speed. It is typically used as a temporary data storage medium for the operating system or other running programs. When the power is off, RAM cannot retain data; that is, RAM typically stores temporary data during the operation of the electronic device. Read-Only Memory (ROM), also known as "non-volatile memory," generally stores data pre-written before being loaded into the device, such as the operating system image file and user data generated when the user uses the electronic device. During the operation of the device, data can only be read and cannot be quickly and easily rewritten like RAM. Therefore, the data stored in ROM is stable and will not change after power is off. In summary, the biggest difference between RAM and ROM is that the data stored in RAM is automatically lost after power is off, while the data in ROM is not automatically lost and can be retained for a long time without power.

[0067] In addition, it should be noted that during the current operating system upgrade process, when the upgrade files in the upgrade package downloaded from the Over-the-Air (OTA) server to the user data partition (located in read-only memory 121A) of the electronic device are decompressed to the corresponding static and dynamic partitions, the kernel cache of random access memory 121B is used to achieve fast read and write of the upgrade files.

[0068] Furthermore, in practical applications, the read-only memory 121A can be, for example, a disk storage device, a flash memory device, or a universal flash storage (UFS); the random access memory 121B can be, for example, a high-speed random access memory.

[0069] Furthermore, it should be noted that in a specific implementation, the read-only memory 121A may include a program storage area and a data storage area. The program storage area may store the operating system and 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.).

[0070] 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, 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).

[0071] See also Figure 2 The partition structure of the internal memory 121 of the electronic device 100 can be, for example, a non-AB system, an AB system, or a virtual AB system. Specifically, based on the characteristics of the above four partitions (basic partition, static partition, dynamic partition, and user data partition), partitions that do not need to be upgraded during operating system upgrades, such as basic partitions and user data partitions, are all single partitions regardless of whether they are in a non-AB system, an AB system, or a virtual AB system. However, partitions that need to be upgraded will be different.

[0072] For example, when upgrading the operating system on a non-AB system, other functions of the electronic device are unavailable during the upgrade process. The device remains on the non-AB system's upgrade screen until the upgrade is complete and the device restarts, at which point it can access the user interface and function normally. Therefore, on non-AB systems, both static and dynamic partitions are single partitions. See details... Figure 3 As shown in (1), this reduces the memory space required, leaving more space for user data partitioning.

[0073] For example, the AB system is designed to allow users to return to the main interface of their electronic devices at any time during operating system upgrades, thus not affecting the use of the devices. Therefore, in the AB system, static and dynamic partitions are used in a dual-partition manner, as detailed in [link to details]. Figure 3 As shown in (2), static partitions can be divided into, for example, a first static partition and a second static partition, and dynamic partitions can be divided into, for example, 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 the operating system upgrade process, it will occupy a large amount of memory space, which will greatly reduce the available space of the user data partition.

[0074] For example, the virtual AB system combines the advantages of both non-AB and AB systems. It divides smaller static partitions (those occupying less storage space) into a first static partition and a second static partition, while larger dynamic partitions (those occupying more storage space) are treated as single partitions. See details... Figure 3 As shown in (3) of the text.

[0075] Taking the partition structure of the read-only memory 121A as an example of the virtual AB system partition structure, in practical applications, the partition deployment information of the read-only memory 121A in electronic devices can be described by the partition table shown in Table 1.

[0076] Table 1 Partition Table

[0077]

[0078] 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.

[0079] Furthermore, it's important to note that, aside from specially reserved partitions, virtually every partition has its corresponding image file. These image files are compiled from software code and integrate various functional files and configurations related to the electronic device's boot and operation. Without an image file, the electronic device cannot function. A complete system version includes many images, such as the partition table image gpt.img, boot-related images (xloader.img, boot.img), the system image super.img (which integrates the Android system kernel), and the user data image userdata.img (used to store user data), etc.

[0080] 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 as the only limitation of this embodiment.

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

[0082] Furthermore, the distribution of partitions in memory in the AB system partition structure and the virtual AB system partition structure, which exist in the form of dual partitions, is not limited to... Figure 3 (2) and Figure 3 The pattern shown in (3) is such that, in practical applications, the position of each partition is determined according to the allocated start and end addresses.

[0083] This concludes the introduction to the hardware structure of electronic device 100. It should be understood that... Figure 1 The 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.

[0084] Furthermore, it should be noted that in practical application scenarios, with the development of Over-the-Air Technology (OTA), OTA upgrades, which remotely upgrade electronic devices via their wireless network interfaces, are becoming increasingly common. In light of actual business scenarios, and to facilitate the explanation of the operating system upgrade schemes described in the embodiments of this application, the following will be combined with... Figure 4 Taking the OTA upgrade scenario as an example, this application describes the interaction between the package delivery server, the OTA server, and the electronic device in the operating system upgrade scheme provided in the embodiments of this application.

[0085] For example, see Figure 4 Used to upgrade electronic devices (such as...) Figure 4 The upgrade packages for the operating systems of PCs, tablets, mobile phones, etc. are created by the package acquisition server based on the version image. The package acquisition server then uploads the created upgrade packages to the OTA server, which manages and actively pushes them to the connected electronic devices, or sends them to the corresponding electronic devices according to their requests.

[0086] For example, the upgrade package created by the package acquisition server based on the version image may include, for example, boot-related images (e.g., xloader.img, boot.img), system images (e.g., super.img), etc., which will not be listed here, and this embodiment does not limit it.

[0087] Furthermore, in the technical solution provided in this embodiment, in order to ensure that the operating system can be upgraded whether the remaining space in the user data partition is sufficient or insufficient, the package server will also create a file list description information (hereinafter referred to as filelist.xml) describing the upgrade package when creating the upgrade package, and upload the filelist.xml describing the upgrade package to the OTA server together with the upgrade package for management.

[0088] It should be noted that, in the technical solution provided in this embodiment, the filelist.xml generated by the package acquisition server includes at least a first size indicating the upgrade package (hereinafter referred to as fileSize), a second size indicating the compressed upgrade file used to upgrade the dynamic partition (hereinafter referred to as compressCowsize), and a third size indicating the uncompressed upgrade file used to upgrade the dynamic partition (hereinafter referred to as uncompressCowsize).

[0089] See also Figure 4After an electronic device receives an upgrade package from an OTA server and upgrades its operating system, it will report the upgrade results to the OTA server so that the OTA server can know whether the electronic device's operating system upgrade was successful.

[0090] In addition, it should be noted that in practical applications, in the event of an upgrade failure, the upgrade result reported by the electronic device to the OTA server can also include log information of the upgrade failure, so as to quickly locate the cause of the operating system upgrade failure.

[0091] Regarding the process of electronic devices downloading upgrade packages from OTA servers and upgrading the operating system using these packages—specifically, writing the data from the upgrade package to the sub-partitions corresponding to the static partition and the dynamic partition—the following section combines... Figures 5.1 to 5.3 Please provide an explanation.

[0092] For example, see Figure 5.1 and Figure 5.2 The upgrade package downloaded by the electronic device from the OTA server is specifically stored in the user data partition. During the process of writing the data in the upgrade package to the sub-partitions corresponding to the static partition and the dynamic partition, the random access memory (RAM) reads the data in the upgrade package stored in the user data partition into the RAM, i.e., executes... Figure 5.1 In step (1), the RAM then writes the data used to upgrade the static partition into the corresponding sub-partition in the static partition, i.e., executes... Figure 5.1 Step (2) involves writing the data used to upgrade the dynamic partition to the corresponding sub-partition within the dynamic partition, i.e., executing... Figure 5.2 Step (3) in the process.

[0093] For example, Figure 5.1 Taking the first static partition as the boot order of the Sino-Israeli electronic device as an example, when the subpartition in the static partition that needs to be upgraded is the dtbo subpartition, the RAM will write the data used to upgrade the dtbo subpartition to the dtbo_b subpartition in the second static partition that is currently in the backup partition.

[0094] For example, Figure 5.2 Taking the System subpartition in the dynamic partition that needs to be upgraded as an example, RAM will write the data corresponding to the System subpartition in the upgrade package to the corresponding COW file in the user data partition's System subpartition. Figure 5.2 System_COW in the user data partition.

[0095] Regarding the files typically included in an upgrade package, the following is a summary... Figure 5.3 Please provide an explanation.

[0096] For example, in practical applications, an upgrade package typically includes a key signature file that stores key signature data, a version description file for the upgrade package, a payload.bin (which is an Android OTA image package file, such as image files including system.img, boot.img, and recovery.img), and an attribute file that describes payload.bin.

[0097] Furthermore, payload.bin can be divided into two parts: Metadata and Data. Metadata describes Data and indicates the specific location of upgrade data for different partitions within Data. That is, Metadata serves as a directory index and also handles signature verification, while Data contains the upgrade data used to upgrade sub-partitions in both static and dynamic partitions.

[0098] For details on how to locate data in each partition of Data based on Metadata, please refer to existing standards; these details will not be elaborated upon here.

[0099] Specifically, in the operating system upgrade scheme provided in this application embodiment, in order to make the upgrade method compatible with the electronic device, so as to take into account both user experience and ensure that the operating system can be upgraded quickly and normally, the electronic device will judge the remaining space of the user data partition when upgrading the operating system, and set the compression attribute according to the judgment result, that is, set whether to use the COW compression function.

[0100] It should be noted that the technical solution provided in this embodiment, when determining the remaining space and setting the compression attribute based on the determination result, specifically determines the remaining space of the user data partition and the fileSize, compressCowsize, and uncompressCowsize in the filelist.xml file mentioned above, and then sets whether to use the COW compression function based on the determination result.

[0101] For example, if the fileSize of the upgrade package recorded in filelist.xml is 506M, the compressCowsize of the upgrade file corresponding to the System subpartition in the dynamic partition is 1.0G, and the uncompressCowsize of the upgrade file corresponding to the System subpartition in the dynamic partition is 8.7G. See also Figure 6.1When the remaining space in the user data partition is 10.0G, since the remaining space (10.0G) > fileSize (506M) + uncompressCowsize (8.7G), the compression attribute is set to not use the COW compression function. That is, when the upgrade package is downloaded, the corresponding System_COW in the System subpartition created in the user data partition is created in an uncompressed form. When RAM writes the data corresponding to the System subpartition in the upgrade package to the uncompressed System_COW, it does not need to compress the data and can write it directly.

[0102] For example, if the fileSize of the upgrade package recorded in filelist.xml is 506M, the compressCowsize of the upgrade file corresponding to the System subpartition in the dynamic partition is 1.0G, and the uncompressCowsize of the upgrade file corresponding to the System subpartition in the dynamic partition is 8.7G. See also Figure 6.2 With 2.0G of remaining space in the user data partition, since fileSize (506M) + uncompressCowsize (8.7G) > remaining space (2.0G) > fileSize (506M) + compressCowsize (1.0G), the compression attribute is set to use the COW compression function. That is, when the upgrade package is downloaded later, the System_COW corresponding System subpartition created in the user data partition is created in compressed form. When RAM writes the data corresponding to the System subpartition in the upgrade package to the compressed System_COW, the data needs to be compressed.

[0103] It should be noted that in practical applications, when the compression attribute is set to use the COW compression function, when RAM writes the data corresponding to the System subpartition in the upgrade package to the compressed System_COW, the compression algorithm can be selected to compress the data according to business requirements. This embodiment does not restrict the selection of compression algorithm.

[0104] For example, before upgrading the operating system of an electronic device, the data is loaded sequentially: the data of the base partition, the data of the first static partition, and the data of the dynamic partition, so that the electronic device can run the first operating system (the previous version of the operating system, SlotA (v1.0)). Taking this system upgrade as an example, which requires upgrading the dtbo subpartition in the static partition and the System subpartition in the dynamic partition, combined with... Figures 7.1 to 7.6 The upgrade scheme for the operating system provided in the embodiments of this application will be described.

[0105] See Figure 7.1 When an operating system upgrade is needed, the electronic device will first perform... Figure 7.1 In step (1), the first size of the upgrade package, the second size of the first upgrade file compressed in the upgrade package, and the third size of the first upgrade file uncompressed are obtained from the OTA server. The first upgrade file corresponds to the System subpartition in the dynamic partition.

[0106] Next, the electronic device will perform... Figure 7.1 In step (2), if the first remaining space of the user data partition is greater than the sum of the first and third sizes, set the compression attribute to self.virtual_ab.compression.enabled=false (i.e., do not use the COW compression function) and download the upgrade package; if the first remaining space of the user data partition is greater than the sum of the first and second sizes but less than the sum of the first and third sizes, set the compression attribute to self.virtual_ab.compression.enabled=true (i.e., use the COW compression function) and download the upgrade package; if the first remaining space of the user data partition is less than the sum of the first and second sizes, pop up a message in the UI to remind the user to clean up the user data space.

[0107] For example, in some implementations, setting self.virtual_ab.compression.enabled="true" indicates that copy-on-write (COW) file compression is used, while setting self.virtual_ab.compression.enabled="false" indicates that COW compression is not used.

[0108] For example, when self.virtual_ab.compression.enabled="true", when writing the upgrade file of the subpartition in the dynamic partition to the user data partition, it is necessary to first create the corresponding COW file in the user data partition in compressed form (hereinafter referred to as compressed COW file), and then write the upgrade file corresponding to the subpartition in the dynamic partition to the compressed COW file in compressed form. That is, the upgrade file corresponding to the subpartition in the dynamic partition is stored in the user data partition as a compressed COW file.

[0109] For example, when self.virtual_ab.compression.enabled="false", when writing the upgrade file of the subpartition in the dynamic partition to the user data partition, it is necessary to first create the corresponding COW file in the user data partition in an uncompressed form (hereinafter referred to as the uncompressed COW file), and then directly write the upgrade file corresponding to the subpartition in the dynamic partition to the uncompressed COW file. That is, the upgrade file corresponding to the subpartition in the dynamic partition is stored in the user data partition as an uncompressed COW file.

[0110] For example, in some implementations, when a pop-up reminds the user that the electronic device's current remaining space is insufficient and that user data space needs to be cleared, it can also remind the user how much space needs to be cleared to ensure that the upgrade package can be downloaded successfully when the operating system upgrade is triggered again.

[0111] For example, in some implementations, a pop-up message reminds the user to clear user data space, which is at least the sum of the first and second sizes.

[0112] For example, in some implementations, if the current first remaining space of the electronic device is insufficient, after a pop-up prompts the user to clear user data space, the electronic device can automatically detect after a preset period whether the current first remaining space is greater than the sum of the first size and the third size, or greater than the sum of the first size and the second size, but less than the sum of the first size and the third size. Then, based on the detection result, it decides whether to download the upgrade package from the OTA server, i.e., re-execute the update. Figure 7.1 Step (2) in the process.

[0113] For example, in some other implementations, if the electronic device's current initial remaining space is insufficient, after prompting the user to clear user data space in a pop-up window, when should the process be re-executed? Figure 7.1 Step (2) can be triggered by the user, for example, by the user clicking the control to upgrade the operating system.

[0114] 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 as the only limitation of this embodiment.

[0115] To facilitate the explanation of the operating system upgrade scheme provided in this application, Figure 7.1 In step (2), taking the case where the first remaining space of the user data partition is greater than the sum of the first size and the third size as an example, the compression attribute is set to not use the COW compression function.

[0116] In addition, it should be noted that the upgrade package downloaded by the electronic device from the OTA server is specifically stored in the user data partition, which is not shown in the user data partition in this embodiment.

[0117] Next, after the electronic device downloads the upgrade package from the OTA server, it will execute... Figure 7.1 In step (3), the data of the second upgrade file corresponding to the dtbo subpartition of the static partition in the upgrade package is written into the dtbo_b subpartition of the second static partition.

[0118] For example, after writing the data of the second upgrade file to the dtbo_b subpartition in the second static partition, the version of the dtbo_b subpartition will be changed from... Figure 7.1 The dtbo_b(1.0) shown in the figure has been changed to Figure 7.2 The example shown is dtbo_b(2.0).

[0119] Understandably, if in practical applications the upgrade package does not include a second upgrade file, meaning there is no need to upgrade subpartitions within the static partition, then there is no need to execute this step. Figure 7.1 Step (3) in the process.

[0120] See next Figure 7.2 For example, after the electronic device writes the data from the second upgrade file to the dtbo_b subpartition of the second static partition (i.e., after upgrading the static partition), to prevent other files from occupying the remaining space of the electronic device during the upgrade package download process, thus causing insufficient space for upgrading the dynamic partition and preventing the upgrade from being completed, the electronic device will perform another space check operation. Figure 7.2 In step (4), if the fourth remaining space of the user data partition (the remaining space after downloading the upgrade package) is greater than the third size, set the compression attribute to self.virtual_ab.compression.enabled = false; if the fourth remaining space of the user data partition is greater than the second size but less than the third size, set the compression attribute to self.virtual_ab.compression.enabled = true and set the compression attribute to self.virtual_ab.compression.enabled = false; if the fourth remaining space of the user data partition is less than the second size, pop up a message on the UI to remind the user to clean up the user data space.

[0121] For example, in some implementations, a pop-up message reminds the user to clear their user data space, which is at least the second size.

[0122] For example, in some implementations, if the current fourth remaining space of the electronic device is insufficient, after a pop-up prompts the user to clear user data space, the electronic device can automatically detect after a preset period whether the current fourth remaining space is greater than the third size, or greater than the second size but less than the third size, and then decide whether to continue the upgrade based on the detection result, i.e., execute... Figure 7.2 Step (5) in the process, or after listening to the user's trigger operation, such as the user actively clicking the control to upgrade the operating system, the upgrade can be continued.

[0123] For example, in some other implementations, when an electronic device determines that the second user data space after user cleanup is greater than the third size, or less than the third size but greater than the second size, and restarts the operating system upgrade, it can download the upgrade package again from the OTA server, and then upgrade the sub-partitions of the static partition and the sub-partitions of the dynamic partition in sequence. This avoids the possibility that data already written may be lost or abnormal due to the user cleaning up the user data partition after the upgrade operation is interrupted.

[0124] 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 as the only limitation of this embodiment.

[0125] To facilitate the explanation of the operating system upgrade scheme provided in this application, Figure 7.2 In step (4), taking the case where the fourth remaining space of the user data partition is greater than the second size but less than the third size as an example, the compression attribute is reset to use the COW compression function after the second space judgment.

[0126] Understandably, the secondary space judgment operation for user data partitioning in step (4) above can be performed according to business needs, and this application does not impose any restrictions on this.

[0127] In addition, it should be noted that in practical applications, the operation of step (4) can be performed before step (3), that is, the order of steps (3) and (4) does not matter. Here, we take step (4) as an example that is performed after step (3).

[0128] Next, after completing Figure 7.2 After step (4) in the process, the electronic device will perform... Figure 7.2 In step (5), a compressed COW file (System_COW) is created in the user data partition corresponding to the System subpartition.

[0129] Understandably, the compressed System_COW created at this point is an empty COW file, meaning no data has been written to it yet.

[0130] See next Figure 7.3 For example, after creating a compressed System_COW corresponding to the System subpartition in compressed form, the electronic device will execute... Figure 7.3 In step (6), the data in the first upgrade file is written in compressed form to the compressed System_COW created in compressed form.

[0131] For example, after the data of the first upgrade file is written in compressed form to a compressed System_COW file created in compressed form, the version of the compressed System_COW file will be... Figure 7.2 The compressed System_COW shown in the image has been changed to... Figure 7.3 The compressed System_COW(2.0) shown in the figure.

[0132] In addition, it should be noted that after completing the operation of writing the upgrade files in the upgrade package to the corresponding sub-partitions, that is, writing the second upgrade file to the dtbo_b sub-partition and writing the first upgrade file to the compressed System_COW in compressed form, it is necessary to verify the sub-partitions that have completed the writing operation.

[0133] Understandably, according to existing protocol standards, static partitions need to be verified first. Only after the static partition verification is successful can the dynamic partition be verified. If the static partition verification fails, subsequent operations are terminated, and an upgrade failure message is reported to the OTA server. Therefore, when verifying sub-partitions that have completed write operations, the electronic device will first execute... Figure 7.3 Step (7) verifies the dtbo_b subpartition, that is, verifies the subpartition where the static partition has completed the write operation. To facilitate the explanation of the operating system upgrade scheme provided in this application, we take the successful verification of the dtbo_b subpartition as an example.

[0134] See next Figure 7.4 For example, the electronic device will perform Figure 7.4 Step (8) involves verifying the contents of the compressed System_COW after the dtbo_b subpartition has been successfully verified. To illustrate the operating system upgrade scheme provided in this application, we will use the successful verification of the compressed System_COW as an example.

[0135] Accordingly, after the System_COW compression verification is successful, the electronic device will execute... Figure 7.5 In step (9), after the System_COW compression verification is successful, restart the electronic device.

[0136] Understandably, in practical applications, after the upgrade files in the upgrade package are written to the corresponding sub-partition and the verification is successful, the electronic device can be directly triggered to restart, or it can be delayed.

[0137] For example, regarding the conditions for delaying the entire device restart, in some implementations, the entire device can be automatically restarted when the electronic device is idle, that is, when the user is not using it and no application is occupying it; in other implementations, the user can manually trigger the entire device restart as needed.

[0138] In addition, it should be noted that if, before the operating system upgrade, the electronic device loads data from the base partition, the first static partition, and the dynamic partition in sequence after booting up, and is running the first operating system (the version before the operating system upgrade), then after restarting, the electronic device will load data from the base partition, the second static partition, the dynamic partition, and the compressed System_COW file in the user data partition in sequence, so that the electronic device runs the second operating system (the upgraded version SlotB (v2.0)).

[0139] Next, after the electronic device restarts and runs on the second operating system, it will execute... Figure 7.6 In step (10) Merge, the contents of the compressed System_COW file are written to the System subpartition.

[0140] For example, after the Merge operation is completed, the System subpartition will be... Figure 7.5 The partition structure of the virtual AB system on the left shows System(1.0) changed to Figure 7.5 The partition structure of the virtual AB system on the right shows System(2.0).

[0141] Next, after completing the Merge operation, the electronic device will also perform... Figure 7.6 In step (11), the data in the dtbo_b subpartition is synchronized to the dtbo_a subpartition, that is, the static partition is synchronized. Specifically, the data in the static partition that is being upgraded during this operating system upgrade is synchronized to the static partition that is not being upgraded.

[0142] For example, when the operating system upgrade involves upgrading the files in the dtbo_b subpartition of the second static partition from version 1.0 to version 2.0, after the Merge operation is completed, the electronic device will copy the files in the dtbo_b subpartition to the dtbo_a subpartition of the first static partition to achieve synchronization between the two subpartitions.

[0143] For example, after partition synchronization is complete, the dtbo_a subpartition will be... Figure 7.5 The dtbo_a(1.0) shown in the figure has been changed to Figure 7.6The example shown is dtbo_a(2.0).

[0144] Next, after completing the partition synchronization operation, the electronic device will execute... Figure 7.6 In step (12), the upgrade result is reported to the OTA server.

[0145] Understandably, in practical applications, if any of the above steps (3) to (11) fails, causing the upgrade of the operating system to fail, the electronic device will interrupt the subsequent upgrade operation and report the upgrade result to the OTA server.

[0146] For example, if the upgrade is successful, the electronic device reports the upgrade result to the OTA server as indicating that the operating system upgrade was successful; otherwise, it reports the result as indicating that the operating system upgrade failed.

[0147] Furthermore, it should be understood that the above description is merely an example provided for a better understanding of the technical solution of this embodiment, and is not intended as the sole limitation of this embodiment.

[0148] Furthermore, it should be noted that the letters corresponding to the above-mentioned partitions may be case-insensitive in practical applications, and this application does not impose any restrictions on this.

[0149] To better understand the operating system upgrade scheme provided in this application, the following is combined with... Figures 8.1 to 8.4 This document details the process from the creation of upgrade packages by the package acquisition server to the electronic device receiving the upgrade packages from the OTA server and performing operating system upgrades.

[0150] In combination Figures 8.1 to 8.4 Before describing the operating system upgrade scheme provided in this application, the functional units / modules / applications involved in the operating system upgrade process of electronic devices will be introduced first. For ease of explanation, this embodiment takes the Android system used by the electronic device as an example. For example, in some implementations, the upgrade package may be obtained from the OTA server by the system upgrade client (OTA Update Client, OUC).

[0151] It should be noted that, in this embodiment, OUC specifically refers to an application installed in the application layer of the electronic device for managing operating system upgrades.

[0152] In addition, after obtaining the upgrade package from the OTA server, OUC will send the obtained upgrade package to the upgrade engine in the electronic device. The upgrade of static partitions is completed by the upgrade of static partitions, and the upgrade of dynamic partitions is completed by the upgrade of static partitions and the snapshot process.

[0153] Next, after the update_engine and snap processes complete the installation (upgrade) of the upgrade files in the upgrade package, OUC triggers the electronic device to enter a complete system reboot. After the electronic device runs the upgraded operating system after reboot, the kernel performs a Merge operation, which writes the data in the cow file in the user data partition to the corresponding sub-partition in the dynamic partition. The update_engine performs partition synchronization on the static partition.

[0154] Furthermore, it is understood that in some other implementations, operating system upgrades can also be completed through an entry point provided by a settings application installed in the application layer, and this embodiment does not limit this.

[0155] For example, see Figures 8.1 to 8.4 The operating system upgrade solution provided in this application includes:

[0156] S101, create an upgrade package based on the version image.

[0157] Specifically, in practical applications, upgrade packages created for the package delivery server can be made into differential upgrade packages and full upgrade packages according to business needs.

[0158] For example, regarding the creation of differential upgrade packages, smaller image files that are boot-related are fully packaged into the upgrade package, and a full overwrite method is used during the upgrade. For larger image files, such as super.img, in order to reduce the size of the upgrade package, a specific differential algorithm is used to extract the differences between each logical partition image in the new and old versions of super.img, and then generate independent patch files, which are packaged into the upgrade package. During the operating system upgrade, a specific differential algorithm is used to merge the patch files in the upgrade package into the old version of super.img in the super partition of the electronic device. This generates the new version of super.img, thus completing the upgrade from the old version of super.img to the new version of super.img.

[0159] The creation of the full package involves packaging all image files of the new version into the upgrade package, meaning there are no separate patch files.

[0160] In practical applications, the creation of differential upgrade packages and full upgrade packages can be found in existing standards, and this embodiment will not elaborate on this.

[0161] S102, calculate the size of the upgrade package (fileSize), the compressed size (compressCowsize) of the upgrade files in the dynamic partition of the upgrade package, and the uncompressed size (uncompressed size) of the upgrade files in the dynamic partition. Add fileSize, compressCowsize, and uncompressCowsize to the filelist.xml file corresponding to the upgrade package.

[0162] In other words, in this embodiment, when the package server creates the upgrade package, it adds the compressCowsize and uncompressCowsize corresponding to the upgrade files of the sub-partitions in the dynamic upgrade partition, as well as the fileSize of the upgrade package, to the filelist.xml corresponding to the upgrade package. In this way, the electronic device can determine which installation method to use based on the contents recorded in filelist.xml and the current remaining space of the user data partition, and install the upgrade files corresponding to the sub-partitions in the dynamic partition into the user data partition.

[0163] Understandably, in practical applications, filelist.xml will include not only fileSize, compressCowsize, and uncompressCowsize, but also other parameter information required during the operating system upgrade process, such as " <support> ”、" <payloadoffset> ”、" <filehash> ”、" <metadatahash> ”、" <metadatasize> ”、" <powerwash> ”、" <switchslotonreboot> ”、" <runpostinstall>Examples of such examples will not be listed here, and this embodiment does not impose any limitations on them.

[0164] It should be noted that in practical applications, the above fields in filelist.xml usually appear in pairs, that is, they will also include "< / runpostinstall> < / switchslotonreboot> < / powerwash> < / metadatasize> < / metadatahash> < / filehash> < / payloadoffset> < / support> , ...

[0165] in," <support> "and"< / support> The content between the quotation marks is used to indicate whether the virtual AB system partition structure is supported, where "0" indicates that it is not supported and "1" indicates that it is supported. <payloadoffset> and"< / payloadoffset> The content between the quotation marks indicates the starting position of payload.bin; <filehash> "and"< / filehash> The content between the quotation marks is used to verify the main body of the file payload.bin; <metadatahash> "and"< / metadatahash> The content between the quotation marks is used to verify the file metadata in payload.bin; <metadatasize> "and"< / metadatasize> The content between the quotation marks indicates the size of the file metadata inside payload.bin; <powerwash> "and"< / powerwash> The content between the quotation marks indicates whether the upgrade file should restore factory settings after the upgrade, where "0" indicates restoration and "1" indicates no restoration; <switchslotonreboot> "and"< / switchslotonreboot>The content between the quotation marks indicates whether to switch the static partition before restarting the electronic device after the upgrade package is installed, where "0" indicates no switching and "1" indicates switching; <runpostinstall> "and"< / runpostinstall> The content between the symbols indicates whether to execute the post-install script steps, where "0" means not to execute and "1" means to execute.

[0166] For example, post-install steps could include metadata partition status data, switching static partitions, etc.

[0167] For example, to facilitate understanding, the following is a filelist.xml example.

[0168] <virtualab>

[0169] <support> 1< / support> / / Indicates support for virtual AB system partitioning structure

[0170] <uncompresscowsize> 87602704384< / uncompresscowsize> / / This indicates that the uncompressed size of the upgrade file corresponding to the subpartition of the dynamic partition is 87602704384 bytes.

[0171] <cowsize> 7602704384< / cowsize> / / This indicates that the compressed size of the upgrade file corresponding to the subpartition of the dynamic partition is 7602704384 bytes.

[0172] <payloadoffset> 887< / payloadoffset> / / This indicates that the starting position of payload.bin is at an offset of 887 bytes.

[0173] <filehash> xobTFJapFXT0LnLFfki6EEgDtGtIMpUmpZpD / 9k1aRo=< / filehash> / / Used to verify the hash value of the file body in payload.bin

[0174] <filesize> 898039335< / filesize> / / This indicates that the upgrade package size is 89803933 bytes.

[0175] <metadatahash> 6LcRfiwjdb7DmB / ZFAXSkB3DTEPoW4E4KBXFq+Df5Bo=< / metadatahash> / / A hash value used to indicate the size of the file metadata in payload.bin

[0176] <metadatasize> 820940< / metadatasize> / / This indicates that the metadata size is 820940 bytes.

[0177] <powerwash> 0< / powerwash> / / After upgrading, the upgrade file will restore factory settings.

[0178] <switchslotonreboot> 1< / switchslotonreboot> / / Switch the static partition after installing the upgrade package and before restarting the electronic device.

[0179] <runpostinstall> 1< / runpostinstall> / / Steps to execute the post-install script

[0180] < / virtualab>

[0181] 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 as the only limitation of this embodiment.

[0182] S103, upload the upgrade package and filelist.xml.

[0183] For example, in some implementations, filelist.xml is stored in the upgrade package.

[0184] For example, in some other implementations, filelist.xml is separate from the upgrade package, so that when the electronic device performs space determination, it does not need to obtain the upgrade package, but can first obtain the filelist.xml which occupies less space.

[0185] 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 as the only limitation of this embodiment.

[0186] In addition, it should be noted that in some implementations, the upgrade package and filelist.xml can be actively uploaded to the OTA server by the package acquisition server when it detects a new version of the upgrade package and the corresponding filelist.xml, or the newly released upgrade package and the corresponding filelist.xml can be actively uploaded to the OTA server at preset intervals.

[0187] For example, in some other implementations, the condition for the package upload server to upload the upgrade package and filelist.xml can be that the newly released upgrade package and the corresponding filelist.xml are uploaded to the OTA server only after receiving a request from the OTA server.

[0188] 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 as the only limitation of this embodiment.

[0189] S104, save the upgrade package and filelist.xml.

[0190] For example, in some implementations, to avoid redundant versions occupying OTA server space, the OTA server can periodically iterate through the saved upgrade packages and corresponding filelist.xml files to clear redundant versions.

[0191] For example, in some other implementations, in order to further reduce the space occupied by the OTA server, the OTA server can periodically clean up the old version of the upgrade and the corresponding filelist.xml.

[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 as the only limitation of this embodiment.

[0193] S105, search the OTA server for the existence of the upgrade package.

[0194] Understandably, given the massive user base, upgrade packages for the operating systems installed on electronic devices are typically created by a package acquisition server and uploaded to an OTA server for management. The OTA server then interacts with the connected electronic devices, establishing a communication link. Therefore, in some implementations, electronic devices can proactively send search requests to the OTA server to determine if an upgrade package for the new operating system version exists.

[0195] For example, in some other implementations, the OTA server may also proactively push notification information when it detects an upgrade package for a new version of the operating system, informing the electronic device that an upgrade package for a new version of the operating system is available.

[0196] For ease of explanation, this embodiment takes the example of an electronic device actively initiating a search request to an OTA server to search for whether there is an upgrade package corresponding to a new version of the operating system.

[0197] Accordingly, if an upgrade package for a new version of the operating system is found in the OTA server, step S106 is executed; otherwise, a search request is sent to the OTA server periodically according to the set search cycle, or a search request is sent to the OTA server when triggered by the user.

[0198] 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 as the only limitation of this embodiment.

[0199] S106, retrieve filelist.xml.

[0200] For example, in the operating system upgrade scheme provided in this embodiment, if the electronic device finds an upgrade package corresponding to a new version of the operating system in the OTA server, it first sends a request to the OTA server to obtain the filelist.xml corresponding to the upgrade package, instead of directly sending a request to obtain the upgrade package.

[0201] Furthermore, as described above, in the operating system upgrade scheme provided in this embodiment, filelist.xml records fileSize, compressCowsize, and uncompressCowsize. Therefore, when the electronic device finds an upgrade package corresponding to a new version of the operating system on the OTA server, it first obtains the filelist.xml corresponding to the upgrade package. In this way, it can determine whether the current remaining space can accommodate the upgrade package based on the fileSize, compressCowsize, and uncompressCowsize recorded in filelist.xml and the current remaining space of the electronic device, and whether to use the COW compression function to install the upgrade file corresponding to the dynamic partition in the upgrade package.

[0202] S107, issue filelist.xml.

[0203] For example, after receiving a request from an electronic device to retrieve the filelist.xml file corresponding to an operating system upgrade package, the OTA server will retrieve the filelist.xml file from the specified storage address and then send it to the corresponding electronic device.

[0204] S108 sets compression attributes based on the machine's first remaining space, fileSize, compressCowsize, and uncompressCowsize.

[0205] For example, depending on the actual situation, step S108 can be divided into the following three cases: (1) For the case where the first remaining space is greater than fileSize + uncompressCowsize, set the compression attribute to "false"; (2) For the case where the first remaining space is greater than fileSize + compressCowsize but less than fileSize + uncompressCowsize, set the compression attribute to "true"; (3) For other cases, such as the case where it is less than fileSize + compressCowsize, pop up a message to remind the user to clean up the user data partition.

[0206] For ease of explanation, in this embodiment, step S108 is exemplified by setting the compression attribute to "true".

[0207] Understandably, during an operating system upgrade, the upgrade package needs to be downloaded to the user data partition of the electronic device first. Then, the upgrade package is decompressed, and the sub-partitions of the static partition are upgraded according to the upgrade files in the upgrade package used to upgrade the static partition. Specifically, the data of the upgrade files for different sub-partitions in the corresponding static partition is written to the corresponding sub-partitions. Similarly, the sub-partitions of the dynamic partition are upgraded according to the upgrade files in the upgrade package used to upgrade the dynamic partition. Specifically, the data of the upgrade files for different sub-partitions in the corresponding dynamic partition is first written to a COW file created in the user data partition. Therefore, when setting compression attributes, the remaining space on the local machine (specifically, the remaining space in the user data partition), fileSize, compressCowsize, and uncompressCowsize are comprehensively considered to ensure that the compression attributes are set more reasonably.

[0208] To better understand the content described in S105 to S108 of this embodiment, the following is in conjunction with... Figure 9 Please provide a detailed explanation.

[0209] For example, see Figure 9 Specifically, it includes:

[0210] S201, OUC found an upgrade package on the OTA server.

[0211] For details on how OUC searches for the existence of upgrade packages in OTA servers, please refer to the description of step S105 above, which will not be repeated here.

[0212] S202, OUC retrieves the filelist.xml file corresponding to the upgrade package from the OTA server.

[0213] Understandably, in this embodiment, filelist.xml is used to record descriptive information related to the upgrade package, and therefore it can be referred to as file list description information in some implementations.

[0214] For example, in this embodiment, the file list description information (filelist.xml) indicates the first size of the upgrade package (fileSize), the second size of the first upgrade file in the upgrade package (compressCowsize), and the third size of the first upgrade file (uncompressCowsize).

[0215] Understandably, the first upgrade file corresponds to the first subpartition in the dynamic partition, the second size is the compressed size, and the third size is the uncompressed size.

[0216] For example, when there is only one subpartition that needs to be upgraded in a dynamic partition, the first subpartition could be, for example, a... Figures 7.1 to 7.6 Any one of the following sub-partitions in the dynamic partition (Super): System, system_ext, Product, Cust, and Odm.

[0217] For example, when there are multiple subpartitions that need to be upgraded in a dynamic partitioning system, the first subpartition could be, for example,... Figures 7.1 to 7.6 Any of the following sub-partitions in the dynamic partition (Super): System, system_ext, Product, Cust, and Odm.

[0218] 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 sole limitation of this embodiment. The term "first sub-partition" mentioned in the above embodiments is merely used to indicate that the sub-partition is a sub-partition in a dynamic partition, and serves as a limitation on the number and specific sub-partitions in a dynamic partition.

[0219] Similarly, the "first upgrade file" mentioned above is only to indicate that the upgrade file is used to upgrade a subpartition in a dynamic partition, and does not constitute a limitation on the number of upgrade files for upgrading subpartitions in a dynamic partition or the specific subpartition to which the upgrade file corresponds.

[0220] S203, OUC retrieves fileSize, compressCowsize, and uncompressCowsize from filelist.xml.

[0221] For example, based on the contents of filelist.xml listed above, " <filesize> "and"< / filesize>The content between “” indicates fileSize, therefore from “ <filesize> "and"< / filesize> "You can get the fileSize from these two fields."

[0222] Accordingly, due to " <cowsize> "and"< / cowsize> The content between “” indicates compressCowsize, therefore from “ <cowsize> "and"< / cowsize> "You can get the compressCowsize from these two fields."

[0223] Accordingly, due to " <uncompresscowsize> "and"< / uncompresscowsize> The content between “” indicates uncompressCowsize, therefore from “ <uncompresscowsize> "and"< / uncompresscowsize> "You can get the uncompressCowsize from these two fields."

[0224] S204, OUC retrieves the first remaining available space A of the user data partition.

[0225] Understandably, the first remaining space mentioned in this embodiment refers to the remaining space of the user data partition before the upgrade package is downloaded.

[0226] S205, OUC determines available spaceA>fileSize+uncompressCowsize?

[0227] That is, OUC calculates the sum of fileSize and uncompressCowsize (referred to as the first sum in this embodiment), and then determines whether the first remaining space is greater than the first sum.

[0228] Accordingly, if the first remaining space is greater than the first total, then step S206 is executed; otherwise, step S207 is executed.

[0229] S206, OUC sets the compression attribute self.virtual_ab.compression.enabled = false.

[0230] For example, in this embodiment, when the first remaining space is greater than the first total, OUC will set the identifier corresponding to the compression attribute to the first identifier, that is, self.virtual_ab.compression.enabled = false.

[0231] It should be noted that the first identifier mentioned above, such as "false" given in this embodiment, is used to indicate that the first upgrade file is installed without using the COW compression function.

[0232] For example, in practical applications, it can also be agreed that "0" indicates that the first upgrade file is installed without using the COW compression function.

[0233] 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 as the only limitation of this embodiment.

[0234] For example, when the first remaining space is greater than the first total, it indicates that there is enough space available in the user data partition. In this case, the OUC can directly send a request to the OTA server to obtain the upgrade package, i.e., execute step S210.

[0235] S207, OUC sets the compression attribute self.virtual_ab.compression.enabled = true.

[0236] For example, in this embodiment, when the first remaining space is not greater than the first total, OUC will set the identifier corresponding to the compression attribute to the second identifier, that is, self.virtual_ab.compression.enabled = true.

[0237] It should be noted that the second identifier mentioned above, such as "true" given in this embodiment, is used to indicate that the first upgrade file is installed using the COW compression function.

[0238] For example, in practical applications, it can also be agreed that "1" indicates that the first upgrade file is installed using the cow compression function.

[0239] 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 as the only limitation of this embodiment.

[0240] For example, if the first remaining space is not greater than the first total, it indicates that the available space for the user data partition is insufficient. In this case, adhering to the principle of space priority, the compression attribute is set to use the COW compression function, thereby minimizing the space occupied by the user data partition.

[0241] S208, OUC determines available spaceA>fileSize+compressCowsize?

[0242] For example, after setting the identifier corresponding to the compression attribute to the second identifier, i.e., true, OUC will make another judgment to ensure that the currently available user data partition of the electronic device can accommodate the upgrade package and the compressed first upgrade file.

[0243] Specifically, OUC calculates the sum of fileSize and compressCowsize (referred to as the second sum in this embodiment), and then determines whether the first remaining space is greater than the second sum.

[0244] Accordingly, if the first remaining space is greater than the second sum, then proceed to step S210; otherwise, proceed to step S209.

[0245] In other words, only when the remaining space of the first subpartition is greater than the sum of the first and second sizes, but less than the sum of the first and third sizes, will the corresponding COW file (compressed COW file) be created in compressed form.

[0246] S209, the UI pop-up reminds users to clear at least (fileSize + compressCowsize - availablespaceA) Mb of user data space.

[0247] For example, if it is determined that even with the COW compression function, the currently available first remaining space in the user data partition is insufficient to accommodate the upgrade package and the compressed first upgrade file, in order to ensure that the operating system upgrade can proceed smoothly, OUC will calculate the difference between the second sum and the first remaining space (referred to as the first difference in this embodiment), i.e., (fileSize + compressCowsize - available spaceA), and then remind the user in the UI interface to clear at least the first difference of space in the user data partition. In this way, even if the user needs to clear the contents of the user data partition, the size of the files that need to be deleted can be reduced, thereby minimizing the interference when the user uses the electronic device.

[0248] For example, after the prompt in step S209 is given, if a preset condition is detected, step S204 is re-executed. For details on how to re-execute step S204 when the preset condition is met, please refer to [link to relevant documentation]. Figure 7.1 The description of cleaning up the user data partition when the user data partition space is insufficient in step (2) will not be repeated here.

[0249] S210, OUC obtains the upgrade package from the OTA server.

[0250] For example, in some implementations, OUC can obtain the upgrade package from the OTA server based on information recorded in filelist.xml, such as the address information of the upgrade package.

[0251] 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 as the only limitation of this embodiment.

[0252] This concludes the description of the space determination and compression attributes performed by OUC before obtaining the upgrade package from the OTA server. The following section will combine... Figure 8.2 If the compression attribute is set to "true" in step S108, the operating system upgrade scheme provided in this embodiment will continue to be described.

[0253] S109, obtain the upgrade package.

[0254] The specific methods by which electronic devices obtain upgrade packages from OTA servers using their OUC will not be elaborated here.

[0255] S110, upgrade package distributed.

[0256] In other words, after receiving a request from OUC to obtain the upgrade package, the OTA server will respond to the request by sending the requested upgrade package to OUC.

[0257] Furthermore, it should be noted that, to prevent other data or files from occupying the first remaining space during the upgrade package download process, thus ensuring that the first remaining space is no greater than the sum of fileSize and uncompressCowsize (i.e., no greater than the first total), and ultimately causing the installation method determined by the compression attributes set before the upgrade package download to be unsuitable, preventing the operating system upgrade from proceeding normally, the operating system upgrade scheme provided in this embodiment, after OUC obtains the upgrade package from the OTA server, upgrades the static and dynamic partitions according to the upgrade files in the upgrade package. That is, before writing the data in the upgrade package to the corresponding sub-partitions, it can perform another space check and reset the compression attributes according to the check result, i.e., execute step S111.

[0258] S111, set compression attributes based on the machine's fourth remaining space (remaining space after downloading the upgrade package), compressCowsize, and uncompressCowsize.

[0259] For example, depending on the actual situation, step S111 can be divided into the following three cases: (1) For the case where the fourth remaining space is greater than uncompressCowsize, set the compression attribute to "false"; (2) For the case where the fourth remaining space is greater than compressCowsize but less than uncompressCowsize, set the compression attribute to "true"; (3) For other cases, such as the case where it is less than compressCowsize, a pop-up window will remind the user to clean up the user data partition.

[0260] For ease of explanation, in this embodiment, step S111 is taken as an example where the compression attribute is set to "true".

[0261] Understandably, in practical applications, step S111 can be selected to be executed according to actual needs, and the execution order of this step can be before issuing the upgrade command, after issuing the upgrade command, before upgrading the static partition, or after upgrading the static partition and before upgrading the dynamic partition. There are no restrictions here. This implementation takes the example of issuing the upgrade command as an example for explanation.

[0262] For example, see Figure 10 Regarding the process of setting compression attributes based on the second space assessment result during the operating system upgrade, the specific steps include:

[0263] S301, OUC downloads the upgrade package from the OTA server.

[0264] S302, OUC retrieves the fourth remaining space available space B of the user data partition.

[0265] For example, after downloading the upgrade package from the OTA server, OUC will re-obtain the currently available space in the user data partition, i.e., the fourth remaining space.

[0266] S303, OUC determines that available spaceB>uncompressCowsize?

[0267] Understandably, since the upgrade package is already stored in the user data partition at this point, the space check OUC only needs to determine whether the fourth remaining space is greater than uncompressCowsize.

[0268] Correspondingly, if the fourth remaining space is greater than uncompressCowsize, it indicates that there is sufficient available space in the user data partition. In this case, the operating system upgrade can be performed without using the Cow compression function, thus prioritizing efficiency and completing the upgrade operation quickly.

[0269] S304, OUC sets the compression attribute self.virtual_ab.compression.enabled = false.

[0270] For example, in this embodiment, when the fourth remaining space is greater than uncompressCowsize, OUC will set the identifier corresponding to the compression attribute to the first identifier, that is, self.virtual_ab.compression.enabled = false.

[0271] As can be seen from the above description, the first identifier mentioned above, such as "false" given in this embodiment, is used to indicate that the first upgrade file is not installed using the COW compression function.

[0272] For example, in practical applications, it can also be agreed that "0" indicates that the first upgrade file is installed without using the COW compression function.

[0273] 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 as the only limitation of this embodiment.

[0274] For example, when the fourth remaining space is greater than uncompressCowsize, it indicates that there is sufficient space available in the user data partition. In this case, OUC can directly send the downloaded upgrade package to update_engine, i.e., execute step S308.

[0275] S305, OUC sets the compression attribute self.virtual_ab.compression.enabled = true.

[0276] For example, in this embodiment, when the fourth remaining space is not greater than uncompressCowsize, OUC will set the identifier corresponding to the compression attribute to the second identifier, that is, self.virtual_ab.compression.enabled = true.

[0277] As can be seen from the above description, the second identifier mentioned above, such as "true" given in this embodiment, is used to indicate that the first upgrade file is installed using the COW compression function.

[0278] For example, in practical applications, it can also be agreed that "1" indicates that the first upgrade file is installed using the cow compression function.

[0279] 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 as the only limitation of this embodiment.

[0280] For example, if the fourth remaining space is not greater than uncompressCowsize, it indicates that there is not enough space available for the user data partition. In this case, the principle of space priority is followed, and the compression attribute is set to use the cow compression function, so as to minimize the space occupied by the user data partition.

[0281] S306, OUC determines that available spaceB>compressCowsize?

[0282] For example, after setting the flag corresponding to the compression attribute to the second flag (true), OUC will perform another check to ensure that the currently available user data partition of the electronic device can accommodate the compressed first upgrade file. That is, OUC will check whether the fourth remaining space is greater than compressCowsize.

[0283] Accordingly, if the fourth remaining space is greater than compressCowsize, then proceed to step S308; otherwise, proceed to step S307.

[0284] S307, the UI pop-up reminds users to clear at least (compressCowsize-available spaceB) Mb of user data space.

[0285] For example, if it is determined that even with the COW compression function, the currently available fourth remaining space in the user data partition is insufficient to accommodate the compressed first upgrade file, in order to ensure that the operating system upgrade can proceed smoothly, OUC will calculate the difference between compressCowsize and the fourth remaining space (referred to as the second difference in this embodiment), i.e., (fcompressCowsize - available spaceB), and then remind the user in the UI interface to clear the space of the second difference in the user data partition. In this way, even if the user needs to clear the contents of the user data partition, the size of the files that need to be deleted can be reduced, thereby minimizing the interference when the user uses the electronic device.

[0286] For example, after the prompt in step S307 is given, if a preset condition is detected, step S302 is re-executed. For details on how to re-execute step S302 when the preset condition is met, please refer to [link to relevant documentation]. Figure 7.2 The description of cleaning up the user data partition when the user data partition space is insufficient in step (4) will not be repeated here.

[0287] S308, OUC sends an upgrade command to update_engine.

[0288] Therefore, before notifying update_engine to install the upgrade files in the upgrade package after downloading the upgrade package, OUC further checks the remaining space of the user data partition and resets the compression attributes based on the judgment result. This further ensures the rationality of the subsequent installation method determined by the compression attributes, thereby ensuring that the operating system upgrade can be completed normally.

[0289] This concludes the description of the space determination and compression attributes performed by OUC before downloading and installing the upgrade package from the OTA server. The following section will combine... Figures 8.2 to 8.4If the compression attribute is set to "true" in step S111, the operating system upgrade scheme provided in this embodiment will continue to be described.

[0290] S112, issue upgrade command.

[0291] Understandably, for Android electronic devices, operating system upgrades are primarily handled by the update engine. Therefore, after downloading the upgrade package from the OTA server and recompressing its attributes, OUC sends an upgrade command to the update engine to trigger it to begin the upgrade process.

[0292] S113, upgrade the static partition according to the upgrade file corresponding to the static partition in the upgrade package.

[0293] For a description of the upgrade process for static partitions, please refer to [link / reference]. Figure 7.1 The description of step (3) will not be repeated here.

[0294] Additionally, it should be noted that in practical applications, this step is an optional step for the technical solution provided in this embodiment. That is, step S113 will only be executed when the upgrade package includes an upgrade file for the static partition.

[0295] S114, confirm that the compression attribute is set to "true", and call the snap process to create a compressed COW file.

[0296] For example, after receiving the upgrade command, update_engine will read the compression properties set by OUC, such as by reading the compression properties through the getprop statement.

[0297] Specifically, if the identifier corresponding to the read compression attribute is the first identifier mentioned above (e.g., false), the installation method corresponding to the first upgrade file (the upgrade file of the subpartition in the dynamic partition) is determined to be the first installation method without using the COW compression function; if the identifier corresponding to the read compression attribute is the second identifier mentioned above (true), the installation method corresponding to the first upgrade file (the upgrade file of the subpartition in the dynamic partition) is determined to be the second installation method using the COW compression function.

[0298] S115, Creates a compressed cow file in the user data partition.

[0299] For example, since this embodiment takes the compression attribute set to "true" as an example, the compression attribute determined by update_engine is "true". Therefore, the snap process will create a second cow file (hereinafter referred to as compressed cow file) in compressed form in the user data partition. That is, according to the second identifier, a compressed cow file is created in compressed form in the user data partition.

[0300] Understandably, this embodiment is illustrated using the second identifier mentioned above as an example of compression attribute. In actual application, if the identifier corresponding to the read compression attribute is the first identifier mentioned above (such as false), and it is determined that the installation method corresponding to the first upgrade file (the upgrade file of the subpartition in the upgrade dynamic partition) is the first installation method without using the COW compression function, then the snap process will create the first COW file (hereinafter referred to as the uncompressed COW file) corresponding to the first subpartition in the user data partition in an uncompressed form according to the first identifier, so that update_engine will write the first upgrade file into the uncompressed COW file in an uncompressed form.

[0301] Understandably, in this embodiment, the size of the first cow file is larger than that of the second cow file, that is, the uncompressCowsize of the uncompressed cow file is larger than the compressCowsize of the compressed cow file.

[0302] S116, feedback: compressed cow file created successfully.

[0303] Understandably, in order for update_engine to know when to start writing the data of the first upgrade file in compressed form to the compressed cow file corresponding to the first subpartition in the user data partition, the snap process will send a message to update_engine that the compressed cow file has been successfully created after it is successfully created.

[0304] Accordingly, after receiving the message from the snap process that the compressed COW file has been successfully created, update_engine will execute step S117.

[0305] S117: The data in the upgrade file corresponding to the dynamic partition in the upgrade package is written to a compressed cow file in compressed form.

[0306] Understandably, in practical applications, if update_engine calls the snap process to create an uncompressed COW file in the user data partition in an uncompressed form, then after the snap process successfully creates the uncompressed COW file, it will send a message to update_engine confirming the successful creation of the uncompressed COW file. Upon receiving this message, update_engine will then write the data from the upgrade file corresponding to the dynamic partition in the upgrade package into the uncompressed COW file in an uncompressed form.

[0307] For example, in this embodiment, writing the data in the upgrade file corresponding to the dynamic partition in the upgrade package (hereinafter referred to as the first upgrade file) into the compressed cow file in compressed form means removing all the 0s from the data in the first upgrade file according to a preset compression algorithm, and then writing the data with the 0s removed into the compressed cow file.

[0308] For example, the preset compression algorithm mentioned in this embodiment may be a redundant compression method or a lossless compression method, that is, a method that removes redundancy without reducing the amount of information and can still restore the data as is.

[0309] In addition, it should be noted that if the snap process fails to create a cow file (whether compressed or uncompressed) in actual application, the snap process will send a message to update_engine indicating that the cow file creation failed. Upon receiving the message from the snap process indicating that the cow file creation failed, update_engine will end the current operating system upgrade operation and directly report the upgrade failure information to the OTA server.

[0310] In addition, regarding the method of writing the upgrade file corresponding to the dynamic partition into a compressed cow file in compressed form or into an uncompressed cow file in uncompressed form, please refer to the existing standards, which will not be elaborated here.

[0311] To better understand the content described in S114 to S117 of this embodiment, the following is combined with... Figure 11 Please provide a detailed explanation.

[0312] For example, see Figure 11 Specifically, it includes:

[0313] S401, update_engine determines self.virtual_ab.compression.enabled=true?

[0314] That is, after receiving the upgrade command issued by OUC, update_engine will read the compression attributes set by OUC.

[0315] Accordingly, if the identifier corresponding to the read compression attribute is the second identifier (true) mentioned above, it is determined that the installation method corresponding to the first upgrade file (the upgrade file of the subpartition in the upgrade dynamic partition) is the second installation method using the COW compression function. The update_engine notifies the snap process to create a compressed COW file in the user data partition in compressed form, i.e., execute step S402; if the identifier corresponding to the read compression attribute is the first identifier (such as false) mentioned above, it is determined that the installation method corresponding to the first upgrade file (the upgrade file of the subpartition in the upgrade dynamic partition) is the first installation method without using the COW compression function. The update_engine notifies the snap process to create an uncompressed COW file in the user data partition in uncompressed form, i.e., execute step S404.

[0316] S402, the snap process creates a compressed COW file in the user data partition.

[0317] S403, update_engine writes the upgrade file corresponding to the dynamic partition into a compressed COW file in compressed form.

[0318] For example, when the installation method is the second installation method, that is, when the compression attribute indicates the use of the COW compression function, update_engine will write the first upgrade file in compressed form to the compressed COW file, which can minimize the space occupied by the user data partition.

[0319] S404, the snap process creates an uncompressed COW file in the user data partition.

[0320] S405, update_engine writes the upgrade file corresponding to the dynamic partition to an uncompressed COW file in an uncompressed form.

[0321] For example, when the installation method is the first installation method, that is, when the compression attribute indicates that the COW compression function is not used, update_engine will write the first upgrade file into an uncompressed COW file in an uncompressed form. In this way, the operating system upgrade process will prioritize efficiency. Since the first upgrade file does not need to be compressed and is written directly into an uncompressed COW file, the writing speed is fast, which will shorten the operating system upgrade time and reduce the power consumption of electronic devices.

[0322] This concludes the description of the space determination and compression attributes performed by OUC before obtaining the upgrade package from the OTA server. The following section will combine... Figure 8.4 The operating system upgrade scheme provided in this embodiment will be further described.

[0323] S118 verifies the written upgrade file.

[0324] For example, when verifying the written upgrade file, according to the existing upgrade logic, the static partition needs to be upgraded first according to the upgrade package. After the static partition is upgraded, the dynamic partition is upgraded according to the upgrade package. After the dynamic partition is upgraded, the static partition and the dynamic partition are verified in turn.

[0325] To distinguish it from the first upgrade file for the first subpartition in a dynamic partition mentioned above, this embodiment refers to the upgrade file used to upgrade a subpartition in a static partition as the second upgrade file.

[0326] For example, during the operating system upgrade process, the upgrade engine obtains a second upgrade file from the upgrade package and then upgrades the data of the currently idle static partition according to the second upgrade file.

[0327] For example, when the boot process is initiated by the first static partition, the operating system upgrade process after the electronic device boots up specifically involves upgrading the data of the second static partition based on the second upgrade file.

[0328] For the verification process of upgraded subpartitions in static partitions and upgraded subpartitions in dynamic partitions (specifically, the corresponding COW files in user data partitions), please refer to existing standards, which will not be elaborated here.

[0329] For example, after successful verification, update_engine will report the verification success information to OUC, that is, execute step S119.

[0330] It should be noted that in practical applications, if the verification fails, update_engine will also report the verification information to OUC. In this case, the reported information is the verification failure information.

[0331] To facilitate the explanation of the subsequent upgrade process, this embodiment takes the example of update_engine reporting a successful verification message to OUC.

[0332] Accordingly, after update_engine reports the successful verification information to OUC, OUC will execute step S120.

[0333] S120 triggered a system restart.

[0334] For example, after verification, the OUC will trigger a system reboot of the electronic device. For details regarding the OUC-triggered system reboot operation, please refer to the above embodiments. Figure 7.4 The description of step (9) restarting the electronic device is omitted here.

[0335] It should be noted that the operation of triggering a system reboot by OUC is actually performed by the snap process. Therefore, after OUC triggers a system reboot, the snap process will execute step S121.

[0336] S121, during the reboot process, the compressed cow file is decompressed, the data in the compressed cow file is loaded, and the upgraded operating system is run.

[0337] Since this embodiment uses the COW compression function, meaning that the upgrade files for the sub-partitions of the dynamic partition are written to a compressed COW file in compressed form, when the electronic device is restarted and the data of the base partition, the second static partition, the dynamic partition, and the compressed COW file in the user data partition are loaded sequentially, the COW file needs to be decompressed. This is necessary to process the compressed data in the compressed COW file into an uncompressed format, and then load it to allow the electronic device to run the upgraded operating system (hereinafter referred to as the second operating system).

[0338] Accordingly, if the upgrade file for the dynamic partition is written to an uncompressed COW file in an uncompressed form, then when restarting the electronic device and sequentially loading the data from the base partition, the second static partition, the dynamic partition, and the uncompressed COW file in the user data partition, there is no need to decompress the uncompressed COW file; the data can be read directly from it.

[0339] Furthermore, it should be noted that, since this embodiment assumes that the electronic device boots from the first static partition before the operating system upgrade, that is, the data of the basic partition, the data of the first static partition, and the data of the dynamic partition are loaded in sequence during startup, the second static partition is upgraded in the above operating system upgrade scheme. Therefore, the data of the second static partition needs to be loaded during restart, that is, the boot order changes from the first static partition to booting from the second static partition.

[0340] For example, after the electronic device is rebooted to run on a second operating system, the snap process notifies the kernel to perform a merge operation, i.e., step S122.

[0341] Accordingly, after receiving the notification from the snap process to perform the Merge operation, the kernel will execute step S123.

[0342] S123, execute the Merge operation to write the data of the compressed cow file to the sub-partition corresponding to the dynamic partition.

[0343] Understandably, the Merge operation mentioned in this embodiment specifically refers to the process of writing the upgrade file of the upgrade dynamic partition in the user data partition to the dynamic partition, that is, the process of writing the data in the COW file to the corresponding sub-partition in the dynamic partition.

[0344] For details on the implementation process of the Merge operation, please refer to the existing standards; this embodiment will not elaborate further.

[0345] S124, report the successful Merge message.

[0346] For example, after the Merge operation is completed, the kernel will report the Merge result to the upgrade engine so that the upgrade engine can know whether the upgrade file of the upgrade dynamic partition in the user data partition has been written to the dynamic partition.

[0347] Accordingly, if the merge is successful, that is, the upgrade file of the upgrade dynamic partition in the user data partition is written to the dynamic partition, then step S125 is executed; otherwise, the upgrade failure can be reported directly to the OTA server through OUC.

[0348] For example, in some implementations, if the Merge operation fails, the OUC can restart the electronic device and control the electronic device to roll back from the second operating system to the first operating system, so that the electronic device can still be used normally even if the upgrade fails.

[0349] For ease of explanation, this embodiment uses a successful merge as an example.

[0350] S125 performs partition synchronization on static partitions.

[0351] For example, if the data of the second static partition is being upgraded according to the second upgrade file, then after the Merge is successful, the partition synchronization operation performed on the static partition is to synchronize the data of the second static partition to the first static partition.

[0352] Regarding the operation of synchronizing data from the second static partition to the first static partition, in some implementations, for example, the kernel can read the data from each sub-partition of the second static partition; and then overwrite the data from each sub-partition of the second static partition to the corresponding sub-partition of the first static partition.

[0353] Understandably, in practical applications, operating system upgrades may only upgrade one or a few sub-partitions in the static partition. Therefore, when performing partition synchronization, in order to reduce the resource consumption of electronic devices, it is advisable to first check whether the data in the second sub-partition of the second static partition is the same as the data in the third sub-partition of the first static partition.

[0354] Accordingly, if the data in the second sub-partition is the same as (consistent with) the data in the third sub-partition, the copying of that sub-partition is skipped, and the comparison of other sub-partitions continues; otherwise, the data in the second sub-partition is copied and then overwritten to the third sub-partition.

[0355] For example, regarding the aforementioned scheme of first checking whether the data in the second sub-partition of the second static partition is the same as the data in the third sub-partition of the first static partition, and then deciding whether to perform partition synchronization based on the check result, the specific implementation could be as follows:

[0356] First, calculate the hash value of the data in the second sub-partition and the hash value of the data in the third sub-partition.

[0357] Specifically, the second subpartition is a subpartition of the second static partition, the third subpartition is a subpartition of the first static partition, and the third subpartition corresponds to the second subpartition.

[0358] For example, see [link to example]. Figures 7.1 to 7.6 If the second subpartition in the second static partition is X-loader_b, then the third subpartition in the first static partition corresponding to the second subpartition is X-loader_a.

[0359] 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 as the only limitation of this embodiment.

[0360] Then, when the hash value of the data in the second sub-partition is inconsistent with the hash value of the data in the third sub-partition, the data in the second sub-partition is overwritten into the third sub-partition.

[0361] S126, report the upgrade success information.

[0362] For example, after performing the static partition synchronization operation, regardless of whether the partition synchronization is successful, the OUC will report the upgrade result to the OTA server so that the OTA server knows whether the operating system upgrade was successful. For details on the operation of the OUC reporting the upgrade result to the OTA server, please refer to the above embodiments. Figure 7.6 The description of step (12) reporting the upgrade results is not repeated here.

[0363] In addition, it should be noted that regarding Figure 8.4 Whether steps S118, S119 and S125 shown in the figure are executed can be set according to business needs. Whether they are executed or not does not affect the technical solution provided in this embodiment. This embodiment uses execution as an example for explanation.

[0364] Furthermore, it should be noted that when upgrading the operating system using the technical solution provided in this embodiment, in order to determine whether the electronic device used COW compression or not during the operating system upgrade process, it can be stipulated that if the first remaining space of the user data partition is greater than the sum of the first size and the third size, the electronic device will not perform any read or write operations on the user data partition other than the operating system upgrade during the operating system upgrade process. Correspondingly, if the first remaining space of the user data partition is greater than the sum of the first size and the second size, but less than the sum of the first size and the third size, the electronic device will not perform any read or write operations on the user data partition other than the operating system upgrade during the operating system upgrade process. Thus, before the electronic device undergoes an operating system upgrade, the remaining space of the user data partition (i.e., the first remaining space mentioned above, specifically the remaining space of the user data partition before downloading the upgrade package) is recorded. After the data of the dynamic partition is written into the COW file of the user data partition using the technical solution provided in this embodiment, and before the restart is performed, the remaining space of the user data partition is obtained. The size of the COW file can be determined by the difference between the remaining space of the user data partition before the upgrade and before the restart. Based on the size of the COW file, and following the premise that the size of the first COW file is greater than the size of the second COW file as specified in this embodiment, it can be determined whether the COW compression function was used or not during this upgrade.

[0365] For example, in order to facilitate the explanation of the size of the first and second COW files, this embodiment refers to the remaining space of the user data partition after downloading the upgrade package and creating the first COW file as the second remaining space, and the remaining space of the user data partition after downloading the upgrade package and creating the second COW file as the third remaining space.

[0366] Accordingly, the size of the first COW file is equal to the first remaining space minus the second remaining space plus the first size, and the size of the second COW file is equal to the first remaining space minus the third remaining space plus the first size.

[0367] To facilitate understanding, the following example illustrates the concept. Assume the first remaining space in the user data partition is 10.0G. After downloading the upgrade package and creating the COW file, the remaining space is 825.2M. The initial size of the upgrade package is 506M. Based on the calculation method for the first and second COW files given above, it can be seen that the created COW file occupies 8.7G (10.0G - 825.2M - 506M) of the user data partition.

[0368] Accordingly, if the first remaining space of the user data partition is 2.0G, the remaining space after downloading the upgrade package and creating the cow file is 518M, and the first size of the upgrade package is 506M, based on the calculation method of the first and second cow files given above, it can be seen that the created cow file occupies 1.0G (2.0G-518M-506M) of the user data partition.

[0369] Based on the principle that the size of the first COW file (a COW file created in uncompressed form) is greater than that of the second COW file (a COW file created in compressed form), for an operating system upgrade scenario where both upgrade packages are 506MB, if the first remaining space of the user data partition is 10.0GB before downloading the upgrade package and the remaining space after downloading the upgrade package and creating the COW file is 825.2MB, then the operating system upgrade did not use COW compression. If the first remaining space of the user data partition is 2.0GB before downloading the upgrade package and the remaining space after downloading the upgrade package and creating the COW file is 518MB, then the operating system upgrade used COW compression.

[0370] Furthermore, based on the above scenario, by recording the time required for the electronic device to download the upgrade package and complete the upgrade, it can be determined whether the upgrade used the COW compression function or not.

[0371] It is not difficult to see that in the operating system upgrade scheme provided in this embodiment, the installation method of the upgrade file corresponding to the subpartition in the dynamic partition depends on the current remaining space of the user data partition and the size of the upgrade file (compressed size, uncompressed size). Thus, during the operating system upgrade process, it is possible to decide whether to use the COW compression function according to the specific situation, thereby meeting the needs of different users.

[0372] To provide a more intuitive understanding of the impact of using and not using COW compression on operating system upgrades, the following comparison shows the difference between using differential upgrade packages and full upgrade packages for operating system upgrades.

[0373] Table 2 Differential Upgrade Packages

[0374]

[0375] Table 3 Full Upgrade Package

[0376]

[0377]

[0378] To make the data in Tables 2 and 3 clearer, taking Table 2 as an example, for operations involving dynamic partitions such as installation, verification, and merging, the installation time is 142 seconds in the upgrade method without COW compression and 145 seconds in the upgrade method with COW compression. Therefore, the installation operation in the upgrade method with COW compression takes 2% longer than the installation operation in the method without COW compression.

[0379] Correspondingly, the time spent on verification operations increased by 315%, the time spent on merge operations increased by 459%, and the total time spent on installation, verification, and merge increased by 108%. This resulted in an overall increase of 6% in the power consumption of electronic devices during the upgrade process.

[0380] However, based on the data recorded in Tables 2 and 3, the size of the user data partition occupied before the electronic device is restarted is significantly smaller when using the COW compression function compared to when the COW compression function is not used, with a reduction of 89% for differential upgrade packages and 44% for full upgrade packages.

[0381] Therefore, as shown in Tables 2 and 3, for space-sensitive users, space is prioritized, and the COW compression function is used, sacrificing upgrade time, power consumption, and heat experience, but without requiring users to delete the original data in the user data partition; for space-insensitive users, efficiency is prioritized, and the COW compression function is not used to ensure that the operating system upgrade can be completed quickly.

[0382] Furthermore, to better understand the entire process of operating system upgrade based on the technical solution provided in this embodiment, the following is combined with... Figure 12 Please provide an explanation.

[0383] It should be noted that, Figure 12 The operating system upgrade process shown is implemented for a virtual AB system partition structure. When the electronic device is currently booting from the first static partition, the electronic device follows the steps shown below. Figure 12 The process shown enables operating system upgrades.

[0384] S501, the electronic device sequentially loads data from the base partition, data from the first static partition, and data from the dynamic partition, and boots from the first static partition to run the first operating system.

[0385] S502, the OUC in the electronic device retrieves the filelist.xml corresponding to the upgrade package.

[0386] For example, in one feasible implementation, the electronic device periodically sends a packet search request to the OTA package server. The packet search request includes the version number of the operating system currently running on the electronic device (e.g., version 1.1). Based on the operating system version number in the packet search request, the OTA server searches for whether there is an upgrade package with an updated version number (e.g., version 1.2). When an upgrade package with an updated version exists, the OTA server sends the download address of filelist.xml corresponding to the upgrade package (e.g., a system incremental upgrade package from version 1.1 to version 1.2) to the electronic device. The electronic device downloads filelist.xml based on the download address of filelist.xml.

[0387] S503, OUC obtains the first remaining space of the user data partition.

[0388] S504, OUC sets compression attributes based on the first remaining space and fileSize, compressCowsize, and uncompressCowsize in filelist.xml.

[0389] For implementation details of steps S501 to S504, please refer to the above section. Figures 7.1 to 9 The textual description is omitted here.

[0390] For ease of explanation, this embodiment takes the case where the compression attribute is set to "false", that is, the first remaining space is greater than the sum of fileSize and uncompressCowsize.

[0391] S505, OUC obtains the upgrade package from the OTA server.

[0392] For example, in one feasible implementation, after the electronic device sends a request to the OTA package server to obtain an upgrade package (e.g., version 1.2), the OTA server sends the download address of the upgrade package (e.g., a system incremental upgrade package from version 1.1 to version 1.2) back to the electronic device; the electronic device downloads the upgrade package according to the download address of the upgrade package and saves the upgrade package to the user data partition.

[0393] S506, OUC retrieves the fourth remaining space of the user data partition.

[0394] S507, OUC sets compression attributes based on the fourth remaining space and compressCowsize and uncompressCowsize.

[0395] For implementation details of steps S506 and S507, please refer to the above text. Figures 7.2 to 10 The textual description is omitted here.

[0396] For ease of explanation, this embodiment will still take the case where the compression attribute is set to "false", that is, the fourth remaining space is greater than uncompressCowsize, as an example.

[0397] The S508 electronic device's upgrade engine upgrades the second static partition based on the upgrade file corresponding to the second static partition in the upgrade package.

[0398] For example, the system incremental upgrade package from version 1.1 to version 1.2 contains the full data of the static partition of version 1.2, and the electronic device overwrites the data of the static partition of version 1.2 into the second static partition.

[0399] S509, the upgrade engine reads the compression attributes set in OUC to determine the installation method for dynamic partitions.

[0400] S510, the snap process creates the corresponding COW file (compressed COW or uncompressed COW file) in the user data partition according to the determined installation method.

[0401] For example, the COW file corresponding to the System subpartition is System_COW. Understandably, if the installation method uses COW compression, the System_COW file created in step S510 will be a compressed COW file; if the installation method does not use COW compression, the System_COW file created in step S510 will be an uncompressed COW file.

[0402] S511, the upgrade engine writes the upgrade files corresponding to the dynamic partition in the upgrade package into the corresponding COW file according to the determined installation method.

[0403] For example, the upgrade package contains data for the version 1.2 dynamic partition, and the electronic device writes the data for the version 1.2 dynamic partition (Super) into a cow file created in the user data partition.

[0404] Understandably, if the COW file is a compressed COW file, then when writing data from the dynamic partition containing version 1.2 in the upgrade package to the compressed COW file, compression will be used; otherwise, no compression is required, and the data will be written directly to the uncompressed COW file.

[0405] Furthermore, in the operating system upgrade scheme for electronic devices with a virtual AB system partition structure, an incremental upgrade method is adopted for the dynamic partition (Super). During the upgrade process, the COW file of the user data partition (Userdata) does not store all the files of the new version of the dynamic partition (Super) after the upgrade, but rather the upgrade result of the data that needs to be upgraded in the old version of the dynamic partition (Super). That is, the COW file of the user data partition (Userdata) stores the updated data of the dynamic partition.

[0406] For ease of explanation, the following example demonstrates how to upgrade a dynamic partition without using a COW file.

[0407] Taking the system sub-partition as an example, suppose that in version 1.1, the data in the system sub-partition can be divided into two parts: system1 and system2. From version 1.1 to version 1.2, the data system2 remains unchanged, but the data system1 is upgraded to system3. Therefore, in step S511, the electronic device creates a cow file in the user data partition (Userdata) and writes the data system3 into the cow file.

[0408] For example, the system incremental upgrade package from version 1.1 to version 1.2 contains the dynamic partition (Super) update data for upgrading from version 1.1 to version 1.2, which includes the data system3.

[0409] Furthermore, in the operating system upgrade scheme of electronic devices with a virtual AB system partition structure, incremental upgrades of the dynamic partition (Super) are implemented based on snapshot technology. Specifically, the upgrade data of the dynamic partition (Super) is stored in the copy-on-write (COW) file of the user data partition (Userdata).

[0410] Specifically, the upgrade data of the dynamic partition (Super) stored in the Userdata partition contains multiple COW files. Each COW file corresponds to a subpartition of the dynamic partition (Super), and the name of the COW file corresponds to the subpartition of the dynamic partition (Super) it targets.

[0411] In the upgrade package obtained in step S505, the COW file of the upgrade data for the dynamic partition (Super) is compressed and saved in binary code form. Within the upgrade package, each COW file is named according to the dynamic partition (Super) subpartition it targets. For example, the COW file for the System subpartition is named system-cow-img.img.0000.

[0412] In step S511, the electronic device unpacks the upgrade package to obtain all the COW files and appends an AB partition marker to each COW file. Specifically, when the electronic device is currently booting from the first static partition, it can be understood that the dynamic partition (Super) loaded by the operating system currently running on the electronic device is the dynamic partition (A). When upgrading the operating system, the COW files created in the user data partition (Userdata) are for the dynamic partition (B). Therefore, the corresponding dynamic partition (B) name marker _b is appended to the COW files. For example, appending _b to system-cow-img.img.0000 generates system_b-cow-img.img.0000.

[0413] Furthermore, in step S511, an Update folder is created in the Userdata partition, and the renamed cow file is saved in the Update folder. For example, in one application scenario, after writing the cow file to the Userdata partition, the Update folder of the Userdata partition contains the following files:

[0414] system_b-cow-img.img.0000;

[0415] system_ext_b-cow-img.img.0000;

[0416] vendor_b-cow-img.img.0000;

[0417] product_b-cow-img.img.0000;

[0418] cust_b-cow-img.img.0000;

[0419] odm_b-cow-img.img.0000.

[0420] Specifically, the COW file contains its own COW file map (snapshot map) and upgrade data. The COW file map (snapshot) corresponds to the file map of the subpartition of the dynamic partition (Super) that the COW file targets. The file map of the subpartition of the dynamic partition (Super) describes all files in the subpartition of the current version of the operating system (the version prior to this upgrade, for example, version 1.1) and the storage location of each file.

[0421] The upgrade data in the cow file represents the updated files in the new version of the subpartition data compared to the current version; the cow file map itself describes the correspondence between the updated files and the files in the current version of the subpartition, as well as the storage location of the updated files.

[0422] Based on the file maps of the subpartitions of the dynamic partition (Super) and the cow file maps within the cow file, the upgrade data in the cow file can be used to replace the corresponding files in the subpartitions of the dynamic partition (Super), thereby achieving the upgrade of the dynamic partition (Super) data. Specifically, when it is necessary to obtain the file map of the subpartitions of the dynamic partition (Super), a snapshot operation can be performed on the data of the subpartitions of the dynamic partition (Super) to generate the file map of the subpartitions of the dynamic partition (Super). Alternatively, the file map of the subpartitions of the dynamic partition (Super) can be pre-generated when creating the upgrade package and added to the cow file.

[0423] Taking the System subpartition as an example, assume that data is stored in the System subpartition according to the following paths:

[0424] / system / app / A0.XXX;

[0425] / system / app / A1.XXX;

[0426] / system / app / A2.XXX;

[0427] / system / B0.XXX;

[0428] / system / B1.XXX;

[0429] / system / user / C0.XXX;

[0430] / system / user / C1.XXX;

[0431] / system / user / C2.XXX;

[0432] / system / user / C3.XXX.

[0433] The file map of the System subpartition can be:

[0434] / system / app / A0.XXX: 024010~024013;

[0435] / system / app / A1.XXX: 024014~024017;

[0436] / system / app / A2.XXX: 024018~024020;

[0437] / system / B0.XXX: 024021~024026;

[0438] / system / B1.XXX: 024027~024028;

[0439] / system / user / C0.XXX: 024029~024032;

[0440] / system / user / C1.XXX: 024033~024035;

[0441] / system / user / C2.XXX: 024036~024040;

[0442] / system / user / C3.XXX: 024041~024044.

[0443] The value following the filename (e.g., 024010 to 024013 in / system / app / A0.XXX:024010 to 024013) is the physical storage address (block address) of the file in the System subpartition of the dynamic partition (Super).

[0444] Suppose that the current operating system upgrade requires updating the data / system / app / A2.XXX and / system / user / C2.XXX.

[0445] It can be considered as:

[0446] / system / app / A2.XXX and / system / user / C2.XXX are the system1 part of the system sub-partition data;

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

[0448] Therefore, the cow file (system_b-cow-img.img.0000) for the System subpartition contains the latest versions of / system / app / A2.XXX and / system / user / C2.XXX.

[0449] The latest versions of / system / app / A2.XXX and / system / user / C2.XXX can be considered as system3. The upgrade goal is to use system3 to update system1.

[0450] When the size of the updated data in the COW file is the same as the size of the original data to be updated, and the location where the updated data in the COW file is saved in the subpartition after the data update is the same as the location where the original data to be updated is saved in the subpartition, the COW file map of the COW file (system_b-cow-img.img.0000) itself can be:

[0451] / system / app / A2.XXX:

[0452] Map1 (address of data to be updated in the original Super partition): starting address: 024018 (offset relative to the starting address of the System subpartition); offset size: 2 (i.e., data in the address range 024018 to 024020).

[0453] Map2 (the address of the updated data stored in the cow file): starting address: 045033 (offset relative to the starting address of the cow file); offset size: 2 (i.e., the data in the address range of 045033 to 045035);

[0454] / system / user / C2.XXX:

[0455] Map1 (address of data to be updated in the original Super partition): starting address: 024036 (offset relative to the starting address of the System subpartition); offset size: 4 (i.e., data in the address range 024036 to 024040).

[0456] Map2 (the address of the updated data stored in the cow file): starting address: 045036 (offset relative to the starting address of the cow file); offset size: 4 (i.e., the data in the address range of 045036 to 045040).

[0457] When the size of the updated data in the COW file is inconsistent with the size of the original data to be updated, the COW file map of the COW file itself (system_b-cow-img.img.0000) can be:

[0458] / system / app / A2.XXX:

[0459] Map1.1 (address of data to be updated in the original Super partition): starting address: 024018 (offset relative to the starting address of the System subpartition); offset size: 2 (i.e., data in the address range 024018 to 024020).

[0460] Map2.1 (the address of the updated data that needs to overwrite the address of Map1.1 stored in the cow file): starting address: 045033 (offset relative to the starting address stored in the cow file); offset size: 2 (i.e., the data in the address range of 045033 to 045035);

[0461] Map1.2 (the address in the original super partition where the updated data in the cow file exceeds the size of the data to be updated): Starting address: 025018 (offset relative to the system starting address); Offset size: 1 (i.e., the data in the address range 025018 to 025020).

[0462] Map2.2 (the address of the updated data that needs to overwrite the address of Map1.2 stored in the cow file): starting address: 046033 (offset relative to the starting address stored in the cow file); offset size: 2 (i.e., data in the address range of 046033 to 046035).

[0463] In the following description, for ease of explanation, we will only use the application scenario where the size of the updated data in the cow file is the same as the size of the original data to be updated, and the location where the updated data in the cow file is saved in the subpartition after the data update is the same as the location where the original data to be updated is saved in the subpartition.

[0464] In the example above, the address ranges (045033~045035 and 045036~045040) are the physical storage addresses (block addresses) of the latest versions of / system / app / A2.XXX and / system / user / C2.XXX in the user data partition (Userdata), respectively.

[0465] Thus, if A2.XXX at addresses 045033-045035 is used to replace A2.XXX at addresses 024018-024020, and C2.XXX at addresses 045036-045040 is used to replace C2.XXX at addresses 045036-045040, the data upgrade of the System subpartition in the dynamic partition (Super) can be completed.

[0466] Furthermore, in step S511, after writing the cow file to the user data partition (Userdata), it is also necessary to perform an overall verification of the dynamic partition (Super) + cow file to verify the validity of the dynamic partition (Super) + cow file and verify whether the synthesis result of the current version of the dynamic partition (Super) data + cow file is the new version of the dynamic partition (Super) data.

[0467] Specifically, taking the upgrade from version 1.1 to version 1.2 as an example, the hash value of the combined result of the data in the dynamic partition (Super) that does not need to be upgraded (data that has not changed from version 1.1 to version 1.2) and the upgrade data in the cow file (data that needs to be upgraded from version 1.1 to version 1.2) is calculated. It is then determined whether this hash value is consistent with the hash value of the complete data of the dynamic partition (Super) in version 1.2. If they are consistent, the cow file is valid; if they are inconsistent, the cow file is invalid, the upgrade fails, the upgrade process is interrupted, and an error is reported. The hash value of the complete data of the dynamic partition (Super) in version 1.2 is stored in the upgrade package.

[0468] Specifically, during the verification process, the dynamic partition (Super) and the cow file are merged based on the snapshot. In the implementation of the snapshot, the merging of the dynamic partition (Super) and the cow file is not a physical merger, but rather a merging of the file map of the subpartition in the dynamic partition (Super) with the cow file map of the cow file itself, generating a new version of the file map of the subpartition data.

[0469] For example, the file map of the System subpartition is: " / system / app / A0.XXX: 024010~024013; / system / app / A1.XXX: 024014~024017; / system / app / A2.XXX: 024018~024020; / system / B0.XXX: 024021~024026; / system / B1.XXX: 024027~024028; / system / user / C0.XXX: " 024029~024032; / system / user / C1.XXX: 024033~024035; / system / user / C2.XXX: 024036~024040; / system / user / C3.XXX: 024041~024044. This is merged with the cow file map " / system / app / A2.XXX: 045033~045035; / system / user / C2.XXX: 045036~045040."

[0470] This will give you a new version of the file map for the System subpartition:

[0471] / system / app / A0.XXX: 024010~024013 (points to A0.XXX under / system / app in the dynamic partition (Super);

[0472] / system / app / A1.XXX: 024014~024017 (points to A1.XXX under / system / app in the dynamic partition (Super);

[0473] / system / app / A2.XXX: 045033~045035 (points to A2.XXX in / Update / system_b-cow-img.img.0000 in the Userdata partition);

[0474] / system / B0.XXX: 024021~024026 (points to B0.XXX under / system in the dynamic partition (Super);

[0475] / system / B1.XXX: 024027~024028 (points to B1.XXX under / system in the dynamic partition (Super);

[0476] / system / user / C0.XXX: 024029~024032 (points to C0.XXX under / system / user in the dynamic partition (Super);

[0477] / system / user / C1.XXX: 024033~024035 (points to C1.XXX under / system / user in the dynamic partition (Super);

[0478] / system / user / C2.XXX: 045036~045040 (points to C2.XXX in / Update / system_b-cow-img.img.0000 in the user data partition (Userdata);

[0479] / system / user / C3.XXX: 024041~024044 (points to C3.XXX under / system / user in the dynamic partition (Super)).

[0480] In the new version of the System subpartition's file map, the storage address of / system / app / A2.XXX does not point to / system / app / A2.XXX on the dynamic partition (Super) on storage, but rather to A2.XXX in system_b-cow-img.img.0000 within the user data partition (Userdata) on storage; similarly, the storage address of / system / user / C2.XXX does not point to / system / user / C2.XXX on the dynamic partition (Super) on storage, but rather to C2.XXX in system_b-cow-img.img.0000 within the user data partition (Userdata) on storage.

[0481] During the verification process, following the above synthesis method, new versions of file maps for all sub-partitions of the dynamic partition (Super) are obtained (if a corresponding COW file for a sub-partition is not written in the user data partition (Userdata), then the file map of that sub-partition is directly used as the new version of the file map). The new versions of the file maps for all sub-partitions are combined to generate a new version of the file system for the dynamic partition (Super).

[0482] Data is read from the new version of the file system based on dynamic partitions (Super), and all files contained in the new version of the file system based on dynamic partitions (Super) are read and their hash values ​​are calculated.

[0483] When the copy file is valid, the disk write status information in the metadata partition ( / metadata) of the base partition (Common) is changed from "Merged" to "wait for Merge". The disk write status information indicates whether a copy file needs to be written to the dynamic partition (Super). Specifically, the disk write status information includes an overall identifier for the dynamic partition (Super) and subpartition identifiers for each subpartition. When the overall identifier is "Merged", it means that none of the subpartitions of the dynamic partition (Super) need to be written to disk; when the overall identifier is "wait for Merge", it means that one or more subpartitions of the dynamic partition (Super) need to be written to disk; when a subpartition identifier is "Merged", it means that the subpartition does not need to be written to disk; when a subpartition identifier is "wait for Merge", it means that the subpartition needs to be written to disk.

[0484] S512, the upgrade engine verifies the COW files corresponding to the second static partition and the dynamic partition in turn.

[0485] The S513 upgrade engine changes the boot order of electronic devices from booting from the first static partition to booting from the second static partition.

[0486] For example, the boot order identifier in the Master Boot Record (MBR) can be rewritten from A to B. After the electronic device is powered on, if the electronic device reads the boot order identifier as A, it will boot from the first static partition, loading data from the first static partition during the boot process; if the electronic device reads the boot order identifier as B, it will boot from the second static partition, loading data from the second static partition during the boot process.

[0487] S514, OUC triggers the electronic device to restart.

[0488] For example, when the OUC triggers an electronic device to restart, it exits the current primary operating system, cuts off the power to the electronic device, and then turns the power back on.

[0489] The S515 electronic device sequentially loads data from the base partition, the second static partition, and the dynamic partition, as well as data from the COW file in the user data partition, and boots from the second static partition to run a second operating system.

[0490] For example, the electronic device first loads data from the common partition. During the loading of the common partition, the electronic device reads the boot flag in the common partition. When the boot flag in the common partition is (A), the device loads the first static partition after loading the common partition, and thus boots from the first static partition. When the boot flag in the common partition is (B), the electronic device loads the second static partition after loading the common partition, and thus boots from the second static partition.

[0491] In S515, the electronic device reads the boot flag from the common partition. The boot flag in the common partition is (B). After loading the common partition, the electronic device loads the second static partition and boots from the second static partition.

[0492] For example, when the electronic device loads the data from the second static partition and then loads the data from the dynamic partition (Super) and the user data partition (Userdata) in the COW file, the electronic device reads the disk status information from the metadata ( / metadata), determines whether it needs to retrieve the COW file from the specified path of the user data partition (Userdata) based on the disk status information, and uses a snapshot to merge and load the dynamic partition (Super) and the COW file.

[0493] Furthermore, in step S515, the electronic device does not load all the COW files in the dynamic partition (Super) and the user data partition (Userdata). Instead, it loads the corresponding files according to the operating requirements of the second operating system. Specifically, in step S515, the electronic device determines the files to be loaded based on the operating requirements of the second operating system and extracts the corresponding files from the COW files in the dynamic partition (Super) or the user data partition based on the snapshot for loading.

[0494] Specifically, in step S515, when a corresponding COW file exists in a subpartition of the dynamic partition (Super), a new version of the file map for each subpartition of the dynamic partition (Super) is generated based on the snapshot. The process of generating the new version of the file map can refer to step S511. The electronic device determines the files to be loaded according to the operating requirements of the second operating system and loads the files based on the new version of the file map of the subpartition of the dynamic partition (Super).

[0495] For example, the second operating system requires loading all data in the user directory ( / system / user) under the System subpartition. The electronic device reads the disk persistence status information from the metadata ( / metadata). In this information, the subpartition of the System subpartition is marked as "wait for merge." Therefore, the electronic device searches for a cow file under / Update in the Userdata partition. After finding the cow file system_b-cow-img.img.0000 under Update, it generates a new version of the file map for the System subpartition based on the snapshot and the file map of the cow file in system_b-cow-img.img.0000. Data is then loaded according to the storage addresses of all files under / system / user in the new version of the file map of the System subpartition. For example, based on the new version of the file map of the System subpartition:

[0496] / system / user / C0.XXX: 024029~024032;

[0497] / system / user / C1.XXX: 024033~024035;

[0498] / system / user / C2.XXX: 045036~045040;

[0499] / system / user / C3.XXX: 024041~024044.

[0500] Load C0.XXX at addresses 024029-024032, C1.XXX at addresses 024033-024035, C2.XXX at addresses 045036-045040, and C3.XXX at addresses 024041-024044.

[0501] Furthermore, when loading all data in the user directory ( / system / user) under the System subpartition, if the subpartition identifier of the System subpartition in the disk status information is "Merged", the electronic device will not search for the cow file in the / Update subpartition of the Userdata partition, but will directly load all data in the user directory ( / system / user) under the System subpartition.

[0502] Furthermore, when loading all data in the user directory ( / system / user) under the System subpartition, if the subpartition identifier of the System subpartition in the disk status information is "not written to disk (wait for Merge)", and the electronic device does not find the corresponding COW file of the System subpartition in the / Update directory of the Userdata partition, it indicates that there was a data writing error during the upgrade process (either a COW file writing error or a disk status information writing error). At this time, the electronic device rolls back to the first operating system and reports the upgrade failure log information to the OTA server.

[0503] Furthermore, during the process of loading data from the dynamic partition (Super) and the user data partition (Userdata) in the COW file, the electronic device needs to verify the file before loading it. Unlike step S511, in step S515, the dynamic partition (Super) + COW file are not verified as a whole; instead, only the file to be loaded is verified. For example, verification is based on dmverity (dm-verity is a target of dm (device mapper), a virtual block electronic device specifically used for file system verification). If the verification is successful, the file is loaded; if the verification fails, the electronic device is restarted, rolling back to the first operating system or attempting to load the file again.

[0504] S516, the electronic device has successfully started up and entered the user interface.

[0505] S517, the kernel performs a merge operation.

[0506] Understandably, in this application, the Merge operation specifically refers to writing the upgrade file (cow file) of the dynamic partition (Super) stored in the user data partition (Userdata) to the dynamic partition (Super) during the operating system upgrade process, so that the file of the dynamic partition (Super) completes the data upgrade, so that the electronic device does not need to load the dynamic partition (Super) and the cow file of the user data partition when it starts up next time, but only needs to load the dynamic partition (Super) to complete the boot of the electronic device.

[0507] Specifically, after a successful boot, the electronic device broadcasts a boot message, which then initiates the upgrade process. The upgrade process reads the disk scrambling status information from the metadata ( / metadata) of the base partition (Common). If the disk scrambling status information is "Merged," the electronic device enters normal operating mode.

[0508] If the disk write status information is "wait for Merge", the upgrade process will write the cow file in the user data partition to the dynamic partition (Super).

[0509] Specifically, the upgrade process writes the upgrade data from the cow file in the user data partition (Userdata) to the corresponding address in the dynamic partition (Super), so that all the data in the dynamic partition (Super) is the new version of the upgraded data.

[0510] For example, based on the file map of the System subpartition ( / system / app / A2.XXX: 024018~024020) and the cow file map ( / system / app / A2.XXX: 045033~045035), data at addresses 045033~045035 is written to addresses 024014~024017; based on the file map of the System subpartition ( / system / user / C2.XXX: 024036~024040) and the cow file map ( / system / user / C2.XXX: 045036~045040), data at addresses 045036~045040 is written to addresses 024036~024040.

[0511] Following this, the upgrade process deletes the COW file in the Userdata partition, returns the storage space to the Userdata partition, and changes the disk status information in the metadata ( / metadata) of the Common partition from "wait for Merge" to "merged".

[0512] In step S508, the data operation for static partition upgrade is performed on the operating system data in the second static partition, and it does not affect the operating system data in the currently booted first static partition. Furthermore, in step S511, the data operation for dynamic partition upgrade is performed on the virtual dynamic partition created in the user data partition (Userdata), and it does not affect the currently mounted dynamic partition (Super). Therefore, the user can use the electronic device normally throughout the entire operating system upgrade process. Moreover, after step S513, the electronic device does not need to restart immediately; the user can choose when to restart. Thus, the operating system upgrade process does not affect the user's normal mobile phone operation, thereby greatly improving the user experience. Furthermore, for the dynamic partition (Super), the virtual dynamic partition is only created on the user data partition (Userdata) when an upgrade is needed, thus effectively improving the utilization of data storage space.

[0513] In S518, kernel l synchronizes the data from the second static partition to the first static partition.

[0514] Based on the upgrade process described above, assuming the first static partition corresponds to operating system version 1.1, the electronic device boots from the first static partition and runs operating system version 1.1. When the operating system is upgraded to 1.2, the electronic device restarts and boots from the second static partition and runs operating system version 1.2; at this time, the electronic device runs operating system version 1.2. The first static partition corresponds to operating system version 1.1, and the second static partition corresponds to operating system version 1.2; the data in the first and second static partitions is not consistent. If the second static partition encounters an error, the first static partition cannot replace its function; that is, the first static partition cannot support the electronic device running operating system version 1.2. However, if the data between the first and second static partitions is always kept consistent, then if either the first or second static partition encounters an error, the other static partition can be used.

[0515] Therefore, after completing the Merge operation, the above-mentioned technical problem can be solved by synchronizing the static partitions, that is, by backing up the data between the first static partition and the second static partition.

[0516] For details on the kernel's implementation of synchronizing data from the second static partition to the first static partition, please refer to the section above. Figure 8.4 The textual description of step S125 is omitted here.

[0517] Furthermore, it should be noted that in practical application scenarios, the operating system upgrade 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 processing circuitry, receiving pins, and transmitting pins, which communicate with each other through internal interconnection paths. The processing circuitry is coupled to a memory, enabling the chip system to call the computer program stored in the memory during runtime, thereby implementing the steps executed by the electronic device.

[0518] In addition, it should be noted that the processing circuitry in this chip system can be either an application processor or a non-application processor.

[0519] Furthermore, this application also provides a computer-readable storage medium storing computer instructions. When these computer instructions are executed on an electronic device, the electronic device performs the aforementioned method steps to implement the operating system upgrade method described in the above embodiments.

[0520] Furthermore, this application also provides a computer program product that, when run on an electronic device, causes the electronic device to perform the aforementioned related steps to implement the operating system upgrade method described in the above embodiments.

[0521] Furthermore, as can be seen from the above description, the electronic device, computer-readable storage medium, computer program product, and chip 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.

[0522] The above-described embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit it. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the scope of the technical solutions of the embodiments of this application.

Claims

1. A method for upgrading an operating system, characterized in that, Applied to an electronic device, the electronic device including dynamic partitions and user data partitions, the method includes: Obtain the file list description information corresponding to the upgrade package. The file list description information indicates the first size of the upgrade package, the second size of the first upgrade file in the upgrade package after compression, and the third size of the first upgrade file before compression. The first upgrade file corresponds to the first sub-partition in the dynamic partition. If the first remaining space of the user data partition is greater than the sum of the first size and the third size, a first COW file corresponding to the first subpartition is created in the user data partition, where the first remaining space is the remaining space of the user data partition before downloading the upgrade package; If the first remaining space in the user data partition is greater than the sum of the first size and the second size, but less than the sum of the first size and the third size, a second cow file corresponding to the first subpartition is created in the user data partition in compressed form, and the size of the first cow file is greater than that of the second cow file. Wherein, the step of creating a second COW file corresponding to the first sub-partition in compressed form within the user data partition, wherein the size of the first COW file is larger than that of the second COW file, includes: If the first remaining space in the user data partition is greater than the sum of the first size and the second size, but less than the sum of the first size and the third size, the identifier corresponding to the compression attribute is set to the second identifier, and the second identifier indicates that the first upgrade file is installed using the COW compression function; Obtain the fourth remaining space of the user data partition, wherein the fourth remaining space is the remaining space of the user data partition after the upgrade package is downloaded; If the fourth remaining space of the user data partition is greater than the second size but less than the third size, the identifier corresponding to the compression attribute is set to the second identifier. Based on the second identifier, the second cow file corresponding to the first sub-partition is created in compressed form in the user data partition; If the fourth remaining space is greater than the third size, the identifier corresponding to the compression attribute is set to the first identifier, and the first identifier indicates that the first upgrade file is not installed using the COW compression function; Based on the first identifier, the second COW file corresponding to the first sub-partition is created in uncompressed form in the user data partition.

2. The method according to claim 1, characterized in that, The size of the first COW file is equal to the first remaining space minus the second remaining space and the first size. The second remaining space is the remaining space of the user data partition after downloading the upgrade package and creating the first COW file. The size of the second COW file is equal to the first remaining space minus the third remaining space plus the first size. The third remaining space is the remaining space in the user data partition after downloading the upgrade package and creating the second COW file.

3. The method according to claim 1 or 2, characterized in that, If the first remaining space in the user data partition is greater than the sum of the first size and the third size, a first COW file corresponding to the first subpartition is created in the user data partition, including: If the first remaining space in the user data partition is greater than the sum of the first size and the third size, the first cow file corresponding to the first subpartition is created in the user data partition in an uncompressed form.

4. The method according to claim 3, characterized in that, When the first remaining space in the user data partition is greater than the sum of the first size and the third size, the first COW file corresponding to the first subpartition is created in the user data partition in uncompressed form, including: If the first remaining space of the user data partition is greater than the sum of the first size and the third size, the identifier corresponding to the compression attribute is set to the first identifier, which indicates that the first upgrade file is not installed using the COW compression function; Based on the first identifier, the first cow file corresponding to the first sub-partition is created in uncompressed form in the user data partition.

5. The method according to claim 4, characterized in that, Before creating the first cow file corresponding to the first sub-partition in uncompressed form in the user data partition according to the first identifier, the method further includes: Obtain the upgrade package; After obtaining the upgrade package, the step of creating the first cow file corresponding to the first sub-partition in the user data partition in uncompressed form according to the first identifier is executed.

6. The method according to claim 5, characterized in that, After obtaining the upgrade package, and before executing the step of creating the first cow file corresponding to the first sub-partition in uncompressed form in the user data partition based on the first identifier, the method further includes: Obtain the fourth remaining space of the user data partition, wherein the fourth remaining space is the remaining space of the user data partition after the upgrade package is downloaded; If the fourth remaining space is greater than the third size, the identifier corresponding to the compression attribute is set to the first identifier; If the fourth remaining space is greater than the second size but less than the third size, the identifier corresponding to the compression attribute is set to the second identifier, which indicates that the first upgrade file is installed using the COW compression function.

7. The method according to any one of claims 4 to 6, characterized in that, After creating the first cow file corresponding to the first sub-partition in uncompressed form in the user data partition according to the first identifier, the method further includes: The data in the first upgrade file is written into the user data partition in uncompressed form to create the first cow file corresponding to the first subpartition in uncompressed form.

8. The method according to claim 1, characterized in that, Before creating the second cow file corresponding to the first sub-partition in compressed form in the user data partition according to the second identifier, the method further includes: Obtain the upgrade package; After obtaining the upgrade package, the step of creating the second cow file corresponding to the first sub-partition in compressed form in the user data partition according to the second identifier is executed.

9. The method according to claim 1 or 8, characterized in that, After creating the second cow file corresponding to the first sub-partition in compressed form in the user data partition according to the second identifier, the method further includes: The data in the first upgrade file is written into the user data partition in compressed form to create the second cow file corresponding to the first subpartition in compressed form.

10. The method according to claim 9, characterized in that, The step of writing the data from the first upgrade file into the user data partition in compressed form to create the second COW file corresponding to the first subpartition in compressed form includes: Remove the zeros from the data in the first upgrade file; The data with zeros removed is written to the user data partition to create the second cow file corresponding to the first subpartition in compressed form.

11. The method according to any one of claims 1 to 2, 4 to 6, 8, or 10, characterized in that, The method further includes: If the first remaining space of the user data partition is greater than the sum of the first size and the third size, during the operating system upgrade process, the electronic device will not perform any read or write operations on the user data partition other than the operating system upgrade. or, If the first remaining space of the user data partition is greater than the sum of the first size and the second size, but less than the sum of the first size and the third size, the electronic device will not perform any read or write operations on the user data partition other than the operating system upgrade during the operating system upgrade process.

12. The method according to any one of claims 1 to 2, 4 to 6, 8, or 10, characterized in that, The method further includes: If the first remaining space is less than the sum of the first size and the second size, a prompt will be made to clean up the user data partition.

13. The method according to claim 12, characterized in that, The prompt to clean up the user data partition includes: Determine the first difference between the sum of the first size and the second size and the first remaining space; The system prompts that the user data partition should be cleaned up to at least the space corresponding to the first difference.

14. The method according to claim 6, characterized in that, The method further includes: If the fourth remaining space is less than the second size, a prompt will appear to clean up the user data partition.

15. The method according to claim 14, characterized in that, The prompt to clean up the user data partition includes: Determine the second difference between the second size and the fourth remaining space; The system prompts that the user data partition should be cleaned up to at least the space of the second difference.

16. The method according to any one of claims 1 to 2, 4 to 6, 8, 10, or 13 to 15, characterized in that, 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 up, it sequentially loads the data in the base partition, the data in the first static partition, and the data in the dynamic partition to run a first operating system. After the first operating system runs, the step of obtaining the file list description information corresponding to the upgrade package is executed.

17. An electronic device, characterized in that, 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 up, it sequentially loads the data in the base partition, the data in the first static partition, and the data in the dynamic partition to run a 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 operating system upgrade method as described in any one of claims 1 to 16.

18. 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 operating system upgrade method as described in any one of claims 1 to 16.

Images