Operation system upgrading method and device and storage medium

Abstract

The invention discloses an operating system upgrading method and device and a storage medium. The method can be applied to wireless communication equipment such as a mobile phone and a tablet personal computer. The electronic equipment can migrate other sub-partitions behind the free storage space forwards after all operating system upgrading data are written in, so that the scattered free storage space is avoided. After migration of all the dynamic partition sub-partitions is completed, the electronic device may reduce the size of the dynamic partition while increasing the size of the user data partition. Therefore, after the demand of the dynamic partition on the storage space is reduced, the electronic equipment can distribute the storage space originally distributed to the dynamic partition to the user data partition, namely, the size of the user data partition is improved, so that the user data storage capability of the electronic equipment is improved, and the user experience is improved.

Description

Operating system upgrade method, device and storage medium

[0001] This application claims priority to the Chinese patent application filed with the China Patent Office on December 5, 2022, with application number 202211549764.7 and application name “Operating system upgrade method, device and storage medium”, the entire contents of which are incorporated by reference into this application. Technical Field

[0002] The present application relates to the field of terminals, and in particular to an operating system upgrade method, device, and storage medium. Background Art

[0003] Over-the-Air Technology (OTA) is a technology that enables remote operating system version updates for wireless communication devices through the wireless network interface of the wireless communication device.

[0004] In the virtual A / B-OTA upgrade strategy, data partitions such as System, Product, Version, and Preload are combined into a dynamic partition (Super). Without changing the size of the dynamic partition (Super), the wireless communication device can adjust the size of each sub-partition within the dynamic partition (such as System, Product, Version, and Preload) to meet the needs of the new operating system version, to expand or shrink each sub-partition.

[0005] During some version updates, the storage space usage of the updated dynamic partition (Super) is significantly reduced, but this storage space cannot be used to store user data, resulting in a waste of storage resources.

[0006] Summary of the Invention

[0007] This application provides an operating system upgrade method, device, and storage medium. The operating system upgrade method provided in this application can be used on wireless communication devices such as mobile phones and tablet computers. By implementing this method, after the operating system is upgraded, the electronic device can modify the size of the dynamic partition (Super) and user data partition (Userdata) based on the size of the upgraded operating system, flexibly adjusting the storage capacity of the electronic device.

[0008] In a first aspect, the present application provides an operating system upgrade method, which is applied to an electronic device, wherein the memory of the electronic device includes a first partition and a second partition, the first partition is used to store first data of a first operating system installed on the electronic device, and the second partition is used to store user data. The memory also includes a first partition table and a first metadata, the first partition table is used to record partition information of multiple partitions in the memory, the multiple partitions include the first partition and the second partition, and the first metadata is used to store partition information of one or more sub-partitions in the first partition. The method includes: obtaining upgrade data, the upgrade data includes second data of the second operating system, second metadata, and a second partition table, the second data corresponds to the first data, the second metadata records the partition information of one or more sub-partitions in the first partition corresponding to the second data, and the second partition table records the partition information of multiple partitions in the memory corresponding to the second operating system; writing the second data to the first partition; writing the second metadata to replace the first metadata; and writing the second partition table to replace the first partition table.

[0009] By implementing the method provided in the first aspect, the electronic device can obtain a system upgrade package including the system data of the new system, the second metadata, and the second partition table. After writing the system data of the new system, the electronic device can replace the electronic device's current first metadata and first partition table with the second metadata and second partition table in the system upgrade package, thereby adjusting the electronic device's memory partitions.

[0010] In combination with the method provided in the first aspect, in some embodiments, the size of the first partition recorded in the second partition table is smaller than the size of the first partition recorded in the first partition table, and the size of the second partition recorded in the second partition table is larger than the size of the second partition recorded in the first partition table; after writing the second partition table to replace the first partition table, the first partition of the memory is reduced and the second partition is increased.

[0011] By implementing the method provided in the above embodiment, the size of the user data partition indicated by the second partition table can be larger than the size of the user data partition indicated by the current first partition table. After the first partition table is replaced with the second partition table, the user data partition of the electronic device memory can be increased according to the indication of the second partition table, thereby improving the electronic device's ability to store user data.

[0012] In combination with the method provided in the first aspect, in some embodiments, writing the second metadata to replace the first metadata specifically includes: after writing the second data stored in the first partition to the second partition, writing the second metadata to replace the first metadata; after the replacement, writing the second data cached in the second partition back to the first partition; writing the second partition table to replace the first partition table specifically includes: after writing the second data cached in the second partition back to the first partition, writing the second partition table to replace the first partition table.

[0013] By implementing the method provided in the above embodiment, before updating the metadata of the first partition of the memory, the electronic device can uniformly move the system data of the new system stored in the first partition to the second partition. After the metadata of the first partition is updated by replacing the first metadata with the second metadata, the electronic device can move the previously cached system data of the new system from the second partition back to the first partition. In this way, the partition information of the sub-partitions of the first partition indicated by the updated second metadata matches the sub-partition data actually stored in the first partition.

[0014] In combination with the method provided in the first aspect, in some embodiments, writing the second data to the first partition specifically includes: writing the first sub-partition data in the second data to the first sub-partition in the first partition, the first sub-partition is a sub-partition in the first partition that includes multiple discontinuous storage blocks, and the first sub-partition data is stored in multiple discontinuous storage blocks; writing the second data stored in the first partition to the second partition specifically includes: writing the first sub-partition data stored on the first storage block to the third storage block of the second partition; writing the first sub-partition data stored on the second storage block to the fourth storage block of the second partition; the first storage block and the second storage block are two discontinuous storage blocks in the first sub-partition, and the third storage block and the fourth storage block are two continuous storage blocks in the second partition.

[0015] By implementing the method provided in the above embodiment, when a sub-partition in the updated first partition is expanded from a single continuous storage block to multiple discontinuous storage blocks, the electronic device can use the device mapper to continuously read the sub-partition data stored in the discontinuous storage blocks at one time and write them to the second partition. In this way, the electronic device can consolidate the discontinuously stored sub-partition data into a single block of continuously stored sub-partition data and align it with the second metadata.

[0016] In combination with the method provided in the first aspect, in some embodiments, writing the second data stored in the first partition to the second partition specifically includes: writing the second data stored in the first partition to the first area of ​​the second partition, where the first area is at the end of the second partition.

[0017] Implementing the method provided in the above embodiment and writing the second data stored in the first partition to the end of the second partition is conducive to more secure caching of the second data, avoiding data loss after partition table adjustment and data loss caused by abnormal power failure during data migration.

[0018] In combination with the method provided in the first aspect, in some embodiments, writing the second metadata to replace the first metadata specifically includes: moving the data in the second subpartition in the first partition from the second area of ​​the first partition to the third area, the second subpartition is a subpartition after the third subpartition, and the third subpartition is a subpartition whose subpartition size is reduced after the second data is written to the first partition; after moving forward, writing the second metadata to replace the first metadata.

[0019] When implementing the method provided in the above embodiment, the electronic device may also shift the sub-partition data following the sub-partition whose size was reduced after the second data was written forward to fill the free storage space. The electronic device may then update the metadata of the first partition with the second metadata. The partition information of the sub-partitions of the first partition indicated by the updated second metadata matches the sub-partition data actually stored in the first partition after the shift.

[0020] In combination with the method provided in the first aspect, in some embodiments, writing the second data to the first partition specifically includes: writing the second data to the second partition in the form of a copy-on-write COW file to obtain third data; and writing the third data to the first partition.

[0021] In combination with the method provided in the first aspect, in some embodiments, before writing the second data to the first partition, the method also includes: performing a restart operation and entering a recovery mode for restoring factory settings upon restart; writing the second data to the first partition, writing the second metadata to replace the first metadata, and writing the second partition table to replace the first partition table are completed in recovery mode.

[0022] By implementing the method provided in the above embodiment, the electronic device can enter recovery mode after restarting, complete the copy and merge operations of the operating system upgrade, and complete the partition resizing operation after the upgrade in recovery mode. In addition, in recovery mode, the electronic device can also change the system mode to match the new operating system.

[0023] In combination with the method provided in the first aspect, in some embodiments, the first partition is a dynamic partition in the Android system; and the second partition is a user data partition in the Android system.

[0024] In combination with the method provided in the first aspect, in some embodiments, the first operating system is a demonstration machine operating system; and the second operating system is a commercial machine operating system.

[0025] During the upgrade process from the demo machine to the commercial machine, the commercial machine's dynamic partition data significantly decreases, and the storage space required for the corresponding dynamic partition also decreases. At this time, based on the characteristic of the dynamic partition reduction of the upgraded commercial machine operating system, the electronic device can convert the storage space used for the dynamic partition before the upgrade into the user data partition, thereby expanding the user data partition, improving the electronic device's ability to store user data and enhancing the user experience.

[0026] In a second aspect, the present application provides an electronic device comprising one or more processors and one or more memories; wherein the one or more memories are coupled to the one or more processors, and the one or more memories are used to store computer program code, and the computer program code comprises computer instructions. When the one or more processors execute the computer instructions, the electronic device executes the method described in the first aspect and any possible implementation of the first aspect.

[0027] In a third aspect, an embodiment of the present application provides a chip system, which is applied to an electronic device, and the chip system includes one or more processors, which are used to call computer instructions to enable the electronic device to execute the method described in the first aspect and any possible implementation method of the first aspect.

[0028] In a fourth aspect, the present application provides a computer-readable storage medium comprising instructions, which, when executed on an electronic device, enables the electronic device to execute the method described in the first aspect and any possible implementation of the first aspect.

[0029] In a fifth aspect, the present application provides a computer program product comprising instructions, which, when executed on an electronic device, enables the electronic device to execute the method described in the first aspect and any possible implementation of the first aspect.

[0030] It is understandable that the electronic device provided in the second aspect, the chip system provided in the third aspect, the computer storage medium provided in the fourth aspect, and the computer program product provided in the fifth aspect are all used to perform the methods provided in this application. Therefore, the beneficial effects that can be achieved can be referred to the beneficial effects of the corresponding methods and will not be repeated here. BRIEF DESCRIPTION OF THE DRAWINGS

[0031] FIG1 is a schematic diagram of memory partitioning based on a virtual A / B-OTA upgrade architecture provided in an embodiment of the present application;

[0032] FIG2 is a schematic diagram of an operating system upgrade scenario provided by an embodiment of the present application;

[0033] FIG3 is a flowchart of an operating system upgrade provided by an embodiment of the present application;

[0034] 4A-4D are schematic diagrams of memory partition changes during a set of operating system upgrades provided in an embodiment of the present application;

[0035] FIG5 is a schematic diagram of reducing the occupancy rate of dynamic partition storage space provided by an embodiment of the present application;

[0036] FIG6 is a flowchart of a partition migration provided by an embodiment of the present application;

[0037] 7A-7B are schematic diagrams of a group of partition relocations provided in an embodiment of the present application;

[0038] FIG8 is a schematic diagram of a partition migration including a variable partition provided by an embodiment of the present application;

[0039] FIG9 is a flowchart of another partition migration provided in an embodiment of the present application;

[0040] FIG10 is a schematic diagram of another partition migration including variable partitions provided in an embodiment of the present application;

[0041] FIG11 is a flowchart of another operating system upgrade provided in an embodiment of the present application;

[0042] FIG12 is a schematic diagram of the structure of an electronic device provided in an embodiment of the present application. DETAILED DESCRIPTION

[0043] The terms used in the following embodiments of the present application are only for the purpose of describing specific embodiments and are not intended to limit the present application.

[0044] The wireless communication device may be referred to as the electronic device 100. In the embodiment of the present application, the electronic device 100 may be a wireless communication device such as a mobile phone or a tablet computer. In other embodiments, the electronic device 100 may also be a desktop computer, a laptop computer, a handheld computer, a notebook computer, an ultra-mobile personal computer (UMPC), a netbook, a cellular phone, a personal digital assistant (PDA), an augmented reality (AR) device, a virtual reality (VR) device, an artificial intelligence (AI) device, a wearable device, an in-vehicle device, a smart home device, and / or a smart city device. The embodiment of the present application does not impose any particular restrictions on the specific type of the electronic device.

[0045] The electronic device 100 can remotely update the operating system version via OTA. During some version updates based on virtual A / B-OTA, the size of one or more dynamic partition (Super) subpartitions after the update is reduced, resulting in a decrease in the storage space occupancy of the overall dynamic partition (Super), resulting in a waste of storage resources.

[0046] For example, when converting a demo phone (for display, not for sale) into a commercial phone (for sale), the manufacturer needs to replace the pre-installed demo phone operating system (first operating system) with the commercial phone operating system (second operating system). The size of the dynamic partition (Super) required by the demo phone operating system is, for example, 20GB, used to store the dynamic partition data (first data) of the demo phone operating system; the size of the dynamic partition (Super) required by the commercial phone operating system is, for example, 10GB, used to store the dynamic partition data (second data) of the commercial phone operating system.

[0047] At this point, after upgrading to the commercial machine operating system, the dynamic partition (Super), originally designed to store the 20GB demo machine operating system dynamic partition data, is now used only to store the 10GB commercial machine operating system dynamic partition data. This significantly reduces the storage space utilization of the dynamic partition (Super). Since the unused storage space in the dynamic partition (Super) cannot be used to store user data, the reduced storage space utilization of the dynamic partition (Super) results in a waste of storage resources.

[0048] In order to avoid wasting storage resources and improve storage resource utilization, the present application provides an operating system upgrade method that can be applied to wireless communication devices such as mobile phones and tablet computers (ie, electronic devices 100).

[0049] When implementing the method provided in this application, during an operating system upgrade, if the size of the upgrade data written to a dynamic partition or subpartition is smaller than the size of the dynamic partition or subpartition, the electronic device 100 can reduce the size of the dynamic partition or subpartition based on the size of the written upgrade data and mark the storage space in the dynamic partition or subpartition that has not been written with the upgrade data as free (available), thereby releasing the free storage space. The free storage space is the storage space marked as free.

[0050] The dynamic partition subpartition that has been reduced can be called the target subpartition. After all operating system upgrade data has been written, the electronic device 100 can migrate (move forward) the other subpartitions after the target subpartition to fill the free storage space, thereby avoiding scattered free storage space. After all dynamic partition subpartitions have been migrated, the electronic device 100 can reduce the size of the dynamic partition while increasing the size of the user data partition (Userdata).

[0051] In this way, after the upgraded operating system reduces the demand for storage space of the dynamic partition (Super), the electronic device 100 can allocate the storage space originally allocated to the dynamic partition (Super) to the user data partition (Userdata), thereby improving the ability of the electronic device 100 to store user data and enhancing the user experience.

[0052] FIG1 is a schematic diagram of memory partitioning based on a virtual A / B-OTA upgrade architecture provided in an embodiment of the present application.

[0053] The electronic device 100 is provided with a memory. The operating system, user data, and other data of the electronic device 100 can be stored in the memory. A partition table (first partition table) is provided in the memory to describe the partition layout of the memory and define the starting address and size of each partition. The storage space corresponding to a partition is only used to store data corresponding to that partition and cannot be used to store data corresponding to other partitions. That is, it cannot be occupied by other partitions.

[0054] As shown in Figure 1, the memory partitions of the electronic device 100 include a basic partition (Common), a system partition (System), and a user data partition (Userdata). The basic partition is used to store system data that does not participate in the operating system upgrade, such as the standard (vendor_country, VC). The system partition is used to save operating system data. Upgrading the operating system of the electronic device 100 is to upgrade the data in the system partition. The user data partition is used to save user data, for example, personal data such as APPs installed by the user, pictures, documents, and videos saved by the user. Taking the system partition as an example, the storage space corresponding to the system partition is only used to store system data and cannot be used to store user data.

[0055] In the virtual A / B-OTA architecture, the system partitions include static partition (A), static partition (B) and dynamic partition (Super).

[0056] Static partition (A) is usually used to store boot programs. The structures of static partition (A) and static partition (B) correspond to each other and store corresponding system image files. The subpartition names of static partition (A) and static partition (B) are distinguished by the suffixes _a and _b. For example, static partition (A) includes bootloader_a, boot_a, vendor_boot_a, dtbo_a, and vbmeta_a; static partition (B) includes bootloader_b, boot_b, vendor_boot_b, dtbo_b, and vbmeta_b. Figure 1 only shows the bootloader and boot partitions in the static partition.

[0057] Dynamic partitions (Super) are typically used to store system-running programs. Dynamic partitions contain multiple subpartitions, such as System, Product, Version, Preload, Vendor, Cust, and Odm. Figure 1 illustrates only the System, Product, Version, and Preload subpartitions within a dynamic partition.

[0058] Exemplarily, Table 1.1 shows an exemplary first partition table for describing memory partitions in a memory:

[0059] Table 1.1

[0060] As shown in Table 1.1, the partition information of the memory partition recorded in the first partition table includes but is not limited to: partition name, first address offset, and size (partition size). The first partition table records the address range of the basic partition, for example, [0-99], the address range of the dynamic partition in the system partition, for example, [490-5999], and the address range of the user data partition, for example, [6000-79999].

[0061] The header of the dynamic partition (Super) is provided with metadata (Super_Metadata). Super_Metadata is also called the first metadata. Super_Metadata can be used to record the partition information of the sub-partitions in the dynamic partition (Super).

[0062] For example, the partition information of the dynamic partition (Super) recorded in Super_Metadata may be shown in the following table (Table 1.2):

[0063] Table 1.2

[0064] Referring to Table 1.2, the first address offset of the System subpartition in the dynamic partition (Super) on the memory is 500, and the size is 2000 (unit storage unit). This means that the 500th to 2499th storage units on the memory (a total of 2000 storage units) are the System subpartition. Similarly, the 2500th to 3499th storage units on the memory are the Product subpartition; the 3500th to 5499th storage units are the Version subpartition; the 5500th to 5999th storage units are the Preload subpartition, and so on. The dynamic partition (Super) also includes other subpartitions, such as vendor, Cust, Odm, and other subpartitions. The dynamic partition (Super) also includes free storage space for expanding the above subpartitions, etc., which are not listed here one by one.

[0065] Fig. 2 is a schematic diagram of an operating system upgrade scenario provided by an embodiment of the present application. As shown in Fig. 2, for example, the operating system currently used by the electronic device 100 is OS 1.0 (eg, a demonstration machine operating system).

[0066] The electronic device 100 may send a packet search request to the packet server to obtain an operating system upgrade package from the packet server. The packet server may store multiple operating system data packets. The packet search request may include the version number of the operating system currently used by the electronic device 100, such as OS1.0. In response to the packet search request of the electronic device 100, the packet server may determine a system upgrade package that matches the electronic device 100, such as a data packet of the operating system OS2.0 (e.g., a commercial machine operating system). OS2.0 is also called the target operating system. The packet server may return the download address of the system upgrade package to the electronic device 100. The electronic device 100 downloads the system upgrade package OS2.0 according to the download address returned by the packet server.

[0067] After acquiring the operating system upgrade package, the electronic device 100 may perform an operating system upgrade operation, and may upgrade the operating system from OS 1.0 to OS 2.0.

[0068] In an embodiment of the present application, when the electronic device 100 writes the dynamic partition data of the operating system OS2.0 to the dynamic partition (i.e., upgrades the dynamic partition data), the electronic device 100 can check the storage space occupancy of the dynamic partition (Super). When the storage space occupancy of the dynamic partition (Super) decreases, that is, a large amount of free storage space is generated, the electronic device 100 can adjust to reduce the dynamic partition (Super) and expand the user data partition (Userdata), thereby improving the electronic device 100's ability to store user data and enhancing the user experience.

[0069] FIG3 is a flowchart of an operating system upgrade provided in an embodiment of the present application.

[0070] S102. Obtain a system upgrade package, including: static partition upgrade data, dynamic partition upgrade data, Metadata2, and a second partition table.

[0071] The electronic device 100 can obtain the operating system upgrade package through the system update agent module (Update_apk_client). Update_apk_client is a tool pre-installed in the electronic device 100 for obtaining system image data (such as OS2.0 image data) from a remote image source (such as a packet capture server).

[0072] The update_apk_client can periodically initiate a search request to the package server. Alternatively, the update_apk_client can initiate a search request based on a user action. Referring to FIG2 , the search request can include the version number of the operating system currently running on the electronic device 100, such as OS 1.0. The package server can determine a matching system upgrade package, such as OS 2.0, based on the operating system version number in the search request. Subsequently, the electronic device 100 can download the system upgrade package OS 2.0 from the download address returned by the package server.

[0073] FIG4A is a schematic diagram of the data structure of the system upgrade package OS2.0 provided in an embodiment of the present application.

[0074] 4A , the system upgrade package may include static partition metadata (Metadata1), static partition upgrade data, dynamic partition metadata (Metadata2), and dynamic partition upgrade data. The static partition upgrade data (i.e., the static partition data of OS 2.0) is used to upgrade the static partition of the electronic device 100. The dynamic partition upgrade data (i.e., the dynamic partition data of OS 2.0) is used to upgrade the dynamic partition (Super) of the electronic device 100. The dynamic partition upgrade data is also called the second data. The static partition metadata (Metadata1) is used to record the partition information of the static partition of OS 2.0. The dynamic partition metadata (Metadata2) is used to record the partition information of the dynamic partition of OS 2.0.

[0075] For example, the partition information of the static partition recorded by Metadata1 may be as shown in Table 2.1; the partition information of the dynamic partition recorded by Metadata2 may be as shown in Table 2.2. Metadata2 may be referred to as the second metadata.

[0076] Table 2.1

[0077] Static partition upgrade data may include upgrade data for sub-partitions such as BootLoader and Boot. The BootLoader size can be 10. A BootLoader size of 10 indicates that the upgrade data stored in the BootLoader sub-partition requires 10 memory cells. Similarly, the Boot partition size can be 10, and so on. These are not listed here.

[0078] The data in the BootLoader subpartition in the system upgrade package can be used to upgrade the BootLoader subpartition of the static partition of the electronic device 100; the data in the Boot subpartition in the system upgrade package can be used to upgrade the Boot subpartition of the static partition of the electronic device 100.

[0079] Table 2.2

[0080] Dynamic partition upgrade data may include sub-partition upgrade data such as System, Product, Version, and Preload.

[0081] The data in the System subpartition in the system upgrade package can be used to upgrade the System subpartition of the dynamic partition (Super) of the electronic device 100; the data in the Product subpartition in the system upgrade package can be used to upgrade the Product subpartition of the dynamic partition (Super) of the electronic device 100; the data in the Version subpartition in the system upgrade package can be used to upgrade the Version subpartition of the dynamic partition (Super) of the electronic device 100; the data in the Preload subpartition in the system upgrade package can be used to upgrade the Preload subpartition of the dynamic partition (Super) of the electronic device 100, etc.

[0082] In an embodiment of the present application, the system upgrade package OS2.0 may further include a partition table (a second partition table) corresponding to the target operating system, which is used to update the partition deployment of the memory after the system upgrade.

[0083] Table 3 exemplarily shows the memory partition information recorded in the second partition table:

[0084] Table 3

[0085] The storage space required for the dynamic partition data of the target operating system OS2.0 is reduced. In this case, the size of the dynamic partition recorded in the second partition table can be reduced accordingly. As shown in Table 3, the address range of Super recorded in the second partition table can be [490-4499]. In this case, the size of Userdata can be increased. For example, the address range of Userdata can be [4500-79999].

[0086] In some embodiments, the second partition table may record the address range of each sub-partition in the static partition, so Metadata1 is optional, that is, the system upgrade may only include Metadata2 and the second partition table.

[0087] S103. Trigger Updata_engine to perform system upgrade.

[0088] S104. Verify the system upgrade package.

[0089] The Updata_engine module is a pre-installed functional module in electronic device 100 that stores system upgrade processing logic and is used to perform system upgrade operations. After obtaining a system upgrade package, the Updata_engine first verifies the system upgrade package. Specifically, this verification includes verifying the legitimacy of the system upgrade package's digital signature.

[0090] S105. Write the upgrade data in the system upgrade package: (1) Write the static partition upgrade data to the static partition (B); (2) Write the dynamic partition upgrade data, Metadata2 and the second partition table to the virtual dynamic partition of Userdata.

[0091] The electronic device 100 can be started from a static partition. Referring to FIG4B , the electronic device 100 can be started from the static partition (A): the basic partition (Common), the static partition (A), and the dynamic partition (Super) are loaded in sequence, and the currently installed operating system, such as the demonstration machine operating system OS1.0, is operated.

[0092] When the system upgrade package passes verification, Updata_engine can use the operating system upgrade data (static partition upgrade data and dynamic partition upgrade data) in the system upgrade package to upgrade the system partition.

[0093] (1) Write the static partition upgrade data to the static partition (B):

[0094] When upgrading the operating system of the electronic device 100 using the virtual A / B-OTA upgrade architecture, when booting from the static partition (A), the Updata_engine can write the static partition upgrade data in the system upgrade package to the static partition (B). As shown in Figure 4B, the electronic device 100 can write the data in the bootloader subpartition in the system upgrade package to the bootloader_b subpartition in the static partition (B) of the electronic device 100. The electronic device 100 can write the data in the boot subpartition in the system upgrade package to the boot_b subpartition in the static partition (B) of the electronic device 100.

[0095] Write operations may fail. When a write failure occurs, Updata_engine interrupts the entire operating system upgrade, displays an upgrade failure prompt to the user (for example, displays an upgrade failure dialog box), and automatically restarts the upgrade, or allows the user to decide whether to restart the upgrade or abandon the upgrade.

[0096] Updata_engine can perform data verification on the static partition (B) after executing the write operation to confirm whether the static partition upgrade data is successfully written to the static partition (B). For example, in the scenario of upgrading from OS1.0 to OS2.0, the system upgrade package may contain the static partition upgrade data of OS2.0 and the hash value of the static partition upgrade data of OS2.0. After executing the write operation, Updata_engine can calculate the hash value of the data in the static partition (B) and determine whether the hash value of the data in the static partition (B) is consistent with the hash value of the static partition upgrade data of OS2.0 recorded in the system upgrade package. If they are consistent, it means that the write is successful, and Updata_engine can perform subsequent operating system upgrade operations; if they are inconsistent, it means that the data write failed and the upgrade failed.

[0097] The Updata_engine will write the upgrade data for each static partition and subpartition contained in the system upgrade package to the corresponding subpartition in static partition (B) according to the write and verify operations described above, and verify that the data has been written correctly. If the system upgrade package does not contain the upgrade data for a static partition and subpartition, the Updata_engine will synchronize the data from the corresponding subpartition in static partition (A) to the subpartition in static partition (B). During the upgrade process, if an upgrade error occurs in a subpartition, the Updata_engine will interrupt the upgrade operation and the upgrade will fail. If all subpartitions are successfully upgraded, the Updata_engine will determine that the static partition upgrade was successful and can proceed to the next steps.

[0098] Furthermore, when a static partition fails to be upgraded, the data of the static partition cannot be used to successfully boot the operating system. At this time, in order to avoid loading a static partition that failed to be upgraded during the operating system startup process and causing an operating system startup error, the static partition can carry a status mark: bootable or not bootable. The electronic device 100 can first read the static partition status mark before loading the static partition data. When the status mark of the static partition is bootable, the electronic device 100 loads the data of the static partition. Specifically, the status mark of the static partition can be saved in the metadata ( / metadata) of the Common partition.

[0099] For example, before upgrading the static partition (B), Updata_engine may mark the static partition (B) as unbootable. After the upgrade of the static partition (B) is successful, Updata_engine may mark the static partition as bootable. In this way, if the upgrade of the static partition (B) fails, the status of the static partition (B) will remain unbootable. The electronic device 100 will not load the data of the static partition that failed to upgrade.

[0100] In the case where the system upgrade includes Metadata1, Updata_engine may write Metadata1 in the system upgrade package into the static partition.

[0101] (2) Write the dynamic partition upgrade data, Metadata2, and the second partition table to the virtual dynamic partition of Userdata:

[0102] Updata_engine can create a virtual dynamic partition in the user data partition (Userdata) and write the dynamic partition upgrade data, Metadata2, and the second partition table in the system upgrade package to the virtual dynamic partition. The electronic device 100 can use a Copy-On-Write (COW) file in the virtual dynamic partition to store the dynamic partition upgrade data. The dynamic partition upgrade data stored in the COW file can be referred to as third data.

[0103] The electronic device 100 can use the incremental upgrade method to write dynamic partition upgrade data in the virtual dynamic partition. During the system upgrade process, for compatibility reasons, in most cases, the dynamic partition data of the old version system (such as OS1.0) and the dynamic partition data of the new version system (such as OS2.0) overlap, that is, some data are the same. The electronic device 100 can determine the dynamic partition data (i.e., incremental data) included in the new version system but not included in the old version system, and write the above incremental data to the virtual dynamic partition in the form of a COW file. For example, the System subpartition of OS1.0 includes files X1 and X2. The System subpartition of OS2.0 includes files X1, X2, and X3. At this time, file X3 is the dynamic partition upgrade data (also called incremental data) included in the new version system (2.0) but not included in the old version system (1.0). When using the incremental upgrade method, the electronic device 100 can simply write the above file X3 in the form of a COW file to the virtual dynamic partition.

[0104] Alternatively, the electronic device 100 may also use a full upgrade method to write dynamic partition upgrade data. The electronic device 100 may write all dynamic partition upgrade data of the new version of the system into the virtual dynamic partition. In the above example, the electronic device 100 may write files X1, X2, and X3 in the System subpartition of OS 2.0 into the virtual dynamic partition in the form of COW files.

[0105] After successfully writing the COW file to the virtual dynamic partition in Userdata, Updata_engine changes the flush status information in the metadata partition ( / metadata) of the base partition (Common) from "Flushed (merged)" to "Not Flushed (wait for merge)". The flush status information indicates whether there are COW files that need to be flushed to the dynamic partition (Super). The flush status information includes an overall identifier for the dynamic partition (Super) and a subpartition identifier for each subpartition. If the overall identifier is "Flushed (merged)", all subpartitions of the dynamic partition (Super) do not need to be flushed to disk; if the overall identifier is "Not Flushed (wait for merge)", one or more subpartitions of the dynamic partition (Super) need to be flushed to disk; if the subpartition identifier is "Flushed (merged)", the subpartition does not need to be flushed to disk; if the subpartition identifier is "Not Flushed (wait for merge)", the subpartition needs to be flushed to disk.

[0106] FIG4C is a schematic diagram of the memory partition after the operating system upgrade data is written. As shown in FIG4C , the static partition (B) stores the static partition data of the new operating system OS2.0. The user data partition (Userdata) may include a virtual dynamic partition (V1). The virtual dynamic partition (V1) stores the dynamic partition (Super) data (third data) of the target operating system OS2.0 saved as a COW file. The virtual dynamic partition (V1) also includes sub-partitions such as System, Product, Version, and Preload. The above-mentioned sub-partitions such as System, Product, Version, and Preload respectively store the corresponding dynamic partition (Super) sub-partition data (COW files) of the new operating system OS2.0.

[0107] S106: Return the status information of the upgrade completion.

[0108] When Updata_engine executes the upgrade operation shown in S104 to S105, Update_apk_client can monitor the progress of the upgrade operation shown in S104 to S106. Electronic device 100 can display a corresponding progress control based on the progress detected by Update_apk_client to show the upgrade progress to the user.

[0109] After writing the upgrade data into the system upgrade package, that is, after executing steps S104 and S105, Updata_engine can return the status information of the upgrade completion to Update_apk_client. Correspondingly, the progress control can indicate to the user that the upgrade is complete.

[0110] S107: Trigger restart.

[0111] After receiving the status information returned by Updata_engine that the upgrade is complete, Update_apk_client can trigger a restart. In an embodiment of the present application, preferably, after the restart is triggered, the electronic device 100 can automatically enter the restart program. In other embodiments, the electronic device 100 can also determine whether to restart immediately based on user operations. For example, the electronic device 100 can display a pop-up window on the screen, prompting the user to choose to restart immediately or restart later. If the user chooses to restart later, the user can further specify the time to restart, such as 12 o'clock that night. The electronic device 100 can enter the restart program and perform the restart operation when the restart time specified by the user arrives.

[0112] When the electronic device 100 is restarted, it can start from the static partition (B) and run the updated operating system, that is, the target operating system OS2.0 mentioned above. The status mark "bootable" of the static partition (B) recorded in the Common partition can indicate that the electronic device 100 starts from the static partition (B). The disk status information "not flushed to disk" in the metadata ( / metadata) in the Common partition can indicate that the electronic device 100, after loading the static partition (B), merges the dynamic partition (Super) and the virtual dynamic partition through snapshot.

[0113] In the upgrade method shown in Figure 3, the electronic device 100 can be restarted into the Android mode by executing the restart shown in S107. In the Android mode, the user can use the electronic device 100 to make calls, take photos, browse web pages, watch videos, etc.

[0114] S108: Execute a merge operation to write the dynamic partition upgrade data in the virtual dynamic partition into the dynamic partition (Super).

[0115] Referring to the introduction of S105, after the dynamic partition upgrade data is written to the virtual dynamic partition of the user data partition (Userdata), Updata_engine can change the disk status information in the metadata partition ( / metadata) of the basic partition (Common) from "merged" to "wait for merge", indicating that there is currently a COW file that needs to be written to the dynamic partition (Super).

[0116] After restarting, according to the disk status information "not yet written to disk (wait for merge)", Updata_engine can determine to perform the disk (merge) operation. In the embodiment of the present application, the disk merge operation refers to: during the operating system upgrade process, the dynamic partition (Super) upgrade data saved in the form of a COW file in the virtual dynamic partition on the user data partition (Userdata) is written to the dynamic partition (Super), so that the dynamic partition (Super) completes the data upgrade operation. When restarting after completing the merge, the electronic device 100 only needs to load the dynamic partition (Super) to complete the device startup, and there is no need to load the dynamic partition (Super) and the virtual dynamic partition.

[0117] Specifically, Updata_engine may write the COW files of each sub-partition in the virtual dynamic partition into the corresponding sub-partition in the dynamic partition (Super), so that the data of each sub-partition in the dynamic partition (Super) is updated to the system data of the new operating system OS2.0.

[0118] 4C , the electronic device 100 can write the upgrade data (second data) in the System subpartition in the virtual dynamic partition (V1) into the System subpartition in the dynamic partition (Super). Similarly, the electronic device 100 can write the upgrade data in the Product, Version, and Preload subpartitions in the virtual dynamic partition (V1) into the Product, Version, and Preload subpartitions in the dynamic partition (Super) in sequence.

[0119] After writing the COW file of the virtual dynamic partition to the corresponding address in the dynamic partition (Super), Updata_engine can delete the COW file in the user data partition (Userdata) and return the corresponding storage space to the user data partition (Userdata). At the same time, Updata_engine can change the disk status information in the metadata ( / metadata) of the basic partition (Common) from "Not yet merged (wait for merge)" to "Merged (merged)".

[0120] After writing the upgrade data, the electronic device 100 can update the partition information of each sub-partition in the Super_Metadata based on the size of each sub-partition after writing. For example, in Figure 4D, after performing the merge operation, the Super_Metadata recording the partition information of the sub-partitions in the dynamic partition can be updated from the Super_Metadata (1.0) corresponding to OS 1.0 to the Super_Metadata (2.0) corresponding to OS 2.0.

[0121] S109: Execute a copy operation to write the data in the static partition (B) into the static partition (A).

[0122] Referring to Figure 4C, Updata_engine can write the data of each sub-partition in static partition (B) into the corresponding sub-partition of static partition (A) in sequence according to the addresses of the corresponding sub-partitions in static partition (A) and static partition (B), thereby completing the data synchronization of static partition (A) and static partition (B).

[0123] In S108, the merge operation is performed on the operating system data in the dynamic partition (Super) and does not affect the operating system data in the virtual dynamic partition currently being used for booting. In S109, the copy operation is performed on the operating system data in the static partition (A) and does not affect the operating system data in the static partition (B) currently being used for booting. Therefore, users can use the device normally throughout the entire operating system upgrade process.

[0124] Figure 4D shows a schematic diagram of memory partitions after the operating system upgrade. At this point, the dynamic partition (Super) stores the system data for the new version of OS 2.0. Super_Metadata records the partition information for each sub-partition of the new version of the operating system. From then on, the electronic device 100 can run the new operating system OS 2.0 each time it boots up.

[0125] 4D , the user data partition (Userdata) of the memory may further include Metadata2 and a second partition table. Metadata2 and the second partition table may be used to subsequently adjust the size of the dynamic partition (Super) and the user data partition (Userdata).

[0126] S110. Check the storage space occupancy of the dynamic partition (Super). When the storage space occupancy of the dynamic partition (Super) decreases, reduce the dynamic partition (Super) and expand the user data partition (Userdata).

[0127] During some upgrade processes, such as upgrading from a demo machine operating system to a commercial machine operating system, the storage space occupancy of the dynamic partition (Super) may be significantly reduced.

[0128] FIG5 is a schematic diagram of reducing the storage space occupancy of a dynamic partition (Super) provided by an embodiment of the present application. (5a) in FIG5 exemplarily shows the address ranges of the memory partitions and their sub-partitions of the electronic device 100 before the upgrade. Referring to (5a) in FIG5 , the address range of the dynamic partition (Super) of the electronic device 100 can be [490-5999], and the address range of the user data partition (Userdata) can be [6000-79999].

[0129] The dynamic partition (Super) can include sub-partitions such as System, Product, Version, and Preload, which are used to store system data of corresponding categories. Referring to Table 1.2, for example, the address ranges of the sub-partitions System, Product, Version, and Preload in the dynamic partition (Super) can be: [500-2499], [2500-3499], [3500-5499], and [5500-5999], respectively, which will not be repeated here. The partition information of each sub-partition in the above dynamic partition (Super) is stored in the Super_Metadata in the dynamic partition (Super) header.

[0130] In the process of writing dynamic partition upgrade data shown in FIG4C , the electronic device 100 may write the upgrade data in a subpartition in the virtual dynamic partition (V1) into the corresponding subpartition in the dynamic partition (Super). For example, the upgrade data in the System subpartition in the virtual dynamic partition (V1) may be written into the System subpartition in the dynamic partition (Super).

[0131] For some sub-partitions, the size of the storage space required for the upgrade data is equal to the size of the sub-partition. In this case, the size of the sub-partition does not need to be changed. For other sub-partitions, the size of the storage space required for the upgrade data is larger than the size of the sub-partition. In this case, the sub-partition needs to apply to the dynamic partition (Super) for reserved storage space for expansion or free storage space released by other sub-partitions to store the overflowed upgrade data. For still other sub-partitions, the size of the storage space required for the upgrade data is smaller than the size of the sub-partition. In this case, the electronic device 100 can reduce the size of the sub-partition.

[0132] Combined with Metadata2 of the dynamic partition upgrade data in the system upgrade package shown in Table 2.2: The upgrade data of the System sub-partition requires 2000 storage units, which is consistent with the size of the current System sub-partition of the electronic device 100. In this case, after the upgrade, the size of the System sub-partition does not need to be changed. The upgrade data of the Product sub-partition requires 1000 storage units, which is consistent with the size of the current Product sub-partition of the electronic device 100; the upgrade data of the Preload sub-partition requires 500 storage units, which is consistent with the size of the current Preload sub-partition of the electronic device 100. Therefore, after the upgrade, the sizes of the Product and Preload sub-partitions do not need to be changed.

[0133] The upgrade data of the Version subpartition requires 500 storage units. However, the size of the current Version subpartition of the electronic device 100 is 2000, which is much larger than the storage units required for the upgrade data. In this case, the electronic device 100 can reduce the size of the Version subpartition to 500. Referring to (5b) in Figure 5, the address range of the reduced Version subpartition becomes [3500-3999]. At the same time, the electronic device 100 can release the storage space [4000-5499] (i.e., free storage space) in the original Version subpartition where the upgrade data is not written.

[0134] When other subpartitions need to be expanded, the dynamic partition (Super) allocates the free storage space to the subpartitions that need to be expanded. When no other subpartitions need to be expanded, or when the total amount of storage space to be expanded is less than the total amount of free storage space, the storage space utilization of the dynamic partition (Super) decreases. In this case, the free storage space in the dynamic partition (Super) remains idle for a long time, wasting storage resources.

[0135] To avoid the aforementioned problem of wasted storage resources, after executing S109, the Updata_engine can check the storage space occupancy of the dynamic partition (Super). When the storage space occupancy of the dynamic partition (Super) decreases, i.e., when free storage space is generated, the Updata_engine will relocate one or more sub-partitions in the dynamic partition (Super) to fill the free storage space between the sub-partitions, thereby reducing the dynamic partition (Super) and expanding the user data partition (Userdata).

[0136] FIG6 is a flowchart of a partition migration provided in an embodiment of the present application.

[0137] S201: Reduce the size of a sub-partition (eg, version) to release free storage space.

[0138] As described in conjunction with FIG5 , during a merge operation, after each subpartition's upgrade data is written, electronic device 100 may adjust the subpartition's size based on the actual size of the upgrade data written to that subpartition. If the actual size of the upgrade data written to a subpartition is smaller than the subpartition's size, electronic device 100 may reduce the subpartition's size and free up storage space within the subpartition where the upgrade data has not been written. For example, see the Version subpartition in FIG5 .

[0139] Depending on the size of the upgrade data in each dynamic partition or subpartition in the system upgrade package, after the merge operation is performed, one or more subpartitions in the dynamic partition (Super) may be reduced, thereby generating one or more segments of free storage space. Here, the present embodiment of the application first uses the example of reducing a subpartition and generating a segment of free storage space to describe the partition migration method provided by the present embodiment of the application.

[0140] The Super_Metadata of the dynamic partition (Super) is used to record the partition information of the dynamic partition (Super). After reducing the sub-partition, the electronic device 100 can update the partition information of each sub-partition recorded in the Super_Metadata sub-partition accordingly. Exemplarily, the partition information of the dynamic partition (Super) recorded in the Super_Metadata can be updated from Table 1.2 to Table 4, corresponding to (5b) in Figure 5:

[0141] Table 4

[0142] For example, after reducing the Version subpartition to [3500-3999], the size of the Version subpartition recorded in the Super_Metadata subpartition can be updated to 500, and the address range can be updated to [3500-3999]. The storage space [4000-5499] released from the original Version subpartition can be marked as free storage space to allow other subpartitions to expand. When there is no need for expansion, the free storage space remains idle.

[0143] S202: The sub-partitions following the target sub-partition in the dynamic partition (Super) are moved forward in sequence to fill the storage space.

[0144] The dynamic partition subpartition that is reduced can be called the target subpartition (i.e., the third subpartition), such as the aforementioned Version subpartition. The subpartition after the target subpartition can be called the subpartition to be migrated (i.e., the second subpartition), such as the aforementioned Preload subpartition. The electronic device 100 can determine the new address range of the subpartition to be migrated based on the tail address of the reduced target subpartition and the size of the subpartition to be migrated.

[0145] Figure 7A is a schematic diagram of partition migration provided by an embodiment of the present application. As shown in Figure 7A, the Version subpartition is the target subpartition, and the subpartition Preload after the Version subpartition is the subpartition to be migrated.

[0146] First, based on the reduced Version subpartition address range [3500-3999], the electronic device 100 can determine that the tail address of the Version subpartition is 3999, that is, the first address range of the next subpartition (Preload) is determined to be 3000. Based on the size of the Preload subpartition 500, the electronic device 100 can determine that the target address range of the Preload subpartition is [4000-4499]. Therefore, the electronic device 100 can migrate the data of the Preload subpartition stored in [5500-5999] to [4000-4499] and release the storage space [5500-5999] of the Preload subpartition before the migration.

[0147] Similarly, after performing the partition migration operation, the electronic device 100 can update the partition information of each sub-partition recorded in the Super_Metadata sub-partition accordingly. For example, the partition information of the dynamic partition (Super) recorded in Super_Metadata can be updated from Table 4 to Table 5:

[0148] Table 5

[0149] Optionally, after moving the sub-partition to be migrated to the target storage space, the electronic device 100 can use Metadata2 to directly write the Super_Metadata of the current dynamic partition to update the partition information of the sub-partition recorded in the current Super_Metadata without having to separately and specifically modify the partition information of the sub-partition to be migrated in the Super_Metadata.

[0150] S203: Reduce the dynamic partition (Super) and increase the user data partition (Userdata).

[0151] 7A, after migrating the child partitions to be migrated forward, the free storage space generated by shrinking the child partitions can all be migrated to the end of the dynamic partition (Super). At this time, the electronic device 100 can shrink the dynamic partition (Super) and enlarge the user data partition (Userdata).

[0152] Specifically, the electronic device 100 can determine the tail address of the last sub-partition after the move as the tail address of the dynamic partition (Super), and set the address of the next storage unit after the above tail address (that is, the first address of the free storage space) as the first address of the user data partition (Userdata).

[0153] Referring to Table 5 or FIG. 7A , the electronic device 100 can determine that the tail address of the last sub-partition Preload is 4499, and the address of the next storage unit after the tail address of Preload is 4500. Therefore, the electronic device 100 can update the tail address of the dynamic partition (Super) to 4499 and the first address of the user data partition (Userdata) to 4500. At this time, the storage space corresponding to the dynamic partition (Super) is reduced from the original [490-5999] to [490-4499]. Correspondingly, the storage space corresponding to the user data partition (Userdata) is expanded from the original [6000-79999] to [4500-79999].

[0154] Optionally, the electronic device 100 can use the partition table in the system upgrade package (i.e., the second partition table, such as Table 3) to update the memory partition table (i.e., the first partition table) using the partition information recorded in the above-mentioned second partition, thereby reducing the dynamic partition (Super) and increasing the user data partition (Userdata) without having to separately and specifically modify the partition information of Super and Userdata.

[0155] After using Metadata2 to update the current Super_Metadata of the electronic device 100 and using the second partition table to update the memory partition table (ie, the first partition table), the electronic device 100 may clear the Metadata2 and the second partition table cached in Userdata.

[0156] By implementing the partition migration method introduced in the above embodiment, the electronic device 100 can allocate the free storage space in the upgraded dynamic partition (Super) to the user data partition (Userdata) to increase the size of the user data partition (Userdata), thereby improving the ability of the electronic device 100 to store user data, allowing users to store more user data such as videos, images, audio, etc., thereby improving the user experience.

[0157] In some upgrade scenarios, after writing the dynamic partition upgrade data, multiple sub-partitions may be reduced in the dynamic partition (Super), generating multiple segments of free storage space. In this case, the electronic device 100 can sequentially move all sub-partitions after the first sub-partition that has been reduced forward, thereby consolidating the multiple segments of free storage space into a continuous segment of free storage space and placing it at the end of the dynamic partition (Super).

[0158] Figure 7B is a schematic diagram of performing partition migration after reducing multiple sub-partitions according to an embodiment of the present application. As shown in Figure 7B, the dynamic partition (Super) may include sub-partitions System, Product, Version, Preload, and Odm. The address ranges of the above-mentioned sub-partitions are: [500-2499], [2500-3499], [3500-5499], [5500-5999], and [6000-6499]. The address range of the dynamic partition (Super) of the electronic device 100 is [490-6499], and the address range of the user data partition (Userdata) is [6500-79999].

[0159] The subpartitions that are reduced include the Version subpartition and the Preload subpartition. The Version subpartition is reduced from [3500-5499] to [3500-3999]. The Preload subpartition is reduced from [5500-5999] to [5500-5899]. The reduction of the Version and Preload subpartitions creates two free storage spaces: Free Storage Space 1 and Free Storage Space 2. The address range of Free Storage Space 1 is [4000-5499], and the address range of Free Storage Space 2 is [5900-5999].

[0160] At this time, the Preload subpartition and the Odm subpartition can be moved forward in sequence. For example, the electronic device 100 can first move the Preload subpartition from [5500-5899] to [4000-4399]. Then, the electronic device 100 can move the Odm subpartition from [6000-6499] to [4400-4899]. At the same time, the free storage space 1 and the free storage space 2 are integrated into a continuous free storage space [4900-6499].

[0161] Subsequently, electronic device 100 can reduce the dynamic partition (Super) and increase the user data partition (Userdata). Referring to Figure 7B, the storage space corresponding to the dynamic partition (Super) is reduced from the original [490-6499] to [490-4899]. Correspondingly, the storage space corresponding to the user data partition (Userdata) is expanded from the original [6500-79999] to [4900-79999].

[0162] In the example shown in FIG7B , similarly, optionally, the electronic device 100 can use Metadata2 to update the current Super_Metadata of the electronic device 100 ; and can use the second partition table to update the memory partition table (i.e., the first partition table). The above-mentioned Metadata2 and the second partition table are not reflected in the Userdata in FIG7B .

[0163] The partition migration method shown in Figure 6 has limitations: it only supports the migration of independent subpartitions. This requires that all dynamic subpartitions following the target subpartition be fixed, independent entities, or independent subpartitions. If a dynamic, variable subpartition (i.e., a non-independent subpartition) exists, it cannot be migrated, hindering the ability to shrink the dynamic subpartition (Super) and expand the user data subpartition (Userdata).

[0164] Specifically, in some upgrade scenarios, one or more subpartitions within an upgraded dynamic partition (Super) may be expanded. In this case, an independent subpartition expands from a single continuous storage block to multiple discontinuous storage blocks. These discontinuous storage blocks are interconnected. Any of these storage blocks is considered a variable partition (i.e., a non-independent subpartition).

[0165] FIG8 is a schematic diagram of a partition migration including variable partitions provided in an embodiment of the present application.

[0166] As shown in Figure 8, the dynamic partition (Super) may include sub-partitions System, Product, Version, and Preload. The address ranges of the above sub-partitions are: [500-2499], [2500-3499], [3500-5499], and [5500-5999], respectively. The dynamic partition (Super) may also reserve a portion of free storage space, which is recorded as a Reserved partition. The address range of the Reserved partition is, for example, [6000-6499], which means the partition size is 500. The address range of the dynamic partition (Super) of the electronic device 100 is [490-6499], and the address range of the user data partition (Userdata) is [6500-79999].

[0167] At this time, the first partition table of the electronic device 100 is as shown in Table 6.1:

[0168] Table 6.1

[0169] Among them, the Super_Metadata of the dynamic partition can be shown as shown in Table 6.2:

[0170] Table 6.2

[0171] The Metadata2 of the system upgrade package cached in Userdata received by the electronic device 100 may be as shown in Table 6.3:

[0172] Table 6.3

[0173] The second partition table adapted to Metadata2 in the system upgrade package can be shown in Table 6.4:

[0174] Table 6.4

[0175] As shown in Table 6.3, the storage space required for the System subpartition's upgrade data, 2200, exceeds the original System subpartition size of 2000. In this case, as shown in Figure 8, the System subpartition can first request reserved free storage space from the dynamic partition (Super) to expand the System subpartition to meet the storage requirements for the System subpartition's upgrade data. For example, the System subpartition can first request 200 storage units from the dynamic partition (Super). At this point, the System subpartition is expanded into two variable partitions: System1 [500-2499] and System2 [6000-6199]. The System subpartition comprising System1 and System2 is referred to as the first subpartition. The system data in the system upgrade package that needs to be written to the System subpartition is referred to as the first subpartition data. Simultaneously, the Version subpartition can be reduced from [3500-5499] to [3500-3999].

[0176] Because only independent subpartitions can be moved, electronic device 100 cannot move storage blocks System1 and System2 using the methods shown in Figures 7A or 7B. As shown in Figure 8, the Preload subpartition can be moved from the original [5500-5999] to [4000-4499]. However, because System2 is a removable partition, it cannot be moved. Therefore, System2's address range remains [6000-6199].

[0177] In this case, the electronic device 100 cannot reduce the size of the dynamic partition (Super) or expand the size of the user data partition (Userdata). That is, the free storage space can only be allocated to the dynamic partition (Super) and cannot be allocated to the user data partition (Userdata) for storing user data. This waste of storage resources cannot be solved.

[0178] In some embodiments, electronic device 100 can also move the storage blocks of variable partitions. However, in this case, electronic device 100 needs to modify the device mapper and Super_Metadata accordingly to ensure that electronic device 100 can correctly load the non-contiguously stored sub-partition data after the move. The device mapper records the mapping relationship between logical devices and physical devices and can be used to locate the non-contiguously stored sub-partition data.

[0179] Taking the above-mentioned System2 as an example, after moving the Preload sub-partition to [4000-4499], the electronic device 100 can move System2 from the original [6000-6199] to [4500-4699]. At the same time, the electronic device 100 can modify the device mapper to indicate that the next storage unit of the last storage unit 2499 of System1 is the first storage unit 4500 of System2. In this way, based on the mapping relationship in the device mapper, after loading System1, the electronic device 100 can jump to storage unit 4500 and continue to load the System sub-partition data in System2. Furthermore, the electronic device 100 can reduce the dynamic partition (Super) while expanding the user data partition (Userdata).

[0180] However, modifying the device mapper and Super_Metadata is complex. To avoid the above problems, an embodiment of the present application provides another partition migration method. FIG9 is a flowchart of another partition migration provided by an embodiment of the present application.

[0181] S301: Reduce the size of the sub-partition (eg, version) to release free storage space. This step can be referred to the introduction of S201 and will not be repeated here.

[0182] S302: The data of each sub-partition in the dynamic partition (Super) is mounted in sequence through the device mapper, and the above data is continuously written into the user data partition (Userdata) in units of sub-partitions.

[0183] When using the device mapper to mount the data of each sub-partition in the dynamic partition (Super), the electronic device 100 can continuously read all the data of the corresponding sub-partition according to the mapping relationship of the variable partition stored in the device mapper. After reading all the data of the sub-partition, the electronic device 100 can continue to read the next sub-partition. Similarly, the electronic device 100 can continuously read all the data of the sub-partition according to the mapping relationship of the variable partition of the next sub-partition stored in the device mapper.

[0184] In the embodiment of the present application, after reading all the data of a sub-partition, the electronic device 100 may write all the data to a continuous storage space in the user data partition (Userdata). At the same time, all the data of the next sub-partition is written to the location of the user data partition (Userdata) immediately following the previous sub-partition.

[0185] Preferably, the electronic device 100 can write the data of each sub-partition read from the dynamic partition (Super) to the end of the user data partition (Userdata). Specifically, the electronic device 100 can apply for a continuous storage space of corresponding size from the user data partition (Userdata) according to the size of the dynamic partition upgrade data in the system upgrade package, recorded as a virtual dynamic partition (V2). The virtual dynamic partition (V2) is also called the first area in the user data partition (Userdata). The virtual dynamic partition (V2) is located at the end of the user data partition (Userdata), and the size of the virtual dynamic partition (V2) is greater than or equal to the size of the dynamic partition upgrade data in the system upgrade package. Then, the electronic device 100 can start from the first address of the virtual dynamic partition (V2) and write the data of each sub-partition read through the device mapper into the virtual dynamic partition (V2) in sequence.

[0186] FIG10 is a schematic diagram of another partition migration including variable partitions provided in an embodiment of the present application.

[0187] After the upgrade, the dynamic partition (Super) can include subpartitions System, Product, Version, and Preload. The System subpartition consists of the variable partitions System1 and System2. The System subpartition that includes the variable partitions System1 and System2 can be referred to as the first subpartition. As shown in Figure 10, System1 and System2 are not contiguous in memory. Using the device mapper, the electronic device 100 can continuously read data stored in System1 and System2.

[0188] 8 , the address ranges of System1, Product, Version, Preload, and System2 are [500-2499], [2500-3499], [3500-5499], [5500-5999], and [6000-6199], respectively. The address range of the dynamic partition (Super) of the electronic device 100 is [490-6499], and the address range of the user data partition (Userdata) is [6500-79999].

[0189] In an embodiment of the present application, after upgrading to obtain a non-independent sub-partition (a sub-partition comprising multiple discontinuous storage blocks), the electronic device 100 may apply for N1 storage units from the user data partition (Userdata). N1 ≥ N2. N2 is the sum of the storage space occupied by each sub-partition in the dynamic partition (Super) after the upgrade. The electronic device 100 may determine the specific value of the above-mentioned N2 by the size of each sub-partition after the upgrade, and then determine N1. Alternatively, the electronic device 100 may determine the specific value of the above-mentioned N2 by the size of the dynamic partition described in the Metadata2 of the dynamic partition upgrade data in the system upgrade package or the target operating system OS2.0 indicated by the second partition table (the two are corresponding), and then determine N1.

[0190] In the example shown in FIG10 , the total storage space occupied by each sub-partition in the dynamic partition (Super) is 4200 (N2). For example, the electronic device 100 may apply to the user data partition (Userdata) for a virtual dynamic partition (V2) containing 10,000 (N1) storage units. The address range of the virtual dynamic partition (V2) is [70000-79999].

[0191] The electronic device 100 may first read the data of the System sub-partition and write the data of the System sub-partition to the virtual dynamic partition (V2). The System sub-partition includes variable partitions System1 and System2. When the System sub-partition is mounted through the device mapper, the electronic device 100 may first read part of the data of the System sub-partition from System1[500-2499] (the first storage block), and write the above part of the data to the virtual dynamic partition (V2) in sequence from the first address 70000 of the virtual dynamic partition (V2). After traversing System1, according to the instruction of the device mapper, the electronic device 100 may immediately jump to System2[6000-6199] (the second storage block) to read the remaining System sub-partition data, and continue to write to the virtual dynamic partition (V2). As shown in Figure 10, the System sub-partition data in System1 and System2 in the dynamic partition (Super) are written sequentially to the System sub-partition [70500-72699] (the third storage block [70500-72499] and the fourth storage block [72500-72699]) in the virtual dynamic partition (V2).

[0192] Similarly, referring to the above-mentioned System sub-partition, the electronic device 100 can sequentially mount other sub-partitions in the dynamic partition (Super) through the device mapper, and sequentially write the data of each of the above sub-partitions into the virtual dynamic partition (V2). As shown in Figure 10, the data in the Product sub-partition in the dynamic partition (Super) can be sequentially and continuously written into the Product sub-partitions [72700-73699] in the virtual dynamic partition (V2); the data in the Version sub-partition in the dynamic partition (Super) can be sequentially and continuously written into the Version sub-partitions [73700-74299] in the virtual dynamic partition (V2); and the data in the Preload sub-partition in the dynamic partition (Super) can be sequentially and continuously written into the Preload sub-partitions [74300-74799] in the virtual dynamic partition (V2).

[0193] S303: Reduce the dynamic partition (Super), expand the user data partition (Userdata), and use the Metadata2 of the dynamic partition upgrade data in the system upgrade package to update the Super_Metadata of the dynamic partition (Super) of the electronic device 100.

[0194] After all the data stored in each sub-partition in the dynamic partition (Super) are written to the user data partition (Userdata), the electronic device 100 can use the Metadata2 of the dynamic partition upgrade data in the system upgrade package to refresh the Super_Metadata of the dynamic partition (Super) of the electronic device 100. Among them, the partition information recorded in the Metadata of the dynamic partition upgrade data in the system upgrade package is consistent with the virtual dynamic partition (V2). Therefore, the electronic device 100 can use the Metadata2 of the dynamic partition upgrade data in the system upgrade package to refresh the Super_Metadata of the dynamic partition (Super) of the electronic device 100 without recalculating the size of each partition of the virtual dynamic partition (V2) and generating Metadata that describes the partition information in the virtual dynamic partition (V2).

[0195] The metadata 2 of the dynamic partition upgrade data in the system upgrade package obtained by the electronic device 100 can be referred to the introduction of the aforementioned Table 6.3, which will not be repeated here. In this way, the electronic device 100 does not need to modify the address range of a sub-partition in Super_Metadata specifically, and the discontinuous storage blocks associated with non-independent sub-partitions.

[0196] At the same time, referring to S203, the electronic device 100 can update the address range of the dynamic partition (Super) to [490-4699] and the address range of the user data partition (Userdata) to [4700-79999], thereby allocating the free storage space in the dynamic partition (Super) to the user data partition (Userdata), thereby increasing the size of the user data partition (Userdata). In this way, users can store more user data such as videos, images, and audio, improving the user experience.

[0197] In an embodiment of the present application, the electronic device 100 can directly use the second partition table in the system upgrade package cached in Userdata to replace the original first partition table without detecting the address partition of the dynamic partition after updating Metadata2.

[0198] After using Metadata2 to update the current Super_Metadata of the electronic device 100 and using the second partition table to replace the original first partition table, the electronic device 100 may clear the Metadata2 and the second partition table cached in Userdata.

[0199] S304: Write the system data cached in the user data partition (Userdata) back to the dynamic partition (Super).

[0200] After updating the Super_Metadata of the dynamic partition (Super), the electronic device 100 may write back the data of the sub-partitions such as System, Product, Version, and Preload stored in the virtual dynamic partition (V2) in sequence.

[0201] Referring to Figure 10, the data in the original System subpartitions of System1 and System2 is continuously stored in the address range [500-2699]. The address range [500-2699] is the new System subpartition. Similarly, the data in the original Product subpartition [2500-3499] can be migrated to the new Product subpartition [2700-3699]; the data in the original Version subpartition [3500-3999] can be migrated to the new Version subpartition [3700-4199]; and the data in the original Preload subpartition [5500-5999] can be migrated to the new Version subpartition [4200-4699].

[0202] Optionally, when reducing the dynamic partition (Super), the electronic device 100 may also reserve a fixed-size Reserved partition in the dynamic partition (Super) for expansion (not shown in Figures 8 and 10). If a Reserved partition is set, the Metadata2 shown in Table 6.3 may record the above-mentioned Reserved partition accordingly. The embodiment of the present application does not limit the size of the Reserved partition. The electronic device 100 may set it based on experience.

[0203] By implementing the partition migration method shown in Figure 9, the electronic device 100 can support the migration of non-independent variable partitions in the dynamic partition, and there is no need to specifically modify the partition information of one or more variable partitions in Super_Metadata. Instead, the dynamic partition metadata Metadata2 in the system upgrade package can be directly written, which is more convenient and quick.

[0204] The method shown in Figure 9 is also applicable to the upgrade scenario shown in Figure 5 (non-independent sub-partitions are not included after the upgrade). At this time, when writing the data of each sub-partition in Super to Userdata, there is no need to use the device mapper. Instead, each partition can be written to Userdata at one time based on the address range of each sub-partition recorded in Super_Metadata. After using Metadata2 to update the current Super_Metadata of the electronic device 100 and replacing the original first partition table with the second partition table, the electronic device 100 can write the data cached in Userdata back to Super.

[0205] Figure 11 is a flowchart of another operating system upgrade method provided by an embodiment of the present application. When implementing the system upgrade method shown in Figure 11, the electronic device 1000 can also modify the system mode in the basic partition (common) of the electronic device 100 at the same time.

[0206] S401. Configure snapshot and snapuser in the recovery mode of the electronic device 100.

[0207] Snapshot is a tool that associates physical and logical addresses. When performing a merge operation, electronic device 100 can generate a file map for the COW file in the virtual dynamic partition and a file map for the subpartition corresponding to the dynamic partition (Super) based on the snapshot, and then write the COW file in the virtual dynamic partition to the subpartition corresponding to the dynamic partition (Super). Snapuser is a tool that compresses and decompresses COW files and writes the COW file from the virtual dynamic partition to the dynamic partition (Super).

[0208] In an embodiment of the present application, the electronic device 100 can configure snapshot and snapuser in its own recovery mode, so that the electronic device 100 can perform a merge operation in the recovery mode and then continue to perform a reform operation.

[0209] Specifically, electronic device 100 can include the lib_snapshot_utils and libsnapshot_nobinder libraries in the recovery file. These libraries are used to implement snapshots in recovery mode. Furthermore, electronic device 100 can create a Snapuserd file in the system / bin / directory and include a Snapuserd.rc configuration file in the recovery file. The Snapuserd file created in system / bin / and the Snapuserd.rc configuration file in the recovery file combine to support the provision of snapuser services in recovery mode.

[0210] S402. Obtain the system upgrade package, including: static partition upgrade data, dynamic partition upgrade data, Metadata2, the second partition table and the target system.

[0211] The electronic device 100 obtains the system upgrade package from the package server via the Update_apk_client. In this embodiment of the present application, the system upgrade package also includes the target standard. The target standard is stored in the root directory of the system upgrade package in the form of a target_vendor_country.mbn file. For example, the system upgrade package records the target standard VC2. The target standard VC2 is different from the official standard VC1 currently used by the electronic device 100.

[0212] S403. Trigger Updata_engine to perform system upgrade.

[0213] S404.Updata_engine verifies the system upgrade package.

[0214] S405. Updata_engine writes the data in the system upgrade package to the corresponding memory partition: (1) writes the static partition upgrade data to the static partition (B); (2) writes the dynamic partition upgrade data, Metadata2 and the second partition table to the virtual dynamic partition of Userdata.

[0215] Specifically, the steps shown in S402 to S405 can refer to the introduction of S102 to S105, which will not be repeated here. The embodiment of the present application does not limit the order in which S401 and S402 occur.

[0216] S406. Create tmp and write the target format.

[0217] In this embodiment of the present application, the electronic device 100 needs to change its standard during a system upgrade. Therefore, after obtaining the upgrade package, the Updata_engine must determine whether the upgrade package downloaded from the package server is for a system change. The Updata_engine can determine whether the upgrade package is for a system change based on whether the upgrade package contains the target standard. If the upgrade package is determined to be for a system change, the Updata_engine can create a tmp in the base partition and write the target standard in the upgrade package to tmp. tmp is the area in the base partition used to cache the target standard VC2.

[0218] Referring to S402, in this embodiment of the present application, the system upgrade package includes upgrade data for the target operating system OS2.0 and the target system VC2. Therefore, after obtaining the system upgrade package, Updata_engine can determine that the data is also used for the system upgrade. In this case, Updata_engine can write the target system VC2 to the aforementioned tmp.

[0219] S407: Write the factory reset command.

[0220] After confirming that the system upgrade package also includes the target system format, Updata_engine can write the factory reset command during the startup process. Specifically, Updata_engine can write the command in / cache / command:

[0221] "--wipe_data", "--reason=change_vcand_wipe_data".

[0222] The above command is the factory reset command.

[0223] Similarly, when Updata_engine executes the upgrade operation shown in S404 to S406, Update_apk_client can monitor the progress of the upgrade operation shown in S404 to S406. The electronic device 100 can display a corresponding progress control based on the progress detected by Update_apk_client to show the upgrade progress to the user.

[0224] S408. Trigger a restart and enter recovery mode.

[0225] After the upgrade is complete and the factory reset command is written, Updata_engine returns a status message to Update_apk_client indicating the upgrade is complete. Correspondingly, a progress bar indicates the upgrade is complete. Update_apk_client then triggers a reboot.

[0226] During the restart process, the electronic device 100 reads the command in the startup process and executes the operation indicated by the command. At this time, the electronic device 100 can read the factory reset command written into the startup process in S407. After parsing the factory reset command, the electronic device 100 can enter the recovery mode.

[0227] S409. Execute a merge operation to write the dynamic partition upgrade data in the virtual dynamic partition into the dynamic partition (Super).

[0228] Based on the snapshot and snapuser that have been configured in recovery mode, after entering recovery mode, recovery can use snapshot to read the metadata (i.e. Super_Metadata) in the dynamic partition (Super) and the COW file in the virtual dynamic partition, and then use snapuser to write the COW file in the virtual dynamic partition to the dynamic partition (Super). For details, please refer to the introduction of S108.

[0229] S410. Execute a copy operation to write the data in the static partition (B) into the static partition (A).

[0230] S411. Write the target format in tmp into OEM.

[0231] Recovery can write the target standard VC2 cached in tmp to OEM. OEM is the area in the base partition that stores the official standard VC1. After writing to OEM, the official standard of electronic device 100 is updated to the new standard VC2. Recovery can then clear tmp.

[0232] S412. Format the userdata partition and clear the custom file (Custom.bin).

[0233] Since the device is currently in recovery mode, after performing the merge, copy, and rewrite operations, that is, after executing S409 to S411, the electronic device 100 can immediately perform a factory reset operation to format the Userdata partition. When formatting the Userdata partition, the custom file (Custom.bin) in the Userdata partition will also be cleared.

[0234] In this way, when the electronic device 100 is started next time, it can read the new format (ie VC2) in the OEM and write the above format into the custom file (Custom.bin) in the user data partition (Userdata) so that it can be called during the operation of the operating system.

[0235] S413. Check the storage space occupancy of the dynamic partition (Super). If the storage space occupancy of the dynamic partition (Super) decreases, reduce the dynamic partition (Super) and expand the user data partition (Userdata). S413 can be referred to S110 and will not be repeated here.

[0236] By implementing the method shown in FIG11 , in an upgrade scenario where the operating system is upgraded in recovery mode and the system format is changed simultaneously, after upgrading the current operating system to the target operating system and changing the current system format to the target system format, the electronic device 100 can also check the storage space occupancy of the dynamic partition (Super). In this way, after the storage space demand of the dynamic partition (Super) decreases, the electronic device 100 can also allocate the storage space originally allocated to the dynamic partition (Super) to the user data partition (Userdata), thereby improving the electronic device 100's ability to store user data and enhancing the user experience.

[0237] FIG12 is a schematic structural diagram of an electronic device 100 provided in an embodiment of the present application.

[0238] The electronic device 100 may include a processor 110, an external memory interface 120, an internal memory 121, a universal serial bus (USB) interface 130, an antenna 1, an antenna 2, a mobile communication module 150, a wireless communication module 160, a sensor module 180, a display screen 194, etc. The sensor module 180 may include a pressure sensor 180A, a touch sensor 180K, etc.

[0239] It should be understood that the structure illustrated in the embodiments of the present invention does not constitute a specific limitation on the electronic device 100. In other embodiments of the present application, the electronic device 100 may include more or fewer components than shown, or may combine or separate certain components, or arrange the components differently. The illustrated components may be implemented in hardware, software, or a combination of software and hardware.

[0240] The processor 110 may include one or more processing units, for example: the processor 110 may include an application processor (AP), a modem processor, a graphics processing unit (GPU), an image signal processor (ISP), a controller, a video codec, a digital signal processor (DSP), a baseband processor, and / or a neural-network processing unit (NPU), etc. Among them, different processing units can be independent devices or integrated into one or more processors. The controller can generate an operation control signal based on the instruction opcode and timing signal to complete the control of instruction fetching and execution. The processor 110 can also be provided with a memory for storing instructions and data.

[0241] In some embodiments, the processor 110 may include one or more interfaces. The interfaces may include an inter-integrated circuit (I2C) interface, an inter-integrated circuit sound (I2S) interface, a pulse code modulation (PCM) interface, a universal asynchronous receiver / transmitter (UART) interface, a mobile industry processor interface (MIPI), a general-purpose input / output (GPIO) interface, a subscriber identity module (SIM) interface, and / or a universal serial bus (USB) interface.

[0242] Exemplarily, the processor 110 can be coupled to the touch sensor 180K via the I2C interface, so that the processor 110 and the touch sensor 180K communicate through the I2C bus interface to realize the touch function of the electronic device 100. The processor 110 communicates with the Bluetooth module in the wireless communication module 160 through the UART interface to realize the Bluetooth function. The MIPI interface includes a display serial interface (DSI). The processor 110 and the display screen 194 communicate through the DSI interface to realize the display function of the electronic device 100. The GPIO interface can be configured by software. The GPIO interface can be configured as a control signal or as a data signal. The GPIO interface can also be configured as an I2C interface, an I2S interface, a UART interface, a MIPI interface, etc.

[0243] USB interface 130 is an interface that complies with USB standards and specifications, and may be a Mini USB interface, a Micro USB interface, a USB Type-C interface, or the like. USB interface 130 can be used to connect a charger to charge electronic device 100 and can also be used to transfer data between electronic device 100 and peripheral devices. In this embodiment of the present application, electronic device 100 can be connected to a dedicated modification tool via USB interface 130 to modify the device's configuration.

[0244] It is understood that the interface connection relationship between the modules illustrated in the embodiment of the present invention is merely an illustrative illustration and does not constitute a structural limitation on the electronic device 100. In other embodiments of the present application, the electronic device 100 may also adopt different interface connection methods from the above embodiments, or a combination of multiple interface connection methods.

[0245] The wireless communication function of the electronic device 100 can be implemented through the antenna 1, the antenna 2, the mobile communication module 150, the wireless communication module 160, the modem processor and the baseband processor.

[0246] Antenna 1 and Antenna 2 are used to transmit and receive electromagnetic wave signals. Each antenna in electronic device 100 can be used to cover a single or multiple communication frequency bands. Different antennas can also be reused to improve antenna utilization. For example, antenna 1 can be reused as a diversity antenna for a wireless local area network. In other embodiments, the antennas can be used in conjunction with a tuning switch.

[0247] The mobile communication module 150 can provide solutions for wireless communications including 2G / 3G / 4G / 5G applied to the electronic device 100. The mobile communication module 150 may include at least one filter, a switch, a power amplifier, a low noise amplifier (LNA), etc. The mobile communication module 150 can receive electromagnetic waves from the antenna 1, and filter, amplify, and process the received electromagnetic waves, and transmit them to the modulation and demodulation processor for demodulation. The mobile communication module 150 can also amplify the signal modulated by the modulation and demodulation processor, and convert it into electromagnetic waves for radiation through the antenna 1. In some embodiments, at least some of the functional modules of the mobile communication module 150 can be set in the processor 110. In some embodiments, at least some of the functional modules of the mobile communication module 150 can be set in the same device as at least some of the modules of the processor 110.

[0248] The modem processor may include a modulator and a demodulator. The modulator is used to modulate the low-frequency baseband signal to be transmitted into a medium-high frequency signal. The demodulator is used to demodulate the received electromagnetic wave signal into a low-frequency baseband signal. The demodulator then transmits the demodulated low-frequency baseband signal to the baseband processor for processing. After being processed by the baseband processor, the low-frequency baseband signal is passed to the application processor. The application processor outputs a sound signal through an audio device (such as a speaker, a receiver, etc.) or displays an image or video through the display screen 194. In some embodiments, the modem processor may be an independent device. In other embodiments, the modem processor may be independent of the processor 110 and be set in the same device as the mobile communication module 150 or other functional modules.

[0249] The wireless communication module 160 can provide wireless communication solutions including wireless local area networks (WLAN) (such as wireless fidelity (Wi-Fi) networks), Bluetooth (BT), global navigation satellite system (GNSS), frequency modulation (FM), near field communication (NFC), infrared (IR), etc., which are applied to the electronic device 100. The wireless communication module 160 can be one or more devices that integrate at least one communication processing module. The wireless communication module 160 receives electromagnetic waves via the antenna 2, frequency modulates and filters the electromagnetic wave signals, and sends the processed signals to the processor 110. The wireless communication module 160 can also receive the signal to be sent from the processor 110, frequency modulate it, amplify it, and convert it into electromagnetic waves for radiation through the antenna 2.

[0250] In an embodiment of the present application, the electronic device 100 can obtain a system upgrade package from the packet server through the wireless communication function provided by antenna 1, antenna 2, mobile communication module 150, wireless communication module 160, modem processor and baseband processor, and then perform a system upgrade operation.

[0251] Electronic device 100 implements display functionality through a GPU, display screen 194, and an application processor. A GPU is a microprocessor for image processing that connects display screen 194 and the application processor. The GPU is used to perform mathematical and geometric calculations for graphics rendering. Processor 110 may include one or more GPUs that execute program instructions to generate or modify display information.

[0252] Display screen 194 is used to display images, videos, etc. Display screen 194 includes a display panel. Display screen 194 includes a display panel. The display panel can be a liquid crystal display (LCD). The display panel can also be made of an organic light-emitting diode (OLED), an active-matrix organic light-emitting diode or an active-matrix organic light-emitting diode (AMOLED), a flexible light-emitting diode (FLED), a miniLED, a microLED, a micro-OLED, a quantum dot light-emitting diode (QLED), etc. In some embodiments, the electronic device can include one or N display screens 194, where N is a positive integer greater than one.

[0253] In an embodiment of the present application, the electronic device 100 can display a user interface through the display functions provided by the GPU, the display screen 194, and the application processor, such as a user interface for obtaining a system upgrade package, a user interface for displaying the upgrade progress during the system upgrade process, etc., so that the user can perform system upgrade operations.

[0254] The internal memory 121 may include one or more random access memories (RAMs) and one or more non-volatile memories (NVMs). The RAM can be directly read and written by the processor 110 and can be used to store executable programs (e.g., machine instructions) of the operating system or other running programs, as well as user and application data. The NVM can also store executable programs and user and application data, and can be pre-loaded into the RAM for direct reading and writing by the processor 110.

[0255] In the embodiment of the present application, the memory corresponding to the partition table of the electronic device 100 shown in Figure 1 refers to the above-mentioned non-volatile memory. The program code of the electronic device 100, such as the system configuration, boot program, and system operation program, is stored in the non-volatile memory. When the electronic device 100 is powered on, the electronic device 100 can load the program code stored in the non-volatile memory into the random access memory and then send it to the processor 110 for execution, thereby implementing the system upgrade method provided in the embodiment of the present application.

[0256] The external memory interface 120 can be used to connect to an external non-volatile memory to expand the storage capacity of the electronic device 100. The external non-volatile memory communicates with the processor 110 through the external memory interface 120 to implement a data storage function.

[0257] Pressure sensor 180A is used to sense pressure signals and convert them into electrical signals. In some embodiments, pressure sensor 180A may be located on display screen 194. When a touch operation is performed on display screen 194, electronic device 100 detects the intensity of the touch operation using pressure sensor 180A. Electronic device 100 may also calculate the location of the touch based on the detection signal from pressure sensor 180A.

[0258] The touch sensor 180K is also called a "touch-sensitive device." The touch sensor 180K can be disposed on the display screen 194. The touch sensor 180K and the display screen 194 form a touch screen, also called a "touch screen." The touch sensor 180K is used to detect touch operations applied thereto or in the vicinity thereof. The touch sensor can transmit the detected touch operations to the application processor to determine the type of touch event. Visual output related to the touch operations can be provided via the display screen 194. In other embodiments, the touch sensor 180K can also be disposed on the surface of the electronic device 100, at a location different from that of the display screen 194.

[0259] In an embodiment of the present application, the electronic device 100 can detect user operations such as clicking and sliding on the screen through the touch detection capability provided by the touch sensor 180K, obtain system upgrade packages, display system upgrade progress, etc.

[0260] The term "user interface (UI)" in the specification, claims and drawings of this application refers to the media interface for interaction and information exchange between an application or operating system and a user, which realizes the conversion between the internal form of information and the form acceptable to the user. The user interface of an application is a source code written in a specific computer language such as Java and Extensible Markup Language (XML). The interface source code is parsed and rendered on the terminal device, and finally presented as content that the user can recognize, such as pictures, text, buttons and other controls. Controls, also known as widgets, are the basic elements of the user interface. Typical controls include toolbars, menu bars, text boxes, buttons, scroll bars, pictures and text. The properties and contents of controls in the interface are defined by tags or nodes, such as XML through <textview> 、 <imgview> 、 <videoview>The controls contained in the interface are specified by nodes such as <head> and <body>. A node corresponds to a control or attribute in the interface, and the node is presented as user-visible content after parsing and rendering. In addition, many applications, such as hybrid applications, usually also contain web pages in their interfaces. A web page, also known as a page, can be understood as a special control embedded in the application interface. A web page is a source code written in a specific computer language, such as hypertext markup language (HTML), cascading style sheets (CSS), JavaScript (JS), etc. The web page source code can be loaded and displayed as user-recognizable content by a browser or a web page display component with similar functions to a browser. The specific content contained in a web page is also defined by tags or nodes in the web page source code, such as HTML through <body>. 、 、 <video> 、 <canvas>To define the elements and attributes of a web page.

[0261] A common form of user interface is the graphical user interface (GUI), which refers to a user interface related to computer operations that uses graphics. It can be an icon, window, control, or other interface element displayed on the display of an electronic device. Controls can include icons, buttons, menus, tabs, text boxes, dialog boxes, status bars, navigation bars, widgets, and other visual interface elements.

[0262] As used in the specification and appended claims of the present application, the singular expressions "a", "an", "said", "above", "the" and "this" are intended to include plural expressions as well, unless the context clearly indicates otherwise. It should also be understood that the term "and / or" used in the present application refers to and includes any or all possible combinations of one or more listed items. As used in the above embodiments, the term "when..." can be interpreted to mean "if..." or "after..." or "in response to determining..." or "in response to detecting...". Similarly, the phrase "when determining..." or "if (stated condition or event) is detected" can be interpreted to mean "if determining..." or "in response to determining..." or "when (stated condition or event) is detected" or "in response to detecting (stated condition or event)", depending on the context.

[0263] In the above embodiments, it can be implemented in whole or in part by software, hardware, firmware or any combination thereof. When implemented using software, it can be implemented in whole or in part in the form of a computer program product. The computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, the process or function described in the embodiment of the present application is generated in whole or in part. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions can be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another computer-readable storage medium. For example, the computer instructions can be transmitted from one website, computer, server or data center to another website, computer, server or data center via a wired (e.g., coaxial cable, optical fiber, digital subscriber line) or wireless (e.g., infrared, wireless, microwave, etc.) method. The computer-readable storage medium can be any available medium that a computer can access or a data storage device such as a server or data center that includes one or more available media integrations. The available medium can be a magnetic medium (e.g., a floppy disk, a hard disk, a tape), an optical medium (e.g., a DVD), or a semiconductor medium (e.g., a solid-state hard disk).

[0264] Those skilled in the art will appreciate that all or part of the process steps in the above-described method embodiments can be implemented by a computer program instructing the relevant hardware. The program can be stored in a computer-readable storage medium, and when executed, the program can include the process steps in the above-described method embodiments. The aforementioned storage medium includes various media capable of storing program code, such as ROM or random access memory (RAM), magnetic disks, or optical disks.< / canvas> < / video> < / videoview> < / imgview> < / textview>

Claims

1. A method for upgrading an operating system, applied to an electronic device, wherein a memory of the electronic device includes a first partition and a second partition, the first partition being used to store first data of a first operating system installed on the electronic device, and the second partition being used to store user data. The memory further includes a first partition table and first metadata, the first partition table being used to record partition information of multiple partitions in the memory, the multiple partitions including the first partition and the second partition, and the first metadata being used to store partition information of one or more sub-partitions in the first partition, characterized in that: The method comprises: Obtaining upgrade data, the upgrade data including second data of the second operating system, second metadata, and a second partition table, wherein the second data corresponds to the first data, the second metadata records partition information of one or more subpartitions in the first partition corresponding to the second data, and the second partition table records partition information of multiple partitions in the memory corresponding to the second operating system; Writing the second data into the first partition; Writing the second metadata to replace the first metadata; The second partition table is written to replace the first partition table.

2. The method according to claim 1, characterized in that The size of the first partition recorded in the second partition table is smaller than the size of the first partition recorded in the first partition table, and the size of the second partition recorded in the second partition table is larger than the size of the second partition recorded in the first partition table; After the second partition table is written to replace the first partition table, the first partition of the memory is reduced in size and the second partition is increased in size.

3. The method according to claim 1 or 2, characterized in that The writing of the second metadata to replace the first metadata specifically includes: after writing the second data stored in the first partition into the second partition, writing the second metadata to replace the first metadata; after the replacement, writing the second data cached in the second partition back to the first partition; Writing the second partition table to replace the first partition table specifically includes: After writing the second data cached in the second partition back to the first partition, the second partition table is written to replace the first partition table.

4. The method according to claim 3, characterized in that Writing the second data into the first partition specifically includes: writing first sub-partition data in the second data into a first sub-partition in the first partition, the first sub-partition being a sub-partition in the first partition including a plurality of discontinuous storage blocks, and the first sub-partition data being stored in the plurality of discontinuous storage blocks; Writing the second data stored in the first partition into the second partition specifically includes: Writing the first sub-partition data stored in the first storage block to the third storage block of the second partition; writing the first sub-partition data stored in the second storage block to the fourth storage block of the second partition; The first storage block and the second storage block are two discontinuous storage blocks in the first sub-partition. The third storage block and the fourth storage block are two consecutive storage blocks in the second partition.

5. The method according to claim 3 or 4, characterized in that Writing the second data stored in the first partition into the second partition specifically includes: writing the second data stored in the first partition into a first area of ​​the second partition, where the first area is at the end of the second partition.

6. The method according to claim 1 or 2, characterized in that Writing the second metadata to replace the first metadata specifically includes: moving data in a second subpartition in the first partition from a second area of ​​the first partition to a third area, the second subpartition being a subpartition subsequent to the third subpartition, the third subpartition being a subpartition whose subpartition size is reduced after writing the second data into the first partition; After the forward shift, the second metadata is written to replace the first metadata.

7. The method according to any one of claims 2 to 6, characterized in that Writing the second data into the first partition specifically includes: Writing the second data into the second partition in a copy-on-write (COW) file format to obtain third data; The third data is written into the first partition.

8. The method according to any one of claims 2 to 7, characterized in that Before writing the second data to the first partition, the method further includes: performing a restart operation and entering a recovery mode for restoring factory settings upon restart; the writing of the second data to the first partition, the writing of the second metadata to replace the first metadata, and the writing of the second partition table to replace the first partition table are completed in the recovery mode.

9. The method according to any one of claims 1 to 8, characterized in that The first partition is a dynamic partition in the Android system; the second partition is a user data partition in the Android system.

10. The method according to any one of claims 1 to 9, characterized in that The first operating system is a demonstration machine operating system; the second operating system is a commercial machine operating system.

11. An electronic device, characterized in that: The method comprises one or more processors and one or more memories; wherein the one or more memories are coupled to the one or more processors, and the one or more memories are used to store computer program code, wherein the computer program code comprises computer instructions, and when the one or more processors execute the computer instructions, the method according to any one of claims 1 to 10 is executed.

12. A computer-readable storage medium comprising instructions, characterized in that: When the instructions are executed on an electronic device, the method according to any one of claims 1 to 10 is executed.

Images