Upgrading method of operating system and electronic equipment

Abstract

The invention discloses an operating system upgrading method and electronic equipment, which can be applied to the technical field of computers. Wherein the electronic equipment obtains the service pack, the service pack comprises a second partition table, and the second partition table is used for describing another partition deployment of the basic partition, the first static partition, the second static partition and the dynamic partition. And after the service pack is obtained, the electronic equipment is restarted for the first time and enters a recovery mode. In a recovery mode, the electronic equipment emigrating data in the basic partition, the first static partition, the second static partition and the dynamic partition, and updating partition deployment of the memory from partition deployment described by a first partition table to partition deployment described by a second partition table, and migrating the migrated data back to each corresponding partition in the partition deployment described by the second partition table. And restarting the electronic equipment for the second time. Therefore, the adjustment of the partition deployment in the memory can be realized without being limited to the partition deployment during delivery.

Description

Operating system upgrade method and electronic device

[0001] This application claims priority to the Chinese patent application filed with the State Intellectual Property Office on November 30, 2022, with application number 202211524696.9 and invention name “A method for upgrading an operating system and an electronic device”, the entire contents of which are incorporated by reference into this application. Technical Field

[0002] The present application relates to the field of computer technology, and in particular to an operating system upgrade method and electronic equipment. Background Art

[0003] Over-the-Air Technology is a technology that enables remote upgrades of operating system versions through the wireless network interface of electronic devices. At the same time, the storage devices of electronic devices, such as Read-Only Memory (ROM), can adopt virtual A / B (i.e., Virtual A / B) data storage structure data. In the data storage structure of Virtual A / B, there are two independent static partitions (such as static partition (A) and static partition (B)) and a shared dynamic partition (Super). For electronic devices with Virtual A / B data storage structure, when using OTA upgrade (i.e., Virtual A / B OTA upgrade) of the operating system, the electronic device can be upgraded imperceptibly when it is operating normally based on a static partition (such as static partition (A) or static partition (B)), and only requires a shared dynamic partition (Super), which can improve the utilization of data storage space.

[0004] However, in the process of implementing the embodiments of the present application, the inventors found that once an electronic device is sold, the existing Virtual A / B OTA upgrade solution can only complete the operating system upgrade under the partition deployment restrictions of the existing data storage structure, which greatly limits the applicable scenarios of the upgrade solution.

[0005] Summary of the Invention

[0006] In view of this, the present application provides an operating system upgrade method and electronic device, which can adjust the partition deployment in the memory without being restricted to the partition deployment at the factory.

[0007] In the first aspect, an embodiment of the present application provides an operating system upgrade method, which is applied to an electronic device including a memory (such as a ROM), the memory including a basic partition, a first static partition, a second static partition and a dynamic partition, and the electronic device including a first partition table, the first partition table being used to describe a partition deployment of the basic partition, the first static partition, the second static partition and the dynamic partition. Among them, the electronic device obtains a patch package, the patch package includes a second partition table, the second partition table being used to describe another partition deployment of the basic partition, the first static partition, the second static partition and the dynamic partition. After obtaining the patch package, the electronic device restarts for the first time and enters recovery mode. In recovery mode, the electronic device migrates the data in the basic partition, the first static partition, the second static partition and the dynamic partition, updates the partition deployment of the memory from the partition deployment described by the first partition table to the partition deployment described by the second partition table, and migrates the migrated data back to the corresponding partitions in the partition deployment described by the second partition table. When the electronic device restarts for the second time, this restart will not enter recovery mode, but will enter normal operating system mode.

[0008] In summary, using the embodiments of the present application, electronic devices can adjust partition deployment in recovery mode, allowing the data storage structure in the memory to change. This optimizes storage space without being restricted by the factory partition deployment and can further adapt to new storage needs. Furthermore, during the partition deployment adjustment process, the electronic device first migrates data, then adjusts the partition deployment, and finally migrates the data back. This ensures that the adjusted partitions still contain data from the current version of the operating system. Therefore, after a second restart after obtaining the patch package, the electronic device can still operate normally.

[0009] In a possible design method of the first aspect, after the electronic device is restarted for the second time, the above method also includes: the electronic device obtains an upgrade package for the operating system of the electronic device, writes the upgrade data in the upgrade package into each partition corresponding to the partition deployment described in the second partition table, and completes the operating system upgrade.

[0010] That is, after adjusting the partition deployment, each partition can store the mirror data of the target version of the operating system, and the data of adjacent sub-partitions will not overwrite each other. Then, after the electronic device obtains the upgrade package of the target version of the operating system, it can write the upgrade data to the corresponding partition, so that the operating system can be upgraded to the target version.

[0011] In another possible design of the first aspect, the first partition table includes partition information of multiple sub-partitions in the basic partition, the first static partition, and the second static partition in the first version (i.e., the version of the operating system currently running on the electronic device, referred to as the current version) of the operating system, as well as partition information of the dynamic partition. The second partition table includes partition information of multiple sub-partitions in the basic partition, the first static partition, and the second static partition in the second version (i.e., the version after the partition deployment is adjusted, referred to as the intermediate version before upgrading to the target version), as well as partition information of the dynamic partition. The partition information includes partition size, partition name, start address, and end address.

[0012] In another possible design of the first aspect, the electronic device enters the recovery mode when it is restarted for the first time, including: if the first partition table is different from the second partition table, the electronic device enters the recovery mode when it is restarted for the first time.

[0013] If the first and second partition tables are identical, the partition tables have not changed. In this case, an exception is considered, and there is no need to enter recovery mode and further adjust the partition layout. Conversely, if the second partition table is different from the first, it indicates that the second partition table has changed compared to the first. In this case, it is necessary to enter recovery mode and further adjust the partition layout.

[0014] That is, the recovery mode is entered only when the second partition table is updated compared to the first partition table, thereby avoiding erroneous entry into the recovery mode without adjusting the partition layout.

[0015] In another possible design of the first aspect, the first partition table differs from the second partition table, including at least one of the following: the second partition table includes partition information for the first partition, while the first partition table does not. Furthermore, the first partition is added to the second partition table. The first partition table includes partition information for the second partition, while the second partition table does not. That is, the second partition is deleted from the second partition table. The first partition table includes partition information for the third partition, while the second partition table includes partition information for the fourth partition. The partition names of the third partition and the fourth partition are different, but the third and fourth partitions are used to store the same data. That is, the third partition in the first partition table is renamed to the fourth partition in the second partition table. Furthermore, both the first and second partition tables include partition information for the fifth partition, but the first partition information for the fifth partition in the first partition table is different from the first partition information for the fifth partition in the second partition table, and the first partition information does not include a partition name. That is, the partition size, start address, and / or end address of the fifth partition have changed.

[0016] The first, second, third, fourth, and fifth partitions are sub-partitions of the basic, first, and second static partitions, or they are dynamic partitions. In other words, changes to partition deployment can be changes to sub-partitions of the basic, first, and second static partitions, or to the entire dynamic partition.

[0017] In another possible design method of the first aspect, the above-mentioned migration of the migrated data back to the corresponding partitions in the partition deployment described in the second partition table includes: the electronic device migrates the data migrated from the sixth partition back to the first target address interval in the memory. Wherein, the sixth partition is a partition other than the first partition, the second partition and the fourth partition in the second partition table. That is, the sixth partition is neither a newly added partition nor a deleted partition nor a partition with a changed name. In other words, the sixth partition may be the aforementioned fifth partition, or it may be a partition whose partition size, start address and end address have not changed. Similarly, the sixth partition is a sub-partition among the basic partition, the first static partition and the second static partition, or the sixth partition is a dynamic partition, and the first target address interval is the interval between the start address and the end address of the sixth partition in the second partition table.

[0018] That is to say, for a partition whose partition size, starting address and / or ending address has changed, or whose partition size, starting address and ending address have not changed, when the electronic device migrates data back, it can directly migrate back according to the starting address and ending address of the partition in the second partition table.

[0019] In another possible design of the first aspect, migrating the migrated data back to the partitions corresponding to the partition arrangement described in the second partition table includes: the electronic device clearing data within a second target address range in the memory. The second target address range is the range between the start address and the end address of the first partition in the second partition table.

[0020] That is to say, the data between the start address and the end address of the newly added partition in the memory is cleared to zero, so that it can be ensured that there is no dirty data in the storage space corresponding to the newly added partition in the memory, such as no mirror data of the current version of the operating system. In another possible design method of the first aspect, the patch package includes a first indication information, and the first indication information is used to indicate that compared with the first partition table, a new first partition has been added to the second partition table. For example, the first indication information is add: xbl_dump, indicating that compared with the first partition table, a new xbl_dump partition has been added to the second partition table. Accordingly, before the electronic device clears the data in the second target address interval in the memory, the above method also includes: the electronic device reads the first indication information, and queries the start address and end address of the first partition from the second partition table based on the first indication information.

[0021] That is to say, by reading the first indication information, the electronic device can obtain the name of the newly added partition. Then, based on the name of the newly added partition, the electronic device can query the starting address and ending address of the newly added partition in the second partition table to determine the first target address range for the cleared data.

[0022] In another possible design of the first aspect, the above-mentioned migrating the migrated data back to the corresponding partitions in the partition deployment described by the second partition table includes: the electronic device does not migrate back the data migrated from the second partition.

[0023] That is, for a deleted partition, the electronic device will not migrate back the data migrated from the deleted partition, thereby avoiding migrating redundant data back.

[0024] In another possible design of the first aspect, the patch package includes second indication information, where the second indication information is used to indicate that the second partition has been deleted from the second partition table compared to the first partition table. For example, the second indication information is delete:abl_test, indicating that the abl_test partition has been deleted from the second partition table compared to the first partition table. The method further includes: the electronic device reading the second indication information, and determining, based on the second indication information, the data to be migrated from the second partition.

[0025] That is to say, by reading the second indication information, the electronic device can obtain the name of the deleted partition. Then, based on the name of the deleted partition, the electronic device can search for a file named with the name of the deleted partition from the location where the data is migrated (such as the user data partition (Userdata)). The data stored in the file is the data migrated from the second partition.

[0026] In another possible design of the first aspect, migrating the migrated data back to the corresponding partitions in the partition arrangement described in the second partition table includes: the electronic device migrating the data migrated from the third partition back to a third target address range of the memory. The third target address range is the range between the start address and the end address of the fourth partition in the second partition table.

[0027] In other words, the data migrated from the partition before the name change will be moved back to the starting and ending addresses of the partition after the name change, thus ensuring that the system data stored in the partition after the name change is the same as the system data stored in the partition before the name change.

[0028] In another possible design of the first aspect, the patch package includes third indication information, and the third indication information is used to indicate that the third partition in the first partition table is updated to the fourth partition in the second partition table. For example, the third indication information is change: abl_test, abl, indicating that the abl_test partition in the first partition table is updated to the abl partition in the second partition table. Accordingly, before the electronic device migrates data from the third partition back to the third target address range of the memory, the above method further includes: the electronic device reads the third indication information, and based on the third indication information, queries the start address and end address of the fourth partition from the second partition table.

[0029] That is to say, by reading the third indication information, the electronic device can obtain the modified partition name. Then, based on the modified partition name, the electronic device can query the starting address and ending address of the partition with the modified name from the second partition table, so as to accurately determine the third target address range.

[0030] In another possible design of the first aspect, after obtaining the patch package, the electronic device restarts for the first time. The method includes: after obtaining the patch package, if the patch package includes a data packet with a preset name, or the patch package includes a first tag, the electronic device restarts for the first time. The data packet with the preset name is used to adjust partition deployment, and the first tag is used to indicate the adjustment of partition deployment.

[0031] That is, the electronic device will only reboot into recovery mode if the patch package includes a data packet for adjusting partition deployment and / or a tag for indicating the need to adjust partition deployment. In other words, the electronic device will only reboot into recovery mode after determining that the patch package is intended to adjust partition deployment, thus preventing the device from mistakenly entering recovery mode if the patch package is intended for other functions that do not require recovery mode.

[0032] In another possible design of the first aspect, the migrating data from the base partition, the first static partition, the second static partition, and the dynamic partition includes: if the patch package includes a data package with a preset name, migrating data from the base partition, the first static partition, the second static partition, and the dynamic partition. The data package with the preset name is used to adjust partition deployment.

[0033] That is, after the first reboot, the electronic device will only perform system data migration after confirming that the current deployment scenario is adjusted partitions. This avoids incorrect system data migration in non-adjusted partition deployment scenarios, which may ultimately affect system operation.

[0034] In another possible design of the first aspect, the above method further includes: in the case where the patch package includes a data packet with a preset name, the electronic device stores the data packet with the preset name in a preset directory of the electronic device, and writes a preset instruction in the electronic device, and the preset instruction includes the preset name. Wherein, the preset directory is a directory that the electronic device can access in recovery mode. Accordingly, after obtaining the patch package, after the electronic device is restarted for the first time, the above method further includes: the electronic device reads the preset instruction, so that the preset name can be read. Then, if the patch package includes a data packet with a preset name, the data in the basic partition, the first static partition, the second static partition and the dynamic partition are migrated out, including: if the preset instruction includes a preset name, the electronic device migrates out the data in the basic partition, the first static partition, the second static partition and the dynamic partition.

[0035] That is, the electronic device can determine whether the current scenario is to adjust the partition deployment by reading the preset instruction, and further determine whether data needs to be migrated.

[0036] In another possible design of the first aspect, if the patch package includes a data packet with a preset name, migrating data from the base partition, the first static partition, the second static partition, and the dynamic partition includes: the patch package includes a data packet with a preset name, and the electronic device sets a preset global variable for indicating adjustment of partition deployment. The electronic device detects the preset global variable and migrates data from the base partition, the first static partition, the second static partition, and the dynamic partition.

[0037] In other words, by setting a preset global variable, such as ptable-change, to indicate the current deployment of a regulated partition, you can clearly indicate that the current deployment is regulated. Later, during code execution, you can perform operations corresponding to the regulated partition deployment scenario based on this preset global variable, eliminating the need to perform scenario checks before each operation.

[0038] In another possible design of the first aspect, the preset instruction includes a preset directory, and the second partition table is stored in a data packet with a preset name. Before updating the partition arrangement of the memory from the partition arrangement described by the first partition table to the partition arrangement described by the second partition table, the method further includes: the electronic device, in accordance with the preset instruction, obtaining a data packet with a preset name from the preset directory, and obtaining the second partition table from the data packet with the preset name.

[0039] That is, the electronic device can determine the storage location of the second partition table by reading the preset instruction, so as to accurately obtain the second partition table for adjusting the partition deployment.

[0040] In another possible design of the first aspect, the memory further includes a user data partition, and migrating data from the basic partition, the first static partition, the second static partition, and the dynamic partition includes: the electronic device migrating the data from the basic partition, the first static partition, the second static partition, and the dynamic partition to the user data partition. Migrating the migrated data back to the corresponding partitions in the partition deployment described by the second partition table includes: migrating the data from the basic partition, the first static partition, the second static partition, and the dynamic partition in the user data partition back to the corresponding partitions in the partition deployment described by the second partition table.

[0041] In another possible design of the first aspect, after migrating the migrated data back to the corresponding partitions in the partition deployment described by the second partition table, the method further includes: deleting the migrated data, thereby freeing up storage space.

[0042] Taking the migration of data to the user data partition (Userdata) as an example, after the migration is completed, the electronic device can format the user data partition (Userdata), thereby deleting the data in the user data partition (Userdata) and releasing storage space.

[0043] In another possible design of the first aspect, the patch package includes a first version number. The electronic device obtaining the patch package includes: while the electronic device loads the basic partition, the first static partition, and the dynamic partition, and operates the electronic device, the electronic device obtains the patch package. After the electronic device obtains the patch package, the method further includes: the electronic device updating the version number in the second static partition to the first version number. By updating the version number, the electronic device can subsequently request a patch package or upgrade package with the updated version number, facilitating accurate acquisition of updated patch packages or upgrade packages. The electronic device sets its startup sequence to boot from the second static partition. Subsequently, the electronic device can boot from the second static partition. Furthermore, when booting from the second static partition, the electronic device can read the latest version number from the second static partition for requesting the patch package or upgrade package. Accordingly, after the electronic device restarts for the second time, the method further includes: the electronic device loading the basic partition, the second static partition, and the dynamic partition, and operating the electronic device. The electronic device reads the first version number from the second static partition. The electronic device obtaining an upgrade package for the electronic device's operating system includes: the electronic device obtaining the upgrade package for the electronic device's operating system based on the first version number. In this way, the latest upgrade package can be accurately acquired for upgrading the operating system.

[0044] In the second aspect, an embodiment of the present application provides an operating system upgrade method, which is applied to an electronic device including a memory (such as ROM), the memory including a basic partition, a first static partition, a second static partition, a first dynamic partition and a second dynamic partition, and the electronic device including a first partition table, the first partition table being used to describe a partition deployment of the basic partition, the first static partition, the second static partition, the first dynamic partition and the second dynamic partition. Among them, the electronic device obtains a patch package, the patch package includes a second partition table, the second partition table being used to describe another partition deployment of the basic partition, the first static partition, the second static partition, the first dynamic partition and the second dynamic partition. After obtaining the patch package, the electronic device restarts for the first time and enters recovery mode. In recovery mode, the electronic device migrates the data in the basic partition, the first static partition, the second static partition, the first dynamic partition and the second dynamic partition, updates the partition deployment of the memory from the partition deployment described by the first partition table to the partition deployment described by the second partition table, and migrates the migrated data back to the corresponding partitions in the partition deployment described by the second partition table. The electronic device restarts for the second time, and this restart will not enter recovery mode, but will enter normal operating system mode.

[0045] In other words, the operating system upgrade method can also be applied to the full A / B data storage structure (two sets of static partitions and dynamic partitions) to achieve updated partition deployment.

[0046] Of course, in the second aspect, the electronic device can also implement a possible design method similar to the first aspect for adjusting partition deployment. The only thing to note is that the dynamic partition in the first aspect needs to be replaced with a first dynamic partition and a second dynamic partition.

[0047] On the third aspect, an embodiment of the present application provides an operating system upgrade method, which is applied to an electronic device including a memory (such as ROM), the memory including a basic partition, a static partition and a dynamic partition, and the electronic device including a first partition table, the first partition table being used to describe a partition deployment of the basic partition, the static partition and the dynamic partition. Among them, the electronic device obtains a patch package, and the patch package includes a second partition table, and the second partition table is used to describe another partition deployment of the basic partition, the static partition and the dynamic partition. After obtaining the patch package, the electronic device restarts for the first time and enters recovery mode. In recovery mode, the electronic device migrates the data in the basic partition, the static partition and the dynamic partition, updates the partition deployment of the memory from the partition deployment described by the first partition table to the partition deployment described by the second partition table, and migrates the migrated data back to the corresponding partitions in the partition deployment described by the second partition table. When the electronic device restarts for the second time, this restart will not enter recovery mode, but will enter normal operating system mode.

[0048] That is, the operating system upgrade method can also be applied to a data storage structure having only one set of static partitions and dynamic partitions to implement updated partition deployment.

[0049] Of course, in the third aspect, the electronic device can also implement a possible design method similar to the first aspect for adjusting partition deployment. The only thing to note is that the first static partition and the second static partition in the first aspect need to be replaced with static partitions.

[0050] In a fourth aspect, an embodiment of the present application further provides an electronic device, comprising a processor and a memory, wherein the memory may adopt a virtual A / B (two sets of static partitions), a full A / B (two sets of static partitions and dynamic partitions), or a single system (only one set of static partitions and dynamic partitions). The electronic device further includes a first partition table, which is used to describe the partition deployment of the data storage structure. The processor is used to execute the software code stored on the memory, so that the electronic device executes the method of the first aspect, the second aspect, the third aspect, and any possible design method thereof.

[0051] In a fifth aspect, an embodiment of the present application provides a chip system, which is applied to an electronic device including a display screen and a memory; the chip system includes one or more interface circuits and one or more processors; the interface circuit and the processor are interconnected by lines; the interface circuit is used to receive a signal from the memory of the electronic device and send the signal to the processor, the signal including computer instructions stored in the memory; when the processor executes the computer instructions, the electronic device executes the method described in the first aspect, the second aspect, the third aspect and any possible design method thereof.

[0052] In a sixth aspect, an embodiment of the present application also provides a computer storage medium, which includes computer instructions. When the computer instructions are run on an electronic device, the electronic device executes the method described in the first aspect, the second aspect, the third aspect and any possible design method thereof.

[0053] In a seventh aspect, the present application provides a computer program product, which, when executed on a computer, enables the computer to execute the method described in the first aspect, the second aspect, the third aspect, and any possible design thereof.

[0054] It can be understood that the beneficial effects that can be achieved by the electronic device described in the fourth aspect, the chip system described in the fifth aspect, the computer storage medium described in the sixth aspect, and the computer program product described in the seventh aspect provided above can refer to the beneficial effects in the first aspect, the second aspect, the third aspect and any possible design methods thereof, and will not be repeated here. BRIEF DESCRIPTION OF THE DRAWINGS

[0055] In order to more clearly illustrate the technical solutions of the embodiments of the present application, the following briefly introduces the drawings required for use in the embodiments. Obviously, the drawings described below are only some embodiments of the present application. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying any creative labor.

[0056] FIG1 is a diagram showing the composition of an upgrade system provided in an embodiment of the present application;

[0057] FIG2 is a schematic diagram of a data storage structure according to an embodiment of the present application;

[0058] FIG3 is a second schematic diagram of a data storage structure provided in an embodiment of the present application;

[0059] FIG4 is a third schematic diagram of a data storage structure provided in an embodiment of the present application;

[0060] FIG5 is a hardware structure diagram of an electronic device 130 provided in an embodiment of the present application;

[0061] FIG6 is one of the interaction diagrams of the operating system upgrade method provided in an embodiment of the present application;

[0062] FIG7 is a second interactive diagram of the operating system upgrade method provided in an embodiment of the present application;

[0063] FIG8 is a schematic diagram of image file migration provided in an embodiment of the present application;

[0064] FIG9 is a schematic diagram of a mirror file migration according to an embodiment of the present application;

[0065] FIG10 is a second schematic diagram of image file migration provided in an embodiment of the present application;

[0066] FIG11 is a third schematic diagram of image file migration provided in an embodiment of the present application;

[0067] FIG12 is a fourth schematic diagram of image file migration provided in an embodiment of the present application;

[0068] FIG13 is a flowchart of a virtual A / B upgrade according to an embodiment of the present application;

[0069] FIG14 is a schematic diagram of a virtual A / B upgrade process according to an embodiment of the present application;

[0070] FIG15 is an interactive diagram of adjusting a partition table according to an embodiment of the present application;

[0071] FIG16 is a fourth schematic diagram of a data storage structure provided in an embodiment of the present application;

[0072] FIG17 is a structural diagram of the chip system provided in an embodiment of the present application. DETAILED DESCRIPTION

[0073] It should be understood that the embodiments described herein are only a portion of the embodiments of this application, not all of the embodiments. Based on the embodiments in this application, all other embodiments obtained by ordinary technicians in this field without creative work are within the scope of protection of this application.

[0074] The embodiment of the present application provides an operating system upgrade method, which can be applied to the upgrade system provided in the present application for upgrading the operating system of an electronic device. Referring to FIG1 , the upgrade system includes a packet processing server 110 , an OTA server 120 , and an electronic device (such as a mobile phone) 130 .

[0075] The package server 110 may be used to create upgrade packages and / or patch packages. The upgrade package is used to upgrade the operating system. The patch package may be used to repair operating system vulnerabilities. It should be understood that repairing the operating system using a patch package may also be considered an operating system upgrade.

[0076] OTA server 120 is used to centrally manage upgrade packages and / or patch packages, as well as upgrade management for connected electronic devices (such as electronic device 130). For example, OTA server 120 records that the operating system version of electronic device 130 is V1.1. After subsequently receiving the operating system version V2.0 produced by packet processing server 110, it is determined that the operating system of electronic device 130 is not the latest. In other words, it is determined that electronic device 130 needs to upgrade its operating system.

[0077] The electronic device 130 refers to a device that has an operating system installed and has a need to upgrade the operating system. Before the electronic device 130 leaves the factory, the operating system is burned into the electronic device 130, thereby realizing the installation of the operating system before the electronic device 130 leaves the factory. Thereafter, in order to improve the user experience, it may be necessary to upgrade the operating system in the electronic device 130. At this time, OTA technology can be used to complete the upgrade. Exemplarily, the electronic device 130 can request an upgrade package and / or patch package from the OTA server 120, or receive an upgrade package and / or patch package issued by the OTA server 120, and complete the operating system upgrade based on the upgrade package, and repair vulnerabilities in the operating system based on the patch package.

[0078] Furthermore, as shown in FIG1 , an operating system update program for operating system upgrades is installed in electronic device 130. Exemplarily, the operating system update program includes two functional modules: an online update client APK (OUC APK) and an update engine. OUC APK is used to obtain operating system upgrade packages and / or patch packages, such as those obtained from OTA server 120. The update engine is used to execute the operating system upgrade process.

[0079] The memory in the electronic device 130, such as ROM, can use a Virtual A / B data storage structure to store data. FIG2 shows a schematic diagram of a Virtual A / B data storage structure. As shown in FIG2 , taking the Android operating system as an example, the Virtual A / B data storage structure includes a basic partition (Common), a static partition (A) (also referred to as a first static partition), a static partition (B) (also referred to as a second static partition), a dynamic partition (Super), and a user data partition (Userdata).

[0080] The user data partition (Userdata) is used to store the user's personal data, such as applications (APPs) installed by the user, and personal data such as pictures, documents, and videos saved by the user. The data stored in the basic partition (Common) is system data that does not participate in operating system upgrades. The structures of the static partition (A) and the static partition (B) correspond to each other, and the subpartition names are distinguished by the suffixes _a and _b. For example, the subpartitions in the static partition (A) include bootloader_a, boot_a, and vendor_boot_a; the subpartitions in the static partition (B) include bootloader_b, boot_b, and vendor_boot_b. The dynamic partition (Super) contains multiple subpartitions, such as System, system_ext, vendor, product, Cust, and Odm.

[0081] It should be noted that the data storage structure shown in Figure 2 is only exemplary. In practice, the basic partition (Common) in the data storage structure may further include multiple sub-partitions, such as a cache partition. In addition, the static partition (A), static partition (B), and dynamic partition (Super) in the data storage structure may include more or fewer sub-partitions than shown in Figure 2. For example, the static partition (A) may also include sub-partitions such as Patch_a, dtbo_a, and vbmeta_a. Correspondingly, the static partition (B) may also include sub-partitions such as Patch_b, dtbo_b, and vbmeta_b. For another example, the dynamic partition (Super) may also include sub-partitions such as version and preload.

[0082] When the electronic device 130 starts up, it needs to start up from a static partition. For example, if the electronic device 130 starts up from the static partition (A), it will load the basic partition (Common), static partition (A), and dynamic partition (Super) in sequence. For another example, if the electronic device 130 starts up from the static partition (B), it will load the basic partition (Common), static partition (B), and dynamic partition (Super) in sequence.

[0083] Static partition (A), static partition (B), and dynamic partition (Super) can be used to store operating system image file data (hereinafter referred to as image data). For example, the image file boot.img is stored in the boot_a subpartition of static partition (A).

[0084] In practice, image files (such as .img files) often need to be expanded. For example, if a new feature is added to an image file, the image file must be expanded to accommodate the new feature. It should be understood that after the image file is expanded, storing the corresponding image data often requires more storage space.

[0085] Exemplarily, the distribution deployment of the data storage structure is shown on the left side of Figure 3. For example, the storage space of the boot_a subpartition in the static partition (A) is space 301, and the storage space of the boot_b subpartition in the static partition (B) is space 302. The data of the image file boot.img is stored in space 301 and space 302. In the current version of the operating system (such as version V1.0), the amount of data of the image file boot.img is relatively small. In the target version of the operating system (such as version V2.0), new features are added to the image file boot.img, resulting in an increase in the amount of data of the image file boot.img. Then, the storage space required for the data of the image file boot.img also increases accordingly. For example, the storage space of the boot_a subpartition required for the data of the image file boot.img changes from space 301 to space 303, and the storage space required for the boot_b subpartition changes from 302 to space 304.

[0086] It should be understood that if the image data occupies a larger storage space, it may overwrite the subsequent storage space. Still using Figure 3 as an example, if the storage space of the boot_a subpartition required for the data of the image file boot.img changes from space 301 to space 303, it may overwrite the data of the boot_b subpartition located after the boot_a subpartition, as shown in the vertical shaded area in Figure 3. For another example, if the storage space of the boot_b subpartition required for the data of the image file boot.img changes from space 302 to space 304, it may overwrite the data of the vendor_boot_a subpartition located after the boot_b subpartition, as shown in the diagonal shaded area in Figure 3.

[0087] However, the existing Virtual A / B OTA upgrade solution mainly focuses on how to write the upgrade data (such as image data) in the upgrade package into the static partition and dynamic partition (Super), but cannot solve the problem shown in Figure 3 that after the image file is expanded, the data in the remaining storage space will be overwritten.

[0088] In other words, the existing Virtual A / B OTA upgrade solution can only complete the operating system upgrade within the constraints of existing partition deployment, such as the partition deployment shown on the left side of Figure 3. Typically, when faced with the problem shown in Figure 3, the only way to meet the demand is to release a new product. For example, a new phone can be released and the appropriate partition deployment can be made in the new phone.

[0089] Based on this, an embodiment of the present application provides a method for upgrading an operating system. The electronic device 130 can adjust the partition deployment in recovery mode so that the adjusted partition deployment meets the new storage space requirements of the target version of the operating system. Adjusting the partition deployment includes one or more operations of adding a partition, deleting a partition, modifying the partition name, and adjusting the partition size and / or address (including the start address and / or end address) of the partition.

[0090] Taking the partition size adjustment as an example, the boot_a and boot_b subpartitions are used to store data from the operating system's image file, boot.img. Referring to Figure 4, before adjustment, the boot_a and boot_b subpartitions store data from the boot.img image file of the current operating system version (e.g., version V1.0). Furthermore, the boot_a subpartition's starting address is A1 and its ending address is B1, meaning its partition size is B1-A1. The boot_b subpartition's starting address is A2 and its ending address is B2, meaning its partition size is B2-A2. Furthermore, the vendor_boot_a subpartition's starting address is A3 and its ending address is B3, meaning its partition size is B3-A3. Furthermore, the vendor_boot_a subpartition's starting address is A3 and its ending address is B3, meaning its partition size is B3-A3.

[0091] However, in the target version of the operating system (e.g., version V2.0), new features are added to the image file boot.img. Therefore, the data in the image file boot.img requires more storage space, such as increasing the storage space by △. Therefore, the partition layout can be adjusted. Continuing with Figure 4, after the adjustment, the starting address of the boot_a subpartition remains A1, and the ending address is adjusted to B1 + △. The partition size of the boot_a subpartition is then increased by △ to accommodate the image data after the new features are added. The starting address of the boot_b subpartition is adjusted to A2 + △ to avoid overlap between the boot_a and boot_b subpartitions. The ending address of the boot_b subpartition is adjusted to B2 + 2 * △. The partition size of the boot_a subpartition is then (B2 + 2 * △) - (A2 + △) = B2 - A2 + △. In other words, the partition size of the boot_b subpartition is increased by △ to also accommodate the image data after the new features are added. Furthermore, the starting address of the vendor_boot_a subpartition is adjusted to A3+2*△ to prevent overlap between the boot_b subpartition and the vendor_boot_a subpartition. The ending address of the vendor_boot_a subpartition is adjusted to B3+2*△, so the partition size of the vendor_boot_a subpartition remains (B3+2*△)-(A3+2*△)=B3-A3. In other words, the partition size of the vendor_boot_a subpartition remains unchanged, ensuring that it can accommodate the image file currently stored in the vendor_boot_a subpartition.

[0092] After completing the partition deployment adjustment, the electronic device 130 can exit the recovery mode and, under normal operation, store the upgrade data in each sub-partition after the partition deployment adjustment based on the upgrade package to complete the operating system upgrade. The upgrade package is used to upgrade the operating system to the target version of the operating system. In this way, each partition can store the mirror data of the target version of the operating system, and the data of adjacent sub-partitions will not overwrite each other.

[0093] Continuing with FIG4 , after adjustment, the data of the image file boot.img (i.e., the expanded image file boot.img) in the V2.0 operating system can be stored in the boot_a subpartition and the boot_b subpartition. Furthermore, since the storage spaces of adjacent subpartitions boot_a, boot_b, and vendor_boot_a do not overlap, data overwriting does not occur.

[0094] Of course, it should be noted that in some scenarios, the purpose of adjusting the partition deployment is only to optimize the storage space. For example, the partition size of the partition is reduced to free up idle storage space for the user data partition (Userdata). In these scenarios, the partition deployment is not adjusted to meet the storage space requirements of the target version (such as version V2.0) of the operating system. Therefore, for these scenarios, the operating system upgrade method provided in the embodiment of the present application may only include the process of adjusting the partition deployment, and does not include the process of upgrading the operating system to the target version based on the upgrade package. In the following, the example of upgrading the operating system to the target version based on the upgrade package is mainly used to illustrate.

[0095] For example, electronic device 130 in the embodiments of the present application includes, but is not limited to, mobile phones, headphones, tablet computers, smart refrigerators, smart speakers, and other devices that can be installed with an operating system. Alternatively, electronic device 130 may also refer to a control board within electronic device 130 that can be installed with an operating system. Furthermore, in the embodiments of the present application, the operating system includes, but is not limited to, iOS, Android, Harmony, Windows, Linux, or other operating systems.

[0096] Referring to FIG5 , which is a hardware structure diagram of an electronic device 130 provided in an embodiment of the present application, as shown in FIG5 , taking the electronic device 130 as a mobile phone as an example, the electronic device may include a processor 310, an external memory interface 320, an internal memory 321, a universal serial bus (USB) interface 330, a charging management module 340, a power management module 341, a battery 342, an antenna 1, an antenna 2, a mobile communication module 350, a wireless communication module 360, an audio module 370, a speaker 370A, a receiver 370B, a microphone 370C, an earphone interface 370D, a sensor module 380, a button 390, a motor 391, an indicator 392, a camera 393, a display 394, and a subscriber identification module (SIM) card interface 395, etc.

[0097] It should be understood that the structure illustrated in this embodiment does not constitute a specific limitation on the electronic device. In other embodiments, the electronic device may include more or fewer components than shown, or may combine or separate certain components, or have different component arrangements. The illustrated components may be implemented in hardware, software, or a combination of software and hardware.

[0098] The processor 310 may include one or more processing units. For example, the processor 310 may include an application processor (AP), a modem processor, a graphics processing unit (GPU), an image signal processor (ISP), a controller, a memory, a video codec, a digital signal processor (DSP), a baseband processor, and / or a neural-network processing unit (NPU). The different processing units may be independent devices or integrated into one or more processors.

[0099] It is understood that the interface connection relationship between the modules illustrated in this embodiment is only for illustrative purposes and does not constitute a structural limitation on the electronic device. In other embodiments, the electronic device may also adopt different interface connection methods from the above embodiments, or a combination of multiple interface connection methods.

[0100] The charging management module 340 is configured to receive charging input from a charger. The charger can be either a wireless charger or a wired charger. In some wired charging embodiments, the charging management module 340 can receive charging input from the wired charger via the USB interface 330. In some wireless charging embodiments, the charging management module 340 can receive wireless charging input via the electronic device's wireless charging coil. While charging the battery 342, the charging management module 340 can also provide power to the electronic device via the power management module 341.

[0101] The power management module 341 is used to connect the battery 342, the charging management module 340, and the processor 310. The power management module 341 receives input from the battery 342 and / or the charging management module 340 and provides power to the processor 310, the internal memory 321, the external memory, the display 394, the camera 393, and the wireless communication module 360. The power management module 341 can also be used to monitor parameters such as battery capacity, battery cycle count, and battery health status (leakage, impedance). In some other embodiments, the power management module 341 can also be set in the processor 310. In other embodiments, the power management module 341 and the charging management module 340 can also be set in the same device.

[0102] The wireless communication function of the electronic device can be implemented through antenna 1, antenna 2, mobile communication module 350, wireless communication module 360, modem processor and baseband processor.

[0103] The wireless communication module 360 ​​can provide wireless communication solutions for electronic devices, 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. The wireless communication module 360 ​​can be one or more devices that integrate at least one communication processing module. The wireless communication module 360 ​​receives electromagnetic waves via the antenna 2, frequency modulates and filters the electromagnetic wave signals, and sends the processed signals to the processor 310. The wireless communication module 360 ​​can also receive the signal to be sent from the processor 310, frequency modulate it, amplify it, and convert it into electromagnetic waves for radiation through the antenna 2.

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

[0105] The electronic device can implement a camera function using an ISP, a camera 393, a video codec, a GPU, a display 394, and an application processor. The ISP processes data fed back by the camera 393. The camera 393 is used to capture still images or videos. The object is projected onto a photosensitive element through the lens to generate an optical image. In some embodiments, the electronic device may include one or N cameras 393, where N is a positive integer greater than one.

[0106] External memory interface 320 can be used to connect an external memory card, such as a Micro SD card, to expand the storage capacity of the electronic device. The external memory card communicates with processor 310 via external memory interface 320 to implement data storage functions. For example, files such as music and videos can be stored on the external memory card.

[0107] The internal memory 321 can be used to store computer executable program code, which includes instructions. The processor 310 executes various functional applications and data processing of the electronic device by running the instructions stored in the internal memory 321. For example, the processor 310 can perform the operation of upgrading the operating system by executing the instructions stored in the internal memory 321. The internal memory 321 may include a program storage area and a data storage area. Among them, the program storage area can store the operating system, at least one application required for a function (such as a sound playback function, an image playback function, etc.), etc. The data storage area can store data created during the use of the electronic device (such as audio data, a phone book, etc.), etc. In addition, the internal memory 321 may include a high-speed random access memory, and may also include a non-volatile memory, such as at least one disk storage device, a flash memory device, a universal flash storage (UFS), etc. It should be understood that the internal memory 321 can be set inside the processor 310, or the internal memory 321 can be independently set outside the processor 310.

[0108] In a specific implementation, the internal memory 321 may include ROM and random access memory (RAM). In practical applications, RAM is also called "main memory". It can be read and written at any time and is very fast. It is usually used as a temporary data storage medium for the operating system or other running programs. When the power is turned off, RAM cannot retain data. That is, RAM usually stores temporary data when the electronic device is running. ROM is also called "non-volatile memory". The data stored in it is generally pre-written before being installed in the entire machine, such as the operating system's image data and user data generated when the user uses the electronic device. It can only be read during the operation of the entire machine and cannot be quickly and conveniently rewritten like RAM. Therefore, the data stored in ROM is stable and will not change after power failure.

[0109] In this application, ROM can adopt a data storage structure similar to Virtual A / B shown in Figure 1. In an electronic device, a total partition table (Ptable, referred to as the partition table in this article) can be used to describe the partition deployment of the data storage structure of Virtual A / B in ROM. Exemplarily, the partition table is saved in Universal Flash Storage (UFS). After the electronic device is started, the partition table can be queried from the UFS to obtain the partition deployment of the data storage structure in the ROM. The partition table includes the starting address and ending address of the basic partition (Common), static partition (A), static partition (B), dynamic partition (Super) and user data partition (Userdata). Exemplarily, some of the data in the partition table are shown in Table 1 below:

[0110] Table 1

[0111] Taking the x-loader subpartition in Table 1 as an example, Table 1 above can indicate that the partition size of the x-loader_a subpartition in the static partition (A) is 256KB, its starting address in the storage space is 0x00000100, and its ending address is 0x00000X1X2X3; the partition size of the x-loader_b subpartition in the static partition (B) is 256KB, its starting address in the storage space is 0x00000X4X5X6, and its ending address is 0x00000X7X8X9.

[0112] It should be noted that the partition table can describe partition deployment. Therefore, in this application, partition deployment can be adjusted by adjusting the partition table. For example, by modifying the start and end addresses of a subpartition in the partition table, the partition deployment of the subpartition in the storage space can be adjusted. In short, adjusting the partition table is actually adjusting the partition deployment.

[0113] It should be noted that for the basic partition, static partition (A) and static partition (B), the partition name, partition size, start address and end address of each subpartition are described in the partition table. However, with respect to the dynamic partition (Super), only the partition size, start address and end address of the dynamic partition (Super) as a whole are described in the partition table. For example, in Table 1 above, the partition size of the dynamic partition (Super) as a whole is 8GB, the start address is 0x00000Q1Q2Q3, and the end address is 0x0000Q4Q5Q6Q7. The address information of each subpartition (such as the system subpartition) in the dynamic partition (Super) is stored in the metadata ( / supermetadata) of the dynamic partition (Super) header. Therefore, with respect to the dynamic partition (Super), the partition deployment is adjusted by adjusting the partition table in this application, and can only be adjusted for the dynamic partition (Super) as a whole. For example, changing the start address and end address of the dynamic partition (Super) as a whole.

[0114] Furthermore, the metadata ( / supermetadata) in the dynamic partition (Super) header records the address information of each subpartition (such as the system subpartition) within the dynamic partition (Super) using offsets. In other words, the address information represents the relative position of each subpartition (such as the system subpartition) within the dynamic partition (Super). Therefore, after adjusting the dynamic partition (Super) as a whole, the position of each subpartition within the dynamic partition (Super) on the ROM can naturally change accordingly.

[0115] That is, in this application, adjusting the partition table includes adjusting the basic partition (Common), static partition (A), and sub-partitions in static partition (B), and can also include adjusting the entire dynamic partition (Super). This achieves adjustable partition deployment. Below, we mainly use the adjustment of sub-partitions in static partition (A) and static partition (B) as an example to illustrate this application solution.

[0116] For the sake of convenience, the partition name, partition size, start address, and end address may be collectively referred to as partition information.

[0117] The electronic device can implement audio functions such as music playback and recording through the audio module 370, the speaker 370A, the receiver 370B, the microphone 370C, the headphone jack 370D, and the application processor.

[0118] The buttons 390 include a power button, a volume button, etc. The buttons 390 can be mechanical buttons. They can also be touch buttons. The electronic device can receive button inputs and generate key signal inputs related to the user settings and function controls of the electronic device. The motor 391 can generate vibration prompts. The motor 391 can be used for incoming call vibration prompts, or for touch vibration feedback. The indicator 392 can be an indicator light, which can be used to indicate the charging status, power changes, messages, missed calls, notifications, etc. The SIM card interface 395 is used to connect the SIM card. The SIM card can be inserted into the SIM card interface 395, or pulled out from the SIM card interface 395 to achieve contact and separation with the electronic device. The electronic device can support 1 or N SIM card interfaces, where N is a positive integer greater than 1.

[0119] The following will further describe the solution provided by the embodiments of the present application with reference to the accompanying drawings, taking the upgrade system shown in FIG1 and the electronic device shown in FIG5 as examples.

[0120] FIG6 is a flow chart of an operating system upgrade method provided in an embodiment of the present application. As shown in FIG6 , taking the electronic device 130 currently booting from the static partition (A) as an example, that is, the electronic device 130 is running in a system (referred to as system A) composed of image files in the static partition (A) and the dynamic partition (Super), the operating system upgrade method includes:

[0121] S601: The packet processing server 110 creates a patch package, which includes a version number and a table adjustment package, and the table adjustment package includes a partition table.

[0122] The version number is the version number of the intermediate version (also called the first version number). The intermediate version refers to the version after the current version of the operating system is repaired using the patch package. For example, if the current operating system version (also called the current version or the first version) is V1.0, and the version repaired using the patch package is V1.1, then the intermediate version is V1.1.

[0123] In this application, the patch package includes a version number and a table adjustment package for adjusting the partition table. Among them, the version number is used to indicate the intermediate version. The table adjustment package is used as a basis for adjusting the partition deployment. The table adjustment package includes a partition table (also referred to as the second partition table), that is, the partition table shown in Table 1 above. The partition table can describe the partition deployment of the data storage structure of Virtual A / B in the intermediate version (also referred to as the second version), that is, the partition deployment of the basic partition (Common), static partition (A), static partition (B), dynamic partition (Super) and user data partition (Userdata). That is, the storage space demand of the target version of the operating system.

[0124] For example, the data structure of the patch package is as follows:

[0125] ptablechange.tag;

[0126] META-INF;

[0127] payload.bin;

[0128] payload_properties.txt;

[0129] SOFTWARE_VER.mbn;

[0130] update_base_ptable_change.zip;

[0131] VERSION.mbn.

[0132] ptablechange.tag is the partition table adjustment tag, indicating that the patch package can be used to adjust partition deployment. payload.bin contains the partition information for the subpartitions involved in repairing the operating system based on the patch package. update_base_ptable_change.zip is the table adjustment package.

[0133] For example, the data structure of the table adjustment package (i.e., update_base_ptable_change.zip) is as follows:

[0134] Ptable;

[0135] META-INF;

[0136] OTA_update.tag;

[0137] skipauth_pkg.tag;

[0138] vendor_country.mbn;

[0139] change_detail.mbn.

[0140] Ptable is the partition table, and its structure is shown in Table 1 above. change_detail.mbn is a partition table change file that describes the partition changes between the intermediate version of the partition table and the current version of the partition table (also called the first partition table). These changes include, but are not limited to, adding partitions, deleting partitions, and modifying partition names.

[0141] For example, the change_detail.mbn includes add: xbl_dump, which is used to describe that the intermediate version of the partition table adds the xbl_dump subpartition compared to the current version of the partition table.

[0142] For ease of explanation, the newly added partition (e.g., the xbl_dump subpartition) can be referred to as the first partition. That is, the partition table in the table adjustment package includes the partition information for the first partition, but the partition table in the current version does not. Furthermore, the information indicating the newly added partition (e.g., add: xbl_dump) in the change_detail.mbn file can be referred to as the first indication information.

[0143] For another example, change_detail.mbn includes delete: abl_test, which is used to describe that the intermediate version of the partition table has deleted the abl_test subpartition compared to the current version of the partition table.

[0144] Similarly, for ease of explanation, the deleted partition (e.g., the abl_test subpartition) can be referred to as the second partition. That is, the partition table of the current version includes the partition information for the second partition, but the partition table in the table adjustment package does not. Furthermore, the information in the change_detail.mbn indicating the partition deletion (e.g., delete: abl_test) can be referred to as the second indication information.

[0145] For another example, change_detail.mbn includes change: abl_reserve, abl, which is used to describe that the name of the sub-partition abl_reserve in the partition table of the current version is changed to the name of the sub-partition abl in the partition table of the intermediate version.

[0146] Similarly, for the sake of convenience, the partition in the current version of the partition table before the name is changed (such as the abl_reserve subpartition) can be called the third partition, and the partition in the partition table in the table adjustment package before the name is changed (such as the abl subpartition) can be called the fourth partition. That is, the third partition in the partition table of the current version is renamed to the fourth partition in the partition table in the table adjustment package. Under normal circumstances, changing the partition name does not affect the function of the partition, so the role of the fourth partition is usually the same as that of the third partition. For example, both are used to store the same data, such as storing the data of the mirror file abl_test.img. In addition, the information indicating the name modification in change_detail.mbn (such as change: abl_reserve, abl) can be called the third indication information.

[0147] The patch server 110 may determine the partition table of the intermediate version based on the data size of each image file in the target version of the operating system, thereby producing a patch package.

[0148] Using Figure 4 as an example, in the target version of the operating system, the image file boot.img has had its data increased by △. Therefore, in the intermediate version's partition table, the sizes of both the boot_a and boot_b subpartitions should increase by △. Therefore, we can determine that the end address of the boot_a subpartition and the start address of the boot_b subpartition have both shifted backward by △. That is, in the intermediate version's partition table, the end address of the boot_a subpartition is B1 + △, and the start address of the boot_b subpartition is A2 + △. We can also determine that the end address of the boot_b subpartition, as well as the start and end addresses of each subsequent subpartition, have shifted backward by 2*△. This yields the intermediate version's partition table.

[0149] S602 : The packet capture server 110 uploads the patch package to the OTA server 120 .

[0150] After creating the patch package, the packet server 110 may send the patch package to the OTA server 120 so that the OTA server 120 can manage the patch package in a unified manner.

[0151] S603 : The electronic device 130 downloads the patch package from the OTA server 120 .

[0152] The OTA server 120 can proactively push the download address of the patch package to the electronic device 130 for download. Alternatively, the electronic device 130 can send a package search request to the OTA server 120, and the OTA server 120 sends the download address of the patch package to the electronic device 130 based on the package search request. After obtaining the download address, the electronic device 130 can download the patch package.

[0153] S604: The electronic device 130 updates the version number based on the patch package.

[0154] In this application, after obtaining the patch package, the electronic device 130 can update the version number of the operating system in the electronic device 130 to the version number carried in the patch package, that is, the version number of the intermediate version, for example, from V1.0 to V1.1.

[0155] For example, the patch package includes payload.bin, which includes the partition information of the sub-partitions involved in repairing the operating system based on the patch package. The main function of the patch package is to patch, so the partitions involved naturally include the patch (Patch) sub-partition in the static partition. Therefore, the partition information of the Patch sub-partition, such as the partition name "Patch", can be obtained from the payload.bin of the patch package. The electronic device 130 can write the version number of the intermediate version into the Patch sub-partition to refresh the version number.

[0156] It should be understood that the electronic device 130 is currently booted from the static partition (A), and the version number of the intermediate version needs to be written into the Patch_b subpartition of the static partition (B), thereby avoiding the impact on the running A system.

[0157] By refreshing the version number, the electronic device 130 can subsequently carry the refreshed version number to request a patch package from the OTA service 120 for further repairing the operating system in the electronic device 130. Alternatively, the electronic device 130 can subsequently carry the refreshed version number to request an upgrade package from the OTA service 120 for upgrading the operating system in the electronic device 130. For example, the refreshed version number is V1.1. Then, after the electronic device 130 completes the repair of the operating system based on the patch package, the electronic device 130 can send a search request to the OTA server 120 with V1.1. The OTA server 120 compares the V1.1 carried in the search request with the latest version number (such as V2.0) in the OTA server 120 and finds that there is a newer version than V1.1. In this case, the OTA server 120 can provide the electronic device 130 with the download address of the upgrade package of the V2.0 version of the operating system for the electronic device 130 to download and update.

[0158] In some embodiments, referring to FIG. 7 , before S604 , S701 may be further included.

[0159] S701. The electronic device 130 verifies the patch package.

[0160] For example, the patch package includes a digital signature (META-INF) of the patch package. The electronic device 130 can verify whether the META-INF of the patch package is legitimate, thereby confirming whether the patch package is legitimate. For specific implementation details, please refer to the relevant existing technology and will not be repeated here.

[0161] In this way, after determining that the patch package is legitimate, the operating system can be repaired based on the patch package. For example, after determining that the patch package is legitimate in S701, S604 and subsequent steps are performed. This can avoid improper processing of illegal patch packages.

[0162] S605 : The electronic device 130 changes the boot sequence from booting from the static partition (A) to booting from the static partition (B).

[0163] Electronic device 130 currently boots from static partition (A), meaning it operates in a system (referred to as system A) consisting of the mirrored data in static partition (A) and dynamic partition (Super). Similarly, electronic device 130 boots from static partition (B), meaning it operates in a system (referred to as system B) consisting of the mirrored data in static partition (B) and dynamic partition (Super).

[0164] By changing the boot sequence from static partition (A) to static partition (B), the electronic device 130 can boot from static partition (B) the next time it boots, i.e., run under operating system B. Furthermore, by booting from static partition (B), the electronic device 130 can read the latest version number from the Patch_b subpartition of static partition (B) and use it to request an upgrade package.

[0165] Take the Universal Flash Storage (UFS) in the Master Boot Record (MBR) format as an example. In the MBR of UFS (Master Boot Sector, the first sector of UFS, that is, the 0th cylinder, 0th head, 1st sector of the C / H / S address), the device startup sequence description is saved. For example, the startup sequence flag is A, indicating that it is started from the static partition (A); the startup sequence flag is B, indicating that it is started from the static partition (B). After the device is started, the device startup sequence is first read from the MBR of UFS to determine whether it needs to be started from the static partition (A) or the static partition (B). Therefore, the electronic device 130 can rewrite the startup sequence flag in the MBR from A to B.

[0166] It should be noted that changing the boot order from static partition (A) to static partition (B) simply instructs the electronic device 130 to boot from static partition (B) next time. That is, the next time it boots, it will run in system B. This does not take effect immediately. In other words, after changing the boot order from static partition (A) to static partition (B), the electronic device 130 does not immediately switch from system A to system B.

[0167] It should be noted that the above steps S604 and S605 are primarily for electronic device 130 to read the version number of the intermediate version, thereby facilitating subsequent requests for upgrade packages. Of course, based on the above description, in some scenarios, the patch package may only be used to optimize distribution deployment, and there is no need to upgrade the operating system to the target version. In this case, there is no need to request an upgrade package. Therefore, in these scenarios, steps S604 and S605 can also be omitted.

[0168] S606: The electronic device 130 restarts and enters recovery mode.

[0169] Since the boot order has been changed from static partition (A) to static partition (B), when the electronic device 130 restarts, it will start from static partition (B) and can run under system B. This restart can also be called the first restart after obtaining the patch package.

[0170] In this application, the electronic device 130 needs to complete the operation of adjusting the partition table in recovery mode. Therefore, this restart also needs to trigger the entry into recovery mode. For example, taking the operating system as Android, the electronic device 130 can use the following restart command to control the electronic device 130 to restart and enter recovery mode:

[0171] property_set(ANDROID_RB_PROPERTY, "reboot, recovery").

[0172] After entering the recovery mode, the electronic device 130 may perform a process of adjusting the partition table, as shown in S607 to S609 below.

[0173] In practice, the patch package can be used to repair vulnerabilities in the data or operating system within the electronic device 130, rather than just for adjusting the partition table. Based on this, in some embodiments, referring to FIG. 7 , before S606 , the electronic device 130 first needs to determine whether the patch package is used to adjust the partition table, which also includes S702a:

[0174] S702a: The electronic device 130 determines that the patch package is used to adjust the partition table.

[0175] A patch package for adjusting a partition table typically includes a tag (also called a first tag) for indicating the partition table adjustment, such as the tag ptablechange.tag. Furthermore, a patch package for adjusting a partition table typically includes a small package with a preset name (also called a data package with a preset name), such as update_base_ptable_change.zip. The preset name of the patch package indicates the patch package.

[0176] Based on this, the electronic device 130 can search the patch package for a tag indicating that the partition table is to be adjusted and a small packet named with the preset table adjustment package name. If a tag indicating that the partition table is to be adjusted and a small packet named with the preset table adjustment package name are found, it can be determined that the patch package is for adjusting the partition table. Conversely, if a tag indicating that the partition table is to be adjusted or a small packet named with the preset table adjustment package name are not found, it can be determined that the patch package is not for adjusting the partition table.

[0177] Of course, the electronic device 130 may also only search for a tag indicating that the partition table is to be adjusted. If a tag indicating that the partition table is to be adjusted is found, the patch package is determined to be used for adjusting the partition table. Alternatively, the electronic device 130 may only search for a small packet with a preset table adjustment package name. If a small packet with a preset table adjustment package name is found, the patch package is determined to be used for adjusting the partition table. This embodiment of the present application does not specifically limit this.

[0178] With this embodiment, the system is restarted into recovery mode only after it is determined that the patch package is used to adjust the partition table, thereby avoiding mistakenly entering recovery mode when the patch package is used for other functions that do not require the use of recovery mode.

[0179] In some scenarios, although the electronic device 130 receives a patch package for adjusting the partition table, the partition table in the patch package may be incorrect, for example, not the intermediate version of the partition table. In this case, it is obviously unreasonable to restart into recovery and further perform the partition table adjustment process.

[0180] Based on this, in some embodiments, referring to FIG. 7 , before S606 , S702 b - S703 are also included.

[0181] S702b: The electronic device 130 compares the partition table in the table adjustment package with the partition table of the current version.

[0182] The current version of the partition table refers to the partition table of the operating system currently running on the electronic device 130. Exemplarily, the electronic device 130 may obtain the current version of the partition table from the UFS.

[0183] When comparing the partition table in the table adjustment package with the partition table of the current version, the electronic device 130 may compare whether the partitions included in the two are the same, and whether the sizes, start addresses, and end addresses of the partitions are the same. If any of the above items are different, it is determined that the partition table in the table adjustment package is different from the partition table of the current version. If all of the above items are the same, it is determined that the partition table in the table adjustment package is the same as the partition table of the current version.

[0184] If the partition table in the table adjustment package is the same as the partition table of the current version, it means that the partition table in the table adjustment package is the partition table of the current version and has not changed. In this case, it is considered an exception and there is no need to enter recovery and further perform partition table adjustment processing, that is, there is no need to execute S606 and subsequent steps.

[0185] Conversely, if the partition table in the adjustment package is different from the partition table of the current version, it indicates that the partition table in the adjustment package has changed compared to the partition table of the current version. In this case, you need to enter recovery mode and further perform the partition table adjustment process.

[0186] Accordingly, referring to FIG. 7 , S606 is specifically S606a:

[0187] S606a: If the partition table in the table adjustment package is different from the partition table of the current version, the electronic device 130 restarts and enters the recovery mode.

[0188] With this embodiment, the recovery mode can be entered only when the partition table in the table adjustment package is updated compared to the partition table of the current version. Thus, the recovery mode can be entered only when there is a need to adjust the partition table.

[0189] Furthermore, in this embodiment, the timing of executing S605 is not limited to that shown in FIG7 . In practice, the boot sequence can be changed from booting from static partition (A) to booting from static partition (B) before the next boot. In other words, S605 can be executed at any time between S604 and before the next boot of electronic device 130 (e.g., S606a). This ensures that electronic device 130 boots from static partition (B) the next time.

[0190] In some embodiments, referring to FIG. 7 , after entering the recovery mode, that is, after S606 , S703 may be further included.

[0191] S703. The electronic device 130 verifies the meter adjustment package.

[0192] For example, the meter adjustment package includes a digital signature (META-INF) of the meter adjustment package. The electronic device 130 can verify whether the META-INF of the meter adjustment package is legal, thereby confirming whether the meter adjustment package is legal. For specific implementation details, please refer to relevant existing technologies and will not be repeated here.

[0193] In this way, after determining that the table adjustment packet is legitimate, relevant processing of adjusting the partition table can be further implemented based on the table adjustment packet, thereby avoiding improper processing of illegal table adjustment packets.

[0194] S607 : The electronic device 130 migrates the system data in the basic partition (Common), the static partition (A), the static partition (B), and the dynamic partition (Super).

[0195] In this way, the electronic device 130 can save system data (such as mirror data) in an area outside the basic partition (Common), static partition (A), static partition (B), and dynamic partition (Super) to facilitate subsequent migration. For example, a copy of the system data can be copied to the user data partition (Userdata). In this way, the system data can be migrated out without affecting the operation of the recovery mode.

[0196] For example, referring to FIG8 , taking static partition (A) and static partition (B) as examples, before migration, image data 11 is stored in the bootloader_a subpartition of static partition (A), and image data 12 is stored in the bootloader_b subpartition of static partition (B). Image data 21 is stored in the boot_a subpartition of static partition (A), and image data 22 is stored in the boot_b subpartition of static partition (B). Continuing to refer to FIG8 , after migration, a copy of image data 11, image data 12, image data 21, and image data 22 is stored in the user data partition (Userdata). For example, there is a tail of the user data partition (Userdata).

[0197] Furthermore, to facilitate the subsequent data migration process, different partitions storing different system data can be distinguished by migrating system data to files named after the subpartitions. For static partitions, the suffixes -a and _b can be used to distinguish them.

[0198] For example, referring to Figure 8, the image data 11 in bootloader_a is migrated to the file named bootloader_a.img in the user data partition (Userdata), the image data 12 in bootloader_b is migrated to the file named bootloader_b.img in the user data partition (Userdata), the image data 21 in boot_a is migrated to the file named boot_a.img in the user data partition (Userdata), and the image data 22 in boot_b is migrated to the file named boot_b.img in the user data partition (Userdata).

[0199] Of course, in other embodiments, the electronic device 130 may also distinguish storage partitions for different system data in other ways. For example, the electronic device 130 may associate the system data with the name of the partition storing the system data and migrate it to the user data partition (Userdata). For example, bootloader_a may be associated with image data 11 and stored in the user data partition (Userdata).

[0200] In practice, in recovery mode, various operations can be performed on the data or operating system inside the electronic device 130. For example, the system of the electronic device 130 can be modified. For another example, in this application, the partition table is adjusted using recovery mode.

[0201] Based on this, in some embodiments, after entering the recovery mode, the electronic device 130 first needs to determine the purpose of entering the recovery mode, so as to facilitate the execution of corresponding processing to achieve the purpose. Then, in the scenario where the recovery mode is used in the present application to adjust the partition table, it is mainly necessary to determine whether the purpose is to adjust the partition table. Specifically, referring to Figure 7, after entering the recovery mode, S704 may also be included:

[0202] S704: The electronic device 130 determines whether the current scenario is to adjust the partition table.

[0203] Different packages included in the patch package will result in different goals after entering recovery mode. For example, if the package in the patch package is a modification package, then after entering recovery mode, the modification purpose can be achieved based on the modification package, such as changing the demonstration format to a commercial format. Another example is if the package in the patch package is a table adjustment package, then after entering recovery mode, the partition table can be adjusted based on the table adjustment package.

[0204] Based on this, in a specific implementation, the electronic device 130 may determine whether the current scenario is to adjust the partition table based on the name of a small package (such as a modification package or a table adjustment package) in the patch package.

[0205] If the name of the small package in the patch package is the same as the preset table adjustment package name (also called the preset name), it is determined that the current scenario is to adjust the partition table. For example, if the preset table adjustment package name is update_base_ptable_change.zip and the name of the small package in the patch package is also update_base_ptable_change.zip, it can be determined that the current scenario is to adjust the partition table.

[0206] If the name of the subpackage in the patch package is not the preset table adjustment package name, it is determined that the current scenario is not a partition table adjustment. For example, the preset table adjustment package name is update_base_ptable_change.zip, and the subpackage name in the patch package is update_base_demochange.zip. If the subpackage name in the patch package is different from the preset table adjustment package name, it can be determined that the current scenario is not a partition table adjustment.

[0207] Accordingly, referring to FIG. 7 , in this embodiment, S607 is specifically S607a:

[0208] S607a: If it is determined that the current scenario is to adjust the partition table, the electronic device 130 migrates the system data in the basic partition (Common), static partition (A), static partition (B), and dynamic partition (Super).

[0209] That is, in this embodiment, system data migration is performed only after determining that the current scenario is a partition table adjustment scenario, thereby avoiding erroneous migration of system data in a scenario where the partition table is not adjusted, which ultimately affects system operation.

[0210] S608: The electronic device 130 updates the current version of the partition table in the electronic device 130 using the partition table in the table adjustment package to obtain an updated partition table.

[0211] That is, the partition deployment of the ROM is updated from the partition deployment described by the partition table of the current version to the partition deployment described by the partition table in the table adjustment package.

[0212] For example, the partition table of the current version in the electronic device 130 is shown in Table 1 above, and the partition table in the table adjustment package is shown in Table 2 below:

[0213] Table 2

[0214] Obviously, compared with Table 1, the partition sizes of the boot_a subpartition and the boot_b subpartition in Table 2 are both expanded from 32MB to 64MB, and the addresses (including the start address and / or end address) of the boot_a subpartition and the partitions thereafter are also changed accordingly.

[0215] In a specific implementation, the electronic device 130 may modify the current version of the partition table to make it consistent with the partition table in the table adjustment package, thereby obtaining an updated partition table.

[0216] In another specific implementation, the electronic device 130 may also use the partition table in the table adjustment package to replace the current version of the partition table to obtain an updated partition table.

[0217] After obtaining the updated partition table, the electronic device 130 may store the updated partition table, for example, store the updated partition table in a UFS for subsequent use.

[0218] S609: The electronic device 130 migrates the system data back to each partition described in the updated partition table.

[0219] In this way, before the electronic device 130 is upgraded to the target version, each partition can still store the image data of the current version of the operating system, thereby ensuring that the electronic device 130 can operate normally.

[0220] Compared to the current version's partition table, the updated partition table includes one or more of the following change types: adding partitions; deleting partitions; modifying partition names; and other changes. The specific implementation of migrating system data differs for each of these four scenarios.

[0221] Exemplarily, the table adjustment package includes a change_detail.mbn file. change_detail.mbn is used to describe the partition changes of the intermediate version of the partition table compared to the current version of the partition table. Therefore, the electronic device 130 can determine the type of changes included in the updated partition table compared to the current version of the partition table by parsing change_detail.mbn. Regarding change_detail.mbn, please refer to the relevant description above and will not be repeated here.

[0222] The following will explain the above four situations and their corresponding migration methods respectively.

[0223] The first method is to add a partition, that is, to add the first partition.

[0224] During the system data migration process, for the newly added partition, the electronic device 130 can query the updated partition table for the newly added sub-partition and its corresponding partition information, such as the partition size, start address, and end address. The electronic device 130 then clears the data between the start address and end address of the newly added partition in the ROM (also referred to as the second target address interval). This ensures that the storage space corresponding to the newly added partition in the ROM is free of dirty data, such as the image data of the current version of the operating system.

[0225] For example, the change_detail.mbn file includes "add: xbl_dump", indicating the addition of the xbl_dump subpartition. For example, the partitions described by the current version of the partition table are shown on the left side of Figure 9, while the partitions described by the updated partition table are shown on the right side of Figure 9. Clearly, compared to the partition shown on the left side of Figure 9, the partition shown on the right side of Figure 9 has two additional subpartitions, xbl_dump_a and xbl_dump_b.

[0226] For the situation shown in Figure 9, during the process of migrating system data, the electronic device 130 can query the newly added partition indicated in change_detail.mbn in the updated partition table, namely the xbl_dump subpartition, and query the two subpartitions xbl_dump_a and xbl_dump_b, as well as the starting addresses and ending addresses of these two subpartitions. As shown on the right side of Figure 9, taking the query of the starting address of the xbl_dump_a subpartition as A1A1 and the ending address as B1B1, and the starting address of the xbl_dump_b subpartition as A2A2 and the ending address as B2B2 as an example, the electronic device 130 can clear the data between addresses A1A1-B2B2 in the ROM. For example, as shown on the right side of Figure 9, in the partition described by the current version of the partition table, the addresses A1A1-B2B2 in the ROM correspond to the storage space of the boot_a subpartition and the boot_b subpartition, which respectively store mirror data 21 and mirror data 22. Therefore, by clearing the data, the mirror data 21 and the mirror data 22 stored between the addresses A1A1 - B2B2 in the ROM in the current version can be deleted.

[0227] The second method is to delete the partition, that is, delete the second partition.

[0228] During the process of retrieving system data, the electronic device 130 does not need to retrieving the system data stored in the deleted partition, thereby avoiding retrieving redundant system data.

[0229] For example, the change_detail.mbn file includes "delete: abl_test", indicating that the abl_test subpartition has been deleted. For example, the partitions described by the current version of the partition table are shown on the left side of Figure 10, while the partitions described by the updated partition table are shown on the right side of Figure 10. Clearly, compared to the partition on the left side of Figure 10, the partition on the right side of Figure 10 has two subpartitions, abl_test_a and abl_test_b, deleted.

[0230] For the situation shown in Figure 10, during the process of migrating system data, the electronic device 130 can query the deleted partition recorded in change_detail.mbn, that is, the abl_test sub-partition, and not migrate the mirror data 31 in the abl_test_a_img file in the user data partition (Userdata), and not migrate the mirror data 32 in the abl_test_b_img file in the user data partition (Userdata).

[0231] It should be noted that only when the system data stored in the partition does not affect the operation of the current version after deletion, can the partition be deleted in recovery mode, and the system data stored in the partition will not be migrated back during migration. Otherwise, deleting the partition will cause the electronic device 130 to be unable to operate normally before upgrading to the target version. Therefore, the situation of deleting partitions is extremely rare. For example, when the mirror data stored in a static sub-partition in the current version of the operating system is redundant, the partition can be deleted through the solution of the present application, and the mirror data stored in the partition will not be migrated back. In this way, more storage space can be freed up.

[0232] The third method is to change the name, that is, rename the third partition to the fourth partition.

[0233] During the process of migrating system data, for the partition whose name has been changed, the electronic device 130 can query the partition whose name has been changed and its corresponding partition information, such as the partition size, starting address, and ending address, from the updated partition table. Then, the electronic device 130 can migrate the mirror data stored in the partition before the name change (i.e., the third partition) to a location between the starting address and the ending address (also referred to as the third target address interval) of the partition after the name change (i.e., the fourth partition) in the ROM. In this way, it can be ensured that the system data stored in the partition after the name change is the same as the system data stored in the partition before the name change.

[0234] For example, the change_detail.mbn file includes "change: abl_test, abl," indicating that the partition name abl_test is changed to abl. For example, the partitions described by the current version of the partition table are shown on the left side of Figure 11, while the partitions described by the updated partition table may be shown on the right side of Figure 11. Clearly, the abl_test_a and abl_test_b subpartitions shown on the left side of Figure 11 are changed to the abl_a and abl_b subpartitions shown on the right side of Figure 11, respectively.

[0235] In the scenario shown in FIG11 , during the system data migration process, electronic device 130 can search the updated partition table for the subpartition with the modified name recorded in change_detail.mbn, namely, the abl subpartition. The search results in two subpartitions, abl_a and abl_b, as well as their start and end addresses. As shown on the right side of FIG11 , the search results in the abl_a subpartition with a start address of C1C1 and an end address of D1D1, and the abl_b subpartition with a start address of C2C2 and an end address of D2D2. Furthermore, the name recorded in change_detail.mbn before the modification was abl_test, so electronic device 130 can migrate the image data 31 in the abl_test_a.img file in the user data partition (Userdata) back to the location between addresses C1C1 and D1D1 in the ROM, and the image data 32 in the abl_test_b.img file in the user data partition (Userdata) back to the location between addresses C2C2 and D2D2 in the ROM.

[0236] The fourth type is situations other than the first to third types mentioned above.

[0237] Referring to Figure 12, the partitions described by the current version of the partition table are shown on the left side of Figure 12, and the partitions described by the updated partition table may be shown on the right side of Figure 12. Situations other than the first to third scenarios described above include one or more of the following sub-situations: no change, partition size change, and address change but partition size unchanged.

[0238] Here, "unchanged" means that the partition size, start address, end address, and name remain unchanged. For example, the size, start address, end address, and name of the bootloader_a subpartition shown on the left side of Figure 12 are the same as those shown on the left side of Figure 12. The size, start address, end address, and name of the bootloader_b subpartition shown on the left side of Figure 12 are the same as those shown on the left side of Figure 12.

[0239] Partition size changes include both expansion and contraction. Contraction refers to a decrease in the storage space associated with a partition, while expansion refers to an increase in the storage space associated with a partition. For example, the size of the boot_a subpartition shown on the right side of Figure 12 is larger than that shown on the left, and the size of the boot_b subpartition shown on the right side of Figure 12 is larger than that shown on the left.

[0240] It should be noted that in order to ensure that the adjusted partition can still store the corresponding system data in the current operation, thereby ensuring that the electronic device 130 can still operate normally before upgrading to the target version, when the partition is reduced, the size of the reduced partition must be sufficient to store the system data of the corresponding partition in the current version.

[0241] It should be understood that changes in partition size are typically accompanied by changes in the starting and / or ending addresses. For example, the size of the boot_a subpartition shown on the right side of Figure 12 is larger than the size of the boot_a subpartition shown on the left side of Figure 12 . Accordingly, the ending address B1aB1aB1a of the boot_a subpartition shown on the right side of Figure 12 is later than the ending address B1B1B1 of the boot_a subpartition shown on the left side of Figure 12 . For another example, the size of the boot_b subpartition shown on the right side of Figure 12 is larger than the size of the boot_b subpartition shown on the left side of Figure 12 . Accordingly, the starting address A2aA2aA2a of the boot_b subpartition shown on the right side of Figure 12 is later than the starting address A2A2A2 of the boot_b subpartition shown on the left side of Figure 12 , and the ending address B2aB2aB2a of the boot_b subpartition shown on the right side of Figure 12 is later than the ending address B2B2B2 of the boot_b subpartition shown on the left side of Figure 12 .

[0242] A change in address but unchanged partition size is typically caused by a change in the sum of the sizes of the preceding partitions. For example, the preceding partition was deleted or its size was reduced, causing the sum of the sizes of the preceding partitions to decrease. Another example is a new preceding partition or an increase in its size, causing the sum of the sizes of the preceding partitions to increase. Another example is a change in the order of partitions, causing the preceding partition to change, causing the sum of the sizes of the preceding partitions to change.

[0243] For example, if the size of the previous partition is increased, as shown in Figure 12, the sizes of the boot_a and boot_b subpartitions increase, causing the addresses of the subsequent partitions to shift backward. For example, the starting address of the vendor_boot_a subpartition shifts from A3A3A3 to A3aA3aA3a, and the ending address of vendor_boot_a shifts from B3B3B3 to B3aB3aB3a.

[0244] For the convenience of explanation, the cells whose partition sizes change and whose addresses change but whose partition sizes remain unchanged may be collectively referred to as the fifth partition.

[0245] It should be understood that the first to third cases mentioned above are all recorded in the change_detail.mbn file of the table adjustment package. As for the fourth case, it can usually be reflected directly from the partition size, start address and / or end address in the partition table, and there is no need to record it in the change_detail.mbn file. Based on this, the electronic device 130 can parse the change_detail.mbn file in the table adjustment package, and for the partitions not recorded in the change_detail.mbn file, it is considered to be the partition involved in the fourth case (also referred to as the sixth partition). That is, the sixth partition is a partition other than the aforementioned first partition, second partition and fourth partition.

[0246] Continuing to refer to Figure 12, in the process of migrating system data, for any partition not recorded in the change_detail.mbn file (i.e., any partition involved in the fourth case), the electronic device 130 can migrate the system data that needs to be stored in the partition to a position between the start address and the end address of the partition recorded in the updated partition table (also referred to as the first target address interval).

[0247] For example, the change_detail.mbn file does not record the boot_a subpartition. The system data that boot_a needs to store is the image data 21 in the boot_a.img file in the user data partition (Userdata). In addition, the starting address of the boot_a subpartition in the updated partition table is A1A1A1, and the ending address is B1B1B1. Therefore, during the process of migrating system data, electronic device 130 can migrate the image data 21 in the boot_a.img file in the user data partition (Userdata) to the location of address A1A1A1-B1B1B1 in the ROM.

[0248] It should be noted that the above S609 is mainly described using static partitions as an example. In actual implementation, the above four situations can also occur in the basic partition (Common). They will not be described here in detail.

[0249] Additionally, for dynamic partitions (Super), only the entire dynamic partition (Super) can be adjusted (see Table 1 and the related text for details). Furthermore, overall dynamic partition (Super) adjustments typically only apply to address changes. For details, see the fourth scenario above, regarding the sub-case of address changes but unchanged partition size, which will not be repeated here.

[0250] After migrating the system data back to the partition described by the updated partition table (i.e., back to the ROM), the migrated system data is no longer useful and will occupy storage space, wasting storage resources. For example, if the system data is migrated to the user data partition (Userdata), the system data will occupy the storage space of the user data partition (Userdata).

[0251] Based on this, in some embodiments, referring to FIG. 7 , after S609, the following step S705 is further included:

[0252] S705: The electronic device 130 deletes the migrated system data, thereby freeing up storage space.

[0253] Taking the migration of system data to the user data partition (Userdata) as an example, after the migration is completed, the electronic device 130 can format the user data partition (Userdata) to delete the system data in the user data partition (Userdata).

[0254] S610: The electronic device 130 restarts.

[0255] Since the boot order has been changed from static partition (A) to static partition (B), the electronic device 130 will still boot from static partition (B) and can continue to run under system B. This restart can also be called the second restart after obtaining the patch package.

[0256] For example, taking the operating system as Android, the electronic device 130 can use the following restart instruction to control the electronic device 130 to restart:

[0257] property_set(ANDROID_RB_PROPERTY, "reboot").

[0258] It should be noted that this restart is a normal restart and does not enter the recovery mode, so the electronic device 130 can normally enter the operating system mode, such as Android mode. In addition, since the current version of the system data files have been migrated back to the corresponding partition, the current version of the operating system can still run normally.

[0259] S611: The package server 110 creates an upgrade package of the target version.

[0260] The package server 110 can create an upgrade package based on the system data of the target version. For example, if the target version has a new feature compared to the current version, the upgrade package created by the package server 110 should include data that implements the new feature.

[0261] S612 : The packet capture server 110 uploads the upgrade package to the OTA server 120 .

[0262] After creating the patch package, the packet server 110 may send the patch package to the OTA server 120 so that the OTA server 120 can manage the patch package in a unified manner.

[0263] S613 : The electronic device 130 downloads the upgrade package from the OTA server 120 .

[0264] The OTA server 120 can actively push the download address of the upgrade package to the electronic device 130 for the electronic device 130 to download the upgrade package. Alternatively, the electronic device 130 can send a search request to the OTA server 120, and the OTA server 120 sends the download address of the upgrade package to the electronic device 130 based on the search request. Exemplarily, the electronic device 130 can read the version number of the intermediate version (such as V1.1) from the Patch_b subpartition and send a search request carrying the version number of the intermediate version (such as V1.1) to the OTA server 120. The OTA server 120 compares the V1.1 carried in the search request with the latest version number (such as V2.0) in the OTA server 120 and finds that V2.0 is newer than V1.1. In this case, the OTA server 120 can provide the electronic device 130 with the download address of the upgrade package of the V2.0 version of the operating system for the electronic device 130 to download the update.

[0265] After obtaining the download address, the electronic device 130 can download the upgrade package of the target version (such as version V2.0).

[0266] S614: The electronic device 130 performs a virtual A / B upgrade based on the upgrade package.

[0267] After obtaining the upgrade package, the electronic device 130 can parse the upgrade package to obtain the upgrade data of each partition (such as an image file), and then write the upgrade data of each partition (such as an image file) into the corresponding partition described in the updated partition table, thereby upgrading the operating system to the target version.

[0268] For example, referring to FIG. 13 , when the electronic device 130 is running under system B (e.g., executing S610 to run under system B) and executing S614, S614 includes:

[0269] S1301: The electronic device 130 performs a data writing operation on the static partition (A) according to the upgrade package and the updated partition table to upgrade the static partition.

[0270] Exemplarily, electronic device 130 writes the upgrade data (e.g., image data) of each subpartition of the static partition in the upgrade package into the corresponding subpartition of the static partition (A) described in the updated partition table. For example, if the updated partition table includes the start address 1 and end address 2 of the boot_a subpartition, electronic device 130 may write the upgrade data of the boot_a subpartition in the upgrade package into the location between the start address 1 and the end address 2 in the ROM.

[0271] S1302, the electronic device 130 creates a virtual dynamic partition in the user data partition (Userdata) according to the upgrade package and the updated partition table, and writes the upgrade data of the dynamic partition (Super) into the virtual dynamic partition.

[0272] Exemplarily, the electronic device 130 writes the upgrade data (e.g., image data) of each sub-partition of the dynamic partition (Super) in the upgrade package into the user data partition (Userdata) described in the updated partition table. For example, if the updated partition table includes the start address 3 and the end address 4 of the user data partition (Userdata), the electronic device 130 can write the upgrade data of each sub-partition of the dynamic partition (Super) in the upgrade package into the location between the start address 3 and the end address 4 in the ROM.

[0273] Furthermore, in the Virtual A / B upgrade solution, an incremental upgrade method is used for the dynamic partition (Super). During the upgrade process, the virtual dynamic partition of the user data partition (Userdata) does not store all the files of the upgraded new version of the dynamic partition (Super). Instead, it stores the upgraded data of the old version (such as the intermediate version) of the dynamic partition (Super). In other words, the virtual dynamic partition of the user data partition (Userdata) stores the updated data of the dynamic partition. In the Virtual A / B upgrade solution, the incremental upgrade of the dynamic partition (Super) is achieved based on snapshot technology.

[0274] Taking the "system" subpartition in the dynamic partition (Super) as an example, assume that in version V1.1, the data in the "system" subpartition can be divided into "system1" and "system2." When upgrading from version V1.1 to version V2.0, the data in "system2" remains unchanged, while the data in "system1" is upgraded to "system3." Then, in S1302, the electronic device 130 creates a virtual dynamic partition in the "userdata" partition and writes the data in "system3" to the virtual dynamic partition.

[0275] Furthermore, in the Virtual A / B upgrade solution, incremental upgrades of the dynamic partition (Super) are implemented based on snapshot technology. Specifically, in the virtual dynamic partition of the user data partition (Userdata), a copy-on-write (cow) file is used to save the upgrade data of the dynamic partition (Super).

[0276] Specifically, the upgrade data of the dynamic partition (Super) stored in the user data partition (Userdata) includes multiple cow files, each cow file corresponds to a sub-partition of the dynamic partition (Super), and the name of the cow file corresponds to the sub-partition of the dynamic partition (Super) it targets.

[0277] In the upgrade package, the cow file containing the dynamic partition (Super) upgrade data is compressed and stored in binary format. Each cow file in the upgrade package is named according to the dynamic partition (Super) subpartition it targets. For example, the cow file for the system subpartition is named system-cow-img.img.0000.

[0278] In S1302, the electronic device 130 unpacks the upgrade package to obtain all cow files and attaches an A / B partition mark to each cow file. Specifically, when the electronic device 130 is currently booted from the static partition (B), it can be understood that the dynamic partition (Super) loaded by the operating system currently running on the electronic device 130 is the dynamic partition (B). When upgrading the operating system, the virtual dynamic partition created in the user data partition (Userdata) is for the dynamic partition (A). Therefore, the name mark _a corresponding to the dynamic partition (A) is attached to the cow file. For example, _a is attached to system-cow-img.img.0000 to generate system_a-cow-img.img.0000.

[0279] Furthermore, in S1302, after writing the cow file to the user data partition (Userdata), it is also necessary to perform a comprehensive check on the dynamic partition (Super) + cow file to verify the validity of the dynamic partition (Super) + cow file and verify whether the synthesis result of the intermediate version of the dynamic partition (Super) data + cow file is the target version of the dynamic partition (Super) data.

[0280] Specifically, taking the upgrade from version V1.1 to version V2.0 as an example, calculate the hash value of the synthetic result of the data in the dynamic partition (Super) that does not need to be upgraded (that is, the data that has not changed from version V1.1 to version V2.0) and the upgraded data in the cow file (the data that needs to be upgraded from version V1.1 to version V2.0), and judge whether the hash value is consistent with the hash value of the complete data of the dynamic partition (Super) in version V2.0. If they are consistent, it means that the cow file is valid; if they are inconsistent, it means that the cow file is invalid, the upgrade fails, the upgrade process is interrupted and an error is reported; among them, the hash value of the complete data of the dynamic partition (Super) in version V2.0 is saved in the upgrade package.

[0281] When the cow file is valid, the disk-pending status information in the metadata partition ( / metadata) of the basic partition (Common) is changed from "merged" to "wait for merge". The disk-pending status information is used to indicate whether there is a cow file that needs to be flushed to the dynamic partition (Super). Specifically, the disk-pending status information includes an overall identifier for the dynamic partition (Super) and a sub-partition identifier for each sub-partition. When the overall identifier is "merged", it means that all sub-partitions of the dynamic partition (Super) do not need to be flushed; when the overall identifier is "wait for merge", it means that one or more sub-partitions of the dynamic partition (Super) need to be flushed; when the sub-partition identifier is "merged", it means that the sub-partition does not need to be flushed; when the sub-partition identifier is "wait for merge", it means that the sub-partition needs to be flushed.

[0282] S1303 , the electronic device 130 changes the boot sequence from booting from the static partition (B) to booting from the static partition (A).

[0283] For example, the boot sequence identifier of the MBR is rewritten from B to A. After the electronic device 130 is powered on, when the electronic device 130 reads the boot sequence identifier as A, the electronic device 130 boots from the static partition (A).

[0284] S1304: The electronic device 130 is restarted. That is, the intermediate version of the operating system is exited, the power supply of the electronic device 130 is turned off, and the power supply of the electronic device 130 is turned on again.

[0285] It should be noted that the restart in S1304 here is different from the restart in the partition table adjustment stage (such as the restart in S606 and S610) mentioned above. The restart in S610 is a restart in response to the user's restart operation. The restart in the partition table adjustment stage (such as the restart in S606 and S610) is a restart implemented by software and does not require user operation.

[0286] S1305 , the electronic device 130 sequentially loads the basic partition (Common) and the static partition (A) based on the updated partition table, and boots from the static partition (A).

[0287] Since the boot order is changed to boot from the static partition (A), the static partition (A) will be loaded.

[0288] Exemplarily, the electronic device 130 can obtain the addresses (including the starting address and the ending address) of each sub-partition in the basic partition (Common) and the static partition (A) from the updated partition table, and then read the system data at the location pointed to by the address in the ROM to complete the loading of the basic partition (Common) and the static partition (A).

[0289] S1306 , the electronic device 130 loads the dynamic partition (Super) and the virtual dynamic partition of the user data partition (Userdata) based on the updated partition table.

[0290] Exemplarily, the electronic device 130 can obtain the address (including the start address and the end address) of the dynamic partition (Super) from the updated partition table, and then read the system data at the location pointed to by the address in the ROM. After reading the metadata ( / supermetadata) in the header of the dynamic partition (Super), the offset of the address of each sub-partition of the dynamic partition (Super) in the dynamic partition (Super) can be obtained. Based on the offset of the address of each sub-partition of the dynamic partition (Super) in the dynamic partition (Super), the electronic device 130 can read the system data in each sub-partition of the dynamic partition (Super).

[0291] In addition, the electronic device 130 reads the disk-falling status information in the metadata ( / metadata), determines whether it is necessary to retrieve the cow file from the specified path of the user data partition (Userdata) based on the disk-falling status information, and uses snapshot merging to load the system data and corresponding cow files in each sub-partition in the dynamic partition (Super).

[0292] Furthermore, in S1306, the electronic device 130 does not load all the cow files in the dynamic partition (Super) and the user data partition (Userdata), but instead loads the corresponding files according to the operating system's operating requirements. Specifically, in S1306, the electronic device 130 determines the files to be loaded according to the operating system's operating requirements, and extracts the corresponding files from the cow files in the dynamic partition (Super) or the virtual dynamic partition based on the snapshot for loading.

[0293] Specifically, in S1306, when a corresponding cow file exists for a subpartition of the dynamic partition (Super), a target version file map of each subpartition of the dynamic partition (Super) is generated based on the snapshot. Electronic device 130 determines the files to be loaded based on the operating system's operating requirements and loads the files based on the target version file map of the subpartition of the dynamic partition (Super).

[0294] For example, the operating system needs to load all the data in the directory user ( / system / user) under the system subpartition. The electronic device 130 reads the disk status information in the metadata ( / metadata). The subpartition identifier of the system subpartition in the disk status information is "not yet stored (wait for merge)". Therefore, the electronic device 130 searches for the cow file in the user data partition (Userdata). After searching for the cow file system_a-cow-img.img.0000, based on the snapshot, the file map of the target version of the system subpartition is generated according to the file map of the cow file in system_a-cow-img.img.0000. Data is loaded according to the save address of all files under / system / user in the file map of the target version of the system subpartition.

[0295] Furthermore, in S1306, before loading the file, the electronic device 130 also needs to verify the loaded file. Unlike S1302, in S1306, the dynamic partition (Super) + cow file is not verified as a whole, but only the file that needs to be loaded is verified. For example, verification is performed based on dmverity (dm-verity is a target of dm (device mapper), a virtual block electronic device 130, specifically used for file system verification). If the verification is successful, the file is loaded. If the verification fails, the electronic device 130 is restarted, the system is rolled back, or the file is tried to be loaded again.

[0296] S1307, the electronic device 130 is successfully started and enters the user interaction interface.

[0297] S1308 , the electronic device 130 writes the data of the virtual dynamic partition to the dynamic partition (Super).

[0298] In the description of the present application specification, the disk write operation refers to writing the dynamic partition (Super) upgrade file (cow file) saved in the virtual dynamic partition on the user data partition (Userdata) into the dynamic partition (Super) during the operating system upgrade process, so that the file of the dynamic partition (Super) completes the data upgrade, so that the electronic device 130 does not need to load the dynamic partition (Super) and the virtual dynamic partition when it is started next time, and only the dynamic partition (Super) needs to be loaded to complete the startup of the electronic device 130.

[0299] Specifically, after successfully booting up, the electronic device 130 broadcasts a startup broadcast, which then initiates the upgrade process. The upgrade process reads the disk-merged status information in the metadata ( / metadata) of the base partition (Common). If the disk-merged status information indicates "merged," the electronic device 130 enters normal operation mode.

[0300] If the flush status information is "Not flushed (wait for merge)", the upgrade process flushes the cow files in the user data partition (Userdata) to the dynamic partition (Super).

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

[0302] After this, the upgrade process deletes the cow file in the user data partition (Userdata) and returns the storage space to the user data partition (Userdata); and changes the flush status information in the metadata ( / metadata) of the base partition (Common) from "Not flushed to disk (waiting for merge)" to "Flushed to disk (merged)".

[0303] S1309 , the electronic device 130 synchronizes the data in the static partition (A) to the static partition (B).

[0304] In some embodiments, after completing the write to disk, electronic device 130 can also synchronize the data stored in each sub-partition of static partition (A) with the corresponding sub-partition of static partition (B), so that static partition (B) also stores data of the target version. Then, when booting from static partition (B), the latest operating system, i.e., the target version, can also be run.

[0305] In S1301, the data operation of the static partition upgrade is for the static partition (A), which does not affect the operating system data of the currently started static partition (B); and, in S1302, the data operation of the dynamic partition upgrade is completed on the virtual dynamic partition created in the user data partition (Userdata), which does not affect the currently mounted dynamic partition (Super). Therefore, during the entire operating system upgrade process, the user can use the electronic device 130 normally. Moreover, after S1303 is completed, the electronic device 130 does not need to be restarted immediately, and the user can choose the restart time. In this way, the operating system upgrade process will not affect the user's normal mobile phone operation, thereby greatly improving the user experience. Furthermore, for the dynamic partition (Super), a virtual dynamic partition will only be created on the user data partition (Userdata) when an upgrade is required, thereby effectively improving the data storage space utilization.

[0306] To facilitate understanding of the above-mentioned Virtual A / B upgrade solution, the Virtual A / B upgrade solution is further simplified below with reference to the example of Figure 14. As shown in Figure 14, when the electronic device 130 is running the B system of version V1.1 (as shown in state 1401 in Figure 14), it obtains the upgrade package of version V2.0 from the OTA server 120 (see the description of S613 above). After obtaining the upgrade package, the electronic device 130 can perform the steps of "installation" and "verification" (see the description of S1301 and S1302 above). In addition, the electronic device 130 can "switch system restart" (see the description of S1303 and S1304 above), so that it can start from the static partition (A) and run in the A system of version V2.0 (as shown in state 1402 in Figure 14). It should be noted that at this time, since the disk is not completed, the A system of version V2.0 shown in state 1402 in Figure 14 needs to be implemented by loading the virtual dynamic partition and the dynamic partition (Super) at the same time. Afterwards, the electronic device 130 can execute the "drop to disk" step (see the description of S1308 above) to drop the cow file to the dynamic partition (Super). In addition, the electronic device 130 can further perform "static partition synchronization" so that the target version of the operating system can be run when started from the static partition (A) or the static partition (B). Afterwards, the electronic device 130 can realize the A system running on version V2.0 (as shown in state 1403 in Figure 14) without loading the virtual dynamic partition and the dynamic partition (Super) at the same time. After completing the above-mentioned Virtual A / B upgrade, the electronic device 130 can also feedback the upgrade results to the OTA server 120, so that the OAT server 120 can clearly understand the version of the operating system currently running in the electronic device 130, which is convenient for the management of the operating system of the electronic device 130.

[0307] In the embodiments of Figures 6 and 7 above, the specific process of adjusting the partition table is mainly described with the electronic device 130 as the main body (such as the steps of adjusting the partition table corresponding to S603-S610 above). Further, referring to Figure 15, with the ouc apk (i.e., online update client tool), update engine (i.e., upgrade engine), and recovery process (i.e., recovery process) in the electronic device 130 as the execution body, and still taking the electronic device 130 currently booting from the static partition (A) as an example, the specific process of adjusting the partition table includes:

[0308] S1501, ouc apk download upgrade package. Please refer to the description of S603 above.

[0309] S1502. ouc apk sends the patch package to the update engine.

[0310] S1503: Update engine verifies the patch package. Please refer to the description of S701 above.

[0311] S1504: The update engine updates the version number based on the patch package. Please refer to the description of S604 above.

[0312] S1505: The update engine changes the boot order from static partition (A) to static partition (B). Please refer to the description of S605 above.

[0313] S1506: The update engine determines that the patch package is used to adjust the partition table. Please refer to the description of S702a above.

[0314] S1507: The update engine parses the table adjustment package in the patch package to obtain the partition table of the table adjustment package.

[0315] S1508: The update engine compares the partition table in the table adjustment package with the partition table of the current version. Please refer to the description of S702a above.

[0316] S1509: If the partition table in the table adjustment package is different from the partition table of the current version, the update engine stores the table adjustment package in a preset directory.

[0317] The default directory is a directory accessible to the Recovery process. For example, the default directory is a directory under the cache subpartition of the base partition (common), such as / cache / recovery. Decompressing the table adjustment package and storing it in the default directory facilitates access to the table adjustment package after entering recovery mode, allowing the Recovery process to perform the corresponding partition table adjustment processing.

[0318] S1510: The update engine writes a table adjustment package acquisition instruction, which is used to instruct the recovery process to obtain the table adjustment package from a preset directory.

[0319] The table adjustment package acquisition instruction (also called preset instruction) includes a preset directory and the name of the table adjustment package (ie, preset name). Exemplarily, the format of the table adjustment package acquisition instruction is: update package = preset directory / name of the table adjustment package.

[0320] Assuming the default directory is / cache / recovery and the name of the table adjustment package is update_base_ptable_change.zip, the table adjustment package acquisition instruction may be update package = / cache / recovery / update_base_ptable_change.zip, which indicates reading the table adjustment package named update_base_ptable_change.zip from the / cache / recovery directory.

[0321] In a specific implementation, the command for obtaining the table adjustment package can be written into a command file in a preset directory. For example, the command for obtaining the table adjustment package can be stored in / cache / recovery / command, so that the recovery process can access it easily.

[0322] S1511: The update engine triggers a restart and enters recovery mode. Please refer to the description of S606 above.

[0323] S1512: The recovery process obtains the table adjustment package from the preset directory based on the table adjustment package obtaining instruction.

[0324] For example, after the recovery process is started, the recovery process can read the command file from the preset directory, thereby reading the table adjustment package to obtain the instruction.

[0325] The recovery process can go to the preset directory indicated by the meter adjustment package acquisition instruction and obtain the meter adjustment package indicated by the meter adjustment package acquisition instruction.

[0326] S1513: The recovery process verifies the table adjustment package. Please refer to the description of S606 above.

[0327] It should be noted that although S1512 and S1513 illustrate the use of a partition table adjustment package, in practice, the recovery process may also read instructions for obtaining other update packages (such as a re-creation package), resulting in obtaining other update packages instead of the partition table adjustment package. Therefore, the recovery process needs to execute S1514 below to determine whether the scenario involves adjusting the partition table.

[0328] S1514: The recovery process determines whether the current scenario is to adjust the partition table. Please refer to the description of S704 above.

[0329] For example, if the name of the table adjustment package (ie, the preset name) is read from the table adjustment package acquisition instruction in S1512, it can be determined that the current scenario is to adjust the partition table.

[0330] S1515: If it is determined that the current scenario is to adjust the partition table, the recovery process sets a preset global variable for indicating adjustment of the partition table.

[0331] The recovery process sets a preset global variable, such as ptable-change, to indicate the partition table adjustment scenario. This clearly indicates the current partition table adjustment scenario. Subsequent code execution can be based on this preset global variable to perform operations corresponding to the partition table adjustment scenario, eliminating the need to re-evaluate the scenario before each operation.

[0332] S1516: The recovery process detects the global variable used to instruct table adjustment and migrates the system data in the basic partition (Common), static partition (A), static partition (B), and dynamic partition (Super). Please refer to the description of S607 above.

[0333] Exemplarily, the recovery process migrates system data in the basic partition (Common), static partition (A), static partition (B), and dynamic partition (Super) to the end of the user data partition (Userdata).

[0334] S1517: The recovery process uses the partition table in the table adjustment package to update the current version of the partition table in the electronic device 130 to obtain an updated partition table. Please refer to the description of S608 above.

[0335] S1518: The recovery process migrates the system data back to the partitions described in the updated partition table. Please refer to the description of S609 above.

[0336] S1519: The recovery process deletes the migrated system data. Please refer to the description of S705 above.

[0337] S1520: The recovery process triggers a restart.

[0338] It should be understood that this restart is a normal restart. After restarting, the system will enter the operating system mode, such as Android mode, but will not enter the recovery mode.

[0339] Finally, it should be noted that the preceding text primarily uses the virtual A / B data storage structure as an example to illustrate the specific implementation of adjusting the partition table based on a patch package. Of course, in other embodiments, a non-virtual A / B data storage structure memory (such as ROM) can also adopt the solution provided in the present application to adjust the partition table based on a patch package to achieve partition deployment adjustment. This embodiment of the present application does not specifically limit this.

[0340] For example, see Figure 16, which can be applied to data storage structure (a). In data storage structure (a), there is only one set of static partitions and dynamic partitions (Super), and the electronic device 130 can only run in an operating system composed of data in the basic partition, static partition, and dynamic partition (Super). In this example, the electronic device 130 records the current version of the partition table, which is used to describe a partition deployment of the basic partition, static partition, and dynamic partition (Super). The electronic device 130 can obtain a patch package for adjusting the partition table, which includes a partition table for describing another partition deployment of the basic partition, static partition, and dynamic partition (Super). Then, the electronic device 130 restarts and enters recovery mode, and in recovery mode, migrates the data of the basic partition, static partition, and dynamic partition (Super), such as migrating to the user data partition (Userdata), and updates the partition deployment of the memory from the partition deployment described by the current version of the partition table to the partition deployment described by the partition table in the patch package, and finally migrates the migrated data back to the partitions corresponding to the partition deployment described by the partition table in the patch package. Thereby, the partition table adjustment for data storage structure (a) is realized.

[0341] As another example, referring to Figure 16, it can also be applied to data storage structure (b). In data storage structure (b), there are two sets of static partitions and dynamic partitions (Super). The electronic device 130 can run in an operating system (such as operating system (A)) composed of data in the basic partition, static partition (A) and dynamic partition (Super) (A) (also referred to as the first dynamic partition), or it can run in an operating system (such as operating system (B)) composed of data in the basic partition, static partition (B) and dynamic partition (Super) (B) (also referred to as the second dynamic partition). In this example, the electronic device 130 records the current version of the partition table, which is used to describe a partition deployment of the basic partition, static partition (A), static partition (B), dynamic partition (Super) (A) and dynamic partition (Super) (B). The electronic device 130 can obtain a patch package for adjusting the partition table, which includes a partition table for describing another partition deployment of the basic partition, static partition (A), static partition (B), dynamic partition (Super) (A) and dynamic partition (Super) (B). Then, the electronic device 130 restarts and enters the recovery mode. In the recovery mode, the data of the basic partition, static partition (A), static partition (B), dynamic partition (Super) (A) and dynamic partition (Super) (B) are migrated out, such as to the user data partition (Userdata), and the partition deployment of the memory is updated from the partition deployment described by the partition table of the current version to the partition deployment described by the partition table in the patch package. Finally, the migrated data is migrated back to each partition corresponding to the partition deployment described by the partition table in the patch package. In this way, the partition table adjustment for the data storage structure (b) is achieved.

[0342] An embodiment of the present application further provides an electronic device, which may include a memory and one or more processors. The memory and processor are coupled. The memory is used to store computer program code, which includes computer instructions. When the processor executes the computer instructions, the electronic device performs each step of the above embodiment. Of course, the electronic device includes but is not limited to the above memory and one or more processors.

[0343] The embodiment of the present application also provides a chip system, which can be applied to the electronic devices in the aforementioned embodiments. As shown in Figure 17, the chip system includes at least one processor 1701 and at least one interface circuit 1702. The processor 1701 can be the processor in the above-mentioned electronic device. The processor 1701 and the interface circuit 1702 can be interconnected via a line. The processor 1701 can receive and execute computer instructions from the memory of the above-mentioned electronic device through the interface circuit 1702. When the computer instructions are executed by the processor 1701, the electronic device can execute the various steps in the above-mentioned embodiments. Of course, the chip system can also include other discrete devices, which is not specifically limited in the embodiment of the present application.

[0344] In some embodiments, through the description of the above embodiments, those skilled in the art can clearly understand that for the convenience and brevity of description, only the division of the above functional modules is used as an example. In actual applications, the above functions can be assigned to different functional modules as needed, that is, the internal structure of the device can be divided into different functional modules to complete all or part of the functions described above. The specific working process of the system, device and unit described above can refer to the corresponding process in the aforementioned method embodiment and will not be repeated here.

[0345] The functional units in the various embodiments of the present application may be integrated into a single processing unit, or each unit may exist physically separately, or two or more units may be integrated into a single unit. The aforementioned integrated units may be implemented in the form of hardware or software functional units.

[0346] If the integrated unit is implemented in the form of a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the embodiment of the present application is essentially or the part that contributes to the prior art or all or part of the technical solution can be embodied in the form of a software product, and the computer software product is stored in a storage medium, including a number of instructions for enabling a computer device (which can be a personal computer, a server, or a network device, etc.) or a processor to perform all or part of the steps of the method described in each embodiment of the present application. The aforementioned storage medium includes: various media that can store program codes, such as flash memory, mobile hard disk, read-only memory, random access memory, magnetic disk or optical disk.

[0347] The above description is merely a specific embodiment of the present invention, but the scope of protection of the present invention is not limited thereto. Any changes or substitutions within the technical scope disclosed in the present invention should be included in the scope of protection of the present invention. Therefore, the scope of protection of the present invention should be based on the scope of protection of the claims.

Claims

1. A method for upgrading an operating system, characterized in that: Applied to an electronic device, the electronic device includes a memory, the memory includes a basic partition, a first static partition, a second static partition, and a dynamic partition, the electronic device includes a first partition table, the first partition table is used to describe a partition deployment of the basic partition, the first static partition, the second static partition, and the dynamic partition, the method comprising: The electronic device obtains a patch package, where the patch package includes a second partition table, where the second partition table is used to describe another partition deployment of the basic partition, the first static partition, the second static partition, and the dynamic partition; After obtaining the patch package, the electronic device restarts for the first time and enters recovery mode; In the recovery mode, the electronic device migrates data from the basic partition, the first static partition, the second static partition, and the dynamic partition, updates the partition layout of the memory from the partition layout described by the first partition table to the partition layout described by the second partition table, and migrates the migrated data back to the corresponding partitions in the partition layout described by the second partition table; The electronic device is restarted for the second time.

2. The method according to claim 1, characterized in that After the electronic device is restarted for the second time, the method further includes: The electronic device obtains an upgrade package of the operating system of the electronic device, writes upgrade data in the upgrade package into each partition corresponding to the partition deployment described in the second partition table, and completes the operating system upgrade.

3. The method according to claim 1 or 2, characterized in that The first partition table includes partition information of the basic partition, the first static partition, and multiple sub-partitions in the second static partition in the first version of the operating system, as well as partition information of the dynamic partition; The second partition table includes partition information of the basic partition, the first static partition, and multiple sub-partitions in the second static partition, as well as partition information of the dynamic partition in the second version of the operating system; The partition information includes partition size, partition name, start address and end address.

4. The method according to claim 3, characterized in that The electronic device restarts for the first time and enters recovery mode, including: If the first partition table is different from the second partition table, the electronic device restarts for the first time and enters the recovery mode.

5. The method according to claim 4, characterized in that The first partition table is different from the second partition table and includes at least one of the following: The second partition table includes partition information of the first partition, and the first partition table does not include partition information of the first partition; The first partition table includes partition information of the second partition, and the second partition table does not include partition information of the second partition; The first partition table includes partition information of a third partition, the second partition table includes partition information of a fourth partition, the partition name of the third partition and the partition name of the fourth partition are different, but the third partition and the fourth partition are used to store the same data; as well as, The first partition table and the second partition table both include partition information of the fifth partition, but the first partition information of the fifth partition in the first partition table is different from the first partition information of the fifth partition in the second partition table. The partition information is different, and the first partition information does not include a partition name; Among them, the first partition, the second partition, the third partition, the fourth partition, and the fifth partition are sub-partitions of the basic partition, the first static partition, and the second static partition, or the first partition, the second partition, the third partition, the fourth partition, and the fifth partition are the dynamic partitions.

6. The method according to claim 5, characterized in that The step of migrating the migrated data back to the corresponding partitions in the partition deployment described in the second partition table includes: The electronic device migrates the data migrated from the sixth partition back to the first target address range in the memory; In which, the sixth partition is a partition in the second partition table other than the first partition, the second partition and the fourth partition, the sixth partition is a sub-partition among the basic partition, the first static partition and the second static partition, or the sixth partition is the dynamic partition, and the first target address interval is the interval between the start address and the end address of the sixth partition in the second partition table.

7. The method according to claim 5 or 6, characterized in that The step of migrating the migrated data back to the corresponding partitions in the partition deployment described in the second partition table includes: The electronic device clears the data in the second target address interval in the memory; The second target address interval is an interval between the start address and the end address of the first partition in the second partition table.

8. The method according to claim 7, characterized in that The patch package includes first indication information, where the first indication information is used to indicate that, compared with the first partition table, the first partition is newly added to the second partition table; Before the electronic device clears the data in the second target address range in the memory, the method further includes: The electronic device reads the first indication information, and queries the start address and the end address of the first partition from the second partition table based on the first indication information.

9. The method according to any one of claims 5 to 8, characterized in that The step of migrating the migrated data back to the corresponding partitions in the partition deployment described in the second partition table includes: The electronic device does not relocate the data migrated from the second partition.

10. The method according to claim 9, characterized in that The patch package includes second indication information, where the second indication information is used to indicate that, compared with the first partition table, the second partition is deleted in the second partition table; The method further comprises: The electronic device reads the second indication information, and determines the data to be migrated from the second partition based on the second indication information.

11. The method according to any one of claims 5 to 10, characterized in that The step of migrating the migrated data back to the corresponding partitions in the partition deployment described in the second partition table includes: The electronic device migrates the data migrated from the third partition back to the third target address range of the memory; The third target address interval is the starting address and ending address of the fourth partition in the second partition table. The interval between the bundle addresses.

12. The method according to claim 11, characterized in that The patch package includes third indication information, where the third indication information is used to indicate that: the third partition in the first partition table is updated to the fourth partition in the second partition table; Before the electronic device migrates the data from the third partition back to the third target address range of the memory, the method includes: The electronic device reads the third indication information, and queries the start address and the end address of the fourth partition from the second partition table based on the third indication information.

13. The method according to any one of claims 1 to 12, characterized in that After obtaining the patch package, the electronic device is first restarted, including: After obtaining the patch package, if the patch package includes a data packet with a preset name, or the patch package includes a first tag, the electronic device restarts for the first time; The data packet with the preset name is used to adjust the partition deployment, and the first tag is used to indicate the adjustment of the partition deployment.

14. The method according to any one of claims 1 to 13, characterized in that Migrating data from the basic partition, the first static partition, the second static partition, and the dynamic partition includes: If the patch package includes a data packet with a preset name, migrating data from the basic partition, the first static partition, the second static partition, and the dynamic partition; The data packet with the preset name is used to adjust the partition deployment.

15. The method according to claim 14, characterized in that The method further comprises: In the case where the patch package includes the data packet with the preset name, the electronic device stores the data packet with the preset name in a preset directory of the electronic device, and writes a preset instruction in the electronic device, wherein the preset instruction includes the preset name; After obtaining the patch package and restarting the electronic device for the first time, the method further includes: The electronic device reads the preset instruction; If the patch package includes a data packet with a preset name, migrating data from the basic partition, the first static partition, the second static partition, and the dynamic partition includes: If the preset instruction includes the preset name, the electronic device migrates data of the basic partition, the first static partition, the second static partition, and the dynamic partition.

16. The method according to claim 14 or 15, characterized in that If the patch package includes a data packet with a preset name, migrating data from the basic partition, the first static partition, the second static partition, and the dynamic partition includes: The patch package includes a data packet with the preset name, and the electronic device sets a preset global variable for indicating adjustment of partition deployment; The electronic device detects the preset global variable and migrates data from the basic partition, the first static partition, the second static partition, and the dynamic partition.

17. The method according to claim 15 or 16, characterized in that The preset instruction includes a preset directory, and the second partition table is stored in a data packet with the preset name; In the step of updating the partitioning arrangement of the memory from the partitioning arrangement described by the first partition table to the partitioning arrangement described by the first partition table Before the partitions described by the second partition table are deployed, the method further includes: The electronic device obtains the data packet with the preset name from the preset directory according to the preset instruction, and obtains the second partition table from the data packet with the preset name.

18. The method according to any one of claims 1 to 17, characterized in that The memory further includes a user data partition, and migrating the data in the basic partition, the first static partition, the second static partition, and the dynamic partition includes: The electronic device migrates data in the basic partition, the first static partition, the second static partition, and the dynamic partition to the user data partition; The step of migrating the migrated data back to the corresponding partitions in the partition deployment described in the second partition table includes: The data of the basic partition, the first static partition, the second static partition, and the dynamic partition in the user data partition are migrated back to the corresponding partitions in the partition deployment described by the second partition table.

19. The method according to any one of claims 1 to 18, characterized in that After migrating the migrated data back to the corresponding partitions in the partition deployment described in the second partition table, the method further includes: Delete the migrated data.

20. The method according to any one of claims 2 to 19, characterized in that The patch package includes a first version number; The electronic device obtains the patch package, including: When the electronic device loads the basic partition, the first static partition, and the dynamic partition and runs the electronic device, the electronic device obtains the patch package; After the electronic device obtains the patch package, the method further includes: The electronic device updates the version number in the second static partition to the first version number; The electronic device sets the startup sequence of the electronic device to start from the second static partition; After the electronic device is restarted for the second time, the method further includes: The electronic device loads the basic partition, the second static partition, and the dynamic partition, and runs the electronic device; The electronic device reads the first version number from the second static partition; The electronic device obtaining an upgrade package of an operating system of the electronic device includes: The electronic device obtains an upgrade package of the operating system of the electronic device based on the first version number.

21. An electronic device, characterized in that: The electronic device includes a processor and a memory, the memory includes a basic partition, a first static partition, a second static partition, a dynamic partition and a user data partition, the electronic device also includes a first partition table, the first partition table is used to describe a partition deployment of the basic partition, the first static partition, the second static partition and the dynamic partition, the processor is used to execute the software code stored on the memory so that the electronic device performs the method described in any one of claims 1-20.

22. A computer-readable storage medium, characterized in that The computer-readable storage medium stores a computer program, which, when executed on an electronic device, enables the electronic device to execute the method according to any one of claims 1 to 20.

23. A chip system, characterized in that: The chip system is applied to an electronic device including a processor and a memory. The chip system includes one or more interface circuits and one or more processors. The interface circuit and the processor are interconnected through lines. The interface circuit is used to receive a signal from the memory of the electronic device and send the signal to the processor. The signal includes a computer instruction stored in the memory. When the processor executes the computer instruction, the electronic device executes the method as described in any one of claims 1 to 20.

Images