WO2023169035A1 - 操作系统的升级方法、电子设备及存储介质 - Google Patents

操作系统的升级方法、电子设备及存储介质 Download PDF

Info

Publication number
WO2023169035A1
WO2023169035A1 PCT/CN2022/139052 CN2022139052W WO2023169035A1 WO 2023169035 A1 WO2023169035 A1 WO 2023169035A1 CN 2022139052 W CN2022139052 W CN 2022139052W WO 2023169035 A1 WO2023169035 A1 WO 2023169035A1
Authority
WO
WIPO (PCT)
Prior art keywords
partition
upgrade
size
user data
file
Prior art date
Application number
PCT/CN2022/139052
Other languages
English (en)
French (fr)
Inventor
陈超
张赠辉
王艳召
黄九林
Original Assignee
荣耀终端有限公司
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 荣耀终端有限公司 filed Critical 荣耀终端有限公司
Priority to EP22899610.4A priority Critical patent/EP4270299A1/en
Publication of WO2023169035A1 publication Critical patent/WO2023169035A1/zh

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00—Arrangements for software engineering
    • G06F8/60—Software deployment
    • G06F8/65—Updates

Definitions

  • the present application relates to the field of computer technology, and in particular, to an operating system upgrade method, electronic equipment, and storage media.
  • the dynamic partition (Surper partition) exists in the form of a single partition
  • the upgrade file corresponding to the dynamic partition needs to be written to the user data partition ( Userdata partition)
  • the upgrade file is read from the user data partition and placed into the sub-partition corresponding to the dynamic partition. This will cause the operating system upgrade process to occupy more space in the user data partition, and even cause The upgrade failed due to insufficient space in the user data partition.
  • this application proposes an operating system upgrade method, electronic equipment and storage media. By selecting an upgrade method for dynamic partitions based on the remaining size of the user data partition space, without affecting the user's use, Ensure that electronic devices can normally complete operating system upgrades.
  • this application provides an operating system upgrade method, which is applied to electronic equipment.
  • the electronic equipment includes a processor and a memory.
  • the memory includes a basic partition, a first static partition, a second static partition, a dynamic partition and a user data partition.
  • the data of the basic partition, the data of the first static partition and the data of the dynamic partition are sequentially loaded to run the first operating system.
  • the method also includes: obtaining 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 compressed size of the first upgrade file in the upgrade package, and the uncompressed third size of the first upgrade file.
  • the first upgrade file corresponds to the first upgrade file in the dynamic partition.
  • One sub-partition when the first remaining space of the user data partition is greater than the sum of the first size and the third size, create the first copy-on-write cow file corresponding to the first sub-partition in the user data partition, and the first remaining space is The space is the remaining space of the user data partition before downloading the upgrade package; when the first remaining space of the user data partition is greater than the sum of the first size and the second size and less than the sum of the first size and the third size, in the user data partition Create a second cow file corresponding to the first sub-partition in the partition. The size of the first cow file is larger than the second cow file.
  • the sub-partitions of the dynamic partition occupy the user data partition in this operating system time.
  • the virtual logical partition that is, the size of the cow file, and then determines whether to select the cow file compression function based on the size of the cow file, so that the upgrade method can be reasonably selected based on the remaining space of the user data partition to meet the needs of different users.
  • the size of the first cow file is equal to the first remaining space minus the value of 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. space; the size of the second cow file is equal to the first remaining space minus the value of the third remaining space and the first size.
  • the third remaining space is the remaining space of the user data partition after downloading the upgrade package and creating the second cow file.
  • the first sub-partition when the first remaining space of the user data partition is greater than the sum of the first size and the third size, the first sub-partition is created in the user data partition.
  • the corresponding first copy-on-write cow file includes: 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 the first identifier, and the first identifier indicates The first upgrade file is installed without using the cow compression function; according to the first identifier, a first cow file corresponding to the first sub-partition is created in the user data partition in an uncompressed form. .
  • the method before creating the first cow file corresponding to the first sub-partition in the user data partition in an uncompressed form according to the first identifier, the method further includes: obtaining Upgrade package; after obtaining the upgrade package, perform 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.
  • the method after obtaining the upgrade package, create the first cow file corresponding to the first sub-partition in the user data partition in an uncompressed form according to the first identifier.
  • the method also includes: when the fourth remaining space of the user data partition is larger than the third size, setting the identification corresponding to the compression attribute as the first identification, and the fourth remaining space is the remaining space of the user data partition after downloading the upgrade package. space; when the fourth remaining space of the user data partition is greater than the second size and less than the third size, set the identifier corresponding to the compression attribute to the second identifier, and the second identifier indicates that the first upgrade file is installed using the cow compression function.
  • the method further includes: Write the data in the first upgrade file into the user data partition in an uncompressed form and create a first cow file corresponding to the first sub-partition in an uncompressed form.
  • the first remaining space of the user data partition when the first remaining space of the user data partition is greater than the sum of the first size and the second size, and is less than the sum of the first size and the third size. , create a second cow file corresponding to the first sub-partition in the user data partition.
  • the size of the first cow file is larger than the second cow file, including: the first remaining space of the user data partition is larger than the first size and the second size. If the sum is less than the sum of the first size and the third size, set the identification corresponding to the compression attribute to the second identification, and the second identification indicates that the first upgrade file is installed using the cow compression function; according to the second identification, in the user data partition Create the second cow file corresponding to the first subpartition in compressed form.
  • the method before creating a second cow file corresponding to the first sub-partition in a compressed form in the user data partition according to the second identifier, the method further includes: obtaining the upgrade package; after obtaining the upgrade package, perform the step of creating a second cow file corresponding to the first sub-partition in a compressed form in the user data partition according to the second identifier.
  • the method after obtaining the upgrade package, before executing the second cow file corresponding to the first sub-partition in the user data partition in a compressed form according to the second identifier. , the method also includes: when the fourth remaining space of the user data partition is larger than the third size, setting the identification corresponding to the compression attribute as the first identification, and the first identification indicates that the first upgrade file is not installed using the cow compression function, and the fourth The remaining space is the remaining space of the user data partition after downloading the upgrade package; when the fourth remaining space of the user data partition is larger than the second size but smaller than the third size, the identifier corresponding to the compression attribute is set to the second identifier.
  • the method further includes: In compressed form, the data in the first upgrade file is written into the user data partition to create a second cow file corresponding to the first sub-partition in compressed form.
  • writing the data in the first upgrade file into the user data partition in a compressed form and creating a second cow file corresponding to the first sub-partition in a compressed form including : Remove the 0s from the data in the first upgrade file; write the data with the 0s removed into the user data partition to create a second cow file corresponding to the first sub-partition in compressed form.
  • the electronic The device when the first remaining space of the user data partition is greater than the sum of the first size and the third size, during the process of upgrading the operating system, the electronic The device does not perform read or write operations on the user data partition other than operating system upgrades; or, the first remaining space in the user data partition is greater than the sum of the first size and the second size, but smaller than the sum of the first size and the third size. In this case, during the process of upgrading the operating system, the electronic device does not perform read or write operations on the user data partition other than upgrading the operating system.
  • prompting to clean up 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 to clean up the user data The partition clears at least the first difference in space.
  • prompting to clean the user data partition includes: determining a second difference between the second size and the fourth remaining space; prompting to clean the user data partition at least the second difference value space.
  • the present application provides an electronic device.
  • the electronic device includes a processor and a memory.
  • the memory includes a basic partition, a first static partition, a second static partition, a dynamic partition and a user data partition. After the electronic device is started, the data of the basic partition, the data of the first static partition and the dynamic partition are sequentially loaded. Partitioned data to run the first operating system; wherein the memory is coupled to the processor, and the memory stores program instructions; when the program instructions are executed by the processor, the electronic device is caused to execute the first aspect, or any one of the above first aspects Directives for implementing methods in a method.
  • the application provides a computer-readable storage medium for storing a computer program.
  • the computer program When the computer program is run on an electronic device, it causes the electronic device to execute the first aspect, or any implementation of the above first aspect. Instructions for methods in methods.
  • this application provides a computer program product.
  • the computer program product includes a computer program that, when run on an electronic device, causes the electronic device to execute the first aspect, or any implementation of the above first aspect. instructions in the method.
  • the present application provides a chip, which includes a processing circuit, a receiving pin and a sending pin.
  • the receiving pin, the sending pin and the processing circuit communicate with each other through an internal connection path, and the processing circuit executes the instructions of the first aspect, or the method in any implementation of the above first aspect, to control the receiving pin to receive Signal, control the sending pin to send the signal.
  • Figure 1 is a schematic diagram of the hardware structure of an electronic device
  • Figure 2 is a schematic diagram illustrating the type classification of internal memory
  • Figure 3 is a schematic diagram of the partition structure of the non-AB system, the AB system and the virtual AB system;
  • Figure 4 is a schematic diagram of the interaction between the package server, the OTA server and the electronic device during the operating system upgrade process
  • Figure 5.1 is a schematic diagram illustrating the writing of data in the upgrade package to a static partition during the operating system upgrade process
  • Figure 5.2 is a schematic diagram illustrating the writing of data in the upgrade package to a dynamic partition during the operating system upgrade process
  • Figure 5.3 is a schematic diagram illustrating the files included in the upgrade package
  • Figure 6.1 is a schematic diagram illustrating the creation of 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;
  • Figure 6.2 is an example showing that the remaining space of the user data partition is less than the sum of the upgrade package and the upgrade files corresponding to the uncompressed dynamic partition, and is larger than the sum of the upgrade package and the upgrade files corresponding to the compressed dynamic partition when the user data partition is created.
  • Figure 7.1 is a schematic diagram illustrating the static partition upgrade before and after the electronic device downloads the upgrade package from the OTA server during the operating system upgrade process;
  • Figure 7.2 is a schematic diagram illustrating an electronic device after upgrading the static partition and before upgrading the dynamic partition during the operating system upgrade process
  • Figure 7.3 is a schematic diagram illustrating the electronic device writing the first upgrade file to System_COW and verifying the dtbo_b sub-partition during the operating system upgrade process;
  • Figure 7.4 is a schematic diagram illustrating an electronic device verifying System_COW and restarting the electronic device during the operating system upgrade process
  • Figure 7.5 is a schematic diagram illustrating an electronic device performing a Merge operation and partition synchronization during the operating system upgrade process
  • Figure 7.6 is a schematic diagram illustrating an exemplary electronic device reporting the upgrade result to the OTA server after completing partition synchronization during the operating system upgrade process;
  • Figure 8.1 is an exemplary timing diagram between the packet server and the OTA server during the operating system upgrade process
  • Figure 8.2 is an exemplary sequence diagram of the electronic device obtaining the upgrade package from the OTA server during the operating system upgrade process
  • Figure 8.3 is an exemplary timing diagram of writing upgrade files to static partitions and dynamic partitions during the operating system upgrade process
  • Figure 8.4 is an exemplary timing diagram of operations performed after writing the upgrade file to the static partition and the dynamic partition during the operating system upgrade process
  • Figure 9 is a schematic flowchart illustrating the setting of compression attributes according to the first space judgment result during the operating system upgrade process
  • Figure 10 is a schematic flowchart of setting compression attributes according to the second space judgment result during the operating system upgrade process
  • Figure 11 is a schematic flowchart illustrating an exemplary process of selecting different installation methods according to different compression attributes to install upgrade files corresponding to dynamic partitions during the operating system upgrade process;
  • FIG. 12 is a schematic flowchart of an exemplary electronic device from startup to operating system upgrade to restarting to complete the operating system upgrade.
  • a and/or B can mean: A exists alone, A and B exist simultaneously, and they exist alone. B these three situations.
  • first and second in the description and claims of the embodiments of this application are used to distinguish different objects, rather than to describe a specific order of objects.
  • first target object, the second target object, etc. are used to distinguish different target objects, rather than to describe a specific order of the target objects.
  • multiple processing units refer to two or more processing units; multiple systems refer to two or more systems.
  • 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, and a battery 142.
  • Antenna 1 antenna 2, mobile communication module 150, wireless communication module 160, audio module 170, sensor module 180, button 190, motor 191, indicator 192, camera 193, display screen 194, and subscriber identification module, SIM) card interface 195, etc.
  • the audio module 170 may include a speaker 170A, a receiver 170B, a microphone 170C, a headphone interface 170D, and the like.
  • the sensor module 180 may include a pressure sensor, a gyroscope sensor, an air pressure sensor, a magnetic sensor, an acceleration sensor, a distance sensor, a proximity light sensor, a fingerprint sensor, a temperature sensor, a touch sensor, an ambient light sensor, a bone conduction sensor, and the like.
  • the keys 190 include a power key (power on key), a volume key, etc.
  • Key 190 may be a mechanical key. It can also be a touch button.
  • the electronic device 100 may receive key inputs and generate key signal inputs related to user settings and function control of the electronic device 100 .
  • the processor 110 may include one or more processing units.
  • the processor 110 may include an application processor (application processor, AP), a modem processor, a graphics processing unit (GPU), an image signal Processor (image signal processor, ISP), controller, memory, video codec, digital signal processor (digital signal processor, DSP), baseband processor, and/or neural-network processing unit, NPU) etc.
  • processing units may be independent devices or integrated in one or more processors.
  • the controller may be the nerve center and command center of the electronic device 100 .
  • the controller can generate operation control signals based on the instruction operation code and timing signals to complete the control of fetching and executing instructions.
  • the memory in processor 110 is primarily used to store instructions and data.
  • the memory in processor 110 is cache memory.
  • executable program codes that trigger the electronic device 100 to implement various functional applications and data processing are stored in the internal memory 121 , and these executable program codes include instructions.
  • the startup of the electronic device 100 and the upgrade of the operating system mainly rely on relevant instructions stored in the internal memory 121 in advance.
  • the processor 110 executes the instructions stored in the internal memory 121 instructions, thereby enabling the electronic device 100 to execute the operating system upgrade method provided by the embodiment of the present application.
  • the internal memory 121 may include a read-only memory 121A and a random access memory 121B, and the read-only memory 121A may be divided into a non-AB system ((1) in FIG. 3).
  • the AB system shown in (2) in Figure 3
  • the virtual AB system shown in (3) in Figure 3
  • Random Access Memory also known as “main memory”
  • main memory Random Access Memory
  • RAM also known as “main memory”
  • main memory Random Access Memory
  • RAM main memory
  • RAM random access memory
  • ROM read-only memory
  • the stored data is generally written in advance before being loaded into the whole machine, such as the image file of the operating system and the user data generated when the user uses electronic equipment.
  • the upgrade package downloaded from an Over-the-Air (OTA) server to the user data partition (located in the read-only memory 121A) of the electronic device
  • OTA Over-the-Air
  • the kernel cache of the random access memory 121B will be used to achieve fast reading and writing of the upgrade file.
  • the read-only memory 121A may be, for example, a disk storage device, a flash memory device, a universal flash storage (UFS), etc.;
  • the random access memory 121B may be, for example, a high-speed random access memory.
  • the read-only memory 121A may include a program storage area and a data storage area.
  • the stored program area can store an operating system, at least one application program required for a function (such as a sound playback function, an image playback function, etc.).
  • the storage data area may store data created during use of the electronic device 100 (such as audio data, phone book, etc.).
  • the stored program area can be, for example, basic partition (Common), static partition (Static partition) and dynamic partition (Super); regarding the stored data area, specifically to Among the technical solutions provided by the embodiments of the present application, it may be user data partitioning (Userdata), for example.
  • Common basic partition
  • Static partition static partition
  • Super dynamic partition
  • Userdata user data partitioning
  • the partition structure of the internal memory 121 of the electronic device 100 may be, for example, a non-AB system, an AB system, and a virtual AB system.
  • a non-AB system an AB system
  • a virtual AB system a partition that does not need to be upgraded during operating system upgrades, such as basic partitions and user data partitions, regardless of whether they are in non-AB System, AB system, or virtual AB system all use a single partition, but the partitions that need to be upgraded will be different.
  • the AB system is designed to allow users to return to the main interface of the electronic device at will during the operating system upgrade process of the electronic device, so as not to affect the use of the electronic device. Therefore, under the AB system, the static partition and the dynamic partition adopt dual partitions, as shown in (2) in Figure 3 for details.
  • the static partition can be divided into a first static partition and a second static partition, for example), and the dynamic partition For example, it can be divided into a first dynamic partition (SuperA) and a second dynamic partition (SuperB).
  • SuperA first dynamic partition
  • SuperB second dynamic partition
  • the virtual AB system combines the advantages of the non-AB system and the AB system, and divides the static partitions that store smaller files, that is, occupy smaller storage space, into a first static partition and a second static partition, and divide the stored files into a first static partition and a second static partition.
  • Larger, that is, dynamic partitions that occupy larger storage space use single partitions, as shown in (3) in Figure 3 for details.
  • the partition deployment information of the read-only memory 121A in the electronic device can be described through the partition table shown in Table 1.
  • the starting address and size of each partition are defined through the partition table, so that the corresponding partition size can be adjusted as needed for different hardware.
  • each partition has its corresponding image file.
  • the image file is compiled through software code and integrates the startup or operation process of the electronic device.
  • Various related function files and configurations Without image files, electronic devices cannot function.
  • a complete system version includes many images, including the partition table image gpt.img, boot-related images (xloader.img, boot.img), system image super.img (integrated with the android system core) and user data image userdata.img (used to store user data), etc.
  • the partitions recorded in the partition table can be divided and set according to actual business needs.
  • the distribution of partitions in the memory in the form of dual partitions in the AB system partition structure and the virtual AB system partition structure is not limited to what is shown in (2) in Figure 3 and (3) in Figure 3 style, in actual applications the location of each partition is determined based on the assigned start address and end address.
  • the electronic device 100 shown in FIG. 1 is only an example. In a specific implementation, the electronic device 100 may have more or more hardware than what is shown in the figure. With fewer parts, two or more parts may be combined, or may have different part configurations.
  • the various components shown in Figure 1 may be implemented in hardware, software, or a combination of hardware and software including one or more signal processing and/or application specific integrated circuits.
  • the upgrade package for upgrading the operating system of electronic devices is produced by the package server based on the version image, and is processed by the package server. Upload the produced upgrade package to the OTA server, and the OTA server will uniformly manage and actively push it to the connected electronic device, or send it to the corresponding electronic device according to the request of the connected electronic device.
  • the upgrade package produced by the package server based on the version image may include startup-related images (such as xloader.img, boot.img), system images (such as super.img), etc., which are not detailed here.
  • startup-related images such as xloader.img, boot.img
  • system images such as super.img
  • this embodiment does not limit this.
  • the package server in order to ensure that the operating system can be upgraded when the remaining space of the user data partition is sufficient or insufficient, the package server will also produce a description upgrade package when producing the upgrade package.
  • file list description information hereinafter referred to as filelist.xml
  • filelist.xml when uploading the upgrade package to the OTA server, the filelist.xml describing the upgrade package will be uploaded to the OTA server for management.
  • the filelist.xml produced by the package server at least includes an indication of the first size of the upgrade package (hereinafter referred to as fileSize) and an upgrade file indicating the upgrade of the dynamic partition.
  • fileSize an indication of the first size of the upgrade package
  • upgrade file indicating the upgrade of the dynamic partition.
  • the second size after compression hereafter called compressCowsize
  • uncompressCowsize the third size indicating that the upgrade file used to upgrade the dynamic partition is uncompressed
  • the electronic device After the electronic device obtains the upgrade package from the OTA server to upgrade the operating system, it will report the upgrade result to the OTA server so that the OTA server can know whether the operating system upgrade of the electronic device is successful.
  • the upgrade result reported by the electronic device to the OTA server may also include log information of the upgrade failure, in order to quickly locate the cause of the operating system upgrade failure.
  • the upgrade package downloaded by the electronic device from the OTA server is specifically stored in the user data partition.
  • the dynamic partition corresponds to During the sub-partitioning process, the random access memory RAM will read the data in the upgrade package stored in the user data partition into RAM, that is, perform step (1) in Figure 5.1, and then the RAM will be used to upgrade the static partition.
  • Write the data to the corresponding sub-partition in the static partition, that is, perform step (2) in Figure 5.1 and write the data used to upgrade the dynamic partition to the corresponding sub-partition in the dynamic partition, that is, perform step (3) in Figure 5.2 ).
  • the electronic device currently uses the first static partition as the startup sequence.
  • the RAM will write the data used to upgrade the dtbo sub-partition. Enter the dtbo_b subpartition currently in the second static partition of the backup partition.
  • Figure 5.2 takes the sub-partition in the dynamic partition that needs to be upgraded as the System sub-partition. Then RAM will write the data corresponding to the System sub-partition in the upgrade package to the cow file corresponding to the System sub-partition in the user data partition. That is System_COW in the user data partition in Figure 5.2.
  • the upgrade package usually includes a key verification file that stores key verification data, a version description file of the upgrade package, and payload.bin (which is an Android OTA image packaging file, including system. img, boot.img, recovery.img and other image files), and the properties file used to describe payload.bin.
  • payload.bin which is an Android OTA image packaging file, including system. img, boot.img, recovery.img and other image files, and the properties file used to describe payload.bin.
  • Metadata is a description of Data, used to indicate the specific location of the upgrade data of different partitions in Data. That is, Metadata is used to control the directory index and also plays the role of signature verification, while Data carries the upgrade data used to upgrade sub-partitions in static partitions and sub-partitions in dynamic partitions.
  • the electronic device in order to match the upgrade method with the electronic device, so as to take into account the user experience and ensure that the operating system can be quickly and normally upgraded, the electronic device is performing the operating system upgrade.
  • the remaining space of the user data partition will be judged, and the compression attributes will be set based on the judgment results, that is, whether to use the cow compression function.
  • the method when judging the remaining space and setting the compression attribute according to the judgment result, is specifically based on the remaining space of the user data partition and the fileSize, compressCowsize and uncompressCowsize in the above filelist.xml. Judge, and then set whether to use the cow compression function based on the judgment result.
  • the compressCowsize of the upgrade file corresponding to the System subpartition in the dynamic partition is 1.0G
  • the uncompressCowsize of the upgrade file corresponding to the System subpartition in the dynamic partition is 8.7G.
  • the compression attribute set is to use the cow compression function, that is, when the upgrade package is subsequently downloaded, the System_COW corresponding to the System subpartition created in the user data partition is created in compressed form, and the RAM corresponds to the System subpartition in the upgrade package.
  • the data is written to the compressed System_COW, the data needs to be compressed.
  • the compression attribute 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 compress System_COW, the compression algorithm can be selected according to industry needs. The data is compressed, and this embodiment does not limit the selection of the compression algorithm.
  • the electronic device will first perform step (1) in Figure 7.1 to obtain the first size of the upgrade package and the compressed second size of the first upgrade file in the upgrade package from the OTA server. , and the uncompressed third size of the first upgrade file, which corresponds to the System subpartition in the dynamic partition.
  • the corresponding cow file needs to be created in compressed form in the user data partition first ( Subsequently referred to as compressed cow file), and then write the upgrade file corresponding to the sub-partition in the dynamic partition into the compressed cow file in the form of a compressed file. That is, the upgrade file corresponding to the sub-partition in the dynamic partition is stored in the user's computer as a compressed cow file. Data partitioned.
  • the pop-up box reminds the user that the current first remaining space of the electronic device is insufficient and the user data space needs to be cleared
  • the user can also be reminded of the minimum amount of space that needs to be cleared to ensure that the operating system upgrade is re-triggered.
  • the upgrade package can be downloaded successfully.
  • a pop-up box reminds the user that the user data space to be cleared is at least the sum of the first size and the second size.
  • the electronic device can automatically detect whether the current first remaining space is available after a preset period. 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, smaller than the sum of the first size and the third size, then decide whether to download the upgrade package from the OTA server based on the detection result, that is, re-execute Step (2) in Figure 7.1.
  • if the current first remaining space of the electronic device is insufficient, after a pop-up box reminds the user to clear the user data space, when to re-execute step (2) in Figure 7.1 may be determined by the user. Actively triggered, for example, the user actively clicks on the control to upgrade the operating system.
  • step (2) in Figure 7.1 takes the case where the first remaining space of the user data partition is larger than the sum of the first size and the third size as an example, that is, the set compression attribute To not use the cow compression function.
  • 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.
  • step (3) in Figure 7.1 the electronic device will perform step (3) in Figure 7.1 to write the data of the second upgrade file corresponding to the dtbo sub-partition of the static partition in the upgrade package to the second static partition.
  • step (3) in Figure 7.1 the electronic device will perform step (3) in Figure 7.1 to write the data of the second upgrade file corresponding to the dtbo sub-partition of the static partition in the upgrade package to the second static partition.
  • the version of the dtbo_b sub-partition will be changed from dtbo_b(1.0) shown in Figure 7.1 to dtbo_b shown in Figure 7.2 (2.0).
  • the upgrade package does not include the second upgrade file, that is, there is no need to upgrade the sub-partitions in the static partition, there is no need to perform step (3) in Figure 7.1.
  • the electronic device writes the data in the second upgrade file to the dtbo_b sub-partition of the second static partition, that is, after upgrading the static partition, in order to avoid being occupied by other files during the download process of the upgrade package
  • the remaining space of the electronic device is reduced, resulting in insufficient space for the dynamic partition upgrade, and the upgrade cannot be completed.
  • the electronic device will perform another space judgment operation, that is, step (4) in Figure 7.2, in the user data partition.
  • a pop-up box reminds the user that the user data space to be cleared is at least the second size.
  • the electronic device can automatically detect whether the current fourth remaining space is available after a preset period. Larger than the third size, or larger than the second size, smaller than the third size, and then decide whether to continue the upgrade based on the detection results, that is, perform step (5) in Figure 7.2, or monitor the user's trigger operation, such as the user actively clicking to upgrade After installing the operating system controls, proceed with the upgrade.
  • the electronic device when the electronic device restarts upgrading the operating system after determining that the second user data space after user cleaning is larger than the third size, or smaller than the third size, or larger than the second size, You can re-download the upgrade package from the OTA server, and then upgrade the sub-partitions of the static partition and the sub-partitions of the dynamic partition in sequence to avoid the interruption of the upgrade operation, which may cause the written data to be lost or abnormal due to the user clearing the user data partition.
  • step (4) in Figure 7.2 takes the case where the fourth remaining space of the user data partition is larger than the second size and smaller than the third size as an example, that is, the second space judgment Then reset the compression properties to use the cow compression function.
  • the secondary space judgment operation on the user data partition in the above step (4) can be selected according to business requirements whether it needs to be performed, and this application does not limit this.
  • step (4) may be performed before step (3), that is, steps (3) and steps (4) may not be distinguished in order.
  • step (4) is used. ) is taken as an example after executing step (3).
  • step (5) in Figure 7.2 the electronic device will execute step (5) in Figure 7.2 to create a cow file (compressed System_COW) corresponding to the System subpartition in a compressed form in the user data partition.
  • the compressed System_COW created at this time is an empty cow file, that is, no data has been written yet.
  • the version of the compressed System_COW will be changed from the compressed System_COW shown in Figure 7.2 to the compressed System_COW shown in Figure 7.3 (2.0).
  • the static partition needs to be verified first, and then the dynamic partition is verified after the static partition verification is successful. If the static partition verification fails, the subsequent operations will be ended directly and reported to the OTA server. Upgrade failed message. Therefore, when verifying the sub-partition that has completed the write operation, the electronic device will first perform step (7) in Figure 7.3 to verify the dtbo_b sub-partition, that is, perform the verification on the sub-partition that has completed the write operation of the static partition. check. In order to facilitate the explanation of the operating system upgrade solution provided by this application, the successful verification of the dtbo_b sub-partition is taken as an example.
  • the electronic device will perform step (8) in Figure 7.4.
  • the content in the compressed System_COW will be verified.
  • the successful verification of compressed System_COW is taken as an example.
  • step (9) in Figure 7.5 the electronic device will perform step (9) in Figure 7.5.
  • the electronic device will be restarted.
  • the electronic device can be directly triggered to enter the whole machine restart, or it can be delayed to enter the whole machine restart.
  • the electronic device can automatically trigger the restart of the whole machine when the electronic device is idle, that is, when the user is not using it and no application is occupied; in another way, the electronic device can automatically trigger the restart of the whole machine.
  • the user can manually trigger the electronic device to restart the entire machine as needed.
  • the electronic device loads the data of the basic partition, the first static partition and the dynamic partition in sequence after starting, and the first operating system (operating system upgrade) is running. previous version), then after restarting, the electronic device sequentially loads the data of the basic partition, the data of the second static partition, the data of the dynamic partition and the data in the compressed System_COW file in the user data partition, so that the electronic device can run to the third Second operating system (operating system upgraded version SlotB (v2.0)).
  • the third Second operating system operating system upgraded version SlotB (v2.0)
  • step (10) Merge in Figure 7.6 will be executed to transfer the contents of the compressed System_COW file to the System subpartition.
  • System sub-partition will change from System (1.0) shown in the partition structure of the virtual AB system on the left in Figure 7.5 to System (2.0) shown in the partition structure of the virtual AB system on the right in Figure 7.5 .
  • step (11) in Figure 7.6 to synchronize the data in the dtbo_b sub-partition to the dtbo_a sub-partition, that is, perform a partition synchronization operation on the static partition. Specifically, this operation During the system upgrade process, the data in the upgraded static partition is synchronized to the non-upgraded static partition.
  • the electronic device when the operating system is upgraded this time to upgrade the files in the dtbo_b sub-partition in the second static partition from version 1.0 to version 2.0, after completing the Merge operation, the electronic device will store the files in the dtbo_b sub-partition. Copy to the dtbo_a sub-partition in the first static partition to achieve synchronization of the two sub-partitions.
  • the dtbo_a sub-partition will be changed from dtbo_a(1.0) shown in Figure 7.5 to dtbo_a(2.0) shown in Figure 7.6.
  • step (12) in Figure 7.6 the electronic device will perform step (12) in Figure 7.6 to report the upgrade result to the OTA server.
  • the upgrade result reported by the electronic device to the OTA server is content indicating that the operating system upgrade is successful; otherwise, the upgrade result reported by the electronic device is content indicating that the operating system upgrade is failed.
  • the functional units/modules/applications involved in the operating system upgrade process of electronic devices are first introduced.
  • this embodiment takes the operating system used by the electronic device as the Android system as an example.
  • the upgrade package may be obtained from an OTA server by a system upgrade client (OTA Update Client, OUC). Obtained.
  • the OUC mentioned in this embodiment is specifically an application installed in the application layer (Application) of the electronic device and used for operating system upgrade management.
  • OUC will send the obtained upgrade package to the upgrade engine (update_engine) in the electronic device, and update_engine will complete the upgrade of the static partition.
  • Update_engine and the snapshot process (snap process) Complete the upgrade of dynamic partition.
  • OUC triggers the electronic device to enter the complete machine restart.
  • the electronic device runs to the upgraded operating system, and the kernel (kernel) executes
  • the Merge operation moves the data in the cow file in the user data partition to the corresponding sub-partition in the dynamic partition, and update_engine performs partition synchronization on the static partition.
  • the upgrade of the operating system can also be completed through the entrance provided by the setting application installed in the application layer, and this embodiment is not limited to this.
  • the upgrade package produced by the package server can be produced as a differential upgrade package and a full upgrade package according to business needs.
  • the package server when making the upgrade package, will add compressCowsize and uncompressCowsize corresponding to the upgrade file of the sub-partition in the upgrade dynamic partition, as well as the size fileSize of the upgrade package to the filelist corresponding to the upgrade package. .xml, so that the electronic device can determine which installation method to use based on the content recorded in filelist.xml and the current remaining space of the user data partition, and install the upgrade file corresponding to the sub-partition in the dynamic partition into the user data partition.
  • filelist.xml will also include other parameter information required during the operating system upgrade process, such as " ⁇ support>”, “ ⁇ payloadOffset>”, “ “ ⁇ fileHash>”, “ ⁇ metadataHash>”, “ ⁇ metadataSize>”, “ ⁇ powerWash>”, “ ⁇ switchSlotOnReboot>”, “ ⁇ runPostInstall>”, etc. are not listed one by one here. This embodiment also No restrictions.
  • filelist.xml usually appear in pairs, that is, there are also " ⁇ /support>”, “ ⁇ /payloadOffset>”, “ ⁇ /fileHash>”, “ ⁇ /metadataHash>”, “ ⁇ /metadataSize>”, “ ⁇ /powerWash>”, “ ⁇ /switchSlotOnReboot>”, “ ⁇ /runPostInstall>”.
  • the content between “ ⁇ support>” and “ ⁇ /support>” is used to indicate whether the virtual AB system partition structure is supported, where “0” means not supported and “1" means supported; ⁇ payloadOffset> and “ ⁇ /support> The content between “payloadOffset>” is used to indicate the starting position of payload.bin; the content between “ ⁇ fileHash>” and “ ⁇ /fileHash>” is used to verify the file body in payload.bin; “ ⁇ metadataHash> The content between “ and “ ⁇ /metadataHash>” is used to verify the file metadata in payload.bin; the content between “ ⁇ metadataSize>” and “ ⁇ /metadataSize>” is used to indicate the file in payload.bin The size of the metadata; the content between “ ⁇ powerWash>” and “ ⁇ /powerWash>” is used to indicate whether the upgrade file should be restored to factory settings after the upgrade, where “0” means restoration and “1” means no restoration; “ ⁇ switchSlotOnReboot >”
  • post-install steps include metadata partition status data, switching static partitions, etc.
  • filelist.xml is stored in the upgrade package.
  • filelist.xml is independent of the upgrade package. In this way, when the electronic device makes space judgment, it does not need to obtain the upgrade package, and can first obtain filelist.xml that takes up less space.
  • the upgrade package and filelist.xml can be actively uploaded to the OTA server by the package server when it detects a new version of the upgrade package and the corresponding filelist.xml, or it can be According to the preset cycle, the newly released upgrade package and the corresponding filelist.xml are actively uploaded to the OTA server regularly.
  • condition for the package server to upload the upgrade package and filelist.xml may be to upload the newly released upgrade package and the corresponding filelist.xml to the OTA server after receiving a request from the OTA server. .
  • the OTA server in order to avoid redundant versions occupying the OTA server space, can periodically traverse the saved upgrade package and the corresponding filelist.xml to clear the redundant versions.
  • the OTA server in order to further reduce the space occupied by the OTA server, can regularly clean up the upgraded version of the old version and the corresponding filelist.xml.
  • the upgrade package used to upgrade the operating system installed in the electronic device is produced by the package server and then uploaded to the OTA server for management.
  • the OTA server will interact with the connected electronic device for data, that is, it will establish a communication link with the electronic device. Therefore, in some implementations, the electronic device can actively initiate a search request to the OTA server to determine whether there is an upgrade package corresponding to the new version of the operating system in the OTA server.
  • the OTA server when the OTA server detects that there is an upgrade package corresponding to a new version of the operating system, it can actively push notification information to inform the electronic device that there is currently an upgrade package for the new version of the operating system.
  • an electronic device actively initiates a search request to the OTA server to search whether there is an upgrade package corresponding to a new version of the operating system in the OTA server.
  • step S106 is performed. Otherwise, a search request is initiated to the OTA server regularly according to the set search cycle, or a search request is initiated to the OTA server when triggered by the user. .
  • the electronic device searches for an upgrade package corresponding to a new version of the operating system in the OTA server, it first initiates a filelist.xml request corresponding to the upgrade package to the OTA server. , instead of directly initiating a request to obtain the upgrade package.
  • fileSize, compressCowsize and uncompressCowsize are recorded in filelist.
  • filelist.xml corresponding to the upgrade package, so that you can determine whether the current remaining space can accommodate the upgrade package based on the fileSize, compressCowsize, and uncompressCowsize recorded in filelist.xml, as well as the current remaining space of the electronic device, and determine whether to use cow
  • the compression function installs the upgrade files corresponding to the dynamic partitions in the upgrade package.
  • the OTA server After receiving a request from an electronic device to obtain the filelist.xml corresponding to an upgrade package of a certain operating system, the OTA server will retrieve the filelist.xml from the specified storage address and then deliver it to the corresponding electronic device. .
  • S108 Set compression attributes according to the first remaining space, fileSize, compressCowsize, and uncompressCowsize of the local machine.
  • step S108 can be divided into the following three situations: (1) For the situation where the first remaining space is larger than fileSize+uncompressCowsize, set the compression attribute to "false"; (2) For the situation where the first remaining space is larger than fileSize+uncompressCowsize If fileSize+compressCowsize is less than fileSize+uncompressCowsize, set the compression attribute to "true”; (3) In other cases, such as if it is less than fileSize+compressCowsize, a pop-up box will remind the user to clean up the user data partition.
  • step S108 takes the set compression attribute as "true” as an example.
  • the upgrade package needs to be downloaded to the user data partition of the electronic device first, and then the upgrade package is decompressed, and the static partition is modified according to the upgrade file used to upgrade the static partition in the upgrade package.
  • To upgrade the sub-partitions specifically write the data of the upgrade files corresponding to different sub-partitions in the static partition into the corresponding sub-partitions, and upgrade the sub-partitions of the dynamic partition according to the upgrade files used to upgrade the dynamic partitions in the upgrade package, specifically as follows: First write the data of the upgrade files corresponding to different sub-partitions in the dynamic partition to the cow file created in the user data partition. Therefore, when setting the compression attributes, the remaining space of the local machine (specifically the remaining space of the user data partition), fileSize, compressCowsize, and uncompressCowsize are comprehensively considered to ensure that the set compression attributes are more reasonable.
  • Figure 9 which specifically includes:
  • OUC searches for an upgrade package in the OTA server.
  • step S105 Regarding the implementation method of OUC searching whether there is an upgrade package in the OTA server, please refer to the above description of step S105 for details, which will not be described again here.
  • OUC obtains the filelist.xml corresponding to the upgrade package from the OTA server.
  • filelist.xml is used to record description information related to the upgrade package, so in some implementations, it can be called file list description information.
  • the file list description information indicates the first size of the upgrade package (fileSize), the second size of the first upgrade file in the upgrade package (compressCowsize), the first upgrade file The third size (uncompressCowsize).
  • the first upgrade file corresponds to the first sub-partition in the dynamic partition
  • the second size is the compressed size
  • the third size is the uncompressed size
  • the first sub-partition can be, for example, the System sub-partition, the system_ext sub-partition, the Product sub-partition, and the Cust sub-partition in the dynamic partition (Super) in Figures 7.1 to 7.6. Any one of subpartitions and Odm subpartitions.
  • the first sub-partition can be, for example, the System sub-partition, the system_ext sub-partition, the Product sub-partition, and the dynamic partition (Super) in Figures 7.1 to 7.6. Any of the Cust sub-partition and Odm sub-partition.
  • first sub-partition mentioned in the above embodiment is only used to indicate that the sub-partition is a sub-partition in the dynamic partition, and serves as a limitation on the number and specific sub-partitions in the dynamic partition.
  • the "first upgrade file" mentioned above is only used to indicate that the upgrade file is used to upgrade the sub-partitions in the dynamic partition, and does not serve as a reference to the number of upgrade files and the number of upgrade files used to upgrade the sub-partitions in the dynamic partition. Restrictions on the specific sub-partitions corresponding to the upgrade file.
  • OUC obtains fileSize, compressCowsize, and uncompressCowsize from filelist.xml.
  • OUC obtains the first remaining space available spaceA of the user data partition.
  • the first remaining space mentioned in this embodiment is the remaining space of the user data partition before downloading the upgrade package.
  • OUC will calculate the sum of fileSize and uncompressCowsize (referred to as the first sum in this embodiment), and then determine whether the first remaining space is greater than the first sum.
  • step S206 is executed; otherwise, step S207 is executed.
  • first identifier such as “false” given in this embodiment, is used to indicate that the first upgrade file is installed without using the cow compression function.
  • the OUC can directly initiate a request to obtain the upgrade package from the OTA server, that is, perform step S210.
  • the above-mentioned second identifier such as “true” given in this embodiment, is used to indicate that the first upgrade file is installed using the cow compression function.
  • the first remaining space is not greater than the first sum, it indicates that the space available for the user data partition is insufficient.
  • the principle of space priority is adhered to, and the compression attribute is set to use the cow compression function, so that the data can be compressed as much as possible. Reduce the space occupied by user data partition.
  • OUC will make another judgment. .
  • 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.
  • step S210 is executed; otherwise, step S209 is executed.
  • the first sub-division will be subsequently created in a compressed form.
  • the cow file corresponding to the partition compressed cow file).
  • a pop-up box on the UI interface reminds to clear at least (fileSize+compressCowsize-available spaceA)Mb user data space.
  • OUC will calculate the difference between the second total and the first remaining space (this embodiment calls it the first difference), that is, (fileSize+compressCowsize-available spaceA), and then pop up the UI interface pop-up box (pop-up window) reminds the user that at least the first difference in space needs to be cleared in the user data partition.
  • the first difference that is, (fileSize+compressCowsize-available spaceA)
  • pop up the UI interface pop-up box reminds the user that at least the first difference in space needs to be cleared in the user data partition.
  • step S204 is re-executed.
  • the implementation method of re-executing step S204 when the preset conditions are met please refer to the description of insufficient space in the user data partition and cleaning up the user data partition in step (2) in Figure 7.1, which will not be described again here.
  • OUC obtains the upgrade package from the OTA server.
  • OUC can obtain the upgrade package from the OTA server based on the information recorded in filelist.xml, such as the address information of the upgrade package.
  • the OTA server after receiving the request to obtain the upgrade package initiated by OUC, the OTA server will respond to the request and deliver the requested upgrade package to OUC.
  • S111 Set the compression attribute according to the fourth remaining space of the machine (the remaining space after downloading the upgrade package), compressCowsize, and uncompressCowsize.
  • step S111 can be divided into the following three situations: (1) For the situation where the fourth remaining space is greater than uncompressCowsize, set the compression attribute to "false"; (2) For the situation where the fourth remaining space is greater than compressCowsize, If it is less than uncompressCowsize, set the compression attribute to "true”; (3) In other cases, such as if it is less than compressCowsize, a pop-up box will remind the user to clean up the user data partition.
  • step S111 in this embodiment the set compression attribute is "true" as an example.
  • step S111 can be executed according to actual needs, and the execution order of this step can be before issuing the upgrade command, or after issuing the upgrade command, before upgrading the static partition, or it can be After the static partition is upgraded, and before the dynamic partition is upgraded, there are no restrictions here.
  • This implementation takes the following as an example before issuing the upgrade command.
  • Figure 10 for the process of setting compression attributes according to the second space judgment result during the operating system upgrade process, which specifically includes:
  • OUC has downloaded the upgrade package from the OTA server.
  • OUC obtains available spaceB, the fourth remaining space of the user data partition.
  • OUC After OUC downloads the upgrade package from the OTA server, it will reacquire the currently available space of the user data partition, that is, the fourth remaining space.
  • this space judgment OUC only needs to determine whether the fourth remaining space is greater than uncompressCowsize.
  • the fourth remaining space is greater than uncompressCowsize, it indicates that the available space of the user data partition is sufficient, and the cow compression function does not need to be used in this operating system upgrade, so that efficiency can be prioritized and the upgrade operation can be completed quickly.
  • first identifier such as "false” given in this embodiment, is used to indicate that the first upgrade file is installed without using the cow compression function.
  • OUC can directly transmit the downloaded upgrade package to update_engine, that is, perform step S308.
  • the above-mentioned second identifier for example, "true” given in this embodiment, is used to indicate that the first upgrade file is installed using the cow compression function.
  • the fourth remaining space is not greater than uncompressCowsize, it indicates that the space available for the user data partition is insufficient.
  • the principle of space priority is adhered to, and the compression attribute is set to use the cow compression function, thereby minimizing the impact on the data partition.
  • OUC will make another judgment. That is, OUC will determine whether the fourth remaining space is greater than compressCowsize.
  • step S308 if the fourth remaining space is greater than compressCowsize, execute step S308; otherwise, execute step S307.
  • a pop-up box on the UI interface reminds you to clear at least (compressCowsize-available spaceB)Mb user data space.
  • OUC will calculate the difference between compressCowsize and the fourth remaining space (this embodiment calls it the second difference), that is, (fcompressCowsize-available spaceB), and then remind the user in the UI interface pop-up box (pop-up window) that the user needs to
  • the data partition clears the second difference space, so that 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 electronic devices.
  • step S302 is re-executed.
  • the implementation method of re-executing step S302 when the preset conditions are met please refer to the description of insufficient space in the user data partition and cleaning up the user data partition in step (4) in Figure 7.2, which will not be described again here.
  • OUC issues an upgrade command to update_engine.
  • OUC further determines the remaining space of the user data partition before notifying update_engine to install the upgrade file in the upgrade package, and resets the compression attribute based on the judgment result, further ensuring the subsequent installation method determined based on the compression attribute. Reasonableness, thereby ensuring that the upgrade of the operating system can be completed normally.
  • OUC downloads the upgrade package from the OTA server, and the description of the space judgment and compression attributes before installation is introduced here.
  • the following is the case where the compression attribute set in step S111 is "true" based on Figure 8.2 to Figure 8.4.
  • the operating system upgrade solution provided in this embodiment will be described further.
  • step S113 is an optional step for the technical solution provided by this embodiment, that is, step S113 will be executed only when the upgrade package includes an upgrade file for upgrading the static partition.
  • update_engine After update_engine receives the upgrade command, it will read the compression attributes set by OUC, for example, read the compression attributes through the getprop statement.
  • the installation method corresponding to the first upgrade file (the upgrade file for upgrading the sub-partition in the dynamic partition) is not using cow.
  • the first installation method of compression function installation if the identification corresponding to the read compression attribute is the second identification (true) mentioned above, determine the installation corresponding to the first upgrade file (upgrade file for sub-partitions in the dynamic partition) The method is the second installation method using the cow compression function.
  • this embodiment takes the set compression attribute as "true” as an example, the compression attribute determined by update_engine is "true”, so the snap process will create a second cow file in a compressed form in the user data partition ( Subsequently called compressed cow file), that is, a compressed cow file is created in a compressed form in the user data partition according to the second identifier.
  • the compression attribute is the above-mentioned second identifier as an example. If in actual application, the identifier corresponding to the read compression attribute is the above-mentioned first identifier (such as false ), it is determined that the installation method corresponding to the first upgrade file (the upgrade file for upgrading the sub-partition in the dynamic partition) is the first installation method that does not use the cow compression function. In this case, the snap process will, based on the first identifier, Create the first cow file corresponding to the first sub-partition in the user data partition in uncompressed form (hereinafter referred to as the uncompressed cow file), so that update_engine writes the first upgrade file into the uncompressed cow file in uncompressed form.
  • the uncompressed cow file uncompressed cow file
  • the size of the first cow file is larger than the second cow file, that is, the uncompressed cow size of the uncompressed cow file is larger than the compressCowsize of the compressed cow file.
  • the snap process will send a message to update_engine after successfully creating the compressed cow file. Feedback message that the compressed cow file is successfully created.
  • update_engine will execute step S117 after receiving a message from the snap process that the compressed cow file is successfully created.
  • update_engine calls the snap process to create an uncompressed cow file in an uncompressed form in the user data partition, then after the snap process successfully creates the uncompressed cow file, it will feed back to update_engine to facilitate the creation of the uncompressed cow. Success message, so update_engine will write the data in the upgrade file corresponding to the dynamic partition in the upgrade package to the uncompressed cow file in uncompressed form after receiving feedback from the snap process that the uncompressed cow file is successfully created. .
  • the above-mentioned writing of the data in the upgrade file corresponding to the dynamic partition in the upgrade package (hereinafter referred to as the first upgrade file) in a compressed form into the compressed cow file means that the Assume that the compression algorithm removes all 0s from the data in the first upgrade file, and then writes the data with 0s removed into the compressed cow file.
  • 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 it is.
  • the snap process fails to create a cow file (whether it is a compressed cow file or a non-compressed cow file)
  • the snap process will feedback the cow file creation failure message to update_engine, so that update_engine receives
  • the snap process reports the failure to create the cow file, it will end the operating system upgrade operation and directly report the upgrade failure information to the OTA server.
  • Figure 11 which specifically includes:
  • update_engine After update_engine receives the upgrade command issued by OUC, it will read the compression attributes set by OUC.
  • the installation method corresponding to the first upgrade file (the upgrade file for upgrading the sub-partition in the dynamic partition) is to use the cow compression function.
  • update_engine notifies the snap process to create a compressed cow file in a compressed form in the user data partition, that is, execute step S402; if the identifier corresponding to the read compression attribute is the first identifier mentioned above (such as false)
  • update_engine notifies the snap process to create a non-compressed file in the user data partition in a non-compressed form. Compress the cow file, that is, perform step S404.
  • the snap process creates a compressed cow file in the user data partition.
  • update_engine writes the upgrade file corresponding to the dynamic partition into the compressed cow file in compressed form.
  • update_engine 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 a compressed form into the compressed cow file, so that the impact on the user data partition can be reduced as much as possible. Occupation of space.
  • the snap process creates a non-compressed cow file in the user data partition.
  • update_engine writes the upgrade file corresponding to the dynamic partition into the uncompressed cow file in uncompressed form.
  • update_engine 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 in an uncompressed form to the uncompressed cow file, so that the operating system upgrade process will Prioritizing efficiency, since there is no need to compress the first upgrade file and write uncompressed cow files in between, the writing speed is fast, which will shorten the upgrade time of the operating system and also reduce the power consumption of electronic devices. .
  • the static partition needs to be upgraded first according to the upgrade package.
  • the dynamic partition needs to be upgraded according to the upgrade package.
  • verify the static partition and dynamic partition in sequence verify the static partition and dynamic partition in sequence.
  • this embodiment refers to the upgrade file for upgrading the sub-partition in the static partition as the second upgrade file.
  • the upgrade engine obtains the second upgrade file from the upgrade package, and then upgrades the data of the currently idle static partition based on the second upgrade file.
  • the operating system upgrade process performed after the electronic device is started is specifically to upgrade the data of the second static partition according to the second upgrade file.
  • update_engine will report the verification success information to OUC, that is, step S119 is performed.
  • update_engine will also report verification information to OUC. In this case, the verification failure information is reported.
  • update_engine reports successful verification information to OUC.
  • OUC will execute step S120.
  • the OUC will trigger the electronic device to restart the entire machine.
  • the operation of OUC triggering the electronic device to restart the entire machine please refer to the description of the step (9) of restarting the electronic device in Figure 7.4 in the above embodiment, and will not be described again here.
  • this embodiment uses the cow compression function, that is, the upgrade file for the sub-partition of the dynamic partition is written to the compressed cow file in a compressed form. Therefore, when restarting the electronic device and sequentially loading the data of the basic partition, the data of the second static partition, the data of the dynamic partition and the data in the compressed cow file in the user data partition, it is necessary to decompress the cow file so that the compressed cow file can be The compressed data in the electronic device is processed into a non-compressed format, and then loaded so that the electronic device runs to the upgraded operating system (hereinafter referred to as the second operating system).
  • the second operating system hereinafter referred to as the upgraded operating system
  • the electronic device is restarted and the data of the basic partition, the data of the second static partition, the data of the dynamic partition and the user data are loaded in sequence.
  • the data in the uncompressed cow file in the partition is stored, there is no need to decompress the uncompressed cow file and the data can be read directly from it.
  • the electronic device starts with the first static partition as the startup sequence before upgrading the operating system, that is, the data of the basic partition, the first static partition are loaded in sequence during startup. data and dynamic partition data. Therefore, in the above operating system upgrade plan, the second static partition is upgraded. Therefore, the data of the second static partition needs to be loaded during restart, that is, the startup sequence is changed from the first static partition to the second static partition. Partition starts.
  • the snap process notifies the kernel to perform a Merge operation, that is, step S122.
  • the kernel after receiving the notification to perform the Merge operation sent by the snap process, the kernel will execute step S123.
  • the Merge operation mentioned in this embodiment specifically refers to the process of placing the upgrade file for upgrading the dynamic partition in the user data partition to the dynamic partition, that is, the data in the cow file is placed to the corresponding sub-partition of the dynamic partition. the process of.
  • the kernel will report the Merge result to the upgrade engine so that the upgrade engine can know whether the upgrade file for upgrading the dynamic partition in the user data partition is placed in the dynamic partition.
  • step S125 is performed. Otherwise, the upgrade failure can be directly reported to the OTA server through OUC.
  • 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 even if the upgrade fails, the electronic device can be used normally.
  • the partition synchronization operation is performed on the static partition, specifically, the data of the second static partition is synchronized to the second static partition.
  • a static partition
  • the kernel may read the data in each sub-partition of the second static partition; and then synchronize each sub-partition of the second static partition. The data in the sub-partition is overwritten to the sub-partition corresponding to the first static partition.
  • the operating system upgrade may only upgrade one or several sub-partitions in the static partition. Therefore, when performing partition synchronization, in order to reduce the occupation of electronic device resources by partition synchronization, you can First, check whether the data in the second sub-partition in the second static partition is the same as the data in the third sub-partition in the first static partition.
  • the copy of the sub-partition will be skipped and comparison will continue with other sub-partitions; otherwise, the copy of the second sub-partition will be compared.
  • the data is copied and then overwritten to the third subpartition.
  • the processing can be:
  • the second sub-partition is a sub-partition of the second static partition
  • the third sub-partition is a sub-partition of the first static partition
  • the third sub-partition corresponds to the second sub-partition.
  • the OUC will report the upgrade result to the OTA server so that the OTA server can know whether the upgrade of the operating system is successful.
  • the operation of the OUC to report the upgrade result to the OTA server please refer to the description of the upgrade result reporting part in step (12) in Figure 7.6 in the above embodiment, and will not be described again here.
  • step S118, step S119 and step S125 shown in Figure 8.4 whether to execute can be set according to business requirements. Whether to execute or not will not affect the technical solution provided by this embodiment.
  • This embodiment takes execution as an example. Be explained.
  • the electronic device when upgrading the operating system using the technical solution provided by this embodiment, in order to know whether the electronic device uses the cow compression function or does not use the cow compression function during the upgrade process of the operating system, it can be stipulated in When the first remaining space of the user data partition is greater than the sum of the first size and the third size, during the process of upgrading the operating system, the electronic device does not perform read or write operations on the user data partition other than upgrading the operating system.
  • the electronic device has a negative impact on the user.
  • the data partition does not perform read or write operations except for operating system upgrades.
  • the remaining space of the user data partition that is, the above-mentioned first remaining space, specifically the remaining space of the user data partition before downloading the upgrade package
  • the technical solution is to write the data of the dynamic partition into the cow file of the user data partition and obtain the remaining space of the user data partition before restarting.
  • 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 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 specified in this embodiment, it can be determined whether the cow compression function is used in this upgrade or whether the cow compression function is not used.
  • this embodiment will refer 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. After downloading the upgrade package and creating the second cow file, the remaining space of the user data partition is called the third remaining space.
  • the size of the first cow file is equal to the first remaining space minus the value of the second remaining space and the first size
  • the size of the second cow file is equal to the first remaining space minus the value of the third remaining space and the first size.
  • the first remaining space of the user data partition is 10.0G.
  • the remaining space is 825.2M.
  • the first size of the upgrade package is 506M.
  • the calculation method of cow file shows that the created cow file occupies 8.7G (10.0G-825.2M-506M) of the user data partition.
  • 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
  • the first size of the upgrade package is 506M
  • the calculation method of the second cow file shows that the created cow file occupies 1.0G (2.0G-518M-506M) of the user data partition.
  • the size of the first cow file (cow file created in uncompressed form) is larger than the size of the second cow file (cow file created in compressed form)
  • the upgrade packages are both 506M
  • the first remaining space of the user data partition before the upgrade package is 10.0G.
  • the remaining space after downloading the upgrade package and creating the cow file is 825.2M
  • the operating system upgrade does not use the cow compression function.
  • the user data partition Before downloading the upgrade package, the user data partition The first remaining space is 2.0G. After downloading the upgrade package and creating the cow file, the remaining space is 518M.
  • the operating system upgrade uses the cow compression function.
  • the installation method of the upgrade file corresponding to the sub-partition in the dynamic partition depends on the current remaining space of the user data partition and the size of the upgrade file (compressed size, non-compressed size). ), so that during the operating system upgrade process, it can be decided according to specific circumstances whether to use the cow compression function to meet the needs of different users.
  • the installation time required for the upgrade method without using the cow compression function is: 142s.
  • the installation time is 145s. Therefore, the installation operation time in the upgrade method using the cow compression function is 2% longer than that in the upgrade method without the cow file compression function.
  • the time spent on the verification operation increased by 315%
  • the time spent on the Merge operation increased by 459%
  • the total time spent on installation, verification, and Merge increased by 108%. This resulted in a 6% increase in the overall power consumption of electronic equipment during the upgrade process.
  • the size of the user data partition (userdata) occupied before the electronic device is restarted is significantly smaller than that occupied by the cow compression function, and the differential upgrade package is reduced by 89 %, the full upgrade package has been reduced by 44%.
  • the electronic device sequentially loads the data of the basic partition, the data of the first static partition, and the data of the dynamic partition, and starts from the first static partition to run the first operating system.
  • the electronic device periodically initiates a packet search request to the OTA packet server, and the packet search request contains the version number of the operating system currently running on the electronic device (for example, version 1.1); the OTA server performs the packet search according to the packet search request.
  • the version number of the operating system in the request is used to retrieve whether there is currently an upgrade package with a newer version number (for example, version 1.2); when there is an upgrade package with a newer version, the OTA server feeds back the upgrade package to the electronic device (for example, upgrading from version 1.1 to The download address of filelist.xml corresponding to the system incremental upgrade package of version 1.2); the electronic device downloads filelist.xml according to the download address of filelist.xml.
  • OUC obtains the first remaining space of the user data partition.
  • OUC sets the compression attribute according to the first remaining space and fileSize, compressCowsize, and uncompressCowsize in filelist.xml.
  • steps S501 to S504 please refer to the above text description of Figures 7.1 to 9, and will not be described again here.
  • this embodiment takes as an example the case where the set compression attribute is "false", that is, the first remaining space is greater than the sum of fileSize and uncompressCowsize.
  • OUC obtains the upgrade package from the OTA server.
  • the electronic device after the electronic device initiates a request to obtain the upgrade package (for example, version 1.2) from the OTA package server, the OTA server feeds back the upgrade package (for example, upgrade from version 1.1 to version 1.2) to the electronic device.
  • the download address of the system incremental upgrade package 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 (Userdata).
  • OUC obtains the fourth remaining space of the user data partition.
  • OUC sets the compression attribute according to the fourth remaining space and compressCowsize and uncompressCowsize.
  • step S506 and step S507 please refer to the above text description of Figures 7.2 to 10, and will not be described again here.
  • this embodiment still takes the case where the set compression attribute is "false", that is, the fourth remaining space is larger than uncompressCowsize, as an example.
  • the upgrade engine in the electronic device upgrades the second static partition according to the upgrade file corresponding to the second static partition in the upgrade package.
  • 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.
  • the upgrade engine reads the compression attributes set by the OUC and determines the installation method of the dynamic partition.
  • the cow file corresponding to the System subpartition is System_COW. It is understandable that if the determined installation method is to use the cow compression function, the System_COW created in step S510 is a compressed cow file; if the determined installation method is not to use the cow compression function, then the System_COW created in step S510 is a non-compressed cow file. document.
  • the upgrade engine writes the upgrade file corresponding to the dynamic partition in the upgrade package into the corresponding cow file according to the determined installation method.
  • the upgrade package contains the data of the dynamic partition of version 1.2, and the electronic device writes the data of the dynamic partition (Super) of version 1.2 in the cow file created in the user data partition.
  • cow file is a compressed cow file
  • the data of the dynamic partition containing version 1.2 in the upgrade package is written to the compressed cow file, it is written in compressed form; otherwise, no compression is needed, and non-compressed data is written in between. in a compressed cow file.
  • an incremental upgrade method is adopted for the dynamic partition (Super).
  • the cow file of the user data partition (Userdata) is not all the files of the upgraded new version of the dynamic partition (Super), but the data that needs to be upgraded in the old version of the dynamic partition (Super).
  • the final upgrade result That is, the cow file of the user data partition (Userdata) stores the updated data of the dynamic partition.
  • the data in the system subpartition can be divided into two parts: system1 and system2.
  • the data system2 does not change, and the data syetem1 is upgraded to system3.
  • the electronic device creates a cow file in the user data partition (Userdata) and writes data system3 in the cow file.
  • the system incremental upgrade package from version 1.1 to version 1.2 contains the dynamic partition (Super) update data from version 1.1 to version 1.2, and the dynamic partition (Super) update data includes the data system3.
  • the upgrade data of the dynamic partition (Super) saved in the user data partition (Userdata) contains multiple cow files.
  • Each cow file corresponds to a sub-partition of the dynamic partition (Super).
  • the cow file is named according to the dynamic partition it targets.
  • the cow file of the upgrade data of the dynamic partition (Super) is compressed and saved in the form of binary code.
  • each cow file is named according to the dynamic partition (Super) subpartition it targets.
  • the cow file for the System subpartition is named system-cow-img.img.0000.
  • step S511 the electronic device unpacks the upgrade package to obtain all cow files, and appends an AB partition mark to each cow file.
  • the dynamic partition (Super) loaded by the operating system currently running on the electronic device is the dynamic partition (A).
  • the cow file created in the user data partition (Userdata) is for the dynamic partition (B). Therefore, the name tag _b corresponding to the dynamic partition (B) is appended to the cow file. For example, appending _b to system-cow-img.img.0000 generates system_b-cow-img.img.0000.
  • step S511 an Update folder is created in the user data partition (Userdata), and the renamed cow file is saved under the Update folder.
  • the Update folder of the user data partition (Userdata) contains the following files:
  • the cow file contains the cow file map (snapshot map) and upgrade data of the cow file itself.
  • the cow file map corresponds to the file map of the sub-partition of the dynamic partition (Super) targeted by the cow file.
  • the file map of the sub-partition of the dynamic partition (Super) is used to describe all the files in the sub-partition of the current version of the operating system (the version before this upgrade, for example, version 1.1) and the storage address of each file. .
  • the upgrade data in the cow file is the updated files in the new version of the sub-partition data compared to the current version of the sub-partition data; the cow file map of the cow file itself is used to describe the updated files and the current version of the sub-partition.
  • the correspondence between the files in the file and the storage address of the updated file is the same as the previous version of the sub-partition data.
  • the upgraded data in the cow file can be used to replace the corresponding files in the sub-partition of the dynamic partition (Super), thereby realizing the dynamic partition (Super ) data upgrade.
  • a snapshot operation can be performed on the data of the sub-partition of the dynamic partition (Super) based on the snapshot to generate the file map of the sub-partition of the dynamic partition (Super).
  • You can also pre-generate the file map of the sub-partition of the dynamic partition (Super) when making the upgrade package, and add the file map to the cow file.
  • the file map of the System subpartition can be:
  • the value after the file name is the physical storage address (block address) of the file in the System subpartition of the dynamic partition (Super).
  • /system/app/A2.XXX and /system/user/C2.XXX are the system1 part of the system sub-partition data
  • 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.
  • the cow file map of the cow file (system_b-cow-img.img.0000) can be:
  • Map1 (the address of the data to be updated in the original Super partition): starting address address start: 024018 (offset relative to the starting address of the System subpartition); offset size size: 2 (i.e., the address segment from 024018 to 024020 data)
  • Map2 (the address of the updated data stored in the cow file): starting address address start: 045033 (offset relative to the starting address stored in the cow file); offset size size: 2 (i.e. 045033 ⁇ 045035 address segment The data);
  • Map1 (the address of the data to be updated in the original Super partition): starting address address start: 024036 (offset relative to the starting address of the System subpartition); offset size size: 4 (i.e., the address segment from 024036 to 024040 data)
  • Map2 (the address of the updated data stored in the cow file): starting address address start: 045036 (offset relative to the starting address stored in the cow file); offset size size: 4 (i.e. 045036 ⁇ 045040 address segment The data).
  • the cow file map of the cow file (system_b-cow-img.img.0000) can be:
  • Map1.1 (the address of the data to be updated in the original Super partition): starting address address start: 024018 (offset relative to the starting address of the System subpartition); offset size size: 2 (that is, 024018 ⁇ 024020 addresses segment data)
  • Map2.1 (the address of updated data stored in the cow file that needs to overwrite the Map1.1 address): starting address address start: 045033 (offset relative to the starting address stored in the cow file); offset size size: 2 (that is, the data in the address segment 045033 ⁇ 045035);
  • Map1.2 (the address to be written in the original super partition of the part of the updated data in the cow file that exceeds the size of the data to be updated): start address address start: 025018 (offset relative to the system start address); offset Amount size: 1 (that is, the data in the address segment 025018 ⁇ 025020)
  • Map2.2 (the address of updated data stored in the cow file that needs to overwrite the Map1.2 address): starting address address start: 046033 (offset relative to the starting address stored in the cow file); offset size size: 2 (that is, the data in the address segment 046033 ⁇ 046035).
  • the address segments (045033 ⁇ 045035 and 045036 ⁇ 045040) are the latest versions of /system/app/A2.XXX and /system/user/C2 in the cow file (system_b-cow-img.img.0000) respectively.
  • .XXX is the physical storage address (block address) of the user data partition (Userdata).
  • step S511 after the cow file is written to the user data partition (Userdata), the dynamic partition (Super)+cow file also needs to be verified as a whole to verify the validity of the dynamic partition (Super)+cow file. property, verify whether the synthesis result of the current version of dynamic partition (Super) data + cow file is the new version of dynamic partition (Super) data.
  • the data that does not need to be upgraded in the dynamic partition (Super) (data that has not changed from version 1.1 to version 1.2) and the upgraded data in the cow file (from version 1.1 to version 1.2).
  • the hash value of the synthetic result of the data that needs to be upgraded in version 1.2 determine whether the 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 , it means that the cow file is invalid, the upgrade fails, the upgrade process is interrupted and an error is reported; among them, the hash value of the complete data of the dynamic partition (Super) in version 1.2 is saved in the upgrade package.
  • dynamic partition (Super)+cow files are merged based on snapshots.
  • the merging of the dynamic partition (Super) and the cow file is not a physical merger, but the file map of the sub-partition in the dynamic partition (Super) and the cow file map of the cow file itself. Generate a new version of the file map of the subpartition data.
  • the save address of /system/app/A2.XXX does not point to /system/app/A2.XXX on the dynamic partition (Super) on the storage, but points to the user on the storage.
  • the saving address of /system/user/C2.XXX does not point to /system/user/C2 on the dynamic partition (Super) on the memory .
  • XXX but points to C2.XXX in system_b-cow-img.img.0000 in the user data partition (Userdata) on the memory.
  • the new version of the file system based on dynamic partition (Super) reads data, reads all files contained in the new version of the file system of dynamic partition (Super) and calculates the hash value.
  • the disk placement status information includes the overall identifier for the dynamic partition (Super) and the sub-partition identifier for each sub-partition.
  • the overall mark is "Merged”, it means that all sub-partitions of the dynamic partition (Super) do not need to be merged; when the overall mark is "Wait for Merge", it means that the dynamic partition (Super) is dynamic.
  • One or more sub-partitions of the partition (Super) need to be put to disk; when the sub-partition is marked as "Merged”, it means that the sub-partition does not need to be put to disk; when the sub-partition is marked as "Not yet dropped” "Disk (wait for Merge)", it means that the subpartition needs to be disked.
  • S512 The upgrade engine sequentially verifies the cow files corresponding to the second static partition and the dynamic partition.
  • the upgrade engine changes the startup sequence of the electronic device from starting from the first static partition to starting from the second static partition.
  • the startup sequence identifier of the Master Boot Record (Master Boot Record, MBR)
  • MBR Master Boot Record
  • the startup sequence identifier is A
  • the electronic device starts from the first static partition
  • the data of the first static partition is loaded during the startup process
  • the electronic device reads that the startup sequence identifier is B
  • the electronic device starts from the second static partition
  • the data of the second static partition is loaded during the startup process.
  • OUC triggers the electronic device to restart.
  • OUC when OUC triggers the electronic device to restart, it will exit the current first operating system, cut off the power of the electronic device, and then turn on the power of the electronic device.
  • the electronic device sequentially loads the data of the basic partition, the data of the second static partition, the data of the dynamic partition, the data in the cow file in the user data partition, and starts from the second static partition to run the second operating system.
  • the electronic device first loads the data of the basic partition (Common).
  • the electronic device reads the startup tag in the basic partition (Common); when the startup tag in the basic partition (Common) When marked (A), the device will load the first static partition after loading the basic partition (Common), thereby booting from the first static partition; when the boot mark in the basic partition (Common) is (B), the electronic device will After loading the basic partition (Common), the second static partition will be loaded to boot from the second static partition.
  • the electronic device reads the boot flag in the base partition (Common).
  • the boot mark in the basic partition (Common) is (B).
  • the electronic device loads the second static partition after loading the basic partition (Common) and starts from the second static partition.
  • the electronic device when the electronic device loads the data of the second static partition and loads the data in the cow file of the dynamic partition (Super) and the user data partition (Userdata), specifically: the electronic device reads the metadata (/metadata ), based on the disk placement status information, determine whether the cow file needs to be retrieved from the specified path of the user data partition (Userdata), and use snapshot merging to load the dynamic partition (Super) and cow file.
  • the electronic device when the electronic device loads the data of the second static partition and loads the data in the cow file of the dynamic partition (Super) and the user data partition (Userdata), specifically: the electronic device reads the metadata (/metadata ), based on the disk placement status information, determine whether the cow file needs to be retrieved from the specified path of the user data partition (Userdata), and use snapshot merging to load the dynamic partition (Super) and cow file.
  • step S515 the electronic device does not load all the cow files in the dynamic partition (Super) and the user data partition (Userdata), but loads the corresponding files according to the second operating system operation requirements. Specifically, in step S515, the electronic device determines the file that needs to be loaded according to the operating requirements of the second operating system, and extracts the corresponding file from the cow file of the dynamic partition (Super) or the user data partition based on the snapshot for loading.
  • step S515 when the corresponding cow file first exists in the sub-partition of the dynamic partition (Super), a new version of the file map of each sub-partition of the dynamic partition (Super) is first generated based on the snapshot.
  • the process of generating a new version of the file map may refer to step S511.
  • the electronic device determines the files that need 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 dynamic partition (Super) sub-partition.
  • the second operating system needs to load all data in the directory user (/system/user) under the System subpartition.
  • the electronic device reads the disk placement status information in the metadata (/metadata).
  • the subpartition identification of the System subpartition in the disk placement status information is "wait for Merge". Therefore, the electronic device is in the user data partition ( Search for the cow file under Userdata)/Update.
  • After searching for the cow file system_b-cow-img.img.0000 under Update based on the snapshot, generate System based on the file map of the cow file in system_b-cow-img.img.0000.
  • a new version of the file map for the subpartition Load data 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, according to the new version of the file map of the System subpartition:
  • step S515 the dynamic partition (Super)+cow file is not verified as a whole, but only the files that need to be loaded are 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, rolled back to the first operating system, or tries to load the file again.
  • dmverity a target of dm (device mapper)
  • the Merge operation specifically refers to writing the dynamic partition (Super) upgrade file (cow file) saved in the user data partition (Userdata) to the dynamic partition (Super) during the operating system upgrade process. , so that the files of the dynamic partition (Super) can complete the data upgrade, so that the electronic device does not need to load the cow files of the dynamic partition (Super) and the user data partition the next time it starts, and only needs to load the dynamic partition (Super) to complete the electronic device. start up.
  • the electronic device performs a power-on broadcast after successful startup, and starts the upgrade process after the power-on broadcast.
  • the upgrade process reads the disk placement status information in the metadata (/metadata) of the basic partition (Common). If the disk placement status information is "Merged", the electronic device enters the normal operating mode.
  • the upgrade process will download the cow file in the user data partition (Userdata) to the dynamic partition (Super).
  • the upgrade process writes the upgrade data in 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 one after the upgrade. version data.
  • the upgrade process deletes the cow file in the user data partition (Userdata) and returns the storage space to the user data partition (Userdata); and also restores the disk status information in the metadata (/metadata) of the basic partition (Common). Changed from "wait for Merge" to "Merged".
  • step S508 the data operation of the static partition upgrade is for the operating system data in the second static partition, which will not affect the operating system data of the currently started first static partition; and, in step S511, the dynamic The data operation of partition upgrade is completed on the virtual dynamic partition created in the user data partition (Userdata), which will not affect the currently mounted dynamic partition (Super). Therefore, during the entire operating system upgrade process, the user can use the electronic device normally; and, after step S513 is completed, the electronic device does not need to be restarted immediately, and the user can choose the restart timing; in this way, the operating system upgrade process does not It will not affect the user's normal mobile phone operation, thus greatly improving the user experience. Furthermore, for dynamic partitions (Super), virtual dynamic partitions are created on the user data partition (Userdata) only when an upgrade is required, thus effectively improving data storage space utilization.
  • Kernel l synchronizes the data of the second static partition to the first static partition.
  • the electronic device starts running the operating system version 1.1 from the first static partition; when the operating system is upgraded to 1.2, the electronic device restarts and starts from the second static partition An operating system running version 1.2; at this time, the electronic device runs an operating system version 1.2.
  • the first static partition corresponds to the operating system version 1.1
  • the second static partition corresponds to the operating system version 1.2.
  • Data in the first static partition and the second static partition are inconsistent. Assuming that an error occurs in the second static partition, the first static partition cannot replace the function of the second static partition, that is, the first static partition cannot support the electronic device running the operating system version 1.2. However, if data consistency between the first static partition and the second static partition is always maintained, then when an error occurs in the first static partition or the second static partition, another static partition can be used.
  • the operating system upgrade method provided by the above embodiments implemented by an electronic device can also be executed by a chip system included in the electronic device, where the chip system can include The processing circuit, the receiving pin and the transmitting pin communicate with each other through the internal connection path.
  • the processing circuit is coupled with the memory, so that when the chip system is running, it calls the computer program stored in the memory to implement the steps executed by the electronic device.
  • processing circuit in the chip system may be an application processor or a non-application processor.
  • embodiments of the present application also provide a computer-readable storage medium.
  • the computer storage medium stores computer instructions.
  • the electronic device causes the electronic device to execute the above-mentioned related method steps to implement the above-mentioned embodiments. How to upgrade the operating system.
  • embodiments of the present application also provide a computer program product.
  • the computer program product When the computer program product is run on an electronic device, it causes the electronic device to perform the above related steps to implement the operating system upgrade method in the above embodiment.

Landscapes

  • Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
  • Stored Programmes (AREA)

Abstract

本申请提供了一种操作系统的升级方法、电子设备及存储介质。该方法对动态分区中子分区对应的升级文件的安装方式取决于用户数据分区当前的剩余空间和升级文件的大小（压缩大小，非压缩大小），从而能够在操作系统的升级过程中，根据具体情况决定是否使用cow压缩功能，进而满足不同用户需求。

Description

操作系统的升级方法、电子设备及存储介质
本申请要求于2022年03月11日提交中国专利局、申请号为202210243332.7、发明名称为“操作系统的升级方法、电子设备及存储介质”的中国专利申请的优先权，其全部内容通过引用结合在本申请中。
技术领域
本申请涉及计算机技术领域，尤其涉及一种操作系统的升级方法、电子设备及存储介质。
背景技术
随着电子设备可安装的应用程序越来越多，用户数据对存储空间的占用需求越来越大。目前，为了既保证操作系统升级的成功性，又能够尽可能降低系统数据对存储空间的占用，以留出更多的存储空间存储用户数据，采用虚拟AB系统(Virtual AB)分区结构的电子设备变的越来越普及。
对于采用虚拟AB系统分区结构的电子设备，由于动态分区(Surper分区)是以单分区的形式存在的，因此在操作系统升级过程中，需要将动态分区对应的升级文件先写入用户数据分区(Userdata分区)，待电子设备重启时再从用户数据分区读取升级文件落盘到动态分区对应的子分区中，这就导致操作系统升级过程中会占用用户数据分区较多的空间，甚至会因为用户数据分区空间不足导致升级失败。
发明内容
为了解决上述技术问题，本申请提出了一种操作系统的升级方法、电子设备及存储介质，通过根据用户数据分区空间的剩余大小选择对动态分区的升级方式，在不影响用户使用的情况下，保证电子设备能够正常完成操作系统的升级。
第一方面，本申请提供了一种操作系统的升级方法，应用于电子设备，电子设备包括处理器以及存储器，存储器包括基础分区、第一静态分区、第二静态分区、动态分区以及用户数据分区，电子设备启动后依次加载基础分区的数据、第一静态分区的数据以及动态分区的数据以运行第一操作系统，第一操作系统运行之后，方法还包括：获取升级包对应的文件列表描述信息，文件列表描述信息指示了升级包的第一大小、升级包中第一升级文件压缩后的第二大小、第一升级文件未压缩的第三大小，第一升级文件对应于动态分区中的第一子分区；在用户数据分区的第一剩余空间大于第一大小和第三大小之和的情况下，在用户数据分区中创建第一子分区对应的第一写时拷贝cow文件，第一剩余空间为下载升级包前用户数据分区的剩余空间；在用户数据分区的第一剩余空间大于第一大小和第二大小之和，小于第一大小和第三大小之和的情况下，在用户数据分区中创建第一子分区对应的第二cow文件，第一cow文件的大小大于第二cow文件。由此，根据用户数据分区剩余空间的大小和升级包的第一大小，第一升级文件的第二大小和第三大小来确定本次操作系统时间中动态分区的子分区在用户数据分区中占用的虚拟逻辑分区，即cow文件的大 小，进而根据cow文件的大小决定是否选择cow文件压缩功能，从而能够根据用户数据分区的剩余空间合理选择升级方式，进而满足不同用户需求。
根据第一方面，第一cow文件的大小等于第一剩余空间减去第二剩余空间和第一大小的值，第二剩余空间为下载升级包并创建第一cow文件后，用户数据分区的剩余空间；第二cow文件的大小等于第一剩余空间减去第三剩余空间和第一大小的值，第三剩余空间为下载升级包并创建第二cow文件后，用户数据分区的剩余空间。
根据第一方面，或者以上第一方面的任意一种实现方式，在用户数据分区的第一剩余空间大于第一大小和第三大小之和的情况下，在用户数据分区中创建第一子分区对应的第一写时拷贝cow文件，包括：在用户数据分区的第一剩余空间大于第一大小和第三大小之和的情况下，设置压缩属性对应的标识为第一标识，第一标识指示第一升级文件不使用cow压缩功能安装；根据第一标识，在用户数据分区中以非压缩形式创建第一子分区对应的第一cow文件。。
根据第一方面，或者以上第一方面的任意一种实现方式，在根据第一标识，在用户数据分区中以非压缩形式创建第一子分区对应的第一cow文件之前，方法还包括：获取升级包；在获取到升级包之后，执行根据第一标识，在用户数据分区中以非压缩形式创建第一子分区对应的第一cow文件的步骤。
根据第一方面，或者以上第一方面的任意一种实现方式，在获取到升级包之后，执行根据第一标识，在用户数据分区中以非压缩形式创建第一子分区对应的第一cow文件的之前，方法还包括：在用户数据分区的第四剩余空间大于第三大小的情况下，设置压缩属性对应的标识为第一标识，第四剩余空间为下载完升级包后用户数据分区的剩余空间；在用户数据分区的第四剩余空间大于第二大小，小于第三大小的情况下，设置压缩属性对应的标识为第二标识，第二标识指示第一升级文件使用cow压缩功能安装。
根据第一方面，或者以上第一方面的任意一种实现方式，在根据第一标识，在用户数据分区中以非压缩形式创建第一子分区对应的第一cow文件的之后，方法还包括：以非压缩形式将第一升级文件中的数据写入用户数据分区中以非压缩形式创建第一子分区对应的第一cow文件。
根据第一方面，或者以上第一方面的任意一种实现方式，在用户数据分区的第一剩余空间大于第一大小和第二大小之和，小于第一大小和第三大小之和的情况下，在用户数据分区中创建第一子分区对应的第二cow文件，第一cow文件的大小大于第二cow文件，包括：在用户数据分区的第一剩余空间大于第一大小和第二大小之和，小于第一大小和第三大小之和的情况下，设置压缩属性对应的标识为第二标识，第二标识指示第一升级文件使用cow压缩功能安装；根据第二标识，在用户数据分区中以压缩形式创建第一子分区对应的第二cow文件。
根据第一方面，或者以上第一方面的任意一种实现方式，在根据第二标识，在用户数据分区中以压缩形式创建第一子分区对应的第二cow文件之前，方法还包括：获取升级包；在获取到升级包之后，执行根据第二标识，在用户数据分区中以压缩形式创建第一子分区对应的第二cow文件的步骤。
根据第一方面，或者以上第一方面的任意一种实现方式，在获取到升级包之后，执行根据第二标识，在用户数据分区中以压缩形式创建第一子分区对应的第二cow文件之前， 方法还包括：在用户数据分区的第四剩余空间大于第三大小的情况下，设置压缩属性对应的标识为第一标识，第一标识指示第一升级文件不使用cow压缩功能安装，第四剩余空间为下载完升级包后用户数据分区的剩余空间；在用户数据分区的第四剩余空间大于第二大小，小于第三大小的情况下，设置压缩属性对应的标识为第二标识。
根据第一方面，或者以上第一方面的任意一种实现方式，在根据第二标识，在用户数据分区中以压缩形式创建第一子分区对应的第二cow文件的之后，方法还包括：以压缩形式将第一升级文件中的数据写入用户数据分区中以压缩形式创建第一子分区对应的第二cow文件。
根据第一方面，或者以上第一方面的任意一种实现方式，以压缩形式将第一升级文件中的数据写入用户数据分区中以压缩形式创建第一子分区对应的第二cow文件，包括：将第一升级文件中的数据中的0去掉；将去掉0的数据写入用户数据分区中以压缩形式创建第一子分区对应的第二cow文件。
根据第一方面，或者以上第一方面的任意一种实现方式，在用户数据分区的第一剩余空间大于第一大小和第三大小之和的情况下，在对操作系统升级的过程中，电子设备对用户数据分区不执行除操作系统升级之外的读写操作；或者，在用户数据分区的第一剩余空间大于第一大小和第二大小之和，小于第一大小和第三大小之和的情况下，在对操作系统升级的过程中，电子设备对用户数据分区不执行除操作系统升级之外的读写操作。
根据第一方面，或者以上第一方面的任意一种实现方式，在第一剩余空间小于第一大小和第二大小之和的情况下，提示清理用户数据分区。
根据第一方面，或者以上第一方面的任意一种实现方式，提示清理用户数据分区，包括：确定第一大小和第二大小之和与第一剩余空间的第一差值；提示对用户数据分区清理至少第一差值的空间。
根据第一方面，或者以上第一方面的任意一种实现方式，在第四剩余空间小于第二大小的情况下，提示清理用户数据分区。
根据第一方面，或者以上第一方面的任意一种实现方式，提示清理用户数据分区，包括：确定第二大小与第四剩余空间的第二差值；提示对用户数据分区清理至少第二差值的空间。
第二方面，本申请提供了一种电子设备。该电子设备包括处理器以及存储器，存储器包括基础分区、第一静态分区、第二静态分区、动态分区以及用户数据分区，电子设备启动后依次加载基础分区的数据、第一静态分区的数据以及动态分区的数据以运行第一操作系统；其中，存储器和处理器耦合，存储器存储有程序指令；当程序指令由处理器执行时，使得电子设备执行第一方面，或者以上第一方面的任意一种实现方式中的方法的指令。
第三方面，本申请提供了一种计算机可读存储介质，用于存储计算机程序，当计算机程序在电子设备上运行时，使得电子设备执行第一方面，或者以上第一方面的任意一种实现方式中的方法的指令。
第四方面，本申请提供了一种计算机程序产品，该计算机程序产品包括计算机程序，当其在电子设备上运行时，使得电子设备执行第一方面，或者以上第一方面的任意一种实现方式中的方法的指令。
第五方面，本申请提供了一种芯片，该芯片包括处理电路、接收管脚和发送管脚。其中，接收管脚、发送管脚和处理电路通过内部连接通路互相通信，该处理电路执行第一方面，或者以上第一方面的任意一种实现方式中的方法的指令，以控制接收管脚接收信号，控制发送管脚发送信号。
附图说明
图1是示例性示出的一种电子设备的硬件结构示意图；
图2是示例性示出的内部存储器的类型划分示意图；
图3是示例性示出的非AB系统、AB系统和虚拟AB系统的分区结构示意图；
图4是示例性示出的操作系统升级过程中拍包服务器、OTA服务器和电子设备之间的交互示意图；
图5.1是示例性示出的操作系统升级过程中将升级包中的数据写入静态分区的示意图；
图5.2是示例性示出的操作系统升级过程中将升级包中的数据写入动态分区的示意图；
图5.3是示例性示出的升级包中包括的文件的示意图；
图6.1是示例性示出的用户数据分区剩余的空间大于升级包和未压缩的动态分区对应的升级文件之和时在用户数据分区创建cow文件的示意图；
图6.2是示例性示出的用户数据分区剩余的空间小于升级包和未压缩的动态分区对应的升级文件之和，大于升级包和压缩的动态分区对应的升级文件之和时在用户数据分区创建cow文件的示意图；
图7.1是示例性示出的操作系统升级过程中电子设备从OTA服务器下载升级包前和下载升级包后，对静态分区升级中的示意图；
图7.2是示例性示出的操作系统升级过程中电子设备对静态分区升级后，对动态分区升级前的示意图；
图7.3是示例性示出的操作系统升级过程中电子设备将第一升级文件写入System_COW和对dtbo_b子分区校验的示意图；
图7.4是示例性示出的操作系统升级过程中电子设备对System_COW校验和重启电子设备后的示意图；
图7.5是示例性示出的操作系统升级过程中电子设备执行Merge操作和分区同步的示意图；
图7.6是示例性示出的操作系统升级过程中电子设备在完成分区同步后向OTA服务器上报升级结果的示意图；
图8.1是示例性示出的操作系统升级过程中拍包服务器和OTA服务器之间的时序图；
图8.2是示例性示出的操作系统升级过程中电子设备从OTA服务器获取升级包的时序图；
图8.3是示例性示出的操作系统升级过程中将升级文件写入静态分区和动态分区的时序图；
图8.4是示例性示出的操作系统升级过程中将升级文件写入静态分区和动态分区后执行操作的时序图；
图9是示例性示出的操作系统升级过程中根据第一次空间判断结果设置压缩属性的流程示意图；
图10是示例性示出的操作系统升级过程中根据第二次空间判断结果设置压缩属性的流程示意图；
图11是示例性示出的操作系统升级过程中根据不同的压缩属性选择不同的安装方式安装动态分区对应的升级文件的流程示意图；
图12是示例性示出的电子设备从启动到进行操作系统升级到重启完成操作系统升级的流程示意图。
具体实施方式
下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。
本文中术语“和/或”，仅仅是一种描述关联对象的关联关系，表示可以存在三种关系，例如，A和/或B，可以表示：单独存在A，同时存在A和B，单独存在B这三种情况。
本申请实施例的说明书和权利要求书中的术语“第一”和“第二”等是用于区别不同的对象，而不是用于描述对象的特定顺序。例如，第一目标对象和第二目标对象等是用于区别不同的目标对象，而不是用于描述目标对象的特定顺序。
在本申请实施例中，“示例性的”或者“例如”等词用于表示作例子、例证或说明。本申请实施例中被描述为“示例性的”或者“例如”的任何实施例或设计方案不应被解释为比其它实施例或设计方案更优选或更具优势。确切而言，使用“示例性的”或者“例如”等词旨在以具体方式呈现相关概念。
在本申请实施例的描述中，除非另有说明，“多个”的含义是指两个或两个以上。例如，多个处理单元是指两个或两个以上的处理单元；多个系统是指两个或两个以上的系统。
为了更好的理解本申请实施例提供的技术方案，在对本申请实施例的技术方案说明之前，首先结合附图对本申请实施例的适用于的电子设备(例如手机、平板、PC机等)的硬件结构进行说明。
参见图1，电子设备100可以包括：处理器110，外部存储器接口120，内部存储器121，通用串行总线(universal serial bus，USB)接口130，充电管理模块140，电源管理模块141，电池142，天线1，天线2，移动通信模块150，无线通信模块160， 音频模块170，传感器模块180，按键190，马达191，指示器192，摄像头193，显示屏194，以及用户标识模块(subscriber identification module，SIM)卡接口195等。
示例性的，音频模块170可以包括扬声器170A、受话器170B、麦克风170C、耳机接口170D等。
示例性的，传感器模块180可以包括压力传感器、陀螺仪传感器、气压传感器、磁传感器、加速度传感器、距离传感器、接近光传感器、指纹传感器、温度传感器、触摸传感器、环境光传感器、骨传导传感器等。
示例性的，按键190包括电源键(开机键)，音量键等。按键190可以是机械按键。也可以是触摸式按键。电子设备100可以接收按键输入，产生与电子设备100的用户设置以及功能控制有关的键信号输入。
此外，处理器110可以包括一个或多个处理单元，例如：处理器110可以包括应用处理器(application processor，AP)，调制解调处理器，图形处理器(graphics processing unit，GPU)，图像信号处理器(image signal processor，ISP)，控制器，存储器，视频编解码器，数字信号处理器(digital signal processor，DSP)，基带处理器，和/或神经网络处理器(neural-network processing unit，NPU)等。
可理解的，在具体实现中，不同的处理单元可以是独立的器件，也可以集成在一个或多个处理器中。
此外，在一些实现方式中，控制器可以是电子设备100的神经中枢和指挥中心。控制器可以根据指令操作码和时序信号，产生操作控制信号，完成取指令和执行指令的控制。
此外，处理器110中的存储器主要用于存储指令和数据。在一些实现方式中，处理器110中的存储器为高速缓冲存储器。
此外，可理解的，在实际的应用场景中，触发电子设备100实现各种功能应用以及数据处理的可执行程序代码是存储在内部存储器121中的，这些可执行程序代码包括指令。
示例性的，具体到本申请实施例提供的技术方案中，电子设备100的启动、操作系统的升级主要依赖于预先存储到内部存储器121中的相关指令，处理器110通过执行内部存储器121中存储的指令，从而能够使得电子设备100执行本申请实施例提供的操作系统的升级方法。
示例性的，参见图2，在具体实现中，内部存储器121可以包括只读存储器121A和随机存取存储器121B，而只读存储器121A又可以划分为非AB系统(图3中的(1)所示)、AB系统(图3中的(2)所示)和虚拟AB系统(图3中的(3)所示)这三种不同的分区结构。
可理解的，具体到实际应用中，随机存取存储器(Random Access Memory，RAM)，又称作“主存”，它可随时读写，而且速度很快，通常作为操作系统或其他正在运行中的程序的临时数据存储媒介，当电源关闭时，RAM不能保留数据，即随机存取存储器121B中通常存储的是电子设备运行时的临时数据；而只读存储器(Read-Only Memory，ROM)，又可以称作“非易失性存储器”，所存数据一般是装入整机前事先写好的，例如操作系统的镜像文件，以及用户使用电子设备时产生的用户数据，整 机工作过程中只能读出，而不能像RAM那样能够快速地、方便地加以改写，因此ROM所存数据稳定，断电后所存数据也不会改变。综上所述，RAM和ROM相比，两者最大的区别是RAM在断电以后保存在上面的数据会自动消失，而ROM不会自动消失，可以长时间断电保存。
此外，需要说明的是，目前操作系统的升级过程中，在将从空中下载(Over-the-Air，OTA)服务器下载到电子设备中用户数据分区(位于只读存储器121A)的升级包中的升级文件解压到对应的静态分区和动态分区时，均会借助随机存取存储器121B的内核缓存，以实现升级文件的快速读写。
此外，具体到实际应用中，只读存储器121A例如可以是磁盘存储器件、闪存器件、通用闪存存储器(universal flash storage，UFS)等；随机存取存储器121B例如可以是高速随机存取存储器。
此外，需要说明的是，在具体实现中，只读存储器121A可以包括存储程序区和存储数据区。其中，存储程序区可存储操作系统，至少一个功能所需的应用程序(比如声音播放功能，图像播放功能等)等。存储数据区可存储电子设备100使用过程中所创建的数据(比如音频数据，电话本等)等。
示例性的，关于存储程序区，具体到本申请实施例提供的技术方案中，例如可以是基础分区(Common)、静态分区(Static partition)和动态分区(Super)；关于存储数据区，具体到本申请实施例提供的技术方案中，例如可以是用户数据分区(Userdata)。
继续参见图2，电子设备100的内部存储器121的分区结构例如可以是非AB系统、AB系统和虚拟AB系统。具体的说，基于上述四种分区(基础分区、静态分区、动态分区和用户数据分区)的特性，对于操作系统升级中不需要升级的分区，例如基础分区和用户数据分区，不论是在非AB系统、AB系统，还是虚拟AB系统下，均采用的是单分区，而需要升级的分区则会有所不同。
示例性的，由于在非AB系统下进行操作系统升级，升级过程中电子设备的其他功能不能使用，电子设备只能停留在非AB系统的升级界面，待操作系统升级完成重启电子设备后才可以进入用户界面正常使用。故而，在非AB系统下，静态分区和动态分区也采用的是单分区，详见图3中的(1)所示，这样就可以降低对存储器空间的占用，以预留更多的空间给用户数据分区。
示例性的，AB系统是为了让电子设备在进行操作系统升级过程中，用户可以任意返回电子设备的主界面，从而不影响电子设备的使用。故而，在AB系统下，静态分区和动态分区采用的是双分区，详见图3中的(2)所示，静态分区例如可以被划分为第一静态分区和第二静态分区)，动态分区例如可以划分为第一动态分区(SuperA)和第二动态分区(SuperB)。虽然这种分区划分方式可以让电子设备在进行操作系统升级过程中，任意返回电子设备的主界面，但是会占用存储器较大的空间，使得用户数据分区可用的空间大大减小。
示例性的，虚拟AB系统结合了非AB系统和AB系统的优点，将存储的文件较小，即占用存储空间较小的静态分区划分为第一静态分区和第二静态分区，将存储的文件较大，即占用存储空间较大的动态分区采用单分区，详见图3中的(3)所示。
以只读存储器121A的分区结构为虚拟AB系统分区结构为例，具体到实际应用中，对于电子设备中只读存储器121A的分区部署信息可以通过表1所示的分区表进行描述。
表1分区表
Figure PCTCN2022139052-appb-000001
这样，通过分区表定义每个分区的起始地址和大小，从而针对不同的硬件可以根据需要调整相应的分区大小。
此外，需要说明的是，除了特殊预留的分区，基本上每个分区都有其对应的镜像(image)文件，镜像文件是通过软件代码编译而成，其内集成了电子设备启动或运行过程相关的各种功能文件和配置。没有镜像文件，电子设备就没法运行。一个完整的系统版本包括很多镜像，分区表镜像gpt.img、启动相关镜像(xloader.img、boot.img)、系统镜像super.img(集成了android系统核心)和用户数据镜像userdata.img(用来储存用户数据)等。
应当理解的是，上述说明仅是为了更好的理解本实施例的技术方案而列举的示例，不作为对本实施例的唯一限制。
也就是说，在实际应用中，分区表中记录的分区可以根据实际的业务需求来进行划分设置。
另外，关于AB系统分区结构和虚拟AB系统分区结构中以双分区的形式存在的分区在存储器中的分布情况并不局限于图3中的(2)和图3中的(3)示出的样式， 在实际应用中各个分区的位置是根据分配的起始地址和结束地址确定的。
关于电子设备100的硬件结构就介绍到此，应当理解的是，图1所示电子设备100仅是一个范例，在具体实现中，电子设备100可以具有比图中所示的更多的或者更少的部件，可以组合两个或多个的部件，或者可以具有不同的部件配置。图1中所示出的各种部件可以在包括一个或多个信号处理和/或专用集成电路在内的硬件、软件、或硬件和软件的组合中实现。
此外，需要说明的，在实际的应用场景中，随着空中下载技术(Over-the-Air Technology，OTA)的发展，通过电子设备的无线网络接口实现对电子设备进行远程版本升级的的OTA升级越来越普及。结合实际的业务场景，为了便于说明本申请实施例所描述的操作系统的升级方案，以下结合图4，以OTA升级场景为例，对本申请实施例提供的操作系统的升级方案中拍包服务器、OTA服务器和电子设备之间的交互进行说明。
示例性的，参见图4，用于升级电子设备(如图4中的PC设备、平板设备、手机等)的操作系统的升级包由拍包服务器根据版本镜像制作而成，并由拍包服务器将制作的升级包上传至OTA服务器，由OTA服务器统一管理主动推送给接入的电子设备，或者根据接入的电子设备的请求发送给对应的电子设备。
示例性的，关于拍包服务器根据版本镜像制作的升级包中，例如可以包括启动相关镜像(例如xloader.img、boot.img)、系统镜像(例如super.img)等，此处不再一一例举，本实施例对此不做限制。
此外，在本实施例提供的技术方案中，为了保证在用户数据分区剩余空间充足和不足的情况下，都可以实现操作系统的升级，拍包服务器在制作升级包时，还会制作描述升级包的文件列表描述信息(后续称为filelist.xml)，并再向OTA服务器上传升级包的时候，将描述该升级包的filelist.xml一同上传OTA服务器进行管理。
需要说明的是，在本实施例提供的技术方案中，拍包服务器制作的filelist.xml中至少包括了指示升级包的第一大小(后续称为fileSize)、指示用于升级动态分区的升级文件压缩后的第二大小(后续称为compressCowsize)，以及指示用于升级动态分区的升级文件未压缩的第三大小(后续称为uncompressCowsize)。
继续参见图4，电子设备在从OTA服务器获取到升级包进行操作系统升级后，会将本次的升级结果上报给OTA服务器，以便OTA服务器获知电子设备本次的操作系统升级是否成功。
此外，需要说明的是，在实际应用中，对于升级失败的情况，电子设备上报给OTA服务器的升级结果中还可以包括升级失败的日志信息，以便快速定位操作系统升级失败的原因。
关于电子设备从OTA服务器下载完成升级包，根据升级包对操作系统升级的过程，即将升级包中的数据写入静态分区对应的子分区，动态分区对应的子分区的过程，以下结合图5.1至图5.3进行说明。
示例性的，参见图5.1和图5.2，电子设备从OTA服务器下载到的升级包具体是存放在用户数据分区的，在将升级包中的数据写入静态分区对应的子分区，动态分区对应的子分区的过程中，随机存取存储器RAM会将用户数据分区中存放的升级包中 的数据读取到RAM中，即执行图5.1中的步骤(1)，然后RAM再将用于升级静态分区的数据写入静态分区中对应的子分区，即执行图5.1中的步骤(2)，将用于升级动态分区的数据写入动态分区中对应的子分区，即执行图5.2中的步骤(3)。
示例性的，图5.1中以电子设备当前以第一静态分区为启动顺序为例，在需要升级的静态分区中的子分区是dtbo子分区时，RAM会将用于升级dtbo子分区的数据写入当前处于备份分区的第二静态分区中的dtbo_b子分区。
示例性的，图5.2以需要升级的动态分区中的子分区为System子分区为例，则RAM会将升级包中System子分区对应的数据写入用户数据分区中System子分区对应的cow文件，即图5.2用户数据分区中的System_COW。
关于升级包中通常包括的文件，以下结合图5.3进行说明。
示例性的，在实际应用中，升级包中通常会包括存放密钥验签数据的密钥验签文件、升级包的版本描述文件、payload.bin(是Android OTA镜像打包文件，例如包括system.img、boot.img和recovery.img等镜像文件)，以及用于描述payload.bin的属性文件。
进一步地，对于payload.bin又可以分为Metadata和Data两部分。其中，Metadata是对Data的描述，用于指示不同分区的升级数据在Data中的具体位置。即，Metadata用于承担目录索引的左右，同时也承担这签名验证的作用，而Data则承载着用于升级静态分区中子分区和动态分区中子分区的升级数据。
关于根据Metadata定位Data中各个分区的数据的实现方式可以参见现有的标准，此处不再赘述。
具体到本申请实施例提供的操作系统的升级方案中，为了使升级方式与电子设备相匹配，从而既兼顾用户体验，又能保证操作系统可以快速、正常的升级完成，电子设备在进行操作系统升级时会对用户数据分区的剩余空间进行判断，并根据判断结果设置压缩属性，即设置是否使用cow压缩功能。
需要说明的是，本实施例提供的技术方案，在进行剩余空间判断，并根据判断结果设置压缩属性时，具体是根据用户数据分区的剩余空间与上述filelist.xml中的fileSize、compressCowsize和uncompressCowsize进行判断，然后根据判断结果设置是否使用cow压缩功能。
示例性的，如果filelist.xml中记录的升级包的fileSize为506M，动态分区中System子分区对应的升级文件的compressCowsize为1.0G，动态分区中System子分区对应的升级文件的uncompressCowsize为8.7G。参见图6.1，在用户数据分区的剩余空间为10.0G的情况下，由于剩余空间(10.0G)>fileSize(506M)+uncompressCowsize(8.7G)，因此这种情况下设置的压缩属性为不使用cow压缩功能，即后续下载到升级包，在用户数据分区创建的对应System子分区的System_COW是以非压缩形式创建的，RAM在将升级包中对应于System子分区的数据写入非压缩System_COW时，不需要对数据进行压缩处理，直接写入即可。
示例性的，如果filelist.xml中记录的升级包的fileSize为506M，动态分区中System子分区对应的升级文件的compressCowsize为1.0G，动态分区中System子分区对应的升级文件的uncompressCowsize为8.7G。参见图6.2，在用户数据分区的剩余空间 为2.0G的情况下，由于fileSize(506M)+uncompressCowsize(8.7G)>剩余空间(2.0G)>fileSize(506M)+compressCowsize(1.0G)，因此这种情况下设置的压缩属性为使用cow压缩功能，即后续下载到升级包，在用户数据分区创建的对应System子分区的System_COW是以压缩形式创建的，RAM在将升级包中对应于System子分区的数据写入压缩System_COW时，需要对数据进行压缩处理。
需要说明的是，在实际应用中，关于设置的压缩属性为使用cow压缩功能的情况，在RAM将升级包中对应于System子分区的数据写入压缩System_COW时，可以根据业需求选择压缩算法对数据进行压缩处理，关于压缩算法的选择，本实施例不做限制。
示例性的，以电子设备进行操作系统升级前，依次加载的是基础分区的数据、第一静态分区的数据、动态分区的数据，以使电子设备运行到第一操作系统(操作系统升级前的版本SlotA(v1.0))，本次系统升级需要对静态分区中的dtbo子分区和动态分区中的System子分区进行升级为例，结合图7.1至图7.6对本申请实施例提供的操作系统的升级方案进行说明。
参见图7.1当需要对操作系统进行升级时，电子设备首先会执行图7.1中的步骤(1)，从OTA服务器获取升级包的第一大小、升级包中第一升级文件压缩后的第二大小，以及第一升级文件未压缩的第三大小，第一升级文件对应于动态分区中的System子分区。
接着，电子设备会执行图7.1中的步骤(2)，在用户数据分区的第一剩余空间大于第一大小和第三大小之和的情况下，将压缩属性设置为self.virtual_ab.compression.enabled＝false(即不使用cow压缩功能)，并下载升级包；在用户数据分区的第一剩余空间大于第一大小和第二大小之和，小于第一大小和第三大小之和的情况下，将压缩属性设置为self.virtual_ab.compression.enabled＝true(即使用cow压缩功能)，并下载升级包；在用户数据分区的第一剩余空间小于第一大小和第二大小之和的情况下，在UI界面弹框提醒用户清理用户数据空间。
示例性的，在一些实现方式中，可以设置self.virtual_ab.compression.enabled＝“true”表示使用写时拷贝(Copy-On-Write，COW)文件压缩功能，设置self.virtual_ab.compression.enabled＝“false”表示不使用cow压缩功能。
示例性的，在self.virtual_ab.compression.enabled＝“true”时，在将动态分区中子分区的升级文件写入用户数据分区时，需要先在用户数据分区以压缩形式创建对应的cow文件(后续简称为压缩cow文件)，然后以压缩文件的形式将动态分区中子分区对应的升级文件写入压缩cow文件，即动态分区中子分区对应的升级文件是以压缩形式的cow文件存放在用户数据分区的。
示例性的，在self.virtual_ab.compression.enabled＝“false”时，在将动态分区中子分区的升级文件写入用户数据分区时，需要先在用户数据分区以非压缩的形式创建对应的cow文件(后续简称为非压缩cow文件)，然后将动态分区中子分区对应的升级文件直接写入非压缩cow文件，即动态分区中子分区对应的升级文件是以非压缩形式的cow文件存放在用户数据分区的。
示例性的，在一些实现方式中，在弹框提醒用户电子设备当前的第一剩余空间不 足，需要清理用户数据空间时，还可以提醒用户需清理至少多大的空间，以保证重新触发操作系统升级时，升级包可以下载成功。
示例性的，在一些实现方式中，弹框提醒用户清理的用户数据空间，至少为第一大小和第二大小之和。
示例性的，在一些实现方式中，如果电子设备当前的第一剩余空间不足，在弹框提醒用户清理的用户数据空间后，电子设备可以在预设周期后自动检测当前的第一剩余空间是否大于第一大小和第三大小之和，或者大于第一大小和第二大小之和，小于第一大小和第三大小之和，然后根据检测结果决定是否从OTA服务器下载升级包，即重新执行图7.1中的步骤(2)。
示例性的，在另一些实现方式中，如果电子设备当前的第一剩余空间不足，在弹框提醒用户清理的用户数据空间后，何时重新执行图7.1中的步骤(2)可以是由用户主动触发，例如由用户主动点击升级操作系统的控件。
应当理解的是，上述说明仅是为了更好的理解本实施例的技术方案而列举的示例，不作为对本实施例的唯一限制。
为了便于说明本申请提供的操作系统的升级方案，图7.1中的步骤(2)以用户数据分区的第一剩余空间大于第一大小和第三大小之和的情况为例，即设置的压缩属性为不使用cow压缩功能。
此外，需要说明的是，电子设备从OTA服务器下载的升级包具体是存放在用户数据分区的，本实施例中在用户数据分区中未示出。
接着，电子设备在从OTA服务器下载完成升级包后，会执行图7.1中的步骤(3)，将升级包中对应于静态分区的dtbo子分区的第二升级文件的数据写入第二静态分区中dtbo_b子分区。
示例性的，在将第二升级文件的数据写入第二静态分区中dtbo_b子分区后，dtbo_b子分区的版本会从图7.1中示出的dtbo_b(1.0)变更为图7.2中示出的dtbo_b(2.0)。
可理解的，如果在实际应用中，升级包中不包括第二升级文件，即不需要对静态分区中的子分区进行升级，则无需执行图7.1中的步骤(3)。
接着参见图7.2，示例性的，电子设备在将第二升级文件中的数据写入第二静态分区的dtbo_b子分区，即对静态分区升级后，为了避免升级包下载过程中，有其他文件占用了电子设备的剩余空间，导致对动态分区升级所需的空间不足，进而无法完成升级，电子设备还会再执行一次空间判断操作，即图7.2中的步骤(4)，在用户数据分区的第四剩余空间(下载升级包后的剩余空间)大于第三大小的情况下，将压缩属性设置为self.virtual_ab.compression.enabled＝false；在用户数据分区的第四剩余空间大于第二大小，小于第三大小的情况下，将压缩属性设置为self.virtual_ab.compression.enabled＝true，将压缩属性设置为self.virtual_ab.compression.enabled＝false；在用户数据分区的第四剩余空间小于第二大小的情况下，在UI界面弹框提醒用户清理用户数据空间。
示例性的，在一些实现方式中，弹框提醒用户清理的用户数据空间，至少为第二大小。
示例性的，在一些实现方式中，如果电子设备当前的第四剩余空间不足，在弹框 提醒用户清理的用户数据空间后，电子设备可以在预设周期后自动检测当前的第四剩余空间是否大于第三大小，或者大于第二大小，小于第三大小，然后根据检测结果决定是否接续升级，即执行图7.2中的步骤(5)，或者在监听到用户的触发操作，例如用户主动点击升级操作系统的控件后再进行接续升级。
示例性的，在另一些实现方式中，电子设备在确定用户清理后的第二用户数据空间大于第三大小，或者小于第三大小，大于第二大小后，重新开始对操作系统的升级时，可以重新从OTA服务器下载升级包，然后依次对静态分区的子分区和动态分区的子分区进行升级，避免升级操作中断后可能导致已经写入的数据因此用户清理用户数据分区导致丢失或异常。
应当理解的是，上述说明仅是为了更好的理解本实施例的技术方案而列举的示例，不作为对本实施例的唯一限制。
为了便于说明本申请提供的操作系统的升级方案，图7.2中的步骤(4)以用户数据分区的第四剩余空间大于第二大小，小于第三大小的情况为例，即第二次空间判断后重新设置的压缩属性为使用cow压缩功能。
可理解的，对于上述步骤(4)中对用户数据分区的二次空间判断操作可以根据业务需求选择是否需要执行，本申请对此不做限制。
此外，需要说明的是，在实际应用中，上述步骤(4)的操作可以是在步骤(3)之前进行，即步骤(3)和步骤(4)可以不区分先后顺序，此处以步骤(4)在步骤(3)执行之后再执行为例。
接着，在完成图7.2中的步骤(4)后，电子设备会执行图7.2中的步骤(5)，在用户数据分区中以压缩形式创建System子分区对应的cow文件(压缩System_COW)。
可理解的，此时创建的压缩System_COW是一个空的cow文件，即还没有数据写入。
接着参见图7.3，示例性的，在以压缩形式创建System子分区对应的压缩System_COW后，电子设备会执行图7.3中的步骤(6)，将第一升级文件中的数据以压缩的形式写入以压缩形式创建的压缩System_COW。
示例性的，在将第一升级文件的数据以压缩形式写入以压缩形式创建的压缩System_COW后，压缩System_COW的版本会从图7.2中示出的压缩System_COW变更为图7.3中示出的压缩System_COW(2.0)。
此外，需要说明的是，在完成将升级包中的升级文件写入对应的子分区的操作，即将第二升级文件写入dtbo_b子分区，将第一升级文件以压缩形式写入压缩System_COW后，需要对完成写入操作的子分区进行校验。
可理解的，根据现有协议标准需要先对静态分区进行校验，在静态分区校验成功后再对动态分区进行校验，如果静态分区校验失败，则直接结束后续操作，向OTA服务器上报升级失败的信息。因此，在对完成写入操作的子分区进行校验时，电子设备会先执行图7.3中的步骤(7)，对dtbo_b子分区进行校验，即对静态分区完成写入操作的子分区进行校验。为了便于说明本申请提供的操作系统的升级方案，以对dtbo_b子分区的校验成功为例。
接着参见图7.4，示例性的，电子设备会执行图7.4中的步骤(8)，在dtbo_b子分区校验成功后，对压缩System_COW中的内容进行校验。为了便于说明本申请提供的操作系统的升级方案，以对压缩System_COW校验成功为例。
相应地，在对压缩System_COW校验成功后，电子设备会执行图7.5中的步骤(9)，在压缩System_COW校验成功后，重启电子设备。
可理解的，在实际应用中，在将升级包中的升级文件写入对应的子分区的操作，并校验成功后，可以直接触发电子设备进入整机重启，也可以在延迟进入整机重启。
示例性的，关于延迟进入整机重启的条件，在一些实现方式中，可以是在电子设备处于闲时，即用户没有使用，也没有应用占用时，电子设备可以自动触发整机重启；在另一些实现方式中，可以是用户根据需要手动触发电子设备进入整机重启。
此外，需要说明的是，如果进行操作系统升级前，电子设备启动后依次加载的是基础分区的数据、第一静态分区的数据和动态分区的数据，运行的是第一操作系统(操作系统升级前的版本)，那么重启后，电子设备依次加载的是基础分区的数据、第二静态分区的数据、动态分区的数据和用户数据分区中压缩System_COW文件中的数据，以使电子设备运行到第二操作系统(操作系统升级后的版本SlotB(v2.0))。
接着，在电子设备重启运行到第二操作系统后，会执行图7.6中的步骤(10)Merge，将压缩System_COW文件中的内容落盘到System子分区。
示例性的，完成Merge操作后，System子分区会从图7.5左侧虚拟AB系统的分区结构示出的System(1.0)变更为图7.5右侧虚拟AB系统的分区结构示出的System(2.0)。
接着，在完成Merge操作后，电子设备还会执行图7.6中的步骤(11)，将dtbo_b子分区中的数据同步到dtbo_a子分区，即对静态分区进行分区同步操作，具体是将本次操作系统升级过程中进行升级的静态分区中的数据同步到未升级的静态分区中。
示例性的，在本次操作系统的升级是将第二静态分区中的dtbo_b子分区中的文件从1.0版本升级到2.0版本时，在完成Merge操作后，电子设备会将dtbo_b子分区中的文件拷贝到第一静态分区中dtbo_a子分区中，以实现这两个子分区的同步。
示例性的，在完成分区同步后，dtbo_a子分区会从图7.5中示出的dtbo_a(1.0)变更为图7.6中示出的dtbo_a(2.0)。
接着，在完成分区同步操作后，电子设备会执行图7.6中的步骤(12)，向OTA服务器上报升级结果。
可理解的，在实际应用中，上述步骤(3)至(11)任一步骤出现异常，导致本次操作系统的升级失败时，电子设备都会中断后续的升级操作，向OTA服务器上报升级结果。
示例性的，如果升级成功，则电子设备向OTA服务器上报的升级结果为指示本次操作系统升级成功的内容，反之则为指示本次操作系统升级失败的内容。
此外，应当理解的是，上述说明仅是为了更好的理解本实施例的技术方案而列举的示例，不作为对本实施例的唯一限制。
此外，需要说明的是，上述各分区对应的字母，在实际应用中可以不区分大小写，本申请对此不作限制。
为了更好的理解本申请提供的操作系统的升级方案，以下结合图8.1至图8.4从拍包服务器制作升级包到电子设备从OTA服务器获取拍包服务器制作的升级包，并进行操作系统的升级过程进行详细说明。
在结合图8.1至图8.4对本申请提供的操作系统的升级方案进行说明之前，首先对电子设备进行操作系统的升级过程中涉及的功能单元/模块/应用进行介绍。为了便于说明，本实施例以电子设备使用的操作系统为Android系统为例，示例性的，在一些实现方式中，升级包例如可以是由系统升级客户端(OTA Update Client，OUC)从OTA服务器获取的。
需要说明的是，本实施例中所说的OUC具体是安装于电子设备的应用程序层(Application)中，用于进行操作系统升级管理的应用。
此外，在从OTA服务器获取到升级包后，OUC会将获取到的升级包下发给电子设备中的升级引擎(update_engine)，由update_engine完成静态分区的升级，由update_engine和快照进程(snap进程)完成动态分区的升级。
接着，在由update_engine和snap进程完成对升级包中升级文件的安装(升级)后，OUC触发电子设备进入整机重启，在重启后电子设备运行到升级后的操作系统后，内核(kernel)执行Merge操作，将用户数据分区中cow文件中的数据落盘到动态分区中对应的子分区中，update_engine对静态分区进行分区同步。
此外，可理解的，在另一些实现方式中，操作系统的升级也可以通过应用程序层中安装的设置应用提供的入口完成，本实施例对此不作限制。
示例性的，参见图8.1至图8.4，本申请提供的操作系统的升级方案，包括：
S101，根据版本镜像制作升级包。
具体的说，在实际应用中，关于拍包服务器制作的升级包，可以根据业务需求制作为差分升级包和全量升级包。
示例性的，关于差分升级包的制作，对于比较小且与启动相关的镜像文件全量打包到升级包中，升级的时候采用全量覆盖的方式；而对于比较大的镜像文件，例如super.img，为了减小升级包的大小，则是通过特定的差分算法提取新、老版本super.img里每个逻辑分区镜像的差异，然后生成独立的补丁(patch)文件打包到升级包，在进行操作系统升级的时候再通过特定的差分算法将升级包里的patch文件合并到电子设备super分区里老版本的super.img，这样就可以生成新版本的super.img，即完成将老版本的super.img升级到新版本的super.img。
关于全量包的制作，具体是将新版本例的所有镜像文件都进行全量打包到升级包，即不存在单独的补丁文件。
具体到实际应用中，差分升级包和全量升级包的制作，参见现有标准即可，本实施例对此不作说明。
S102，计算升级包的大小fileSize、升级包中动态分区的升级文件压缩后的大小compressCowsize、动态分区的升级文件的未压缩(压缩前)的大小uncompressCowsize，将fileSize、compressCowsize和uncompressCowsize添加到升级包对应的filelist.xml。
也就是说，在本实施例中，拍包服务器在制作升级包时，会将升级动态分区中子分区的升级文件对应的compressCowsize和uncompressCowsize，以及升级包的大小 fileSize均添加到升级包对应的filelist.xml，这样电子设备便可以根据filelist.xml中记载的内容和用户数据分区当前的剩余空间确定采用哪种安装方式，将动态分区中子分区对应的升级文件安装到用户数据分区中。
可理解的，在实际应用中，filelist.xml中除了包括fileSize、compressCowsize和uncompressCowsize，还会包括操作系统升级过程中所需要的其他参数信息，例如“<support>”、“<payloadOffset>”、“<fileHash>”、“<metadataHash>”、“<metadataSize>”、“<powerWash>”、“<switchSlotOnReboot>”、“<runPostInstall>”等，此处不再一一列举，本实施例对此也不作限制。
需要说明的是，在实际应用中，filelist.xml中出现的上述字段通常是成对出现的，即还会“</support>”、“</payloadOffset>”、“</fileHash>”、“</metadataHash>”、“</metadataSize>”、“</powerWash>”、“</switchSlotOnReboot>”、“</runPostInstall>”。
其中，“<support>”和“</support>”之间的内容用于指示是否支持虚拟AB系统分区结构，其中“0”表示不支持，“1”表示支持；<payloadOffset>和“</payloadOffset>”之间的内容用于指示payload.bin的起始位置；“<fileHash>”和“</fileHash>”之间的内容用于校验payload.bin里面的文件主体；“<metadataHash>”和“</metadataHash>”之间的内容用于校验payload.bin里面的文件元数据；“<metadataSize>”和“</metadataSize>”之间的内容用于指示payload.bin里面的文件元数据的大小；“<powerWash>”和“</powerWash>”之间的内容用于指示升级后升级文件是否恢复出厂设置，其中“0”表示恢复，“1”表示不恢复；“<switchSlotOnReboot>”和“</switchSlotOnReboot>”之间的内容指示升级包安装后，电子设备重启前是否切换静态分区，其中“0”表示不切换，“1”表示切换；“<runPostInstall>”和“</runPostInstall>”之间的内容指示是否执行安装后的脚本程序(post-install)的步骤，其中“0”表示不执行，“1”表示执行。
示例性的，post-install的步骤，例如可以是metadata分区状态数据、切换静态分区等。
示例性的，为了便于理解，以下给出一种filelist.xml。
<VirtualAB>
<support>1</support>//表示支持虚拟AB系统分区结构
<uncompressCowsize>87602704384</uncompressCowsize>//表示动态分区的子分区对应的升级文件的非压缩大小为87602704384bytes
<cowsize>7602704384</cowsize>//表示动态分区的子分区对应的升级文件的压缩大小为7602704384bytes
<payloadOffset>887</payloadOffset>//表示偏移887bytes处为payload.bin的起始位置
<fileHash>xobTFJapFXT0LnLFfki6EEgDtGtIMpUmpZpD/9k1aRo＝</fileHash>//用于校验payload.bin里面的文件主体的哈希值
<fileSize>898039335</fileSize>//表示升级包的大小为89803933bytes
<metadataHash>6LcRfiwjdb7DmB/ZFAXSkB3DTEPoW4E4KBXFq+Df5Bo＝</metadataHash>//用于指示payload.bin里面的文件元数据的大小的哈希值
<metadataSize>820940</metadataSize>//表示元数据的大小为820940bytes
<powerWash>0</powerWash>//升级后升级文件恢复出厂设置
<switchSlotOnReboot>1</switchSlotOnReboot>//升级包安装后，电子设备重启前切换静态分区
<runPostInstall>1</runPostInstall>//执行安装后的脚本程序(post-install)的步骤
</VirtualAB>
应当理解的是，上述说明仅是为了更好的理解本实施例的技术方案而列举的示例，不作为对本实施例的唯一限制。
S103，上传升级包和filelist.xml。
示例性的，在一些实现方式中，filelist.xml是存储在升级包中的。
示例性的，在另一些实现方式中，filelist.xml是独立于升级包之外的，这样电子设备在进行空间判断时，无需获取升级包，先获取占用空间较小的filelist.xml即可。
应当理解的是，上述说明仅是为了更好的理解本实施例的技术方案而列举的示例，不作为对本实施例的唯一限制。
此外，需要说明的是，在一些实现方式中，升级包和filelist.xml可以是由拍包服务器在检测到有新版本的升级包和对应的filelist.xml时主动上传到OTA服务器的，也可以是按照预设周期，定时将新发布的升级包和对应的filelist.xml主动上传到OTA服务器。
示例性的，在另一些实现方式中，拍包服务器上传升级包和filelist.xml的条件可以是在接收到OTA服务器的请求后再将新发布的升级包和对应的filelist.xml上传到OTA服务器。
应当理解的是，上述说明仅是为了更好的理解本实施例的技术方案而列举的示例，不作为对本实施例的唯一限制。
S104，保存升级包和filelist.xml。
示例性的，在一些实现方式中，为了避免冗余版本对OTA服务器空间的占用，OTA服务器可以定期对保存的升级包和对应的filelist.xml进行遍历，进而清楚冗余版本。
示例性的，在另一些实现方式中，为了进一步减少对OTA服务器空间的占用，OTA服务器可以定期清理旧版本的升级版和对应的filelist.xml。
应当理解的是，上述说明仅是为了更好的理解本实施例的技术方案而列举的示例，不作为对本实施例的唯一限制。
S105，搜索OTA服务器中是否存在升级包。
可理解的，通常情况下，面对海量的用户群体，用于升级电子设备中安装的操作系统的升级包是由拍包服务器制作好后上传到OTA服务器进行管理的。而OTA服务器又会与接入的电子设备进行数据交互，即与电子设备之间建立了通信链路。故而，在一些实现方式中，电子设备可以主动向OTA服务器发起搜索请求，以确定OTA服务器中是否存在新版本的操作系统对应的升级包。
示例性的，在另一些实现方式中，OTA服务器也可以在检测到有新版本的操作系统对应的升级包时，主动推送通知信息，以告知电子设备当前有新版本的操作系统的 升级包。
为了便于说明，本实施例以电子设备主动向OTA服务器发起搜索请求，搜索OTA服务器中是否存在新版本的操作系统对应的升级包为例。
相应地，如果搜索到OTA服务器中存在新版本的操作系统对应的升级包，执行步骤S106，反之则按照设置的搜索周期定时向OTA服务器发起搜索请求，或者在用户触发时向OTA服务器发起搜索请求。
应当理解的是，上述说明仅是为了更好的理解本实施例的技术方案而列举的示例，不作为对本实施例的唯一限制。
S106，获取filelist.xml。
示例性的，在本实施例提供的操作系统的升级方案中，如果电子设备搜索到OTA服务器中存在新版本的操作系统对应的升级包，先向OTA服务器发起获取升级包对应的filelist.xml请求，而非直接发起获取升级包的请求。
此外，通过上述描述可知，在本实施例提供的操作系统的升级方案中，filelist.xml中记录了fileSize、compressCowsize和uncompressCowsize，因此电子设备在搜索到OTA服务器存在新版本的操作系统对应的升级包时，先获取升级包对应的filelist.xml，这样便可以根据filelist.xml中记录的fileSize、compressCowsize和uncompressCowsize，以及电子设备当前的剩余空间确定当前的剩余空间是否能够容纳升级包，以是否使用cow压缩功能对升级包中动态分区对应的升级文件进行安装。
S107，下发filelist.xml。
示例性的，OTA服务器在接收到电子设备发送的请求获取某一操作系统的升级包对应的filelist.xml请求后，便会从指定的存储地址取出filelist.xml，然后下发给对应的电子设备。
S108，根据本机的第一剩余空间、fileSize、compressCowsize、uncompressCowsize设置压缩属性。
示例性的，根据实际情况，步骤S108可以分为以下三种情况：(1)对于第一剩余空间大于fileSize+uncompressCowsize的情况，设置压缩属性为“false”；(2)对于第一剩余空间大于fileSize+compressCowsize，小于fileSize+uncompressCowsize的情况，设置压缩属性为“true”；(3)其他情况，例如小于fileSize+compressCowsize的情况，弹框提醒用户清理用户数据分区。
为了便于说明，本实施例中步骤S108以设置的压缩属性为“true”为例。
可理解的，由于操作系统升级过程中，升级包是需要先下载到电子设备的用户数据分区的，然后在对升级包进行解压，根据升级包中用于升级静态分区的升级文件对静态分区的子分区进行升级，具体为将对应静态分区中不同子分区的升级文件的数据写入对应的子分区，根据升级包中用于升级动态分区的升级文件对动态分区的子分区进行升级，具体为将对应动态分区中不同子分区的升级文件的数据先写入用户数据分区中创建的cow文件。因此，在设置压缩属性时，综合考虑了本机剩余空间(具体为用户数据分区的剩余空间)、fileSize、compressCowsize和uncompressCowsize，从而确保设置的压缩属性更加合理。
为了更好的理解本实施例中S105至S108描述的内容，以下结合图9进行具体说 明。
示例性的，参见图9，具体包括：
S201，OUC搜索到OTA服务器中存在升级包。
关于OUC搜索OTA服务器中是否存在升级包的实现方式，详见上述针对步骤S105的描述，此处不再赘述。
S202，OUC从OTA服务器中获取升级包对应的filelist.xml。
可理解的，在本实施例中filelist.xml是用来记录与升级包相关的描述信息的，故而在一些实现方式中可以将其称为文件列表描述信息。
示例性的，在本实施例中，文件列表描述信息(filelist.xml)指示了升级包的第一大小(fileSize)、升级包中第一升级文件的第二大小(compressCowsize)、第一升级文件的第三大小(uncompressCowsize)。
可理解的，第一升级文件对应于动态分区中的第一子分区，第二大小为压缩后的大小，第三大小为未压缩的大小。
示例性的，在动态分区中需要升级的子分区为一个时，第一子分区例如可以是图7.1至图7.6中动态分区(Super)中的System子分区、system_ext子分区、Product子分区、Cust子分区、Odm子分区中的任意一个。
示例性的，在动态分区中需要升级的子分区为多个时，第一子分区例如可以是图7.1至图7.6中动态分区(Super)中的System子分区、system_ext子分区、Product子分区、Cust子分区、Odm子分区中的任意几个。
应当理解的是，上述说明仅是为了更好的理解本实施例的技术方案而列举的示例，不作为对本实施例的唯一限制。上述实施例中所说的“第一子分区”仅仅是为了表示子分区为动态分区中的子分区，并作为对动态分区中子分区的数量和具体子分区的限定。
同理，上述所说的“第一升级文件”仅仅时为了表示该升级文件是用于升级动态分区中的子分区的，并不作为对升级动态分区中的子分区的升级文件的数量和该升级文件具体对应的子分区的限定。
S203，OUC从filelist.xml中获取fileSize、compressCowsize、uncompressCowsize。
示例性的，根据上述列举出的filelist.xml的内容可知，“<fileSize>”和“</fileSize>”之间的内容指示的是fileSize，因此从“<fileSize>”和“</fileSize>”这两个字段之间获取fileSize即可。
相应地，由于“<cowsize>”和“</cowsize>”之间的内容指示的是compressCowsize，因此从“<cowsize>”和“</cowsize>”这两个字段之间获取compressCowsize即可。
相应地，由于“<uncompressCowsize>”和“</uncompressCowsize>”之间的内容指示的是uncompressCowsize，因此从“<uncompressCowsize>”和“</uncompressCowsize>”这两个字段之间获取uncompressCowsize即可。
S204，OUC获取用户数据分区的第一剩余空间available spaceA。
可理解的，本实施例中所说的第一剩余空间为下载升级包之前，用户数据分区的剩余空间。
S205，OUC判断available spaceA>fileSize+uncompressCowsize？
即，OUC会计算fileSize和uncompressCowsize之和(本实施例将其称为第一总和)，然后判断第一剩余空间是否大于第一总和。
相应地，如果第一剩余空间大于第一总和，则执行步骤S206；否则执行步骤S207。
S206，OUC设置压缩属性self.virtual_ab.compression.enabled＝false。
示例性的，在本实施例中，当第一剩余空间大于第一总和时，OUC会将压缩属性对应的标识设置为第一标识，即self.virtual_ab.compression.enabled＝false。
需要说明的是，上述所说的第一标识，例如本实施例中给出的“false”是用于指示第一升级文件不使用cow压缩功能安装的。
示例性的，在实际应用中，还可以约定用“0”指示第一升级文件不使用cow压缩功能安装的。
应当理解的是，上述说明仅是为了更好的理解本实施例的技术方案而列举的示例，不作为对本实施例的唯一限制。
示例性的，在第一剩余空间大于第一总和时，表明用户数据分区可用的空间充足，这种情况下OUC可以直接向OTA服务器发起获取升级包的请求，即执行步骤S210。
S207，OUC设置压缩属性self.virtual_ab.compression.enabled＝true。
示例性的，在本实施例中，当第一剩余空间不大于第一总和时，OUC会将压缩属性对应的标识设置为第二标识，即self.virtual_ab.compression.enabled＝true。
需要说明的是，上述所说的第二标识，例如本实施例中给出的“true”是用于指示第一升级文件使用cow压缩功能安装的。
示例性的，在实际应用中，还可以约定用“1”指示第一升级文件使用cow压缩功能安装的。
应当理解的是，上述说明仅是为了更好的理解本实施例的技术方案而列举的示例，不作为对本实施例的唯一限制。
示例性的，在第一剩余空间不大于第一总和时，表明用户数据分区可用的空间不足，这种情况下秉持空间优先的原则，通过将压缩属性设置为使用cow压缩功能，从而可以尽可能减少对用户数据分区空间的占用。
S208，OUC判断available spaceA>fileSize+compressCowsize？
示例性的，OUC在将压缩属性对应的标识设置为第二标识，即true后，为了确保电子设备当前可用的用户数据分区能够容纳升级包和压缩的第一升级文件，OUC会再进行一次判断。
具体的，OUC会计算fileSize和compressCowsize之和(本实施例将其称为第二总和)，然后判断第一剩余空间是否大于第二总和。
相应地，如果第一剩余空间大于第二总和，则执行步骤S210；否则执行步骤S209。
也就是说，在用户数据分区的第一剩余空间大于所述第一大小和第二大小之和，小于第一大小和第三大小之和的情况下，后续才会以压缩形式创建第一子分区对应的cow文件(压缩cow文件)。
S209，UI界面弹框提醒清理至少(fileSize+compressCowsize-available spaceA)Mb用户数据空间。
示例性的，如果通过判断确定即便采用cow压缩功能，用户数据分区当前可用的 第一剩余空间也不足以容纳升级包和压缩的第一升级文件，这种情况下为了保证本次操作系统的升级能够顺利进行，OUC会计算第二总和和第一剩余空间的差值(本实施例将其称为第一差值)，即(fileSize+compressCowsize-available spaceA)，然后在UI界面弹框(弹窗)提醒用户需要对用户数据分区清理至少第一差值的空间，这样即便需要用户清理用户数据分区的内容，也可以减少需要删除的文件大小，从而尽可能降低用户使用电子设备时的干扰。
示例性的，在做出步骤S209的提示后，如果检测到满足预设条件，则重新执行步骤S204。关于满足预设条件重新执行步骤S204的实现方式，可以参见图7.1中步骤(2)中对于用户数据分区空间不足，清理用户数据分区的描述，此处不再赘述。
S210，OUC从OTA服务器获取升级包。
示例性的，在一些实现方式中，OUC可以根据filelist.xml中记录的信息，例如升级包的地址信息，从OTA服务器获取升级包。
应当理解的是，上述说明仅是为了更好的理解本实施例的技术方案而列举的示例，不作为对本实施例的唯一限制。
由此，OUC从OTA服务器获取升级包之前进行的空间判断和压缩属性的描述就介绍到此，以下结合图8.2，在步骤S108设置的压缩属性为“true”的情况下，对本实施例提供的操作系统的升级方案继续进行说明。
S109，获取升级包。
关于电子设备的OUC从OTA服务器获取升级包的具体方式，此处不再赘述。
S110，下发升级包。
即，OTA服务器在接收到OUC发起的获取升级包的请求后，响应于该请求，会向OUC下发请求的升级包。
此外，需要说明的是，为了避免升级包下载过程中有其他数据、文件占用了第一剩余空间，进而导致第一剩余空间不大于fileSize和uncompressCowsize之和，即不大于第一总和，最终造成根据升级包下载前设置的压缩属性确定的安装方式不合适，使得操作系统的升级无法正常进行。本实施例提供的操作系统的升级方案中，OUC在从OTA服务器获取到升级包之后，根据升级包中的升级文件对静态分区和动态分区进行升级，即将升级包中的数据写入对应的子分区前，可以再进行一次空间判断，并根据判断结果重新设置压缩属性，即执行步骤S111。
S111，根据本机的第四剩余空间(下载升级包后的剩余空间)、compressCowsize、uncompressCowsize设置压缩属性。
示例性的，根据实际情况，步骤S111可以分为以下三种情况：(1)对于第四剩余空间大于uncompressCowsize的情况，设置压缩属性为“false”；(2)对于第四剩余空间大于compressCowsize，小于uncompressCowsize的情况，设置压缩属性为“true”；(3)其他情况，例如小于compressCowsize的情况，弹框提醒用户清理用户数据分区。
为了便于说明，本实施例中步骤S111以设置的压缩属性为“true”为例。
可理解的，在实际应用中，步骤S111可以根据实际需要选择执行，并且该步骤的执行顺序可以是在下发升级指令前，也可以是在下发升级指令后，对静态分区升级前，还可以是对静态分区升级后，对动态分区升级前，此处不作限制，本实施了以下 发升级指令前为例进行说明。
示例性的，参见图10，关于操作系统升级过程中根据第二次空间判断结果设置压缩属性的过程，具体包括：
S301，OUC从OTA服务器下载完升级包。
S302，OUC获取用户数据分区的第四剩余空间available spaceB。
示例性的，OUC在从OTA服务器下载完升级包之后，会重新获取用户数据分区当前可用的空间，即第四剩余空间。
S303，OUC判断available spaceB>uncompressCowsize？
可理解的，由于此时升级包已经存储在了用户数据分区，因此本次空间判断OUC只需要判断第四剩余空间是否大于uncompressCowsize。
相应地，如果第四剩余空间大于uncompressCowsize，则表明用户数据分区的可用空间充足，本次操作系统的升级可以不使用cow压缩功能，这样就可以效率优先，快速完成升级操作。
S304，OUC设置压缩属性self.virtual_ab.compression.enabled＝false。
示例性的，在本实施例中，当第四剩余空间大于uncompressCowsize时，OUC会将压缩属性对应的标识设置为第一标识，即self.virtual_ab.compression.enabled＝false。
通过上述描述可知，上述所说的第一标识，例如本实施例中给出的“false”是用于指示第一升级文件不使用cow压缩功能安装的。
示例性的，在实际应用中，还可以约定用“0”指示第一升级文件不使用cow压缩功能安装的。
应当理解的是，上述说明仅是为了更好的理解本实施例的技术方案而列举的示例，不作为对本实施例的唯一限制。
示例性的，在第四剩余空间大于uncompressCowsize时，表明用户数据分区可用的空间充足，这种情况下OUC可以直接将下载到的升级包传送给update_engine，即执行步骤S308。
S305，OUC设置压缩属性self.virtual_ab.compression.enabled＝true。
示例性的，在本实施例中，当第四剩余空间不大于uncompressCowsize时，OUC会将压缩属性对应的标识设置为第二标识，即self.virtual_ab.compression.enabled＝true。
通过上述描述可知，上述所说的第二标识，例如本实施例中给出的“true”是用于指示第一升级文件使用cow压缩功能安装的。
示例性的，在实际应用中，还可以约定用“1”指示第一升级文件使用cow压缩功能安装的。
应当理解的是，上述说明仅是为了更好的理解本实施例的技术方案而列举的示例，不作为对本实施例的唯一限制。
示例性的，在第四剩余空间不大于uncompressCowsize时，表明用户数据分区可用的空间不足，这种情况下秉持空间优先的原则，通过将压缩属性设置为使用cow压缩功能，从而可以尽可能减少对用户数据分区空间的占用。
S306，OUC判断available spaceB>compressCowsize？
示例性的，OUC在将压缩属性对应的标识设置为第二标识，即true后，为了确 保电子设备当前可用的用户数据分区能够容纳压缩的第一升级文件，OUC会再进行一次判断。即OUC会判断第四剩余空间是否大于compressCowsize。
相应地，如果第四剩余空间大于compressCowsize，则执行步骤S308；否则执行步骤S307。
S307，UI界面弹框提醒清理至少(compressCowsize-available spaceB)Mb用户数据空间。
示例性的，如果通过判断确定即便采用cow压缩功能，用户数据分区当前可用的第四剩余空间也不足以容纳压缩的第一升级文件，这种情况下为了保证本次操作系统的升级能够顺利进行，OUC会计算compressCowsize和第四剩余空间的差值(本实施例将其称为第二差值)，即(fcompressCowsize-available spaceB)，然后在UI界面弹框(弹窗)提醒用户需要对用户数据分区清理第二差值的空间，这样即便需要用户清理用户数据分区的内容，也可以减少需要删除的文件大小，从而尽可能降低用户使用电子设备时的干扰。
示例性的，在做出步骤S307的提示后，如果检测到满足预设条件，则重新执行步骤S302。关于满足预设条件重新执行步骤S302的实现方式，可以参见图7.2中步骤(4)中对于用户数据分区空间不足，清理用户数据分区的描述，此处不再赘述。
S308，OUC向update_engine下发升级指令。
由此，OUC在下载完升级包，通知update_engine安装升级包中的升级文件之前进一步判断用户数据分区的剩余空间，并根据判断结果重新设置压缩属性，进一步保证了后续根据压缩属性确定的安装方式的合理性，从而保证了操作系统的升级能够正常完成。
由此，OUC从OTA服务器下载到升级包，进行安装之前进行的空间判断和压缩属性的描述就介绍到此，以下结合图8.2至图8.4，在步骤S111设置的压缩属性为“true”的情况下，对本实施例提供的操作系统的升级方案继续进行说明。
S112，下发升级指令。
可理解的，对于Android系统的电子设备，操作系统的升级是由升级引擎(update_engine)主导完成的。故而，OUC在从OTA服务器下载到升级包，并完成重新设置压缩属性后，会向update_engine下发升级指令，以触发update_engine开始执行升级流程。
S113，根据升级包中对应于静态分区的升级文件对静态分区升级。
关于静态分区的升级描述，可以参见图7.1中步骤(3)的描述，此处不再赘述。
另外，需要说明的是，在实际应用中，该步骤对于本实施例提供的技术方案而言是一个可选步骤，即在升级包中包括升级静态分区的升级文件时，才会执行步骤S113。
S114，确定设置的压缩属性为“ture”，调用snap进程创建压缩cow文件。
示例性的，update_engine接收到升级指令后，会读取OUC设置的压缩属性，例如通过getprop语句读取压缩属性。
具体的，如果读取的压缩属性对应的标识为上述所说的第一标识(如false)时，确定第一升级文件(升级动态分区中子分区的升级文件)对应的安装方式为不使用cow压缩功能安装的第一安装方式；如果读取的压缩属性对应的标识为上述所说的第二标 识(true)时，确定第一升级文件(升级动态分区中子分区的升级文件)对应的安装方式为使用cow压缩功能安装的第二安装方式。
S115，在用户数据分区中以压缩形式创建压缩cow文。
示例性的，由于本实施例是以设置的压缩属性为“true”为例，故而update_engine确定的压缩属性为“true”，因此snap进程会在用户数据分区中以压缩形式创建第二cow文件(后续称为压缩cow文件)，即根据第二标识，在用户数据分区中以压缩形式创建压缩cow文件。
可理解的，本实施例是以压缩属性为上述所说的第二标识为例进行的说明，如果在实际应用中，读取的压缩属性对应的标识为上述所说的第一标识(如false)时，确定第一升级文件(升级动态分区中子分区的升级文件)对应的安装方式为不使用cow压缩功能安装的第一安装方式，这种情况下，snap进程会根据第一标识，在用户数据分区中以非压缩形式创建第一子分区对应的第一cow文件(后续称为非压缩cow文件)，以使update_engine将第一升级文件以非压缩形式写入非压缩cow文件。
可理解的，在本实施例中，第一cow文件的大小大于第二cow文件，即非压缩cow文件的uncompressCowsize大于压缩cow文件的compressCowsize。
S116，反馈压缩cow文件创建成功。
可理解的，为了使update_engine获知何时开始向用户数据分区中第一子分区对应的压缩cow文件中以压缩形式写入第一升级文件的数据，snap进程在创建成功压缩cow文件后会向update_engine反馈压缩cow文件创建成功的消息。
相应地，update_engine在接收到snap进程反馈的压缩cow文件创建成功的消息后，便会执行步骤S117。
S117，将升级包中对应于动态分区的升级文件中的数据，以压缩形式写入压缩cow文件。
可理解的，如果在实际应用中，update_engine调用snap进程在用户数据分区是以非压缩形式创建的非压缩cow文件，那么snap进程创建成功非压缩cow文件后，向update_engine反馈的便于非压缩cow创建成功的消息，这样update_engine在接收到snap进程反馈的非压缩cow文件创建成功的消息后，便会将升级包中对应于动态分区的升级文件中的数据，以非压缩形式写入非压缩cow文件。
示例性的，在本实施例中，上述所说的将升级包中对应于动态分区的升级文件(后续称为第一升级文件)中的数据，以压缩形式写入压缩cow文件是指根据预设的压缩算法，将第一升级文件中的数据中的0全部去掉，然后将去掉0的数据写入压缩cow文件。
示例性的，本实施例中所说的预设的压缩算法例如可以是冗余压缩法或无损压缩法，即去掉冗余不会减少信息量，而且仍可原样恢复数据的方法。
此外，需要说明的是，如果在实际应用中，snap进程创建cow文件(不论是压缩cow文件，还是非压缩cow文件)失败，snap进程会向update_engine反馈cow文件创建失败的消息，这样update_engine在接收到snap进程反馈的cow文件创建失败的消息后，便会结束本次操作系统的升级操作，直接向OTA服务器上报升级失败的信息。
此外，关于将动态分区对应的升级文件以压缩形式写入压缩cow文件，或者以非压缩形式写入非压缩cow文件的方式，可以参见现有标准，此处不再赘述。
为了更好的理解本实施例中S114至S117描述的内容，以下结合图11进行具体说明。
示例性的，参见图11，具体包括：
S401，update_engine判断self.virtual_ab.compression.enabled＝true？
即，update_engine在接收到OUC下发的升级指令后，会读取OUC设置的压缩属性。
相应地，如果读取的压缩属性对应的标识为上述所说的第二标识(true)时，确定第一升级文件(升级动态分区中子分区的升级文件)对应的安装方式为使用cow压缩功能安装的第二安装方式，update_engine通知snap进程在用户数据分区中以压缩形式创建压缩cow文件，即执行步骤S402；如果读取的压缩属性对应的标识为上述所说的第一标识(如false)时，确定第一升级文件(升级动态分区中子分区的升级文件)对应的安装方式为不使用cow压缩功能安装的第一安装方式，update_engine通知snap进程在用户数据分区中以非压缩形式创建非压缩cow文件，即执行步骤S404。
S402，snap进程在用户数据分区中创建压缩cow文件。
S403，update_engine将动态分区对应的升级文件以压缩形式写入压缩cow文件。
示例性的，在安装方式为第二安装方式，即压缩属性指示使用cow压缩功能时，update_engine会将第一升级文件以压缩形式写入压缩cow文件，这样便可以尽可能降低对用户数据分区的空间的占用。
S404，snap进程在用户数据分区中创建非压缩cow文件。
S405，update_engine将动态分区对应的升级文件以非压缩形式写入非压缩cow文件。
示例性的，在安装方式为第一安装方式，即压缩属性指示不使用cow压缩功能时，update_engine会将第一升级文件以非压缩形式写入非压缩cow文件，这样操作系统的升级过程便会以效率优先，由于不需要对第一升级文件进行压缩，之间写入非压缩的cow文件，因此写入速度快，这样就会缩短操作系统的升级时长，也会将对电子设备电量的消耗。
由此，OUC从OTA服务器获取升级包之前进行的空间判断和压缩属性的描述就介绍到此，以下结合图8.4对本实施例提供的操作系统的升级方案继续进行说明。
S118，对写入的升级文件进行校验。
示例性的，在对写入的升级文件进行校验时，按照现有的升级逻辑，需要先根据升级包对静态分区进行升级，在静态分区升级完毕后，再根据升级包对动态分区进行升级，在动态分区升级完毕后，再依次对静态分区和动态分区进行校验。
为了便于与上述所说的针对动态分区中第一子分区的第一升级文件区别，本实施例将用于升级静态分区中子分区的升级文件称为第二升级文件。
示例性的，在操作系统的升级过程中，升级引擎会从升级包中获取第二升级文件，然后根据第二升级文件升级当前闲置的静态分区的数据。
例如，在启动是由第一静态分区启动时，在电子设备启动后进行的操作系统的升 级过程中具体是根据第二升级文件升级第二静态分区的数据。
关于对静态分区中完成升级的子分区的校验和动态分区中完成升级的子分区(具体是用户数据分区中对应的cow文件)的校验过程，可以参见现有标准，此处不再赘述。
示例性的，在校验成功后，update_engine会向OUC上报校验成功信息，即执行步骤S119。
需要说明的是，在实际应用中，校验失败，update_engine也会向OUC上报校验信息，这种情况下上报的是校验失败的信息。
为了便于后续升级流程的说明，本实施例以update_engine向OUC上报的是校验成功的信息为例。
相应地，update_engine在向OUC上报校验成功的信息后，OUC会执行步骤S120。
S120，触发整机重启。
示例性的，在校验完成后，OUC会触发电子设备进行整机重启。关于OUC触发电子设备进行整机重启的操作，详见上述实施例中关于图7.4中步骤(9)重启电子设备部分的描述，此处不再赘述。
需要说明的是，OUC触发整机重启的操作具体是snap进程完成的。故而，OUC触发整机重启后，snap进程会执行步骤S121的操作。
S121，重启过程中，对压缩cow文件进行解压缩，加载压缩cow文件中的数据，运行到升级后的操作系统。
由于本实施例是以使用cow压缩功能，即针对动态分区的子分区的升级文件是以压缩形式写入到压缩cow文件的。因此，在重启电子设备，依次加载基础分区的数据、第二静态分区的数据、动态分区的数据和用户数据分区中压缩cow文件中的数据时，需要解压缩cow文件，这样才能将压缩cow文件中的压缩数据处理为非压缩格式，进而加载使电子设备运行到升级后的操作系统(后续称为第二操作系统)。
相应地，如果针对动态分区的升级文件是以非压缩形式写入非压缩cow文件的，则在重启电子设备，依次加载基础分区的数据、第二静态分区的数据、动态分区的数据和用户数据分区中非压缩cow文件中的数据时，无需对非压缩cow文件进行解压缩操作，直接从中读取数据即可。
此外，需要说明的是，由于本实施例是以电子设备在进行操作系统的升级前是以第一静态分区为启动顺序进行启动，即启动时依次加载的是基础分区的数据、第一静态分区的数据、动态分区的数据，故而上述操作系统的升级方案中升级的是第二静态分区，因此重启时需要加载第二静态分区的数据，即启动顺序从第一静态分区变更为从第二静态分区启动。
示例性的，在将电子设备重启运行到第二操作系统后，snap进程会通知内核执行Merge操作，即步骤S122。
相应地，内核在收到snap进程发送的执行Merge操作的通知后，会执行步骤S123。
S123，执行Merge操作，将压缩cow文件的数据落盘到动态分区对应的子分区。
可理解的，本实施例中所说的Merge操作具体是指将用户数据分区中升级动态分区的升级文件落盘到动态分区的过程，即cow文件中的数据落盘到动态分区中对应子 分区的过程。
关于Merge操作的具体实现流程，参见现有标准即可，本实施例对此不再赘述。
S124，上报Merge成功的信息。
示例性的，在Merge操作执行完成后，内核会向升级引擎上报Merge结果，以便升级引擎获知用户数据分区中升级动态分区的升级文件是否落盘到动态分区。
相应地，如果Merge成功，即用户数据分区中升级动态分区的升级文件落盘到动态分区，则执行步骤S125，否则可以直接通过OUC向OTA服务器上报升级失败。
示例性的，在一些实现方式中，在Merge操作失败后，OUC可以重启电子设备，控制电子设备从第二操作系统回滚到第一操作系统，这样即便升级失败也可以保证电子设备能够正常使用。
为了便于说明，本实施例以Merge成功为例。
S125，对静态分区进行分区同步。
示例性的，仍以根据第二升级文件升级的是第二静态分区的数据为例，则在Merge成功后，对静态分区进行的分区同步操作，具体是将第二静态分区的数据同步到第一静态分区。
关于将第二静态分区的数据同步到第一静态分区的操作，在一些实现方式中，例如可以是由内核读取第二静态分区的各个子分区中的数据；然后将第二静态分区的各个子分区中的数据覆写到第一静态分区对应的子分区中。
可理解的，由于实际应用中，操作系统的升级可能仅对静态分区中的某一个或某几个子分区进行了升级，因此在进行分区同步时，为了减少分区同步对电子设备资源的占用，可以先检验第二静态分区中第二子分区内的数据是否与第一静态分区中第三子分区内的数据相同。
相应地，如果第二子分区内的数据与第三子分区内的数据相同(一致)，则跳过对该子分区的拷贝，继续比对其他子分区；反之则对第二子分区内的数据进行拷贝，然后覆写到第三子分区。
示例性的，对于上述所说的先检验第二静态分区中第二子分区内的数据是否与第一静态分区中第三子分区内的数据相同，再根据检验结果决定是否进行分区同步的方案，在具体实现时，处理可以是：
首先，计算第二子分区的数据的哈希值和第三子分区的数据的哈希值。
具体的说，第二子分区为第二静态分区的一个子分区，第三子分区为第一静态分区的一个子分区，并且，第三子分区与第二子分区相对应。
示例性的，继续参见图7.1至图7.6，如果第二静态分区中的第二子分区为X-loader_b，则第一静态分区中与第二子分区对应的第三子分区为X-loader_a。
应当理解的是，上述说明仅是为了更好的理解本实施例的技术方案而列举的示例，不作为对本实施例的唯一限制。
然后，当第二子分区的数据的哈希值与第三子分区的数据的哈希值不一致时，将第二子分区中的数据覆写到第三子分区中。
S126，上报升级成功的信息。
示例性的，在执行完静态分区同步操作后，不论分区同步是否成功，OUC均会向 OTA服务器上报升级结果，以便OTA服务器获知本次操作系统的升级是否成功。关于OUC向OTA服务器上报升级结果的操作，详见上述实施例中关于图7.6中步骤(12)上报升级结果部分的描述，此处不再赘述。
此外，需要说明的是，关于图8.4中示出的步骤S118，步骤S119和步骤S125是否执行可以根据业务需求设置，是否执行对本实施例提供的技术方案不造成影响，本实施例以执行为例进行说明。
此外，需要说明的是，在采用本实施例提供的技术方案对操作系统进行升级时，为了获知电子设备对操作系统的升级过程是使用了cow压缩功能，还是未使用cow压缩功能，可以规定在用户数据分区的第一剩余空间大于第一大小和第三大小之和的情况下，在对操作系统升级的过程中，电子设备对用户数据分区不执行除操作系统升级之外的读写操作。相应地，在用户数据分区的第一剩余空间大于第一大小和第二大小之和，小于第一大小和第三大小之和的情况下，在对操作系统升级的过程中，电子设备对用户数据分区不执行除操作系统升级之外的读写操作。这样，在电子设备进行操作系统升级前，记录用户数据分区的剩余空间(即上述所说的第一剩余空间，具体为下载升级包前用户数据分区的剩余空间)，在采用本实施例提供的技术方案将动态分区的数据写入用户数据分区的cow文件后执行重启前，获取用户数据分区的剩余空间，通过升级前、重启前用户数据分区的剩余空间的差值便可以确定cow文件的大小，基于cow文件的大小，遵循本实施例中规定的第一cow文件的大小大于第二cow的大小前提，便可以确定本次升级是使用了cow压缩功能，还是未使用cow压缩功能。
示例性的，为了便于说明第一cow文件的大小和第二cow文件的大小，本实施例将下载升级包并创建第一cow文件后，用户数据分区的剩余空间称为第二剩余空间，将下载升级包并创建第二cow文件后，用户数据分区的剩余空间称为第三剩余空间。
相应地，第一cow文件的大小等于第一剩余空间减去第二剩余空间和第一大小的值，第二cow文件的大小等于第一剩余空间减去第三剩余空间和第一大小的值。
为了便于理解，以下结合实例进行说明。假设用户数据分区的第一剩余空间为10.0G，下载升级包，并创建cow文件后的剩余空间为825.2M，升级包的第一大小为506M，基于上述给出的第一cow文件和第二cow文件的计算方式可知创建的cow文件占用了用户数据分区8.7G(10.0G-825.2M-506M)。
相应地，如果用户数据分区的第一剩余空间为2.0G，下载升级包，并创建cow文件后的剩余空间为518M，升级包的第一大小为506M，基于上述给出的第一cow文件和第二cow文件的计算方式可知创建的cow文件占用了用户数据分区1.0G(2.0G-518M-506M)。
基于第一cow文件(以非压缩形式创建的cow文件)的大小大于第二cow文件(以压缩形式创建的cow文件)的原理可知，对于升级包均为506M的操作系统的升级场景，在下载升级包前用户数据分区的第一剩余空间为10.0G，下载升级包，并创建cow文件后的剩余空间为825.2M时，操作系统的升级没有使用cow压缩功能，在下载升级包前用户数据分区的第一剩余空间为2.0G，下载升级包，并创建cow文件后的剩余空间为518M时，操作系统的升级使用了cow压缩功能。
此外，在上述场景的基础上，通过记录电子设备从下载升级包到完成升级所需的 时间，也可以确定本次升级是使用了cow压缩功能，还是未使用cow压缩功能。
不难发现，本实施例提供的操作系统的升级方案中，对动态分区中子分区对应的升级文件的安装方式取决于用户数据分区当前的剩余空间和升级文件的大小(压缩大小，非压缩大小)，从而能够在操作系统的升级过程中，根据具体情况决定是否使用cow压缩功能，进而满足不同用户需求。
为了更加直观的了解使用cow压缩功能和不使用cow压缩功能对操作系统升级的影响，以下罗列出了使用差分升级包和全量升级包进行操作系统的升级的对比。
表2差分升级包
Figure PCTCN2022139052-appb-000002
表3全量升级包
Figure PCTCN2022139052-appb-000003
Figure PCTCN2022139052-appb-000004
为了对表2和表3例举的数据内容更加清楚，以表2为例，对于安装、校验、Merge等涉及动态分区的操作，不使用cow压缩功能的升级方式中，安装需要的时间为142s，使用cow压缩功能的升级方式中，安装需要的时间为145s，因此使用cow压缩功能的升级方式中安装操作比不使用cow文件压缩功能的方式中安装操作花费的时间增加了2％。
相应地，校验操作花费的时间增加了315％，Merge操作花费的时间增加了459％，安装、校验、Merge花费的时间总计增加了108％。这就导致升级过程电子设备的整体功耗增加了6％。
但是，通过表2和表3记录的数据，使用cow压缩功能，在电子设备重启前占用用户数据分区(userdata)的大小明显比不使用cow压缩功能的占用的小，对于差分升级包减少了89％，全量升级包减少了44％。
因此，通过表2和表3可知，对于空间敏感的用户，空间优先，使用cow压缩功能，牺牲升级时间、功耗和热的体验，但无需用户删除用户数据分区中的原有数据；对于空间不敏感的用户，效率优先，不使用cow压缩功能，保证操作系统的升级能够快速完成。
此外，为了更好的理解基于本实施例提供的技术方案实现操作系统升级的整个流程，以下结合图12进行说明。
需要说明的是，图12所示的实现操作系统的升级流程是针对虚拟AB系统分区结构实现的，在电子设备当前是从第一静态分区启动时，电子设备按照如图12所示的流程实现操作系统的升级。
S501，电子设备依次加载基础分区的数据、第一静态分区的数据以及动态分区的数据，从第一静态分区启动，以运行第一操作系统。
S502，电子设备中的OUC获取升级包对应的filelist.xml。
示例性的，在一种可行的实现方案中，电子设备定期向OTA包服务器发起搜包请求，搜包请求包含电子设备当前运行的操作系统的版本号(例如版本1.1)；OTA服务器根据搜包请求中的操作系统的版本号，检索当前是否存在更新版本号的升级包(例如版本1.2)；当存在更新版本的升级包时，OTA服务器向电子设备反馈升级包(例如，由版本1.1升级到版本1.2的系统增量升级包)对应的filelist.xml的下载地址；电子设备根据filelist.xml的下载地址下载filelist.xml。
S503，OUC获取用户数据分区的第一剩余空间。
S504，OUC根据第一剩余空间和filelist.xml中的fileSize、compressCowsize、uncompressCowsize，设置压缩属性。
关于步骤S501至步骤S504的实现细节，详见上文针对图7.1至图9的文字描述，此处不再赘述。
为了便于说明，本实施例以设置的压缩属性为“false”，即第一剩余空间大于 fileSize和uncompressCowsize之和的情况为例。
S505，OUC从OTA服务器获取升级包。
示例性的，在一种可行的实现方案中，电子设备向OTA包服务器发起获取升级包(例如版本1.2)的请求后，OTA服务器向电子设备反馈升级包(例如，由版本1.1升级到版本1.2的系统增量升级包)的下载地址；电子设备根据升级包的下载地址下载升级包，并将级包保存到用户数据分区(Userdata)。
S506，OUC获取用户数据分区的第四剩余空间。
S507，OUC根据第四剩余空间和compressCowsize、uncompressCowsize，设置压缩属性。
关于步骤S506和步骤S507的实现细节，详见上文针对图7.2至图10的文字描述，此处不再赘述。
为了便于说明，本实施例仍以设置的压缩属性为“false”，即第四剩余空间大于uncompressCowsize的情况为例。
S508，电子设备中的升级引擎根据升级包中对应于第二静态分区的升级文件对第二静态分区进行升级。
例如，版本1.1升级到版本1.2的系统增量升级包包含版本1.2的静态分区的全量数据，电子设备将版本1.2的静态分区的数据覆写到第二静态分区中。
S509，升级引擎读取OUC设置的压缩属性，确定动态分区的安装方式。
S510，snap进程根据确定的安装方式在用户数据分区中创建对应的cow文件(压缩cow或者非压缩cow文件)。
例如System子分区对应的cow文件为System_COW。可理解的，如果确定的安装方式为使用cow压缩功能，则步骤S510中创建的System_COW为压缩cow文件；如果确定的安装方式为不使用cow压缩功能，则步骤S510中创建的System_COW为非压缩cow文件。
S511，升级引擎根据确定的安装方式，将升级包中对应于动态分区的升级文件写入对应的cow文件。
例如，在升级包中包含版本1.2的动态分区的数据，电子设备在用户数据分区中创建的cow文件中写入版本1.2的动态分区(Super)的数据。
可理解的，如果cow文件为压缩cow文件，则在将升级包中包含版本1.2的动态分区的数据写入压缩cow文件时，采用压缩形式进行写入；反之则无需压缩，之间写入非压缩的cow文件中。
进一步的，在虚拟AB系统分区结构的电子设备的操作系统的升级方案中，针对动态分区(Super)，采用增量升级方式。在升级过程中，用户数据分区(Userdata)的cow文件中保存的并不是升级后新版本的动态分区(Super)的全部文件，而是旧版本的动态分区(Super)中需要升级的数据在升级后的升级结果。即，用户数据分区(Userdata)的cow文件中保存的是动态分区的更新数据。
为了便于说明，以下以对动态分区的升级不需要使用cow文件为例，对动态分区的升级进行具体说明。
以system子分区为例，假设在版本1.1中，system子分区中的数据可以分为 system1、system2两部分。从版本1.1升级到版本1.2，数据system2没有发生变化，数据syetem1被升级为system3。那么，在步骤S511中，电子设备在用户数据分区(Userdata)创建cow文件，在cow文件中写入数据system3。
例如，版本1.1升级到版本1.2的系统增量升级包包含版本1.1升级到版本1.2的动态分区(Super)更新数据，该动态分区(Super)更新数据包含数据system3。
进一步的，在虚拟AB系统分区结构的电子设备的操作系统的升级方案中，基于快照技术(snapshot)实现动态分区(Super)的增量升级。具体的，用户数据分区(Userdata)的cow文件中，采用写时拷贝(Copy-On-Write，cow)文件保存动态分区(Super)的升级数据。
具体的，用户数据分区(Userdata)中保存的动态分区(Super)的升级数据包含多个cow文件，每个cow文件对应一个动态分区(Super)的子分区，cow文件的命名与其所针对的动态分区(Super)子分区相对应。
在步骤S505所获取的升级包中，动态分区(Super)的升级数据的cow文件以二进制代码形式压缩保存。在升级包中，每个cow文件根据其所针对的动态分区(Super)子分区所命名。例如，针对System子分区的cow文件被命名为system-cow-img.img.0000。
在步骤S511中，电子设备解包升级包以获取所有的cow文件，为每个cow文件附加AB分区标记。具体的，当电子设备当前从第一静态分区启动时，可以理解为电子设备当前运行操作系统所加载的动态分区(Super)为动态分区(A)。在升级操作系统时，用户数据分区(Userdata)中创建的cow文件是针对动态分区(B)。因此，为cow文件附加对应动态分区(B)的名称标记_b。例如，为system-cow-img.img.0000附加_b生成system_b-cow-img.img.0000。
进一步的，在步骤S511中，在用户数据分区(Userdata)中创建Update文件夹，将重命名的cow文件保存到Update文件夹下。例如，在一应用场景中，在向用户数据分区(Userdata)写入cow文件后，用户数据分区(Userdata)的Update文件夹中包含下述文件：
system_b-cow-img.img.0000；
system_ext_b-cow-img.img.0000；
vendor_b-cow-img.img.0000；
product_b-cow-img.img.0000；
cust_b-cow-img.img.0000；
odm_b-cow-img.img.0000。
具体的，cow文件中包含cow文件自身的cow文件地图(快照map)以及升级数据。
cow文件地图(快照)与cow文件所针对的动态分区(Super)的子分区的文件地图相对应。动态分区(Super)的子分区的文件地图用于描述当前版本的操作系统(本次升级之前的版本，例如，版本1.1)动态分区(Super)的子分区中的所有文件以及各个文件的保存地址。
cow文件中的升级数据为相较于当前版本的子分区数据，新版本的子分区数据中 被更新的文件；cow文件自身的cow文件地图则用于描述被更新的文件与当前版本的子分区中的文件间的对应关系以及被更新的文件的保存地址。
基于动态分区(Super)的子分区的文件地图以及cow文件中的cow文件地图，就可以使用cow文件中的升级数据替换动态分区(Super)的子分区中的对应文件，从而实现动态分区(Super)数据的升级。具体的，在需要获取动态分区(Super)的子分区的文件地图时，可以基于snapshot对动态分区(Super)的子分区的数据进行快照操作以生成动态分区(Super)的子分区的文件地图。也可以在制作升级包时，预先生成动态分区(Super)的子分区的文件地图，将该文件地图加入到cow文件中。
以System子分区为例，假设System子分区中按照以下路径保存数据：
/system/app/A0.XXX；
/system/app/A1.XXX；
/system/app/A2.XXX；
/system/B0.XXX；
/system/B1.XXX；
/system/user/C0.XXX；
/system/user/C1.XXX；
/system/user/C2.XXX；
/system/user/C3.XXX。
System子分区的文件地图可以是：
/system/app/A0.XXX：024010～024013；
/system/app/A1.XXX：024014～024017；
/system/app/A2.XXX：024018～024020；
/system/B0.XXX：024021～024026；
/system/B1.XXX：024027～024028；
/system/user/C0.XXX：024029～024032；
/system/user/C1.XXX：024033～024035；
/system/user/C2.XXX：024036～024040；
/system/user/C3.XXX：024041～024044。
文件名后的数值(例如，/system/app/A0.XXX：024010～024013中的024010～024013)为该文件在动态分区(Super)的System子分区的物理保存地址(块地址)。
假设当前操作系统升级需要更新数据/system/app/A2.XXX以及/system/user/C2.XXX。
可以视为：
/system/app/A2.XXX以及/system/user/C2.XXX为system子分区数据的system1部分；
/system/app/A0.XXX、/system/app/A1.XXX、/system/B0.XXX、/system/B1.XXX、/system/user/C0.XXX、/system/user/C1.XXX以及/system/user/C3.XXX为system子分区数据的system2部分。
那么，针对System子分区的cow文件(system_b-cow-img.img.0000)就包含最新版的/system/app/A2.XXX以及/system/user/C2.XXX。
可以视为，最新版的/system/app/A2.XXX以及/system/user/C2.XXX为system3。升级目标是使用system3更新掉system1。
当cow文件中的更新数据的大小与其所要更新的原始数据的大小一致，并且，cow文件中的更新数据在数据更新后在子分区中的保存位置与其所要更新的原始数据在子分区中的保存位置一致时，cow文件(system_b-cow-img.img.0000)自身的cow文件地图可以为：
/system/app/A2.XXX：
Map1(原Super分区中待更新数据的地址)：起始地址address start：024018(相对于System子分区起始地址的偏移量)；偏移量大小size：2(即024018～024020地址段的数据)
Map2(cow文件中存储的更新数据的地址)：起始地址address start：045033(相对于cow文件存储的起始地址的偏移量)；偏移量大小size：2(即045033～045035地址段的数据)；
/system/user/C2.XXX：
Map1(原Super分区中待更新数据的地址)：起始地址address start：024036(相对于System子分区起始地址的偏移量)；偏移量大小size：4(即024036～024040地址段的数据)
Map2(cow文件中存储的更新数据的地址)：起始地址address start：045036(相对于cow文件存储的起始地址的偏移量)；偏移量大小size：4(即045036～045040地址段的数据)。
当cow文件中的更新数据的大小与其所要更新的原始数据的大小不一致时，cow文件(system_b-cow-img.img.0000)自身的cow文件地图可以为：
/system/app/A2.XXX：
Map1.1(原Super分区中待更新数据的地址)：起始地址address start：024018(相对于System子分区起始地址的偏移量)；偏移量大小size：2(即024018～024020地址段的数据)
Map2.1(cow文件中存储的，需要覆盖Map1.1地址的更新数据的地址)：起始地址address start：045033(相对于cow文件存储的起始地址的偏移量)；偏移量大小size：2(即045033～045035地址段的数据)；
Map1.2(cow文件中更新数据超出待更新数据大小的那一部分在原super分区中的待写入地址)：起始地址address start：025018(相对于system起始地址的偏移量)；偏移量大小size：1(即025018～025020地址段的数据)
Map2.2(cow文件中存储的，需要覆盖Map1.2地址的更新数据的地址)：起始地址address start：046033(相对于cow文件存储的起始地址的偏移量)；偏移量大小size：2(即046033～046035地址段的数据)。
在接下来的描述中，为便于描述，仅以当cow文件中的更新数据的大小与其所要更新的原始数据的大小一致，并且，cow文件中的更新数据在数据更新后在子分区中 的保存位置与其所要更新的原始数据在子分区中的保存位置一致的应用场景进行举例说明。
在上述例子中，地址段(045033～045035以及045036～045040)分别为cow文件(system_b-cow-img.img.0000)中最新版的/system/app/A2.XXX以及/system/user/C2.XXX在用户数据分区(Userdata)的物理保存地址(块地址)。
这样，如果使用地址045033～045035上的A2.XXX替换掉地址024018～024020上的A2.XXX，并且，使用地址045036～045040上的C2.XXX替换掉地址024036～024040上的C2.XXX，就可以完成动态分区(Super)的System子分区的数据升级。
进一步的，在步骤S511中，在将cow文件写入用户数据分区(Userdata)后，还需要对动态分区(Super)+cow文件进行整体校验，校验动态分区(Super)+cow文件的有效性，验证当前版本的动态分区(Super)数据+cow文件的合成结果是否为新版本的动态分区(Super)数据。
具体的，以从1.1版本升级到1.2版本为例，计算动态分区(Super)中不需要升级的数据(从版本1.1到版本1.2未发生变化的数据)与cow文件中升级数据(从版本1.1到版本1.2需要升级的数据)的合成结果的哈希值，判断该哈希值与1.2版本中动态分区(Super)的完整数据的哈希值是否一致，如果一致，则说明cow文件有效；如果不一致，则说明cow文件无效，升级失败，中断升级进程并报错；其中，1.2版本中动态分区(Super)的完整数据的哈希值被保存在升级包中。
具体的，在校验过程中，基于snapshot合并动态分区(Super)+cow文件。在snapshot的实现过程中，动态分区(Super)与cow文件的合并并不是物理意义上的合并，而是将动态分区(Super)中子分区的文件地图与cow文件自身的cow文件地图进行合并，生成新版本的子分区数据的文件地图。
例如，将System子分区的文件地图“/system/app/A0.XXX：024010～024013；/system/app/A1.XXX：024014～024017；/system/app/A2.XXX：024018～024020；/system/B0.XXX：024021～024026；/system/B1.XXX：024027～024028；/system/user/C0.XXX：024029～024032；/system/user/C1.XXX：024033～024035；/system/user/C2.XXX：024036～024040；/system/user/C3.XXX：024041～024044。”与cow文件地图“/system/app/A2.XXX：045033～045035；/system/user/C2.XXX：045036～045040。”合并。则得到System子分区的新版本的文件地图：
/system/app/A0.XXX：024010～024013(指向动态分区(Super)中/system/app下的A0.XXX)；
/system/app/A1.XXX：024014～024017(指向动态分区(Super)中/system/app下的A1.XXX)；
/system/app/A2.XXX：045033～045035(指向用户数据分区(Userdata)中/Update/system_b-cow-img.img.0000中的A2.XXX)；
/system/B0.XXX：024021～024026(指向动态分区(Super)中/system下的B0.XXX)；
/system/B1.XXX：024027～024028(指向动态分区(Super)中/system下的B1.XXX)；
/system/user/C0.XXX：024029～024032(指向动态分区(Super)中/system/user下的C0.XXX)；
/system/user/C1.XXX：024033～024035(指向动态分区(Super)中/system/user下的C1.XXX)；
/system/user/C2.XXX：045036～045040(指向用户数据分区(Userdata)中/Update/system_b-cow-img.img.0000中的C2.XXX)；
/system/user/C3.XXX：024041～024044(指向动态分区(Super)中/system/user下的C3.XXX)。
在新版本的System子分区的文件地图中，/system/app/A2.XXX的保存地址并不是指向存储器上动态分区(Super)上的/system/app/A2.XXX，而是指向存储器上用户数据分区(Userdata)中system_b-cow-img.img.0000中的A2.XXX；/system/user/C2.XXX的保存地址并不是指向存储器上动态分区(Super)上的/system/user/C2.XXX，而是指向存储器上用户数据分区(Userdata)中system_b-cow-img.img.0000中的C2.XXX。
在校验过程中，按照上述合成方式，获取动态分区(Super)的所有子分区的新版本的文件地图(如果用户数据分区(Userdata)中并未写入某个子分区的对应cow文件，则直接以该子分区的文件地图为新版本的文件地图)。将所有子分区的新版本的文件地图组合生成动态分区(Super)的新版本的文件系统。
基于动态分区(Super)的新版本的文件系统读取数据，读取动态分区(Super)的新版本的文件系统所包含的所有文件并计算哈希值。
当cow文件有效时，将基础分区(Common)的元数据分区(/metadata)中的落盘状态信息由“已落盘(Merged)”改为“未落盘(wait for Merge)”。落盘状态信息用于表示当前是否存在需要落盘到动态分区(Super)的cow文件。具体的，落盘状态信息包含针对动态分区(Super)的整体标识以及针对每个子分区的子分区标识。当整体标识为“已落盘(Merged)”时，代表动态分区(Super)的所有子分区均不需要进行落盘操作；当整体标识为“未落盘(wait for Merge)”时，代表动态分区(Super)的一个或多个子分区需要进行落盘操作；当子分区标识为“已落盘(Merged)”时，代表该子分区不需要进行落盘操作；当子分区标识为“未落盘(wait for Merge)”时，代表该子分区需要进行落盘操作。
S512，升级引擎依次对第二静态分区和动态分区对应的cow文件进行校验。
S513，升级引擎将电子设备的启动顺序由从第一静态分区启动变更为从第二静态分区启动。
例如，改写主引导记录(Master Boot Record，MBR)的启动顺序标识，将启动顺序标识由A改写为B。在电子设备上电后，当电子设备读取到启动顺序标识为A，电子设备从第一静态分区启动，启动过程中加载第一静态分区的数据；当电子设备读取到启动顺序标识为B，电子设备从第二静态分区)启动，启动过程中加载第二静态分区的数据。
S514，OUC触发电子设备进行重启。
示例性的，OUC在触发电子设备进行重启时，会退出当前的第一操作系统，切断电子设备电源，然后再开启电子设备电源。
S515，电子设备依次加载基础分区的数据、第二静态分区的数据以及动态分区的数据，用户数据分区中cow文件中的数据，从第二静态分区启动，以运行第二操作系 统。
示例性的，电子设备首先加载基础分区(Common)的数据，在加载基础分区(Common)的过程中，电子设备读取基础分区(Common)中的启动标记；当基础分区(Common)中的启动标记为(A)时，设备在加载基础分区(Common)之后会加载第一静态分区，从而从第一静态分启动；当基础分区(Common)中的启动标记为(B)时，电子设备在加载基础分区(Common)之后会加载第二静态分区，从而从第二静态分区启动。
在S515中，电子设备读取基础分区(Common)中的启动标记。基础分区(Common)中的启动标记为(B)，电子设备在加载基础分区(Common)之后加载第二静态分区，从第二静态分区启动。
示例性的，电子设备在加载完第二静态分区的数据，加载动态分区(Super)以及用户数据分区(Userdata)的cow文件中的数据时，具体的为：电子设备读取元数据(/metadata)中的落盘状态信息，基于落盘状态信息确定是否需要从用户数据分区(Userdata)的指定路径中检索cow文件，并采用snapshot合并加载动态分区(Super)以及cow文件。
进一步的，在步骤S515中，电子设备并不加载动态分区(Super)以及用户数据分区(Userdata)中的全部cow文件，而是根据第二操作系统运行需求加载对应的文件。具体的，在步骤S515中，电子设备根据第二操作系统运行需求确定需要加载的文件，基于snapshot从动态分区(Super)或用户数据分区的cow文件中提取对应的文件进行加载。
具体的，在步骤S515中，当动态分区(Super)的子分区首存在对应的cow文件时，先基于snapshot生成动态分区(Super)各个子分区的新版本的文件地图。生成新版本的文件地图的过程可以参照步骤S511。电子设备根据第二操作系统运行需求确定需要加载的文件，基于动态分区(Super)子分区的新版本的文件地图进行文件加载。
例如，第二操作系统运行需求加载System子分区下目录user(/system/user)中的所有数据。电子设备读取元数据(/metadata)中的落盘状态信息，落盘状态信息中System子分区的子分区标识为“未落盘(wait for Merge)”，因此，电子设备在用户数据分区(Userdata)中/Update下搜索cow文件，在Update下搜索到cow文件system_b-cow-img.img.0000后，基于snapshot，根据system_b-cow-img.img.0000中的cow文件的文件地图生成System子分区的新版本的文件地图。按照System子分区的新版本的文件地图中/system/user下所有文件的保存地址进行数据加载，例如，根据System子分区的新版本的文件地图中：
/system/user/C0.XXX：024029～024032；
/system/user/C1.XXX：024033～024035；
/system/user/C2.XXX：045036～045040；
/system/user/C3.XXX：024041～024044。
加载地址024029～024032处的C0.XXX、地址024033～024035处的C1.XXX、地址045036～045040处的C2.XXX以及地址024041～024044处的C3.XXX。
进一步的，在加载System子分区下目录user(/system/user)中的所有数据时， 当落盘状态信息中System子分区的子分区标识为“已落盘(Merged)”时，电子设备就不会在用户数据分区(Userdata)中/Update下搜索cow文件，而是直接加载System子分区下目录user(/system/user)中的所有数据。
进一步的，在加载System子分区下目录user(/system/user)中的所有数据时，当落盘状态信息中System子分区的子分区标识为“未落盘(wait for Merge)”时，如果电子设备在用户数据分区(Userdata)中/Update下未搜索到对应System子分区的cow文件时，则说明升级过程中数据写入错误(cow文件写入错误或者落盘状态信息写入错误)，此时电子设备回滚到第一操作系统并向OTA服务器上报升级失败的日志信息。
进一步的，电子设备在加载动态分区(Super)以及用户数据分区(Userdata)的cow文件中的数据的过程中，在加载文件之前，电子设备还需要对加载文件进行校验。不同于步骤S511，在步骤S515中，不对动态分区(Super)+cow文件进行整体验证，而是仅对需要加载的文件进行验证。例如，基于dmverity进行校验(dm-verity是dm(device mapper)的一个目标(target)，是一个虚拟块电子设备，专门用于文件系统的校验)。校验成功则加载文件，校验失败则重启电子设备，回滚到第一操作系统或者尝试再次加载文件。
S516，电子设备成功启动，进入用户交互界面。
S517，内核执行Merge操作。
可理解的，在本申请中，Merge操作具体是指在操作系统升级过程中，将用户数据分区(Userdata)中保存的动态分区(Super)升级文件(cow文件)写入到动态分区(Super)中，使得动态分区(Super)的文件完成数据升级，以便电子设备在下次启动时不需要加载动态分区(Super)和用户数据分区的cow文件，只需加载动态分区(Super)就可以完成电子设备启动。
具体的，电子设备在启动成功后进行开机广播，开机广播后开启升级进程。升级进程读取基础分区(Common)的元数据(/metadata)中的落盘状态信息，如果落盘状态信息为“已落盘(Merged)”，则电子设备进入正常运行模式。
如果落盘状态信息为“未落盘(wait for Merge)”，升级进程将用户数据分区(Userdata)中的cow文件落盘到动态分区(Super)中。
具体的，升级进程将用户数据分区(Userdata)中的cow文件中的升级数据写入到动态分区(Super)中的对应地址上，使得动态分区(Super)中的全部数据均为升级后的新版本的数据。
例如，基于System子分区的文件地图中的/system/app/A2.XXX：024018～024020以及cow文件地图中的/system/app/A2.XXX：045033～045035，将地址045033～045035上的数据写入到地址024014～024017上；基于System子分区的文件地图中的/system/user/C2.XXX：024036～024040以及cow文件地图中的/system/user/C2.XXX：045036～045040，将地址045036～045040上的数据写入到地址024036～024040上。
在此之后升级进程删除用户数据分区(Userdata)中的cow文件，将存储空间归还给用户数据分区(Userdata)；并且，将基础分区(Common)的元数据(/metadata)中的落盘状态信息由“未落盘(wait for Merge)”改为“已落盘(Merged)”。
在步骤S508中，静态分区升级的数据操作是针对第二静态分区中的操作系统数据的，其并不会影响到当前启动的第一静态分区的操作系统数据；并且，在步骤S511中，动态分区升级的数据操作是在用户数据分区(Userdata)中所创建的虚拟动态分区上完成的，其并不会影响到当前挂载的动态分区(Super)。因此，在整个操作系统升级的过程中，用户可以正常使用电子设备；并且，在步骤S513完成后，电子设备并不需要立即重启，可以由用户自行选择重启时机；这样，操作系统的升级过程并不会对用户的正常手机操作产生影响，从而大大提高了用户体验。进一步的，针对动态分区(Super)，仅在需要进行升级时才会在用户数据分区(Userdata)上创建虚拟动态分区，因此有效提高了数据存储空间利用率。
S518，内核l将第二静态分区的数据同步到第一静态分区。
基于上述升级流程，假设第一静态分区对应版本1.1的操作系统，电子设备从第一静态分区启动运行版本1.1的操作系统；当操作系统升级到1.2时，电子设备重启后从第二静态分区启动运行版本1.2的操作系统；此时，电子设备运行版本1.2的操作系统。第一静态分区对应版本1.1的操作系统，第二静态分区对应版本1.2的操作系统，第一静态分区与第二静态分区中的数据并不一致。假设第二静态分区出现错误，第一静态分区无法取代第二静态分区的功能，即第一静态分区无法支持电子设备运行版本1.2的操作系统。然而，如果始终保持第一静态分区与第二静态分区间数据的一致，那么，当第一静态分区或第二静态分区出现错误，就可以使用另一个静态分区。
因此，在完成Merge操作后，通过对静态分区进行分区同步，即在第一静态分区与第二静态分区间相互备份数据，从而保持第一静态分区与第二静态分区中数据的一致，这样便可以解决上述技术问题。
关于kernel将第二静态分区的数据同步到第一静态分区的具体实现细节，详见上文针对图8.4中步骤S125文字描述，此处不再赘述。
此外，需要说明的是，在实际的应用场景中由电子设备实现的上述各实施例提供的操作系统的升级方法，也可以由电子设备中包括的芯片系统来执行，其中，该芯片系统可以包括处理电路、接收管脚和发送管脚，接收管脚、发送管脚和处理电路通过内部连接通路互相通信。该处理电路与存储器耦合，使得该芯片系统运行时调用该存储器中存储的计算机程序，实现上述电子设备执行的步骤。
此外，需要说明的是，该芯片系统中的处理电路可以是应用处理器也可以是非应用处理器。
此外，本申请实施例还提供一种计算机可读存储介质，该计算机存储介质中存储有计算机指令，当该计算机指令在电子设备上运行时，使得电子设备执行上述相关方法步骤实现上述实施例中的操作系统的升级方法。
此外，本申请实施例还提供了一种计算机程序产品，当该计算机程序产品在电子设备上运行时，使得电子设备执行上述相关步骤，以实现上述实施例中的操作系统的升级方法。
此外，通过上述描述可知，本申请实施例提供的电子设备、计算机可读存储介质、计算机程序产品、芯片均用于执行上文所提供的对应的方法，因此，其所能达到的有益效果可参考上文所提供的对应的方法中的有益效果，此处不再赘述。
以上所述，以上实施例仅用以说明本申请的技术方案，而非对其限制；尽管参照前述实施例对本申请进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分技术特征进行等同替换；而这些修改或者替换，并不使相应技术方案的本质脱离本申请各实施例技术方案的范围。

Claims (18)

  1. 一种操作系统的升级方法，其特征在于，应用于电子设备，所述电子设备包括处理器以及存储器，所述存储器包括基础分区、第一静态分区、第二静态分区、动态分区以及用户数据分区，所述电子设备启动后依次加载所述基础分区的数据、所述第一静态分区的数据以及所述动态分区的数据以运行第一操作系统，所述第一操作系统运行之后，所述方法还包括：
    获取升级包对应的文件列表描述信息，所述文件列表描述信息指示了所述升级包的第一大小、所述升级包中第一升级文件压缩后的第二大小、所述第一升级文件未压缩的第三大小，所述第一升级文件对应于所述动态分区中的第一子分区；
    在所述用户数据分区的第一剩余空间大于所述第一大小和所述第三大小之和的情况下，在所述用户数据分区中创建所述第一子分区对应的第一写时拷贝cow文件，所述第一剩余空间为下载所述升级包前所述用户数据分区的剩余空间；
    在所述用户数据分区的第一剩余空间大于所述第一大小和所述第二大小之和，小于所述第一大小和所述第三大小之和的情况下，在所述用户数据分区中创建所述第一子分区对应的第二cow文件，所述第一cow文件的大小大于所述第二cow文件。
  2. 根据权利要求1所述的方法，其特征在于，
    所述第一cow文件的大小等于所述第一剩余空间减去第二剩余空间和所述第一大小的值，所述第二剩余空间为下载所述升级包并创建所述第一cow文件后，所述用户数据分区的剩余空间；
    所述第二cow文件的大小等于所述第一剩余空间减去第三剩余空间和所述第一大小的值，所述第三剩余空间为下载所述升级包并创建所述第二cow文件后，所述用户数据分区的剩余空间。
  3. 根据权利要求1或2所述的方法，其特征在于，在所述用户数据分区的第一剩余空间大于所述第一大小和所述第三大小之和的情况下，在所述用户数据分区中创建所述第一子分区对应的第一写时拷贝cow文件，包括：
    在所述用户数据分区的第一剩余空间大于所述第一大小和所述第三大小之和的情况下，设置压缩属性对应的标识为第一标识，所述第一标识指示所述第一升级文件不使用cow压缩功能安装；
    根据所述第一标识，在所述用户数据分区中以非压缩形式创建所述第一子分区对应的所述第一cow文件。
  4. 根据权利要求3所述的方法，其特征在于，在根据所述第一标识，在所述用户数据分区中以非压缩形式创建所述第一子分区对应的所述第一cow文件之前，所述方法还包括：
    获取所述升级包；
    在获取到所述升级包之后，执行所述根据所述第一标识，在所述用户数据分区中以非压缩形式创建所述第一子分区对应的所述第一cow文件的步骤。
  5. 根据权利要求4所述的方法，其特征在于，在获取到所述升级包之后，执行所述根据所述第一标识，在所述用户数据分区中以非压缩形式创建所述第一子分区对应的所述第一cow文件的之前，所述方法还包括：
    在所述用户数据分区的第四剩余空间大于所述第三大小的情况下，设置压缩属性对应的标识为第一标识，所述第四剩余空间为下载完所述升级包后所述用户数据分区的剩余空间；
    在所述用户数据分区的第四剩余空间大于所述第二大小，小于所述第三大小的情况下，设置压缩属性对应的标识为第二标识，所述第二标识指示所述第一升级文件使用cow压缩功能安装。
  6. 根据权利要求5所述的方法，其特征在于，在所述根据所述第一标识，在所述用户数据分区中以非压缩形式创建所述第一子分区对应的所述第一cow文件的之后，所述方法还包括：
    以非压缩形式将所述第一升级文件中的数据写入所述用户数据分区中以非压缩形式创建所述第一子分区对应的所述第一cow文件。
  7. 根据权利要求1至6任一项所述的方法，其特征在于，在所述用户数据分区的第一剩余空间大于所述第一大小和所述第二大小之和，小于所述第一大小和所述第三大小之和的情况下，在所述用户数据分区中创建所述第一子分区对应的第二cow文件，所述第一cow文件的大小大于所述第二cow文件，包括：
    在所述用户数据分区的第一剩余空间大于所述第一大小和所述第二大小之和，小于所述第一大小和所述第三大小之和的情况下，设置压缩属性对应的标识为第二标识，所述第二标识指示所述第一升级文件使用cow压缩功能安装；
    根据所述第二标识，在所述用户数据分区中以压缩形式创建所述第一子分区对应的所述第二cow文件。
  8. 根据权利要求7所述的方法，其特征在于，在根据所述第二标识，在所述用户数据分区中以压缩形式创建所述第一子分区对应的所述第二cow文件之前，所述方法还包括：
    获取所述升级包；
    在获取到所述升级包之后，执行所述根据所述第二标识，在所述用户数据分区中以压缩形式创建所述第一子分区对应的所述第二cow文件的步骤。
  9. 根据权利要求8所述的方法，其特征在于，在获取到所述升级包之后，执行所述根据所述第二标识，在所述用户数据分区中以压缩形式创建所述第一子分区对应的所述第二cow文件之前，所述方法还包括：
    在所述用户数据分区的第四剩余空间大于所述第三大小的情况下，设置压缩属性对应的标识为第一标识，所述第一标识指示所述第一升级文件不使用cow压缩功能安装，所述第四剩余空间为下载完所述升级包后所述用户数据分区的剩余空间；
    在所述用户数据分区的第四剩余空间大于所述第二大小，小于所述第三大小的情况下，设置压缩属性对应的标识为第二标识。
  10. 根据权利要求9所述的方法，其特征在于，在所述根据所述第二标识，在所述用户数据分区中以压缩形式创建所述第一子分区对应的所述第二cow文件的之后，所述方法还包括：
    以压缩形式将所述第一升级文件中的数据写入所述用户数据分区中以压缩形式创建所述第一子分区对应的所述第二cow文件。
  11. 根据权利要求1至10任一项所述的方法，其特征在于，所述以压缩形式将所述第一升级文件中的数据写入所述用户数据分区中以压缩形式创建所述第一子分区对应的所述第二cow文件，包括：
    将所述第一升级文件中的数据中的0去掉；
    将去掉0的数据写入所述用户数据分区中以压缩形式创建所述第一子分区对应的所述第二cow文件。
  12. 根据权利要求1至11任一项所述的方法，其特征在于，所述方法还包括：
    在所述用户数据分区的第一剩余空间大于所述第一大小和所述第三大小之和的情况下，在对所述操作系统升级的过程中，所述电子设备对所述用户数据分区不执行除所述操作系统升级之外的读写操作；
    或者，
    在所述用户数据分区的第一剩余空间大于所述第一大小和所述第二大小之和，小于所述第一大小和所述第三大小之和的情况下，在对所述操作系统升级的过程中，所述电子设备对所述用户数据分区不执行除所述操作系统升级之外的读写操作。
  13. 根据权利要求1至12任一项所述的方法，其特征在于，所述方法还包括：
    在所述第一剩余空间小于所述第一大小和所述第二大小之和的情况下，提示清理所述用户数据分区。
  14. 根据权利要求13所述的方法，其特征在于，所述提示清理所述用户数据分区，包括：
    确定所述第一大小和所述第二大小之和与所述第一剩余空间的第一差值；
    提示对所述用户数据分区清理至少所述第一差值的空间。
  15. 根据权利要求1至12任一项所述的方法，其特征在于，所述方法还包括：
    在所述第四剩余空间小于所述第二大小的情况下，提示清理所述用户数据分区。
  16. 根据权利要求15所述的方法，其特征在于，所述提示清理所述用户数据分区，包括：
    确定所述第二大小与所述第四剩余空间的第二差值；
    提示对所述用户数据分区清理至少所述第二差值的空间。
  17. 一种电子设备，其特征在于，所述电子设备包括处理器以及存储器，所述存储器包括基础分区、第一静态分区、第二静态分区、动态分区以及用户数据分区，所述电子设备启动后依次加载所述基础分区的数据、所述第一静态分区的数据以及所述动态分区的数据以运行第一操作系统；
    其中，所述存储器和所述处理器耦合，所述存储器存储有程序指令；
    当所述程序指令由所述处理器执行时，使得所述电子设备执行如权利要求1至16中任意一项所述的操作系统的升级方法。
  18. 一种计算机可读存储介质，包括计算机程序，其特征在于，当所述计算机程序在电子设备上运行时，使得所述电子设备执行如权利要求1至16中任意一项所述的操作系统的升级方法。
PCT/CN2022/139052 2022-03-11 2022-12-14 操作系统的升级方法、电子设备及存储介质 WO2023169035A1 (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
EP22899610.4A EP4270299A1 (en) 2022-03-11 2022-12-14 Operating system upgrade method, electronic device, and storage medium

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN202210243332.7 2022-03-11
CN202210243332.7A CN114661322B (zh) 2022-03-11 2022-03-11 操作系统的升级方法、电子设备及存储介质

Publications (1)

Publication Number Publication Date
WO2023169035A1 true WO2023169035A1 (zh) 2023-09-14

Family

ID=82028771

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2022/139052 WO2023169035A1 (zh) 2022-03-11 2022-12-14 操作系统的升级方法、电子设备及存储介质

Country Status (3)

Country Link
EP (1) EP4270299A1 (zh)
CN (2) CN116737195A (zh)
WO (1) WO2023169035A1 (zh)

Families Citing this family (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN116737195A (zh) * 2022-03-11 2023-09-12 荣耀终端有限公司 操作系统的升级方法、电子设备及存储介质
CN116668285B (zh) * 2022-12-05 2024-05-03 荣耀终端有限公司 配置制式的方法、设备和存储介质

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN105843656A (zh) * 2016-04-22 2016-08-10 Tcl集团股份有限公司 磁盘空间不足的系统升级方法、终端设备及服务器
US20170090903A1 (en) * 2015-09-30 2017-03-30 Apple Inc. Software Updating
CN113032032A (zh) * 2021-05-21 2021-06-25 武汉深之度科技有限公司 一种系统管理方法、装置、计算设备及可读存储介质
CN113821233A (zh) * 2021-06-15 2021-12-21 荣耀终端有限公司 操作系统升级方法、设备、存储介质及计算机程序产品
CN114661322A (zh) * 2022-03-11 2022-06-24 荣耀终端有限公司 操作系统的升级方法、电子设备及存储介质

Family Cites Families (14)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7814474B2 (en) * 2000-11-17 2010-10-12 Hewlett-Packard Development Company, L.P. Updatable mobile handset based on Linux with compression and decompression techniques
US7509636B2 (en) * 2003-12-15 2009-03-24 Microsoft Corporation System and method for updating files utilizing delta compression patching
CN101552653A (zh) * 2009-05-20 2009-10-07 腾讯科技（深圳）有限公司 一种基于im的文件发送方法及装置
US9563410B2 (en) * 2011-05-25 2017-02-07 Amx Llc Data-driven menuing system for providing a flexible user interface on an electronic device
US8874700B2 (en) * 2013-03-21 2014-10-28 Nextbit Systems Inc. Optimizing storage of data files
CN103473099B (zh) * 2013-09-13 2017-02-01 惠州Tcl移动通信有限公司 一种移动终端的软件升级方法和系统
CN104301383A (zh) * 2014-09-05 2015-01-21 小米科技有限责任公司 一种升级方法、装置及设备
US20190235758A1 (en) * 2018-01-29 2019-08-01 International Business Machines Corporation Autonomic Data Compression for Balancing Performance and Space
US10587287B2 (en) * 2018-03-28 2020-03-10 International Business Machines Corporation Computer system supporting multiple encodings with static data support
CN110221856B (zh) * 2019-06-25 2024-03-19 努比亚技术有限公司 一种可穿戴设备升级方法、可穿戴设备及存储介质
CN110865837B (zh) * 2019-11-14 2023-08-18 青岛海信移动通信技术有限公司 一种进行系统升级的方法和终端
CN111142896A (zh) * 2019-12-09 2020-05-12 苏州浪潮智能科技有限公司 一种存储设备固件升级的方法、设备及可读介质
CN113821235B (zh) * 2021-06-15 2023-10-20 荣耀终端有限公司 操作系统数据更新方法、设备、存储介质及程序产品
CN113867768A (zh) * 2021-09-30 2021-12-31 厦门亿联网络技术股份有限公司 操作系统处理方法、装置、电子设备及存储介质

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20170090903A1 (en) * 2015-09-30 2017-03-30 Apple Inc. Software Updating
CN105843656A (zh) * 2016-04-22 2016-08-10 Tcl集团股份有限公司 磁盘空间不足的系统升级方法、终端设备及服务器
CN113032032A (zh) * 2021-05-21 2021-06-25 武汉深之度科技有限公司 一种系统管理方法、装置、计算设备及可读存储介质
CN113821233A (zh) * 2021-06-15 2021-12-21 荣耀终端有限公司 操作系统升级方法、设备、存储介质及计算机程序产品
CN114661322A (zh) * 2022-03-11 2022-06-24 荣耀终端有限公司 操作系统的升级方法、电子设备及存储介质

Also Published As

Publication number Publication date
CN114661322A (zh) 2022-06-24
CN116737195A (zh) 2023-09-12
EP4270299A1 (en) 2023-11-01
CN114661322B (zh) 2023-05-23

Similar Documents

Publication Publication Date Title
WO2023169035A1 (zh) 操作系统的升级方法、电子设备及存储介质
CN110825563B (zh) 系统恢复方法、装置以及电子设备
WO2022262744A1 (zh) 操作系统升级方法、设备、存储介质及计算机程序产品
US20080216066A1 (en) Program upgrade system and method for ota-capable mobile terminal
CN111796856B (zh) 差分升级方法及装置、存储介质、计算机设备
WO2022111097A1 (zh) 一种文件更新方法及装置、设备、存储介质
CN114265616B (zh) 操作系统的升级方法、电子设备及存储介质
WO2022262754A1 (zh) 操作系统数据更新方法、设备、存储介质及程序产品
CN101719073A (zh) 一种基于智能客户端的按需下载实现方法
CN104918114A (zh) 一种操作系统升级方法及装置
CN113805914B (zh) 操作系统升级方法、设备、存储介质及计算机程序产品
WO2022095758A1 (zh) 终端升级的方法及终端
CN113868156B (zh) 系统升级掉电保护方法、电子设备及存储介质
CN115543368A (zh) 一种操作系统升级方法及电子设备
CN112162773A (zh) 差分升级方法及装置、存储介质、终端
WO2016074460A1 (zh) 一种数据处理方法及装置
WO2023198056A1 (zh) 嵌入式设备固件更新方法以及嵌入式设备
WO2023130946A1 (zh) 操作系统升级方法、电子设备、存储介质及芯片系统
CN106933604B (zh) 一种系统升级方法及装置
CN114461257B (zh) 操作系统数据配置方法、设备、存储介质及程序产品
CN107436783B (zh) 一种用于移动终端的差分升级方法、存储介质及移动终端
WO2018028321A1 (zh) 一种虚拟外置存储设备的管理方法、装置及终端
CN116701318B (zh) 系统升级信息获取方法、电子设备及存储介质
CN113821234B (zh) 操作系统升级方法、设备、存储介质及计算机程序产品
CN115562695B (zh) 操作系统升级方法、电子设备、存储介质及芯片系统

Legal Events

Date Code Title Description
ENP Entry into the national phase

Ref document number: 2022899610

Country of ref document: EP

Effective date: 20230607