Data update methods and electronic devices

Abstract

This application provides a data update method and electronic device, relating to the field of intelligent connected vehicle technology. The method includes: obtaining a system update differential package, the system update differential package including at least a difference bitmap; with a first system partition running in the foreground and a second system partition running in the background, determining at least one data block to be updated in the second system partition according to the data blocks to be updated indicated in the difference bitmap, and updating at least one data block to be updated according to the difference bitmap, wherein the first system partition and the second system partition are backup partitions for each other; switching the updated second system partition to run in the foreground, placing the first system partition to run in the background, and synchronously updating the data in the first system partition according to the data in the updated second system partition.

Description

Technical Field

[0001] This application relates to the field of intelligent connected vehicle technology, and in particular to a data update method and electronic device. Background Technology

[0002] Multiple systems can be configured in electronic devices, with one system running in the foreground and others in the background. These systems share the same data but operate independently. Currently, data updates primarily employ a full-overwrite method. Even if the upgrade package is a differential package, regardless of the actual data difference, the system partition to be upgraded is written byte-by-byte to the new system partition. Unchanged data is also copied from the source file, resulting in redundant writing, wasting resources, and reducing data update efficiency. Summary of the Invention

[0003] In view of the above problems, this application provides a data updating method and electronic device that overcomes or at least partially solves the above problems, and the technical solution is as follows: A data update method, the data update method comprising: Obtain a system update differential packet, wherein the system update differential packet includes at least a difference bitmap; When the first system partition is running in the foreground and the second system partition is running in the background, at least one data block to be updated in the second system partition is determined according to the data block to be updated indicated in the difference bitmap, and the at least one data block to be updated is updated according to the difference bitmap, wherein the first system partition and the second system partition are backup partitions for each other; The updated second system partition is switched to run in the foreground, the first system partition is run in the background, and the data in the first system partition is synchronously updated according to the data in the updated second system partition.

[0004] In this solution, while the first system partition runs in the foreground, the second system partition is incrementally updated in the background based on the difference bitmap. This ensures that the system partition running in the foreground remains available at all times, and no device restart is required during the update process, achieving seamless updates and greatly improving the user experience. In addition, by accurately identifying the data blocks that need to be updated through the difference bitmap, only the data blocks that have actually changed in the second system partition are updated, rather than a full write of the entire system partition, which greatly reduces the amount of data that needs to be updated and significantly shortens the time required for system updates. Furthermore, after switching the updated second system partition to run in the foreground, the first system partition is then updated synchronously based on the updated second system partition, ensuring that the two system partitions always maintain data consistency.

[0005] Optionally, determining at least one data block to be updated in the second system partition based on the presence of updated data blocks indicated in the difference bitmap includes: The difference bitmap is parsed to identify whether a first data update identifier exists in the difference bitmap. The first data update identifier is used to indicate that the current data block needs to be updated. If the difference bitmap is detected to include at least one first data update identifier, the data block in the second system partition indicated by each first data update identifier is determined as the data block to be updated, thus obtaining the at least one data block to be updated.

[0006] In this scheme, by identifying the first data update identifier in the difference bitmap, the data block that needs to be updated can be accurately located without traversing all data blocks, thus avoiding invalid updates and effectively improving the targeting and execution efficiency of the data update process.

[0007] Optionally, updating the at least one data block to be updated according to the difference bitmap includes: According to the target data corresponding to each first data update identifier in the difference bitmap, the data block to be updated indicated by each first data update identifier is updated.

[0008] In this scheme, each first data update identifier is bound to the target data of the corresponding data block, ensuring that when data is updated, the correct matching target data is written to the corresponding data block, avoiding data update anomalies caused by data misalignment, improving the accuracy of data updates, and ensuring the normal operation of the system.

[0009] Optionally, switching the updated second system partition to run in the foreground and placing the first system partition to run in the background includes: The system update differential packet is parsed to obtain the target checksum; Based on the target check code, the data in the updated second system partition is verified to obtain the verification result; If the verification result indicates that the verification is successful, the updated second system partition is switched to run in the foreground, and the first system partition is placed to run in the background.

[0010] In this scheme, the updated data is verified before the system partition is switched. Only if the verification passes can the system be switched to the foreground. This avoids the risk of system crash due to corrupt or incomplete updated data and ensures device security. In addition, the target verification code is obtained directly from the system update differential packet and comes from the same source as the updated data, ensuring the accuracy and reliability of the verification results.

[0011] Optionally, after verifying the data in the updated second system partition based on the target checksum and obtaining the verification result, the method further includes: If the verification result indicates that the verification fails, identify whether there is a second data update identifier in the difference bitmap. The second data update identifier is used to indicate that the current data block does not need to be updated. If at least one second data update identifier is detected in the difference bitmap, the data block in the second system partition indicated by each second data update identifier is identified as the data block to be refreshed; Based on the data in the first system partition, the data block to be refreshed is refreshed.

[0012] In this scheme, when the verification fails, the second data update identifier in the difference bitmap is used to identify which data blocks have not been modified (i.e., should remain consistent with the first system partition). Since the first system partition remains in the foreground and its data is complete throughout the update process, it can be used as the data source for the refresh. The corresponding data is obtained from the first system partition for refresh, ensuring the correctness of the refreshed data and eliminating the need for additional data backup, thus improving the repair efficiency.

[0013] Optionally, after verifying the updated second system partition based on the target checksum and obtaining the verification result, the method further includes: If the verification result indicates that the verification fails, a rollback operation is performed on the updated second system partition, and all data blocks in the rolled-back second system partition are updated based on the data in the first system partition and the difference bitmap.

[0014] In this solution, in addition to partial patching, the second system partition can be restored to the data version before the update through a rollback operation. Then, a full update is performed based on the data and difference bitmap in the intact first system partition, ensuring that the update process will not result in unrecoverable situations due to data corruption.

[0015] Optionally, the step of synchronously updating the data in the first system partition according to the updated data in the second system partition includes: The data blocks in the first system partition and the updated data blocks in the second system partition are compared respectively to generate a local difference bitmap; The data in the first system partition is synchronously updated according to the local difference bitmap.

[0016] In this solution, when updating the first system partition, the data of the two system partitions can be fully compared to generate a local difference bitmap before updating. The entire process can be completed locally on the device, and the full comparison can minimize the problem of data omission and improve the integrity of data synchronization.

[0017] Optionally, the step of synchronously updating the data in the first system partition according to the updated data in the second system partition includes: The data in the first system partition is synchronously updated according to the difference bitmap corresponding to the updated second system partition.

[0018] In this scheme, the difference bitmap corresponding to the updated second system partition is directly reused to synchronously update the first system partition. There is no need to perform a full data comparison and difference bitmap generation again on the device side, which saves a lot of computing resources and time and improves the efficiency of synchronous update. In addition, both system partitions use the same difference bitmap for updating, which ensures the consistency of update logic and data synchronization.

[0019] Optionally, after synchronizing and updating the data in the first system partition according to the updated data in the second system partition, the method further includes: The updated second system partition and the updated first system partition are compared to obtain the data comparison results; If the data comparison results indicate that the data is the same, it is determined that both the first system partition and the second system partition have been updated.

[0020] In this scheme, the update is considered complete only after a final data comparison between the two system partitions confirms that the data in the two system partitions is completely consistent. This provides a clear completion condition for the entire update process and also ensures that the data in the two system partitions is completely synchronized when the next data update begins, avoiding the accumulation of errors in incremental updates.

[0021] A data updating device, the data updating device comprising: An acquisition module is used to acquire a system update differential packet, wherein the system update differential packet includes at least a difference bitmap; The processing module is configured to, when the first system partition is running in the foreground and the second system partition is running in the background, determine at least one data block to be updated in the second system partition based on the existence of updated data blocks indicated in the difference bitmap, and update the at least one data block to be updated according to the difference bitmap, wherein the first system partition and the second system partition are backup partitions for each other; The processing module is further configured to switch the updated second system partition to run in the foreground, place the first system partition to run in the background, and synchronously update the data in the first system partition according to the data in the updated second system partition.

[0022] An electronic device includes a memory and a processor, wherein the memory stores executable program code, and the processor is configured to call and execute the executable program code to perform any of the optional data update methods described above.

[0023] A computer-readable storage medium storing a computer program that, when executed by a processor, implements any of the optional data update methods described above.

[0024] A computer program product, when run on a computer, causes the computer to perform the aforementioned related steps to implement any of the optional data update methods described above.

[0025] Using the above technical solution, this application provides a data update method and electronic device that obtains a system update differential package, which includes at least a difference bitmap. When the first system partition is running in the foreground and the second system partition is running in the background, based on the data blocks indicating updates in the difference bitmap, at least one data block to be updated in the second system partition is determined, and the at least one data block to be updated is updated according to the difference bitmap. The first system partition and the second system partition serve as backup partitions for each other. The updated second system partition is switched to run in the foreground, the first system partition is placed in the background, and the data in the first system partition is synchronously updated according to the data in the updated second system partition. While the first system partition runs in the foreground, the second system partition is incrementally updated in the background based on the difference bitmap. This ensures that the system partition running in the foreground remains available at all times, and no device restart is required during the update process, achieving a seamless update and greatly improving the user experience. In addition, by accurately identifying the data blocks that need to be updated through the difference bitmap, only the data blocks that have actually changed in the second system partition are updated, rather than a full write of the entire system partition, which greatly reduces the amount of data that needs to be updated and significantly shortens the time required for system updates. Furthermore, after switching the updated second system partition to run in the foreground, the first system partition is then updated synchronously based on the updated second system partition, ensuring that the two system partitions always maintain data consistency.

[0026] The above description is only an overview of the technical solution of this application. In order to better understand the technical means of this application and to implement it in accordance with the contents of the specification, and to make the above and other objects, features and advantages of this application more obvious and understandable, the following are specific embodiments of this application. Attached Figure Description

[0027] Various other advantages and benefits will become apparent to those skilled in the art upon reading the following detailed description of preferred embodiments. The accompanying drawings are for illustrative purposes only and are not intended to limit the scope of this application. Furthermore, the same reference numerals denote the same parts throughout the drawings. In the drawings: Figure 1 One of the flowcharts of the data update method provided in this application is shown; Figure 2 The second schematic flowchart of the data update method provided in the embodiment of this application is shown; Figure 3 The third schematic flowchart of the data update method provided in this application embodiment is shown; Figure 4 The fourth schematic flowchart of the data update method provided in this application embodiment is shown; Figure 5 The fifth illustration shows a flowchart of the data update method provided in an embodiment of this application; Figure 6 The sixth illustration shows a flowchart of the data update method provided in an embodiment of this application; Figure 7 The seventh flowchart illustrates the data update method provided in this application embodiment; Figure 8 This is illustrated as the eighth flowchart of the data update method provided in this application embodiment; Figure 9 A flowchart of the data update method provided in an embodiment of this application is shown as diagram number nine; Figure 10 This illustration shows a schematic diagram of the structure of a data update device provided in an embodiment of this application; Figure 11 A schematic diagram of the structure of an electronic device provided in an embodiment of this application is shown. Detailed Implementation

[0028] Exemplary embodiments of the present application will now be described in more detail with reference to the accompanying drawings. While exemplary embodiments of the present application are shown in the drawings, it should be understood that the present application may be implemented in various forms and should not be limited to the embodiments set forth herein. Rather, these embodiments are provided so that this application will be thorough and complete, and will fully convey the scope of the present application to those skilled in the art.

[0029] The A / B partitioning system (also known as the seamless update system) is an OTA (Over-The-Air) upgrade mechanism widely used in Android and embedded Linux systems. This system divides the storage medium into two independent partitions (A side and B side), each containing a complete system partition (such as boot, system, vendor, etc.). It can be understood as having two identical and independent operating systems in an electronic device. When one system is running in the foreground, the other runs in the background, acting as a backup system. If the foreground system fails, the other system can be switched to the foreground, thus ensuring the continued operation of the electronic device as much as possible.

[0030] When updating the A / B system partitions, you can first update the idle backup partition. After the update is complete, you can switch the backup partition to run in the foreground, so that the partition that was originally running in the foreground is moved to the background for synchronous updates, thus completing the update of all data in the A / B partition system.

[0031] Currently, the mainstream approach for updating data across system partitions is to use a full-overwrite method. This means that regardless of the actual size of the data difference, the complete partition image to be upgraded is written byte by byte to the backup system partition. Even if the upgrade package itself is in differential package form, the differential package only contains binary difference patches. Even if the differential package indicates that only a small portion of the data has been updated, a full data rewrite operation is still required. In other words, for data that has not changed, it is still necessary to copy it from the source file, while for data that has changed, it can be obtained from the differential package, resulting in a significant waste of resources. The write time is directly proportional to the partition size. When the partition size is much larger than the amount of difference data (e.g., only 5MB of data changes in a 100MB partition, but 100MB of data still needs to be written), the write time cannot be reduced proportionally to the difference, resulting in excessively long partition update times.

[0032] Furthermore, after updating the backup partition, it is necessary to switch partitions and synchronize the data on the other partition. The data in the upgraded partition is synchronized to the other partition. This process also uses a full write method, and the write time is linearly related to the partition capacity. This also results in redundant writing and wasted time and resources.

[0033] Furthermore, the continuous I / O operations during a full write process consume bus bandwidth, incurring processor interrupt handling overhead and memory buffer usage. In resource-constrained embedded scenarios, this may affect the real-time performance of critical tasks. Additionally, a long write window increases the risk of write interruptions due to abnormal power outages or voltage fluctuations.

[0034] In some embodiments, electronic devices can communicate with a server. Electronic devices may communicate with the server via a Local Area Network (LAN) or a Wireless Local Area Network (WLAN). The server may be a server providing various services, may be a server cluster or multiple server clusters, and may include one or more types of servers.

[0035] It should be noted that the data update method provided in this application embodiment can be executed by an electronic device.

[0036] Furthermore, the data update method provided in this application embodiment can be executed by a data update device, which can be hardware or software. When the data update device is hardware, it can be various electronic devices with data update functions, including but not limited to mobile phones, computers, tablets, and in-vehicle systems. When the data update device is software, it can be installed in the aforementioned electronic devices. It can be implemented as multiple software programs or software modules, or as a single software program or software module. No specific limitations are made here.

[0037] This application provides a data updating method, such as Figure 1 As shown, Figure 1 This is a schematic flowchart illustrating a data update method provided in an embodiment of this application. The method includes: 101. Obtain the system update differential package.

[0038] In this embodiment of the application, the system update differential packet can be used to update data in the system partition. The system update differential packet can include at least a difference bitmap, which can be used to indicate which specific data blocks need to be updated and what kind of data they need to be updated to.

[0039] In some embodiments, the system update differential package can be generated by a cloud-based package-making tool and sent to the electronic device to update the data of each system partition in the electronic device. After obtaining the target version, the package-making tool can compare the target version with the source version, calculate the block-level differences between the target version and the source version, generate a difference bitmap, embed the difference bitmap into the system update differential package, and send it to the electronic device over the network so that the electronic device can obtain the system update differential package and extract the difference bitmap from it. Here, the source version is the data version before the update, and the target version is the updated data version, which is the latest data version. The data in each system partition needs to be updated from the data in the source version to the data in the target version.

[0040] In some embodiments, the difference bitmap may be embedded in the system update difference package in the form of metadata. Of course, the difference bitmap may also be embedded in the system update difference package in the form of a script file, and there is no limitation.

[0041] 102. When the first system partition is running in the foreground and the second system partition is running in the background, based on the data blocks to be updated indicated in the difference bitmap, determine at least one data block to be updated in the second system partition, and update at least one data block to be updated according to the difference bitmap.

[0042] It should be noted that an electronic device may include a first system partition and a second system partition. These two partitions are identical and independent, and can be considered backup partitions for each other. During the operation of the electronic device, one system partition will run in the foreground while the other runs in the background. Of course, the system partition running in the foreground can be switched at any time during operation. That is, it can be that the first system partition is running in the foreground and the second system partition is running in the background, or vice versa. This switching of running system partitions can be a built-in function of the electronic device.

[0043] In this embodiment, when updating data in a system partition, since the foreground system partition is running and its data is needed to support device operation, it is not necessary to update the foreground system partition online. However, the system partition running in the background is idle and can be updated. Therefore, the system partition running in the background can be updated first. Thus, when the first system partition is running in the foreground and the second system partition is running in the background, the second system partition can be updated first. During the data update process of the second system partition, since not all data blocks need to be updated, the difference bitmap will indicate which data blocks need to be updated. Therefore, based on the data blocks that need to be updated indicated in the difference bitmap, the corresponding data blocks in the second system partition can be determined. These data blocks are the data blocks in the second system partition that need to be updated. In this way, at least one data block in the second system partition can be identified as needing to be updated.

[0044] After identifying at least one data block in the second system partition that needs updating, the difference bitmap indicates how these data blocks will be updated. Therefore, the at least one data block can be updated according to this difference bitmap to obtain the updated second system partition. It can be seen that during the update process, only the at least one data block that has changed is updated; other data blocks that do not require updates are not processed.

[0045] 103. Switch the updated second system partition to run in the foreground, put the first system partition to run in the background, and synchronize the data in the first system partition according to the data in the updated second system partition.

[0046] In this embodiment, after updating the second system partition and obtaining the updated second system partition, the data in the second system partition is already the latest version. Since the first system partition still needs to be updated, the updated second system partition can be switched to the foreground and the first system partition can be placed in the background. At this time, the first system partition is in an idle state, so the data in the first system partition can be updated. When updating the data in the first system partition, since the data in the updated second system partition is already the latest version, the data in the first system partition can be updated synchronously according to the data in the updated second system partition.

[0047] In some embodiments, this application uses data block granularity for data updates. Of course, larger file granularity or smaller byte granularity can also be used for data updates. For example, the difference bitmap includes each file that needs to be updated, and the corresponding file in the second system partition is updated; and the difference bitmap includes each byte range that needs to be updated, and the bytes in the corresponding byte range in the second system partition are updated.

[0048] In the solution provided in this application embodiment, a system update differential package is obtained, which includes at least a difference bitmap; when the first system partition is running in the foreground and the second system partition is running in the background, at least one data block to be updated in the second system partition is determined according to the data block to be updated indicated in the difference bitmap, and the at least one data block to be updated is updated according to the difference bitmap, with the first system partition and the second system partition serving as backup partitions for each other; the updated second system partition is switched to run in the foreground, the first system partition is placed in the background, and the data in the first system partition is synchronously updated according to the data in the updated second system partition. While the first system partition runs in the foreground, the second system partition is incrementally updated in the background based on the difference bitmap. This ensures that the system partition running in the foreground remains available at all times, and no device restart is required during the update process, achieving a seamless update and greatly improving the user experience. In addition, by accurately identifying the data blocks that need to be updated through the difference bitmap, only the data blocks that have actually changed in the second system partition are updated, rather than a full write of the entire system partition, which greatly reduces the amount of data that needs to be updated and significantly shortens the time required for system updates. Furthermore, after switching the updated second system partition to run in the foreground, the first system partition is then updated synchronously based on the updated second system partition, ensuring that the two system partitions always maintain data consistency.

[0049] In some embodiments, such as Figure 2 As shown, in Figure 1 Based on the data blocks to be updated indicated in the difference bitmap, at least one data block in the second system partition is determined to be updated, which may specifically include the following steps: 1021. Analyze the difference bitmap to identify whether there is a first data update identifier in the difference bitmap.

[0050] In this embodiment of the application, after extracting the difference bitmap from the system update differential packet, the difference bitmap can be parsed to identify whether there is a first data update identifier in the difference bitmap. The first data update identifier can be used to indicate that the current data block needs to be updated.

[0051] It should be noted that when the packet generation tool generates the difference bitmap, it can write a data update identifier for each data block to indicate whether the data block has been updated. At least a first data update identifier can be written for data blocks that have been updated, and a second data update identifier can also be written for data blocks that have not been updated. In this way, when parsing the difference bitmap, it is possible to directly determine which data blocks need to be updated by identifying the first data update identifier.

[0052] 1022. If at least one first data update identifier is detected in the difference bitmap, the data block in the second system partition indicated by each first data update identifier is identified as the data block to be updated, thereby obtaining at least one data block to be updated.

[0053] In this embodiment of the application, by identifying the data update identifiers included in the difference bitmap, if at least one first data update identifier is identified in the difference bitmap, since the first data update identifier corresponds to each data block, the number of data blocks that need to be updated is equal to the number of first data update identifiers. Therefore, it can be concluded that at least one data block in the current second system partition needs to be updated. Thus, the data block in the second system partition indicated by each first data update identifier can be determined as the data block to be updated, thereby obtaining at least one data block to be updated in the second system partition.

[0054] It is understandable that the difference bitmap can indicate at least one data block that needs to be updated, and a first data update identifier is written for each of these data blocks. When parsing the difference bitmap, as long as a first data update identifier is identified, it can be considered that the data block corresponding to the first data update identifier needs to be updated. Similarly, the corresponding data block in the second system partition can be identified as a data block to be updated. The number of first data update identifiers in the difference bitmap corresponds to the number of data blocks to be updated in the second system partition.

[0055] In the solution provided in this application embodiment, by identifying the first data update identifier in the difference bitmap, the data block that needs to be updated can be accurately located without traversing all data blocks, thus avoiding invalid updates and effectively improving the targeting and execution efficiency of the data update process.

[0056] In some embodiments, such as Figure 3 As shown, in Figure 2 Based on this, at least one data block to be updated is updated according to the difference bitmap, which may specifically include the following steps: 1023. Update the data block to be updated indicated by each first data update identifier according to the target data corresponding to each first data update identifier in the difference bitmap.

[0057] In this embodiment, after determining at least one data block to be updated based on the first data update identifier in the difference bitmap, these data blocks need to be updated. Since the difference bitmap not only indicates which data blocks need updating but also what data these blocks should be updated to, a first data update identifier and target data are written to each data block that needs updating. The target data is the data that this data block needs to be modified to. Then, according to the target data corresponding to each first data update identifier, the data blocks to be updated in the second system partition indicated by the first data update identifier can be updated, that is, the data of the data blocks to be updated is updated to the target data.

[0058] For example, the difference bitmap includes: data block 5 carrying a first data update identifier, the target data of data block 5 being A; data block 8 carrying a first data update identifier, the target data of data block 8 being B; and data block 10 carrying a first data update identifier, the target data of data block 10 being C. It can be seen that data updates are currently needed for data blocks 5, 8, and 10 in the second system partition. Data blocks 5, 8, and 10 are the data blocks to be updated, and A, B, and C are the updated data of data blocks 5, 8, and 10. Therefore, the data of data block 5 can be updated to A, the data of data block 8 can be updated to B, and the data of data block 10 can be updated to C. No operation is performed on other data blocks.

[0059] In the solution provided in this application embodiment, each first data update identifier is bound to the target data of the corresponding data block, ensuring that when the data is updated, the correct matching target data is written to the corresponding data block, avoiding data update anomalies caused by data misalignment, improving the accuracy of data updates, and ensuring the normal operation of the system.

[0060] In some embodiments, such as Figure 4 As shown, in Figure 1 Based on this, the updated second system partition is switched to run in the foreground, while the first system partition is placed in the background. This can specifically include the following steps: 1031. Parse the system update differential packet to obtain the target checksum.

[0061] In this embodiment, since the system partition contains data that supports device operation, it is necessary to ensure that the updated data is accurate and complete. Therefore, the updated system partition data must be verified to ensure normal device operation. The verification process for the data in the system partition can be implemented using commonly used hash algorithms. Therefore, when generating the system update differential packet, the packet generation tool can perform hash calculations on the updated data of the changed data blocks to obtain hash values. Since the target version data obtained by the packet generation tool can be considered accurate, the hash values ​​calculated from this target version data can also be considered accurate values. Therefore, the calculated hash value can be stored as the target checksum in the system update differential packet and sent to the electronic device. In this way, during the verification process, the target checksum can be considered a standard baseline value.

[0062] 1032. Based on the target checksum, verify the data in the updated second system partition to obtain the verification result.

[0063] It should be noted that a hash algorithm can be understood as knowing a standard hash value, and then performing a hash calculation on the data that needs to be verified to calculate a verification hash value. If the verification hash value is the same as the standard hash value, it means that the data that needs to be verified is accurate and complete.

[0064] In this embodiment, the target check code is the standard hash value, and the data in the updated second system partition is the data that needs to be checked. So, the data in the updated second system partition can be hashed to obtain the check hash value corresponding to the data in the updated second system partition. Then, the check hash value can be compared with the target check code to obtain the check result, which can include check pass and check fail.

[0065] In some embodiments, if the verification hash value is the same as the target check code, it indicates that the data in the updated second system partition is accurate and complete, and the verification can be considered to have passed; if the verification hash value is different from the target check code, it indicates that the data in the updated second system partition is inaccurate and incomplete, which may be due to an anomaly in the process of system update differential packet transmission, difference bitmap parsing, update of data blocks to be updated, etc., and the verification can be considered to have failed.

[0066] 1033. If the verification result indicates that the verification passed, switch the updated second system partition to run in the foreground and put the first system partition to run in the background.

[0067] In this embodiment of the application, if the verification result indicates that the verification is successful, it means that the data in the updated second system partition is accurate and complete, and the data in the updated second system partition is the latest version of the data. Then the updated second system partition can be switched to run in the foreground, and the first system partition that was originally running in the foreground can be moved to run in the background.

[0068] In the solution provided in this application embodiment, the updated data is verified before the system partition is switched. Only when the verification passes is the switch to the foreground allowed, which avoids the risk of system crash due to corrupt or incomplete updated data and ensures device security. In addition, the target verification code is obtained directly from the system update differential packet and belongs to the same source as the updated data, ensuring the accuracy and reliability of the verification result.

[0069] In some embodiments, such as Figure 5 As shown, in Figure 4 Based on the target checksum, the data in the updated second system partition is verified. After obtaining the verification result, the following steps may also be included: 1034. If the verification result indicates that the verification failed, identify whether there is a second data update identifier in the difference bitmap.

[0070] In this embodiment, after verifying the data in the updated second system partition, if the verification result indicates that the verification fails, it means that there is abnormal data in the updated second system partition. Since the data in the updated second system partition includes newly updated data and data that has not been updated, and since the newly updated data is based on the difference bitmap in the newly received system update differential packet, the probability of failure is not high. However, it is possible that the data in the second system partition that has not been updated is abnormal. That is, some data blocks in the source version of the second system partition are abnormal, and the data in these data blocks has not been updated. This abnormal data may cause the verification to fail. Therefore, the data that has not been updated can also be flushed. Then, it is necessary to continue to identify whether there is a second data update identifier in the difference bitmap. The second data update identifier can be used to indicate that the current data block does not need to be updated. The second data update identifier is similar to the first data update identifier, both of which are identifiers carried by data blocks in the difference bitmap. Thus, each data block in the difference bitmap carries a data update identifier, but some data blocks carry a first data update identifier indicating that data updates are needed, and some data blocks carry a second data update identifier indicating that data updates are not needed.

[0071] 1035. If at least one second data update identifier is detected in the difference bitmap, the data block in the second system partition indicated by each second data update identifier is identified as the data block to be refreshed.

[0072] In this embodiment of the application, if at least one second data update identifier is detected in the difference bitmap, it indicates that at least one data block does not need to be updated. That is, at least one data block in the currently updated second system partition still contains data from the source version. This part of the source version data may be abnormal and needs to be refreshed. Then, the data block in the second system partition indicated by each second data update identifier can be identified as the data block to be refreshed. The data block to be refreshed can also be all the data blocks in the second system partition except for at least one data block to be updated. That is, at this time, all the data blocks in the second system partition are divided into two parts: one part is the data block to be updated that has been updated, and the other part is the data block to be refreshed that has not been updated before and now needs to be refreshed.

[0073] 1036. Based on the data in the first system partition, refresh the data blocks to be refreshed.

[0074] In this embodiment, after determining the data blocks to be updated, these data blocks can be updated. Since the data blocks to be updated are data blocks that have not been updated before, that is, data blocks that have not been updated in this target version update, the data in these data blocks is the data of the source version. Since the first system partition and the second system partition are the same and are backups of each other, the data of the source version in the first system partition and the second system partition are the same. At this time, the first system partition has not been updated, so the data blocks to be updated can be updated based on the data in the first system partition.

[0075] In some embodiments, since the first system partition and the second system partition are the same and are backups of each other, the data blocks in the first system partition and the second system partition are also the same. Therefore, the reference data block corresponding to each data block to be refreshed can be determined in the first system partition, and the data block to be refreshed can be refreshed according to the data of this reference data block.

[0076] For example, both the first and second system partitions include five data blocks. The first system partition includes data block 1A, data block 1B, data block 1C, data block 1D, and data block 1E; the second system partition includes data block 2A, data block 2B, data block 2C, data block 2D, and data block 2E. In the second system partition, only data blocks 2A and 2D have been updated to 2AA and 2DD. However, the updated second system partition fails verification, which may be due to anomalies in the data of data blocks 2B, 2C, and 2E. Therefore, data blocks 2B, 2C, and 2E can be identified as data blocks to be refreshed. Data blocks 2B, 2C, and 2E correspond to data blocks 1B, 1C, and 1E in the first system partition, respectively. Further refreshes can be performed on data blocks 2B based on the data of data block 1B, data blocks 2C based on the data of data block 1C, and data blocks 2E based on the data of data block 1E.

[0077] In the solution provided in this application embodiment, when the verification fails, the second data update identifier in the difference bitmap is used to identify which data blocks have not been modified (i.e., should remain consistent with the first system partition). Since the first system partition remains running in the foreground and the data is complete throughout the update process, it can be used as the data source for data replenishment. The corresponding data is obtained from the first system partition for data replenishment, ensuring the correctness of the replenished data and eliminating the need for additional data backup, thus improving the repair efficiency.

[0078] In some embodiments, such as Figure 6 As shown, in Figure 4 Based on the target checksum, the updated second system partition is verified. After obtaining the verification result, the following steps may also be included: 1037. If the verification result indicates that the verification fails, perform a rollback operation on the updated second system partition, and update all data blocks in the rolled-back second system partition based on the data in the first system partition and the difference bitmap.

[0079] In this embodiment, after verifying the data in the updated second system partition, if the verification result indicates that the verification fails, it means that there is abnormal data in the updated second system partition. The previous embodiment described that the abnormality may be in the data of the data blocks that have not been updated. Of course, it is also possible that the abnormality is in the data of the data blocks that have been updated. Specifically, an abnormality may have occurred during the process of updating the data blocks to be updated according to the target data in the difference bitmap. In this case, a rollback operation can be performed on the updated second system partition, that is, the data update operation on each data block to be updated is canceled, and the updated data is rolled back to the source version. At this time, the data in the rolled-back second system partition is the same as the data in the first system partition. Then, based on the data in the first system partition and the difference bitmap, all data blocks in the rolled-back second system partition can be updated. This can be understood as a full write, which means writing all data blocks. Specifically, for the data blocks to be updated, the write is still based on the target data in the difference bitmap, and for other data blocks, the write is based on the data of the corresponding data blocks in the first system partition.

[0080] In the solution provided in this application embodiment, in addition to partial refresh, the second system partition can be restored to the data version before the update through a rollback operation, and then a full update can be performed based on the data and difference bitmap in the intact first system partition, ensuring that the update process will not result in an unrecoverable situation due to data corruption.

[0081] In some embodiments, such as Figure 7 As shown, in Figure 1 Based on the updated data in the second system partition, the data in the first system partition is synchronously updated. This may include the following steps: 1038. Compare the data blocks in the first system partition with the updated data blocks in the second system partition to generate a local difference bitmap.

[0082] In this embodiment, after the second system partition is updated and placed in the foreground, and the first system partition is switched to the background, since the first and second system partitions are identical and independent, serving as backups of each other, it is also necessary to synchronously update the data in the first system partition after updating the second system partition to ensure that both the first and second system partitions have been updated. When updating the first system partition, the corresponding data blocks in the first system partition can be updated based on the data blocks in the updated second system partition. Therefore, it is necessary to compare the data blocks in the first system partition with the updated data blocks in the second system partition to determine which data blocks in the first system partition need to be updated and what data these data blocks have been updated to in the second system partition. This allows for the generation of a local difference bitmap.

[0083] It's important to note that while both the local difference bitmap and the difference bitmap used when updating the second system partition are difference bitmaps, the difference bitmap used for updating the second system partition is received online from the cloud, while the local difference bitmap is generated locally by the electronic device. Furthermore, although theoretically the difference bitmap and the local difference bitmap should contain the same content, the difference bitmap is actually generated by the cloud comparing the source version data and the target version data, while the local difference bitmap is generated by the electronic device comparing the data blocks in the first system partition with the updated data blocks in the second system partition. Additionally, the difference bitmap is used to update the data in the second system partition that was previously running in the background, while the local difference bitmap is used to update the data in the first system partition that is currently running in the background. However, it's clear that both are used to update system partitions running in the background; only system partitions running in the background can undergo data updates.

[0084] 1039. Update the data in the first system partition synchronously according to the local difference bitmap.

[0085] In this embodiment of the application, after obtaining the local difference bitmap, the corresponding data blocks in the first system partition can be synchronously updated according to the data blocks with changes indicated in the local difference bitmap and the specific data. The steps for synchronously updating the data in the first system partition are similar to the process of updating the data blocks in the second system partition mentioned above, and will not be described in detail here.

[0086] In the solution provided in this application embodiment, when updating the first system partition, the data of the two system partitions can be fully compared to generate a local difference bitmap, and then the update can be performed. The entire process can be completed locally on the device, and the full comparison can minimize the problem of data omission and improve the integrity of data synchronization.

[0087] In some embodiments, such as Figure 8 As shown, in Figure 7 Based on the updated data in the second system partition, the data in the first system partition is synchronously updated. This may include the following steps: 10310. Synchronize and update the data in the first system partition according to the updated difference bitmap corresponding to the second system partition.

[0088] In this embodiment of the application, when updating the data in the first system partition, in addition to generating a local difference bitmap in real time, the difference bitmap used when updating the data in the second system partition can also be reused. Since the difference bitmap has been obtained when updating the data in the second system partition, it is equivalent to the difference bitmap being stored in the local memory space of the electronic device and parsed. Therefore, the difference bitmap can be directly retrieved to continue to update the data in the first system partition synchronously. The update process is similar to the process of updating the data blocks in the second system partition, which will not be described in detail here.

[0089] In the solution provided in this application embodiment, the difference bitmap corresponding to the updated second system partition is directly reused to synchronously update the first system partition. There is no need to perform a full data comparison and difference bitmap generation again on the device side, which saves a lot of computing resources and time and improves the efficiency of synchronous update. In addition, both system partitions use the same difference bitmap for updating, which ensures the uniformity of update logic and data synchronization.

[0090] In some embodiments, such as Figure 9 As shown, in Figure 1 Based on this, after synchronizing and updating the data in the first system partition according to the updated data in the second system partition, the following steps may also be included: 104. Compare the updated second system partition and the updated first system partition to obtain the data comparison results.

[0091] In this embodiment, after the first system partition is also updated synchronously, both the second and first system partitions have been updated. Theoretically, the data in the first and second system partitions should be completely identical. However, in real-world scenarios, various factors may lead to different data. Therefore, it is necessary to further compare the data in the updated second and first system partitions. Specifically, the data in the corresponding data blocks in the updated second and first system partitions can be compared to obtain the data comparison result. This data comparison result can include the data comparison result for each data block.

[0092] 105. If the data comparison results indicate that the data is the same, determine that both the first system partition and the second system partition have been updated.

[0093] In this embodiment of the application, if the data comparison result indicates that the data is the same, it means that the data in the first system partition and the second system partition are completely identical and there is no abnormality. Therefore, it can be determined that both the first system partition and the second system partition have been updated.

[0094] In some embodiments, if the data comparison result indicates that there is different data, it means that at least one of the updated second system partition and the updated first system partition has abnormal data. Since the second system partition has been hashed, it can be said that an anomaly occurred when synchronizing data in the first system partition, resulting in abnormal data in the updated first system partition. Therefore, all data blocks in the first system partition can be updated based on the updated data in the second system partition, which is called a full write.

[0095] In some embodiments, after the first system partition has also been updated, the second system partition is still running in the foreground and does not need to be replaced. The first system partition continues to run in the background as a backup partition. When data updates are needed next time, the first system partition running in the background can be updated first, and then the updated first system partition can be switched to the foreground, while the second system partition is placed in the background and updated synchronously. It can be understood that when system partitions need data updates, the system partition running in the background is always updated first, then that system partition is switched to the foreground, and then the other system partition is updated synchronously.

[0096] In the solution provided in this application embodiment, the update is determined to be complete only after the data of the two system partitions is completely consistent by performing a final data comparison between the two system partitions. This provides a clear completion determination condition for the entire update process, which can also ensure that the data of the two system partitions are completely synchronized when the data update starts next time, avoiding the accumulation of errors in incremental updates.

[0097] This application embodiment can divide the data update device into functional modules according to the above method example. For example, each function can be divided into its own functional modules, or two or more functions can be integrated into one processing unit. The integrated modules can be implemented in hardware or as software functional modules. It should be noted that the module division in this application embodiment is illustrative and only represents one logical functional division. In actual implementation, there may be other division methods.

[0098] In addition, such as Figure 10 As shown, Figure 10 This is a schematic diagram of a data update device provided in an embodiment of this application. The data update device includes: The acquisition module 1001 is used to acquire the system update differential packet, which includes at least a difference bitmap. The processing module 1002 is used to determine at least one data block to be updated in the second system partition according to the existence of updated data blocks indicated in the difference bitmap when the first system partition is running in the foreground and the second system partition is running in the background, and to update at least one data block to be updated according to the difference bitmap. The first system partition and the second system partition are backup partitions for each other. The processing module 1002 is also used to switch the updated second system partition to run in the foreground, put the first system partition to run in the background, and synchronize the data in the first system partition according to the data in the updated second system partition.

[0099] In one specific embodiment, the processing module 1002 is specifically used to parse the difference bitmap and identify whether there is a first data update identifier in the difference bitmap. The first data update identifier is used to indicate that the current data block needs to be updated. The processing module 1002 is specifically used to determine the data block in the second system partition indicated by each first data update identifier as the data block to be updated when the difference bitmap is detected to include at least one first data update identifier, thereby obtaining at least one data block to be updated.

[0100] In one specific embodiment, the processing module 1002 is specifically used to update the data block to be updated indicated by each first data update identifier according to the target data corresponding to each first data update identifier in the difference bitmap.

[0101] In one specific embodiment, the processing module 1002 is specifically used to parse the system update differential packet to obtain the target check code; Processing module 1002 is specifically used to verify the data in the updated second system partition based on the target check code, and obtain the verification result; The processing module 1002 is specifically used to switch the updated second system partition to run in the foreground and put the first system partition to run in the background when the verification result indicates that the verification has passed.

[0102] In one specific embodiment, the processing module 1002 is further configured to identify whether a second data update identifier exists in the difference bitmap when the verification result indicates that the verification fails. The second data update identifier is used to indicate that the current data block does not need to be updated. The processing module 1002 is further configured to, when detecting that the difference bitmap includes at least one second data update identifier, determine the data block in the second system partition indicated by each second data update identifier as the data block to be refreshed; The processing module 1002 is also used to refresh the data blocks to be refreshed based on the data in the first system partition.

[0103] In one specific embodiment, the processing module 1002 is further configured to perform a rollback operation on the updated second system partition when the verification result indicates that the verification fails, and update all data blocks in the rolled-back second system partition based on the data and difference bitmap in the first system partition.

[0104] In one specific embodiment, the processing module 1002 is specifically used to compare the data blocks in the first system partition and the updated data blocks in the second system partition respectively, and generate a local difference bitmap; The processing module 1002 is specifically used to synchronously update the data in the first system partition according to the local difference bitmap.

[0105] In one specific embodiment, the processing module 1002 is specifically used to synchronously update the data in the first system partition according to the difference bitmap corresponding to the updated second system partition.

[0106] In one specific embodiment, the processing module 1002 is further configured to compare the updated second system partition and the updated first system partition to obtain a data comparison result; The processing module 1002 is also used to determine that both the first system partition and the second system partition have been updated when the data comparison result indicates that the data is the same.

[0107] Regarding the apparatus in the above embodiments, the specific manner in which each unit performs its operation has been described in detail in the embodiments related to the method, and will not be elaborated upon here.

[0108] Figure 11 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. For example, as shown... Figure 11 As shown, the electronic device includes a memory 1101 and a processor 1102. The memory 1101 stores executable program code 11011, and the processor 1102 is used to call and execute the executable program code 11011 to perform a data update method.

[0109] This embodiment can divide the electronic device into functional modules according to the above method example. For example, each module can correspond to a separate functional module, or two or more functions can be integrated into one processing module. The integrated module can be implemented in hardware. It should be noted that the module division in this embodiment is illustrative and only represents one logical functional division. In actual implementation, there may be other division methods.

[0110] When each functional module is divided according to its corresponding function, the electronic device may include: an acquisition module, a determination module, etc. It should be noted that all relevant content of each step involved in the above method embodiments can be referenced from the functional description of the corresponding functional module, and will not be repeated here.

[0111] The electronic device provided in this embodiment is used to execute the above-described data update method, and thus can achieve the same effect as the above-described implementation method.

[0112] When using integrated units, the electronic device may include a processing module and a storage module. The processing module is used to control and manage the operation of the electronic device. The storage module is used to support the execution of program code and data by the electronic device.

[0113] The processing module may be a processor or a controller, which can implement or execute various exemplary logic blocks, modules, and circuits as described in the embodiments of this application. The processor may also be a combination of computing functions, such as a combination of one or more microprocessors, a combination of digital signal processing (DSP) and a microprocessor, etc., and the storage module may be a memory.

[0114] This embodiment also provides a computer-readable storage medium (including but not limited to disk storage, compact disc read-only memory (CD-ROM), optical storage, etc.) storing computer program code. When the computer program code is run on a computer, the computer executes the above-mentioned related method steps to implement a data update method provided in the above embodiment.

[0115] This embodiment also provides a computer program product that, when run on a computer, causes the computer to perform the aforementioned steps to implement a data update method provided in the above embodiment.

[0116] The beneficial effects of the above embodiments can be referred to the beneficial effects of the corresponding methods provided above, and will not be repeated here.

[0117] Through the above description of the embodiments, those skilled in the art will understand that, for the sake of convenience and brevity, 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.

[0118] In the embodiments provided in this application, it should be understood that the disclosed apparatus and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of modules or units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another device, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection between devices or units may be electrical, mechanical, or other forms.

[0119] In the description of this application, it should be understood that if the terms "upper", "lower", "front", "rear", "left" and "right" are used to indicate the orientation or positional relationship based on the orientation or positional relationship shown in the drawings, they are only for the convenience of describing the present invention and simplifying the description, and do not indicate or imply that the position or element referred to must have a specific orientation, or be constructed and operated in a specific orientation, and therefore should not be construed as a limitation of this application.

[0120] It should be noted that, in this document, relational terms such as "first" and "second" are used only to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. It should also be noted that the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such process, method, article, or apparatus. Unless otherwise specified, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes the element.

[0121] The above are merely embodiments of this application and are not intended to limit the scope of this application. Various modifications and variations can be made to this application by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the scope of the claims of this application.

Claims

1. A data update method, characterized in that, The method includes: Obtain a system update differential packet, wherein the system update differential packet includes at least a difference bitmap; When the first system partition is running in the foreground and the second system partition is running in the background, at least one data block to be updated in the second system partition is determined according to the data block to be updated indicated in the difference bitmap, and the at least one data block to be updated is updated according to the difference bitmap, wherein the first system partition and the second system partition are backup partitions for each other; The updated second system partition is switched to run in the foreground, the first system partition is run in the background, and the data in the first system partition is synchronously updated according to the data in the updated second system partition.

2. The data update method according to claim 1, characterized in that, The step of determining at least one data block to be updated in the second system partition based on the presence of updated data blocks indicated in the difference bitmap includes: The difference bitmap is parsed to identify whether a first data update identifier exists in the difference bitmap. The first data update identifier is used to indicate that the current data block needs to be updated. If the difference bitmap is detected to include at least one first data update identifier, the data block in the second system partition indicated by each first data update identifier is determined as the data block to be updated, thus obtaining the at least one data block to be updated.

3. The data update method according to claim 2, characterized in that, The step of updating the at least one data block to be updated according to the difference bitmap includes: According to the target data corresponding to each first data update identifier in the difference bitmap, the data block to be updated indicated by each first data update identifier is updated.

4. The data update method according to claim 1, characterized in that, The step of switching the updated second system partition to run in the foreground and placing the first system partition to run in the background includes: The system update differential packet is parsed to obtain the target checksum; Based on the target check code, the data in the updated second system partition is verified to obtain the verification result; If the verification result indicates that the verification is successful, the updated second system partition is switched to run in the foreground, and the first system partition is placed to run in the background.

5. The data update method according to claim 4, characterized in that, After verifying the data in the updated second system partition based on the target checksum and obtaining the verification result, the method further includes: If the verification result indicates that the verification fails, identify whether there is a second data update identifier in the difference bitmap. The second data update identifier is used to indicate that the current data block does not need to be updated. If at least one second data update identifier is detected in the difference bitmap, the data block in the second system partition indicated by each second data update identifier is identified as the data block to be refreshed; Based on the data in the first system partition, the data block to be refreshed is refreshed.

6. The data update method according to claim 4, characterized in that, After verifying the updated second system partition based on the target checksum and obtaining the verification result, the method further includes: If the verification result indicates that the verification fails, a rollback operation is performed on the updated second system partition, and all data blocks in the rolled-back second system partition are updated based on the data in the first system partition and the difference bitmap.

7. The data update method according to claim 1, characterized in that, The step of synchronizing and updating the data in the first system partition according to the updated data in the second system partition includes: The data blocks in the first system partition and the updated data blocks in the second system partition are compared respectively to generate a local difference bitmap; The data in the first system partition is synchronously updated according to the local difference bitmap.

8. The data update method according to claim 1, characterized in that, The step of synchronizing and updating the data in the first system partition according to the updated data in the second system partition includes: The data in the first system partition is synchronously updated according to the difference bitmap corresponding to the updated second system partition.

9. The data update method according to claim 1, characterized in that, After synchronizing and updating the data in the first system partition according to the updated data in the second system partition, the method further includes: The updated second system partition and the updated first system partition are compared to obtain the data comparison results; If the data comparison results indicate that the data is the same, it is determined that both the first system partition and the second system partition have been updated.

10. An electronic device, characterized in that, include: A memory and a processor, wherein the memory stores executable program code, and the processor is configured to call and execute the executable program code to perform the data update method as described in any one of claims 1 to 9.

Images