Ota download control method, apparatus, and medium

Abstract

The application provides an OTA download control method, device and medium, and aims at the problem that a user's pause request cannot take effect immediately in a download process when a script sub-process runs a download tool in a foreground mode in the prior art.The application derives a sentinel sub-process before the script sub-process starts the download tool.A GUI main process creates a persistent pause marker file in a storage medium in response to a pause request.The sentinel sub-process periodically polls the marker file, detects the download tool, sends a catchable termination signal to the download tool to make the download tool normally exit, and further triggers the script sub-process to execute an exit cleaning program, shunts cleaning according to stage markers, and retains a downloaded half-upgrade package.In response to a resume instruction, the pause marker is cleared, and the download is continued from the half-upgrade package breakpoint.The application can realize immediate pause control and breakpoint resume of a foreground download process, and is mainly applied to application-level software OTA upgrade of an embedded Linux device.

Description

Technical Field

[0001] This invention relates to the field of embedded system software upgrade technology, and in particular to an OTA download control method, device and medium. Background Technology

[0002] In embedded devices equipped with a graphical user interface (GUI), application-level OTA (Over-The-Air) software upgrades typically employ a dual-process collaborative architecture. In this architecture, the GUI main process is responsible for responding to user interactions, displaying upgrade progress, and managing upgrade status. When an upgrade task is triggered, the GUI main process launches a shell script subprocess via a system interface using elevated privileges and an independent process group. This script subprocess, in a foreground blocking manner, calls a download tool (such as curl or wget) to retrieve a large upgrade package file from a remote server. After the download is complete, the script subprocess continues to perform package verification, decompression, and installation operations.

[0003] In general operating systems and shell runtime environments, the signal capture mechanism of shell scripts (such as Bash's trap mechanism) has inherent limitations on execution timing: when a script child process is waiting for a foreground command to complete, a termination signal sent to the shell script from the outside will be suspended until the foreground command exits naturally, at which point the pre-defined cleanup routine will have a chance to execute. If the GUI main process sends a forced termination signal (SIGKILL) directly to the entire process group after receiving a pause request from the user, the download tool can stop immediately, but the script child process cannot capture the signal, causing the exit cleanup routine to be skipped. The status of the downloaded half-upgrade package remains unclear, and temporary markers remain, disrupting the state consistency of the file system. If a regular termination signal (SIGTERM) is sent to a multi-level boot chain, it is very easy for the signal to fail to reach the foreground download tool accurately due to forwarding by privilege escalation tools and process group topology isolation, resulting in an uncontrolled phenomenon where the download process continuously occupies network bandwidth and storage resources.

[0004] Furthermore, in scenarios where upgrades are interrupted due to network failures or abnormal power outages, existing breakpoint resume mechanisms typically initiate a range request to the server based directly on the byte length of the locally existing file. If the disk write operation was interrupted by a forced shutdown or abnormal power loss, the remaining partial upgrade package may exhibit an abnormal situation where the physical size has reached the expected total size, but the internal data is corrupted. In this case, conventional breakpoint resume tools will mistakenly determine that the file has been completely downloaded and exit directly, leading to the failure of subsequent integrity verification. When resuming the download during the fault recovery loop, the above judgment will be repeated, resulting in an infinite retry loop that cannot be automatically recovered. Summary of the Invention

[0005] This invention provides an OTA download control method, device, and medium. It addresses the problems of existing dual-process architectures, which are limited by the mechanism of script signal processing being blocked by foreground commands during foreground downloads. This results in external pause commands not taking effect in time during the download, and the forced killing of process groups skips the cleanup logic, causing the state of half-finished upgrade packages to become out of control and unable to be reliably resumed. Furthermore, after power failure or abnormal interruption, it is easy to cause a dead loop in the resumption of download due to pseudo-complete bad packets.

[0006] The core technology of this invention is to pre-start an independent background sentinel subprocess before the download tool runs in the foreground of the script subprocess to poll and detect the disk persistent pause mark and terminate the download tool accordingly. After the download tool exits, the script exit cleanup program performs half-packet retention and on-site cleanup according to the disk stage mark, and performs integrity pre-verification on the local half-packet that has reached the expected size before resuming the download from the breakpoint to heal the damaged packet.

[0007] In a first aspect, the present invention provides an OTA download control method, the method comprising the following steps: In response to the upgrade trigger command, a script subprocess is started through the GUI main process, and the script subprocess executes the download tool in the foreground to download the upgrade package. Before executing the download tool, the script subprocess starts a sentinel subprocess running in the background. In response to a pause request, a persistent pause marker file is created in a preset path on the storage medium by the GUI main process. The storage medium maintains stage markers for indicating upgrade stages, and the stage markers include at least the pause marker file. The sentinel subprocess periodically polls the preset path and sends a termination signal to the download tool when it detects a pause marker file, so that the download tool, which is running in the foreground, responds to the termination signal and exits. After the download tool exits, the script subprocess is triggered to execute the pre-registered exit cleanup program. The exit cleanup program performs traffic splitting based on the stage markers. When a pause marker file is detected, the downloaded half of the upgrade package is retained and the script subprocess is controlled to exit. In response to the resume command, the pause marker file is cleared via the GUI main process, and the script child process is restarted to continue downloading the upgrade package from the breakpoint where it was partially downloaded.

[0008] Furthermore, in response to a pause request, after the GUI main process creates a persistent pause marker file in a preset path on the storage medium, it also includes sending a termination signal to the process group where the script child process resides through the GUI main process; The main channel, which sends termination signals from the GUI main process to the process group, and the fallback channel, which polls the paused marked files and sends termination signals to the download tool, are executed in parallel. The download tool is triggered to exit by the termination signal that arrives first. When the GUI main process receives a pause request and sets the pause intent flag, it actively blocks the download progress timeout monitoring and processing logic so that the pause process takes precedence over the timeout determination.

[0009] Furthermore, while the sentinel child process is running in the background, it sends probe signals to the script child process to detect the liveness of the script child process. When the script child process is detected to have exited, the sentinel child process exits automatically. Sending a termination signal to the download tool includes: the sentinel child process precisely matching the download tool and initiating a termination signal according to the command line mode containing the path to the upgrade package to be downloaded; After the download tool completes the download normally, the script subprocess will actively terminate and reclaim the sentinel subprocess based on the recorded process ID before entering the decompression and installation stage. The sentinel subprocess periodically polls the preset path with a polling period of 0.3 seconds.

[0010] Furthermore, the stage markers include download stage markers, pause marker files, and installation lock markers; The exit cleanup process is routed according to stage markers, including: When a pause marker file is detected, delete the pause marker file and the download stage marker, retain half of the upgrade package, and exit the script subprocess with an explicit exit code; If no pause marker file is detected and a download phase marker exists, delete the half-finished upgrade package and the download phase marker. When an installation lock flag is detected, the installation state is preserved, and cancellation and pause requests for the upgrade process are rejected through the GUI main process; In the exit cleanup process, the deletion of stage markers is performed before the file deletion, and the process is allowed to exit by default when the storage medium is in an unmarked state.

[0011] Furthermore, it also includes a pre-verification step before resuming interrupted downloads: After restarting the script subprocess and before restarting the download tool, when a partial upgrade package is detected locally and its file size is greater than or equal to the expected total size in the upgrade list, the check hash value of the partial upgrade package is calculated and compared with the expected hash value in the upgrade list. If the comparison does not match, the incomplete upgrade package is determined to be a corrupted package. Delete the incomplete upgrade package and switch to full download mode to restart the download tool for download. If a match is found, the process is allowed to proceed to the next stage. If the file size of the partial upgrade package is smaller than the expected total size, the download tool will be launched directly to resume the download from where it left off.

[0012] Furthermore, before restarting the script subprocess, the GUI main process obtains the physical file size of the half-upgrade package at the current moment through the file system interface as the starting number of bytes for resuming the download, so as to anchor and align with the start point of the breakpoint request initiated by the script subprocess to the remote server when it re-executes the download tool. The script subprocess, while executing the download in the breakpoint resume mode loop, simultaneously configures a preset retry count threshold and a preset cumulative waiting time threshold; When the download tool returns an error code indicating that the remote server does not support the breakpoint range request, the script subprocess deletes the half-finished upgrade package and automatically downgrades the download mode to full download mode. Before each retry, the script subprocess checks the remaining available space on the storage medium. If the remaining available space is lower than a preset storage threshold, it exits the download loop and reports a storage error.

[0013] Furthermore, when the upgrade package contains multiple components to be upgraded and each component is downloaded and installed serially, a download phase marker is written when the current component enters the download phase, the download phase marker is cleared and an installation lock marker is written when the current component is downloaded, and the installation lock marker is cleared when the current component is installed or fails. The sentinel subprocess is started before each component enters the download phase and is recycled after the download of that component is completed. When the upgrade process is interrupted and restarted due to an abnormality, the GUI main process scans the storage medium during the initialization phase. If an installation lock mark is detected, the lock state is restored and the script subprocess is checked for survival. If no script subprocess is found to be alive, the installation lock mark is determined to be a crash remnant. Before starting a new upgrade task, the residual phase mark is cleared, and the integrity check is performed on the residual half-upgrade package to determine whether to resume the download or re-download.

[0014] Secondly, the present invention provides an OTA download control device, comprising: The upgrade startup module is used to respond to upgrade trigger commands by starting a script subprocess through the GUI main process. The script subprocess then executes the download tool in the foreground to download the upgrade package. Before executing the download tool, the script subprocess starts a sentinel subprocess running in the background. The tag creation module is used to create a persistent pause tag file in a preset path of the storage medium in response to a pause request through the GUI main process. The storage medium maintains stage tags for indicating upgrade stages, and the stage tags include at least the pause tag file. The sentinel control module is used to periodically poll the preset path through the sentinel subprocess, and send a termination signal to the download tool when a pause marker file is detected, so that the download tool running in the foreground responds to the termination signal and exits; The traffic splitting and cleaning module is used to trigger the script subprocess to execute the pre-registered exit cleaning program after the download tool exits. The exit cleaning program performs traffic splitting based on the stage marker. When a pause marker file is detected, the downloaded half of the upgrade package is retained and the script subprocess is controlled to exit. The resume control module is used to respond to the resume command by clearing the pause marker file through the GUI main process and restarting the script subprocess to continue downloading the upgrade package from the breakpoint of the incomplete upgrade package.

[0015] Thirdly, the present invention provides an electronic device including a memory and a processor, wherein the memory stores a computer program and the processor is configured to run the computer program to execute the above-described OTA download control method.

[0016] Fourthly, the present invention provides a readable storage medium storing a computer program, which, when executed by a processor, implements the OTA download control method as described above.

[0017] The main contributions and innovations of this invention are as follows: 1. This invention effectively bypasses the system's underlying limitation that signal capture routines are delayed when the script process executes foreground commands by pre-starting an independent background sentinel subprocess before the script subprocess launches the foreground download tool, and using a persistent marker file in the storage medium as a cross-process command channel. When the user initiates a pause, the sentinel subprocess quickly detects the marker through periodic polling and sends a termination signal to the download tool itself through precise matching, causing the foreground download tool to exit quickly and promptly transfer execution control to the exit cleanup program. This significantly shortens the response latency from command issuance to download interruption and avoids invalid background downloads caused by blocked signal forwarding in multi-level process links.

[0018] 2. This invention transforms process termination into a controlled exit process by reading persistent stage markers written at different stages through a script exit cleanup program. When a pause marker is detected, the downloaded partial upgrade package is retained for subsequent resume downloads. When a download is abnormally canceled, residual packages and download markers are cleaned up. During the decompression and installation phase, an installation lock marker blocks unauthorized interruptions and protects the installation environment. Combined with the execution order of stage markers prioritizing file deletion and the default allowance policy for unmarked states, the idempotency and atomicity of the cleanup logic are guaranteed, effectively preventing chaotic upgrade environment states and abnormal storage space occupation by invalid residual packages.

[0019] 3. To address the specific situation where "file size meets the standard but data content is corrupted" when the device experiences a power outage or abnormal termination, this invention introduces a pre-hash pre-verification mechanism before resuming interrupted downloads. When the size of the local truncated packet is greater than or equal to the expected total size, its integrity is verified first. If the verification fails, the corrupted packet is deleted and the download is automatically reset to full download mode. This avoids the repeated retries and verification failure loops caused by traditional interrupted download tools misjudging the file as complete and immediately reverting. At the same time, this pre-verification does not add extra computational overhead to normally incomplete truncated packets, balancing download efficiency and fault self-healing capability.

[0020] 4. By actively blocking the download timeout monitoring logic during the pause flag setting, the race condition between timeout judgment and pause process under weak network long-term waiting is eliminated, avoiding the normal pause being mistakenly judged as upgrade failure due to the preemptive intervention of timeout logic; when resuming the download, the physical size of the half-packet is reread in real time by the file system as the starting point for the resume download, so that the progress displayed on the interface is synchronized with the actual breakpoint request range initiated at the underlying level; in addition, the sentinel child process is automatically terminated when the parent script exits through the survival probe, and is explicitly recycled by the script after the normal download ends, avoiding the leakage of background orphan processes and the waste of idle resources.

[0021] Details of one or more embodiments of the present invention are set forth in the following drawings and description, so that other features, objects and advantages of the invention will be more readily understood. Attached Figure Description

[0022] The accompanying drawings, which are included to provide a further understanding of the invention and form part of this invention, illustrate exemplary embodiments of the invention and are used to explain the invention, but do not constitute an undue limitation of the invention. In the drawings: Figure 1 This is a system architecture and instruction / signal / tag flow diagram of the OTA download control method according to an embodiment of the present invention; Figure 2 This is a complete timing diagram of pause-resume according to an embodiment of the present invention; Figure 3 This is a three-marker disk state machine diagram according to an embodiment of the present invention. Detailed Implementation

[0023] Exemplary embodiments will now be described in detail, examples of which are illustrated in the accompanying drawings. When the following description relates to the drawings, unless otherwise indicated, the same numerals in different drawings denote the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with one or more embodiments of this specification. Rather, they are merely examples of apparatuses and methods consistent with some aspects of one or more embodiments of this specification as detailed in the appended claims.

[0024] It should be noted that the steps of the corresponding methods are not necessarily performed in the order shown and described in this specification in other embodiments. In some other embodiments, the methods may include more or fewer steps than described in this specification. Furthermore, a single step described in this specification may be broken down into multiple steps in other embodiments; and multiple steps described in this specification may be combined into a single step in other embodiments.

[0025] The hardware environment used in this embodiment is an embedded Linux device, such as an NVIDIA Jetson Orin NX platform with an ARM64 architecture processor, an Ubuntu 20.04 LTS operating system, a Qt 5.15.2 graphical interface framework, curl 7.68.0 as the download tool, and GNU bash 4+ as the shell interpreter. The system working directory is set to / opt / ota (hereinafter referred to as $OTA_DIR), and the temporary storage path for the upgrade package is set to / tmp. Those skilled in the art will understand that the above hardware platform and software version are exemplary implementation environments. The technical solution of this invention can be adapted to be implemented in environments using operating systems with similar process models and signal mechanisms (such as other Linux distributions, POSIX-compatible systems) and similar graphical frameworks, and does not constitute a limitation on the scope of protection of this invention.

[0026] Example 1 This embodiment illustrates the specific process of implementing real-time pause control during application-level OTA downloads in a dual-process architecture, through persistent marker channels in the storage medium, independent sentinel subprocesses, and a dual-channel racing mechanism.

[0027] I. System Operation Architecture and Foreground Execution Mechanism like Figure 1As shown, this embodiment adopts a dual-process collaborative architecture. The GUI main process (i.e., the OtaManager process built based on the C++ and Qt frameworks) is responsible for upgrade triggering, progress display, status management, and download timeout monitoring. After the user initiates a software upgrade instruction through the QML front-end interface, the GUI main process constructs a start command, and starts the script sub-process (e.g., soft_ota.sh) in an independent process group (configured with setsid) with elevated privileges (configured with echo <sudo password>| sudo -S) through a process start interface (such as QProcess). After the script sub-process is started, it downloads and parses the upgrade manifest manifest.json to obtain the version number, download URL, and expected SHA256 value of the component to be upgraded; then it sends an HTTP HEAD request to the remote upgrade server to obtain the expected total size (Content-Length) of the upgrade package, and prints structured progress markers to the GUI main process through the standard output pipe.

[0028] Before the script sub-process executes the download tool (curl) in a foreground blocking manner, it pre-forks an independent pause sentinel sub-process running in the background.

[0029] In the present invention, the so-called "foreground manner" or "foreground blocking manner" means that after the script sub-process pulls up the download tool, it actively suspends and synchronously waits for the download tool process to complete execution and exit, and during this period, the script sub-process does not continue to execute subsequent instruction lines. Limited by the execution mechanism of Shell interpreters such as Bash, when the script sub-process is in a blocking state waiting for the foreground command to exit, even if it receives an asynchronous signal sent from the outside, its pre-registered signal capture routine (the cleanup function registered via trap) will be postponed by the interpreter, and will not get the execution opportunity until the foreground download tool exits. If the running of the foreground command is not broken, the cleanup routine of the script itself cannot intervene immediately.

[0030] 2. Life Cycle Management and Directed Interruption Logic of the Sentinel Sub-process To break through the blocking restriction of the foreground command on the signal trap, when the script sub-process forks the background sentinel sub-process, the sentinel sub-process assumes the responsibilities of independent monitoring and forcibly interrupting the download tool. The code logic of the sentinel sub-process is illustrated by taking the Bash scripting language as an example as follows: ( while kill -0 $$ 2> / dev / null; do if [ -f "$OTA_DIR / ota_paused" ]; then pkill -TERM -f "curl . $PKG_PATH" 2> / dev / null&&break fi sleep 0.3 done )& PAUSE_SENTINEL_PID=$! # Record the sentinel's PID for automatic recycling after downloading is complete.

[0031] The specific execution and control characteristics of the aforementioned sentinel child processes are as follows: 1. Self-management of lifecycle: The sentinel child process performs a loop of checks in the background. In each loop, it first executes `kill -0$$` to send a probe signal to the parent script process (signal 0 does not actually interrupt the process; it is only used to detect whether the parent process's PID exists). If the parent script process terminates due to normal exit, abnormal crash, or being forcibly killed by the system, the probe instruction returns failure, and the sentinel child process immediately jumps out of the loop and terminates automatically, preventing the creation of background orphan processes.

[0032] 2. Periodic Polling Detection: The sentinel subprocess sleeps every 0.3 seconds and checks if a pause marker file (ota_paused) exists in a preset path on the storage medium. The 0.3-second polling period is chosen because, in actual testing, the entire process from the appearance of the marker to the termination of curl and the completion of the cleanup process can be completed in about 0.5 seconds, which is perceived by the user as an instant pause; further shortening the period would have limited benefits, while increasing idle overhead.

[0033] 3. Precise Command Line Matching for Targeted Termination: Once the ota_paused flag file is detected, the sentinel child process immediately performs a targeted termination. To avoid mistakenly killing other non-upgrade curl processes running on the device by simply matching by process name, the sentinel child process uses a complete command line matching mode, concatenating the downloaded tool name with the target upgrade package's local path PKG_PATH (i.e., matching in the form of curl). The script sends a SIGTERM termination signal (which can be captured and processed normally) to the matched download tool process via the PKG_PATH command line, after which the sentinel child process exits. Before concatenating the command line mode, the script escapes regular expression metacharacters such as version numbers, periods (.), and square brackets that may exist in the path. In this embodiment, the upgrade package is stored in a device-exclusive directory, and OTA upgrades are globally mutually exclusive and executed serially as single tasks. This constraint ensures that the "curl+PKG_PATH" combination mode uniquely hits the target download tool on the device.

[0034] As an optional implementation of the above-mentioned exact command-line matching, the script subprocess records the process ID (PID) of the download tool after starting it. Upon detecting a pause marker file, the sentinel subprocess sends a termination signal to the download tool process based on this process ID to eliminate potential ambiguities in the regular expression matching. When the process ID is unavailable (e.g., process ID recording fails), the process reverts to the exact command-line matching method described above.

[0035] 4. Proactive Recycling Mechanism: If the upgrade package download completes normally, the script child process, upon detecting a successful return from the curl foreground command and before entering the subsequent decompression and installation phase, proactively executes `kill "$PAUSE_SENTINEL_PID` to terminate and recycle the sentinel child process based on the recorded sentinel process identifier `PAUSE_SENTINEL_PID`. This prevents the sentinel from continuously idling and polling during the several-minute decompression and installation phase, and from mistakenly killing other processes that have accidentally written their flags. Even if proactive recycling fails, the sentinel child process will automatically terminate upon exiting with the parent script process and being detected by the probe signal, thus preventing process leakage.

[0036] III. Timing of Dual-Channel Racing Control for Pause Requests like Figure 2 As shown in the pause segment (timing t1 to t8), the collaborative control timing after the user initiates a pause in the interface is as follows: 1. Timing t1: When the user clicks the "Pause" button on the front-end interface, the GUI main process receives the pause request.

[0037] 2. Timing t2 (Pre-verification): The GUI main process performs a validation check on the execution status, confirming that the current upgrade status is in the downloading state and that the storage medium does not contain the installation lock flag `ota_extracting` indicating that the decompression and installation phase has begun. Simultaneously, a liveness check is performed on the script child processes to confirm that they are still running. If the script has exited but the termination signal has not yet been dispatched, pausing is refused, and the process waits for the script to report a true exit result to avoid losing upgrade results or the status getting stuck in the Paused state.

[0038] 3. Timing t3 (Mark First to Disk): After successful verification, the GUI main process first creates a persistent pause marker file, ota_paused, in the $OTA_DIR directory. This marker file is written directly to the physical disk as a cross-process command channel, existing before any subsequent signal actions, ensuring that even if a subsequent process experiences a partial crash, the user's pause intention will not be lost.

[0039] 4. Timing t4 and t5 (Main / Backup Dual-Channel Racing): Main channel (timing t4): The GUI main process sets the internal pause intention flag m_pauseRequested and sends a SIGTERM termination signal to the process group where the script child process resides. In ideal conditions where the process group topology is flat and the signal is not blocked, this signal can be quickly transmitted to the download tool, causing it to exit.

[0040] The fallback channel (timing t5): Because the script is started via a multi-level chain of "QProcess→setsid→sudo -S→bash→curl", the signal forwarding behavior of the privilege escalation tool or process group session isolation may cause the SIGTERM signal from the main channel to fail to reach the curl body. At this time, the background sentinel child process independently detects the existence of the ota_paused flag file within a polling cycle of at most 0.3 seconds and immediately sends a SIGTERM signal to the curl body.

[0041] 5. The main channel and the backup channel execute in parallel, competing with each other. The download tool is triggered to exit by the first termination signal received. Through multiple rounds of pause operation testing during the development and verification phase, the interruption is completed within approximately 0.5 seconds from the time the pause marker file is written to the foreground download tool's exit.

[0042] 6. Timing t6 and t7 (trap cleanup): After receiving SIGTERM, the download tool has the opportunity to safely close the TCP connection and exit. The moment the foreground download tool exits, the blocking of the parent script process is released, Bash's signal handling mechanism is immediately activated, and the pre-registered unified exit handler (registered via `trap cleanup_on_exitEXIT INT TERM HUP`) is executed. The exit handler reads the stage markers on the disk, detects the existence of `ota_paused`, determines it as an active pause semantic, retains the partially downloaded upgrade package located in the ` / tmp` directory, actively deletes `ota_paused` and the download stage marker `ota_downloading` from the disk, and calls `exit 1` to explicitly exit the script child process. Explicit exit can block the download retry loop outside the script, preventing the download tool from being restarted.

[0043] 7. Timing t8: The GUI main process detects the exit of the script child process (captures the finished signal of QProcess), and according to the previously set m_pauseRequested flag, it transitions the internal upgrade state to the paused state and refreshes the interface display.

[0044] IV. Anti-race state control that prioritizes pause over timeout A download progress timeout monitoring timer (threshold set to 120 seconds) runs in the GUI main process. If the download is stalled for more than 120 seconds due to network interruption or other reasons, the timeout monitoring logic will attempt to mark the upgrade as an error and execute the cancellation process. If the user clicks pause at the timeout threshold, and the blocking wait during the pause process causes the timeout monitoring to trigger first, the state machine will set the state to Error. This will then reject subsequent Paused state transitions triggered by pause callbacks based on the state transition whitelist, causing the user interface to generate a false pause failure report.

[0045] To eliminate this race condition, while the GUI main process sets the pause intent flag m_pauseRequested, the callback function of the download progress timeout monitoring timer checks the flag first upon entry. Once the pause intent is detected to be active, the timeout handling function immediately and proactively returns, shielding the timeout cancellation logic and ensuring that the pause process strictly takes precedence over the timeout determination.

[0046] Example 2 This embodiment illustrates the specific diversion and cleanup rules and protection design of the three-marker state machine when a process exits.

[0047] I. Stage Marker Definition and Disk State Machine like Figure 3 As shown, the upgrade state machine spanning the process lifecycle is maintained in the storage medium ( / opt / ota) through three mutually exclusive or combined persistent phase marker files: 1. Download phase marker (ota_downloading): This is written to disk by the script subprocess when entering the download phase, indicating that the current download transmission phase can be paused or canceled.

[0048] 2. Pause marker file (ota_paused): This file is written to disk by the GUI main process when responding to a pause request. It expresses the intention to actively pause the process and serves as a cross-process command channel.

[0049] 3. Installation lock flag (ota_extracting): This flag is written to the disk by the script subprocess after the download is complete and verification is passed, just before the decompression and installation scripts are called. It indicates that the critical installation section has been entered and must not be paused, canceled, or interrupted by power failure.

[0050] II. EXIT trap routing and cleanup rules The script subprocess registers a unified exit cleanup procedure via `trap cleanup_on_exit EXIT INT TERM HUP`. This procedure is triggered when the script subprocess exits normally, receives an interrupt signal (INT), receives a termination signal (TERM), or receives a pending signal (HUP). It performs strict flow control based on the combined state of the three phase markers on the disk. 1. Branch 1 (ota_paused exists): Corresponds to the scenario of active pause. Exit the cleanup program and retain the partially downloaded upgrade package located in the / tmp directory for later resumption; delete the ota_paused and ota_downloading markers by using rm -f in a best-effort manner; execute exit 1 to explicitly terminate the script to avoid restarting the download tool.

[0051] 2. Branch Two (ota_paused does not exist but ota_downloading exists): This corresponds to abnormal scenarios such as user-initiated cancellation of the upgrade, abnormal termination of the process group, or complete failure of network retries. The cleanup process determines that the incomplete upgrade package has no value and actively deletes the incomplete upgrade package file under / tmp, removes the ota_downloading marker, and frees up disk space.

[0052] 3. Branch Three (ota_extracting exists): This corresponds to the scenario where the system exits during the decompression and installation phase. The exit cleanup process strictly preserves the installation site data without deleting anything; simultaneously, the GUI main process rejects user cancellation and pause requests based on this flag. In error exit paths confirmed by the script as unrecoverable, the ota_extracting flag is explicitly removed to unlock the system.

[0053] III. Idempotency and Defensive Design of Exit Cleanup Procedures The execution of the exit cleanup process follows the following protection design: 1. The deletion operation of the stage marker is performed before the file deletion operation to ensure that even if an error occurs during the file deletion process, the disk marker status has been updated.

[0054] 2. All deletion operations are performed in a best-effort manner (e.g., rm -f ... 2> / dev / null ||true). Deletion failure will not affect the subsequent exit process, and residual markers will be cleaned up by the GUI main process before the next upgrade startup.

[0055] 3. When there are no stage markers on the disk (unmarked state), the cleanup program exits by default without deleting any files or modifying the current state. In GNU bash 4+, the EXIT trap for the same process is executed at most once, and the exit function within the cleanup function will not cause the trap to re-enter. Furthermore, due to the aforementioned idempotent design, even if the cleanup program re-enters due to an exception, since there are no stage markers on the disk, the function returns directly without side effects, preventing accidental deletion of partially preserved upgrade packages.

[0056] 4. All three marker files are persistent disk files rather than process memory variables. Any process (GUI main process, script child process, sentinel child process) can read the markers to know its current stage. The existence and combination of markers determine the allowed operations (pause, cancel, deny) and cleanup semantics, thus achieving state consistency across process lifecycles.

[0057] Example 3 This embodiment illustrates the specific pre-verification mechanism for eliminating dead loops caused by falsely complete bad packets during the recovery and upgrade phase.

[0058] I. Causes of Pseudo-Complete Bad Packet Dead Loop like Figure 2 As shown in the recovery segment timing (t9~t12), when the user clicks to continue downloading, the GUI main process clears the pause marker file ota_paused and restarts the script subprocess in resume mode.

[0059] In the practice of resuming interrupted downloads, there exists a specific type of engineering vulnerability: if the device experiences an abnormal power outage, kernel crash, or forced termination during the previous download process, the partially written upgrade package to disk may have its end padded by the file system, and its physical byte size may just reach or slightly exceed the expected total size (ExpectedContent-Length) recorded in the upgrade manifest, but the internal data of the file may be truncated or corrupted. In this invention, such partially written upgrade packages where "the file size has reached or exceeded the expected total size but the content is corrupted" are referred to as pseudo-complete bad packages.

[0060] In this scenario, if `curl -C -` is called directly with a resume function, curl will detect that the local file has reached or exceeded the target size in bytes, and will immediately terminate the download (or the server will return a 416 RangeNot Satisfiable error). The download process is mistakenly considered complete. The script then enters the final SHA256 checksum of the entire packet and fails with an error. When restarted in a subsequent recovery loop, the pseudo-complete local file still exists, causing the system to terminate again and fail the checksum again, thus getting stuck in an infinite loop of "retry always fails" that cannot be automatically broken out.

[0061] II. Pre-verification Triggering Conditions and Traffic Splitting To resolve this issue, the script subprocess performs the following targeted pre-verification before restarting the download tool to resume the download: 1. Triggering Condition Judgment: The script compares the actual physical size (LOCAL_SIZE) of the local truncated upgrade package with the expected total size (EXPECTED_SIZE). Full package pre-verification is triggered only when the following conditions are met simultaneously: the expected total size of the upgrade package is known (HTTP HEAD request successful); the upgrade manifest contains the expected SHA256 value; the local truncated package file exists, and LOCAL_SIZE >= EXPECTED_SIZE.

[0062] 2. The reason for using "greater than or equal to" instead of strictly equal to is as follows: The size exactly equal to the expected total size is the most typical case of a pseudo-complete package (forced termination during disk writing, truncation at the end but the size statistics are full); the size greater than the expected total size is an abnormal case (such as the server changing the package file and the manifest not being synchronized, abnormal splicing residue), which also triggers pre-verification—if there is a mismatch, delete and re-download (safety fallback); if there is a match, allow it (without introducing additional risks). This pre-verification specifically targets the specific engineering fault of "pseudo-complete packages." For half-packages that are damaged at the mid-download breakpoint, the pre-verification is skipped by design (condition not met, zero overhead). The damage is discovered by the final SHA256 verification of the entire package after the resumed download, and the conventional fallback path of deletion and full re-download is followed, incurring only one additional download cost and not constituting an infinite loop.

[0063] 3. Verification and comparison: When the conditions are met, the script calls the system hash tool (sha256sum) to calculate the SHA256 checksum hash value of the local file and compares it with the expected hash value in the upgrade manifest (manifest.json).

[0064] 4. Flow splitting logic: Check for mismatch (self-healing of corrupted packets): If the calculated value does not match the expected value, the current half-packet is determined to be an abnormally corrupted pseudo-complete bad packet. The script logs an indication that the resumed packet is corrupted (complete in size but SHA256 does not match), executes `rm -f "$PKG_PATH"` to completely delete the corrupted packet, switches the current download mode from resume download to full download mode, restarts the download tool to fetch from byte 0, eliminates the bad packet, and breaks the infinite loop.

[0065] Verification Match (Complete Download): If the calculated value matches the expected value exactly, it indicates that the file has actually been written completely and correctly. The script skips the subsequent download stage and proceeds to the decompression and installation stage.

[0066] Size not up to standard (conventional resumption): If LOCAL_SIZE < EXPECTED_SIZE, it indicates that the file is in a normal intermediate truncated transmission state. This pre-verification logic directly skips as designed, and allows the script to call curl -C - with zero overhead to directly request the remaining data interval from the server (timing sequence t12). For local data block corruption in this state, the conventional final verification after resumption completion will provide fallback interception.

[0067] Through the above pre-verification, the detection and repair of bad packets are moved forward to before resumption is started, compressing an inevitably failed full download cycle into a local hash verification, and eliminating the resumption infinite loop caused by pseudo-complete packets.

[0068] Embodiment Four This embodiment describes the execution details of breakpoint resumption, dynamic re-anchoring of the starting byte count, and the adaptive protection mechanism for network anomalies.

[0069] I. Dynamic On-site Re-anchoring of Physical Size As shown Figure 2 in the timing sequence t10, before restarting the script subprocess, the GUI main process reads the real byte size of the half-upgrade package stored in the / tmp directory at the current physical moment on-site through the operating system file status interface (such as QFileInfo::size() of Qt or the stat system call of POSIX), and uses this physical read value as the starting byte count reference for interface calculation and progress display, instead of using the progress value cached in the memory at the pause moment.

[0070] During the period from pause to resumption, if there is an abnormal situation such as a residual process continuing to write to the disk, the actual size of the half-upgrade package may change. By re-reading the file size from the underlying physical disk immediately before initiating resumption, it is ensured that the breakpoint starting point held by the GUI main process is re-anchored and aligned at the same moment with the starting point of the HTTP Range request initiated by curl to the server on the script subprocess side (curl also calculates the offset based on the current actual physical size of the file through the -C - parameter), so that the interface progress calculation remains continuous, without rollback or drift.

[0071] II. Dual Upper Limits of Download Loop Retry and Capability Degradation The script subprocess continues downloading from the breakpoint in curl -C - mode, and its outer download management adopts a while loop architecture with multiple robustness protections: 1. Dual Retry Limits: The outer retry loop is configured with both a maximum number of retries (default 300) and a maximum cumulative offline waiting time (default 9000 seconds, or 2.5 hours). Both limits work together; the loop exits and reports an error as soon as either threshold is reached, preventing the script from suspending indefinitely and consuming system resources in extreme scenarios such as unplugging the network cable or network outages. The reason for setting dual limits instead of just a retrieval limit is to avoid the combination of a "retry limit + long single-timeout" causing the actual waiting time to far exceed expectations. Built-in parameters in the download tool (such as curl configuration `--retry 10 --retry-connrefused`) are used to cover momentary network jitter.

[0072] 2. Server Range Capability Adaptive Degradation: In resume mode, if the remote server environment is abnormal and does not support HTTP Range slice requests, curl will return exit code 33 (cannot resume) or HTTP status code 416. Upon detecting this exit code, the script automatically determines that the server does not support resume, proactively deletes the local half-packet, and downgrades the mode to a full download to restart, avoiding repeated failures on servers that do not support resume.

[0073] 3. Disk Space Pre-check: After each retry, the actual downloaded file size is checked against the expected total size. If the size is insufficient, the retry continues. Before each retry, the script uses the df command to check the remaining available space on the storage medium. When the remaining available space is lower than the preset storage threshold (set to 1GB in this embodiment), the download loop is actively terminated and a storage error is reported, instead of repeatedly retrying due to a network error.

[0074] Example 5 This embodiment illustrates the system fault tolerance mechanism under conditions of multi-component serial upgrades, system power failure, and process crash windows.

[0075] I. Stage Marker Rotation and Sentinel Management for Multi-Component Serial Upgrades In embedded devices, a single software upgrade often involves the sequential upgrade of multiple strongly related components (such as the front-end plugin package, the back-end service package (webapi), and the main program software app). A three-marker state machine employs a stateless round-robin multiplexing mechanism when multiple components are upgraded sequentially. 1. Stage Marker Rotation: The three marker files represent the "currently progressing global lifecycle stage," rather than the persistent properties of a specific component. For any currently processed component: 2. When entering the current component download phase, the script writes the ota_downloading flag, at which point the user is allowed to pause or cancel.

[0076] 3. After the component is downloaded and verified to be correct, the script clears the ota_downloading flag and writes the ota_extracting installation lock flag to the disk.

[0077] 4. The script executes the decompression, overwrite, and service reload of this component. During this process, the GUI main process reads the ota_extracting flag and strictly rejects pause and cancel operations on the interface.

[0078] 5. After the component is successfully installed, the script clears the `ota_extracting` flag. The working directory then returns to its initial state without stage flags, freeing up semantic space for the download of the next component. The sequential execution of components naturally guarantees atomicity due to the serial execution of the script.

[0079] 6. Sentinel Lifecycle Dynamic Binding: Background paused sentinel child processes are dynamically created and destroyed strictly according to the component download lifecycle. Before each component starts downloading, the script re-spawns a sentinel child process using the upgrade package path specific to the current component; after the component download ends and exits, the sentinel is immediately and actively recycled based on the recorded PID to prevent the sentinel from misreading the marker and causing unexpected actions during subsequent component installations.

[0080] II. Lock detection and deadlock release procedures after abnormal power failure of the whole machine Because the installation lock flag `ota_extracting` is persisted in the storage medium, if a hardware power failure or abnormal restart occurs in the critical section of the device during decompression and installation, the lock flag will remain on the disk after the system restarts. Without a self-healing mechanism, the GUI main process after booting will permanently read the flag, causing the device to fall into a deadlock state where it is "permanently prohibited from canceling and unable to initiate new upgrades".

[0081] For this fault condition, such as Figure 3 As shown in the top-level diagram, the system is constructed with the following power outage recovery detection logic: 1. Initial Boot Scan: When the device reboots and the GUI main process starts, the GUI main process actively scans the $OTA_DIR directory during the initialization phase. If the ota_extracting flag file is detected, the interface will first display an upgrade lock protection state to prevent the user from interrupting the installation, which may still be in progress, under uncertain conditions.

[0082] 2. Script liveness detection: The GUI main process immediately checks the operating system for any ongoing shell script processes that are still running in the background during installation using system process detection commands (such as pgrep -f soft_ota.sh). 3. Survival scenario: If the relevant script process is detected to still be alive (e.g., only the GUI interface crashes and restarts, while the underlying upgrade script continues to execute), the GUI main process remains locked, the upgrade reporting continues in the background, and new tasks are refused to be initiated.

[0083] 4. Crash Residual Scenario: If it is confirmed that there is no surviving OTA script child process in the current system (the script has been destroyed due to a power outage), the GUI main process determines that the current ota_extracting flag belongs to the crash residual flag left over from the previous power outage.

[0084] 5. Deadlock Resolution and Pre-upgrade Cleanup: After confirming that the issue is a crash remnant, the GUI main process displays a message to the user indicating that the last upgrade was interrupted and reopens the upgrade trigger entry. When the user initiates a new upgrade task, the script subprocess, during the pre-upgrade cleanup phase, forcibly removes all residual ota_extracting, ota_paused, and ota_downloading marker files from the disk. For any remaining incomplete packages in the temporary directory, the pre-verification mechanism in Implementation Example 3 handles them; abnormally sized bad packages are identified, deleted, and re-downloaded, thus enabling the device to automatically recover to a clean, upgradeable state after a hardware power outage.

[0085] 6. If the script fails and exits at any step, it should proactively delete ota_extracting before exiting to prevent residual locks from blocking subsequent operations.

[0086] III. Protection against three crash windows during the pause process During the pause control process, the system provides the following fault tolerance guarantees to address potential process crashes: 1. Window 1 (Script child process crashes and exits after script liveness verification passes but before writing the marker): The pause marker file subsequently written by the GUI main process becomes a dangling marker, which will not be consumed by terminated scripts. Subsequent termination of the process group by the GUI main process has no actual impact; the script's end callback reports the true exit result and will not be mistakenly interpreted as paused; this dangling marker is cleared during the cleanup phase of this upgrade session.

[0087] 2. Window 2 (script subprocess crashes and exits after writing the mark and before setting the pause intent flag): The script exits normally according to its exit code, and the dangling mark is also deleted during session cleanup.

[0088] 3. Window 3 (after the mark is written and the pause intent flag is set): Enter the normal pause process. The exit cleanup program of the script subprocess senses the completion of the traffic diversion and cleanup of the retained half-packets.

[0089] Regardless of the type of window, the existence time of the dangling marker is limited to the period between the end of the current session and the start of the next upgrade, and it is uniformly cleared before the start of the new upgrade. There is no path where the marker is dangling indefinitely.

[0090] Example 6 This embodiment illustrates the physical implementation of the hardware device, electronic device, and storage medium that carry the above control method.

[0091] I. Modular Architecture of OTA Download Control Device like Figure 1 As shown, this embodiment provides an OTA download control device deployed in an embedded device, where each functional module works collaboratively under the scheduling of the device processor and operating system: 1. Upgrade Startup Module: Integrated into the GUI main process, it is used to respond to user upgrade commands. It starts a Shell script subprocess in an independent process group through a process startup interface (such as QProcess) and in combination with setsid and sudo. The script subprocess is driven to execute the curl download tool in a foreground blocking manner, and a background sentinel subprocess is launched before execution.

[0092] 2. Tag Creation Module: Integrated into the GUI main process, it is used to respond to pause requests. After the execution status verification and script liveness verification pass, it writes a persistent ota_paused tag file to the preset directory of the storage medium.

[0093] 3. Sentinel Control Module: Running in the background sentinel child process, it polls the ota_paused flag every 0.3 seconds. When the flag is detected, it constructs an escaped command line mode according to the path of the upgrade package to be downloaded, accurately sends the SIGTERM signal to the foreground download tool, and automatically terminates when the parent script exits via probe signals during operation. After the download is completed normally, it actively terminates and reclaims the sentinel child process based on the process identifier recorded by the script.

[0094] 4. Triage and Cleanup Module: The EXIT trap program, which runs in a Shell script subprocess, reads disk stage markers after the download tool exits and performs tripping based on the marker combination: when ota_paused is detected, it retains the half-packet, deletes the marker, and exits explicitly; when only the download marker is present, it deletes the half-packet and the marker; when the installation lock marker is detected, it preserves the current state and blocks the interruption operation.

[0095] 5. Resume Control Module: This module works in collaboration between the GUI main process and the script subprocess. Upon receiving a resume command, it clears the ota_paused flag, and the GUI main process rereads the physical size of the local half-packet to align with the resume start point. Before restarting the download tool on the script side, it performs SHA256 hash comparison on local packets that are the size of the expected packet or larger. If there is a mismatch, the bad packet is deleted and the download is reset to full size; if there is a match, the download is allowed.

[0096] II. Hardware Implementation of Electronic Devices and Computer-Readable Storage Media This embodiment also provides an electronic device, including a memory and a processor. The memory includes volatile random access memory and non-volatile persistent storage media (such as flash memory, solid-state drives, etc.). The persistent storage media is divided into a storage partition (such as / opt / ota) for storing upgrade programs and system configuration files and a temporary data exchange partition (such as / tmp), and stores computer-executable program code and a state machine file composed of stage markers.

[0097] The processor includes one or more multi-core central processing units, and is physically and electrically connected to memory, network communication interfaces, and a graphics display controller via an internal system bus. The processor is configured to invoke computer programs stored in memory to schedule and execute the various steps of the OTA download control methods described in Embodiments 1 to 5 at the hardware level.

[0098] This embodiment also provides a computer-readable storage medium, which is a non-transitory computer-readable storage medium (such as a flash memory chip, a solid-state drive, an optical disc, etc.), on which a computer program is stored. When the computer program is read and executed by the processor of an electronic device, it causes the processor to execute the OTA download control method of any one of embodiments one to five above.

[0099] It should be noted that the specific examples in this embodiment can refer to the examples described in the above embodiments and optional implementations, and will not be repeated here.

[0100] Generally, various embodiments can be implemented in hardware or dedicated circuitry, software, logic, or any combination thereof. Some aspects of the invention can be implemented in hardware, while others can be implemented by firmware or software executed by a controller, microprocessor, or other computing device, but the invention is not limited thereto. Although various aspects of the invention may be shown and described as block diagrams, flowcharts, or using some other graphical representation, it should be understood that, by way of non-limiting example, these blocks, apparatuses, systems, techniques, or methods described herein can be implemented in hardware, software, firmware, dedicated circuitry or logic, general-purpose hardware or controllers or other computing devices, or some combination thereof.

[0101] Embodiments of the present invention can be implemented by computer software, which may be executable by a data processor of a mobile device, such as a processor entity, or by hardware, or by a combination of software and hardware. Computer software or programs (also referred to as program products) including software routines, applets, and / or macros can be stored in any device-readable data storage medium, and they include program instructions for performing specific tasks. The computer program product may include one or more computer-executable components configured to perform the embodiments when the program is run. The one or more computer-executable components may be at least one piece of software code or a portion thereof. Additionally, it should be noted in this respect that, as Figure 1 Any box in the logical flow can represent a program step, or interconnected logic circuits, boxes and functions, or a combination of program steps and logic circuits, boxes and functions. Software can be stored on physical media such as memory chips or blocks of storage implemented within a processor, magnetic media such as hard disks or floppy disks, and optical media such as DVDs and their data variants, CDs, etc. The physical medium is a non-transient medium.

[0102] Those skilled in the art should understand that the technical features of the above embodiments can be combined in any way. For the sake of brevity, not all possible combinations of the technical features in the above embodiments have been described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this specification.

[0103] The above embodiments are merely illustrative of several implementations of the present invention, and their descriptions are relatively specific and detailed, but they should not be construed as limiting the scope of the present invention. It should be noted that those skilled in the art can make various modifications and improvements without departing from the concept of the present invention, and these all fall within the protection scope of the present invention. Therefore, the protection scope of the present invention should be determined by the appended claims.

Claims

1. An OTA download control method, characterized in that, Includes the following steps: In response to an upgrade trigger command, a script subprocess is started through the GUI main process, and the script subprocess executes the download tool in the foreground to download the upgrade package. The script subprocess starts a sentinel subprocess running in the background before executing the download tool. In response to a pause request, the GUI main process creates a persistent pause marker file in a preset path on the storage medium. The storage medium maintains stage markers for indicating upgrade stages, and the stage markers include at least the pause marker file. The sentinel subprocess periodically polls the preset path, and when it detects the pause marker file, it sends a termination signal to the download tool so that the download tool, which is running in the foreground, responds to the termination signal and exits. After the download tool exits, the script subprocess is triggered to execute a pre-registered exit cleanup program. The exit cleanup program performs traffic splitting based on the stage marker. When the pause marker file is detected, the downloaded half of the upgrade package is retained and the script subprocess is controlled to exit. In response to the resume command, the pause marker file is cleared by the GUI main process, and the script subprocess is restarted to continue downloading the upgrade package from the breakpoint of the half-finished upgrade package.

2. The OTA download control method as described in claim 1, characterized in that, In response to a pause request, after the GUI main process creates a persistent pause marker file in a preset path on the storage medium, the method further includes: sending a termination signal to the process group where the script subprocess is located through the GUI main process. The main channel, in which the GUI main process sends a termination signal to the process group, and the fallback channel, in which the sentinel child process polls the pause marker file and sends a termination signal to the download tool, are executed in parallel. The download tool is triggered to exit by the termination signal that is delivered to the download tool first. During the period when the GUI main process receives the pause request and sets the pause intention flag, it actively blocks the download progress timeout monitoring and processing logic so that the pause process takes precedence over the timeout determination.

3. The OTA download control method as described in claim 1, characterized in that, While the sentinel subprocess is running in the background, it sends probe signals to the script subprocess to detect the liveness of the script subprocess. When the script subprocess is detected to have exited, the sentinel subprocess automatically exits. Sending a termination signal to the download tool includes: the sentinel subprocess precisely matching the download tool and initiating a termination signal in a command-line mode containing the path to the upgrade package to be downloaded; After the download tool completes the download normally, the script subprocess will actively terminate and reclaim the sentinel subprocess based on the recorded process identifier of the sentinel subprocess before entering the decompression and installation stage. The polling period for the preset path by the sentinel subprocess is 0.3 seconds.

4. The OTA download control method as described in claim 1, characterized in that, The stage markers include download stage markers, pause marker files, and installation lock markers; The exit cleanup process performs triage based on the stage markers, including: When the pause marker file is detected, delete the pause marker file and the download stage marker, retain the half-upgrade package, and exit the script subprocess with an explicit exit code; If the pause marker file is not detected and the download stage marker exists, delete the half-upgrade package and the download stage marker; Upon detecting the installation lock marker, the installation state is preserved, and the cancellation and pause requests for the upgrade process are rejected through the GUI main process; In the exit cleanup process, the deletion of stage markers is performed before the deletion of files, and the exit is allowed by default when the storage medium is in an unmarked state.

5. The OTA download control method as described in claim 1, characterized in that, It also includes a pre-verification step before resuming interrupted downloads: After restarting the script subprocess and before restarting the download tool, when it is detected that the partial upgrade package already exists locally and its file size is greater than or equal to the expected total size in the upgrade list, the verification hash value of the partial upgrade package is calculated, and the verification hash value is compared with the expected hash value in the upgrade list. If the comparison does not match, the half-upgrade package is determined to be a corrupted package. The half-upgrade package is then deleted, and the download tool is restarted in full download mode to download the entire package. If a match is found, the process is allowed to proceed to the next stage. If the file size of the partial upgrade package is smaller than the expected total size, the download tool will be launched directly to resume the download from where it was interrupted.

6. The OTA download control method as described in claim 5, characterized in that, Before restarting the script subprocess, the GUI main process obtains the physical file size of the half-upgrade package at the current moment through the file system interface as the starting number of bytes for resuming the download, so as to anchor and align with the start point of the breakpoint request initiated by the script subprocess to the remote server when it re-executes the download tool at the same time. The script subprocess, in the loop of executing download in breakpoint resume mode, simultaneously configures a preset retry count threshold and a preset cumulative waiting time threshold. When the download tool returns an error code indicating that the remote server does not support the breakpoint range request, the script subprocess deletes the half-upgrade package and automatically downgrades the download mode to the full download mode; Before each retry, the script subprocess checks the remaining available space of the storage medium. If the remaining available space is lower than a preset storage threshold, it exits the download loop and reports a storage error.

7. The OTA download control method as described in claim 4, characterized in that, When the upgrade package contains multiple components to be upgraded and each component is downloaded and installed serially, a download stage marker is written when the current component enters the download stage, the download stage marker is cleared and the installation lock marker is written when the current component is downloaded, and the installation lock marker is cleared when the current component is installed or fails. The sentinel subprocess is started before each component enters the download stage and is recycled after the download of that component is completed. When the upgrade process is interrupted and restarted due to an abnormality, the GUI main process scans the storage medium during the initialization phase. If the installation lock mark is detected, the lock state is restored and the script subprocess is checked for survival. If no script subprocess is found to be alive, the installation lock mark is determined to be a crash remnant. Before starting a new upgrade task, the residual phase mark is cleared, and the integrity check is performed on the residual half-upgrade package to determine whether to resume the download or download it again.

8. An OTA download control device, characterized in that, include: The upgrade startup module is used to respond to the upgrade trigger command by starting a script subprocess through the GUI main process, and the script subprocess executes the download tool in the foreground to download the upgrade package. The script subprocess starts a sentinel subprocess running in the background before executing the download tool. A marker creation module is used to create a persistent pause marker file in a preset path of the storage medium through the GUI main process in response to a pause request. The storage medium maintains stage markers for indicating upgrade stages, and the stage markers include at least the pause marker file. The sentinel control module is used to periodically poll the preset path through the sentinel subprocess, and when the pause marker file is detected, send a termination signal to the download tool so that the download tool, which is running in the foreground, responds to the termination signal and exits. The diversion and cleanup module is used to trigger the script subprocess to execute a pre-registered exit cleanup program after the download tool exits. The exit cleanup program performs diversion processing according to the stage marker. When the pause marker file is detected, the downloaded half of the upgrade package is retained and the script subprocess is controlled to exit. The resume control module is used to respond to the resume command by clearing the pause marker file through the GUI main process and restarting the script subprocess to continue downloading the upgrade package from the breakpoint of the half-finished upgrade package.

9. An electronic device comprising a memory and a processor, characterized in that, The memory stores a computer program, and the processor is configured to run the computer program to perform the OTA download control method according to any one of claims 1 to 7.

10. A readable storage medium, characterized in that, The readable storage medium stores a computer program that, when executed by a processor, implements the OTA download control method as described in any one of claims 1 to 7.

Images