Operating system data updating method, device and storage medium
Patent Information
- Application Number
- CN202211524404.1
- Authority / Receiving Office
- CN · China
- Patent Type
- Patents(China)
- Current Assignee / Owner
- Filing Date
- 2021-06-15
- Publication Date
- 2026-08-28
- Estimated Expiration
- 2041-06-15
AI Technical Summary
[0005]有鉴于此，本申请提供一种操作系统数据更新方法、设备及存储介质，以利于解决现有技术中操作系统数据存在更新需求的问题
Smart Images
Figure CN116069375B_ABST
Abstract
Description
Technical Field
[0001] This application relates to the field of computer technology, and more specifically to an operating system data update method, device, and storage medium. Background Technology
[0002] In existing technology applications, user terminals need to have an operating system installed before they can be used by users. For example, mobile phones need to have a mobile operating system (such as iOS or Android) installed before they can be used by users.
[0003] In existing technology applications, after an operating system is released, it is sometimes necessary to update the system data within that operating system. For example, after release, the application environment of the operating system may change, requiring corresponding updates to certain parameters. Another example is that during the writing of the operating system code, due to human error or insufficient consideration by the programmer, vulnerabilities (bugs) may exist in the operating system data. Generally, when an operating system is first released, the vendor is unaware of the bugs. At this point, a buggy operating system will be installed on user terminals. As operating system runtime data and testing data accumulate, the vendor will detect the bugs. At this point, it is necessary to fix the system bugs on user terminals that previously had the buggy operating system installed.
[0004] Therefore, a method for updating operating system data is needed to update operating system data when there is a need to update operating system data. Summary of the Invention
[0005] In view of this, this application provides an operating system data update method, device, and storage medium to help solve the problem of operating system data update needs in the prior art.
[0006] In a first aspect, embodiments of this application provide an operating system data update method applied to an electronic device. The electronic device includes a processor and a memory. The memory includes a basic partition, a first static partition, a second static partition, a dynamic partition, and a user data partition. After the electronic device starts, it loads data from the basic partition, the first static partition, and the dynamic partition to run a first operating system. After the first operating system runs, the method includes:
[0007] Obtain a patch package, which includes an update location description and update data. The update location description is used to specify the update target in the static partition that needs to be updated, and the update data is used to describe the data update result of the static partition.
[0008] Update the data in the second static partition according to the update location description and update data in the patch package;
[0009] The boot order of the electronic device is changed from booting from the first static partition to booting from the second static partition;
[0010] Restart the electronic device and confirm that the current boot order is to boot from the second static partition;
[0011] Load the data from the base partition, the second static partition, and the dynamic partition to run the first operating system after the static partition data has been updated;
[0012] Before updating the data in the second static partition according to the update location description and update data in the patch package, the method further includes synchronizing the data in the first static partition to the second static partition.
[0013] In one implementation of the first aspect, synchronizing the data of the first static partition to the second static partition includes:
[0014] Read the data from each sub-partition of the first static partition;
[0015] The data in each sub-partition of the first static partition is overwritten into the corresponding sub-partition of the second static partition.
[0016] In one implementation of the first aspect, synchronizing the data of the first static partition to the second static partition includes:
[0017] Calculate the hash value of the data in the third sub-partition, wherein the third sub-partition is a sub-partition of the first static partition;
[0018] Calculate the hash value of the data in the fourth sub-partition, wherein the fourth sub-partition is a sub-partition of the second static partition, and the fourth sub-partition corresponds to the third sub-partition;
[0019] When the hash value of the data in the third sub-partition is inconsistent with the hash value of the data in the fourth sub-partition, the data in the third sub-partition is overwritten into the fourth sub-partition.
[0020] In one implementation of the first aspect, after obtaining the patch package, the step of synchronizing the data of the first static partition to the second static partition is performed.
[0021] In one implementation of the first aspect, before obtaining the patch package, the method further includes:
[0022] Load the data from the base partition, the second static partition, and the dynamic partition to run the second operating system;
[0023] Obtain the upgrade installation package, which includes static partition upgrade files;
[0024] Upgrade the data in the first static partition based on the static partition upgrade file;
[0025] The boot order of the electronic device is changed from booting from the second static partition to booting from the first static partition;
[0026] Restart the electronic device and confirm that the current boot order is to boot from the first static partition;
[0027] Load the data from the base partition, the first static partition, and the dynamic partition to run the first operating system;
[0028] Specifically, after restarting the electronic device and confirming that the current boot order is to boot from the first static partition, the process of synchronizing the data of the first static partition to the second static partition is executed.
[0029] In one implementation of the first aspect, during the process of loading the data of the first static partition, after the static partition data is successfully verified, the step of synchronizing the data of the first static partition to the second static partition is performed.
[0030] In one implementation of the first aspect, during the process of loading the data of the dynamic partition, after the dynamic partition file to be loaded is successfully verified, the process of synchronizing the data of the first static partition to the second static partition is executed.
[0031] In one implementation of the first aspect, the upgrade installation package further includes dynamic partition upgrade data;
[0032] The method of restarting the electronic device and confirming that the current boot order is before booting from the first static partition further includes creating a virtual dynamic partition in the user data partition and storing the dynamic partition upgrade data in the virtual dynamic partition.
[0033] The step of loading data from the base partition, the first static partition, and the dynamic partition to run the first operating system includes loading data from the dynamic partition and upgrade data from the dynamic partition.
[0034] After loading the data of the base partition, the first static partition, and the dynamic partition to run the first operating system, the method further includes writing the dynamic partition upgrade data to the dynamic partition.
[0035] After the dynamic partition upgrade data is written to the dynamic partition, the data of the first static partition is synchronized to the second static partition.
[0036] In one implementation of the first aspect, updating the data in the second static partition according to the update location description and update data in the patch package includes:
[0037] Add a correction for the second static partition path to the updated location description.
[0038] In one implementation of the first aspect, the update location description points to a first path of a first file, the update data is a second file, the second file is a file with the same name as the first file, and the second file is an updated version of the first file. Updating the data in the second static partition according to the update location description and update data in the patch package includes:
[0039] Add the directory name suffix corresponding to the second static partition to the first path to generate the second path;
[0040] The first file in the second static partition is located according to the second path;
[0041] Delete the first file in the second static partition;
[0042] Write the second file to the second path.
[0043] In one implementation of the first aspect, the update location description is a third path, the update data is a third file, and updating the data in the second static partition according to the update location description and update data in the patch package includes:
[0044] Add the directory name suffix corresponding to the second static partition to the third path to generate the fourth path;
[0045] Write the third file to the fourth path.
[0046] In one implementation of the first aspect, the update location description is a fifth path pointing to a first code segment of a fourth file, the update data is a second code segment, and the step of updating the data in the second static partition according to the update location description and update data in the patch package includes:
[0047] Add the directory name suffix corresponding to the second static partition to the fifth path to generate the sixth path;
[0048] The fourth file in the second static partition is located according to the sixth path;
[0049] Open the fourth file and locate the first code segment;
[0050] Use the second code segment to override the first code segment.
[0051] Secondly, this application also provides an electronic device, the electronic device including a processor and a memory, the memory including a basic partition, a first static partition, a second static partition, a dynamic partition and a user data partition, the processor being configured to execute software code stored in the memory, such that:
[0052] After the electronic device starts up, it loads the data from the base partition, the first static partition, and the dynamic partition to run the first operating system.
[0053] And after the first operating system is running, the process described in the first aspect is executed.
[0054] Thirdly, this application also provides a computer-readable storage medium storing a computer program that, when run on a computer, causes the computer to perform the method described in the first aspect.
[0055] Fourthly, this application also provides a computer program product comprising a computer program that, when run on a computer, causes the computer to perform the method described in the first aspect.
[0056] The technical solutions proposed in the embodiments of this application can achieve at least the following technical effects:
[0057] According to the method in the embodiments of this application, data in static partitions can be patched and corrected without upgrading the entire operating system, which greatly reduces the difficulty of operating system repair, improves the efficiency of operating system repair, and improves the stability of operating system operation. Attached Figure Description
[0058] To more clearly illustrate the technical solutions of the embodiments of this application, the drawings used in the embodiments will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.
[0059] Figure 1 The diagram shows the data storage structure of an Android system using the virtual A / B upgrade method on a terminal device.
[0060] Figure 2 The diagram shown is a flowchart of an operating system data update according to an embodiment of this application;
[0061] Figure 3a The diagram shown is a flowchart of an operating system data update according to an embodiment of this application;
[0062] Figure 3b The diagram shown is a flowchart of an operating system data update according to an embodiment of this application;
[0063] Figure 3c The diagram shown is a flowchart of an operating system data update according to an embodiment of this application;
[0064] Figure 4 The diagram shown is a flowchart of an operating system upgrade according to an embodiment of this application;
[0065] Figure 5 The diagram shown is a flowchart of an operating system data update according to an embodiment of this application;
[0066] Figure 6 The diagram shown is a static partition synchronization flowchart according to an embodiment of this application;
[0067] Figure 7 The diagram shown is a static partition synchronization flowchart according to an embodiment of this application;
[0068] Figure 8 The diagram shown is a static partition synchronization flowchart according to an embodiment of this application;
[0069] Figure 9 The diagram shown is a flowchart of an operating system upgrade according to an embodiment of this application;
[0070] Figure 10 The diagram shown is a flowchart of an operating system upgrade according to an embodiment of this application. Detailed Implementation
[0071] To better understand the technical solution of this application, the embodiments of this application will be described in detail below with reference to the accompanying drawings.
[0072] It should be understood that the described embodiments are merely some, not all, of the embodiments in this application. All other embodiments obtained by those skilled in the art based on the embodiments in this application without inventive effort are within the scope of protection of this application.
[0073] The terminology used in the embodiments of this application is for the purpose of describing particular embodiments only and is not intended to be limiting of this application. The singular forms “a,” “the,” and “the” used in the embodiments of this application and the appended claims are also intended to include the plural forms unless the context clearly indicates otherwise.
[0074] It should be understood that the term "and / or" used in this article is merely a description of the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A existing alone, A and B existing simultaneously, or B existing alone. Additionally, the character " / " in this article generally indicates that the preceding and following related objects have an "or" relationship.
[0075] When an operating system requires data updates, a viable solution is to release a new version. User devices periodically send packet search requests to a packet search server, containing the version number of the device's currently running operating system (e.g., version 1.1, which contains bugs). The packet search server, based on the operating system version number in the request, searches for an existing operating system installation package with an updated version (e.g., version 1.2, which has fixed bugs). When an updated version is available, the packet search server provides the device with a download link for the operating system upgrade package (e.g., an upgrade package from version 1.1 to version 1.2). The device downloads the operating system upgrade package from the provided link. After the upgrade package is downloaded, the operating system is upgraded.
[0076] While the above solutions can update the operating system data on the user's device, the amount of data required to download the operating system installation package is relatively large, and the system resources and operation time consumed by the operating system upgrade will greatly affect the user's normal use of the device.
[0077] For situations where the operating system requires data updates, another feasible solution is to release patch files specifically for updating data. Patch files only update designated operating system data. For example, if an incorrect value for parameter A causes a bug in the operating system, the patch file contains the location information for parameter A and its correct value. According to the patch file, only the value of parameter A is updated, without upgrading the entire operating system. Since the patch file is much smaller than the operating system upgrade package, it significantly reduces user bandwidth consumption. Furthermore, the system resources and time consumed by updating only specified data are far less than those consumed by upgrading the entire operating system. Therefore, the impact of operating system data updates on normal user device use can be effectively reduced.
[0078] However, while using patch files to update only specific data can effectively control download bandwidth consumption, system resource usage, and repair time, under normal circumstances, device startup loads operating system data. During operating system operation, this loaded data is read-only. For example, when the device is running the operating system normally, the operating system's static partition is read-only. If the data to be updated exists in the static partition, then it is impossible to update the operating system data in the static partition while the device is running the operating system.
[0079] To address the aforementioned issues, this application proposes a method for updating operating system data. Based on a static A / B partition configuration, the data in the static partition is updated during normal device operation.
[0080] Specifically, Figure 1 The diagram shows the data storage structure of an Android system using the virtual A / B upgrade method on a terminal device. Figure 1 As shown, the Android system data storage area includes the basic partition (Common), static partition (A), static partition (B), dynamic partition (Super), and user data partition (Userdata).
[0081] The Userdata partition stores users' personal data, such as apps they've installed, photos, documents, and videos. The base partition stores system data that doesn't participate in operating system upgrades. Static partitions (A) and (B) correspond in structure, with subpartitions distinguished by the suffixes _a and _b. Static partition (A) includes bootloader_a, boot_a, vendor_boot_a, dtbo_a, and vbmeta_a; static partition (B) includes bootloader_b, boot_b, vendor_boot_b, dtbo_b, and vbmeta_b. The Super partition contains multiple subpartitions.
[0082] When the device boots, it starts from a static partition. For example, if the device boots from static partition (A): the basic partition (Common), static partition (A), and dynamic partition (Super) are loaded in sequence; if the device boots from static partition (B): the basic partition (Common), static partition (B), and dynamic partition (Super) are loaded in sequence.
[0083] exist Figure 1In the system storage structure shown, the partition structure of static partition (A) and static partition (B) is consistent. When the data burned into static partition (A) and static partition (B) is consistent (for example, in some application scenarios, after the system is installed before the device leaves the factory, the data burned into static partition (A) and static partition (B) is consistent), static partition (A) and static partition (B) can be substituted for each other.
[0084] Figure 2 The illustration shows an embodiment of this application. Figure 1 The flowchart illustrates the operating system data update process within the system storage structure shown. The device boots from static partition (A), and the data in static partition (A) is consistent with that in static partition (B). The device follows the steps described above. Figure 2 The process shown updates the data in the static partition of the operating system.
[0085] S200: The device loads the basic partition (Common), static partition (A), and dynamic partition (Super) in sequence, and boots from the static partition (A);
[0086] S210, the device obtains the operating system patch package;
[0087] For example, in one feasible implementation, the device periodically sends packet search requests to the packet search server. The packet search request contains the version number of the operating system currently running on the device (e.g., version 1.1). The packet search server searches for the existence of an operating system patch package for that version number based on the operating system version number in the packet search request. When an operating system patch package for that version number exists, the packet search server provides the device with the download address of the operating system patch package. The device downloads the operating system patch package according to the download address and saves the operating system patch package to the user data partition.
[0088] S220, the device reads the operating system patch package from the user data partition (Userdata) and updates the static partition (B) according to the operating system patch package.
[0089] S230, change the device's boot order from booting from static partition (A) to booting from static partition (B). For example, rewrite the boot order identifier of the Master Boot Record (MBR) from A to B. After the device is powered on, if the device reads the boot order identifier as A, it boots from static partition (A) and loads static partition (A) during the boot process; if the device reads the boot order identifier as B, it boots from static partition (B) and loads static partition (B) during the boot process.
[0090] S240, the device restarts. Exit the current operating system, disconnect the device power, and then turn the device power back on.
[0091] After S230, the device does not need to be restarted immediately; the user can choose when to restart it.
[0092] The S250 loads the basic partition (Common), static partition (B), and dynamic partition (Super) in sequence, and boots from the static partition (B).
[0093] S260, the device has successfully booted up and entered the user interface. At this time, the static partition data loaded by the operating system is the updated data.
[0094] According to the method in the embodiments of this application, data in static partitions can be patched and corrected without upgrading the entire operating system, which greatly reduces the difficulty of operating system repair, improves the efficiency of operating system repair, and improves the stability of operating system operation.
[0095] Specifically, in this embodiment, the data structure of the operating system patch package and the method of updating the data in the static partition according to the operating system patch package are not specifically limited. Those skilled in the art can use various operating system patch packages with different data structures and various different data update schemes to update the data in the static partition according to actual needs.
[0096] For example, Figure 3a The illustration shows an embodiment of this application. Figure 1 The flowchart illustrates the operating system data update process for the system storage structure. The device boots from static partition (A), and the data in static partition (A) is consistent with that in static partition (B). The operating system patch package contains location data for locating the update target and the update data. For example, the update target is to update file A in the vbmeta subpartition. The operating system patch package contains the description of the storage path of file A on the device: / dev / block / by-name / vbmeta / A, the latest version of file A, and the hash value of the latest version of the vbmeta subpartition.
[0097] The equipment is in accordance with the following Figure 3a The process shown updates the data in the static partition of the operating system.
[0098] S300a and S301a, refer to S200 and S210;
[0099] S309a, extracts path description from operating system patch package; device obtains path description / dev / block / by-name / vbmeta / A;
[0100] S310a, identify the current boot order of the operating system; the device learns that the operating system is currently booting from the static partition (A); for example, refer to S230, read the MBR;
[0101] S311a, correct the path of the file to be updated according to the current boot order of the operating system; since the operating system is currently booting from the static partition (A), the device adds the suffix of the corresponding static partition (B) to the path description / dev / block / by-name / vbmeta / A, resulting in the path description / dev / block / by-name / vbmeta_b / A;
[0102] S312a, delete the file to be updated; the device deletes file A under / dev / block / by-name / vbmeta_b;
[0103] S313a extracts update files from the operating system patch package; the device obtains the latest version of file A.
[0104] S314a, Write Update File; The device writes the latest version of file A to / dev / block / by-name / vbmeta_b;
[0105] S320a, Verify update results; The device calculates the hash value of the vbmeta_b subpartition and compares the calculated hash value with the hash value of the latest version of the vbmeta subpartition in the operating system patch package to see if they are consistent.
[0106] If the verification fails and the hash values are inconsistent, execute S330a to re-obtain the operating system patch package and repeat S220 to S226; or, the device prompts the user that the patching failed, and the user manually checks the reason for the failure.
[0107] If the verification is successful and the hash values match, execute S340a to change the device's boot order from static partition (A) to static partition (B). Specifically, rewrite the boot identifier in the common partition, changing it from A to B.
[0108] S350a, device restart. Exit the current operating system, disconnect the device power, and then turn the device power back on.
[0109] After S340a is completed, the device does not need to be restarted immediately; the user can choose when to restart it.
[0110] The S360a device loads the basic partition (Common), static partition (B), and dynamic partition (Super) sequentially.
[0111] S370a, the device has successfully booted up and entered the user interface. At this time, the data loaded in the static partition is the latest updated version.
[0112] For example, for example, Figure 3b The illustration shows an embodiment of this application. Figure 1 The flowchart illustrates the operating system data update process for the system storage structure. The device boots from static partition (A), and the data in static partition (A) is consistent with that in static partition (B). The operating system patch package contains location data for locating the update target and the update data. For example, the update target might be to add file B to the vbmeta subpartition. The operating system patch package includes the storage path description of file B on the device: / dev / block / by-name / vbmeta, the file B itself, and the hash value of the latest version of the vbmeta subpartition.
[0113] The equipment is in accordance with the following Figure 3b The process shown updates the data in the static partition of the operating system.
[0114] S300b and S301b, refer to S200 and S210;
[0115] S309b extracts path descriptions from operating system patch packages; the device obtains the path description / dev / block / by-name / vbmeta.
[0116] S310b identifies the current boot order of the operating system; the device learns that the operating system is currently booting from the static partition (A);
[0117] S311b, corrects the path of the file to be updated according to the current boot order of the operating system; since the operating system is currently booting from the static partition (A), the device adds the suffix of the corresponding static partition (B) to the path description / dev / block / by-name / vbmeta, resulting in the path description / dev / block / by-name / vbmeta_b; since the path description / dev / block / by-name / vbmeta does not point to a specific file, the device does not need to delete the file in the static partition (B);
[0118] S313b extracts update files from the operating system patch package; the device obtains file B.
[0119] S314b, write update file; the device writes file B to / dev / block / by-name / vbmeta_b;
[0120] S320b~S370b, refer to S320a~S361a.
[0121] For example, for example, Figure 3c The illustration shows an embodiment of this application. Figure 1 The flowchart illustrates the operating system data update process for the system storage structure shown. The device boots from static partition (A), and the data in static partition (A) is consistent with that in static partition (B). The operating system patch package contains location data for locating the update target and the update data. For example, the update target might be to replace code segment S with S1 in a C file under the vbmeta subpartition. The operating system patch package includes the storage path description of the C file on the device: / dev / block / by-name / vbmeta / C:S, the code segment S1, and the hash value of the latest version of the vbmeta subpartition.
[0122] The equipment is in accordance with the following Figure 3c The process shown updates the data in the static partition of the operating system.
[0123] S300c and S301c, refer to S200 and S210;
[0124] S309c, extracts path description from operating system patch package; device obtains path description / dev / block / by-name / vbmeta / C:S;
[0125] S310c identifies the current boot order of the operating system; the device learns that the operating system is currently booting from the static partition (A);
[0126] S311c, the path of the file to be updated is corrected according to the current boot order of the operating system; since the operating system is currently booting from the static partition (A), the device adds the suffix of the corresponding static partition (B) to the path description / dev / block / by-name / vbmeta / C:S, resulting in the path description / dev / block / by-name / vbmeta_b / C:S; since the path description / dev / block / by-name / vbmeta / C:S points to the code segment in the specific file, the device executes S312c;
[0127] S312c, based on / dev / block / by-name / vbmeta_b / C, open the C file in the vbmeta_b subpartition;
[0128] S313c, based on / dev / block / by-name / vbmeta_b / C:S, locate the code segment S in the C file; for example, match S in / dev / block / by-name / vbmeta_b / C:S with the code in the C file, and search for the code segment in the C file that matches S.
[0129] S314c extracts code segment S1 from the operating system patch package and replaces code segment S in the C file in the vbmeta_b subpartition with code segment S1.
[0130] S320c~S370c, refer to S320a~S361a.
[0131] Furthermore, after the equipment leaves the factory, there is still a need to upgrade the equipment in actual application scenarios. Figure 4 The following is for Figure 1 The flowchart shown illustrates the operating system upgrade process using the system data storage structure. When the device is currently booting from the static partition (A), the device proceeds as follows: Figure 4 The process shown enables operating system upgrades.
[0132] The S400 device loads the basic partition (Common), static partition (A), and dynamic partition (Super) sequentially, and boots from the static partition (A).
[0133] S410, the device obtains the operating system upgrade installation package;
[0134] For example, in one feasible implementation, the device periodically sends packet search requests to the packet search server. These requests include the version number of the operating system currently running on the device (e.g., version 1.1). The packet search server, based on the operating system version number in the packet search request, searches for the existence of an operating system installation package with an updated version number (e.g., version 1.2). When an updated operating system installation package exists, the packet search server provides the device with the download address of the operating system upgrade installation package (e.g., a system incremental upgrade installation package from version 1.1 to version 1.2). The device downloads the operating system upgrade installation package based on the download address and saves it to the user data partition.
[0135] S420, the device performs data writing operations on the static partition (B) to upgrade the static partition according to the operating system upgrade installation package.
[0136] For example, the system incremental upgrade installation package for upgrading from version 1.1 to version 1.2 contains the full data of the static partition of version 1.2, and the device overwrites the data of the static partition of version 1.2 into the static partition (B).
[0137] S430: The device creates a virtual dynamic partition in the user data partition (Userdata) based on the operating system upgrade installation package, and writes the upgrade data of the dynamic partition (Super) into the virtual dynamic partition. For example, if the operating system upgrade installation package contains data for the dynamic partition of version 1.2, the device writes the data of the dynamic partition (Super) of version 1.2 into the virtual dynamic partition.
[0138] Furthermore, in the virtual A / B upgrade scheme, an incremental upgrade method is adopted 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 new version of the dynamic partition (Super) after the upgrade, but rather the upgrade result of the data that needs to be upgraded in the old version of the dynamic partition (Super). That is, the virtual dynamic partition of the user data partition (Userdata) stores the updated data of the dynamic partition.
[0139] Taking the system sub-partition as an example, suppose that in version 1.1, the data in the system sub-partition can be divided into two parts: system1 and system2. From version 1.1 to version 1.2, the data system2 remains unchanged, but the data system1 is upgraded to system3. Therefore, in the S430, the device creates a virtual dynamic partition in the user data partition and writes the data system3 into this virtual dynamic partition.
[0140] For example, the system incremental upgrade package for upgrading from version 1.1 to version 1.2 contains dynamic partition (Super) update data for upgrading from version 1.1 to version 1.2, which includes the data system3.
[0141] Furthermore, in the virtual A / B upgrade scheme, incremental upgrades of the dynamic partition (Super) are implemented based on snapshot technology. Specifically, in the virtual dynamic partition of the user data partition, a copy-on-write (COW) file is used to store the upgrade data of the dynamic partition (Super).
[0142] Specifically, the upgrade data of the Super dynamic partition stored in the Userdata partition contains multiple COW files. Each COW file corresponds to a subpartition of the Super dynamic partition, and the name of the COW file corresponds to the subpartition of the Super dynamic partition it targets.
[0143] In the operating system upgrade installation package obtained by the S410, the COW file of the upgrade data for the dynamic partition (Super) is compressed and saved in binary code form. Within the operating system upgrade installation package, each COW file is named according to the dynamic partition (Super) subpartition it targets. For example, the COW file for the system subpartition is named system-cow-img.img.0000.
[0144] In the S430, the device unpacks the operating system upgrade installation package to obtain all COW files, and appends A / B partition markers to each COW file. Specifically, when the device is currently booting from the static partition (A), it can be understood that the dynamic partition (Super) loaded by the operating system currently running on the device is the dynamic partition (A). During the operating system upgrade, the virtual dynamic partition created in the user data partition (Userdata) is for the dynamic partition (B). Therefore, the name marker _b corresponding to the dynamic partition (B) is appended to the COW file. For example, appending _b to system-cow-img.img.0000 generates system_b-cow-img.img.0000.
[0145] Furthermore, in S430, an Update folder is created in the Userdata partition, and the renamed COW file is saved in the Update folder. For example, in one application scenario, after writing a COW file to the Userdata partition, the Update folder of the Userdata partition contains the following files:
[0146] system_b-cow-img.img.0000;
[0147] system_ext_b-cow-img.img.0000;
[0148] vendor_b-cow-img.img.0000;
[0149] product_b-cow-img.img.0000;
[0150] cust_b-cow-img.img.0000;
[0151] odm_b-cow-img.img.0000.
[0152] Specifically, the COW file contains its own COW file map (snapshot map) and upgrade data. The COW file map (snapshot) corresponds to the file map of the sub-partition of the dynamic partition (Super) that the COW file targets. The file map of the sub-partition of the dynamic partition (Super) describes all files in the sub-partition of the current version of the operating system (the version prior to this upgrade, for example, version 1.1) and the storage location of each file.
[0153] The upgrade data in the COW file represents the updated files in the new version of the subpartition data compared to the current version; the COW file map itself describes the correspondence between the updated files and the files in the current version of the subpartition, as well as the storage location of the updated files.
[0154] Based on the file maps of the subpartitions of the dynamic partition (Super) and the COW file maps within the COW file, the upgrade data in the COW file can be used to replace the corresponding files in the subpartitions of the dynamic partition (Super), thereby achieving the upgrade of the dynamic partition (Super) data. Specifically, when it is necessary to obtain the file map of the subpartitions of the dynamic partition (Super), a snapshot operation can be performed on the data of the subpartitions of the dynamic partition (Super) to generate the file map. Alternatively, the file map of the subpartitions of the dynamic partition (Super) can be pre-generated when creating the operating system upgrade installation package and added to the COW file.
[0155] Taking the system subpartition as an example, assume that the data in the system subpartition is stored in the following paths:
[0156] / system / app / A0.XXX;
[0157] / system / app / A1.XXX;
[0158] / system / app / A2.XXX;
[0159] / system / B0.XXX;
[0160] / system / B1.XXX;
[0161] / system / user / C0.XXX;
[0162] / system / user / C1.XXX;
[0163] / system / user / C2.XXX;
[0164] / system / user / C3.XXX.
[0165] The file map of the system subpartition can be:
[0166] / system / app / A0.XXX: 024010~024013;
[0167] / system / app / A1.XXX: 024014~024017;
[0168] / system / app / A2.XXX: 024018~024020;
[0169] / system / B0.XXX: 024021~024026;
[0170] / system / B1.XXX: 024027~024028;
[0171] / system / user / C0.XXX: 024029~024032;
[0172] / system / user / C1.XXX: 024033~024035;
[0173] / system / user / C2.XXX: 024036~024040;
[0174] / system / user / C3.XXX: 024041~024044.
[0175] The value following the filename (e.g., 024010 to 024013 in / system / app / A0.XXX:024010 to 024013) is the physical storage address (block address) of the file in the system subpartition of the dynamic partition (Super).
[0176] Suppose that the current operating system upgrade requires updating the data / system / app / A2.XXX and / system / user / C2.XXX.
[0177] It can be considered as:
[0178] / system / app / A2.XXX and / system / user / C2.XXX are the system1 part of the system sub-partition data;
[0179] / system / app / A0.XXX, / system / app / A1.XXX, / system / B0.XXX, / system / B1.XXX, / system / user / C0.XXX, / system / user / C1.XXX, and / system / user / C3.XXX are the system2 part of the system sub-partition data.
[0180] Therefore, the COW file (system_b-cow-img.img.0000) for the system subpartition contains the latest versions of / system / app / A2.XXX and / system / user / C2.XXX.
[0181] The latest versions of / system / app / A2.XXX and / system / user / C2.XXX can be considered as system3. The upgrade goal is to use system3 to update system1.
[0182] When the size of the updated data in the COW file is the same as the size of the original data to be updated, and the location where the updated data in the COW file is saved in the subpartition after the data update is the same as the location where the original data to be updated is saved in the subpartition, the COW file map of the COW file (system_b-cow-img.img.0000) itself can be:
[0183] / system / app / A2.XXX:
[0184] Map1 (address of data to be updated in the original super partition): starting address: 024018 (offset relative to the system starting address); offset size: 2 (i.e., data in the address range 024018 to 024020).
[0185] Map2 (the address of the updated data stored in the cow file): starting address: 045033 (offset relative to the starting address of the cow file); offset size: 2 (i.e., the data in the address range of 045033 to 045035);
[0186] / system / user / C2.XXX:
[0187] Map1 (address of data to be updated in the original super partition): starting address: 024036 (offset relative to the system starting address); offset size: 4 (data in the address range 024036 to 024040).
[0188] Map2 (the address of the updated data stored in the cow file): starting address: 045036 (offset relative to the starting address of the cow file); offset size: 4 (i.e., the data in the address range of 045036 to 045040).
[0189] When the size of the updated data in the COW file is inconsistent with the size of the original data to be updated, the COW file map of the COW file (system_b-cow-img.img.0000) itself can be:
[0190] / system / app / A2.XXX:
[0191] Map1.1 (address of data to be updated in the original super partition): starting address: 024018 (offset relative to the system starting address); offset size: 2 (i.e., data in the address range 024018 to 024020).
[0192] Map2.1 (the address of the updated data that needs to overwrite the address of Map1.1 stored in the cow file): starting address: 045033 (offset relative to the starting address stored in the cow file); offset size: 2 (i.e., the data in the address range of 045033 to 045035);
[0193] Map1.2 (the address in the original super partition where the updated data in the cow file exceeds the size of the data to be updated): Starting address: 025018 (offset relative to the system starting address); Offset size: 1 (i.e., the data in the address range 025018 to 025020).
[0194] Map2.2 (the address of the updated data that needs to overwrite the address of Map1.2 stored in the cow file): starting address: 046033 (offset relative to the starting address stored in the cow file); offset size: 2 (i.e., data in the address range of 046033 to 046035).
[0195] In the following description, for ease of explanation, we will only use the following application scenario as an example: the size of the updated data in the COW file is the same as the size of the original data to be updated, and the location of the updated data in the COW file after the data update in the subpartition is the same as the location of the original data to be updated in the subpartition.
[0196] In the example above, the address ranges (045033~045035 and 045036~045040) are the physical storage addresses (block addresses) of the latest versions of / system / app / A2.XXX and / system / user / C2.XXX in the user data partition (Userdata), respectively.
[0197] Thus, if A2.XXX at addresses 045033-045035 is used to replace A2.XXX at addresses 024018-024020, and C2.XXX at addresses 045036-045040 is used to replace C2.XXX at addresses 045036-045040, the data upgrade of the system subpartition in the dynamic partition (Super) can be completed.
[0198] Furthermore, in S430, after writing the COW file to the user data partition, it is also necessary to perform an overall verification of the dynamic partition (Super) + COW file to verify the validity of the dynamic partition (Super) + COW file and to verify whether the combined result of the current version of the dynamic partition (Super) data + COW file is the new version of the dynamic partition (Super) data.
[0199] Specifically, taking the upgrade from version 1.1 to version 1.2 as an example, the hash value of the combined result of the data in the dynamic partition (Super) that does not need to be upgraded (data that has not changed from version 1.1 to version 1.2) and the upgrade data in the COW file (data that needs to be upgraded from version 1.1 to version 1.2) is calculated. It is then determined whether this hash value is consistent with the hash value of the complete data of the dynamic partition (Super) in version 1.2. If they are consistent, the COW file is valid; if they are inconsistent, the COW file is invalid, the upgrade fails, the upgrade process is interrupted, and an error is reported. The hash value of the complete data of the dynamic partition (Super) in version 1.2 is stored in the operating system upgrade installation package.
[0200] Specifically, during the verification process, the dynamic partition (Super) and COW file are merged based on the snapshot. In the implementation of the snapshot, the merging of the dynamic partition (Super) and COW file is not a physical merger, but rather a merging of the overall file map of the subpartition in the COW file with the COW file's own COW file map, generating a new version of the subpartition data's file map.
[0201] For example, a file map of the system subpartition:
[0202] / system / app / A0.XXX: 024010~024013;
[0203] / system / app / A1.XXX: 024014~024017;
[0204] / system / app / A2.XXX: 024018~024020;
[0205] / system / B0.XXX: 024021~024026;
[0206] / system / B1.XXX: 024027~024028;
[0207] / system / user / C0.XXX: 024029~024032;
[0208] / system / user / C1.XXX: 024033~024035;
[0209] / system / user / C2.XXX: 024036~024040;
[0210] / system / user / C3.XXX: 024041~024044.
[0211] Map with COW file:
[0212] / system / app / A2.XXX:
[0213] Map1: Address start: 024018; Size: 2 (i.e., data in the address range 024018 to 024020)
[0214] Map2: address start: 045033; size: 2 (i.e., data in the address range 045033 to 045035);
[0215] / system / user / C2.XXX:
[0216] Map1: address start: 024036; size: 4 (i.e., data in the address range 024036 to 024040)
[0217] Map2: address start: 045036; size: 4 (i.e., data in the address range 045036 to 045040).
[0218] Merge. This will give you a new version of the file map for the system subpartition:
[0219] / system / app / A0.XXX: 024010~024013;
[0220] (Points to A0.XXX under / system / app in the dynamic partition (Super))
[0221] / system / app / A1.XXX: 024014~024017;
[0222] (Points to A1.XXX under / system / app in the dynamic partition (Super))
[0223] / system / app / A2.XXX: 045033~045035;
[0224] (Points to A2.XXX in / Update / system_b-cow-img.img.0000 within the Userdata partition)
[0225] / system / B0.XXX: 024021~024026;
[0226] (Points to B0.XXX under / system in the dynamic partition (Super))
[0227] / system / B1.XXX: 024027~024028;
[0228] (Points to B1.XXX under / system in the dynamic partition (Super))
[0229] / system / user / C0.XXX: 024029~024032;
[0230] (Points to C0.XXX under / system / user in the dynamic partition (Super))
[0231] / system / user / C1.XXX: 024033~024035;
[0232] (Points to C1.XXX under / system / user in the dynamic partition (Super))
[0233] / system / user / C2.XXX: 045036~045040;
[0234] (Points to C2.XXX in / Update / system_b-cow-img.img.0000 within the Userdata partition)
[0235] / system / user / C3.XXX: 024041~024044.
[0236] (Points to C3.XXX under / system / user in the dynamic partition (Super))
[0237] In the new version of the file map for the system subpartition, the storage address of / system / app / A2.XXX does not point to / system / app / A2.XXX on the dynamic partition (Super) on storage, but rather to A2.XXX in system_b-cow-img.img.0000 within the user data partition (Userdata) on storage; similarly, the storage address of / system / user / C2.XXX does not point to / system / user / C2.XXX on the dynamic partition (Super) on storage, but rather to C2.XXX in system_b-cow-img.img.0000 within the user data partition (Userdata) on storage.
[0238] During the verification process, following the above synthesis method, new versions of file maps for all sub-partitions of the dynamic partition (Super) are obtained (if a corresponding COW file for a sub-partition is not written in the user data partition (Userdata), then the file map of that sub-partition is directly used as the new version of the file map). The new versions of the file maps for all sub-partitions are combined to generate a new version of the file system for the dynamic partition (Super).
[0239] Data is read from the new version of the file system based on dynamic partitions (Super), and all files contained in the new version of the file system based on dynamic partitions (Super) are read and their hash values are calculated.
[0240] When the COW file is valid, the disk write status information in the metadata partition ( / metadata) of the base partition (Common) is changed from "merged" to "wait for merge". The disk write status information indicates whether a COW file needs to be written to the dynamic partition (Super). Specifically, the disk write status information includes an overall identifier for the dynamic partition (Super) and subpartition identifiers for each subpartition. When the overall identifier is "merged", it means that none of the subpartitions of the dynamic partition (Super) need to be written to disk; when the overall identifier is "wait for merge", it means that one or more subpartitions of the dynamic partition (Super) need to be written to disk; when a subpartition identifier is "merged", it means that the subpartition does not need to be written to disk; when a subpartition identifier is "wait for merge", it means that the subpartition needs to be written to disk.
[0241] S431, change the device boot order from booting from static partition (A) to booting from static partition (B).
[0242] For example, the boot sequence identifier in the Master Boot Record (MBR) can be rewritten from A to B. After the device is powered on, if the device reads the boot sequence identifier as A, the device will boot from the static partition (A) and load the static partition (A) during the boot process; if the device reads the boot sequence identifier as B, the device will boot from the static partition (B) and load the static partition (B) during the boot process.
[0243] S432, Device restart. Exit the current operating system, disconnect the device power, and then turn the device power back on.
[0244] S440, the device loads the basic partition (Common) and the static partition (B) in sequence.
[0245] S441, the device loads a virtual dynamic partition, including a dynamic partition (Super) and a user data partition (Userdata).
[0246] Specifically, the device reads the disk write status information from the metadata ( / metadata), determines whether it needs to retrieve the COW file from the specified path of the user data partition (Userdata) based on the disk write status information, and uses a snapshot to merge and load the dynamic partition (Super) and the COW file.
[0247] Furthermore, in S441, the device does not load all COW files from the dynamic partition (Super) and the user data partition (Userdata). Instead, it loads the corresponding files based on the operating system's requirements. Specifically, in S441, the device determines the files to be loaded based on the operating system's requirements and extracts the corresponding files from the COW files in the dynamic partition (Super) or the virtual dynamic partition based on a snapshot for loading.
[0248] Specifically, in S441, when a corresponding COW file exists in a subpartition of the dynamic partition (Super), a new version of the file map for each subpartition of the dynamic partition (Super) is first generated based on the snapshot. The process of generating the new version of the file map can be referred to in S430. The device determines the files to be loaded according to the operating system's requirements and loads the files based on the new version of the file map of the dynamic partition (Super) subpartitions.
[0249] For example, the operating system requires loading all data in the user directory ( / system / user) under the system subpartition. The device reads the disk persistence status information from the metadata ( / metadata). In this information, the subpartition of the system subpartition is marked as "wait for merge." Therefore, the device searches for a COW file under / Update in the user data partition. After finding the COW file system_b-cow-img.img.0000 under Update, it generates a new version of the file map for the system subpartition based on the snapshot and the file map of the COW file in system_b-cow-img.img.0000. Data is then loaded according to the storage addresses of all files under / system / user in the new version of the file map for the system subpartition. For example, based on the new version of the file map for the system subpartition:
[0250] / system / user / C0.XXX: 024029~024032;
[0251] / system / user / C1.XXX: 024033~024035;
[0252] / system / user / C2.XXX: 045036~045040;
[0253] / system / user / C3.XXX: 024041~024044.
[0254] Load C0.XXX at addresses 024029-024032, C1.XXX at addresses 024033-024035, C2.XXX at addresses 045036-045040, and C3.XXX at addresses 024041-024044.
[0255] Furthermore, when loading all data in the user directory ( / system / user) under the system subpartition, if the subpartition identifier of the system subpartition in the disk status information is "merged", the device will not search for COW files in the / Update subpartition of the user data partition, but will directly load all data in the user directory ( / system / user) under the system subpartition.
[0256] Furthermore, when loading all data in the user directory ( / system / user) under the system subpartition, if the subpartition identifier of the system subpartition in the disk status information is "not written to disk (wait for merge)", and the device does not find the corresponding COW file of the system subpartition in the user data partition (Userdata) under / Update, it indicates that there is a data writing error during the upgrade process (COW file writing error or disk status information writing error). At this time, the device rolls back the system and reports an error.
[0257] Furthermore, in S441, the device needs to verify the file before loading it. Unlike S430, S441 does not perform overall verification of the dynamic partition (Super) + COW file, but only verifies the file to be loaded. For example, verification is based on dmverity (dm-verity is a target of dm (device mapper), a virtual block device specifically used for file system verification). If verification succeeds, the file is loaded; if verification fails, the device is restarted, the system is rolled back, or the file is tried to be loaded again.
[0258] S450, the device has successfully started up and entered the user interface.
[0259] S451, the device writes the data of the virtual dynamic partition to the dynamic partition (Super).
[0260] In the description of this application specification, the disk write operation refers to writing the dynamic partition (Super) upgrade file (COW file) stored in the virtual dynamic partition on the user data partition (Userdata) to the dynamic partition (Super) during the operating system upgrade process. This allows the files in the dynamic partition (Super) to complete the data upgrade, so that the device does not need to load the dynamic partition (Super) and the virtual dynamic partition on the next boot, but only needs to load the dynamic partition (Super) to complete the device boot.
[0261] Specifically, after a successful boot, the device broadcasts a power-on message, which then initiates the upgrade process. The upgrade process reads the disk merge status information from the metadata ( / metadata) of the base partition (Common). If the disk merge status information is "merged," the device enters normal operating mode.
[0262] If the disk write status is "wait for merge", the upgrade process will write the COW file in the Userdata partition to the dynamic partition (Super).
[0263] Specifically, the upgrade process writes the upgrade data from the COW file in the Userdata partition to the corresponding address in the Super partition, so that all the data in the Super partition is the upgraded version.
[0264] For example, based on the file map of the system subpartition / system / app / A2.XXX:024018~024020 and the COW file map / system / app / A2.XXX:045033~045035, data at addresses 045033~045035 is written to addresses 024014~024017; based on the file map of the system subpartition / system / user / C2.XXX:024036~024040 and the COW file map / system / user / C2.XXX:045036~045040, data at addresses 045036~045040 is written to addresses 024036~024040.
[0265] Following this, the upgrade process deletes the COW files in the Userdata partition, returns the storage space to the Userdata partition, and changes the disk status information in the metadata ( / metadata) of the Common partition from "wait for merge" to "merged".
[0266] In S420, the data operation for static partition upgrade is performed on the operating system data in the static partition (B), and it does not affect the operating system data in the currently booted static partition (A). Furthermore, in S430, the data operation for dynamic partition upgrade is performed on the virtual dynamic partition created in the user data partition (Userdata), and it does not affect the currently mounted dynamic partition (Super). Therefore, the user can use the device normally throughout the entire operating system upgrade process. Moreover, after S431 is completed, the device does not need to be restarted immediately; the user can choose when to restart. Thus, the operating system upgrade process does not affect the user's normal phone operation, greatly improving the user experience. Furthermore, for the dynamic partition (Super), the virtual dynamic partition is only created on the user data partition (Userdata) when an upgrade is needed, thus effectively improving data storage space utilization.
[0267] In some application scenarios, when the device is based on Figure 4 After the operating system upgrade process shown, there will be version differences between static partition (B) and static partition (A), and the data in static partition (A) and static partition (B) may be inconsistent. Therefore, if the current device boots from static partition (B), then when it is necessary to update the current operating system data, patching operations cannot be performed directly on the data in static partition (A).
[0268] Figure 5 The illustration shows an embodiment of this application. Figure 1 The flowchart illustrates the operating system data update process within the system storage structure shown. After the device boots from static partition (A), based on... Figure 4 The operating system upgrade is performed according to the procedure shown, booting from the static partition (B) to complete the upgrade. Afterwards, with the device booted from the static partition (B), the device proceeds as follows... Figure 5 The process shown updates the data in the static partition of the operating system.
[0269] The S500 loads the basic partition (Common), static partition (B), and dynamic partition (Super) in sequence, and boots from the static partition (B).
[0270] S510, Obtain the operating system patch package; refer to S210;
[0271] S511, synchronize the data of static partition (B) to static partition (A);
[0272] S520, the device reads the operating system patch package from the user data partition (Userdata) and updates the static partition (A) according to the operating system patch package; see S220;
[0273] S530, change the device boot order from booting from static partition (B) to booting from static partition (A); see S230;
[0274] S540, device restart; see S240 for reference.
[0275] The S550 device loads the basic partition (Common), static partition (A), and dynamic partition (Super) in sequence, and boots from the static partition (A).
[0276] The S560 device has successfully booted up and entered the user interface. At this point, the static partition data loaded by the operating system is the updated data.
[0277] Furthermore, this application does not impose specific limitations on the specific implementation of S511, and those skilled in the art can implement S511 in various feasible ways. The specific implementation process of S511 is illustrated below through specific embodiments.
[0278] In S420, the device writes the data from the static partition in the operating system upgrade installation package to the static partition (B). Therefore, if the same operating system upgrade installation package is used, and the data from the static partition in the operating system upgrade installation package is written to the static partition (A), the data in the static partition (A) will be consistent with the data in the static partition (B).
[0279] Therefore, in one application scenario, S511 includes: obtaining the operating system upgrade installation package stored in S410 from the user data partition (Userdata), and writing the data of the static partition in the operating system upgrade installation package into the static partition (A).
[0280] Static partition (A) and static partition (B) are completely identical in partition structure and size. Therefore, data from static partition (A) can be directly mirrored to static partition (B), or data from static partition (B) can be mirrored to static partition (A).
[0281] Figure 6 The diagram shows a flowchart of one implementation of S511. The terminal device executes as follows: Figure 6 The following process is shown to implement S511.
[0282] S600 reads all the data in the static partition (B), packages and compresses it to create an image file B;
[0283] S610 unpacks the image file B and restores it to the static partition (A), thereby overwriting the data of the static partition (B) to the static partition (A).
[0284] Static partition (A) and static partition (B) have the same partition structure, containing the same subpartitions. Therefore, by overwriting the files in each subpartition of static partition (B) to the corresponding subpartition in static partition (A), the data in static partition (B) can be synchronized to static partition (A).
[0285] Figure 7 The diagram shows a flowchart of one implementation of S511. The terminal device executes as follows: Figure 7 The following process is shown to implement S511.
[0286] S700 reads parameters related to the partition table from the device memory (these parameters are pre-stored in the device at the factory), and synthesizes the total partition table of the memory.
[0287] For example, read the address mapping descriptions of each partition under / dev / block / by-name / and integrate the address mappings of all partitions into a single master partition table.
[0288] For example, reading the partition table stored in the MBR.
[0289] S710 reads all static sub-partitions with the suffix _b from the master partition table and generates List 1 to describe each sub-partition of static partition (B). List 1 includes the name and address of each sub-partition in static partition (B). For example:
[0290] serial number Subpartition name Subpartition address (file path) Selected state 1 bootloader_b / dev / block / by-name / bootloader_b 0 2 boot_b / dev / block / by-name / boot_b 0 3 vendor_boot_b / dev / block / by-name / vendor_boot_b 0 4 dtbo_b / dev / block / by-name / dtbo_b 0 5 vbmeta_b / dev / block / by-name / vbmeta_b 0
[0291] Table 1
[0292] S720 reads all static sub-partitions with the suffix _a from the master partition table and generates List 2 to describe each sub-partition of static partition (A). List 2 includes the name and address of each sub-partition in static partition (A). For example:
[0293] serial number Subpartition name Subpartition address (file path) 1 bootloader_a / dev / block / by-name / bootloader_a 2 boot_a / dev / block / by-name / boot_a 3 vendor_boot_a / dev / block / by-name / vendor_boot_a 4 dtbo_a / dev / block / by-name / dtbo_a 5 vbmeta_a / dev / block / by-name / vbmeta_a
[0294] Table 2
[0295] It should be noted that in Tables 1 and 2, the addresses of the sub-partitions are referred to as file paths. In practical applications, those skilled in the art can use various different methods to describe the addresses of sub-partitions. For example, linear addresses can be used.
[0296] S730, select an unselected subpartition (first subpartition) in list 1, and obtain the name (first subpartition name) and address (first file path) of the subpartition.
[0297] Specifically, prior to S730, none of the sub-partitions in List 1 were selected. In S730, sub-partitions can be selected sequentially according to the order (number order) of the sub-partitions in List 1, or they can be randomly selected from all the unselected sub-partitions.
[0298] Furthermore, after selecting a subpartition, the subpartition is marked so that it can be confirmed later whether the subpartition has been selected. For example, as shown in Table 1, a "Selected Status" column is added to Table 1. The initial value of the selected status is 0, and if the subpartition is selected, the selected status is changed to 1.
[0299] S740, perform a suffix-free matching between the sub-partitions selected in S730 and each sub-partition in list 2; determine the sub-partition in list 2 whose name matches the sub-partition name selected in S730 after removing the suffix (second sub-partition name) and the sub-partition address (second file path) corresponding to the second sub-partition name in list 2.
[0300] S741, read data from the first file path;
[0301] S742 overwrites the read data to the second file path.
[0302] S750, Determine whether there are any unselected sub-partitions in list 1;
[0303] If it exists, return to step S730 and reselect the first sub-partition;
[0304] If it does not exist, static partition synchronization ends.
[0305] Taking Tables 1 and 2 as examples, in one application scenario, the device executes the following process:
[0306] Select the first subpartition in Table 1 whose selected status is 0 (the bootloader_b subpartition with number 1), and change the selected status of number 1 to 1;
[0307] Use bootloader_b to perform a suffix-free match on all sub-partition names in Table 2. bootloader_a and bootloader_b are the same after removing _a and _b respectively. Therefore, bootloader_a is matched based on bootloader_b.
[0308] Read the file path corresponding to bootloader_b from Table 1: / dev / block / by-name / bootloader_b;
[0309] Read the file path corresponding to bootloader_a from Table 2: / dev / block / by-name / bootloader_a;
[0310] Read data from / dev / block / by-name / bootloader_b and overwrite the read data to / dev / block / by-name / bootloader_a;
[0311] There are still sub-partitions in Table 1 with a selected status of 0. Select the first sub-partition in Table 1 with a selected status of 0 (the boot_b sub-partition with the number 2) and change the selected status of the number 2 to 1.
[0312] Use boot_b to perform a suffix-free match on all sub-partition names in Table 2. boot_a and boot_b are the same after removing _a and _b respectively. Therefore, boot_a is matched based on boot_b.
[0313] Read the file path corresponding to boot_b from Table 1: / dev / block / by-name / boot_b;
[0314] Read the file path corresponding to boot_a from Table 2: / dev / block / by-name / boot_a;
[0315] Read the data under / dev / block / by-name / boot_b and overwrite the read data to / dev / block / by-name / boot_a;
[0316] There are still sub-partitions in Table 1 with a selected status of 0. Select the first sub-partition in Table 1 with a selected status of 0 (sub-partition vendor_boot_b with number 3) and change the selected status of number 3 to 1.
[0317] Use vendor_boot_b to perform a suffix-free match on all subpartition names in Table 2. vendor_boot_a and vendor_boot_b are the same after removing _a and _b respectively. Therefore, vendor_boot_a is matched based on vendor_boot_b.
[0318] Read the file path corresponding to vendor_boot_b from Table 1: / dev / block / by-name / vendor_boot_b;
[0319] Read the file path corresponding to vendor_boot_a from Table 2: / dev / block / by-name / vendor_boot_a;
[0320] Read the data under / dev / block / by-name / vendor_boot_b and overwrite the read data to / dev / block / by-name / vendor_boot_a;
[0321] There are still sub-partitions in Table 1 with a selected status of 0. Select the first sub-partition in Table 1 with a selected status of 0 (sub-partition dtbo_b with number 4) and change the selected status of number 4 to 1.
[0322] Use dtbo_b to perform a suffix-free match on all sub-partition names in Table 2. dtbo_a and dtbo_b are identical after removing _a and _b respectively. Therefore, dtbo_a is matched based on dtbo_b.
[0323] Read the file path corresponding to dtbo_b from Table 1: / dev / block / by-name / dtbo_b;
[0324] Read the file path corresponding to vendor_boot_a from Table 2: / dev / block / by-name / dtbo_a;
[0325] Read the data under / dev / block / by-name / dtbo_b and overwrite the read data to / dev / block / by-name / dtbo_a;
[0326] There are still sub-partitions in Table 1 with a selected status of 0. Select the first sub-partition in Table 1 with a selected status of 0 (sub-partition vbmeta_b with number 5) and change the selected status of sub-partition number 5 to 1.
[0327] Use vbmeta_b to perform a suffix-free match on all sub-partition names in Table 2. vbmeta_a and vbmeta_b are the same after removing _a and _b respectively. Therefore, vbmeta_a is matched based on vbmeta_b.
[0328] Read the file path corresponding to vbmeta_b from Table 1: / dev / block / by-name / vbmeta_b;
[0329] Read the file path / dev / block / by-name / vbmeta_a corresponding to vendor_boot_a from Table 2;
[0330] Read data from / dev / block / by-name / vbmeta_b and overwrite the read data to / dev / block / by-name / vbmeta_a;
[0331] There are no sub-partitions with a selected status of 0 in Table 1, so static partition synchronization is complete.
[0332] Furthermore, in the above scheme, Table 1 and Table 2 are transitional data, and Table 1 and Table 2 will be deleted after the static partition synchronization is completed.
[0333] During the operating system upgrade process on S520, when reading and writing data to the static partition (B) based on the operating system upgrade installation package, it is not guaranteed that all subpartitions within static partition (B) will be overwritten. That is, if the data in static partition (A) and static partition (B) were completely identical before the operating system upgrade, then... Figure 5 After upgrading the operating system as shown in the process, the data in some sub-partitions of static partition (A) and static partition (B) may still remain consistent. Therefore, in the process of synchronizing the data of static partition (B) to static partition (A), if we first identify the sub-partitions with inconsistent data between static partition (B) and static partition (A), and only synchronize the sub-partitions with inconsistent data, we can greatly reduce the amount of data read and write operations while achieving data consistency.
[0334] Figure 8 The diagram shows a flowchart of one implementation of S511. The terminal device executes as follows: Figure 8 The following process is shown to implement S511.
[0335] S810~S840, refer to S710~S740.
[0336] S841, perform hash calculation on the data under the first path to obtain the first hash value;
[0337] S842, perform hash calculation on the data under the second sub-path to obtain the second hash value;
[0338] S843, verify whether the first hash value and the second hash value are consistent;
[0339] If they match, proceed to S850;
[0340] If they are inconsistent, S845 reads the data from the first path;
[0341] S846, overwrite the read data to the second path.
[0342] S850, refer to S750;
[0343] If it exists, return to step S830 and reselect the first sub-partition;
[0344] If it does not exist, static partition synchronization ends.
[0345] Furthermore, in the scheme of this application, the execution node for data synchronization between static partition (A) and static partition (B) is after either static partition (A) or static partition (B) is written with upgrade data, and the execution time node of S511 is not limited to after S510.
[0346] Specifically, after S420, upgrade data is written to the static partition (B). However, since the operating system loads the static partition (A) at this time, the data in the static partition (B) cannot be synchronized to the static partition (A). After S431, during the execution of S440, the device loads the static partition (B) to run the operating system. The operation of the operating system does not require loading the static partition (A), and the data in the static partition (B) can be synchronized to the static partition (A). Therefore, in the embodiments of this application, S511 can be executed at any time after S431. This application does not impose specific restrictions on the execution timing of S511. Those skilled in the art can set the synchronization time of the static partition or the triggering conditions for triggering the synchronization of the static partition according to actual needs. The following describes other execution timings of S511 through specific embodiments.
[0347] Figure 9 The diagram shown is a flowchart of an operating system upgrade according to an embodiment of this application. When the device is currently booting from a static partition (A), the device follows the steps described above. Figure 9 The process shown enables operating system upgrades and static partition synchronization.
[0348] S900~S932, refer to S400~S432;
[0349] S940, the device loads the basic partition (Common);
[0350] S950, device loads static partition (B);
[0351] S951, determine whether the static partition (B) has been successfully loaded;
[0352] If the static partition (B) fails to load, S952, restart the device and boot from the static partition (A);
[0353] If the static partition (B) is loaded successfully, in step S953, the data in the static partition (B) is synchronized to the static partition (A); the execution of S953 is the same as that in S511.
[0354] S960, load dynamic partition (Super) + virtual dynamic partition; refer to S541.
[0355] S970, the device has successfully started up and entered the user interface; see S450.
[0356] S971, the device writes the data of the virtual dynamic partition to the dynamic partition (Super); see S451.
[0357] In the virtual A / B upgrade scheme, after the device restarts and boots from the upgraded static partition, it verifies the files required for the current system to run in the dynamic partition and virtual dynamic partition. Only if the verification is successful will the necessary files be loaded. If verification fails, the device will restart and roll back the system, at which point the system upgrade will fail.
[0358] Therefore, to avoid static partition synchronization in the event of upgrade failure, in one embodiment of this application, static partition synchronization is only performed after the files required to be loaded by the dynamic partition + virtual dynamic partition have been successfully verified, or after the files required to be loaded by the dynamic partition + virtual dynamic partition have been successfully loaded.
[0359] Figure 10 The diagram shown is a flowchart of an operating system upgrade according to an embodiment of this application. When the device is currently booting from a static partition (A), the device follows the steps described above. Figure 10 The process shown enables operating system upgrades and static partition synchronization.
[0360] S1000~S1052, refer to S900~S952;
[0361] If the static partition (B) is loaded successfully, S1053, verify the files that need to be loaded in the dynamic partition + virtual dynamic partition; for example, use dmverity.
[0362] S1054, determine whether the verification was successful.
[0363] If the verification fails, S1060, restart the device and roll back the system, for example, by booting from the static partition (A).
[0364] If the verification is successful, execute S1055;
[0365] S1055 synchronizes the data from static partition (B) to static partition (A); the execution of S1055 is the same as S511.
[0366] S1056~S1058, refer to S960~S971.
[0367] Furthermore, prior to S520, the data in static partition (A) and static partition (B) was consistent. After S520, because the data in static partition (B) was updated, the data in static partition (A) and static partition (B) became inconsistent. To ensure data consistency between static partition (A) and static partition (B), such as... Figure 5 As shown, after S560, the device also executes S570 to synchronize the data of static partition (A) to static partition (B). The execution of S570 is the same as that of S511.
[0368] It is understood that some or all of the steps or operations in the above embodiments are merely examples, and other operations or variations thereof can be performed in the embodiments of this application. Furthermore, the steps may be performed in different orders as presented in the above embodiments, and it is not necessary to perform all the operations in the above embodiments.
[0369] Furthermore, generally speaking, improvements to a technology can be clearly distinguished as either hardware improvements (e.g., improvements to the circuit structure of diodes, transistors, switches, etc.) or software improvements (improvements to the methodology). However, with technological advancements, many improvements to the methodology today can be considered direct improvements to the hardware circuit structure. Designers almost always obtain the corresponding hardware circuit structure by programming the improved methodology into the hardware circuit. Therefore, it cannot be said that an improvement to the methodology cannot be implemented using hardware physical modules. For example, a Programmable Logic Device (PLD) (e.g., a Field Programmable Gate Array (FPGA)) is such an integrated circuit whose logic function is determined by the user programming the device. Designers can program a digital device themselves to "integrate" it onto a PLD, without needing chip manufacturers to design and manufacture dedicated integrated circuit chips. Furthermore, nowadays, instead of manually manufacturing integrated circuit chips, this programming is mostly implemented using "logic compiler" software. Similar to the software compiler used in program development, the original code before compilation must be written in a specific programming language, called a Hardware Description Language (HDL). There are many HDLs, such as ABEL (Advanced Boolean Expression Language), AHDL (Altera Hardware Description Language), Confluence, CUPL (Cornell University Programming Language), HDCal, JHDL (Java Hardware Description Language), Lava, Lola, MyHDL, PALASM, and RHDL (Ruby Hardware Description Language). Currently, the most commonly used are VHDL (Very-High-Speed Integrated Circuit Hardware Description Language) and Verilog. Those skilled in the art should understand that by simply performing some logic programming on the method flow using one of these hardware description languages and programming it into an integrated circuit, the hardware circuit implementing the logical method flow can be easily obtained.
[0370] Therefore, the method flow proposed in the embodiments of this application can be implemented in hardware, for example, by using a controller to control the touch screen to implement the method flow proposed in the embodiments of this application.
[0371] The controller can be implemented in any suitable manner. For example, it can take the form of a microprocessor or processor and a computer-readable medium storing computer-readable program code (e.g., software or firmware) executable by the (micro)processor, logic gates, switches, application-specific integrated circuits (ASICs), programmable logic controllers, and embedded microcontrollers. Examples of controllers include, but are not limited to, the following microcontrollers: ARC 625D, Atmel AT91SAM, Microchip PIC18F26K20, and Silicon Labs C8051F320. A memory controller can also be implemented as part of the control logic of the memory. Those skilled in the art will also recognize that, in addition to implementing the controller in purely computer-readable program code form, the same functionality can be achieved by logically programming the method steps to make the controller take the form of logic gates, switches, application-specific integrated circuits, programmable logic controllers, and embedded microcontrollers. Therefore, such a controller can be considered a hardware component, and the means included therein for implementing various functions can also be considered as structures within the hardware component. Alternatively, the means for implementing various functions can be considered as both software modules implementing the method and structures within the hardware component.
[0372] Corresponding to the above embodiments, this application also provides an electronic device. The electronic device includes a memory for storing computer program instructions and a processor for executing the program instructions, wherein when the computer program instructions are executed by the processor, the electronic device is triggered to perform the method steps as described in the embodiments of this application.
[0373] This application also provides a computer program product, which includes a computer program that, when run on a computer, causes the computer to perform some or all of the steps provided in the embodiments of this application.
[0374] Those skilled in the art will clearly understand that the techniques in the embodiments of the present invention can be implemented using software plus necessary general-purpose hardware platforms. Based on this understanding, the technical solutions in the embodiments of the present invention, or the parts that contribute to the prior art, can be embodied in the form of a software product. This computer software product can be stored in a storage medium, such as ROM / RAM, magnetic disk, optical disk, etc., and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute the methods described in various embodiments or certain parts of the embodiments of the present invention.
[0375] The same or similar parts between the various embodiments in this specification can be referred to mutually. In particular, the device embodiments and terminal embodiments are basically similar to the method embodiments, so the description is relatively simple, and the relevant parts can be referred to the description in the method embodiments.
Claims
1. An operating system data update method, characterized in that, The method is applied to an electronic device, which includes a processor and a memory. The memory includes a base partition, a first static partition, a second static partition, a dynamic partition, and a user data partition. After the electronic device starts up, it loads data from the base partition, the first static partition, and the dynamic partition to run a first operating system. After the first operating system runs, the method includes: Obtain the patch package based on the version number of the first operating system; Confirm whether the data in the first static partition is consistent with the data in the second static partition; After confirming that the data in the first static partition is consistent with the data in the second static partition, update the data in the second static partition according to the patch package; The boot order of the electronic device is changed from booting from the first static partition to booting from the second static partition; Restart the electronic device; Load the data from the base partition, the second static partition, and the dynamic partition to run the first operating system after the static partition data has been updated; Before obtaining the patch package, the method further includes: Load the data from the base partition, the second static partition, and the dynamic partition to run the second operating system; Obtain the upgrade installation package, which includes static partition upgrade files and dynamic partition upgrade data; The data of the first static partition is upgraded based on the static partition upgrade file, and the dynamic partition upgrade data is saved in the user data partition. The boot order of the electronic device is changed from booting from the second static partition to booting from the first static partition; Restart the electronic device and confirm that the current boot order is to boot from the first static partition; Load the base partition, the first static partition, and verify the data in the dynamic partition and the data to be loaded in the dynamic partition upgrade data; If the verification is successful, the data of the dynamic partition and the upgrade data of the dynamic partition are loaded to run the first operating system; After the verification is successful, the data in the first static partition is synchronized to the second static partition.
2. The method according to claim 1, characterized in that, The method further includes: After confirming that the data in the first static partition is inconsistent with the data in the second static partition, the data in the first static partition is synchronized to the second static partition.
3. The method according to claim 2, characterized in that, The step of synchronizing the data from the first static partition to the second static partition includes: Read the data from each sub-partition of the first static partition; The data in each sub-partition of the first static partition is overwritten into the corresponding sub-partition of the second static partition.
4. The method according to claim 2, characterized in that, The step of synchronizing the data from the first static partition to the second static partition includes: Calculate the hash value of the data in the third sub-partition, wherein the third sub-partition is a sub-partition of the first static partition; Calculate the hash value of the data in the fourth sub-partition, wherein the fourth sub-partition is a sub-partition of the second static partition, and the fourth sub-partition corresponds to the third sub-partition; When the hash value of the data in the third sub-partition is inconsistent with the hash value of the data in the fourth sub-partition, the data in the third sub-partition is overwritten into the fourth sub-partition.
5. The method according to claim 1, characterized in that, After loading the data from the base partition, the second static partition, and the dynamic partition to run the first operating system updated with the static partition data, the method further includes: Synchronize the data from the second static partition to the first static partition.
6. The method according to any one of claims 1 to 5, characterized in that, The patch package includes an update location description and update data. The update location description is used to specify the update target in the second static partition that needs to be updated, and the update data is used to describe the data update result of the second static partition. The step of updating the data in the second static partition according to the patch package includes: Update the data in the second static partition according to the update location description and update data in the patch package.
7. The method according to claim 6, characterized in that, The step of obtaining the patch package based on the version number of the first operating system includes: Obtain the first path; Add the directory name suffix corresponding to the second static partition to the first path to generate the updated location description.
8. 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 processor is used to execute software code stored in the memory, such that: After the electronic device starts up, it loads the data from the base partition, the first static partition, and the dynamic partition to run the first operating system. And after the first operating system is running, the method flow as described in any one of claims 1 to 7 is executed.
9. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program that, when run on a computer, causes the computer to perform the method as described in any one of claims 1 to 7.
Citation Information
Patent Citations
A software starting method and a software upgrading method
CN109408153A
OTA upgrading method and device, terminal and computer readable storage medium
CN110543321A