Nothing Special   »   [go: up one dir, main page]

WO2023005370A1 - 一种操作系统升级方法、设备、存储介质及计算机程序产品 - Google Patents

一种操作系统升级方法、设备、存储介质及计算机程序产品 Download PDF

Info

Publication number
WO2023005370A1
WO2023005370A1 PCT/CN2022/094139 CN2022094139W WO2023005370A1 WO 2023005370 A1 WO2023005370 A1 WO 2023005370A1 CN 2022094139 W CN2022094139 W CN 2022094139W WO 2023005370 A1 WO2023005370 A1 WO 2023005370A1
Authority
WO
WIPO (PCT)
Prior art keywords
partition
operating system
upgrade
electronic device
partition table
Prior art date
Application number
PCT/CN2022/094139
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 US18/247,315 priority Critical patent/US20230229424A1/en
Priority to EP22847982.0A priority patent/EP4202649A4/en
Publication of WO2023005370A1 publication Critical patent/WO2023005370A1/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
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00—Arrangements for software engineering
    • G06F8/60—Software deployment
    • G06F8/61—Installation
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/4401—Bootstrapping
    • G06F9/4406—Loading of operating system

Definitions

  • the present application relates to the field of computer technology, and in particular to an operating system upgrade method, device, storage medium and computer program product.
  • a user terminal needs to be installed with an operating system before it can be used by the user.
  • an operating system for example: IOS system, Android system
  • a mobile phone operating system for example: IOS system, Android system
  • the operating system installed on the terminal device After the operating system is installed on the terminal device, when the version of the operating system is upgraded, the operating system installed on the terminal device needs to be upgraded.
  • the partition structure of the operating system of the terminal device is planned in advance on the memory of the terminal device.
  • the upgrade of the operating system is mainly to update the operating system data under the original operating system partition structure.
  • it is necessary to change the partition structure of the operating system for example, to add partitions or delete partitions. Therefore, there is a need for an operating system upgrade method that supports adjusting the partition structure.
  • the present application provides a method for upgrading an operating system, a device, a storage medium, and a computer program product, so as to solve the problem of how to adjust the partition structure of the device memory in the prior art.
  • the embodiment of the present application provides a method for upgrading an operating system, which is applied to an electronic device.
  • the electronic device includes a processor and a memory, and the memory includes a basic partition, a first static partition, a second static partition, a dynamic partition, and a user partition.
  • the current partition table of the electronic device is the first partition table corresponding to the first operating system.
  • the operating system upgrade package includes a second partition table corresponding to the second operating system and operating system upgrade data, the operating system upgrade data is used to upgrade the first operating system to the second operating system, wherein, in the second In the partition table and the first partition table, the address configurations of the partitions with the same name are consistent;
  • the electronic device loads the data of the basic partition, the first static partition and the dynamic partition to run the first operating system;
  • the operating system of the electronic device is upgraded according to the operating system upgrading data, and the first operating system is upgraded to the second operating system.
  • the operating system using the virtual A/B upgrade scheme can be upgraded and the partition table of the device memory can be updated during the upgrading process; according to the scheme of the first aspect of the present application, there is no need to prepare a burning tool , the device can complete the update of the partition table by itself based on the downloaded operating system upgrade package; the solution according to the first aspect of the application greatly simplifies the operation difficulty of updating the device partition table and improves user experience.
  • the method before restarting the electronic device and entering the recovery mode, the method further includes:
  • the partition table update preparation operation is used to configure the execution process of the electronic device in the recovery mode.
  • performing partition table update preparation operations includes:
  • a first control command is written in the cache, the first control command corresponds to a first operation flow, and the first operation flow is used to update the partition table of the electronic device to the second partition table.
  • the first operation process includes:
  • updating the partition table of the electronic device to the second partition table includes:
  • Analyzing the first control command calling the execution code of the first operation process according to the first control command;
  • the method before executing the partition table update preparation operation, the method further includes:
  • confirming whether the operating system upgrade package is used to update the partition includes:
  • the description file corresponding to the operating system upgrade package is parsed.
  • the description file contains a partition upgrade package flag, the operating system upgrade package is used to update the partition.
  • updating the partition table of the electronic device to the second partition table includes setting the status of the partition update flag to updated
  • Upgrading the operating system of the electronic device according to the operating system upgrade data, and upgrading the first operating system to the second operating system includes setting the state of the partition update flag as not updated.
  • the method before upgrading the operating system of the electronic device according to the operating system upgrade data, the method further includes:
  • the operating system of the electronic device is upgraded according to the operating system upgrade data.
  • the first operating system includes a first upgrade package acquisition tool and a first upgrade engine, and after the first operating system runs, the method includes:
  • the first upgrade package acquisition tool acquires the operating system upgrade package
  • the first upgrade package acquisition tool confirms whether the operating system upgrade package is used to update the partition
  • the first upgrade package acquisition tool confirms whether the partition table of the electronic device has been updated based on the second partition table
  • the first upgrade package acquisition tool performs a partition table update preparation operation
  • the first upgrade package acquisition tool records the first upgrade process breakpoint, and the first upgrade process breakpoint corresponds to confirming whether the partition table of the electronic device has been updated based on the second partition table;
  • the first upgrade package acquisition tool triggers the first restart
  • the electronic device After the first restart, the electronic device enters the recovery mode, and in the recovery mode, the partition table of the electronic device is updated to the second partition table, after which, the partition table of the electronic device has been updated based on the second partition table;
  • the electronic device loads the data of the basic partition, the first static partition and the dynamic partition to run the first operating system;
  • the first upgrade package acquisition tool reads the first upgrade process breakpoint, and confirms again whether the partition table of the electronic device has been updated based on the second partition table;
  • the first upgrade package acquisition tool When the first upgrade package acquisition tool confirms that the partition table of the electronic device has been updated based on the second partition table, the first upgrade package acquisition tool triggers the first upgrade engine to upgrade the operating system of the electronic device according to the operating system upgrade data.
  • the first operating system includes a second upgrade package acquisition tool and a second upgrade engine, and after the first operating system runs, the method includes:
  • the second upgrade package acquisition tool acquires the operating system upgrade package
  • the second upgrade package acquisition tool triggers the second upgrade engine to enter the upgrade process
  • the second upgrade engine confirms whether the operating system upgrade package is used to update the partition
  • the second upgrade engine confirms whether the partition table of the electronic device has been updated based on the second partition table
  • the second upgrade engine When the partition table of the electronic device has not been updated based on the second partition table, the second upgrade engine performs a partition table update preparation operation
  • the second upgrade engine returns the state information that the partition table update preparation operation is completed to the second upgrade package acquisition tool
  • the second upgrade package acquisition tool records the second upgrade process breakpoint, and the second upgrade process breakpoint corresponds to the second upgrade package acquisition tool triggering the second upgrade engine to enter the upgrade process;
  • the second upgrade package acquisition tool triggers the third restart of the electronic device
  • the electronic device After the third restart, the electronic device enters the recovery mode, and in the recovery mode, the partition table of the electronic device is updated to the second partition table, after which, the partition table of the electronic device has been updated based on the second partition table;
  • the electronic device loads the data of the basic partition, the first static partition and the dynamic partition to run the first operating system;
  • the second upgrade package acquisition tool reads the breakpoint of the second upgrade process, and triggers the second upgrade engine to enter the upgrade process again;
  • the second upgrade engine confirms again whether the operating system upgrade package is used to update the partition
  • the second upgrade engine confirms again whether the partition table of the electronic device has been updated based on the second partition table;
  • the second upgrade engine upgrades the operating system of the electronic device according to the operating system upgrade data.
  • the operating system upgrade data also includes static partition upgrade data and dynamic partition upgrade data, and the operating system of the electronic device is upgraded according to the operating system upgrade data, including:
  • the electronic device loads the data of the basic partition, the second static partition, the dynamic partition and the virtual dynamic partition to run the second operating system;
  • the data of the virtual dynamic partition is dropped to the dynamic partition.
  • the present application proposes 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, and the dynamic partition includes a plurality of sub-partitions,
  • the processor is used to execute the software code stored on the memory, so that after the electronic device is started, the data of the basic partition, the first static partition and the dynamic partition are loaded to run the first operating system;
  • the electronic device is made to execute the method flow of the first aspect.
  • the present application provides a computer-readable storage medium, in which a computer program is stored, and when running on a computer, the computer is made to execute the method in the first aspect.
  • the present application provides a computer program product, the computer program product includes a computer program, and when it is run on a computer, it causes the computer to execute the method of the first aspect.
  • FIG. 1 is a schematic diagram of a data storage structure according to an embodiment of the present application.
  • FIG. 2 is a schematic diagram of a data storage structure according to an embodiment of the present application.
  • FIG. 3 is a flow chart of upgrading the operating system according to an embodiment of the present application.
  • FIG. 4 is a schematic diagram of a data storage structure according to an embodiment of the present application.
  • FIG. 5 is a flow chart showing an operating system upgrade according to an embodiment of the present application.
  • FIG. 6 is a schematic diagram of the frame structure of the burning system for burning the system before leaving the factory according to an embodiment of the present application
  • FIG. 7 is a schematic diagram of a data storage structure according to an embodiment of the present application.
  • FIG. 8 is a schematic diagram of a partition structure of a reconfigured partition architecture according to an embodiment of the present application.
  • Fig. 9a is a flow chart showing an operating system upgrade according to an embodiment of the present application.
  • FIG. 9b is a schematic diagram showing the composition of internal files of an operating system upgrade package according to an embodiment of the present application.
  • FIG. 10 is a flow chart showing an operating system upgrade according to an embodiment of the present application.
  • Fig. 11 shows a partial flowchart of operating system upgrade according to an embodiment of the present application
  • Fig. 12 is a schematic diagram of a mobile phone running interface according to an embodiment of the present application.
  • Fig. 13 is a schematic diagram of a mobile phone running interface according to an embodiment of the present application.
  • FIG. 14 is a partial flowchart of operating system upgrade according to an embodiment of the present application.
  • FIG. 15 is a flow chart showing an operating system upgrade according to an embodiment of the present application.
  • FIG. 16 is a partial flow chart of operating system upgrade according to an embodiment of the present application.
  • the partition table is used to describe the partition deployment of the memory in the device, and defines the starting address and size of each partition.
  • the partition table is usually stored in the disk header of the device's memory, and each partition on the memory can be located by reading the partition table when the device is started.
  • FIG. 1 is a schematic diagram of a data storage structure according to an embodiment of the present application.
  • the partition structure of the version 1.0 operating system includes GPT partition, x-loader partition, bootloader partition, boot partition, vendor-boot partition, Super partition and Userdata partition.
  • the partition table is saved in the GPT partition;
  • Userdata is used to save the user's personal data, for example, personal data such as APP installed by the user, pictures, documents, and videos saved by the user;
  • x-loader partition, bootloader partition, boot partition, The vendor-boot partition and the Super partition are used to store operating system data.
  • AD1-AD6 respectively represent different address strings.
  • the number string of the address is hexadecimal, adding 1 to the address string represents a storage bit (bit), every 8 storage bits is a byte (Byte), every 1024 bytes is 1KB, and every 1024KB is 1MB.
  • AD1 is 0x000000FF offset 256KB storage bit, which is 0x002000FF;
  • the address of x-loader is 0x00000100 ⁇ 0x002000FF, and the size of 0x00000100 ⁇ 0x002000FF is 256KB;
  • AD1+1 is 0x000200FF offset by one storage bit, which is 0x00200100;
  • AD2 is the storage bit offset by 600KB from AD1 (0x002000FF), which is 0x006B00FF; the address of the bootloader is 0x00200100 ⁇ 0x006B00FF, and the size of 0x00200100 ⁇ 0x006B00FF is 600KB.
  • FIG. 2 is a schematic diagram of a data storage structure according to an embodiment of the present application. It is assumed that the partition structure of the version 2.0 operating system includes GPT partition, x-loader partition, bootloader partition, boot partition, A partition, vendor-boot partition, Super partition and Userdata partition.
  • AD21 and AD22 respectively represent different address strings.
  • AD21 is the storage bit offset by 32MB from AD3;
  • AD22 is the storage bit offset by 32MB from AD21.
  • the size of Super is reduced by 32MB.
  • the partition architecture of the operating system of version 1.0 corresponds to the partition architecture shown in Figure 1
  • the partition architecture of the operating system of version 2.0 corresponds to the partition architecture shown in Figure 2
  • the partition architecture shown in Figure 1 is different from the partition architecture shown in Figure 2. Therefore, in the process of upgrading the operating system on the device from version 1.0 to version 2.0, it is first necessary to reconfigure the partition structure on the device memory from the partition structure shown in FIG. 1 to the partition structure shown in FIG. 2 . That is, refresh the partition table saved in GPT from table 1 to table 2.
  • a feasible upgrading solution is to rewrite data to all operating system data partitions after refreshing the partition table.
  • FIG. 3 shows a flow chart of upgrading an operating system according to an embodiment of the present application.
  • the device performs the following process to upgrade the operating system from version 1.0 to version 2.0:
  • the operating system upgrade package includes the partition table shown in Table 2 and the corresponding bootloader partition, boot partition, A partition, vendor-boot of the version 2.0 operating system Mirror data of partitions and Super partitions;
  • FIG. 4 is a schematic diagram of a data storage structure according to an embodiment of the present application.
  • the Android system data storage area includes a basic partition (Common), a static partition (A), a static partition (B), a dynamic partition (Super), and a user data partition (Userdata).
  • Common basic partition
  • A static partition
  • B static partition
  • Super dynamic partition
  • Userdata user data partition
  • the user data partition (Userdata) is used to store the user's personal data, for example, personal data such as apps installed by the user, pictures, documents, and videos saved by the user.
  • the data saved in the basic part is system data that does not participate in the operating system upgrade.
  • the structures of static partition (A) and static partition (B) correspond to each other, and sub-partition names are distinguished from each other by suffixes _a and _b.
  • static partition (A) includes bootloader_a, boot_a, vendor_boot_a, dtbo_a, vbmeta_a
  • static partition (B) includes bootloader_b, boot_b, vendor_boot_b, dtbo_b, vbmeta_b.
  • the dynamic partition (Super) contains multiple sub-partitions (System, system_ext, vendor, product, Cust, Odm).
  • the device When the device boots, it starts from a static partition. For example, if the device starts from the static partition (A): load the basic partition (Common), static partition (A) and dynamic partition (Super) in sequence; the device starts from the static partition (B): load the basic partition (Common), static partition in sequence (B) and dynamic partition (Super).
  • A load the basic partition
  • A static partition
  • Super dynamic partition
  • UFS Universal Flash Storage
  • MBR Master Boot Record
  • A Start (the boot sequence is marked as A) or start from the static partition (B) (the boot sequence is marked as A).
  • the device boot sequence is first read from the MBR of UFS.
  • Fig. 5 shows the flow chart of upgrading the operating system for the operating system data storage structure of the embodiment shown in Fig. 4.
  • the device When the device is currently started from the static partition (A), the device implements the operation according to the flow shown in Fig. 5 System upgrades.
  • the device acquires an operating system upgrade package.
  • the device periodically initiates a packet search request to the packet search server, and the packet search request includes the version number (such as version 1.1) of the operating system currently running on the device; The version number of the operating system to search whether there is an operating system installation package with a newer version number (for example, version 1.2); 1.1 upgrade to the download address of the system incremental upgrade installation package of version 1.2); the device downloads the operating system upgrade package according to the download address of the operating system upgrade package.
  • version number such as version 1.1
  • the device performs a data writing operation on the static partition (B) according to the operating system upgrade package to upgrade the static partition.
  • the execution of S520 fails (static partition upgrade fails).
  • the device will interrupt the entire operating system upgrade operation, output an upgrade failure prompt to the user (for example, display an upgrade failure dialog box), and automatically re-upgrade or let the user determine whether to re-upgrade or give up the upgrade.
  • the system upgrade installation package from version 1.1 to version 1.2 includes the full data of the static partition of version 1.2 and the hash value of the full data of the static partition of version 1.2.
  • the device overwrites the full amount of data in the static partition of version 1.2 to the static partition (B).
  • the device calculates the hash value of the data in the static partition (B), and checks the hash value of the data in the static partition (B) with the static partition of version 1.2 in the system upgrade installation package from version 1.1 to version 1.2 Whether the hash value of the full amount of data is consistent. If they are consistent, it means that the data is written successfully, and the subsequent operating system upgrade operation can be performed; if they are not consistent, it means that the data writing fails, and the upgrade fails.
  • the system upgrade installation package from version 1.1 to version 1.2 includes the differential data of the static partition upgraded from version 1.1 to version 1.2, the hash value of the full data of the static partition of version 1.1, and the hash value of version 1.2 The hash value of the full amount of data in the static partition.
  • the device Before writing data to the static partition (B), the device first calculates the hash value of the data in the static partition (A), and checks the hash value of the data in the static partition (A) and the system upgrade from version 1.1 to version 1.2 Whether the hash values of the full data of the static partition of version 1.1 in the installation package are consistent, if they are consistent, it means that the data in the current static partition (A) is the static partition data of version 1.1, and the difference between the static partition of version 1.1 and version 1.2 The data is available; if it is not consistent, the differential data of the static partition that is upgraded from version 1.1 to version 1.2 is not available, and the upgrade fails.
  • the device After the device determines that the differential data of the static partition upgraded from version 1.1 to version 1.2 is available, read the data in the static partition (A), use the differential data of the static partition upgraded from version 1.1 to version 1.2 and the data in the static partition (A) to execute Restore the full amount of data in the static partition of version 1.2, and overwrite the full amount of data in the static partition of version 1.2 into the static partition (B).
  • the device calculates the hash value of the data in the static partition (B), and checks the hash value of the data in the static partition (B) with the static partition of version 1.2 in the system upgrade installation package from version 1.1 to version 1.2 Whether the hash value of the full amount of data is consistent. If they are consistent, it means that the data is written successfully, and the subsequent operating system upgrade operation can be performed; if they are not consistent, it means that the data writing fails, and the upgrade fails.
  • the system upgrade installation package from version 1.1 to version 1.2 contains the following data:
  • boot partition name, indicating that the current data is the upgrade data pointing to the sub-partition boot of the static partition
  • HASH11 (the hash value of the data of the sub-partition boot of the static partition of version 1.1)
  • Image target hash value HASH12 (the hash value of the data of the sub-partition boot of the static partition of version 1.2)
  • DELTA1 Differential data of static partitions upgraded from version 1.1 to version 1.2
  • the device reads the fixed mounting path of the device through the misc partition in the common partition, such as /dev/block/by-name/misc. Read the card slot (slot-b) from the UFS device, and replace it with a sub-partition path, such as /dev/block/by-name/boot_b.
  • the device first calculates the hash value of the data under /dev/block/by-name/boot_a, and checks the hash value and hash value of the data under /dev/block/by-name/boot_a Whether HASH11 is consistent, if consistent, DELTA1 is available, if not, the upgrade operation fails.
  • the device When the hash value of the data under /dev/block/by-name/boot_a is consistent with the hash value HASH11, the device reads DELTA1 based on Start:12222 and size:2410, and uses DELTA1 and /dev/block/by-name/ The data under boot_a is restored to obtain the full data of the sub-partition boot of the static partition of version 1.2. The device writes the full data of the subpartition boot of the static partition of version 1.2 to /dev/block/by-name/boot_b.
  • the device calculates the hash value of the data under /dev/block/by-name/boot_b, and checks whether the hash value of the data under /dev/block/by-name/boot_b is consistent with the hash value HASH12. If they are consistent, the sub-partition boot of the static partition is upgraded successfully, and the sub-partition of the next static partition can be upgraded; if they are inconsistent, the upgrade operation fails.
  • the device upgrades the sub-partitions of the static partition according to the static partition sub-partition upgrade data contained in the system upgrade installation package. Specifically, if the system upgrade installation package contains the sub-partition upgrade data of a static partition, the The upgrade process of the above boot sub-partition upgrades the sub-partition in the static partition (B). If the system upgrade installation package does not contain the sub-partition upgrade data of a certain static partition, the Data is directly synchronized to this subpartition in the static partition (B). During the upgrade process, when an upgrade error occurs in a sub-partition and the hash verification fails, the upgrade operation is interrupted and the upgrade fails; when all sub-partitions are upgraded successfully, the static partition is upgraded successfully, and the next steps can be performed.
  • static partitions have corresponding status flags (bootable or unbootable).
  • the device first reads the static partition status flag before loading the static partition data, and loads the data of the static partition only when the status of the static partition is marked as bootable. Before upgrading the data of the static partition, the static partition will be marked as unbootable. After the data of the static partition is successfully upgraded, the static partition will be marked as bootable. In this way, if the static partition fails to be upgraded, the status of the static partition will remain at Unable to start. The device will not load the data of the static partition that fails to be upgraded.
  • S520 before upgrading the data of the static partition (B), mark the static partition (B) as unbootable. Specifically, the state flag of the static partition is stored in the Common partition.
  • S520 before upgrading the data of the static partition (B), mark slot-b in the state flag of the static partition in the Common partition as unbootable.
  • S520 is successfully executed (when all hash checks are successful), mark the static partition (B) as bootable.
  • the device creates a virtual dynamic partition in the user data partition (Userdata) according to the operating system upgrade package, and writes upgrade data of the dynamic partition (Super) in the virtual dynamic partition.
  • the operating system upgrade package contains the data of the dynamic partition of version 1.2, and the device writes the data of the dynamic partition (Super) of version 1.2 in the virtual dynamic partition.
  • an incremental upgrade method is adopted for the dynamic partition (Super).
  • the virtual dynamic partition of the user data partition (Userdata) does not save all the files of the new version of the dynamic partition (Super) after the upgrade, but the data that needs to be upgraded in the old version of the dynamic partition (Super).
  • the result of the upgrade after the upgrade That is, what is stored in the virtual dynamic partition of the user data partition (Userdata) is 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 has not changed, and the data syetem1 has been upgraded to system3.
  • the device creates a virtual dynamic partition in the user data partition (Userdata), and writes data system3 into the virtual dynamic partition.
  • the system incremental upgrade installation package from version 1.1 to version 1.2 includes dynamic partition (Super) update data from version 1.1 to version 1.2
  • the dynamic partition (Super) update data includes data system3.
  • the incremental upgrade of the dynamic partition (Super) is realized based on the snapshot technology (snapshot).
  • snapshot technology snapshot technology
  • COW Copy-On-Write
  • the upgrade data of the dynamic partition (Super) stored in the user data partition (Userdata) contains multiple COW files, and each COW file corresponds to a sub-partition of the dynamic partition (Super).
  • Partition (Super) corresponds to sub-partition.
  • 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 sub-partition of the dynamic partition (Super).
  • the COW file for the system subpartition is named system-cow-img.img.0000.
  • the device unpacks the operating system upgrade package to obtain all COW files, and attaches an A/B partition mark to each COW file.
  • the dynamic partition (Super) loaded by the operating system currently running on the device is the dynamic partition (A).
  • the virtual dynamic partition created in the user data partition (Userdata) is for the dynamic partition (B). Therefore, the name mark _b corresponding to the dynamic partition (B) is appended to the COW file. For example, append_b for system-cow-img.img.0000 generates system_b-cow-img.img.0000.
  • an Update folder is created in the user data partition (Userdata), and the renamed COW file is saved in the Update folder.
  • the Update folder of the user data partition (Userdata) contains the following files:
  • the COW file includes a COW file map (snapshot map) and upgrade data of the COW file itself.
  • the COW file map (snapshot) 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 dynamic partition (Super) and the storage address of each file in the current version of the operating system (the version before this upgrade, for example, version 1.1) .
  • the upgrade data in the COW file is the updated file in the sub-partition data of the new version compared with the sub-partition data of the current version; the COW file map of the COW file itself is used to describe the updated file and the sub-partition of the current version The correspondence between the files in and the storage address of the updated files.
  • the upgrade data in the COW file can be used to replace the corresponding file in the sub-partition of the dynamic partition (Super), thereby realizing the dynamic partition (Super) ) data upgrade.
  • a snapshot operation may be performed on the data of the sub-partition of the dynamic partition (Super) based on the snapshot to generate the file map of the sub-partition of the dynamic partition (Super). It is also possible to pre-generate the file map of the sub-partition of the dynamic partition (Super) when making the operating system 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 sub-partition of the dynamic partition (Super).
  • /system/app/A2.XXX and /system/user/C2.XXX are the system1 part of the system sub-partition data
  • the COW file (system_b-cow-img.img.0000) for the system subpartition contains the latest versions of /system/app/A2.XXX and /system/user/C2.XXX.
  • the COW file map of the COW file (system_b-cow-img.img.0000) itself can be:
  • Map1 (the address of the data to be updated in the original super partition): start address address start: 024018 (the offset relative to the system start address); offset size: 2 (that is, the data in the address segment of 024018 ⁇ 024020)
  • Map2 (the address of the updated data stored in the cow file): start address address start: 045033 (the offset relative to the start address stored in the cow file); offset size: 2 (that is, the address segment of 045033 to 045035 The data);
  • Map1 (the address of the data to be updated in the original super partition): start address address start: 024036 (the offset relative to the system start address); offset size: 4 (that is, the data in the address segment 024036 ⁇ 024040)
  • Map2 (the address of the update data stored in the cow file): start address address start: 045036 (offset relative to the start address stored in the cow file); offset size: 4 (that is, the address segment of 045036 ⁇ 045040 The data);
  • the values after the file name (045033 ⁇ 045035 and 045036 ⁇ 045040) are respectively the latest versions of /system/app/A2.XXX and /system/user/C2.XXX in the COW file (system_b-cow-img.img.0000)
  • the flush status information is used to indicate whether there are currently COW files that need to be flushed to the dynamic partition (Super).
  • the disk placement status information includes an overall identifier for the dynamic partition (Super) and a sub-partition identifier for each sub-partition.
  • the device not only writes the COW file to the user data partition (Userdata), but also refreshes the partition information in the metadata of the dynamic partition (Super).
  • FIG. 6 is a schematic diagram of a framework structure of a burning system for performing system burning before a device leaves the factory in an application scenario.
  • the metadata (/supermetadata) at the head of the dynamic partition (Super) includes Slot0 (slot 1 data) corresponding to the static partition (A) And Slot1 (slot two data) of the static partition (B). Slot0 and Slot1 are used to save the partition table of the Super partition.
  • configuring Slot0 corresponds to booting from the static partition (A)
  • configuring Slot1 corresponds to booting from the static partition (B).
  • the device selects to obtain the partition information of the Super partition from Slot0 or Slot1 according to the static partition to be started. For example, when the device is started from the static partition A, when loading the Super partition, the device first reads Slot0 to obtain the sub-partition address of the Super partition; when the device is started from the static partition B, when loading the Super partition, the device first reads Take Slot1 to obtain the sub-partition address of the Super partition.
  • Slot0 and Slot1 include multiple sub-partition description groups, and each sub-partition description group corresponds to a sub-partition of the Super partition.
  • Each subpartition description group contains:
  • Name (Name) item its value is the name of the sub-partition
  • Group (Group), whose value is the sub-partition type
  • Attributes item its value is partition read-write attribute, for example, read-only attribute (readonly);
  • Address (Extents) item its value is the address of the sub-partition (for example, partition size, offset).
  • the suffix of the value is _a, which corresponds to the static partition (A); the suffix of the value is _b, which corresponds to the static partition (B).
  • Slot0 When starting from static partition A and loading the Super partition, Slot0 is first read.
  • the device When reading Slot0, since the suffix _a corresponds to the static partition (A), the device reads the value of the Extents item in the partition description group whose Name item and/or Group item suffix is _a in Slot0 to obtain the sub-partition of the Super partition. partition address.
  • Slot1 When booting from static partition B and loading the Super partition, Slot1 is first read. When reading Slot1, since the suffix _b corresponds to the static partition (B), the device reads the value of the Extents item in the partition description group with the suffix _b in the Name item and/or Group item in Slot0 to obtain the sub-partition of the Super partition. partition address.
  • the operating system upgrade package acquired by S510 contains the partition information of the dynamic partition (Super) of version 1.2.
  • the device extracts the partition information of the dynamic partition (Super) of version 1.2 from the operating system upgrade package, and uses The partition information of the dynamic partition (Super) of the version refreshes the partition information in Slot1 corresponding to the static partition (B).
  • the partition information of the dynamic partition (Super) of version 1.2 includes the following content:
  • the device locates the static partition (B) through the current static partition that needs to be upgraded to Slot 1 of /supermetadata of the dynamic partition (Super) corresponding to the static partition (B), and uses the partition of the dynamic partition (Super) of version 1.2 Information refreshes the content in Slot 1.
  • Slot 1 of /supermetadata in the dynamic partition (Super) contains the following content:
  • the execution of S530 may fail.
  • the device will interrupt the entire operating system upgrade operation, output an upgrade failure prompt to the user (for example, display an upgrade failure dialog box), and automatically re-upgrade or let the user determine whether to re-upgrade or give up the upgrade. (Refer to the static partition data write failure in S520)
  • S530 when the storage space of the user data partition (Userdata) is insufficient, the execution of S530 will fail.
  • the size of the virtual dynamic partition is determined by the data size of the dynamic partition of version 1.2 in the operating system upgrade package.
  • execution of S530 fails.
  • the device extracts the COW file from the operating system upgrade package and writes the COW file into the Update folder of the user data partition (Userdata).
  • the operating system upgrade package contains the content and size of the COW file.
  • the device first creates an empty COW file under the Update folder of the user data partition (Userdata) according to the name of the cow file and the size of the COW file in the operating system upgrade package, and then extracts the data of the COW file from the operating system upgrade package and writes it to Empty COW file.
  • the COW file for the system subpartition is named system-cow-img.img.0000, and the size of system-cow-img.img.0000 is XXXX.
  • the device creates a system_b-cow file under the Update folder of the user data partition (Userdata).
  • the size of the system_b-cow file is XXXX and the content is empty.
  • the device can extract system-cow-img.img.0000 from the system upgrade installation package, write it into system_b-cow and rename it to system_b-cow-img.img.0000.
  • the device creates empty COW files system_b-cow, system_ext_b-cow, vendor_b-cow, product_b-cow, cust_b-cow, and odm_b-cow under the Update folder of the user data partition (Userdata). After all the empty COW files are created, the device can extract the COW file data from the system upgrade installation package, write the empty COW files and rename them.
  • the Update folder of the end user data partition contains the following files:
  • the device creates an empty COW file each time, and creates the next one after one empty COW file is successfully created.
  • an empty COW file fails to be created, it means that the storage space of the user data partition (Userdata) is insufficient, the execution of the S530 fails, and the upgrade of the operating system fails.
  • the failure to extract the COW file will also cause the execution failure of S530.
  • the COW file is saved in the form of binary code.
  • Userdata When writing the COW file into the user data partition (Userdata), it is first necessary to extract the COW file from the operating system upgrade package, open the COW file, and COW file data is written to the user data partition (Userdata).
  • the operating system upgrade package has data errors and the COW file cannot be extracted or opened, the execution of the S530 will fail, and the operating system upgrade will fail.
  • the failure to write the COW file will also cause the execution failure of S530.
  • the COW file In order to check whether the writing of the COW file is successful, in S530, after writing the COW file into the user data partition (Userdata), it is also necessary to perform an overall verification of the dynamic partition (Super) + COW file, and verify the dynamic partition (Super) + The validity of the COW file, verify whether the synthesis result of the current version of the dynamic partition (Super) data + the COW file is the new version of the dynamic partition (Super) data.
  • the dynamic partition (Super)+COW file is merged based on the snapshot.
  • the merging of the dynamic partition (Super) and the COW file is not a physical merging, but the overall file map of the system sub-partition is merged with the COW file map of the COW file itself to generate a new version File map of subpartitioned data.
  • the storage 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 A2.XXX in system_b-cow-img.img.0000 in the data partition (Userdata); the storage address of /system/user/C2.XXX does not point to /system/user/C2 on the dynamic partition (Super) on the storage .XXX, but points to C2.XXX in system_b-cow-img.img.0000 in the user data partition (Userdata) on the storage.
  • the new version of the file map of all sub-partitions of the dynamic partition (Super) is obtained (if the corresponding COW file of a certain sub-partition is not written in the user data partition (Userdata), directly Use the filemap of the subpartition as the new version's filemap). Combine the new version of the file map of all subpartitions to generate the new version of the file system of the dynamic partition (Super).
  • the file system of the new version based on the dynamic partition (Super) reads data, reads all files contained in the file system of the new version of the dynamic partition (Super), and calculates a hash value.
  • the boot sequence identifier of the Master Boot Record For example, rewrite the boot sequence identifier of the Master Boot Record (MBR), and rewrite the boot sequence identifier from A to B.
  • MLR Master Boot Record
  • the device After the device is powered on, when the device reads the boot sequence ID as A, the device starts from the static partition (A), and loads the static partition (A) during startup; when the device reads the boot sequence ID as B, the device starts from the static partition (A). Partition (B) starts, and static partition (B) is loaded during startup.
  • slot-b in the state flag of the static partition in the Common partition is also marked as bootable.
  • the device sequentially loads the basic partition (Common) and the static partition (B).
  • the device loads the dynamic partition (Super) and the virtual dynamic partition of the user data partition (Userdata).
  • the device reads the storage status information in the metadata (/metadata), determines whether to retrieve the COW file from the specified path of the user data partition (Userdata) based on the storage status information, and uses snapshot to merge and load the dynamic partition ( Super) and COW files.
  • the device does not load all the COW files in the dynamic partition (Super) and the user data partition (Userdata), but loads corresponding files according to operating requirements of the operating system. Specifically, in S541, the device determines the files to be loaded according to the operation requirements of the operating system, and extracts corresponding files from the COW files in the dynamic partition (Super) or virtual dynamic partition based on the snapshot for loading.
  • S541 when there is a corresponding COW file in the first sub-partition of the dynamic partition (Super), first generate a new version of the file map of each sub-partition of the dynamic partition (Super) based on the snapshot. For the process of generating a file map of a new version, reference may be made to S530.
  • the device determines the files to be loaded according to the operation requirements of the operating system, and loads the files based on the file map of the new version of the dynamic partition (Super) sub-partition.
  • the operating system needs to load all the data in the directory user (/system/user) under the system subpartition.
  • the device reads the migration status information in the metadata (/metadata), and the subpartition of the system subpartition in the migration status information is marked as "wait for merge". Therefore, the device is in the user data partition (Userdata) Search for COW files under Medium/Update. After searching for the COW file system_b-cow-img.img.0000 under Update, generate a system sub-partition based on the snapshot and according to the file map of the COW file in system_b-cow-img.img.0000 The new version of the file map. 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:
  • the device when loading all the data in the directory user (/system/user) under the system subpartition, when the subpartition of the system subpartition in the storage status information is marked as "merged", the device will not Search for COW files under /Update in the user data partition (Userdata), but directly load all the data in the directory user (/system/user) under the system subpartition.
  • the device before loading the file, the device needs to verify the loaded file.
  • 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, verify based on dmverity (dm-verity is a target of dm (device mapper), which is a virtual block device, specially used for file system verification). If the verification is successful, load the file; if the verification fails, restart the device, roll back the system or try to load the file again.
  • dmverity is a target of dm (device mapper), which is a virtual block device, specially used for file system verification.
  • the device puts the data of the virtual dynamic partition to the dynamic partition (Super).
  • the disk operation refers to writing the dynamic partition (Super) upgrade file (COW file) stored in the virtual dynamic partition on the user data partition (Userdata) into the In the dynamic partition (Super), the files of the dynamic partition (Super) are upgraded, so that the device does not need to load the dynamic partition (Super) and the virtual dynamic partition at the next startup, and only needs to load the dynamic partition (Super) to complete the device. start up.
  • COW file dynamic partition upgrade file
  • the device After the device is successfully started, it performs a power-on broadcast, and starts an upgrade process after the power-on broadcast.
  • the upgrade process reads the migration status information in the metadata (/metadata) of the basic partition (Common). If the migration status information is "merged", the device enters the normal operation mode.
  • the upgrade process will put the COW files 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) are the new data after the upgrade. Version data.
  • the data at addresses 045033-045035 Write to addresses 024014-024017; based on /system/user/C2.XXX: 024036-024040 in the file map of the system subpartition and /system/user/C2.XXX: 045036-045040 in the COW file map, the Data at addresses 045036 to 045040 are written to addresses 024036 to 024040.
  • the upgrade process deletes the COW file in the user data partition (Userdata), returns the storage space to the user data partition (Userdata); Changed from "wait for merge” to "merged".
  • the data operation of the static partition upgrade is aimed at the operating system data in the static partition (B), and it will not affect the operating system data of the currently started static partition (A); and, in S530, 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 whole process of upgrading the operating system, the user can use the device normally; and, after the completion of S531, the device does not need to be restarted immediately, and the user can choose the restarting time; in this way, the upgrading process of the operating system will not affect the The user's normal mobile phone operation is affected, thereby greatly improving the user experience. Further, for the dynamic partition (Super), a virtual dynamic partition will be created on the user data partition (Userdata) only when an upgrade is required, thus effectively improving the utilization rate of data storage space.
  • FIG. 7 is a schematic diagram of a data storage structure according to an embodiment of the present application. If the partition structure shown in Figure 4 needs to be reconfigured, for example, sub-partitions A_a and A_b are added to the static partition (A) and static partition (B) respectively to obtain the data storage structure shown in Figure 7, it is necessary Refresh the partition table stored in the disk header (for example, MBR partition or GPT partition) of the memory of the device to the partition table corresponding to the data storage structure shown in Figure 7 (the original partition table is corresponding to the partition structure shown in Figure 4 partition table).
  • the partition table stored in the disk header for example, MBR partition or GPT partition
  • the device completes the operating system data upgrade when the operating system is running; and when the operating system is running normally, the partition table of the disk head of the memory is read-only, therefore, according to the figure The upgrade process shown in 5 cannot complete the refresh of the partition table.
  • the operating system upgrade package is stored in the user data partition (Userdata).
  • the operating system upgrade package includes the partition table and the data storage structure shown in Figure 7 Mirror data of each partition in the data storage structure shown in 7.
  • the device enters Recovery mode, reads the operating system upgrade package saved in the user data partition (Userdata) in Recovery mode, uses the partition table in the operating system upgrade package to refresh the partition table in the disk MBR, Locate each partition based on the refreshed partition table, and restore the image data of each partition in the operating system upgrade package to each partition.
  • the data stored in the user data partition (Userdata) is encrypted, and the user data partition (Userdata) can only be partitioned when the Android system is running normally.
  • Userdata to access the data stored in. That is to say, when the device restarts and enters the recovery (Recovery) mode, it cannot access the data saved in the user data partition (Userdata). In this way, the device cannot reconfigure the partition structure and rewrite data for each newly configured partition in the recovery (Recovery) mode.
  • the present application proposes an operating system upgrade method combining virtual A/B upgrade and recovery (Recovery) mode upgrade. First refresh the partition table in Recovery mode to reconfigure the partition structure, then start the operating system, and use the virtual A/B upgrade method to upgrade the operating system data.
  • this application proposes a new operating system partition architecture.
  • the partition architecture of an embodiment of the present application not all the space of the disk is created as an available partition, but a part of the space is reserved as a reserved partition.
  • the reserve partition is an unavailable partition, which is not reflected in the available partition of the device when the device is running. That is, assuming that the partition structure corresponding to the operating system is shown in Figure 4, if the device has a reserve partition configured on the memory, the device will run When operating the system, the available partitions are still shown in Figure 4, and the reserve partition is not shown.
  • FIG. 8 is a schematic diagram of a partition structure of a reconfigured partition architecture according to an embodiment of the present application.
  • the partition architecture shown in FIG. 4 is mapped to a part of storage space allocation on the memory as shown in the left diagram of FIG. 8 .
  • the partition table corresponding to the left figure in Figure 8 is shown in Table 3:
  • AD31-AD38 respectively represent different address strings.
  • XX is the partition size, and XX of different partitions can be the same or different.
  • the above process is reversed, and the deleted partition is configured as a new reserve partition.
  • a method of splitting a single reserve partition and/or merging multiple reserve partitions may be used, a part of a reserve partition may be cut to create a new partition, or multiple reserve partitions may be merged to create a new partition.
  • Fig. 9a is a flow chart of operating system upgrade according to an embodiment of the present application.
  • the device performs as shown in Figure 9a to implement an operating system upgrade that includes partition architecture reconfiguration.
  • the device loads the basic partition (Common), static partition (A) and dynamic partition (Super) in sequence, and starts from the static partition (A).
  • the operating system upgrade package contains the partition table of the partition structure corresponding to the latest version of the operating system and the operating system upgrade data.
  • For the specific content of the operating system upgrade data refer to the content of the operating system upgrade package in the upgrade process shown in FIG. 5 .
  • the partition table included in the operating system upgrade package is the same as the address of the partition with the same name on the current partition table on the device storage.
  • the partition structure corresponding to the current operating system (version 1.0) of the device is shown in FIG. 4
  • the partition structure corresponding to the latest version of the operating system (version 2.0) is shown in FIG. 7 .
  • the current partition structure includes not only the partitions and sub-partitions shown in Figure 4, but also the reserve partition.
  • Part of the current partition table of the device is shown in Table 3.
  • a part of the partition table included in the operating system upgrade package is shown in Table 4.
  • the operating system upgrade data includes data of the sub-partition A of the static partition.
  • the operating system upgrade data is usually packaged as update_base.zip.
  • the device while obtaining the operating system upgrade package, the device also obtains a description file (filelist file) for the operating system upgrade package.
  • the filelist file is used to describe the relevant information of update_base.zip.
  • the filelist file includes update_base. The version number of the operating system targeted by the zip, the hash value of update_base.zip, etc.
  • update_base.zip contains the partition table of the partition structure corresponding to the latest version of the operating system.
  • update_ptable.zip (package according to the update_base.zip package type), update_ptable.zip is signed, typed into update_base.zip, and then signed as a whole.
  • Fig. 9b is a schematic diagram showing the composition of internal files of an operating system upgrade package according to an embodiment of the present application.
  • update_ptable.zip packages the partition table image (update_ptable.zip) in the root directory.
  • ptable.img is the partition table image file.
  • the operating system upgrade package including the partition table is configured as a key node package, and during the process of operating system upgrade, the key node package cannot be skipped in the cross-version upgrade operation. That is, the device must first upgrade the operating system (reconfigure the partition structure) based on the key node package before upgrading to an operating system of a version later than the key node package.
  • operating systems prior to version 2.0 correspond to the partition structure shown in FIG. 4 .
  • the operating system corresponds to the partition structure shown in Figure 7.
  • the operating system upgrade package of the version 2.0 operating system is a key node package.
  • the device cannot be directly upgraded to the version 2.1 operating system, but must first be upgraded to the version 2.0 operating system based on the version 2.0 operating system upgrade package (reconfigure the partition
  • the structure is the partition structure shown in Figure 7), in order to continue to upgrade to version 2.1.
  • update_base.zip does not contain the partition table, and this operating system upgrade does not need to update the partition table, execute S912, and perform operating system upgrade based on the operating system upgrade data (update_base.zip) in the operating system upgrade package, S912 For the execution, refer to S520-S551.
  • S921 upgrade the operating system based on the operating system upgrade data (update_base.zip) in the operating system upgrade package, and refer to S520-S551 for execution of S921.
  • the operating system using the virtual A/B upgrade scheme can be upgraded and the partition table of the device memory can be updated during the upgrade process.
  • the upgrade scheme of the embodiment of the present application greatly simplifies the operation difficulty of updating the device partition table and improves user experience.
  • the operating system that adopts the virtual A/B upgrade scheme can be upgraded and the partition table of the device memory can be updated during the upgrade process; according to the method of the embodiment shown in Figure 9a, there is no need to prepare for burning recording tool, the device can complete the update of the partition table by itself based on the downloaded operating system upgrade package; the method according to the embodiment shown in Figure 9 greatly simplifies the operation difficulty of updating the device partition table and improves the user experience.
  • the operation upgrade operation is completed by an operating system update program installed on the device.
  • an update package acquisition tool update apk clent
  • an update engine update engine
  • the upgrade package acquisition tool is used to obtain the upgrade installation package of the operating system, download and save the upgrade package of the operating system to the user data partition (Userdata). Refer to S210.
  • the update package acquisition tool (update apk clent) periodically initiates a package search request to the package search server.
  • the package search request includes information such as the current operating system version number of the device (such as version 1.1), the SN number of the device, the product model, and the standard (such as version 1.1); the search package server retrieves whether there is an operating system installation package (such as version 1.2) with a newer version number on the installation package server according to the operating system version number in the package search request; when there is a newer version of the operating system installation package, search The package server feeds back the download address (for example, URL address) of the operating system upgrade package (for example, the operating system upgrade package upgraded from version 1.1 to version 1.2) and the filelist corresponding to the system upgrade installation package to the update package acquisition tool (update apk clent) file; the upgrade package acquisition tool (update apk clent) downloads the operating system upgrade package from the installation package server according to the download address of the operating system upgrade package.
  • the upgrade package acquisition tool obtains the operating system upgrade package, it starts the update engine (update engine), and the update engine (update engine) performs the upgrade of the operating system according to the operating system update package.
  • the update package acquisition tool (update apk clent) obtains the operating system upgrade package
  • the update package acquisition tool (update apk clent) sets the startup attribute of the update engine (update engine), and the startup attribute is set to true.
  • the service servicemanger of resident operating system backstage can monitor the startup attribute of upgrade engine (update engine) 302, when servicemanger detects that the startup attribute of upgrade engine (update engine) is true, servicemanger starts upgrade engine (update engine).
  • the update package acquisition tool obtains the status of the update engine (update engine) through binder communication. clent) transmits upgrade parameters to the update engine (for example, whether the current upgrade operation is a file update operation or a file storage operation), and triggers the update engine to enter the upgrade process.
  • upgrade parameters for example, whether the current upgrade operation is a file update operation or a file storage operation
  • FIG. 10 shows a flow chart of operating system upgrade according to an embodiment of the present application.
  • the device executes as shown in Figure 10 to implement an operating system upgrade that includes partition architecture reconfiguration.
  • the upgrade server pushes and releases the latest version of an operating system upgrade package for updating the partition table.
  • the device loads the basic partition (Common), static partition (A) and dynamic partition (Super) in sequence, and starts from the static partition (A).
  • S1000 may be executed after the device is started, or may be executed before the device is started.
  • update apk clent executes S1010 to obtain the operating system upgrade package.
  • the process of obtaining the operating system upgrade package can refer to S910.
  • the update apk clent detects whether the filelist file for the operating system upgrade package contains a partition upgrade package flag. Refer to S911.
  • the filelist file for the operating system upgrade package contains the partition upgrade package mark.
  • Execute S1012 the update apk clent determines whether the operation of updating the partition table has been performed by using the operating system upgrade package. In the currently executing S1012, the update apk clent determines that the operation of updating the partition table has not been performed using the operating system upgrade package. Therefore, execute S1013, update apk clent executes partition table update preparation operation.
  • the update apk clent After the update apk clent completes the partition table update preparation operation, execute S1014, the update apk clent triggers the device to restart (the first restart), and the restarted device enters the Recovery mode.
  • the device uses the partition table in the operating system upgrade package to update the partition table on the device storage.
  • the update apk clent executes S1012 again to determine whether the operation of updating the partition table has been performed by using the operating system upgrade package.
  • the update apk clent determines that the operation of updating the partition table has been performed by using the operating system upgrade package. Therefore, the update apk clent executes S1030, triggering the update engine to enter the upgrade process.
  • the update engine executes S1031 to verify the operating system upgrade package. Specifically, verify whether the digital signature of the operating system upgrade package is legal, and confirm whether the operating system upgrade package is a legal upgrade package.
  • the update engine executes S1032 to update the data of the static partition and the dynamic partition according to the operating system upgrade package, refer to S520, S530 and S531 for details.
  • the update engine executes S1033, and returns status information that the upgrade operation is completed to the update apk clent.
  • the update apk clent triggers the device to restart (the third restart), for example, prompting the user with a pop-up box, and the user can choose to restart immediately or restart later.
  • the update apk clent executes S1041, and the update apk clent triggers the update engine to enter the merge process.
  • the update engine executes the merge process, refer to S551. After the merge process is complete, the operating system of the device is upgraded.
  • FIG. 11 shows a partial flow chart of operating system upgrade according to an embodiment of the present application.
  • an upgrade package acquisition tool acquires the operating system upgrade package and the filelist file. After that, S1011 to S1014 execute the following steps as shown in FIG. 11 .
  • the update package acquisition tool (update apk clent) parses the filelist file, and judges whether the filelist file contains a partition upgrade package sign;
  • the device performs an operating system upgrade according to the operating system upgrade package. Specifically, the update package acquisition tool (update apk clent) starts the update engine (update engine), and the update engine (update engine) upgrades the static partition (B) and the dynamic partition according to the operating system upgrade package, and restarts the device from the static partition (B) Start, and the upgrade package acquisition tool (update apk clent) starts the upgrade engine (update engine) to perform disk operation.
  • the update package acquisition tool update apk clent starts the update engine (update engine)
  • the update engine upgrades the static partition (B) and the dynamic partition according to the operating system upgrade package, and restarts the device from the static partition (B) Start
  • the upgrade package acquisition tool update apk clent starts the upgrade engine (update engine) to perform disk operation.
  • the update package acquisition tool determines whether the partition table has been updated.
  • the update package acquisition tool judges whether the partition table has been updated according to the state of the partition update flag (ptable oeminfo) stored in the metadata (/metadata) of the common partition.
  • the upgrade package acquisition tool (update apk clent) performs the partition table update preparation operation, and the partition table update preparation operation (ie S1013) includes S1110 ⁇ S1111:
  • CMD command command
  • update_ptable.zip contains the partition table image ptable.img and the hash value H1 of ptable.img.
  • the command command is written, and the command command includes the execution process identifier (Process1) pointing to the process (1).
  • Process (1) includes the following steps:
  • ptable0 and ptable1 have the same partition address start position-end position of all partitions with the same name, use ptable.img to update the current partition table on the device memory (update ptable0 to ptable1);
  • update apk clent completes the partition table update preparation operation. Then update apk clent executes S1112, records breakpoints, and records the current upgrade progress of the operating system. After the device restarts and enters the operating system, the operating system upgrade operation starts from S1102.
  • update apk clent completes the partition table update preparation operation, and update apk clent triggers the device to restart (the first restart). Specifically, update apk clent executes S1113, and a dialog box pops up, prompting the user to restart the device for the current operating system upgrade .
  • S1010, S1100, S1110, S1111, and S1112 can all be executed in the background when the user is using the mobile phone normally.
  • FIG. 12 is a schematic diagram of a mobile phone running interface according to an embodiment of the present application.
  • the mobile phone After the mobile phone successfully starts the operating system, it enters the system interface shown in 1201 in FIG. 12 .
  • the mobile phone performs operating system upgrade (execute S1010, S1100, S1110, S1111 and S1112), and the display interface of the mobile phone can be the interface shown in 1202 in FIG. 12, so as to show the progress of the operating system upgrade to the user.
  • the execution of S1010, S1100, S1110, S1111, and S1112 can also run in the background of the system.
  • the mobile phone when the mobile phone needs to be restarted, the mobile phone outputs a restart prompt to the user, and the user confirms whether to restart immediately.
  • FIG. 13 is a schematic diagram of a mobile phone running interface according to an embodiment of the present application.
  • the mobile phone currently displays an interface as shown at 1202 in FIG. 12 to show the user the progress of the operating system upgrade.
  • the mobile phone displays an interface as shown in 1303 in FIG. 13, and the user confirms whether to restart immediately or to restart later.
  • the mobile phone currently displays an interface as shown at 1203 in FIG. 12 , and the user uses a chat application.
  • the mobile phone displays an interface as shown in 1301 in FIG. 13, and pops up a notification.
  • the user clicks on the prompt notification to enter the interface shown as 1303 in FIG. 13 , and the user confirms whether to restart immediately or to restart later.
  • the user opens the pull-down notification bar, and the mobile phone displays an interface as shown at 1302 in FIG. 13 .
  • the drop-down notification bar the user clicks the prompt notification to enter the interface shown as 1303 in FIG. 13 , and the user confirms to restart immediately or to restart later.
  • S1120 that is, S1014.
  • S1120 that is, S1014
  • the device is restarted, and the restarted device enters a recovery (Recovery) mode.
  • S1113 if the user clicks the later button, S1121 is executed, the device suspends the upgrade process, and restarts the upgrade process at the preset timing upgrade node. After the upgrade process starts, the device restarts, and the restarted device enters recovery (Recovery) mode.
  • FIG. 14 is a partial flow chart of operating system upgrade according to an embodiment of the present application. After S1120 or S1121, the device reboots into a recovery (Recovery) mode, and in the recovery (Recovery) mode, the device executes the process shown in FIG. 14 .
  • S1020-S1021 include:
  • the device parse and obtain the execution process identifier (Process1) pointing to the process (1) in the command command.
  • the execution process identifier (Process1)
  • the pre-stored execution code corresponding to the execution process of Process1 (process (1)) is called, and the execution code of the process (1) is executed to realize the process (1).
  • the device verifies the hash value of the mounted ptable.img; verifies whether ptable.img is available after the verification is passed; refreshes the original partition table on the device storage when ptable.img is available; refreshes successfully Then reboot the device (second reboot).
  • the device loads the basic partition (Common), the static partition (A) and the dynamic partition (Super), and starts from the static partition (A).
  • the device loads the breakpoint saved in S1112, continues the operating system upgrade operation from S1102, and executes S1102 again.
  • the update package acquisition tool determines whether the partition table has been updated.
  • S1101 that is, S1030
  • the device upgrades the operating system according to the operating system upgrade package.
  • FIG. 15 is a flow chart of operating system upgrade according to an embodiment of the present application. The device executes as shown in Figure 15 to implement an operating system upgrade that includes partition architecture reconfiguration.
  • the upgrade server pushes and releases the latest version of an operating system upgrade package for updating the partition table.
  • the device loads the basic partition (Common), static partition (A) and dynamic partition (Super) in sequence, and starts from the static partition (A).
  • S1500 may be executed after the device is started, or may be executed before the device is started.
  • update apk clent executes S1510 to obtain the operating system upgrade package.
  • the process of obtaining the operating system upgrade package can refer to S910.
  • the update apk clent triggers the update engine to enter the upgrade process.
  • the update engine executes S1520 to verify the operating system upgrade package. Specifically, verify whether the digital signature of the operating system upgrade package is legal, and confirm whether the operating system upgrade package is a legal upgrade package.
  • the update engine executes S1521 to detect whether the filelist file for the operating system upgrade package contains the partition upgrade package mark. Refer to S911.
  • the filelist file for the operating system upgrade package contains the partition upgrade package mark.
  • the update engine judges whether the operation of updating the partition table has been performed by using the operating system upgrade package. In currently executing S1522, the update engine determines that the operation of updating the partition table has not been performed using the operating system upgrade package. Therefore, S1523 is executed, and the update engine performs partition table update preparation operations.
  • the update engine executes S1524, and returns the status information of the completion of the partition table update preparation operation to the update apk clent.
  • the update apk clent After the update apk clent confirms that the update engine completes the partition table update preparation operation, the update apk clent executes S1530 to trigger the device to restart (the first restart), and the restarted device enters the Recovery mode.
  • the device uses the partition table in the operating system upgrade package to update the partition table on the device storage. Refer to S1020.
  • the update apk clent executes S1511 again, triggering the update engine to enter the upgrade process.
  • the update engine executes S1520 again to verify the operating system upgrade package.
  • the update engine executes S1521 again to detect whether the filelist file for the operating system upgrade package contains the partition upgrade package mark.
  • the update engine executes S1522 again to determine whether the operation of updating the partition table has been performed by using the operating system upgrade package. In currently executing S1522, the update engine determines that the operation of updating the partition table has been performed using the operating system upgrade package. Therefore, execute S1525, and upgrade the data of the static partition and the dynamic partition according to the operating system upgrade package. For details, refer to S520, S530, and S531.
  • the update engine executes S1526, and returns status information that the upgrade operation is completed to the update apk clent.
  • update apk clent triggers the device to restart (the third restart), for example, prompting the user with a pop-up box, and the user can choose to restart immediately or restart later.
  • the update apk clent executes S1551, and the update apk clent triggers the update engine to enter the merge process.
  • the update engine executes the merge process, refer to S551. After the merge process is complete, the operating system of the device is upgraded.
  • FIG. 16 shows a partial flow chart of operating system upgrade according to an embodiment of the present application.
  • an upgrade package acquisition tool acquires an operating system upgrade package and a filelist file. After that, the device executes the following steps as shown in FIG. 16 to realize S1511-S1530.
  • the update package acquisition tool (update apk clent) starts the update engine (update engine).
  • An update engine (update engine) verifies an operating system upgrade package.
  • the update engine executes S1610, parses the filelist file, and judges whether the filelist file contains the partition upgrade package sign;
  • the update engine updates the data of the static partition and the dynamic partition according to the operating system upgrade package, refer to S520, S530 and S531 for details.
  • the update apk clent triggers the device to restart. After the device restarts, the basic partition (Common), static partition (B) and dynamic partition (Super) are loaded in sequence, and the device starts from the static partition (B). After the device starts from the static partition (B), the update apk clent triggers the update engine to enter the merge process.
  • the update engine executes the merge process. After the merge process is completed, the operating system of the device is upgraded. Refer to S520-S551.
  • Partition table update preparation operations include:
  • the update engine executes S1622, and returns the status information of the partition table update preparation operation completion to the update apk clent.
  • the update apk clent After the update apk clent confirms that the update engine completes the partition table update preparation operation, the update apk clent executes S1630, records breakpoints, and records the current upgrade progress of the operating system. After the device restarts and enters the operating system, the operating system upgrade operation starts from S1600.
  • S1631, S1632, and S1633 refer to S1113, S1120, and S1121.
  • the device reboots into the recovery (Recovery) mode, and in the recovery (Recovery) mode, the device executes the process shown in FIG. 14: S1400-S1420.
  • the device After restarting the device in Recovery mode, the device loads the basic partition (Common), static partition (A) and dynamic partition (Super), and starts from the static partition (A).
  • the device loads the breakpoint saved by the S1630, and continues to upgrade the operating system. As shown in FIG. 15 , the operating system upgrade operation starts from S1600 to execute the follow-up process again.
  • the update engine (update engine) parses the filelist file, and judges that the filelist file contains the partition upgrade package flag.
  • S1612 is executed again, S1611 is executed to upgrade the operating system according to the operating system upgrade package.
  • improvements to a technology can be clearly distinguished as improvements in hardware (for example, improvements to circuit structures such as diodes, transistors, and switches) or improvements in software (improvements to method flow).
  • improvements in hardware for example, improvements to circuit structures such as diodes, transistors, and switches
  • improvements in software improvements to method flow.
  • the improvement of many current method flows can be regarded as the direct improvement of the hardware circuit structure.
  • Designers almost always get the corresponding hardware circuit structure by programming the improved method flow into the hardware circuit. Therefore, it cannot be said that the improvement of a method flow cannot be realized by hardware physical modules.
  • a programmable logic device (Programmable Logic Device, PLD) (such as a field programmable gate array (Field Programmable Gate Array, FPGA)) is such an integrated circuit, the logic function of which is determined by the programming of the device by the accessing party. It is programmed by the designer to "integrate" a digital device on a PLD, instead of asking a chip manufacturer to design and make a dedicated integrated circuit chip.
  • PLD Programmable Logic Device
  • FPGA Field Programmable Gate Array
  • HDL Hardware Description Language
  • ABEL Advanced Boolean Expression Language
  • AHDL Altera Hardware Description Language
  • HDCal JHDL
  • Lava Lava
  • Lola MyHDL
  • PALASM RHDL
  • VHDL Very-High-Speed Integrated Circuit Hardware Description Language
  • Verilog Verilog
  • the method flow proposed in the embodiment of the present application may be implemented in hardware, for example, using a controller, and the controller controls the touch screen to implement the method flow proposed in the embodiment of the present application.
  • the controller may be implemented in any suitable way, for example the controller may take the form of a microprocessor or processor and a computer readable medium storing computer readable program code (such as software or firmware) executable by the (micro)processor , logic gates, switches, application specific integrated circuits (Application Specific Integrated Circuit, ASIC), programmable logic controllers and embedded microcontrollers, examples of controllers include but are not limited to the following microcontrollers: ARC 625D, Atmel AT91SAM, Microchip PIC18F26K20 and Silicone Labs C8051F320, the memory controller can also be implemented as part of the control logic of the memory.
  • controller in addition to realizing the controller in a purely computer-readable program code mode, it is entirely possible to make the controller use logic gates, switches, application-specific integrated circuits, programmable logic controllers, and embedded The same function can be realized in the form of a microcontroller or the like. Therefore, such a controller can be regarded as a hardware component, and the devices included in it for realizing various functions can also be regarded as structures within the hardware component. Or even, means for realizing various functions can be regarded as a structure within both a software module realizing a method and a hardware component.
  • the present application further provides an electronic device.
  • the electronic device includes a memory for storing computer program instructions and a processor for executing the program instructions, wherein when the computer program instructions are executed by the processor, the electronic device is triggered to execute the method steps described in the embodiments of the present application.
  • the present application also provides a computer program product, the computer program product includes a computer program, and when it is run on a computer, causes the computer to execute some or all of the steps provided in the embodiments of the present application.

Landscapes

  • Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • Theoretical Computer Science (AREA)
  • General Engineering & Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Computer Security & Cryptography (AREA)
  • Stored Programmes (AREA)

Abstract

本申请实施例提供的一种升级操作系统的方法、设备、存储介质及计算机程序产品，包括：获取操作系统升级包，操作系统升级包包括第二分区表以及操作系统升级数据，其中，在第二分区表以及第一分区表中，名称相同的分区的地址配置一致；触发电子设备的第一次重启，在第一次重启之后，电子设备进入恢复模式；在恢复模式下，将电子设备的分区表更新为第二分区表；触发电子设备的第二次重启，在第二次重启之后，电子设备加载基础分区、第一静态分区以及动态分区的数据以运行第一操作系统；根据操作系统升级数据升级电子设备的操作系统，将第一操作系统升级为第二操作系统。本申请实施例的升级方案大大简化了分区表更新的操作难度，提高了用户体验。

Description

一种操作系统升级方法、设备、存储介质及计算机程序产品 技术领域
本申请涉及计算机技术领域，具体地涉及一种操作系统升级方法、设备、存储介质及计算机程序产品。
背景技术
在现有技术的应用场景中，用户终端需要安装操作系统才可以被用户使用。例如，手机上需要安装手机操作系统(例如：IOS系统、安卓系统)才可以被用户使用。
在终端设备安装操作系统后，当操作系统出现版本升级时，需要升级终端设备上所安装的操作系统。一般的，终端设备的操作系统的分区架构是事先在终端设备的存储器上规划好的。操作系统的升级主要是在原有的操作系统分区架构下对操作系统数据进行更新。但是，在进行某些改动较大的版本升级时，需要改动操作系统的分区架构，例如，增加分区或者是删除分区。因此，需要一种支持调整分区架构的操作系统升级方法。
发明内容
有鉴于此，本申请提供一种升级操作系统的方法、设备、存储介质及计算机程序产品，以利于解决现有技术中如何调整设备存储器的分区架构的问题。
第一方面，本申请实施例提供了一种升级操作系统的方法，应用于电子设备，电子设备包括处理器以及存储器，存储器包括基础分区、第一静态分区、第二静态分区、动态分区以及用户数据分区，电子设备当前的分区表为对应第一操作系统的第一分区表，电子设备启动后加载基础分区、第一静态分区以及动态分区的数据以运行第一操作系统，第一操作系统运行之后，方法包括：
获取操作系统升级包，操作系统升级包包括对应第二操作系统的第二分区表以及操作系统升级数据，操作系统升级数据用于将第一操作系统升级到第二操作系统，其中，在第二分区表以及第一分区表中，名称相同的分区的地址配置一致；
触发电子设备的第一次重启，在第一次重启之后，电子设备进入恢复模式；
在恢复模式下，将电子设备的分区表更新为第二分区表；
触发电子设备的第二次重启，在第二次重启之后，电子设备加载基础分区、第一静态分区以及动态分区的数据以运行第一操作系统；
根据操作系统升级数据升级电子设备的操作系统，将第一操作系统升级为第二操作系统。
根据本申请第一方面的方案，可以针对采用虚拟A/B升级方案的操作系统进行升级并在升级过程中更新设备存储器的分区表；根据本申请第一方面的方案，不需要准备烧录工具，设备基于下载的操作系统升级包就可以自行完成分区表的更新；根据本申请第一方面的方案大大简化了设备分区表更新的操作难度，提高了用户体验。
在第一方面的一种实现方式中，重启电子设备，进入恢复模式之前，方法还包括：
执行分区表更新准备操作，分区表更新准备操作用于配置电子设备在恢复模式下的执行 流程。
在第一方面的一种实现方式中，执行分区表更新准备操作，包括：
将第二分区表保存到缓存；
在缓存中写入第一控制命令，第一控制命令对应第一操作流程，第一操作流程用于将电子设备的分区表更新为第二分区表。
在第一方面的一种实现方式中，第一操作流程包括：
校验第二分区表；
第二分区表校验成功后，验证第二分区表以及第一分区表中，名称相同的分区的地址配置是否一致；
当第二分区表以及第一分区表中，名称相同的分区的地址配置一致时，使用第二分区表更新电子设备的分区表。
在第一方面的一种实现方式中，在恢复模式下，将电子设备的分区表更新为第二分区表，包括：
加载缓存中的第二分区表以及第一控制命令；
解析第一控制命令，根据第一控制命令调用第一操作流程的执行代码；
执行第一操作流程的执行代码。
在第一方面的一种实现方式中，执行分区表更新准备操作之前，方法还包括：
确认操作系统升级包是否用于更新分区；
当操作系统升级包用于更新分区时，确认电子设备的分区表是否已基于第二分区表进行过更新；
当电子设备的分区表未基于第二分区表进行过更新时，执行分区表更新准备操作。
在第一方面的一种实现方式中，确认操作系统升级包是否用于更新分区，包括：
解析操作系统升级包对应的描述文件，当描述文件中包含分区升级包标志时，操作系统升级包用于更新分区。
在第一方面的一种实现方式中：
确认电子设备的分区表是否已基于第二分区表进行过更新，其中，根据分区更新标志位的状态确认电子设备的分区表是否已基于第二分区表进行过更新，在获取操作系统升级包之前，分区更新标志位的状态为未更新；
在恢复模式下，将电子设备的分区表更新为第二分区表，包括，将分区更新标志位的状态设置为已更新；
根据操作系统升级数据升级电子设备的操作系统，将第一操作系统升级为第二操作系统，包括，将分区更新标志位的状态设置为未更新。
在第一方面的一种实现方式中，在根据操作系统升级数据升级电子设备的操作系统之前，方法还包括：
在第二次重启之后，在第一操作系统运行之后，再次确认电子设备的分区表是否已基于第二分区表进行过更新；
当第一升级包获取工具确认电子设备的分区表已基于第二分区表进行过更新时，根据操作系统升级数据升级电子设备的操作系统。
在第一方面的一种实现方式中，第一操作系统包括第一升级包获取工具以及第一升级引擎，第一操作系统运行之后，方法包括：
第一升级包获取工具获取操作系统升级包；
第一升级包获取工具确认操作系统升级包是否用于更新分区；
当操作系统升级包用于更新分区时，第一升级包获取工具确认电子设备的分区表是否已基于第二分区表进行过更新；
当电子设备的分区表未基于第二分区表进行过更新时，第一升级包获取工具执行分区表更新准备操作；
第一升级包获取工具记录第一升级流程断点，第一升级流程断点对应确认电子设备的分区表是否已基于第二分区表进行过更新；
第一升级包获取工具触发第一次重启；
第一次重启之后，电子设备进入恢复模式，在恢复模式下，电子设备的分区表被更新为第二分区表，之后，电子设备的分区表已基于第二分区表进行过更新；
在恢复模式下，触发第二次重启；
第二次重启之后，电子设备加载基础分区、第一静态分区以及动态分区的数据以运行第一操作系统；
第一操作系统运行之后，第一升级包获取工具读取第一升级流程断点，再次确认电子设备的分区表是否已基于第二分区表进行过更新；
当第一升级包获取工具确认电子设备的分区表已基于第二分区表进行过更新，第一升级包获取工具触发第一升级引擎根据操作系统升级数据升级电子设备的操作系统。
在第一方面的一种实现方式中，第一操作系统包括第二升级包获取工具以及第二升级引擎，第一操作系统运行之后，方法包括：
第二升级包获取工具获取操作系统升级包；
第二升级包获取工具触发第二升级引擎进入升级流程；
第二升级引擎确认操作系统升级包是否用于更新分区；
当操作系统升级包用于更新分区时，第二升级引擎确认电子设备的分区表是否已基于第二分区表进行过更新；
当电子设备的分区表未基于第二分区表进行过更新时，第二升级引擎执行分区表更新准备操作；
第二升级引擎向第二升级包获取工具返回分区表更新准备操作执行完成的状态信息；
第二升级包获取工具记录第二升级流程断点，第二升级流程断点对应第二升级包获取工具触发第二升级引擎进入升级流程；
第二升级包获取工具触发电子设备的第三重启；
第三重启之后，电子设备进入恢复模式，在恢复模式下，电子设备的分区表被更新为第二分区表，之后，电子设备的分区表已基于第二分区表进行过更新；
在恢复模式下，触发电子设备的第四重启；
第四重启之后，电子设备加载基础分区、第一静态分区以及动态分区的数据以运行第一操作系统；
第一操作系统运行之后，第二升级包获取工具读取第二升级流程断点，再次触发第二升级引擎进入升级流程；
第二升级引擎再次确认操作系统升级包是否用于更新分区；
当操作系统升级包用于更新分区时，第二升级引擎再次确认电子设备的分区表是否已基 于第二分区表进行过更新；
当电子设备的分区表未基于第二分区表进行过更新时，第二升级引擎根据操作系统升级数据升级电子设备的操作系统。
在第一方面的一种实现方式中，操作系统升级数据还包括静态分区升级数据以及动态分区升级数据，根据操作系统升级数据升级电子设备的操作系统，包括：
基于静态分区升级数据升级第二静态分区的数据；
在用户数据分区中创建虚拟动态分区，将动态分区升级数据写入到虚拟动态分区；
将电子设备的启动顺序由从第一静态分区启动，修改为从第二静态分区启动；
触发电子设备的第三次重启；
在第三次重启之后，电子设备加载基础分区、第二静态分区、动态分区以及虚拟动态分区的数据以运行第二操作系统；
在第二操作系统运行后，将虚拟动态分区的数据落盘到动态分区。
第二方面，本申请提出了一种电子设备，电子设备包括处理器以及存储器，存储器包括基础分区、第一静态分区、第二静态分区、动态分区以及用户数据分区，动态分区包括多个子分区，处理器用于执行存储器上存储的软件代码，以使得电子设备启动后加载基础分区、第一静态分区以及动态分区的数据以运行第一操作系统；
并且，在第一操作系统运行之后，使得电子设备执行如第一方面的方法流程。
第三方面，本申请提出了一种计算机可读存储介质，计算机可读存储介质中存储有计算机程序，当其在计算机上运行时，使得计算机执行如第一方面的方法。
第四方面，本申请提出了一种计算机程序产品，计算机程序产品包括计算机程序，当其在计算机上运行时，使得计算机执行如第一方面的方法。
附图说明
为了更清楚地说明本申请实施例的技术方案，下面将对实施例中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本申请的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动性的前提下，还可以根据这些附图获得其它的附图。
图1所示为根据本申请一实施例的数据存储结构示意图；
图2所示为根据本申请一实施例的数据存储结构示意图；
图3所示为根据本申请一实施例对操作系统进行升级的流程图；
图4所示为根据本申请一实施例的数据存储结构示意图；
图5所示为根据本申请一实施例进行操作系统升级的流程图；
图6所示为根据本申请一实施例出厂前进行系统烧录的烧录系统框架结构示意图；
图7所示为根据本申请一实施例的数据存储结构示意图；
图8所示为根据本申请一实施例的重新配置分区架构的分区结构示意图；
图9a所示为根据本申请一实施例进行操作系统升级的流程图；
图9b所示为根据本申请一实施例的操作系统升级包内部文件构成示意图；
图10所示为根据本申请一实施例进行操作系统升级的流程图；
图11所示为根据本申请一实施例进行操作系统升级的部分流程图；
图12为根据本申请一实施例的手机运行界面示意图；
图13为根据本申请一实施例的手机运行界面示意图；
图14所示为根据本申请一实施例进行操作系统升级的部分流程图；
图15所示为根据本申请一实施例进行操作系统升级的流程图；
图16所示为根据本申请一实施例进行操作系统升级的部分流程图。
具体实施方式
为了更好的理解本申请的技术方案，下面结合附图对本申请实施例进行详细描述。
应当明确，所描述的实施例仅仅是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其它实施例，都属于本申请保护的范围。
在本申请实施例中使用的术语是仅仅出于描述特定实施例的目的，而非旨在限制本申请。在本申请实施例和所附权利要求书中所使用的单数形式的“一种”、“所述”和“该”也旨在包括多数形式，除非上下文清楚地表示其他含义。
应当理解，本文中使用的术语“和/或”仅仅是一种描述关联对象的关联关系，表示可以存在三种关系，例如，甲和/或乙，可以表示：单独存在甲，同时存在甲和乙，单独存在乙这三种情况。另外，本文中字符“/”，一般表示前后关联对象是一种“或”的关系。
改动操作系统的分区架构，一种可行的解决方案是退出操作系统，进入恢复(Recovery)模式，在Recovery下对设备的存储器进行整体刷新，重新配置设备存储器的分区结构并在重新配置的分区中写入操作系统程序。
一般的，分区表用于描述设备中存储器的分区部署，定义每个分区的起始地址和大小。分区表通常保存在设备的存储器的磁盘头部，在设备启动时，可以通过读取分区表来定位存储器上的各个分区。
以一采用全局唯一标识分区表(GUID Partition Table，GPT)的磁盘为例。图1所示为根据本申请一实施例的数据存储结构示意图。假设版本1.0的操作系统的分区架构包含GPT分区、x-loader分区、bootloader分区、boot分区、vendor-boot分区、Super分区以及Userdata分区。其中，分区表保存在GPT分区；Userdata用于保存用户的个人数据，例如，用户个人安装的APP、用户个人保存的图片、文档以及视频等个人数据；x-loader分区、bootloader分区、boot分区、vendor-boot分区以及Super分区用于保存操作系统数据。
保存在GPT分区的分区表如表1所示：
Figure PCTCN2022094139-appb-000001
Figure PCTCN2022094139-appb-000002
表1
在表1中，AD1～AD6分别代表不同的地址字串。地址的数字串为16进制，地址字串加1代表偏移一个存储位(bit)，每8个存储位为一个字节(Byte)，每1024个字节为1KB，每1024KB为1MB。例如：
AD1为0x000000FF偏移256KB的存储位，即为0x002000FF；
x-loader的地址为0x00000100～0x002000FF，0x00000100～0x002000FF的大小为256KB；
AD1+1为0x000200FF偏移一个存储位，即为0x00200100；
AD2为AD1(0x002000FF)偏移600KB的存储位，即为0x006B00FF；bootloader的地址为0x00200100～0x006B00FF，0x00200100～0x006B00FF的大小为600KB。
假设在操作系统升级到版本2.0后，分区架构中增加了一个A分区。图2所示为根据本申请一实施例的数据存储结构示意图。假设版本2.0的操作系统的分区架构包含GPT分区、x-loader分区、bootloader分区、boot分区、A分区、vendor-boot分区、Super分区以及Userdata分区。
保存在GPT分区的分区表如表2所示：
Figure PCTCN2022094139-appb-000003
表2
在表2中，AD21、AD22分别代表不同的地址字串。AD21为AD3偏移32MB的存储位；AD22为AD21偏移32MB的存储位。相较于表1的分区结构，在表2的分区结构中，Super的大小减少了32MB。由于版本1.0的操作系统的分区架构对应图1所示分区架构，版本2.0的操作系统的分区架构对应图2所示分区架构，图1所示分区架构与图2所示分区架构并不相同，因此，设备上的操作系统从版本1.0升级到版本2.0的过程中，首先需要将设备存储器上的分区架构 由图1所示的分区架构重新配置图2所示的分区架构。即，将GPT中保存的分区表由表1刷新为表2。
不难理解，相较于表1所示的各个分区起始地址-终止地址，表2所示的分区起始地址-终止地址中，vendor-boot分区以及Super分区的起始地址-终止地址发生了改变，因此，如果将分区表由表1刷新为表2(重新配置分区架构)，存储器中的vendor-boot分区以及Super分区上的数据就不可用；那么，即使操作系统从版本1.0升级到版本2.0，vendor-boot分区以及Super分区中的数据未发生变化，在分区表由表1刷新为表2后，也需要对存储器中的vendor-boot分区以及Super分区进行数据重新写入。
因此，针对操作系统由1.0升级到2.0，一种可行的升级方案是在刷新分区表后，对所有的操作系统数据分区进行数据重新写入。
具体的，图3所示为根据本申请一实施例对操作系统进行升级的流程图。如图3所示，设备执行下述流程以将操作系统由版本1.0升级到版本2.0：
S300，获取操作系统升级包，将操作系统升级包保存到Userdata分区，操作系统升级包包括表2所示的分区表以及版本2.0的操作系统对应的bootloader分区、boot分区、A分区、vendor-boot分区、Super分区的镜像数据；
S310，重启设备进入恢复(Recovery)模式；
S320，在恢复(Recovery)模式下，读取Userdata分区的操作系统升级包；
S321，提取操作系统升级包中的分区表，使用操作系统升级包中的分区表替换设备存储器GPT分区中的分区表；在S321之前，GPT分区中的分区表如表1所示；
S322，分别提取操作系统升级包中bootloader分区、boot分区、A分区、vendor-boot分区、Super分区的镜像数据，按照表2所示的分区起始地址-终止地址，将镜像数据恢复到bootloader分区、boot分区、A分区、vendor-boot分区、Super分区的镜像数据；
S330，重启设备，启动操作系统。
虽然基于图3所示流程可以实现对操作系统分区架构的调整，但是，随着数据安全性要求的不断提高，在某些操作系统中，禁止在恢复(Recovery)模式下对用户个人数据进行访问，这就使得在恢复(Recovery)模式设备无法在分区中重新写入操作系统数据。
以采用虚拟A/B升级方式的安卓系统为例，图4所示为根据本申请一实施例的数据存储结构示意图。如图4所示，安卓系统数据存储区包含基础分区(Common)、静态分区(A)、静态分区(B)、动态分区(Super)、用户数据分区(Userdata)。
用户数据分区(Userdata)用于保存用户的个人数据，例如，用户个人安装的APP、用户个人保存的图片、文档以及视频等个人数据。基础部分中保存的数据为不参与操作系统升级的系统数据。静态分区(A)与静态分区(B)的结构相互对应，子分区命名通过后缀_a以及_b相互区分。例如，静态分区(A)包括bootloader_a、boot_a、vendor_boot_a、dtbo_a、vbmeta_a；静态分区(B)包括bootloader_b、boot_b、vendor_boot_b、dtbo_b、vbmeta_b。动态分区(Super)包含多个子分区(System、system_ext、vendor、product、Cust、Odm)。
在设备启动时，从一个静态分区启动。例如，设备从静态分区(A)启动：依次加载基础分区(Common)、静态分区(A)以及动态分区(Super)；设备从静态分区(B)启动：依次加载基础分区(Common)、静态分区(B)以及动态分区(Super)。
以采用主引导记录(Master Boot Record，MBR)格式的通用闪存(Universal Flash Storage，UFS)为例。在UFS的MBR(主引导扇区，UFS的第一个扇区，即C/H/S地址的0柱面0磁头1扇区)中，保存有设备启动顺序描述，例如，从静态分区(A)启动(启动顺序标志为A)或从静态分区(B)启动(启动顺序标志为A)。设备启动后首先从UFS的MBR中读取设备启动顺序。
图5所示为针对图4所示实施例的操作系统数据存储结构进行操作系统升级的流程图，当设备当前是从静态分区(A)启动时，设备按照如图5所示的流程实现操作系统的升级。
S500，设备依次加载基础分区(Common)、静态分区(A)以及动态分区(Super)，从静态分区(A)启动。
S510，设备获取操作系统升级包。
示例的，在一种可行的实现方案中，设备定期向搜包服务器发起搜包请求，搜包请求包含设备当前运行的操作系统的版本号(例如版本1.1)；搜包服务器根据搜包请求中的操作系统版本号，检索当前是否存在更新版本号的操作系统安装包(例如版本1.2)；当存在更新版本的操作系统安装包时，搜包服务器向设备反馈操作系统升级包(例如，由版本1.1升级到版本1.2的系统增量升级安装包)的下载地址；设备根据操作系统升级包的下载地址下载操作系统升级包。
S520，设备根据操作系统升级包针对静态分区(B)进行数据写入操作以升级静态分区。
在S520的执行过程中，存在S520执行失败(静态分区升级失败)的情况。针对该情况，设备会中断整个操作系统升级操作，向用户输出升级失败提示(例如，显示升级失败的对话框)，自动重新升级或者由用户确定是否重新升级或放弃升级。
为检测S520中是否存在静态分区升级失败的情况，在S520中，会对数据写入后的静态分区(B)进行数据校验以确认静态分区数据是否成功写入。
例如，在一应用场景中，版本1.1升级到版本1.2的系统升级安装包包含版本1.2的静态分区的全量数据以及版本1.2的静态分区的全量数据的哈希值。设备将版本1.2的静态分区的全量数据覆写到静态分区(B)中。数据写入之后，设备计算静态分区(B)中数据的哈希值，校验静态分区(B)中数据的哈希值与版本1.1升级到版本1.2的系统升级安装包中版本1.2的静态分区的全量数据的哈希值是否一致。如果一致，则说明数据写入成功，可以进行后续的操作系统升级操作；如果不一致，则说明数据写入失败，升级失败。
又例如，在一应用场景中，版本1.1升级到版本1.2的系统升级安装包包含版本1.1升级到版本1.2的静态分区的差分数据、版本1.1的静态分区的全量数据的哈希值以及版本1.2的静态分区的全量数据的哈希值。
设备在向静态分区(B)写入数据之前，首先计算静态分区(A)中数据的哈希值，校验静态分区(A)中数据的哈希值与版本1.1升级到版本1.2的系统升级安装包中版本1.1的静态分区的全量数据的哈希值是否一致，如果一致，则说明当前静态分区(A)中数据为版本1.1的静态分区数据，版本1.1升级到版本1.2的静态分区的差分数据可用；如果不一致，则版本1.1升级到版本1.2的静态分区的差分数据不可用，升级失败。
在设备确定版本1.1升级到版本1.2的静态分区的差分数据可用后，读取静态分区(A)中数据，使用版本1.1升级到版本1.2的静态分区的差分数据以及静态分区(A)中数据执行还原得到版本1.2的静态分区的全量数据，将版本1.2的静态分区的全量数据覆写到静态分区(B)中。数据写入之后，设备计算静态分区(B)中数据的哈希值，校验静态分区(B)中数 据的哈希值与版本1.1升级到版本1.2的系统升级安装包中版本1.2的静态分区的全量数据的哈希值是否一致。如果一致，则说明数据写入成功，可以进行后续的操作系统升级操作；如果不一致，则说明数据写入失败，升级失败。
以一个静态分区的子分区boot为例，在一应用场景中，版本1.1升级到版本1.2的系统升级安装包包含下述数据：
Name:boot(分区名称，表示当前数据为指向静态分区的子分区boot的升级数据)
Start:12222(数据块起始地址，表示静态分区的子分区boot的升级数据(差分数据DELTA1)的起始位置为12222)
size:2410(数据大小，表示静态分区的子分区boot的升级数据(差分数据DELTA1)的大小为2410)
原hash值:HASH11(版本1.1的静态分区的子分区boot的数据的哈希值)
镜像目标hash值:HASH12(版本1.2的静态分区的子分区boot的数据的哈希值)
差分数据delta:DELTA1(版本1.1升级到版本1.2的静态分区的差分数据)
在S520中，设备通过common分区中的misc分区读取设备的固定挂载路径，如/dev/block/by-name/misc。从UFS器件中读取卡槽位(slot-b)，替换得到个子分区路径，如/dev/block/by-name/boot_b。
继续以子分区boot为例，设备首先计算/dev/block/by-name/boot_a下数据的哈希值，校验/dev/block/by-name/boot_a下数据的哈希值与哈希值HASH11是否一致，如果一致，则DELTA1可用，如果不一致，则升级操作失败。
当/dev/block/by-name/boot_a下数据的哈希值与哈希值HASH11一致时，设备基于Start:12222以及size:2410读取DELTA1，使用DELTA1与/dev/block/by-name/boot_a下数据执行还原得到版本1.2的静态分区的子分区boot的全量数据。设备将版本1.2的静态分区的子分区boot的全量数据写到/dev/block/by-name/boot_b下。
数据写入后，设备计算/dev/block/by-name/boot_b下数据的哈希值，校验/dev/block/by-name/boot_b下数据的哈希值与哈希值HASH12是否一致，如果一致，则静态分区的子分区boot升级成功，可以针对下一个静态分区子分区进行升级；如果不一致，则升级操作失败。
在一应用场景中，设备根据系统升级安装包所包含的静态分区子分区升级数据对静态分区的子分区进行升级，具体的，如果系统升级安装包包含某个静态分区子分区升级数据，则按照上述boot子分区的升级流程对该静态分区(B)中的该子分区进行升级，如果系统升级安装包不包含某个静态分区子分区升级数据，则将静态分区(A)中该子分区的数据直接同步到静态分区(B)中该子分区中。在升级过程中，当一个子分区出现升级错误，哈希校验失败，则中断升级操作，升级失败；当所有子分区升级成功，则静态分区升级成功，可以执行后续步骤。
进一步的，当某个静态分区(静态分区(A)或静态分区(B))升级失败时，静态分区的数据无法用于顺利启动操作系统，为了避免在操作系统启动过程中加载升级失败的静态分区而导致操作系统启动错误，在一应用场景中，静态分区具备对应的状态标记(可启动或不可启动)。设备在加载静态分区数据之前首先读取静态分区状态标记，仅当静态分区的状态标记为可启动时才加载静态分区的数据。在升级静态分区的数据之前，会将静态分区标记为不可启动，在静态分区的数据升级成功后再将静态分区标记为可启动，这样，如果静态分区升级失败，则静态分区的状态会保持在不可启动。设备就不会加载升级失败的静态分区的数据。
例如，在S520中，在升级静态分区(B)的数据之前，标记静态分区(B)为不可启动。具体的，静态分区的状态标记保存在Common分区。在S520中，在升级静态分区(B)的数据之前，将Common分区中静态分区的状态标记中slot-b标记为unbootable。当S520成功执行(所有的哈希校验均成功时)后，标记静态分区(B)为可启动。例如，在S520之后，将Common分区中静态分区的状态标记中slot-b标记为bootable。
S530，设备根据操作系统升级包在用户数据分区(Userdata)创建虚拟动态分区，在虚拟动态分区写入动态分区(Super)的升级数据。例如，在操作系统升级包中包含版本1.2的动态分区的数据，设备在虚拟动态分区中写入版本1.2的动态分区(Super)的数据。
进一步的，在虚拟A/B升级方案中，针对动态分区(Super)，采用增量升级方式。在升级过程中，用户数据分区(Userdata)的虚拟动态分区中保存的并不是升级后新版本的动态分区(Super)的全部文件，而是旧版本的动态分区(Super)中需要升级的数据在升级后的升级结果。即，用户数据分区(Userdata)的虚拟动态分区中保存的是动态分区的更新数据。
以system子分区为例，假设在版本1.1中，system子分区中的数据可以分为system1、system2两部分。从版本1.1升级到版本1.2，数据system2没有发生变化，数据syetem1被升级为system3。那么，在S530中，设备在用户数据分区(Userdata)创建虚拟动态分区，在虚拟动态分区中写入数据system3。
例如，版本1.1升级到版本1.2的系统增量升级安装包包含版本1.1升级到版本1.2的动态分区(Super)更新数据，该动态分区(Super)更新数据包含数据system3。
进一步的，在虚拟A/B升级方案中，基于快照技术(snapshot)实现动态分区(Super)的增量升级。具体的，用户数据分区(Userdata)的虚拟动态分区中，采用写时拷贝(Copy-On-Write，COW)文件保存动态分区(Super)的升级数据。
具体的，用户数据分区(Userdata)中保存的动态分区(Super)的升级数据包含多个COW文件，每个COW文件对应一个动态分区(Super)的子分区，COW文件的命名与其所针对的动态分区(Super)子分区相对应。
在S510所获取的操作系统升级包中，动态分区(Super)的升级数据的COW文件以二进制代码形式压缩保存。在操作系统升级包中，每个COW文件根据其所针对的动态分区(Super)子分区所命名。例如，针对system子分区的COW文件被命名为system-cow-img.img.0000。
在S530中，设备解包操作系统升级包以获取所有的COW文件，为每个COW文件附加A/B分区标记。具体的，当设备当前从静态分区(A)启动时，可以理解为设备当前运行操作系统所加载的动态分区(Super)为动态分区(A)。在升级操作系统时，用户数据分区(Userdata)中创建的虚拟动态分区是针对动态分区(B)。因此，为COW文件附加对应动态分区(B)的名称标记_b。例如，为system-cow-img.img.0000附加_b生成system_b-cow-img.img.0000。
进一步的，在S530中，在用户数据分区(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文件(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地址段的数据)；
文件名后的数值(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子分区的数据升级。
在COW文件成功写入到用户数据分区(Userdata)后，将基础分区(Common)的元数据分区(/metadata)中的落盘状态信息由“已落盘(merged)”改为“未落盘(wait for merge)”。落盘状态信息用于表示当前是否存在需要落盘到动态分区(Super)的COW文件。具体的，落盘状态信息包含针对动态分区(Super)的整体标识以及针对每个子分区的子分区标识。当整体标识为“已落盘(merged)”时，代表动态分区(Super)的所有子分区均不需要进行落盘操作；当整体标识为“未落盘(wait for merge)”时，代表动态分区(Super)的一个或多个子分区需要进行落盘操作；当子分区标识为“已落盘(merged)”时，代表该子分区不需要进行落盘操作；当子分区标识为“未落盘(wait for merge)”时，代表该子分区需要进行落盘操作。
进一步的，在某些应用场景中，在S530中，设备不仅仅向用户数据分区(Userdata)写入COW文件，还会刷新动态分区(Super)的metadata中的分区信息。
具体的，图6所示为一应用场景下设备出厂前进行系统烧录的烧录系统框架结构示意图。在采用虚拟A/B升级方式的安卓系统中，由于只有静态分区采用A/B方案，而动态分区采用升级时构造虚拟动态分区的方案。因此，为了静态分区与动态分区的匹配，如图4所示，在动态分区(Super)的头部的元数据(/supermetadata)中，包含对应静态分区(A)的Slot0(插槽一数据)以及静态分区(B)的Slot1(插槽二数据)。Slot0以及Slot1用于保存Super分区的分区表。
例如，在UFS的MBR中，设备启动顺序描述中，配置Slot0对应从静态分区(A)启动，配置Slot1对应从静态分区(B)启动。在设备启动时，根据启动的静态分区的不同，选择从Slot0或Slot1中的一个中获取Super分区的分区信息。例如，在设备由静态分区A启动时，在加载Super分区时，设备首先读取Slot0，以获取Super分区的子分区地址；在设备由静态分区B启动时，在加载Super分区时，设备首先读取Slot1，以获取Super分区的子分区地址。
具体的，Slot0以及Slot1中包含多个子分区描述组，每个子分区描述组对应Super分区的一个子分区。每个子分区描述组包含：
名称(Name)项，其值为子分区的名称；
组(Group)项，其值为子分区类型；
属性(Attributes)项，其值为分区读写属性，例如，只读属性(readonly)；
地址(Extents)项，其值为子分区的地址(例如，分区大小、偏移量)。
在Name项以及Group项中，值的后缀为_a，则对应静态分区(A)；值的后缀为_b，则对应静态分区(B)。
在由静态分区A启动，加载Super分区时，首先读取Slot0。在读取Slot0时，由于后缀为_a对应静态分区(A)，设备读取Slot0中Name项和/或Group项后缀为_a的分区描述组中Extents项的值，以获取Super分区的子分区地址。
在由静态分区B启动，加载Super分区时，首先读取Slot1。在读取Slot1时，由于后缀为_b对应静态分区(B)，设备读取Slot0中Name项和/或Group项后缀为_b的分区描述组中Extents项的值，以获取Super分区的子分区地址。
在S510所获取的操作系统升级包中，包含1.2版本的动态分区(Super)的分区信息，在S530中，设备从操作系统升级包中提取1.2版本的动态分区(Super)的分区信息，使用1.2版本的动态分区(Super)的分区信息刷新静态分区(B)所对应的Slot1中的分区信息。
以System子分区为例，假设在S530之前，动态分区(Super)的/supermetadata的Slot 1中包含如下内容：
Metadata version:10.2
Metadata size:1300bytes
Metadata max size:65536bytes
Metadata slot count:3
Header flags:virtual_ab_device
Partition table:------------------------
Name:system_b
Group:ry_dynamic_partitions_b
Attributes:readonly,updated
Extents:0..6995967 linear super 2048
在S510所获取的操作系统升级包中，1.2版本的动态分区(Super)的分区信息包含如下内容：
Name:system
Group:ry_dynamic_partitions
Extents:0..699XXXX linear super 2048
在S530中，设备通过当前需要升级的静态分区为静态分区(B)定位到对应静态分区(B) 的动态分区(Super)的/supermetadata的Slot 1，使用1.2版本的动态分区(Super)的分区信息刷新Slot 1中的内容。在S530之后，动态分区(Super)的/supermetadata的Slot 1中包含如下内容：
Metadata version:10.2
Metadata size:1300bytes
Metadata max size:65536bytes
Metadata slot count:3
Header flags:virtual_ab_device
Partition table:------------------------
Name:system_b
Group:ry_dynamic_partitions_b
Attributes:readonly,updated
Extents:0..699XXXX linear super 2048
进一步的，在S530的执行过程中，存在S530执行失败的情况。针对该情况，设备会中断整个操作系统升级操作，向用户输出升级失败提示(例如，显示升级失败的对话框)，自动重新升级或者由用户确定是否重新升级或放弃升级。(参照S520中静态分区数据写入失败)
具体的，当用户数据分区(Userdata)的存储空间不足时会导致S530执行失败。在S530中，在设备根据操作系统升级包在用户数据分区(Userdata)创建虚拟动态分区的过程中，虚拟动态分区的大小是由操作系统升级包中版本1.2的动态分区的数据的大小决定的。当用户数据分区(Userdata)上的空余空间不足以创建虚拟动态分区时，S530执行失败。
例如，在一应用场景中，设备从操作系统升级包中提取COW文件并将COW文件写入用户数据分区(Userdata)的Update文件夹中。操作系统升级包中包含COW文件内容以及COW文件大小。在S530中，设备首先根据操作系统升级包中的cow文件名称以及COW文件大小在用户数据分区(Userdata)的Update文件夹下创建空COW文件，然后从操作系统升级包中提取COW文件数据写入空COW文件。
以system子分区为例，在操作系统升级包中，针对system子分区的COW文件被命名为system-cow-img.img.0000，system-cow-img.img.0000的大小为XXXX。设备在用户数据分区(Userdata)的Update文件夹下创建system_b-cow文件，system_b-cow文件的大小为XXXX，内容为空。在system_b-cow文件创建完成后，设备就可以从系统升级安装包中提取system-cow-img.img.0000，写入system_b-cow并改名为system_b-cow-img.img.0000。
设备在用户数据分区(Userdata)的Update文件夹下创建空COW文件system_b-cow、system_ext_b-cow、vendor_b-cow、product_b-cow、cust_b-cow、odm_b-cow。当所有的空COW文件创建完成后，设备就可以从系统升级安装包中提取COW文件数据，写入空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文件创建成功后创建下一个。在此过程中，当一个空COW文件创建失败，则说明用户数据分区(Userdata)的存储空间不足，S530执行失败，操作系统升级失败。
进一步的，在S530中，COW文件的提取失败也会导致S530执行失败。具体的，在操作系统升级包中，以二进制代码形式保存COW文件，在将COW文件写入用户数据分区(Userdata)时，首先需要从操作系统升级包中提取COW文件，将COW文件打开，将COW文件数据写入到用户数据分区(Userdata)。在上述过程中，如果操作系统升级包存在数据错误，COW文件无法提取或打开，则S530执行失败，操作系统升级失败。
进一步的，在S530中，COW文件的写入失败也会导致S530执行失败。为检测COW文件写入是否成功，在S530中，在将COW文件写入用户数据分区(Userdata)后，还需要对动态分区(Super)+COW文件进行整体校验，校验动态分区(Super)+COW文件的有效性，验证当前版本的动态分区(Super)数据+COW文件的合成结果是否为新版本的动态分区(Super)数据。
具体的，以从1.1版本升级到1.3版本为例，计算动态分区(Super)中不需要升级的数据(从版本1.1到版本1.2未发生变化的数据)与COW文件中升级数据(从版本1.1到版本1.2需要升级的数据)的合成结果的哈希值，判断该哈希值与1.3版本中动态分区(Super)的完整数据的哈希值是否一致，如果一致，则说明COW文件有效；如果不一致，则说明COW文件无效，升级失败，中断升级进程并报错；其中，1.3版本中动态分区(Super)的完整数据的哈希值被保存在操作系统升级包中。
具体的，在校验过程中，基于snapshot合并动态分区(Super)+COW文件。在snapshot的实现过程中，动态分区(Super)与COW文件的合并并不是物理意义上的合并，而是将system子分区的整体文件地图与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)的新版本的文件系统所包含的所有文件并计算哈希值。
S531，将设备的启动顺序由可从静态分区(A)启动变更为可从静态分区(B)启动。
例如，改写主引导记录(Master Boot Record，MBR)的启动顺序标识，将启动顺序标识由A改写为B。在设备上电后，当设备读取到启动顺序标识为A，设备从静态分区(A)启动，启动过程中加载静态分区(A)；当设备读取到启动顺序标识为B，设备从静态分区(B)启动，启动过程中加载静态分区(B)。
进一步的，在S531中，还将Common分区中静态分区的状态标记中slot-b标记为bootable。
S532，设备重启。退出当前的操作系统，切断设备电源，再次开启设备电源。
S540，设备依次加载基础分区(Common)、静态分区(B)。
S541，设备加载动态分区(Super)以及用户数据分区(Userdata)的虚拟动态分区。
具体的，设备读取元数据(/metadata)中的落盘状态信息，基于落盘状态信息确定是否需要从用户数据分区(Userdata)的指定路径中检索COW文件，并采用snapshot合并加载动态分区(Super)以及COW文件。
进一步的，在S541中，设备并不加载动态分区(Super)以及用户数据分区(Userdata)中的全部COW文件，而是根据操作系统运行需求加载对应的文件。具体的，在S541中，设备根据操作系统运行需求确定需要加载的文件，基于snapshot从动态分区(Super)或虚拟动态分区中的COW文件中提取对应的文件进行加载。
具体的，在S541中，当动态分区(Super)的子分区首存在对应的COW文件时，先基于snapshot生成动态分区(Super)各个子分区的新版本的文件地图。生成新版本的文件地图的过程可以参照S530。设备根据操作系统运行需求确定需要加载的文件，基于动态分区(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文件写入错误或者落盘状态信息写入错误)，此时设备回滚系统并报错。
进一步的，在S541中，在加载文件之前，设备还需要对加载文件进行校验。不同于S530，在S541中，不对动态分区(Super)+COW文件进行整体验证，而是仅对需要加载的文件进行验证。例如，基于dmverity进行校验(dm-verity是dm(device mapper)的一个目标(target)，是一个虚拟块设备，专门用于文件系统的校验)。校验成功则加载文件，校验失败则重启设备，回滚系统或者尝试再次加载文件。
S550，设备成功启动，进入用户交互界面。
S551，设备将虚拟动态分区的数据落盘到动态分区(Super)。
在本申请说明书的描述中，落盘操作指的是，在操作系统升级过程中，将用户数据分区(Userdata)上虚拟动态分区中保存的动态分区(Super)升级文件(COW文件)写入到动态分区(Super)中，使得动态分区(Super)的文件完成数据升级，以便设备在下次启动时不需要加载动态分区(Super)和虚拟动态分区，只需加载动态分区(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)”。
在S520中，静态分区升级的数据操作是针对静态分区(B)中的操作系统数据的，其并不会影响到当前启动的静态分区(A)的操作系统数据；并且，在S530中，动态分区升级的数据操作是在用户数据分区(Userdata)中所创建的虚拟动态分区上完成的，其并不会影响到当前挂载的动态分区(Super)。因此，在整个操作系统升级的过程中，用户可以正常使用设备；并且，在S531完成后，设备并不需要立即重启，可以由用户自行选择重启时机；这样，操作系统的升级过程并不会对用户的正常手机操作产生影响，从而大大提高了用户体验。进一步的，针对动态分区(Super)，仅在需要进行升级时才会在用户数据分区(Userdata)上创建虚拟动态分区，因此有效提高了数据存储空间利用率。
图7所示为根据本申请一实施例的数据存储结构示意图。如果需要对图4所示的的分区结构进行重新配置，例如，在静态分区(A)以及静态分区(B)中分别增加子分区A_a以及A_b，得到图7所示的数据存储结构，就需要将设备的存储器的磁盘头部(例如，MBR分区或GPT分区)中所保存的分区表刷新为图7所示数据存储结构所对应的分区表(原始分区表为图4所示分区结构所对应的分区表)。由于在图5所示的升级流程中，设备在操作系统运行的状态下完成操作系统数据升级；而操作系统正常运行状态下，存储器的磁盘头部的分区表是只读的，因此，按照图5所示的升级流程，无法完成分区表的刷新。
因此，一种逻辑上可行的应用方案是基于图3所示流程，在用户数据分区(Userdata)中保存操作系统升级包，该操作系统升级包包含图7所示数据存储结构的分区表以及图7所示的数据存储结构中各个分区的镜像数据。设备重启后进入恢复(Recovery)模式，在恢复 (Recovery)模式下读取用户数据分区(Userdata)中保存的操作系统升级包，使用操作系统升级包中的分区表刷新磁盘MBR中的分区表，基于刷新后的分区表定位各个分区，将操作系统升级包中各个分区的镜像数据恢复到各个分区。
然而，在采用虚拟A/B升级方式的安卓系统中，为了确保用户数据安全，用户数据分区(Userdata)中保存的数据是被加密的，只有在安卓系统正常运行下才可以对用户数据分区(Userdata)中保存的数据进行访问。也就是说，当设备重启进入恢复(Recovery)模式后，其无法访问用户数据分区(Userdata)中保存的数据。这样，设备就无法在恢复(Recovery)模式中重新配置分区结构并重新为新配置的各个分区写入数据。
针对上述问题，本申请提出了一种虚拟A/B升级与恢复(Recovery)模式升级相结合的操作系统升级方法。先在恢复(Recovery)模式下刷新分区表以重新配置分区架构，然后启动操作系统，采用虚拟A/B升级的方式升级操作系统数据。
由于在重新配置分区架构后需要启动操作系统，因此，就要求重新配置分区架构后，操作系统启动时所要加载的各个分区仍然可用。即，在重新配置分区架构前后，操作系统启动时所要加载的各个分区的起始地址-终止地址保持不变。针对上述要求，本申请提出了一种新的操作系统分区架构。在本申请一实施例的分区架构中，并不把磁盘的所有空间都创建为可用的分区，而是预留一部分空间作为预留(reserve)分区。reserve分区为不可用的分区，其在设备运行时不体现在设备的可用分区中，即，假设操作系统对应的分区架构如图4所示，如果设备的存储器上配置有reserve分区，则设备运行操作系统时，其可用的分区依然如图4所示，reserve分区并未体现。
而在重新配置分区架构时，如果需要新增分区，使用reserve分区来创建新分区；如果需要删除分区，则将需要删除的分区转换为reserve分区；在重新配置分区架构前后，reserve分区以外的其他分区保持不变。
以增加新分区的应用场景为例，图8所示为根据本申请一实施例的重新配置分区架构的分区结构示意图。在重新配置分区架构之前，图4所示的分区架构映射到存储器上的一部分存储空间分配如图8左图所示。图8左图对应的分区表如表3所示：
Figure PCTCN2022094139-appb-000004
Figure PCTCN2022094139-appb-000005
表3
在表3中，AD31～AD38分别代表不同的地址字串。参照表1的AD1～AD6。XX为分区大小，不同分区的XX可以相同也可以不同。
将图4所示的分区架构重新配置分区为图7所示的分区架构，在重新配置分区架构之后，图7所示的分区架构映射到存储器上的一部分存储空间分配如图8右图所示。图8右图对应的分区表如表4所示：
Figure PCTCN2022094139-appb-000006
表4
同样，针对删除分区的应用场景，则是将上述流程倒过来，将删除的分区配置为新的reserve分区。
进一步的，根据所要创建的新分区的大小，可以采用分割单个reserve分区和/或合并多个reserve分区的方式，切割一个reserve分区的一部分空间创建新分区，或合并多个reserve分区创建新分区。
图9a所示为根据本申请一实施例进行操作系统升级的流程图。设备执行如图9a所示以实现包含分区架构重新配置的操作系统升级。
S900，设备依次加载基础分区(Common)、静态分区(A)以及动态分区(Super)，从静态分区(A)启动。
S910，获取操作系统升级包，操作系统升级包的获取过程可以参照S510。
操作系统升级包包含最新版本的操作系统所对应的分区结构的分区表以及操作系统升级 数据。操作系统升级数据的具体内容可以参照图5所示升级流程中的操作系统升级包的内容。
操作系统升级包所包含的分区表与设备存储器上当前的分区表上，同名分区的地址相同。
例如，假设设备当前操作系统(版本1.0)对应的分区结构如图4所示，最新版本的操作系统(版本2.0)对应的分区结构如图7所示。在设备存储器上，当前的分区结构除包含图4所示分区以及子分区以外，还包含reserve分区。设备当前的分区表的一部分如表3所示。而操作系统升级包所包含的分区表的一部分如表4所示。并且，操作系统升级数据包含静态分区子分区A的数据。
在操作系统升级包中，操作系统升级数据通常被打包为update_base.zip。在S910中，设备在获取操作系统升级包的同时还获取到针对操作系统升级包的描述文件(filelist文件)，该filelist文件用于描述update_base.zip的相关信息，例如，filelist文件中包括update_base.zip所针对的操作系统版本号、update_base.zip的哈希值等。
在S910所获取的操作系统升级包中，update_base.zip中包含最新版本的操作系统所对应的分区结构的分区表。
具体的，在生成操作系统升级包以及对应操作系统升级包的filelist文件的过程中：
将分区表镜像单独打包成update_ptable.zip(按update_base.zip包类型打包)，update_ptable.zip签名后打入到update_base.zip中，再整体签名。
图9b所示为根据本申请一实施例的操作系统升级包内部文件构成示意图。如图9b所示，update_ptable.zip将分区表镜像(update_ptable.zip)打包在根目录。在update_ptable.zip中，ptable.img为分区表镜像文件。
在操作系统升级包的filelist文件中增加分区升级包标志，该分区升级包标志用于标识当前操作系统升级包中的update_base.zip包含最新版本的分区表。
进一步的，包含分区表的操作系统升级包被配置为关键节点包，在进行操作系统升级的过程中，跨版本的升级操作不能跳过关键节点包。即，设备必须首先基于关键节点包升级操作系统(重新配置分区结构)后，才能升级到关键节点包之后的版本的操作系统。例如，版本2.0之前的操作系统对应图4所示的分区结构。版本2.0开始，操作系统对应图7所示的分区结构。版本2.0的操作系统的操作系统升级包就为关键节点包。假设设备当前的操作系统版本为1.0，最新的操作系统为2.1，设备不能直接升级到版本2.1的操作系统，而必须首先基于版本2.0的操作系统升级包升级到版本2.0的操作系统(重新配置分区结构为图7所示分区结构)，才能继续升级到版本2.1。
S911，检测本次操作系统升级是否需要更新分区表。具体的，检测S910所获取的，针对操作系统升级包的filelist文件里是否包含分区升级包标志。
如果不包含，则说明update_base.zip不包含分区表，本次操作系统升级不需要更新分区表，执行S912，基于操作系统升级包中的操作系统升级数据(update_base.zip)进行操作系统升级，S912的执行参照S520～S551。
如果filelist文件里包含分区升级包标志。则说明update_base.zip包含分区表，本次操作系统升级需要更新分区表，执行S913，重启并进入恢复(Recovery)模式。
S914，在恢复(Recovery)模式下，使用update_base.zip中的分区表更新设备存储器上的分区表；
S920，重启设备，依次加载基础分区(Common)、静态分区(A)以及动态分区(Super)，从静态分区(A)启动。
S921，基于操作系统升级包中的操作系统升级数据(update_base.zip)进行操作系统升级，S921的执行参照S520～S551。
根据图9a所示实施例的方法，可以针对采用虚拟A/B升级方案的操作系统进行升级并在升级过程中更新设备存储器的分区表。本申请实施例的升级方案大大简化了设备分区表更新的操作难度，提高了用户体验。根据图9a所示实施例的方法，可以针对采用虚拟A/B升级方案的操作系统进行升级并在升级过程中更新设备存储器的分区表；根据图9a所示实施例的方法，不需要准备烧录工具，设备基于下载的操作系统升级包就可以自行完成分区表的更新；根据图9所示实施例的方法大大简化了设备分区表更新的操作难度，提高了用户体验。
具体的，操作升级操作是由设备上安装的操作系统更新程序所完成的。具体的，升级包获取工具(update apk clent)以及升级引擎(update engine)是操作系统中的两个模块。升级包获取工具(update apk clent)用于获取操作系统的升级安装包，将操作系统升级包下载并保存到用户数据分区(Userdata)。参照S210。
例如，升级包获取工具(update apk clent)定期向搜包服务器发起搜包请求，搜包请求包含设备当前操作系统版本号(例如版本1.1)、设备SN号、产品型号、制式等信息(例如版本1.1)；搜包服务器根据搜包请求中的操作系统版本号，检索安装包服务器上是否存在更新版本号的操作系统安装包(例如版本1.2)；当存在更新版本的操作系统安装包时，搜包服务器向升级包获取工具(update apk clent)反馈操作系统升级包(例如，由版本1.1升级到版本1.2的操作系统升级包)的下载地址(例如，URL地址)以及系统升级安装包对应的filelist文件；升级包获取工具(update apk clent)根据操作系统升级包的下载地址从安装包服务器下载操作系统升级包。
当升级包获取工具(update apk clent)获取到操作系统升级包后，其启动升级引擎(update engine)，由升级引擎(update engine)根据操作系统升级包进行操作系统的升级。
具体的，当升级包获取工具(update apk clent)获取到操作系统升级包后，升级包获取工具(update apk clent)设置升级引擎(update engine)的启动属性，将启动属性设置为true。常驻操作系统后台的服务servicemanger会监控升级引擎(update engine)302的启动属性，当servicemanger检测到升级引擎(update engine)的启动属性为true时，servicemanger启动升级引擎(update engine)。
升级包获取工具(update apk clent)通过binder通信获取升级引擎(update engine)的状态，当升级包获取工具(update apk clent)确认升级引擎(update engine)成功启动时，升级包获取工具(update apk clent)向升级引擎(update engine)传递升级参数(例如，当前的升级操作是文件更新操作还是文件落盘操作)，触发升级引擎(update engine)进入升级流程。具体的升级流程可以参照S520～S551。
在本申请一实施例中，基于升级包获取工具(update apk clent)实现S911。具体的，图10所示为根据本申请一实施例进行操作系统升级的流程图。设备执行如图10所示以实现包含分区架构重新配置的操作系统升级。
S1000，升级服务器推送发布最新版本的、用于更新分区表的操作系统升级包。
设备依次加载基础分区(Common)、静态分区(A)以及动态分区(Super)，从静态分区(A)启动。S1000可以在设备启动后执行，也可以在设备启动前执行。设备在从静态分区(A) 启动的状态下，update apk clent执行S1010，获取操作系统升级包，操作系统升级包的获取过程可以参照S910。
S1011，update apk clent检测针对操作系统升级包的filelist文件里是否包含分区升级包标志。参照S911。
由于update apk clent获取的操作系统升级包为用于更新分区表的操作系统升级包，因此，针对操作系统升级包的filelist文件里包含分区升级包标志。执行S1012，update apk clent判断是否已使用操作系统升级包进行过更新分区表操作。在当前执行的S1012中，update apk clent判定尚未使用操作系统升级包进行过更新分区表操作。因此，执行S1013，update apk clent执行分区表更新准备操作。
在update apk clent完成分区表更新准备操作后，执行S1014，update apk clent触发设备重启(第一次重启)，重启后的设备进入Recovery模式。
S1020，在Recovery模式下，设备使用操作系统升级包中的分区表更新设备存储器上的分区表。
在Recovery模式下，当设备完成分区表的更新后，执行S1021，触发设备再次重启(第二次重启)，重启后的设备依次加载基础分区(Common)、静态分区(A)以及动态分区(Super)，从静态分区(A)启动。
设备在从静态分区(A)启动的状态下，update apk clent再次执行S1012，判断是否已使用操作系统升级包进行过更新分区表操作。在再次执行的S1012中，update apk clent判定已使用操作系统升级包进行过更新分区表操作。因此，update apk clent执行S1030，触发update engine进入升级流程。
在升级流程中，update engine执行S1031，校验操作系统升级包。具体的，校验操作系统升级包的数字签名是否合法，确认操作系统升级包是否为合法的升级包。
当操作系统升级包通过校验后，update engine执行S1032，根据操作系统升级包升级静态分区以及动态分区的数据，具体参照S520、S530以及S531。
在update engine完成S1032的升级操作后，update engine执行S1033，向update apk clent返回升级操作完成的状态信息。
S1040，update apk clent触发设备重启(第三次重启)，例如，向用户弹框提示，用户用选择立即重启或稍后重启。
设备重启后依次加载基础分区(Common)、静态分区(B)以及动态分区(Super)，从静态分区(B)启动。参照S540以及S541。
设备从静态分区(B)启动后，update apk clent执行S1041，update apk clent触发update engine进入merge流程。
S1042，update engine执行merge流程，参照S551。merge流程完成后设备的操作系统完成升级。
具体的，图11所示为根据本申请一实施例进行操作系统升级的部分流程图。
在S1010中，升级包获取工具(update apk clent)获取操作系统升级包以及filelist文件。在此之后，S1011～S1014执行如图11所示的下述步骤。
S1100，升级包获取工具(update apk clent)解析filelist文件，判断filelist文件中是否包含分区升级包标志；
如filelist文件中不包含分区升级包标志，S1101，设备根据操作系统升级包进行操作系统升级。具体的，升级包获取工具(update apk clent)启动升级引擎(update engine)，由升级引擎(update engine)根据操作系统升级包升级静态分区(B)以及动态分区，重启设备从静态分区(B)启动，升级包获取工具(update apk clent)启动升级引擎(update engine)进行落盘操作。参照S520～S551。
如filelist文件中包含分区升级包标志，S1102(即S1012)，升级包获取工具(update apk clent)判断分区表是否已被更新。
具体的，在S1102中，升级包获取工具(update apk clent)根据保存在common分区的元数据(/metadata)中的分区更新标志位(ptable oeminfo)的状态来判断分区表是否已被更新。当ptable oeminfo＝0(状态为未更新)时，分区表未被更新；当ptable oeminfo＝1(状态为已更新)时，分区表已被更新；ptable oeminfo默认的初始状态为0。
在设备尚未使用操作系统升级包进行过更新分区表操作时，ptable oeminfo＝0时，升级包获取工具(update apk clent)执行分区表更新准备操作，分区表更新准备操作(即S1013)包括S1110～S1111：
S1110，从update_base.zip中提取update_ptable.zip，将update_ptable.zip解压后保存到缓存分区(cache目录)。
S1111，写针对分区表更新的command命令(CMD)。具体的，将command命令写入到缓存分区(cache目录)，该command命令用于指示设备执行更新分区表的流程。
例如，update_ptable.zip包含分区表镜像ptable.img以及ptable.img的哈希值H1。在S1111中，写入command命令，command命令包含指向流程(1)的执行流程标识符(Process1)。
流程(1)包括下述步骤：
计算ptable.img的哈希值H2；
对比H1以及H2；
如不同，报错并重启设备(设备重启后加载基础分区(Common)、静态分区(A)以及动态分区(Super)，从静态分区(A)启动)；
如相同，读取设备当前的分区表(假设设备当前的分区表为ptable0)；
打开ptable.img(假设ptable.img打开后为ptable1)；
验证ptable0与ptable1中名称一致的分区的分区地址起始位置-终止位置是否一致；
如果ptable0与ptable1中名称一致的分区的分区地址起始位置-终止位置不一致，报错并重启设备(设备重启后加载基础分区(Common)、静态分区(A)以及动态分区(Super)，从静态分区(A)启动)；
如果ptable0与ptable1中所有名称一致的分区的分区地址起始位置-终止位置一致，使用ptable.img更新设备存储器上当前的分区表(更新ptable0为ptable1)；
配置ptable oeminfo＝1；
重启设备(设备重启后加载基础分区(Common)、静态分区(A)以及动态分区(Super)，从静态分区(A)启动)。
在S1111后，update apk clent完成分区表更新准备操作。之后update apk clent执行S1112，记录断点，记录操作系统当前的升级进度，当设备重启进入操作系统后，操作系统升级操作从S1102开始。
在S1112后，update apk clent完成分区表更新准备操作，update apk clent触发设备重启 (第一次重启)，具体的，update apk clent执行S1113，弹出对话框，提示用户当前的操作系统升级需要重启设备。
具体的，S1010、S1100、S1110、S1111以及S1112的执行均可以在用户正常使用手机的过程中后台执行。
具体的，图12为根据本申请一实施例的手机运行界面示意图。当手机顺利启动操作系统后，进入如图12中1201所示的系统界面。手机进行操作系统升级(执行S1010、S1100、S1110、S1111以及S1112)，手机的显示界面可以为图12中1202所示的界面，从而向用户展示操作系统升级进度。S1010、S1100、S1110、S1111以及S1112的执行也可以在系统后台运行，用户在手机运行S1010、S1100、S1110、S1111以及S1112时可以切换至1201所示的系统界面，打开其他应用；或者，用户在手机运行S1010、S1100、S1110、S1111以及S1112时可以切换至系统正在运行的其他应用的应用界面，例如，1203所示的聊天应用界面。
在S1113中，当手机需要重启时，手机向用户输出重启提示，由用户确认是否立即重启。
例如，图13为根据本申请一实施例的手机运行界面示意图。手机当前展示如图12中1202所示的界面，向用户展示操作系统升级进度。在S1113中，手机展示如图13中1303所示的界面，由用户确认立即重启或是稍后重启。
又例如，手机当前展示如图12中1203所示的界面，用户使用聊天应用。在S1113中，手机展示如图13中1301所示的界面，弹出提示通知。用户点击提示通知，进入如图13中1303所示的界面，由用户确认立即重启或是稍后重启。或者，用户打开下拉通知栏，手机展示如图13中1302所示的界面。在下拉通知栏中，用户点击提示通知，进入如图13中1303所示的界面，由用户确认立即重启或是稍后重启。
具体的，在S1113中，如果用户点击重启按钮，执行S1120(即S1014)，设备重启，重启后的设备进入恢复(Recovery)模式。
在S1113中，如果用户点击稍后按钮，执行S1121，设备暂停升级流程，并在预设的定时升级节点重新启动升级流程，升级流程启动后设备重启，重启后的设备进入恢复(Recovery)模式。
图14所示为根据本申请一实施例进行操作系统升级的部分流程图。在S1120或S1121之后，设备重启进入恢复(Recovery)模式，在恢复(Recovery)模式下，设备执行如图14所示的流程。
具体的，S1020～S1021包括：
S1400，挂载缓存数据，具体的，挂载cache目录下的数据(update_ptable.zip解压内容以及S1111写的command命令)；
S1410，解析command命令，具体的，解析S1111写的command命令；
S1420，根据command命令，调用流程(1)的执行代码。
例如，解析获取command命令中指向流程(1)的执行流程标识符(Process1)。根据执行流程标识符(Process1)调取预存的、对应Process1的执行流程(流程(1))的执行代码，执行流程(1)的执行代码从而实现流程(1)。具体的，在S1420中，设备对挂载的ptable.img进行哈希值校验；校验通过后验证ptable.img是否可用；当ptable.img可用时刷新设备存储器上原有的分区表；刷新成功后重启设备(第二次重启)。
S1420的具体执行参照S1111中流程(1)的描述。
在S1420之后，设备加载基础分区(Common)、静态分区(A)以及动态分区(Super)，从静态分区(A)启动。在操作系统启动后，设备加载S1112保存的断点，从S1102开始继续进行操作系统升级操作，再次执行S1102。
S1102，升级包获取工具(update apk clent)判断分区表是否已被更新。
具体的，在S1420中，设备执行S1111写的command命令所对应的流程(1)，在分区表被成功更新后配置ptable oeminfo＝1。因此，在再次执行的S1102中，升级包获取工具(update apk clent)读取到保存在common分区的元数据(/metadata)中的分区更新标志位(ptable oeminfo)为ptable oeminfo＝1时，分区表已被更新。
因此，在再次执行的S1102后，执行S1101(即S1030)，设备根据操作系统升级包进行操作系统升级。参照S520～S551。进一步的，在S1101中，在操作系统升级成功后，升级引擎(update engine)配置ptable oeminfo＝0。具体的，在S531中，升级引擎(update engine)配置ptable oeminfo＝0。
进一步的，在另一实施例中，基于升级引擎(update engine)实现S911。具体的，图15所示为根据本申请一实施例进行操作系统升级的流程图。设备执行如图15所示以实现包含分区架构重新配置的操作系统升级。
S1500，升级服务器推送发布最新版本的、用于更新分区表的操作系统升级包。
设备依次加载基础分区(Common)、静态分区(A)以及动态分区(Super)，从静态分区(A)启动。S1500可以在设备启动后执行，也可以在设备启动前执行。设备在从静态分区(A)启动的状态下，update apk clent执行S1510，获取操作系统升级包，操作系统升级包的获取过程可以参照S910。
S1511，update apk clent触发update engine进入升级流程。在升级流程中，update engine执行S1520，校验操作系统升级包。具体的，校验操作系统升级包的数字签名是否合法，确认操作系统升级包是否为合法的升级包。
当操作系统升级包通过校验后，update engine执行S1521，检测针对操作系统升级包的filelist文件里是否包含分区升级包标志。参照S911。
由于update apk clent获取的操作系统升级包为用于更新分区表的操作系统升级包，因此，针对操作系统升级包的filelist文件里包含分区升级包标志。执行S1522，update engine判断是否已使用操作系统升级包进行过更新分区表操作。在当前执行的S1522中，update engine判定尚未使用操作系统升级包进行过更新分区表操作。因此，执行S1523，update engine执行分区表更新准备操作。
在update engine完成分区表更新准备操作后，update engine执行S1524，向update apk clent返回分区表更新准备操作完成的状态信息。
在update apk clent确认update engine完成分区表更新准备操作后，update apk clent执行S1530，触发设备重启(第一次重启)，重启后的设备进入Recovery模式。
S1540，在Recovery模式下，设备使用操作系统升级包中的分区表更新设备存储器上的分区表。参照S1020。
在Recovery模式下，当设备完成分区表的更新后，执行S1541，触发设备再次重启(第二次重启)，重启后的设备依次加载基础分区(Common)、静态分区(A)以及动态分区(Super)，从静态分区(A)启动。
设备在从静态分区(A)启动的状态下，update apk clent再次执行S1511，触发update engine进入升级流程。update engine再次执行S1520，校验操作系统升级包。
当操作系统升级包通过校验后，update engine再次执行S1521，检测针对操作系统升级包的filelist文件里是否包含分区升级包标志。
update engine再次执行S1522，判断是否已使用操作系统升级包进行过更新分区表操作。在当前执行的S1522中，update engine判定已使用操作系统升级包进行过更新分区表操作。因此，执行S1525，根据操作系统升级包升级静态分区以及动态分区的数据，具体参照S520、S530以及S531。
在update engine完成S1525的升级操作后，update engine执行S1526，向update apk clent返回升级操作完成的状态信息。
S1550，update apk clent触发设备重启(第三次重启)，例如，向用户弹框提示，用户用选择立即重启或稍后重启。
设备重启后依次加载基础分区(Common)、静态分区(B)以及动态分区(Super)，从静态分区(B)启动。参照S540以及S541。
设备从静态分区(B)启动后，update apk clent执行S1551，update apk clent触发update engine进入merge流程。
S1552，update engine执行merge流程，参照S551。merge流程完成后设备的操作系统完成升级。
具体的，图16所示为根据本申请一实施例进行操作系统升级的部分流程图。
在S1510中，升级包获取工具(update apk clent)获取操作系统升级包以及filelist文件。在此之后，设备执行如图16所示的下述步骤实现S1511～S1530。
S1600，升级包获取工具(update apk clent)启动升级引擎(update engine)。
S1601，升级引擎(update engine)校验操作系统升级包。
校验成功后，升级引擎(update engine)执行S1610，解析filelist文件，判断filelist文件中是否包含分区升级包标志；
如filelist文件中不包含分区升级包标志，执行S1611,根据操作系统升级包进行操作系统的升级。具体的，update engine根据操作系统升级包升级静态分区以及动态分区的数据，具体参照S520、S530以及S531。update apk clent触发设备重启，设备重启后依次加载基础分区(Common)、静态分区(B)以及动态分区(Super)，从静态分区(B)启动。设备从静态分区(B)启动后，update apk clent触发update engine进入merge流程。update engine执行merge流程，merge流程完成后设备的操作系统完成升级。参照S520～S551。
如filelist文件中包含分区升级包标志，升级引擎(update engine)执行S1612，升级引擎(update engine)判断分区表是否已被更新。参照S1102，ptable oeminfo＝0，升级引擎(update engine)执行分区表更新准备操作。分区表更新准备操作包括：
S1620，从update_base.zip中提取update_ptable.zip，将update_ptable.zip解压后保存到缓存分区(cache目录)。
S1621，写针对分区表更新的command命令(CMD)。参照S1111。
在分区表更新准备操作完成之后，update engine执行S1622，向update apk clent返回分区表更新准备操作完成的状态信息。
在update apk clent确认update engine完成分区表更新准备操作后，update apk clent执行S1630，记录断点，记录操作系统当前的升级进度，当设备重启进入操作系统后，操作系统升级操作从S1600开始。
S1631、S1632、S1633，参照S1113、S1120、S1121。
在S1632或S1633之后，设备重启进入恢复(Recovery)模式，在恢复(Recovery)模式下，设备执行如图14所示的流程：S1400～S1420。
在恢复(Recovery)模式下重启设备之后，设备加载基础分区(Common)、静态分区(A)以及动态分区(Super)，从静态分区(A)启动。在操作系统启动后，设备加载S1630保存的断点，继续进行操作系统升级操作。如图15所示，操作系统升级操作从S1600开始再次执行后续流程，在S1610中，升级引擎(update engine)解析filelist文件，判断filelist文件中包含分区升级包标志。
在恢复(Recovery)模式下，设备执行S1621写的command命令对应的流程(1)，在分区表被成功更新后配置ptable oeminfo＝1。因此，在再次执行的S1612中，升级引擎(update engine)读取到保存在common分区的元数据(/metadata)中的分区更新标志位(ptable oeminfo)为ptable oeminfo＝1时，分区表已被更新。
因此，在再次执行的S1612之后，执行S1611，根据操作系统升级包进行操作系统的升级。
进一步的，在S1611中，在操作系统升级成功后，升级引擎(update engine)配置ptable oeminfo＝0。参照S1101。
可以理解的是，上述实施例中的部分或全部步骤或操作仅是示例，本申请实施例还可以执行其它操作或者各种操作的变形。此外，各个步骤可以按照上述实施例呈现的不同的顺序来执行，并且有可能并非要执行上述实施例中的全部操作。
进一步的，一般的，对于一个技术的改进可以很明显地区分是硬件上的改进(例如，对二极管、晶体管、开关等电路结构的改进)还是软件上的改进(对于方法流程的改进)。然而，随着技术的发展，当今的很多方法流程的改进已经可以视为硬件电路结构的直接改进。设计人员几乎都通过将改进的方法流程编程到硬件电路中来得到相应的硬件电路结构。因此，不能说一个方法流程的改进就不能用硬件实体模块来实现。例如，可编程逻辑器件(Programmable Logic Device,PLD)(例如现场可编程门阵列(Field Programmable Gate Array，FPGA))就是这样一种集成电路，其逻辑功能由访问方对器件编程来确定。由设计人员自行编程来把一个数字装置“集成”在一片PLD上，而不需要请芯片制造厂商来设计和制作专用的集成电路芯片。而且，如今，取代手工地制作集成电路芯片，这种编程也多半改用“逻辑编译器(logic compiler)”软件来实现，它与程序开发撰写时所用的软件编译器相类似，而要编译之前的原始代码也得用特定的编程语言来撰写，此称之为硬件描述语言(Hardware Description Language，HDL)，而HDL也并非仅有一种，而是有许多种，如ABEL(Advanced Boolean Expression Language)、AHDL(Altera Hardware Description Language)、Confluence、CUPL(Cornell University Programming Language)、HDCal、JHDL(Java Hardware Description Language)、Lava、Lola、MyHDL、PALASM、RHDL(Ruby Hardware Description Language)等，目前最普遍使用的是VHDL(Very-High-Speed Integrated Circuit Hardware Description  Language)与Verilog。本领域技术人员也应该清楚，只需要将方法流程用上述几种硬件描述语言稍作逻辑编程并编程到集成电路中，就可以很容易得到实现该逻辑方法流程的硬件电路。
因此，本申请实施例所提出的方法流程可以以硬件方式实现，例如，使用控制器，控制器控制触摸屏以实现本申请实施例所提出的方法流程。
控制器可以按任何适当的方式实现，例如，控制器可以采取例如微处理器或处理器以及存储可由该(微)处理器执行的计算机可读程序代码(例如软件或固件)的计算机可读介质、逻辑门、开关、专用集成电路(Application Specific Integrated Circuit，ASIC)、可编程逻辑控制器和嵌入微控制器的形式，控制器的例子包括但不限于以下微控制器：ARC 625D、Atmel AT91SAM、Microchip PIC18F26K20以及Silicone Labs C8051F320，存储器控制器还可以被实现为存储器的控制逻辑的一部分。本领域技术人员也知道，除了以纯计算机可读程序代码方式实现控制器以外，完全可以通过将方法步骤进行逻辑编程来使得控制器以逻辑门、开关、专用集成电路、可编程逻辑控制器和嵌入微控制器等的形式来实现相同功能。因此这种控制器可以被认为是一种硬件部件，而对其内包括的用于实现各种功能的装置也可以视为硬件部件内的结构。或者甚至，可以将用于实现各种功能的装置视为既可以是实现方法的软件模块又可以是硬件部件内的结构。
与上述实施例对应，本申请还提供了一种电子设备。电子设备包括用于存储计算机程序指令的存储器和用于执行程序指令的处理器，其中，当该计算机程序指令被该处理器执行时，触发电子设备执行如本申请实施例所述的方法步骤。
本申请还提供一种计算机程序产品，计算机程序产品包括计算机程序，当其在计算机上运行时，使得计算机执行本申请实施例提供的部分或全部步骤。
本领域的技术人员可以清楚地了解到本发明实施例中的技术可借助软件加必需的通用硬件平台的方式来实现。基于这样的理解，本发明实施例中的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品可以存储在存储介质中，如ROM/RAM、磁碟、光盘等，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本发明各个实施例或者实施例的某些部分所述的方法。
本说明书中各个实施例之间相同相似的部分互相参见即可。尤其，对于装置实施例和终端实施例而言，由于其基本相似于方法实施例，所以描述的比较简单，相关之处参见方法实施例中的说明即可。

Claims (15)

  1. 一种升级操作系统的方法，其特征在于，应用于电子设备，所述电子设备包括处理器以及存储器，所述存储器包括基础分区、第一静态分区、第二静态分区、动态分区以及用户数据分区，所述电子设备当前的分区表为对应第一操作系统的第一分区表，所述电子设备启动后加载所述基础分区、所述第一静态分区以及动态分区的数据以运行所述第一操作系统，所述第一操作系统运行之后，所述方法包括：
    获取操作系统升级包，所述操作系统升级包包括对应第二操作系统的第二分区表以及操作系统升级数据，所述操作系统升级数据用于将所述第一操作系统升级到所述第二操作系统，其中，在所述第二分区表以及所述第一分区表中，名称相同的分区的地址配置一致；
    触发所述电子设备的第一次重启，在所述第一次重启之后，所述电子设备进入恢复模式；
    在所述恢复模式下，将所述电子设备的分区表更新为所述第二分区表；
    触发所述电子设备的第二次重启，在所述第二次重启之后，所述电子设备加载所述基础分区、所述第一静态分区以及动态分区的数据以运行所述第一操作系统；
    根据所述操作系统升级数据升级所述电子设备的操作系统，将所述第一操作系统升级为所述第二操作系统。
  2. 根据权利要求1所述的方法，其特征在于，所述重启所述电子设备，进入恢复模式之前，所述方法还包括：
    执行分区表更新准备操作，所述分区表更新准备操作用于配置所述电子设备在所述恢复模式下的执行流程。
  3. 根据权利要求2所述的方法，其特征在于，所述执行分区表更新准备操作，包括：
    将所述第二分区表保存到缓存；
    在所述缓存中写入第一控制命令，所述第一控制命令对应第一操作流程，所述第一操作流程用于将所述电子设备的分区表更新为所述第二分区表。
  4. 根据权利要求3所述的方法，其特征在于，所述第一操作流程包括：
    校验所述第二分区表；
    所述第二分区表校验成功后，验证所述第二分区表以及所述第一分区表中，名称相同的分区的地址配置是否一致；
    当所述第二分区表以及所述第一分区表中，名称相同的分区的地址配置一致时，使用所述第二分区表更新所述电子设备的分区表。
  5. 根据权利要求3所述的方法，其特征在于，所述在所述恢复模式下，将所述电子设备的分区表更新为所述第二分区表，包括：
    加载所述缓存中的所述第二分区表以及所述第一控制命令；
    解析所述第一控制命令，根据所述第一控制命令调用所述第一操作流程的执行代码；
    执行所述第一操作流程的执行代码。
  6. 根据权利要求2～5中任一项所述的方法，其特征在于，所述执行分区表更新准备操作之前，所述方法还包括：
    确认所述操作系统升级包是否用于更新分区；
    当所述操作系统升级包用于更新分区时，确认所述电子设备的分区表是否已基于所述第二分区表进行过更新；
    当所述电子设备的分区表未基于所述第二分区表进行过更新时，执行所述分区表更新准备操作。
  7. 根据权利要求6所述的方法，其特征在于，所述确认所述操作系统升级包是否用于更新分区，包括：
    解析所述操作系统升级包对应的描述文件，当所述描述文件中包含分区升级包标志时，所述操作系统升级包用于更新分区。
  8. 根据权利要求6所述的方法，其特征在于：
    所述确认所述电子设备的分区表是否已基于所述第二分区表进行过更新，其中，根据分区更新标志位的状态确认所述电子设备的分区表是否已基于所述第二分区表进行过更新，在所述获取操作系统升级包之前，所述分区更新标志位的状态为未更新；
    所述在所述恢复模式下，将所述电子设备的分区表更新为所述第二分区表，包括，将所述分区更新标志位的状态设置为已更新；
    所述根据所述操作系统升级数据升级所述电子设备的操作系统，将所述第一操作系统升级为所述第二操作系统，包括，将所述分区更新标志位的状态设置为未更新。
  9. 根据权利要求6～8中任一项所述的方法，其特征在于，在所述根据所述操作系统升级数据升级所述电子设备的操作系统之前，所述方法还包括：
    在所述第二次重启之后，在所述第一操作系统运行之后，再次确认所述电子设备的分区表是否已基于所述第二分区表进行过更新；
    当确认所述电子设备的分区表已基于所述第二分区表进行过更新时，根据所述操作系统升级数据升级所述电子设备的操作系统。
  10. 根据权利要求9所述的方法，其特征在于，所述第一操作系统包括第一升级包获取工具以及第一升级引擎，所述第一操作系统运行之后，所述方法包括：
    所述第一升级包获取工具获取所述操作系统升级包；
    所述第一升级包获取工具确认所述操作系统升级包是否用于更新分区；
    当所述操作系统升级包用于更新分区时，所述第一升级包获取工具确认所述电子设备的分区表是否已基于所述第二分区表进行过更新；
    当所述电子设备的分区表未基于所述第二分区表进行过更新时，所述第一升级包获取工具执行所述分区表更新准备操作；
    所述第一升级包获取工具记录第一升级流程断点，所述第一升级流程断点对应所述确认所述电子设备的分区表是否已基于所述第二分区表进行过更新；
    所述第一升级包获取工具触发所述第一次重启；
    所述第一次重启之后，所述电子设备进入所述恢复模式，在所述恢复模式下，所述电子设备的分区表被更新为所述第二分区表，之后，所述电子设备的分区表已基于所述第二分区表进行过更新；
    在所述恢复模式下，触发所述第二次重启；
    所述第二次重启之后，所述电子设备加载所述基础分区、所述第一静态分区以及动态分区的数据以运行所述第一操作系统；
    所述第一操作系统运行之后，所述第一升级包获取工具读取所述第一升级流程断点，再次确认所述电子设备的分区表是否已基于所述第二分区表进行过更新；
    当所述第一升级包获取工具确认所述电子设备的分区表已基于所述第二分区表进行过更 新，所述第一升级包获取工具触发所述第一升级引擎根据所述操作系统升级数据升级所述电子设备的操作系统。
  11. 根据权利要求9所述的方法，其特征在于，所述第一操作系统包括第二升级包获取工具以及第二升级引擎，所述第一操作系统运行之后，所述方法包括：
    所述第二升级包获取工具获取所述操作系统升级包；
    所述第二升级包获取工具触发所述第二升级引擎进入升级流程；
    所述第二升级引擎确认所述操作系统升级包是否用于更新分区；
    当所述操作系统升级包用于更新分区时，所述第二升级引擎确认所述电子设备的分区表是否已基于所述第二分区表进行过更新；
    当所述电子设备的分区表未基于所述第二分区表进行过更新时，所述第二升级引擎执行所述分区表更新准备操作；
    所述第二升级引擎向所述第二升级包获取工具返回所述分区表更新准备操作执行完成的状态信息；
    所述第二升级包获取工具记录第二升级流程断点，所述第二升级流程断点对应所述第二升级包获取工具触发所述第二升级引擎进入升级流程；
    所述第二升级包获取工具触发所述电子设备的第三重启；
    所述第三重启之后，所述电子设备进入所述恢复模式，在所述恢复模式下，所述电子设备的分区表被更新为所述第二分区表，之后，所述电子设备的分区表已基于所述第二分区表进行过更新；
    在所述恢复模式下，触发所述电子设备的第四重启；
    所述第四重启之后，所述电子设备加载所述基础分区、所述第一静态分区以及动态分区的数据以运行所述第一操作系统；
    所述第一操作系统运行之后，所述第二升级包获取工具读取所述第二升级流程断点，再次触发所述第二升级引擎进入升级流程；
    所述第二升级引擎再次确认所述操作系统升级包是否用于更新分区；
    当所述操作系统升级包用于更新分区时，所述第二升级引擎再次确认所述电子设备的分区表是否已基于所述第二分区表进行过更新；
    当所述电子设备的分区表未基于所述第二分区表进行过更新时，所述第二升级引擎根据所述操作系统升级数据升级所述电子设备的操作系统。
  12. 根据权利要求1所述的方法，其特征在于，所述操作系统升级数据还包括静态分区升级数据以及动态分区升级数据，所述根据所述操作系统升级数据升级所述电子设备的操作系统，包括：
    基于所述静态分区升级数据升级所述第二静态分区的数据；
    在所述用户数据分区中创建虚拟动态分区，将所述动态分区升级数据写入到所述虚拟动态分区；
    将所述电子设备的启动顺序由从所述第一静态分区启动，修改为从所述第二静态分区启动；
    触发所述电子设备的第三次重启；
    在所述第三次重启之后，所述电子设备加载所述基础分区、所述第二静态分区、所述动态分区以及所述虚拟动态分区的数据以运行所述第二操作系统；
    在所述第二操作系统运行后，将所述虚拟动态分区的数据落盘到所述动态分区。
  13. 一种电子设备，其特征在于，所述电子设备包括处理器以及存储器，所述存储器包括基础分区、第一静态分区、第二静态分区、动态分区以及用户数据分区，所述动态分区包括多个子分区，所述处理器用于执行所述存储器上存储的软件代码，以使得所述电子设备启动后加载所述基础分区、所述第一静态分区以及所述动态分区的数据以运行第一操作系统；
    并且，在所述第一操作系统运行之后，使得所述电子设备执行如权利要求1～12中任一项所述的方法流程。
  14. 一种计算机可读存储介质，其特征在于，所述计算机可读存储介质中存储有计算机程序，当其在计算机上运行时，使得计算机执行如权利要求1～12中任一项所述的方法。
  15. 一种计算机程序产品，其特征在于，所述计算机程序产品包括计算机程序，当其在计算机上运行时，使得计算机执行如权利要求1～12中任一项所述的方法。
PCT/CN2022/094139 2021-07-30 2022-05-20 一种操作系统升级方法、设备、存储介质及计算机程序产品 WO2023005370A1 (zh)

Priority Applications (2)

Application Number Priority Date Filing Date Title
US18/247,315 US20230229424A1 (en) 2021-07-30 2022-05-20 Operating System Upgrade Method and Device, Storage Medium, and Computer Program Product
EP22847982.0A EP4202649A4 (en) 2021-07-30 2022-05-20 OPERATING SYSTEM UPGRADE METHOD, DEVICE, STORAGE MEDIUM AND COMPUTER PROGRAM PRODUCT

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN202110872080.XA CN115686584B (zh) 2021-07-30 2021-07-30 一种操作系统升级方法、设备、存储介质及计算机程序产品
CN202110872080.X 2021-07-30

Publications (1)

Publication Number Publication Date
WO2023005370A1 true WO2023005370A1 (zh) 2023-02-02

Family

ID=85058321

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2022/094139 WO2023005370A1 (zh) 2021-07-30 2022-05-20 一种操作系统升级方法、设备、存储介质及计算机程序产品

Country Status (4)

Country Link
US (1) US20230229424A1 (zh)
EP (1) EP4202649A4 (zh)
CN (2) CN117873511A (zh)
WO (1) WO2023005370A1 (zh)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN117707566A (zh) * 2023-08-23 2024-03-15 荣耀终端有限公司 一种操作系统升级方法及电子设备

Families Citing this family (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20240028456A1 (en) * 2022-07-22 2024-01-25 Vmware, Inc Unattended snapshot reversion for upgrades
CN117707565A (zh) * 2023-07-12 2024-03-15 荣耀终端有限公司 终端设备及其升级方法
CN116701318B (zh) * 2023-08-09 2023-12-15 荣耀终端有限公司 系统升级信息获取方法、电子设备及存储介质
CN116841575B (zh) * 2023-09-01 2023-11-24 荣耀终端有限公司 生成镜像文件的方法及相关装置
CN117687663B (zh) * 2024-02-04 2024-04-16 湖北芯擎科技有限公司 基于ota的分区动态调整方法、装置、设备及存储介质
CN117834649B (zh) * 2024-03-01 2024-07-23 荣耀终端有限公司 数据传输方法及相关装置

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN103176824A (zh) * 2013-03-15 2013-06-26 青岛海信移动通信技术股份有限公司 一种系统升级的方法及装置
CN105630548A (zh) * 2015-12-22 2016-06-01 小米科技有限责任公司 系统更新方法及装置
CN106484450A (zh) * 2015-08-28 2017-03-08 青岛海信移动通信技术股份有限公司 一种软件升级方法及装置
CN106708543A (zh) * 2015-07-22 2017-05-24 Tcl集团股份有限公司 一种操作系统的ota升级方法及装置
CN107643898A (zh) * 2016-07-21 2018-01-30 中兴通讯股份有限公司 终端升级方法及装置

Family Cites Families (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9329802B2 (en) * 2013-11-11 2016-05-03 Qualcomm Incorporated Fail safe refresh of data stored in NAND memory device
US9569195B2 (en) * 2014-05-13 2017-02-14 Zscaler, Inc. Systems and methods for live operating system upgrades of inline cloud servers
CN107885535A (zh) * 2017-11-08 2018-04-06 青岛海信电器股份有限公司 一种系统启动方法、系统切换方法及装置
CN110704090B (zh) * 2018-07-09 2022-09-30 阿里巴巴集团控股有限公司 现场可编程门阵列fpga及其升级方法和升级系统
CN112783537B (zh) * 2020-12-31 2023-03-03 浙江万胜智能科技股份有限公司 基于MTD存储设备的嵌入式linux操作系统升级方法及系统

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN103176824A (zh) * 2013-03-15 2013-06-26 青岛海信移动通信技术股份有限公司 一种系统升级的方法及装置
CN106708543A (zh) * 2015-07-22 2017-05-24 Tcl集团股份有限公司 一种操作系统的ota升级方法及装置
CN106484450A (zh) * 2015-08-28 2017-03-08 青岛海信移动通信技术股份有限公司 一种软件升级方法及装置
CN105630548A (zh) * 2015-12-22 2016-06-01 小米科技有限责任公司 系统更新方法及装置
CN107643898A (zh) * 2016-07-21 2018-01-30 中兴通讯股份有限公司 终端升级方法及装置

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
See also references of EP4202649A4 *

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN117707566A (zh) * 2023-08-23 2024-03-15 荣耀终端有限公司 一种操作系统升级方法及电子设备
CN117707566B (zh) * 2023-08-23 2024-10-22 荣耀终端有限公司 一种操作系统升级方法及电子设备

Also Published As

Publication number Publication date
CN117873511A (zh) 2024-04-12
CN115686584A (zh) 2023-02-03
EP4202649A4 (en) 2024-06-19
EP4202649A1 (en) 2023-06-28
CN115686584B (zh) 2023-11-17
US20230229424A1 (en) 2023-07-20

Similar Documents

Publication Publication Date Title
WO2023005370A1 (zh) 一种操作系统升级方法、设备、存储介质及计算机程序产品
WO2022262751A1 (zh) 操作系统升级方法、设备、存储介质及计算机程序产品
WO2022262744A1 (zh) 操作系统升级方法、设备、存储介质及计算机程序产品
WO2022262754A1 (zh) 操作系统数据更新方法、设备、存储介质及程序产品
WO2022262753A1 (zh) 操作系统启动方法、设备、存储介质及计算机程序产品
CN113821221B (zh) 安装操作系统的方法、设备及存储介质
WO2023130946A1 (zh) 操作系统升级方法、电子设备、存储介质及芯片系统
WO2022262748A1 (zh) 操作系统的管理方法、设备、存储介质及计算机程序产品
CN114489813B (zh) 配置操作系统制式的方法、设备及存储介质
CN114461257B (zh) 操作系统数据配置方法、设备、存储介质及程序产品
CN113805956B (zh) 操作系统的配置方法、设备及存储介质
WO2023005371A1 (zh) 配置操作系统制式的方法、设备及存储介质
CN116594639A (zh) 系统安装包的管理方法、设备、存储介质及程序产品
CN113821234B (zh) 操作系统升级方法、设备、存储介质及计算机程序产品
CN115562695B (zh) 操作系统升级方法、电子设备、存储介质及芯片系统
CN117707566B (zh) 一种操作系统升级方法及电子设备
US20240378043A1 (en) Operating System Upgrading Method, Electronic Device, Storage Medium, and Chip System
CN116450169A (zh) 操作系统升级方法、电子设备、存储介质及芯片系统

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 22847982

Country of ref document: EP

Kind code of ref document: A1

ENP Entry into the national phase

Ref document number: 2022847982

Country of ref document: EP

Effective date: 20230323

NENP Non-entry into the national phase

Ref country code: DE