Recovery mode repair method based on merging upgrade package and electronic device

Abstract

This invention provides a recovery mode repair method and electronic device based on a merged upgrade package. The method includes: obtaining a merged upgrade package, which contains a recovery mode firmware image file as a component; after entering the system firmware in normal mode, monitoring the number of recovery mode boot anomalies; and if the number of boot anomalies exceeds a threshold, determining that the recovery mode firmware is corrupted, and extracting the recovery mode firmware image file from the merged upgrade package to repair the recovery mode firmware partition based on the recovery mode firmware image file. This invention achieves autonomous repair of the recovery mode firmware, avoiding repeated device restarts and improving reliability and maintainability.

Description

Technical Field

[0001] This invention relates to the field of embedded technology, and more particularly to a recovery mode repair method and electronic device based on merged upgrade packages. Background Technology

[0002] Currently, firmware upgrades for Android devices typically rely on recovery mode. The device boots into recovery mode by setting an upgrade flag, where the recovery mode firmware verifies the upgrade package and updates the system partition. However, this technology has the following drawbacks: The recovery mode firmware, being a separate partition, may fail to boot due to data errors or accidental damage. Once damaged, the device will be unable to enter recovery mode to perform the upgrade, resulting in a "cannot upgrade, cannot recover" predicament that ordinary users cannot repair themselves. Furthermore, traditional upgrade packages only contain the Android system firmware and not the recovery mode firmware, making it impossible to repair a damaged recovery mode via OTA (Over-The-Air). Summary of the Invention

[0003] The technical problem to be solved by the present invention is to provide a recovery mode repair method and electronic device based on merged upgrade packages, which can automatically complete firmware repair and system upgrade when the recovery mode firmware is damaged, thus solving the problem of devices being unable to be upgraded or becoming bricked due to recovery mode firmware damage in traditional upgrade solutions.

[0004] In one aspect of the present invention, a recovery mode repair method based on a merged upgrade package is provided. The method includes: obtaining a merged upgrade package, the merged upgrade package including a recovery mode firmware image file as a component; after entering the system firmware in normal mode, monitoring the number of recovery mode boot anomalies; and if the number of boot anomalies exceeds a threshold, determining that the recovery mode firmware is corrupted, and extracting the recovery mode firmware image file from the merged upgrade package to repair the recovery mode firmware partition based on the recovery mode firmware image file.

[0005] In another aspect of the invention, an electronic device is provided. The electronic device includes: a memory configured to store an executable program; and a processor configured to execute the program to perform the aforementioned recovery mode repair and upgrade method based on a merged upgrade package.

[0006] The beneficial effects of this invention are as follows: By acquiring a merged upgrade package, which includes a recovery mode firmware image file as a component, this invention achieves unified packaging and distribution of the recovery mode firmware and the system firmware. This differs from the technical limitation of traditional upgrade packages that only contain system firmware and cannot repair the recovery mode, thus laying a material foundation for subsequent repairs. After entering the system firmware in normal mode, the number of recovery mode boot anomalies is monitored. When the number of boot anomalies exceeds a threshold, the recovery mode firmware is determined to be corrupted. This differs from traditional solutions that get stuck in a dead loop of repeated restarts when the recovery mode is corrupted. This solution actively monitors and detects recovery mode corruption while the system firmware is running, effectively avoiding the device from falling into a boot failure state, ensuring basic system accessibility, and providing an operating environment for subsequent repairs. Based on the determination of recovery mode firmware corruption, a merged upgrade package is acquired, and the recovery mode firmware image file is extracted from the merged upgrade package. The recovery mode firmware partition is repaired based on the recovery mode firmware image file, enabling the device to autonomously repair the recovery mode under a normal operating system environment without the need for professional flashing tools or repair personnel, reducing the device's maintenance costs and complexity. Attached Figure Description

[0007] Figure 1 This is a flowchart of a recovery mode repair method based on a merged upgrade package according to an embodiment of the present invention; Figure 2 This is a flowchart illustrating the monitoring and repair triggering process in the recovery mode repair method based on the merged upgrade package according to an embodiment of the present invention. Figure 3 This is a flowchart illustrating the process of obtaining, verifying, and repairing the merged upgrade package in the recovery mode repair method based on the merged upgrade package according to an embodiment of the present invention. Figure 4 This is a schematic diagram of the structure of an electronic device according to an embodiment of the present invention. Detailed Implementation

[0008] To explain in detail the technical content, objectives, and effects of the present invention, the following description is provided in conjunction with the embodiments and accompanying drawings.

[0009] In existing technologies, common firmware upgrade solutions are as follows: the firmware upgrade package only contains system firmware. Once the recovery mode firmware is damaged, the device will be unable to enter recovery mode to perform the upgrade operation, resulting in upgrade failure and a vicious cycle of repeated restarts, ultimately bricking the device.

[0010] To address at least the aforementioned technical problems, this disclosure provides a recovery mode repair method based on a merged upgrade package. According to this disclosure, by including the recovery mode firmware image file as a component of the merged upgrade package, the number of recovery mode boot anomalies is monitored in normal mode. When the number of boot anomalies exceeds a threshold, the recovery mode firmware is determined to be corrupted. The merged upgrade package is then obtained, and the recovery mode firmware image is extracted to repair the recovery mode partition, thus achieving autonomous repair of the recovery mode firmware. In this way, embodiments of this disclosure can automatically complete repair when the recovery mode firmware is corrupted, effectively avoiding device bricking caused by recovery mode firmware corruption, ensuring reliable execution of the firmware upgrade process, and improving device stability and maintainability.

[0011] In the following, the technical solutions according to this disclosure will be described with reference to specific embodiments and in conjunction with the accompanying drawings.

[0012] Figure 1 This is a flowchart illustrating a recovery mode repair method 100 based on a merged upgrade package according to an embodiment of the present disclosure. (Refer to...) Figure 1 The method 100 includes the following steps S102 to S106.

[0013] In S102, the merged upgrade package is obtained, which includes a recovery mode firmware image file as a component.

[0014] In some embodiments, obtaining the merged upgrade package includes: receiving the merged upgrade package from a firmware upgrade server; reading merged upgrade package metadata from a boot communication partition, the merged upgrade package metadata including the decompression path of the merged upgrade package and a recovery mode firmware digital digest; checking whether the recovery mode firmware image file exists under the decompression path of the merged upgrade package; if it exists, calculating the digital digest of the recovery mode firmware image file and comparing it with the recovery mode firmware digital digest; and if it does not exist, decompressing the merged upgrade package to the decompression path to obtain the recovery mode firmware image file.

[0015] In this way, by reading the merged upgrade package metadata persistently stored in the boot communication partition, the system first checks whether a usable recovery mode firmware image file exists in the local decompression path, and performs digital digest comparison on existing image files to ensure their integrity and correctness. When a recovery mode firmware image file does not exist locally or the digest comparison is inconsistent, the system automatically downloads the merged upgrade package from the firmware upgrade server and decompresses it for use, avoiding the waste of network resources caused by repeated downloads.

[0016] In some embodiments, the method 100 may further include: compressing and packaging the system firmware upgrade package and the recovery mode firmware image file according to a preset compression and packaging format to generate the merged upgrade package, and storing the merged upgrade package public key in the merged upgrade package; signing the merged upgrade package using the upgrade package private key corresponding to the merged upgrade package public key; and placing the signed merged upgrade package in a firmware upgrade server.

[0017] This approach introduces a public-private key signature mechanism during the merged upgrade package generation stage. The recovery mode firmware image file and the system firmware upgrade package are packaged together and digitally signed, enabling unified distribution and management of the recovery mode firmware and system firmware within the same package. By pre-setting the upgrade package's public key in the merged upgrade package, a verification basis is provided for subsequent signature verification of the merged package on the device side. Using the private key to sign the merged upgrade package ensures its integrity and source credibility during transmission and storage, preventing tampering or forgery.

[0018] In some embodiments, the method 100 may further include: if a recovery signal requiring entry into recovery mode is detected, obtaining recovery mode exit metadata from the boot communication partition, the recovery signal including a factory reset command or an upgrade command; determining whether the number of boot anomalies in the recovery mode exit metadata exceeds a preset threshold; and if the threshold is exceeded, determining that recovery mode cannot be entered, clearing the recovery signal, and entering the system firmware.

[0019] In this way, before responding to factory reset or upgrade commands, the system proactively reads the persistently stored recovery mode exit metadata in the boot communication partition, obtains the historical number of boot anomalies, and compares it with a preset threshold in real time. When the number of boot anomalies exceeds the threshold, the system proactively determines that the recovery mode firmware is corrupted and unusable, then clears the recovery signal and forces boot into the system firmware, avoiding attempts to boot into the corrupted recovery mode. By advancing the exposure of corrupted recovery mode firmware from the boot execution stage to the signal processing stage, risk identification and interception are completed before operations that could cause system crashes are executed. This effectively prevents the device from repeatedly restarting or deadlocking due to attempts to enter a corrupted recovery mode, ensuring that the device always remains in a safe and operational state, preserving system activity for subsequent repair operations in the system firmware.

[0020] In S104, after entering the system firmware in normal mode, the number of abnormal boot attempts in recovery mode is monitored.

[0021] In some embodiments, after entering the system firmware in normal mode, monitoring the number of boot anomalies in recovery mode includes: reading recovery mode exit metadata from the boot communication partition, wherein the recovery mode exit metadata includes verification information for identifying validity and the number of boot anomalies; when the verification information meets a preset condition, obtaining the number of boot anomalies in the recovery mode exit metadata; comparing the number of boot anomalies with a preset maximum boot count threshold; and if the threshold is exceeded, determining that the recovery mode firmware is corrupted.

[0022] In this way, by reading the recovery mode exit metadata persistently stored in the boot communication partition, the system obtains the historical number of boot anomalies and compares this number with a preset threshold in real time. When the number of boot anomalies exceeds the threshold, the system proactively determines that the recovery mode firmware is corrupted, thus completing an accurate assessment of the recovery mode firmware's health status before attempting to enter recovery mode. This mechanism advances the detection of recovery mode firmware corruption from the boot stage to the system runtime stage, preventing the device from falling into a crash deadlock state due to directly attempting to enter a corrupted recovery mode, while providing a reliable basis for triggering subsequent repair processes.

[0023] In S106, if the number of boot errors exceeds the threshold, the recovery mode firmware is determined to be corrupted, and the recovery mode firmware image file is extracted from the merged upgrade package to repair the recovery mode firmware partition based on the recovery mode firmware image file.

[0024] In some embodiments, before determining that the recovery mode firmware is corrupted, obtaining the merged upgrade package, and extracting the recovery mode firmware image file from the merged upgrade package, the method further includes: reading the merged upgrade package metadata from the boot communication partition, the merged upgrade package metadata including the merged upgrade package path, the merged upgrade package decompression path, and the recovery mode firmware digital digest; checking whether the recovery mode firmware image file exists under the merged upgrade package decompression path; if it exists, calculating the digital digest value of the recovery mode firmware image file under the merged upgrade package decompression path and comparing it with the recovery mode firmware digital digest; if the comparison result is consistent, directly using the locally existing recovery mode firmware image file for repair; and if the recovery mode firmware image file does not exist under the merged upgrade package decompression path, or the calculated digital digest value is inconsistent with the recovery mode firmware digital digest, then performing the step of obtaining the merged upgrade package from the firmware upgrade server.

[0025] In this way, before triggering the merged upgrade package retrieval process, the system reads the merged upgrade package metadata persistently stored in the boot communication partition. It first checks if a usable recovery mode firmware image file already exists in the local decompression path and performs a digital digest comparison on the existing recovery mode firmware image file to verify its integrity and correctness. When the image exists locally and the digest matches, the system directly reuses the locally cached image for repair, avoiding the network resource consumption and time delay caused by repeatedly downloading the merged upgrade package from the server. When the recovery mode firmware image file does not exist locally or the digest comparison is inconsistent, the system then executes the step of retrieving the merged upgrade package from the server. This local caching priority strategy improves repair efficiency, while the dual digital digest verification ensures the integrity and reliability of the recovery mode firmware image file used for repair.

[0026] In some embodiments, after obtaining the merged upgrade package from the firmware upgrade server, the method further includes: decompressing the obtained merged upgrade package to a preset path to obtain a system firmware upgrade package and the recovery mode firmware image file; calculating the digital digest of the recovery mode firmware image file and comparing it with the recovery mode firmware digital digest in the metadata of the merged upgrade package; if the comparison result is consistent, then using the recovery mode firmware image file for repair; and if the comparison result is inconsistent, then obtaining the merged upgrade package again from the firmware upgrade server.

[0027] In this manner, the system decompresses the downloaded merged upgrade package and performs a digital digest calculation on the resulting recovery mode firmware image file. The calculated result is then compared with the recovery mode firmware digital digest pre-stored in the merged upgrade package's metadata. If the digests match, it confirms that the image file was not damaged or tampered with during download and decompression, and it can then be used. If the digests do not match, the system proactively determines that the recovery mode firmware image file is abnormal and triggers a re-download process. By adding integrity verification before repair, the system effectively prevents the misuse of damaged images caused by network transmission errors, abnormal storage media, or malicious tampering, ensuring the absolute integrity and reliability of the recovery mode firmware image file used for repair, thus providing a guarantee for reliable repair of the recovery mode firmware.

[0028] In some embodiments, repair using the recovery mode firmware image file includes: writing the recovery mode firmware image file into the block device node file corresponding to the recovery mode firmware; reading back the written data from the block device node file; performing a binary comparison between the read-back data and the recovery mode firmware image file; if the comparison result is consistent, confirming that the recovery mode firmware repair is successful; and if the comparison result is inconsistent, re-performing the operation of writing the recovery mode firmware image file into the block device node file until the data of the two are completely consistent.

[0029] In this way, immediately after writing the recovery mode firmware image file, the system reads back the written data from the device node file and performs a byte-by-byte binary comparison with the original image file. When the read-back data is completely consistent with the original image, the system confirms the repair operation is successful; when an inconsistency is found, the system automatically triggers a rewrite operation and retries repeatedly until the written data is completely correct. Through immediate verification and automatic retry after writing, write errors caused by bad blocks on the storage medium, write interference, or hardware malfunctions are effectively eliminated, ensuring that the recovery mode firmware partition is strictly consistent with the original image. This fundamentally guarantees the integrity and reliability of the recovery mode firmware repair and avoids the risk of secondary damage due to incomplete or inaccurate writing.

[0030] In some embodiments, before writing the recovery mode firmware image file to the block device node file corresponding to the recovery mode firmware, the method further includes: obtaining the size of the recovery mode firmware partition and the size of the recovery mode firmware image file; and terminating the repair operation if the size of the recovery mode firmware partition is smaller than the size of the recovery mode firmware image file.

[0031] In this way, the system first obtains the physical capacity of the recovery mode firmware partition and the size of the image file to be written, and compares the two. When it detects that the partition capacity is insufficient to hold the complete image file, the system actively terminates the repair operation to avoid incomplete writing or writing failure due to insufficient space. By performing capacity compatibility verification before writing, abnormal situations such as partial writing, data truncation, or write overflow caused by insufficient partition space are effectively prevented, avoiding the risk of secondary damage caused by the repair operation itself, and ensuring the standardized execution of the repair process and the reasonable use of system storage space.

[0032] In some embodiments, repairing the recovery mode firmware partition based on the recovery mode firmware image file includes: resetting the recovery mode boot count in the recovery mode exit metadata to an initial value and writing it back to the boot communication partition; checking whether a system firmware upgrade package exists in the decompression path of the merged upgrade package; if it exists, performing signature verification on the system firmware upgrade package; after successful verification, writing the upgrade command and the path of the system firmware upgrade package into the boot communication partition; and restarting the device to enter recovery mode and perform the firmware upgrade operation.

[0033] In this way, after the recovery mode firmware repair is completed, the system first resets the number of boot anomalies in the recovery mode exit metadata to its initial value and stores it continuously, clearing historically accumulated anomaly records and establishing a new health baseline for the recovery mode firmware. Subsequently, the system checks if a usable system firmware upgrade package exists in the local decompression path and performs signature verification on the firmware upgrade package to verify its integrity and source credibility. After successful verification, the system writes the upgrade command and the merged upgrade package path to the boot communication partition and triggers a device reboot, automatically entering recovery mode to perform the upgrade operation. This achieves seamless integration from recovery mode repair to system firmware upgrade. Ensuring the recovery mode firmware has returned to a healthy state, it automatically triggers subsequent upgrade processes, forming an integrated closed loop of repair and upgrade, avoiding manual user intervention, and improving the automation level of firmware upgrades and user experience.

[0034] In some embodiments, entering recovery mode to perform a firmware upgrade operation includes: in recovery mode, using the upgrade package public key preset in the recovery mode firmware to sign and verify the system firmware upgrade package; after successful verification, performing the firmware upgrade operation according to a preset upgrade process; and after the upgrade is completed, clearing the upgrade instructions in the boot communication partition, exiting recovery mode, and restarting the device.

[0035] In this way, after the device enters recovery mode, it first uses the public key of the upgrade package pre-installed in the recovery mode firmware to sign and verify the system firmware upgrade package, ensuring that the merged upgrade package has not been tampered with or damaged during transmission and storage. After successful verification, the system performs the firmware upgrade operation according to the preset upgrade process. After the upgrade is completed, the system automatically clears the upgrade instructions from the boot communication partition to prevent residual upgrade instructions from causing duplicate upgrades or abnormal boots, and then exits recovery mode to restart the device, allowing the device to start normally with a brand-new firmware version. Through the secondary sign-in verification in recovery mode, a trusted execution environment independent of the system firmware is provided for firmware upgrades, ensuring the security of the upgrade operation.

[0036] In some embodiments, the method 100 may further include: after the device enters recovery mode, reading recovery mode exit metadata from the boot communication partition, the recovery mode exit metadata including verification information for identifying validity and the number of boot anomalies; if the verification information satisfies the verification information, setting the number of boot anomalies to an initial value; if the verification information does not satisfy the verification information, setting the verification information to a valid state and setting the number of boot anomalies to an initial value; and writing the updated recovery mode exit metadata back to the boot communication partition.

[0037] In this way, a recovery mode exit metadata reset mechanism is introduced after the device successfully enters recovery mode. The system performs unified initialization processing on the verification information and boot anomaly count in the recovery mode exit metadata. Regardless of whether the verification information is valid, the system resets the boot anomaly count to its initial value and synchronously restores its valid state when the verification information is invalid. Finally, the updated recovery mode exit metadata is persistently written back to the boot communication partition. This mechanism promptly clears historically accumulated boot anomaly records when recovery mode can be entered normally, avoiding false judgments triggered by the continuous accumulation of historical anomaly counts. At the same time, by repairing invalid verification information, it ensures the structural integrity and readability of the recovery mode exit metadata. Through this reset mechanism, the system achieves dynamic maintenance of the recovery mode health status record, providing a clean initial state for accurate monitoring of the next recovery mode boot anomaly count, effectively improving the accuracy and reliability of recovery mode health status assessment.

[0038] The following section will describe, through examples, the application scenarios of the monitoring and repair triggering process in the recovery mode repair method based on the merged upgrade package according to embodiments of the present invention.

[0039] Figure 2 This is a flowchart illustrating the monitoring and repair triggering process according to an embodiment of the present invention. It includes the following steps S201 to S215.

[0040] S201, The device boots up and enters the system firmware.

[0041] In some embodiments, after the device is powered on or restarted, the processor executes the bootloader firmware, which guides the system firmware to boot normally and enter the operating system. After the system boots up, the firmware upgrade service runs automatically as a system-level background service, responsible for monitoring the health status of the recovery mode firmware and firmware upgrade requirements, and preparing the runtime environment for subsequent recovery mode firmware corruption determination and self-repair process.

[0042] S202, Monitor the number of abnormal boot attempts in recovery mode.

[0043] In some embodiments, the firmware upgrade service continuously monitors the health status of the recovery mode firmware in the background. The monitoring mechanism reads recovery mode exit metadata from the boot communication partition periodically or through event triggering to obtain the historical number of boot anomalies, which serves as the core basis for assessing whether the recovery mode firmware is corrupted.

[0044] S203. Read recovery mode exit metadata from the boot communication partition.

[0045] In some embodiments, the firmware upgrade service accesses a preset storage location in the boot communication partition (such as the misc partition) used to store recovery mode exit metadata, and reads the recovery mode exit metadata. This metadata is a data structure persistently stored across boot cycles, containing two core fields: one is verification information (such as a preset magic number) used to identify data validity, distinguishing between initialized and uninitialized metadata; the other is a boot anomaly count field used to record the number of historical boot attempt failures. This field cumulatively records the number of times the device has continuously attempted to enter recovery mode but failed, and is a core indicator for evaluating the health status of the recovery mode firmware.

[0046] S204. Determine whether the verification information meets the preset conditions.

[0047] In some embodiments, the firmware upgrade service checks the verification information in the read recovery mode exit metadata and compares it with a preset valid value to confirm the validity and completeness of the metadata.

[0048] If the verification information meets the preset conditions and is consistent with the preset value, it indicates that the metadata structure is complete and the data is valid. The process then proceeds to S206 to obtain the number of guidance exceptions and make subsequent judgments.

[0049] If the verification information does not meet the preset conditions and is inconsistent with the preset value, it indicates that the metadata has not been initialized or the data is corrupted due to storage abnormalities and cannot be used directly. The process then enters S205 to perform the initialization operation.

[0050] S205. Initialize recovery mode exit metadata, set verification information to be valid, and set boot count to 0.

[0051] In some embodiments, when the verification information does not meet preset conditions, the firmware upgrade service performs an initialization operation on the recovery mode exit metadata. Specifically, this includes: setting the verification information to a preset valid state value to ensure correct identification during subsequent readings; and setting the boot failure count to an initial value of 0, indicating that there are no historical boot failure records. After initialization, the process proceeds to S206 to obtain the initialized boot failure count (i.e., 0). This operation ensures that the recovery mode exit metadata is always in a parseable and usable standard state, establishing a unified benchmark for subsequent health status assessments.

[0052] S206. Obtain the number of boot errors in the recovery mode exit metadata.

[0053] In some embodiments, the firmware upgrade service obtains the value of the boot error count field from the recovery mode exit metadata and prepares to compare it with a preset threshold.

[0054] S207. Determine whether the number of times the guidance error has exceeded the preset threshold.

[0055] In some embodiments, the firmware upgrade service compares the number of boot failures obtained with a preset maximum boot count threshold in the system (configurable according to product policy, such as 6 times). This threshold represents the maximum number of consecutive boot failures the system can tolerate; exceeding this threshold indicates that the recovery mode firmware has suffered irreversible physical or logical damage.

[0056] If the number of boot failures exceeds a preset threshold, the recovery mode firmware is determined to be corrupted, and the process enters S208.

[0057] If the number of boot failures does not exceed the preset threshold, the recovery mode firmware is determined to be normal, and the process proceeds to S209.

[0058] S208, The firmware in recovery mode is determined to be corrupted.

[0059] In some embodiments, based on the determination result of S207, the firmware upgrade service confirms that the recovery mode firmware has been corrupted and cannot boot normally. The process then proceeds to the subsequent recovery signal processing and repair triggering process.

[0060] S209. The recovery mode firmware is determined to be normal. Continue normal operation.

[0061] In some embodiments, based on the judgment result of S207, the firmware upgrade service confirms that the current state of the recovery mode firmware is normal or the number of boot anomalies has not reached the damage threshold, thus meeting the conditions for entering recovery mode to perform operations. The device continues to operate in normal mode, and the firmware upgrade service waits for the next detection cycle or user trigger.

[0062] S210, Has a recovery signal been detected?

[0063] In some embodiments, the firmware upgrade service monitors in real time for the presence of recovery signals that require guiding the device into recovery mode. These recovery signals fall into two categories: user-triggered factory reset commands and upgrade commands generated by the system upon detecting a new firmware version. Both types of signals require guiding the device into recovery mode to execute specific operations.

[0064] If a recovery signal is detected, the process proceeds to S211.

[0065] If no recovery signal is detected, return to S202 and continue monitoring the number of times recovery mode boot anomalies occur.

[0066] S211, Clear recovery signal and enter system firmware.

[0067] In some embodiments, when a recovery signal is detected while the recovery mode is corrupted, to prevent the device from attempting to enter the corrupted recovery mode and causing a system crash and a deadlock state from which it cannot exit (i.e., the device becomes bricked), the firmware upgrade service performs the following operations: clears the currently detected recovery signal, whether it is a factory reset command or an upgrade command, to prevent the system from repeatedly attempting to execute the signal and getting stuck in an invalid loop; and allows the device to continue running in the current system firmware without performing any operations to boot into recovery mode. This mechanism, through pre-emptive health status detection before the recovery signal is executed, proactively intercepts risky operations that could brick the device, ensuring that the device is always in a safe and operable state, preserving system activity for subsequent recovery mode repair in the system firmware. The process proceeds to S212.

[0068] S212. Obtain the merged upgrade package.

[0069] In some embodiments, the firmware upgrade service initiates a process to obtain a merged upgrade package based on the determination that the recovery mode firmware is corrupted. The merged upgrade package is pre-installed on the firmware upgrade server and includes a standard firmware upgrade package and a recovery mode firmware image file. The specific process for obtaining the merged upgrade package includes: reading the merged package metadata from the boot communication partition; checking whether a usable recovery mode firmware image file already exists in the local decompression path; if it does not exist or the digest verification is inconsistent, downloading the merged upgrade package from the firmware upgrade server, and performing signature verification and digest comparison to ensure the integrity and reliable source of the image file used for repair.

[0070] S213. Extract the recovery mode firmware image file from the merged upgrade package.

[0071] In some embodiments, the firmware upgrade service decompresses the obtained merged upgrade package to a preset path to obtain a standard firmware upgrade package and a recovery mode firmware image file, preparing repair materials for subsequent repair operations.

[0072] S214. Repair the recovery mode firmware partition.

[0073] In some embodiments, the firmware upgrade service uses the extracted recovery mode firmware image file to repair the recovery mode firmware partition. The repair process includes: checking whether the recovery mode firmware partition has sufficient capacity to accommodate the image file; writing the image file to the block device node file corresponding to the recovery mode firmware; reading back the written data from the block device node file and performing a binary comparison with the original image file; if the comparison results match, the repair is confirmed to be successful; if they do not match, the write operation is re-executed until the data is completely consistent, ensuring the integrity and reliability of the repair.

[0074] S215. Reset the number of boot attempts in the recovery mode exit metadata to the initial value and proceed to the repair and upgrade process.

[0075] In some embodiments, after successful recovery mode firmware repair, the firmware upgrade service updates the recovery mode exit metadata: resetting the boot anomaly count field to its initial value of 0, writing the updated metadata back to the boot communication partition, clearing historically accumulated anomaly records, and establishing a new health baseline for the recovery mode firmware. Subsequently, the process transitions to the post-repair upgrade process, checking whether a standard firmware upgrade package is available locally. If it exists, the firmware upgrade operation is triggered, achieving a seamless transition from recovery mode repair to system firmware upgrade.

[0076] The following will describe, through examples, the application scenarios of the merged upgrade package acquisition, verification, and repair process in the recovery mode repair method based on the merged upgrade package according to embodiments of the present invention.

[0077] Figure 3 This is a flowchart illustrating the process of obtaining, verifying, and repairing the merged upgrade package in the recovery mode repair method based on the merged upgrade package according to an embodiment of the present invention. It includes the following steps S301 to S323.

[0078] S301. Start obtaining the merged upgrade package.

[0079] In some embodiments, when the firmware upgrade service determines that the recovery mode firmware is corrupted and needs to be repaired, a merged upgrade package acquisition process is initiated. The merged upgrade package is pre-installed in the firmware upgrade server and contains a standard firmware upgrade package and a recovery mode firmware image file, serving as the material source for repairing the recovery mode firmware.

[0080] S302. Read merged upgrade packet information from the boot communication partition.

[0081] In some embodiments, the firmware upgrade service accesses a preset storage location in the boot communication partition (such as the misc partition) used to store the merged upgrade package metadata, and reads the merged upgrade package metadata. This metadata is a data structure persistently stored after the device has successfully obtained the merged upgrade package, used to record relevant information about the merged upgrade package to avoid repeated downloads and verify the integrity of locally existing files.

[0082] S303, the merged upgrade package information includes: decompression path, recovery mode firmware digital digest.

[0083] In some embodiments, the merged upgrade package metadata includes two core fields: one is the decompression path field, which records the storage path used when decompressing the merged upgrade package, used to locate the recovery mode firmware image file that may already exist locally; the other is the recovery mode firmware digital digest field, which stores the hash value (such as SHA256) of the recovery mode firmware image file, used for subsequent integrity verification of the image file to ensure that it has not been tampered with or damaged.

[0084] S304. Check if a recovery mode firmware image file exists in the decompression path.

[0085] In some embodiments, the firmware upgrade service checks whether a recovery mode firmware image file already exists at the decompression path in the merged upgrade package metadata.

[0086] If it exists, the process proceeds to S305 to perform integrity verification on the existing local image file.

[0087] If it does not exist, it means that a usable recovery mode firmware image file has not been cached locally, and the process directly proceeds to S308 to download the merged upgrade package from the firmware upgrade server.

[0088] S305. Calculate the digital digest of the local image file.

[0089] In some embodiments, when a recovery mode firmware image file exists in the decompression path, the firmware upgrade service uses a preset algorithm consistent with the algorithm used when generating the merged upgrade package to calculate the digital digest value of the local image file, in preparation for subsequent comparison with the digest stored in the metadata.

[0090] S306. Whether the digital digest is consistent with the merged and upgraded package element information.

[0091] In some embodiments, the firmware upgrade service compares the calculated digital digest of the local image file with the digital digest of the recovery mode firmware stored in the merged upgrade package metadata.

[0092] If the two are consistent, it indicates that the local image file is complete and has not been tampered with. The process then proceeds to S314, where the local image file is used directly for repair, avoiding repeated downloads.

[0093] If the two are inconsistent, it indicates that the local image file has been damaged or tampered with and cannot be used for repair. The process then proceeds to S308, where the merged upgrade package is downloaded again from the firmware upgrade server.

[0094] S307. Download the merged upgrade package from the firmware upgrade server.

[0095] In some embodiments, when a recovery mode firmware image file is not available locally, or when local image file digest verification fails, the firmware upgrade service initiates a download request to a preset firmware upgrade server to obtain the merged upgrade package corresponding to the current device version. The download process supports resume download and integrity verification to ensure the integrity of the downloaded data.

[0096] S308. Verify the merged upgrade package signature using the public key of the upgrade package pre-installed in the system firmware.

[0097] In some embodiments, the firmware upgrade service uses a public key pre-installed in the system firmware to sign and verify the downloaded merged upgrade package. This public key is pre-installed in the system firmware during the device compilation phase and forms a key pair with the private key used when generating the merged upgrade package. Signature verification is a critical security barrier to ensure that the merged upgrade package is of trustworthy origin and has not been tampered with.

[0098] S309. Has the signature verification passed?

[0099] In some embodiments, the firmware upgrade service determines the signature verification result of the merged upgrade package.

[0100] If the signature verification passes, it indicates that the source of the merged upgrade package is trustworthy and the content is complete, and the process proceeds to S310.

[0101] If the signature verification fails, it indicates that the merged upgrade package may have been tampered with or come from an unofficial source. The process returns to S307, and the merged upgrade package is downloaded again from the firmware upgrade server until the signature verification is successful or the maximum number of retries is reached, at which point an error message is displayed and the process exits.

[0102] S310, Unzip and merge the upgrade package to the preset path.

[0103] In some embodiments, after successful signature verification, the firmware upgrade service decompresses the merged upgrade package to a preset decompression path according to a preset compressed packaging format (such as ZIP). The decompression operation restores the standard firmware upgrade package and recovery mode firmware image file contained in the merged upgrade package, preparing materials for subsequent repair operations.

[0104] S311. Obtain the system firmware upgrade package and recovery mode firmware image file.

[0105] In some embodiments, after decompression, two core files are generated in the preset path: one is a standard firmware upgrade package (such as update.zip), which is used for subsequent system firmware upgrades; the other is a recovery mode firmware image file (such as recovery.img), which is used to repair the damaged recovery mode firmware.

[0106] S312. Calculate the digital digest of the decompressed recovery mode firmware image file.

[0107] In some embodiments, the firmware upgrade service uses a preset hash algorithm to calculate the digital digest value of the decompressed recovery mode firmware image file in preparation for secondary integrity verification, ensuring that the image file is not corrupted during download and decompression.

[0108] S313. Is the digital digest consistent with the merged and upgraded packet element information? In some embodiments, the firmware upgrade service compares the calculated digital digest of the decompressed image file with the digital digest of the recovery mode firmware stored in the merged upgrade package metadata.

[0109] If the two match, it indicates that the image file is complete and undamaged, and the process proceeds to S315, where the image file is used for repair.

[0110] If the two are inconsistent, it indicates that the image file has been corrupted during the download or decompression process. The process returns to S307, and the merged upgrade package is downloaded again from the firmware upgrade server until the digest verification is successful or the maximum number of retries is reached, at which point an error is reported and the process exits.

[0111] S314. Repair directly using the local image file.

[0112] In some embodiments, when the local image file digest verification in S306 is consistent, the firmware upgrade service directly uses the locally existing recovery mode firmware image file for repair, without having to download it repeatedly, which significantly improves repair efficiency and saves network resources.

[0113] S315. Use the downloaded recovery mode firmware image file to repair.

[0114] In some embodiments, when the digest verification in S313 is consistent, the firmware upgrade service uses the recovery mode firmware image file obtained by decompressing the merged upgrade package for repair. At this point, the repair materials are ready, and the process enters the actual image writing and verification stage.

[0115] S316. Check if the size of the recovery mode firmware partition is smaller than the size of the recovery mode firmware image file. In some embodiments, before writing the image file to the recovery mode firmware partition, the firmware upgrade service first obtains the partition size of the block device node file corresponding to the recovery mode firmware and the size of the recovery mode firmware image file to be written, and compares the two.

[0116] If the recovery mode firmware partition size is smaller than the image file size, it indicates that the partition capacity is insufficient to hold the complete image file. The process then enters S317 and terminates the repair operation.

[0117] If the partition size is not less than the image file size, it indicates that the partition capacity meets the write requirements, and the process enters S318 to perform the write operation.

[0118] S317. Terminate repair operation.

[0119] In some embodiments, when insufficient firmware partition capacity is detected in recovery mode, the firmware upgrade service immediately terminates the repair operation and outputs a failure message to the user or system log to avoid incomplete writing or writing failure due to insufficient space, and to prevent the repair operation itself from causing secondary damage.

[0120] S318. Write the recovery mode firmware image file to the block device node file corresponding to the recovery mode firmware.

[0121] In some embodiments, after confirming that the partition capacity meets the requirements, the firmware upgrade service starts from the beginning of the recovery mode firmware image file, reads the data of the image file size in sequence, and writes it to the beginning of the block device node file (such as / dev / block / by-name / recovery) corresponding to the recovery mode firmware, thus completing the image file burning operation.

[0122] S319. Read back the data that has been written from the block device node file.

[0123] In some embodiments, after the write operation is completed, the firmware upgrade service immediately starts from the beginning of the same device node file, reads data of the same size as the image file, and reads back the data written to the partition into memory to prepare comparison samples for subsequent integrity verification.

[0124] S320, Perform a binary comparison with the original image file.

[0125] In some embodiments, the firmware upgrade service performs a byte-by-byte binary comparison between the readback data and the original recovery mode firmware image file to verify that the write operation is accurate.

[0126] S321. Are the data completely consistent?

[0127] In some embodiments, the firmware upgrade service determines the result of the binary comparison.

[0128] If the readback data is completely consistent with the original image file, it indicates that the write operation was successful, and the process enters S323 to confirm that the recovery mode firmware repair was successful.

[0129] If any inconsistency exists, it indicates that an error occurred during the writing process, and the process enters S322 to perform a rewrite operation.

[0130] S322, Re-execute the write operation.

[0131] In some embodiments, when a binary comparison reveals data inconsistency, the firmware upgrade service automatically re-executes the write operation, rewriting the recovery mode firmware image file to the block device node file, and repeats the readback and binary comparison steps until the data is completely consistent or the preset maximum number of retries is reached. This retry mechanism effectively eliminates write errors caused by bad blocks in the storage medium, write interference, or hardware malfunctions.

[0132] S323, Confirmed that the firmware repair in recovery mode was successful.

[0133] In some embodiments, when a binary comparison confirms that the readback data is completely consistent with the original image file, the firmware upgrade service determines that the recovery mode firmware repair is successful. Subsequently, the system can continue to execute the subsequent metadata reset and firmware upgrade triggering process, completing a full closed loop from recovery mode repair to system upgrade.

[0134] According to another aspect of the invention, Figure 4 This is a schematic diagram illustrating an electronic device 400 according to an embodiment of the present invention. (Refer to...) Figure 4 The electronic device 400 includes a memory 402, a processor 404, and a computer program stored in the memory 402 and executable on the processor. When the processor 404 executes the computer program, it implements the various steps of the recovery mode repair method based on the merged upgrade package as described above.

[0135] In summary, this invention provides a recovery mode repair method and electronic device based on a merged upgrade package. By incorporating the recovery mode firmware image file as a component of the merged upgrade package, it achieves unified packaging, distribution, and cloud storage of the recovery mode firmware and system firmware. During system operation, this method proactively monitors the number of recovery mode boot anomalies to accurately determine the firmware corruption status. Through local caching priority and multi-verification mechanisms, it obtains a reliable merged upgrade package from the firmware upgrade server and extracts the recovery mode firmware image to autonomously repair the damaged partition.

[0136] During the repair process, the system introduces a partition capacity pre-check and a write-read-verify retry mechanism to ensure the integrity and reliability of the repaired data. After the repair is completed, the system automatically resets the boot anomaly record and triggers the subsequent firmware upgrade process, forming an integrated closed loop of monitoring, repair, and upgrade. This solution effectively solves the problem of devices being unable to enter recovery mode, perform firmware upgrades, or restore factory settings due to firmware corruption in recovery mode. It avoids the risk of repeated device restarts or device bricking, significantly improves device reliability and maintainability, and reduces after-sales maintenance costs.

[0137] This system is applicable to various Android terminals and embedded devices. By building a complete firmware self-healing system, it provides reliable technical support for firmware upgrades and system stability of smart devices.

[0138] The above description is merely an embodiment of the present invention and does not limit the patent scope of the present invention. Any equivalent modifications made based on the content of the present invention specification and drawings, or direct or indirect applications in related technical fields, are similarly included within the patent protection scope of the present invention.

Claims

1. A recovery mode repair method based on merging upgrade packages, characterized in that, include: Obtain the merged upgrade package, which includes a recovery mode firmware image file as a component; After entering the system firmware in normal mode, monitor the number of times the recovery mode boot fails. as well as If the number of boot errors exceeds the threshold, the recovery mode firmware is determined to be corrupted, and the recovery mode firmware image file is extracted from the merged upgrade package to repair the recovery mode firmware partition based on the recovery mode firmware image file.

2. The method according to claim 1, characterized in that, Obtaining the merged upgrade package includes: Receive the merged upgrade package from the firmware upgrade server; Read merged upgrade package metadata from the boot communication partition. The merged upgrade package metadata includes the decompression path of the merged upgrade package and the recovery mode firmware digital digest. Check if the recovery mode firmware image file exists in the decompression path of the merged upgrade package; If it exists, calculate the digital digest of the recovery mode firmware image file and compare it with the digital digest of the recovery mode firmware; and If it does not exist, the merged upgrade package is decompressed to the decompression path to obtain the recovery mode firmware image file.

3. The method according to claim 1, characterized in that, Also includes: The system firmware upgrade package and the recovery mode firmware image file are compressed and packaged according to a preset compression and packaging format to generate the merged upgrade package, and the merged upgrade package public key is stored in the merged upgrade package; The merged upgrade package is signed using the upgrade package private key corresponding to the public key of the merged upgrade package; as well as The signed merged upgrade package is placed on the firmware upgrade server.

4. The method according to claim 1, characterized in that, After entering the system firmware in normal mode, the number of times the recovery mode boot anomaly was detected includes: Read recovery mode exit metadata from the boot communication partition. The recovery mode exit metadata includes verification information for identifying validity and the number of boot anomalies. When the verification information meets the preset conditions, the number of boot errors in the recovery mode exit metadata is obtained; Compare the number of boot failures with a preset maximum boot count threshold; and If the threshold is exceeded, the recovery mode firmware is determined to be corrupted.

5. The method according to claim 1, characterized in that, Also includes: After the device enters recovery mode, recovery mode exit metadata is read from the boot communication partition. The recovery mode exit metadata includes verification information for identifying validity and the number of boot anomalies. If the verification information satisfies the verification information, then the number of boot exceptions is set to the initial value; If the verification information does not meet the requirements, then the verification information is set to a valid state, and the number of boot exceptions is set to an initial value. as well as Write the updated recovery mode exit metadata back to the boot communication partition.

6. The method according to claim 1, characterized in that, Also includes: If a recovery signal requiring entry into recovery mode is detected, recovery mode exit metadata is obtained from the boot communication partition. The recovery signal includes a factory reset command or an upgrade command. Determine whether the number of boot anomalies in the recovery mode exit metadata exceeds a preset threshold. as well as If the threshold is exceeded, it is determined that the recovery mode cannot be entered, the recovery signal is cleared, and the system firmware is entered.

7. The method according to claim 1, characterized in that, Before determining that the recovery mode firmware is corrupted and extracting the recovery mode firmware image file from the merged upgrade package, the process also includes: Read the merged upgrade package metadata from the boot communication partition. The merged upgrade package metadata includes the merged upgrade package path, the merged upgrade package decompression path, and the recovery mode firmware digital digest. Check if the recovery mode firmware image file exists in the unzipped path of the merged upgrade package; If it exists, calculate the digital digest value of the recovery mode firmware image file under the unzipped path of the merged upgrade package, and compare it with the digital digest of the recovery mode firmware; If the comparison results are consistent, then the existing recovery mode firmware image file can be used directly for repair; and If the recovery mode firmware image file does not exist in the decompression path of the merged upgrade package, or if the calculated digital digest value is inconsistent with the recovery mode firmware digital digest, then the step of obtaining the merged upgrade package from the firmware upgrade server is executed.

8. The method according to claim 7, characterized in that, After retrieving the merged upgrade package from the firmware upgrade server, the process further includes: The obtained merged upgrade package is decompressed to a preset path to obtain the system firmware upgrade package and the recovery mode firmware image file; Calculate the digital digest of the recovery mode firmware image file and compare it with the digital digest of the recovery mode firmware in the merged upgrade package meta information; If the comparison results are consistent, then the recovery mode firmware image file is used for repair; and If the comparison results are inconsistent, the merged upgrade package is retrieved again from the firmware upgrade server.

9. The method according to claim 8, characterized in that, Repairing using the recovery mode firmware image file includes: Write the recovery mode firmware image file into the block device node file corresponding to the recovery mode firmware; Read back the data that has been written from the block device node file; The readback data is compared in binary with the recovery mode firmware image file; If the comparison results are consistent, then the recovery mode firmware repair is confirmed to be successful; and If the comparison results are inconsistent, the operation of writing the recovery mode firmware image file to the block device node file is repeated until the data of the two are completely consistent.

10. The method according to claim 9, characterized in that, Before writing the recovery mode firmware image file to the block device node file corresponding to the recovery mode firmware, the process also includes: Obtain the size of the recovery mode firmware partition and the size of the recovery mode firmware image file; and If the size of the recovery mode firmware partition is smaller than the size of the recovery mode firmware image file, the repair operation will be terminated.

11. The method according to claim 1, characterized in that, Repairing the recovery mode firmware partition based on the recovery mode firmware image file includes: The number of recovery mode boot attempts in the recovery mode exit metadata is reset to the initial value and written back to the boot communication partition; Check if a system firmware upgrade package exists in the unzipped path of the merged upgrade package; If present, the system firmware upgrade package is then signed and verified. After successful verification, the upgrade command and the path to the system firmware upgrade package are written to the boot communication partition; and Reboot the device and enter recovery mode to perform a firmware upgrade.

12. The method according to claim 11, characterized in that, Entering recovery mode to perform a firmware upgrade includes: In recovery mode, the system firmware upgrade package is signed and verified using the public key of the upgrade package pre-installed in the recovery mode firmware; After successful verification, the firmware upgrade operation will be performed according to the preset upgrade process; and After the upgrade is complete, clear the upgrade instructions in the boot communication partition, exit recovery mode, and restart the device.

13. An electronic device, characterized in that, include: The memory is configured to store executable programs; as well as A processor is configured to execute the program to perform the method according to any one of claims 1 to 12.

Images