Application hot repair method, electronic equipment and vehicle

Abstract

The invention relates to the field of data processing, and provides an application hot repair method, electronic equipment and a vehicle, an application update instruction and a patch path are received, a hot repair server determines a to-be-repaired application corresponding to the application update instruction, and the to-be-repaired application is controlled to start; the hot repair server sends the patch path to a hot repair client corresponding to the to-be-repaired application; and in response to the patch path received by the hot repair client, performing hot repair processing on the to-be-repaired application according to the patch path, and feeding back a repair result to the hot repair server. After the hot repair server receives the application updating instruction, the to-be-repaired application is controlled to be started, and the problem that the to-be-repaired application is still in a background state and background limitation of an Android system occurs due to the fact that broadcast is only sent to the to-be-repaired application is avoided. And the repair result is fed back to the hot repair server to form a closed-loop link, so that the process interruption caused by loose module cooperation and state black box is avoided, and the integrity and reliability of the hot repair process are improved.

Description

Technical Field

[0001] This disclosure relates to the field of data processing, and more particularly to an applied thermal repair method, electronic devices, and vehicles. Background Technology

[0002] Software updates for in-vehicle infotainment systems (IVI), especially application-level software updates, place extremely high demands on reliability and user experience. Online hotfixes, as a technology that can quickly fix online issues without requiring a full system update, have significant application value in the automotive field.

[0003] Currently, during the hotfix process, after the upper-layer system downloads the patch package, it sends a broadcast to the target application. If the target application has not yet started, the system will attempt to launch a background process in response to the broadcast. However, due to various restrictions on background behavior in the Android system, the hotfix may fail. Summary of the Invention

[0004] In view of this, the purpose of this disclosure is to propose an application hotfix method, electronic device, and vehicle to solve the problem that when the upper-layer system downloads a patch package and sends a broadcast to the target application, if the target application has not yet started, it faces various restrictions on background behavior by the Android system, thus causing the hotfix to fail.

[0005] To achieve the above objectives, a first aspect of this disclosure provides a method for applying thermal repair, the method comprising: Upon receiving the application update instruction and patch path, the hotfix server determines the application to be repaired corresponding to the application update instruction and controls the application to be repaired to start. The hotfix server sends the patch path to the hotfix client corresponding to the application to be fixed. In response to the hotfix client receiving the patch path, the hotfix client performs hotfix processing on the application to be fixed according to the patch path and feeds back the repair result to the hotfix server.

[0006] Based on the same inventive concept, a second aspect of this disclosure proposes an application of a thermal repair device, comprising: The application startup module is configured to receive an application update instruction and patch path, and the hotfix server determines the application to be repaired corresponding to the application update instruction and controls the startup of the application to be repaired. The path sending module is configured to send the patch path from the hotfix server to the hotfix client corresponding to the application to be fixed. The result feedback module is configured to respond to the hotfix client receiving the patch path, perform hotfix processing on the application to be fixed according to the patch path, and feed back the repair result to the hotfix server.

[0007] Based on the same inventive concept, a third aspect of this disclosure proposes an electronic device, including a memory, a processor, and a computer program stored in the memory and executable by the processor, wherein the processor, when executing the computer program, implements the application hot-fix method as described above.

[0008] Based on the same inventive concept, a fourth aspect of this disclosure provides a non-transitory computer-readable storage medium storing computer instructions for causing a computer to execute the application hotfix method as described above.

[0009] Based on the same inventive concept, the fifth aspect of this disclosure provides a vehicle including the thermal repair device described in the second aspect, the electronic device described in the third aspect, or the storage medium described in the fourth aspect.

[0010] As can be seen from the above, this disclosure proposes an application hotfix method, electronic device, and vehicle. Upon receiving an application update instruction and patch path, the hotfix server determines the application to be repaired corresponding to the application update instruction and controls the application to be repaired to start. After receiving the application update instruction, the hotfix server controls the application to be repaired to start, avoiding the problem of the application not starting and remaining in the background, thus avoiding the background restriction problem of Android system, which could occur if only a broadcast is sent to the application to be repaired. At the same time, the hotfix server sends the patch path to the hotfix client corresponding to the application to be repaired. In response, the hotfix client receives the patch path, performs hotfix processing on the application to be repaired according to the patch path, and feeds back the repair result to the hotfix server. The hotfix server sends the patch path to the hotfix client, and the hotfix client performs hotfix processing on the application to be repaired according to the patch path, and then feeds back the repair result to the hotfix server, forming a closed-loop link. This avoids process interruption and unknown result problems caused by loose module cooperation and state black box, and improves the integrity and reliability of the hotfix process. Attached Figure Description

[0011] To more clearly illustrate the technical solutions in this disclosure or related technologies, the accompanying drawings used in the description of the embodiments or related technologies will be briefly introduced below. Obviously, the accompanying drawings described below are only embodiments of this disclosure. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0012] Figure 1 This is a flowchart of the application of the hot-repair method according to an embodiment of the present disclosure; Figure 2 This is a flowchart of an application hot-repair method according to another embodiment of this disclosure; Figure 3 This is a structural block diagram of the application thermal repair device according to an embodiment of the present disclosure; Figure 4 This is a schematic diagram of the structure of an electronic device according to an embodiment of the present disclosure. Detailed Implementation

[0013] To make the objectives, technical solutions, and advantages of this disclosure clearer, the following detailed description is provided in conjunction with specific embodiments and the accompanying drawings.

[0014] It should be noted that, unless otherwise defined, the technical or scientific terms used in the embodiments of this disclosure should have the ordinary meaning understood by one of ordinary skill in the art to which this disclosure pertains. Words such as "comprising" or "including" mean that an element or object preceding the word encompasses the elements or objects listed following the word and their equivalents, without excluding other elements or objects. Words such as "connected" or "linked" are not limited to physical or mechanical connections, but can include electrical connections, whether direct or indirect.

[0015] The following are definitions of terms used in this disclosure: Android: Android is a free and open-source mobile operating system based on the Linux kernel (excluding GNU components).

[0016] Hotfix: A patch is a patch released after software is published to fix vulnerabilities or problems that have been discovered.

[0017] LOTA: Link-On-The-Air (LOTA) is a commonly used term in the automotive industry, referring to the technology of software upgrades via the cloud.

[0018] Foreground Service: An Android foreground service used to perform user-perceptible tasks. It has a high system priority and must display a persistent notification in the notification bar.

[0019] Software updates for in-vehicle infotainment systems (IVI), especially application-level software updates, place extremely high demands on reliability and user experience. Online hotfixes, as a technology that can quickly fix online issues without requiring a full system update, have significant application value in the automotive field. The entire hotfix process is a complex systems engineering project, typically involving collaboration among the following key roles: The LOTA System is the highest-level update strategy decision-maker and task initiator located in the cloud.

[0020] The hotfixservice (hotfix server / communication hub) is a background service that resides permanently in the vehicle system. Its core responsibility is to act as a communication hub: on one hand, it listens for and receives update commands from the upper-layer LOTA system; on the other hand, it accurately distributes these commands to the target applications that need hotfixes by initiating inter-process communication (IPC) mechanisms such as launching the target application's Activity. Simultaneously, it is also responsible for receiving the final execution results returned by the client and reporting them to the LOTA system.

[0021] hotfixclient is an SDK encapsulated within the target application, responsible for executing all specific patch installation, monitoring, and circuit breaker logic.

[0022] Third-party hotfix frameworks (such as Tinker) act as the "engine" that provides core patch synthesis capabilities.

[0023] Currently, after downloading a patch, the LOTA client typically notifies the target application that a patch needs to be installed by sending a broadcast. If the target application process has not yet started, the system will attempt to launch a background process in response to the broadcast. In this initial background startup state, if the application immediately executes the hotfix process, it will directly encounter various restrictions on background behavior by the Android system, such as restrictions on background service startup, causing the update to fail from the very beginning.

[0024] Meanwhile, during the lengthy patch installation process, users may switch the application to the background at any time, causing the update to fail due to background service startup restrictions. Furthermore, Tinker's execution process itself is a 'black box'; it may silently die due to internal crashes or system detection, leaving the client in an infinite wait with an 'unknown state,' which is also a major fatal risk in the execution phase.

[0025] Finally, after Tinker completes its execution, the application client only processes the result internally. The LOTA system, as the initiator and ultimate responsible party for the entire update process, cannot clearly and reliably obtain the final execution result of this task. It doesn't know whether the patch was installed successfully, failed, or encountered an error. This prevents LOTA from making effective subsequent decisions, such as providing users with a clear success or failure message, developing effective retry strategies after a failure, or performing accurate data statistics and problem analysis in the cloud.

[0026] Based on the above description, and addressing the issues of insufficient overall reliability in current hotfix systems due to improper triggering methods, lack of execution process guarantees, and missing feedback links, this embodiment proposes an application-based hotfix method, such as... Figure 1 As shown, the method includes: Step 101: Upon receiving the application update instruction and patch path, the hotfix server determines the application to be repaired corresponding to the application update instruction and controls the application to be repaired to start.

[0027] In practice, once the upper-layer system detects the target patch package for the application to be repaired, it indicates that the application needs to be updated. The upper-layer system then downloads and stores the target patch package, and sends an application update command and the patch path of the target patch package to the hotfix server. The patch path is a unique path to obtain the target patch package, corresponding to its storage path within the upper-layer system.

[0028] In this embodiment, the application update instruction includes the application to be repaired, and the application update instruction is used to notify the hotfix server to update the application to be repaired according to the target patch package in the patch path.

[0029] In this embodiment, in order to reduce the amount of data transmitted and reduce the risk of leakage of the target patch package, when the upper-layer system transmits to the hotfix server, it only transmits the patch path of the target patch package, and does not directly transmit the target patch package.

[0030] In this embodiment, the upper-layer system is the highest-level update strategy decision-maker and task initiator. For example, the upper-layer system is a cloud-based LOTA system, where the LOTA system is the highest-level update strategy decision-maker and task initiator located in the cloud.

[0031] The application update instruction contains the application to be repaired. After receiving the application update instruction and patch path sent by the upper layer system, the hotfix server determines the application to be repaired corresponding to the application update instruction and controls the application to be repaired to start.

[0032] Step 102: The hotfix server sends the patch path to the hotfix client corresponding to the application to be fixed.

[0033] In practice, after the hotfix server controls the application to be repaired to start, it sends the patch path to the hotfix client corresponding to the application. The hotfix client is a module integrated into the application to be repaired, used to execute application update instructions based on the patch path, that is, to perform hotfix processing on the application to be repaired according to the patch path.

[0034] In this embodiment, the hotfix server is a background service that resides permanently in the vehicle system. As a communication hub, the hotfix server is responsible for two aspects: firstly, listening for and receiving application update instructions and patch paths from the upper-layer system; secondly, accurately distributing application update instructions to the target applications requiring hotfix through cross-process communication mechanisms such as targeted broadcasts, i.e., sending the application update instructions and patch paths to the applications to be repaired. Simultaneously, the hotfix server is also responsible for receiving the final execution results returned by the hotfix client and reporting them to the upper-layer system.

[0035] In this embodiment, the hotfix client is a client software development kit (SDK) encapsulated as a standard project management dependency library, namely the Maven dependency library, and the SDK is the software development kit itself. That is, the hotfix client is a client SDK encapsulated as a standard Maven dependency library. Any application that needs to integrate hotfix functionality must depend on this library. The design goal of the hotfix client is non-intrusive and easy to integrate. Application developers typically only need to call the `init()` method once during the initialization phase of their application to complete all necessary settings and background listening. In this embodiment, the core logic for ensuring reliability is encapsulated within this hotfix client.

[0036] Step 103: In response to the hotfix client receiving the patch path, perform hotfix processing on the application to be repaired according to the patch path, and feed back the repair result to the hotfix server.

[0037] In practice, the hotfix client obtains the target patch package corresponding to the patch path, and performs hotfix processing on the application to be repaired based on the target patch package, that is, updates the application to be repaired using the target patch package.

[0038] After the hotfix process is completed, the repair result is obtained and fed back to the hotfix server. Then, after receiving the repair result, the hotfix server sends the repair result to the upper layer system.

[0039] In some embodiments, when the hotfix server sends the patch path to the hotfix client corresponding to the application to be repaired, the patch path can be sent via broadcast. That is, in step 102, the hotfix server sends the patch path to the hotfix client corresponding to the application to be repaired, specifically including: Step 1021: The hotfix server sends a target broadcast to the hotfix client corresponding to the application to be fixed, wherein the target broadcast contains the patch path; Step 1022: The hotfix client uses a broadcast receiver to receive the target broadcast, parses the target broadcast, and obtains the patch path contained in the target broadcast.

[0040] In practice, after the hotfix server controls the application to be repaired to start, it sends a target broadcast to the hotfix client corresponding to the application to be repaired, wherein the target broadcast contains the patch path.

[0041] The hotfix client receives the target broadcast using a broadcast receiver, wherein the broadcast receiver is a statically registered broadcast receiver included in the hotfix client. Upon receiving the target broadcast, the hotfix client parses the target broadcast to obtain the patch path contained within it.

[0042] For example, the broadcast receiver is a StaticLotaPatchReceiver, which is statically registered in AndroidManifest.xml to enable it to receive system broadcasts. Upon receiving a broadcast for a specific Action, patch information is parsed out, including the patch path.

[0043] In some embodiments, during the hotfix process of an Android system application, there is a problem where the result notification service fails to start because the application is switched to the background during patch installation, ultimately causing the entire hotfix process to be interrupted or its status to be unknown. To avoid the problem of the hotfix process being interrupted by the user switching the application to the background, a temporary foreground service is started, so that the system always treats the application to be repaired as a foreground application. That is, in step 103, the response of the hotfix client receiving the patch path, performing hotfix processing on the application to be repaired according to the patch path, and feeding back the repair result to the hotfix server specifically includes: Step 1031: In response to the hotfix client receiving the patch path, a temporary foreground service is started and a countdown begins; Step 1032: The hotfix client obtains the target patch package corresponding to the patch path, performs hotfix processing on the application to be repaired using the target patch package based on the countdown, and feeds back the repair result to the hotfix server.

[0044] In practice, after receiving the patch path from the hotfix server, the hotfix client starts a temporary foreground service and simultaneously begins a countdown. This temporary foreground service is a defined and reliable foreground environment. Regardless of whether the user subsequently switches the application to be repaired to the background, the application is considered a foreground application at the system level and is not subject to the restrictions imposed by Android systems on applications running in the background.

[0045] In this embodiment, the countdown is a pre-set duration, implemented through an external monitoring timer. The countdown corresponds to the maximum allowed duration of the heat repair process; if the countdown ends, the pre-set maximum heat repair process duration has been reached.

[0046] The hotfix client obtains the target patch package corresponding to the patch path, and performs hotfix processing on the application to be repaired based on the countdown and the target patch package, that is, updates the application to be repaired using the target patch package.

[0047] After the hotfix process is completed, the repair result is obtained and fed back to the hotfix server. Then, after receiving the repair result, the hotfix server sends the repair result to the upper layer system.

[0048] The above solution enables the application to be repaired to remain in the foreground throughout the hot repair process by starting a temporary foreground service after the hot repair client receives the patch path. This means that the application to be repaired is always treated as a foreground application during the hot repair process, regardless of whether the user switches the application to be repaired to the background. This removes the restriction on starting services for applications in the background in the Android system, avoids interruptions during the hot repair process, and improves the success rate of hot repair.

[0049] In some embodiments, to improve the success rate of subsequent hotfix processing, after receiving the patch path from the hotfix server, the hotfix client can first verify the validity of the patch path, and only after confirming that the patch path is valid can it start the temporary foreground service. That is, step 1031, which involves the hotfix client receiving the patch path and starting the temporary foreground service, specifically includes: Step 10311: In response to the hotfix client receiving the patch path, the validity of the patch path is verified, and a verification result is obtained; Step 10312: In response to the verification result indicating that the patch path is valid, a security window is created and a temporary foreground service is started.

[0050] In practice, after the hotfix client receives the patch path, it verifies the validity of the patch path and obtains a verification result. The validity verification determines whether the patch path is correct, specifically including whether the patch package can be obtained based on the patch path, and whether the patch package obtained based on the patch path is the correct patch package required by the application to be repaired. The verification result includes whether the patch path is valid or invalid.

[0051] If the verification result shows that the patch path is valid, it means that the patch path validity verification has passed. A security window is created and a temporary foreground service is started. After the temporary foreground service is started, the application to be repaired can be recognized as a foreground service in the system. That is, when the user switches the application to be repaired to the background, the system will consider the application to be repaired to be in the foreground state, thereby removing the restriction on starting other services.

[0052] In this embodiment, the hotfix client includes a central controller and a temporary foreground service module. The central controller is used for subsequent interaction with the hotfix framework, and all hotfix requests are processed by the central controller. The central controller is also used to manage the complete lifecycle of the foreground service. The temporary foreground service module is a lightweight service module used to call the startup class when the security window is created, display a notification, and promote itself to the foreground service, i.e., start the temporary foreground service.

[0053] In this embodiment, the temporary foreground service module does not contain any business logic, and its start and stop are entirely controlled externally by the central controller. That is, the lifecycle of the temporary foreground service is entirely controlled by the external central controller through the start() and stop() methods. This "stateless" design makes it very stable and reliable.

[0054] For example, the central controller is TinkerManager, and the temporary foreground service module is PatchInstallForegroundService. After obtaining the patch path installPath, TinkerManager verifies its validity. Once the patch path is confirmed to be valid, the central controller creates a secure window by starting PatchinstallForegroundService(), and controls the creation and startup of the temporary foreground service module via the start() method. Upon receiving the control command, the temporary foreground service module creates itself via onCreate() and promotes itself to the foreground service. Finally, the central controller begins the asynchronous, time-consuming patch installation process, i.e., the hotfix process, by calling TinkerinstalleronReceiveUpgradePatch().

[0055] In some embodiments, when validating the patch path, it can first be determined whether the patch package can be obtained based on the patch path. That is, the validity verification of the patch path described in step 10311, and the obtaining of the verification result, specifically includes: Step 10A: The hotfix client searches according to the patch path and obtains the search results; Step 10B: In response to the search result being empty, determine that the verification result indicates the patch path is invalid; or, Step 10C: In response to the search result being that the target patch package corresponding to the patch path has been obtained, obtain the target identifier corresponding to the target patch package, and determine the verification result based on the target identifier.

[0056] In practice, the hotfix client searches based on the received patch path, specifically checking if a patch package exists at the location corresponding to the patch path, and obtains the search result. The search result includes whether a patch package exists at the location corresponding to the patch path, or whether a patch package does not exist at the location corresponding to the patch path. If a patch package exists at the location corresponding to the patch path, the search result is that the target patch package corresponding to the patch path has been obtained. If a patch package does not exist at the location corresponding to the patch path, the search result is empty.

[0057] If the search result is empty, it means that the patch package does not exist at the location corresponding to the patch path, i.e., the patch path is abnormal, and subsequent hotfix processing of the application to be repaired cannot be achieved based on the patch path. In this case, the validity verification result of the patch path is determined to be invalid.

[0058] If the search result shows that the target patch package corresponding to the patch path is found, it means that a patch package exists at the location corresponding to the patch path. To further improve the success rate of hotfix processing, the obtained target patch package needs to be further verified, that is, to verify whether the target patch package is the patch package for the application to be repaired. At this time, the target identifier corresponding to the target patch package is obtained, and the verification result is determined based on the target identifier. Here, the target identifier is identification information that distinguishes different applications, that is, different applications have different target identifiers.

[0059] Specifically, obtaining the target identifier corresponding to the target patch package and determining the verification result based on the target identifier includes: Step A: Obtain the target identifier corresponding to the target patch package, and determine the target application corresponding to the target identifier; Step B: In response to the target application being the same as the application to be repaired, determine that the verification result indicates the patch path is valid; or, Step C: In response to the fact that the target application is different from the application to be repaired, the verification result is determined to be that the patch path is invalid.

[0060] In specific implementation, the target identifier corresponding to the target patch package is obtained, and the target application corresponding to the target identifier is determined. Specifically, a search is performed based on the target identifier to obtain the target application corresponding to the target identifier. The target application is compared with the application to be repaired to obtain a comparison result. The comparison result includes whether the target application and the application to be repaired are the same, or whether the target application and the application to be repaired are different.

[0061] If the comparison result shows that the target application is the same as the application to be repaired, the verification result is determined to be that the patch path is valid, that is, the target patch package obtained according to the patch path is the patch package corresponding to the application to be repaired.

[0062] If the comparison result shows that the target application is different from the application to be repaired, it means that the target patch package obtained according to the patch path is not the patch package corresponding to the application to be repaired, that is, the verification result is that the patch path is invalid.

[0063] The above approach, when validating patch paths, first determines whether the patch package can be obtained based on the patch path. If the patch package cannot be obtained, meaning the location corresponding to the patch path is empty, the patch path can be directly determined to be invalid. If the patch package can be obtained, the target patch package corresponding to the patch path is further verified to determine whether the target patch package is the patch package for the application to be repaired. This more thorough validation of patch path validity further improves the success rate of subsequent hotfix processing. Simultaneously, if the patch path is invalid, subsequent steps can be skipped, reducing resource waste.

[0064] In some embodiments, during the hotfix process, if the hotfix client receives the repair result from the hotfix framework before the countdown ends, the temporary foreground service is stopped to avoid wasting resources by continuing to run the temporary foreground service. Specifically, in step 1032, the hotfix client obtains the target patch package corresponding to the patch path, performs hotfix processing on the application to be repaired using the target patch package based on the countdown, and feeds back the repair result to the hotfix server. This includes: Step 10321: The hotfix client obtains the target patch package corresponding to the patch path, calls the preset hotfix framework, and uses the hotfix framework to perform hotfix processing on the application to be repaired based on the target patch package; Step 10322: In response to the hotfix client receiving the repair result from the hotfix framework before the countdown ends, the countdown is stopped and the temporary foreground service is stopped. Step 10323: The hotfix client sends the repair result to the hotfix server; Step 10324: In response to the hotfix server receiving the repair result, the repair result is sent to the cloud.

[0065] In practice, when performing hotfix on the application to be repaired, the hotfix client first obtains the target patch package corresponding to the patch path. Simultaneously, the hotfix client invokes a preset hotfix framework, which provides core patch synthesis capabilities.

[0066] After invoking the hotfix framework, the target patch package and the application to be repaired are synthesized and repaired using the hotfix framework. The core principle of the hotfix framework is to synthesize the target patch package and the application to be repaired to obtain a new application that has fixed the problem.

[0067] For example, the preset hotfix framework is the Tinker framework. The core principle of the Tinker framework is to replace or repair the original problematic classes by dynamically loading classes in the patch package (patch.dex) at runtime, thereby achieving the purpose of code repair.

[0068] If the hotfix client receives the repair result from the hotfix framework before the countdown ends, it indicates that a normal callback from the Tinker black box has been received. At this point, the countdown can be stopped, and the temporary foreground service can be discontinued.

[0069] When starting the temporary foreground service, the hotfix client calls a message handling class, which registers a callback function within the hotfix framework. Therefore, the hotfix framework can be monitored through these callback functions.

[0070] If the hotfix client receives a repair result from the hotfix framework before the countdown ends, that is, if the hotfix client detects that the hotfix framework has provided a repair result, it calls the message processing class to remove the callback function and stops the countdown and the temporary foreground service.

[0071] For example, the hotfix framework is the Tinker framework. After Tinker is installed, it notifies the hotfix client via the onPatchResult() method. If onPatchResult is received before the countdown ends, it indicates that the hotfix client has received a normal callback from the Tinker black box. The hotfix client removes the callback function using the removeCallback method of Handler, thus ending the process normally, canceling monitoring, and stopping the countdown. Simultaneously, the hotfix client calls the stopService() method to stop the temporary foreground service.

[0072] After receiving the repair result from the hotfix framework, the hotfix client sends the repair result to the hotfix server. The hotfix server then receives the repair result and sends it to the cloud, which is the upper-layer system.

[0073] Once the cloud receives the repair result sent by the hotfix server, it displays the repair result. This means the repair result is displayed on the vehicle's infotainment system; that is, after receiving the repair result, the cloud sends it to the vehicle's infotainment system for display.

[0074] Additionally, since applications typically require a restart after an update to display the updated version, after showing the repair results, if the update was successful, the user can be reminded that the changes will take effect upon the next power-on.

[0075] For example, if a hotfix is ​​performed on application A and the received fix result is "update successful", a message can be displayed on the vehicle's infotainment system indicating that application A has been successfully updated and will take effect on the next power-on.

[0076] With the above approach, if the hotfix client receives the repair result from the hotfix framework before the countdown ends, meaning the hotfix process is complete, the temporary foreground service is stopped to avoid wasting resources by continuing to run the temporary foreground service.

[0077] In some embodiments, during the hotfix process, if no repair result is received from the hotfix framework before the countdown ends, the temporary foreground service should be stopped to avoid wasting resources. Simultaneously, because the countdown has ended and the hotfix client has not received the repair result from the hotfix framework, it indicates that the hotfix client is unaware of whether the hotfix framework has completed the hotfix process or whether the application to be repaired has been successfully updated. Furthermore, because the countdown has ended, the temporary foreground service is stopped to avoid resource waste, and to ensure that the upper-layer system that issued the application update command is aware of the result, the hotfix client will send an update failure message. That is, after step 10321, the process further includes: Step 1032A: In response to the countdown ending and the hotfix client not receiving the repair result from the hotfix framework, the temporary foreground service is stopped. Step 1032B: The hotfix client sends an update failure message to the hotfix server; Step 1032C: In response to the hotfix server receiving the update failure information, the update failure information is sent to the cloud.

[0078] In practice, a hotfix framework is used to synthesize and repair the target patch package and the application to be repaired. Once the hotfix process is complete, the hotfix framework will send the repair results back to the hotfix client.

[0079] If the hotfix client does not receive a repair result from the hotfix framework by the end of the countdown, indicating that the Tinker black-box process has silently failed or is unresponsive, a circuit breaker will be triggered, thus stopping the temporary foreground service.

[0080] At this point, the hotfix client sends an update failure message to the hotfix server. Upon receiving this message, the hotfix server forwards it to the cloud, i.e., the upper-layer system in the above embodiment. This informs the upper-layer system that the application update installation failed. Upon the next power-on, the upper-layer system will send the application update command again to retry the update installation.

[0081] With the above approach, if no repair result is received from the hotfix framework after the countdown time has elapsed, an update failure message will be sent to the upper-level system to inform it of the installation failure, thus forming a complete hotfix process and avoiding the problem of the upper-level system being unaware of the failure information.

[0082] Based on the same inventive concept, another embodiment of this disclosure provides a method for applying thermal repair, such as... Figure 2 As shown, the method includes: Once the LOTA system in the cloud detects the target patch package for the application to be repaired, it indicates that the application needs to be updated. At this point, the upper-layer system downloads and stores the target patch package, and sends an application update command and the patch path of the target patch package to the hotfix server.

[0083] The vehicle system service includes a hotfix service, which is called hotfixservice. The hotfix service launches the application activity interface, that is, controls the start of the application to be repaired, and passes the patch path to the application activity interface.

[0084] The application to be repaired calls applyLotaPatch(path) on the active side. The central controller in the hotfix client calls the hotfix framework. The hotfix client is hotfixclient, the central controller is TinkerManager, and the hotfix framework is Tinker framework.

[0085] TinkerManager calls `startService()` to start a temporary foreground service and create a secure window. Upon receiving the control command, the temporary foreground service module `PatchInstallForegroundService` creates itself via `onCreate()` and promotes itself to the foreground. Simultaneously, TinkerManager calls the `postDelayed()` method, setting a countdown timer to 5 minutes. That is, TinkerManager calls `postDelayed(timeoutRunnable, 5min)`, and activates external monitoring. Finally, TinkerManager invokes the Tinker framework, calling `TinkerinstalleronReceiveUpgradePatch()` to begin the asynchronous, time-consuming patch installation process, i.e., the hotfix process.

[0086] The hotfix framework includes a hotfix module and a result feedback module. The hotfix module is TinkerPatchService, and the result feedback module is TinkerResultService. TinkerPatchService performs the most crucial and time-consuming patch merging operation, which combines the downloaded patch file with the application's current base DEX file to generate a new DEX file that fixes the problem. While PatchSvc is still running, the application to be repaired is considered a foreground application, thus circumventing system limitations. TinkerResultService's responsibility is to pass the patch merging result, such as success, failure, and the reason for failure, from the patch process back to the application's main process, i.e., to pass the repair result to TinkerManager.

[0087] TinkerManager invokes the Tinker framework to call TinkerInstaller.install(), initiating an asynchronous, time-consuming patch installation process—the hotfix process. After completing the hotfix process, the hotfix framework provides feedback on the fix result via onPatchResult() within a preset time of 5 minutes.

[0088] Once TinkerManager receives the repair result (i.e., receives a normal callback from the black-box process), it sends a command to the external monitoring timer to unmonitor by calling `removecalbacks(timeoutRunnable)`. Simultaneously, TinkerManager calls `stopService()` to immediately stop the foreground service and destroy the security window. TinkerManager then feeds back the repair result to `hotfixservice`, which in turn feeds back the result to the LOTA system.

[0089] If no repair result is reported via onPatchResult() within the preset 5-minute timeout, indicating a silent failure or unresponsiveness in the Tinker black-box process, the countdown ends, the monitoring timeout expires, the timeoutRunnable is executed, and TinkerManager calls stopService() to immediately stop the foreground service and destroy the security window. TinkerManager then reports the update failure information to hotfixservice, which in turn reports the update failure information to the LOTA system.

[0090] Based on the same inventive concept, another embodiment of this disclosure provides a method for applying thermal repair, the method comprising: Step 201: Upon receiving the application update instruction and patch path, the hotfix server determines the application to be repaired corresponding to the application update instruction and sends the patch path to the hotfix client corresponding to the application to be repaired.

[0091] In practice, once the upper-layer system detects the target patch package for the application to be repaired, it indicates that the application needs to be updated. The upper-layer system then downloads and stores the target patch package, and sends an application update command and the patch path of the target patch package to the hotfix server. The patch path is a unique path to obtain the target patch package, corresponding to its storage path within the upper-layer system.

[0092] In this embodiment, the application update instruction includes the application to be repaired, and the application update instruction is used to notify the hotfix server to update the application to be repaired according to the target patch package in the patch path.

[0093] In this embodiment, in order to reduce the amount of data transmitted and reduce the risk of leakage of the target patch package, when the upper-layer system transmits to the hotfix server, it only transmits the patch path of the target patch package, and does not directly transmit the target patch package.

[0094] In this embodiment, the upper-layer system is the highest-level update strategy decision-maker and task initiator. For example, the upper-layer system is a cloud-based LOTA system, where the LOTA system is the highest-level update strategy decision-maker and task initiator located in the cloud.

[0095] After receiving the application update command and patch path from the upper-layer system, the hotfix server determines the application to be repaired corresponding to the application update command and sends the patch path to the hotfix client corresponding to the application to be repaired. The hotfix client is a module integrated into the application to be repaired, used to execute the application update command according to the patch path, that is, to perform hotfix processing on the application to be repaired based on the patch path.

[0096] In this embodiment, the hotfix server is a background service that resides permanently in the vehicle system. As a communication hub, the hotfix server is responsible for two aspects: firstly, listening for and receiving application update instructions and patch paths from the upper-layer system; secondly, accurately distributing application update instructions to the target applications requiring hotfix through cross-process communication mechanisms such as targeted broadcasts, i.e., sending the application update instructions and patch paths to the applications to be repaired. Simultaneously, the hotfix server is also responsible for receiving the final execution results returned by the hotfix client and reporting them to the upper-layer system.

[0097] In this embodiment, the hotfix client is a client software development kit (SDK) encapsulated as a standard project management dependency library, namely the Maven dependency library, and the SDK is the software development kit itself. That is, the hotfix client is a client SDK encapsulated as a standard Maven dependency library. Any application that needs to integrate hotfix functionality must depend on this library. The design goal of the hotfix client is non-intrusive and easy to integrate. Application developers typically only need to call the `init()` method once during the initialization phase of their application to complete all necessary settings and background listening. In this embodiment, the core logic for ensuring reliability is encapsulated within this hotfix client.

[0098] Step 202: In response to the hotfix client receiving the patch path, a temporary foreground service is started.

[0099] In practice, after receiving the patch path from the hotfix server, the hotfix client starts a temporary foreground service. This temporary foreground service is a defined and reliable foreground environment. Regardless of whether the user subsequently switches the application to be repaired to the background, the application is considered a foreground application at the system level and is not subject to the restrictions imposed by Android systems on applications running in the background.

[0100] Step 203: The hotfix client obtains the target patch package corresponding to the patch path and uses the target patch package to perform hotfix processing on the application to be repaired.

[0101] In practice, the hotfix client obtains the target patch package corresponding to the patch path, and performs hotfix processing on the application to be repaired based on the target patch package, that is, updates the application to be repaired using the target patch package.

[0102] The above scheme, upon receiving an application update command and patch path, determines the application to be repaired corresponding to the application update command and sends the patch path to the hot-repair client corresponding to the application to be repaired. By determining the application to be repaired corresponding to the application update command and then sending the patch path to the hot-repair client corresponding to the application to be repaired, the hot-repair process can be performed on the application to be repaired based on the target patch package corresponding to the patch path, thus improving the accuracy of the hot-repair process. In response to the hot-repair client receiving the patch path, a temporary foreground service is started. The hot-repair client obtains the target patch package corresponding to the patch path and uses the target patch package to perform hot-repair processing on the application to be repaired. After the hot-repair client receives the patch path, by starting the temporary foreground service, the application to be repaired is always treated as a foreground application during the hot-repair process. That is, during the hot-repair process, regardless of whether the user switches the application to be repaired to the background, it is always treated as a foreground application. This removes the restriction on starting services for applications in the background state in the Android system, avoids the problem of interruption during the hot-repair process, and improves the success rate of hot-repair processing.

[0103] In some embodiments, to improve the success rate of subsequent hotfix processing, after receiving the patch path from the hotfix server, the hotfix client can first verify the validity of the patch path. Only after confirming the patch path is valid can the temporary foreground service be started. That is, step 202, which involves the hotfix client receiving the patch path and starting the temporary foreground service, specifically includes: Step 2021: In response to the hotfix client receiving the patch path, the validity of the patch path is verified, and a verification result is obtained; Step 2022: In response to the verification result indicating that the patch path is valid, a security window is created and a temporary foreground service is started.

[0104] In some embodiments, when validating the patch path, it can first be determined whether the patch package can be obtained based on the patch path. That is, the validity verification of the patch path described in step 2021, and the obtaining of the verification result, specifically includes: Step 20211: The hotfix client searches according to the patch path and obtains the search results; Step 20212: In response to the search result being empty, determine that the verification result indicates the patch path is invalid; or, Step 20213: In response to the search result being that the target patch package corresponding to the patch path has been obtained, obtain the target identifier corresponding to the target patch package, and determine the verification result based on the target identifier.

[0105] Specifically, obtaining the target identifier corresponding to the target patch package and determining the verification result based on the target identifier includes: Step A: Obtain the target identifier corresponding to the target patch package, and determine the target application corresponding to the target identifier; Step B: In response to the target application being the same as the application to be repaired, determine that the verification result indicates the patch path is valid; or, Step C: In response to the fact that the target application is different from the application to be repaired, the verification result is determined to be that the patch path is invalid.

[0106] In some embodiments, when performing hot repair on the application to be repaired, the hot repair client can call a preset hot repair framework. That is, in step 203, the hot repair client obtains the target patch package corresponding to the patch path and uses the target patch package to perform hot repair on the application to be repaired. Specifically, this includes: Step 2031: The hotfix client obtains the target patch package corresponding to the patch path and calls the preset hotfix framework; Step 2032: Using the hotfix framework, perform a combined repair process on the target patch package and the application to be repaired to obtain the repaired application.

[0107] In some embodiments, to avoid the temporary foreground service being constantly running in the background and wasting resources, the temporary foreground service can be stopped after the hotfix of the application to be repaired is completed. That is, after step 2032, the following is also included: Step 20A: The hotfix framework sends the repair result back to the hotfix client; Step 20B: In response to the hotfix client receiving the repair result, the temporary foreground service is stopped.

[0108] In practice, a hotfix framework is used to synthesize and repair the target patch package and the application to be repaired. Once the hotfix process is complete, the hotfix framework will send the repair results back to the hotfix client.

[0109] Once the hotfix client receives the repair result from the hotfix framework callback, it can determine that the hotfix process has been completed, and at this point, the temporary foreground service is stopped. The repair result includes either "update successful" or "update failed." If the repair result is "update failed," it also includes the reason for the failure.

[0110] In this embodiment, the hotfix client only verifies the validity of the patch path; that is, it can only determine whether the location corresponding to the patch path contains a patch package, and if so, whether the patch package corresponds to the application to be repaired. However, it does not determine the version information of the target patch package. This means there may be a situation where the version information of the target patch package is lower than the current version information of the application to be repaired. For example, the target patch package might be version 2.0 of application A, while the current version of application A is 3.0. The version information of the target patch package is obtained by the hotfix framework during the hotfix process. When the version information of the target patch package is lower than the current version information of the application to be repaired, the hotfix process cannot be completed; the repair result is a failure, and the reason for the failure is that the version information of the target patch package is lower than the current version information of the application to be repaired.

[0111] For example, the preset hotfix framework is the Tinker framework, which includes a hotfix module and a result feedback module. The hotfix module is TinkerPatchService, and the result feedback module is TinkerResultService. TinkerPatchService is an IntentService running in an independent process, typically the :patch process. The main responsibility of TinkerPatchService is to perform the most critical and time-consuming patch merging operation, which involves combining the downloaded patch file with the application's current base DEX file to generate a new DEX file that fixes the problem. TinkerResultService is also an IntentService, started by TinkerPatchService after the patch merging operation is complete. The responsibility of TinkerResultService is to pass the patch merging result, such as success, failure, and the reason for failure, from the :patch process back to the application's main process so that the application can perform subsequent processing, such as prompting the user or reporting data.

[0112] With the above scheme, once the hot repair framework completes its hot repair process, the repair result is sent to the hot repair client. Upon receiving the repair result from the hot repair framework callback, the hot repair client can determine that the hot repair process has been completed and stop the temporary foreground service. This ensures that the foreground service will not run in the background without reason, perfectly achieving the design goal of temporary and one-time use of the temporary foreground service in this embodiment.

[0113] In some embodiments, the upper-layer system, acting as the highest-level update strategy decision-maker and task initiator, sends application update instructions, which are then followed by modules performing hotfix processing. Therefore, after the hotfix process is complete, the repair results need to be fed back to the upper-layer system. That is, after step 20B, the process further includes: Step 20C: The hotfix client sends the repair result to the hotfix server; Step 20D: In response to the hotfix server receiving the repair result, the repair result is sent to the cloud; Step 20E: After the cloud confirms that the repair result has been received, it displays the repair result.

[0114] In practice, after receiving the repair result from the hotfix framework, the hotfix client sends the repair result to the hotfix server. The hotfix server then receives the repair result and sends it to the cloud, which is the upper-layer system.

[0115] In this embodiment, the startup status of the application to be repaired can also be monitored. Upon detecting a restart, the repaired application is displayed. That is, after step 20E, the following steps are also included: Step 20F: In response to the repair result being a successful update, monitor the startup status of the application to be repaired; Step 20H: The application to be repaired is detected to have restarted, and the repaired application is displayed.

[0116] In practice, if the upper-layer system receives a successful update result, the startup status of the application to be repaired can be monitored. The startup status refers to whether the application to be repaired is running. If the application to be repaired is detected to have restarted (i.e., it goes from starting up to closing and then restarting), it indicates that the application to be repaired has restarted, and the repaired application can then be displayed.

[0117] For example, a vehicle may have a STR (Suspend to RAM) mode, which is essentially "suspending to memory" or "sleeping in memory." This is an advanced power management technology originating from the computer field, designed to enable electronic devices to maintain a fast wake-up capability in a low-power state. When a user triggers the in-vehicle STR mode, the vehicle's infotainment system enters STR mode and closes the current application. Upon exiting STR, when the user opens the application, they will see the updated interface, i.e., the repaired application.

[0118] Based on the same inventive concept, the lifecycle management of temporary foreground services relies entirely on the completion callback of patch services. That is, the main process's controller will only stop the temporary foreground service after the result service has successfully started and notified the main process via callback.

[0119] The execution process of the patch service is a black box; it runs in an independent process and may be permanently suspended or crash abnormally due to various unforeseen reasons. For example, the device may experience excessive I / O load during patch merging, causing the process to become unresponsive. Or, the patch file itself may have problems, leading to uncaught exceptions within the patch service and causing the :patch process to crash directly. Another example is when the device's system resources are extremely strained, killing the :patch process.

[0120] All of the above issues will cause the patch service to never send a completion callback, resulting in the temporary foreground service running indefinitely in the background. This temporary foreground service will continuously drain the user's device battery, even if the user has completely closed the application. Furthermore, a persistent "Updating" notification will appear in the notification bar, which the user cannot clear, causing confusion and annoyance. Additionally, a service that behaves abnormally and cannot be closed automatically may be flagged as "rogue software" by the phone manufacturer's system management or the user, leading to restrictions on its background activity or even prompting the user to uninstall it.

[0121] Therefore, to address the serious problem of application resource leakage, power consumption, and user experience degradation caused by the temporary foreground service running indefinitely and failing to shut down automatically due to abnormal suspension or crashes of the patch service during the current hot-repair process, which ultimately relies on temporary foreground services, this embodiment proposes an application hot-repair method, which includes: Step 301: Upon receiving the patch path, the hotfix client corresponding to the application to be repaired starts a temporary foreground service and begins a countdown.

[0122] In practice, once the upper-layer system detects the target patch package for the application to be repaired, it indicates that the application needs to be updated. The upper-layer system then downloads and stores the target patch package, and sends an application update command and the patch path of the target patch package to the hotfix server. The patch path is a unique path to obtain the target patch package, corresponding to its storage path within the upper-layer system.

[0123] After receiving the application update command and patch path from the upper-layer system, the hotfix server determines the application to be repaired corresponding to the application update command and sends the patch path to the hotfix client corresponding to the application to be repaired. The hotfix client is a module integrated into the application to be repaired, used to execute the application update command according to the patch path, that is, to perform hotfix processing on the application to be repaired based on the patch path.

[0124] After receiving the patch path from the hotfix server, the hotfix client starts a temporary foreground service and simultaneously begins a countdown. This temporary foreground service is a defined and reliable foreground environment. Regardless of whether the user subsequently switches the application to be repaired to the background, the application is considered a foreground application at the system level and is not subject to the restrictions imposed by Android systems on applications running in the background.

[0125] Step 302: The hotfix client obtains the target patch package corresponding to the patch path, calls the preset hotfix framework, and uses the hotfix framework to perform hotfix processing on the application to be repaired based on the target patch package.

[0126] Step 303: In response to the countdown ending and the hotfix client not receiving the repair result from the hotfix framework, the temporary foreground service is stopped.

[0127] In practice, a hotfix framework is used to synthesize and repair the target patch package and the application to be repaired. Once the hotfix process is complete, the hotfix framework will send the repair results back to the hotfix client.

[0128] If the hotfix client does not receive a repair result from the hotfix framework by the end of the countdown, indicating that the Tinker black-box process has silently failed or is unresponsive, a circuit breaker will be triggered, thus stopping the temporary foreground service.

[0129] The above solution, by activating a temporary foreground service, ensures that the application to be repaired remains in the foreground throughout the hotfix process. This means that regardless of whether the user switches the application to the background during hotfix, it is always treated as a foreground application. This removes the restriction on background applications starting services in the Android system, avoiding interruptions during hotfix and improving the success rate of hotfix processing. Upon the countdown ending, if the hotfix client does not receive a repair result from the hotfix framework, the temporary foreground service is stopped. By starting a countdown when the temporary foreground service is activated, if no repair result is received from the hotfix framework by the end of the countdown, it indicates that the hotfix framework may be unable to receive a callback due to system crashes or other reasons. Therefore, the temporary foreground service is stopped, preventing it from being permanently suspended and wasting resources. Furthermore, since the temporary foreground service continuously consumes the user's device battery, it is shut down if no repair result is received by the end of the countdown to prevent further battery drain.

[0130] In some embodiments, to receive subsequent repair results from the hotfix framework, the hotfix client can register a callback function when starting the temporary foreground service. Specifically, upon receiving the patch path as described in step 301, the repair client corresponding to the application to be repaired starts the temporary foreground service and begins a countdown, including: Step 3011: Upon receiving the patch path, the hotfix client corresponding to the application to be repaired starts a temporary foreground service; Step 3012: The hotfix client registers a callback function in the hotfix framework through a message processing class and starts a countdown.

[0131] In practice, after the hotfix client corresponding to the application to be repaired receives the patch path sent by the hotfix server, it starts a temporary foreground service. Then, the hotfix client calls the message processing class, registers a callback function in the hotfix framework through the message processing class, and starts a countdown.

[0132] For example, the message processing class is Handler(). The hotfix client controls the circuit breaker logic by passing in an executable callback function and a timeout through the postDelayed method of Handler(), and defines the forced stop operation to be performed when the timeout occurs.

[0133] In some embodiments, if the hotfix client does not receive the repair result from the hotfix framework after the countdown ends, it means that the hotfix client is unaware of whether the hotfix framework has completed the hotfix process or whether the application to be repaired has been successfully updated. Simultaneously, because the countdown has ended, to avoid resource waste and other issues, the temporary foreground service is stopped. To ensure that the upper-layer system that issued the application update command is aware of the result, the hotfix client will send an update failure message. That is, after step 303, the method further includes: Step 30A: The hotfix client sends an update failure message to the hotfix server; Step 30B: In response to the hotfix server receiving the update failure information, the update failure information is sent to the cloud.

[0134] In some embodiments, if the hotfix client receives the repair result from the hotfix framework before the countdown ends, the temporary foreground service is also stopped to avoid wasting resources by continuing to keep the temporary foreground service running. That is, after step 302, the method further includes: Step 30a: In response to the hotfix client receiving the repair result from the hotfix framework before the countdown ends, the countdown is stopped and the temporary foreground service is stopped.

[0135] Specifically, the response occurs when, before the countdown ends, the hotfix client receives the repair result from the hotfix framework, stops the countdown, and stops the temporary foreground service, specifically including: Step 30a1: Monitor the hotfix framework through the callback function; Step 30a2: In response to the hotfix client detecting the hotfix framework's feedback on the repair result before the countdown ends, the client calls the message processing class to remove the callback function and stops the countdown and the temporary foreground service.

[0136] In some embodiments, to improve the success rate of subsequent hotfix processing, after receiving the patch path from the hotfix server, the hotfix client can first verify the validity of the patch path. Only after confirming the patch path is valid can the temporary foreground service be started. That is, upon receiving the patch path in step 301, the hotfix client corresponding to the application to be repaired starts the temporary foreground service and begins a countdown, specifically including: Step 3011: In response to the hotfix client receiving the patch path, the validity of the patch path is verified, and a verification result is obtained; Step 3022: In response to the verification result indicating that the patch path is valid, a security window is created and a temporary foreground service is started.

[0137] In some embodiments, when validating the patch path, it can first be determined whether the patch package can be obtained based on the patch path. That is, the validity verification of the patch path described in step 3011, and the obtaining of the verification result, specifically includes: Step 30111: The hotfix client searches according to the patch path and obtains the search results; Step 30112: In response to the search result being empty, determine that the verification result indicates the patch path is invalid; or, Step 30113: In response to the search result being that the target patch package corresponding to the patch path has been obtained, obtain the target identifier corresponding to the target patch package, and determine the verification result based on the target identifier.

[0138] Specifically, obtaining the target identifier corresponding to the target patch package and determining the verification result based on the target identifier includes: Step A: Obtain the target identifier corresponding to the target patch package, and determine the target application corresponding to the target identifier; Step B: In response to the target application being the same as the application to be repaired, determine that the verification result indicates the patch path is valid; or, Step C: In response to the fact that the target application is different from the application to be repaired, the verification result is determined to be that the patch path is invalid.

[0139] It should be noted that the method of this disclosure embodiment can be executed by a single device, such as a computer or server. The method of this embodiment can also be applied to a distributed scenario, where multiple devices cooperate to complete the task. In such a distributed scenario, one of these devices may execute only one or more steps of the method of this disclosure embodiment, and the multiple devices will interact with each other to complete the method described.

[0140] It should be noted that the above description describes some embodiments of this disclosure. Other embodiments are within the scope of the appended claims. In some cases, the actions or steps recorded in the claims can be performed in a different order than that shown in the above embodiments and still achieve the desired result. Furthermore, the processes depicted in the drawings do not necessarily require a specific or sequential order to achieve the desired result. In some embodiments, multitasking and parallel processing are also possible or may be advantageous.

[0141] Based on the same inventive concept, corresponding to any of the above-described embodiments, this disclosure also provides an application of thermal repair device.

[0142] refer to Figure 3 , Figure 3The application of thermal repair device as an example includes: The application startup module 301 is configured to receive an application update instruction and patch path, and the hot repair server determines the application to be repaired corresponding to the application update instruction and controls the startup of the application to be repaired. The path sending module 302 is configured to send the patch path to the hotfix client corresponding to the application to be fixed by the hotfix server. The result feedback module 303 is configured to respond to the hotfix client receiving the patch path, perform hotfix processing on the application to be fixed according to the patch path, and feed back the repair result to the hotfix server.

[0143] In some embodiments, the path sending module 302 is specifically configured to: The hotfix server sends a target broadcast to the hotfix client corresponding to the application to be fixed, wherein the target broadcast contains the patch path; The hotfix client uses a broadcast receiver to receive the target broadcast, parses the target broadcast, and obtains the patch path contained in the target broadcast.

[0144] In some embodiments, the result feedback module 303 is specifically configured as follows: In response to the hotfix client receiving the patch path, a temporary foreground service is started, and a countdown begins; The hotfix client obtains the target patch package corresponding to the patch path, performs hotfix processing on the application to be repaired using the target patch package based on the countdown, and feeds back the repair result to the hotfix server.

[0145] In some embodiments, the result feedback module 303 is specifically configured as follows: Upon receiving the patch path, the hotfix client corresponding to the application to be repaired verifies the validity of the patch path and obtains the verification result. In response to the verification result indicating that the patch path is valid, a security window is created and a temporary foreground service is started, along with a countdown.

[0146] In some embodiments, the result feedback module 303 is specifically configured as follows: The hotfix client searches according to the patch path and obtains the search results; In response to an empty search result, the verification result is determined to be that the patch path is invalid; or, In response to the search result being that the target patch package corresponding to the patch path has been obtained, the target identifier corresponding to the target patch package is obtained, and the verification result is determined based on the target identifier.

[0147] In some embodiments, the result feedback module 303 is specifically configured as follows: Obtain the target identifier corresponding to the target patch package, and determine the target application corresponding to the target identifier; In response to the target application being the same as the application to be repaired, the verification result is determined to indicate that the patch path is valid; or... In response to the fact that the target application is different from the application to be repaired, the verification result is determined to be that the patch path is invalid.

[0148] In some embodiments, the result feedback module 303 is specifically configured as follows: The hotfix client obtains the target patch package corresponding to the patch path, calls the preset hotfix framework, and uses the hotfix framework to perform hotfix processing on the application to be fixed based on the target patch package. In response to the hotfix client receiving the repair result from the hotfix framework before the countdown ends, the countdown is stopped and the temporary foreground service is stopped; The hotfix client sends the repair result to the hotfix server; In response to the hotfix server receiving the repair result, the repair result is sent to the cloud.

[0149] In some embodiments, the result feedback module 303 is specifically configured as follows: In response to the countdown ending, if the hotfix client does not receive the repair result from the hotfix framework, the temporary foreground service will be stopped. The hotfix client sends an update failure message to the hotfix server. In response to the hotfix server receiving the update failure information, the update failure information is sent to the cloud.

[0150] For ease of description, the above apparatus is described in terms of its functions, divided into various modules. Of course, in implementing this disclosure, the functions of each module can be implemented in one or more software and / or hardware.

[0151] The apparatus of the above embodiments is used to implement the corresponding application thermal repair method in any of the foregoing embodiments, and has the beneficial effects of the corresponding method embodiments, which will not be repeated here.

[0152] Based on the same inventive concept, corresponding to the methods of any of the above embodiments, this disclosure also provides an electronic device, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the program to implement the application hot-fix method described in any of the above embodiments.

[0153] Figure 4 This embodiment illustrates a more specific hardware structure of an electronic device. The device may include a processor 1010, a memory 1020, an input / output interface 1030, a communication interface 1040, and a bus 1050. The processor 1010, memory 1020, input / output interface 1030, and communication interface 1040 are interconnected internally via the bus 1050.

[0154] The processor 1010 can be implemented using a general-purpose CPU (Central Processing Unit), microprocessor, application-specific integrated circuit (ASIC), or one or more integrated circuits, and is used to execute relevant programs to implement the technical solutions provided in the embodiments of this specification.

[0155] The memory 1020 can be implemented in the form of ROM (Read Only Memory), RAM (Random Access Memory), static storage device, dynamic storage device, etc. The memory 1020 can store the operating system and other applications. When the technical solutions provided in the embodiments of this specification are implemented by software or firmware, the relevant program code is stored in the memory 1020 and is called and executed by the processor 1010.

[0156] The input / output interface 1030 is used to connect input / output modules to realize information input and output. Input / output modules can be configured as components within the device (not shown in the figure) or externally connected to the device to provide corresponding functions. Input devices may include keyboards, mice, touchscreens, microphones, various sensors, etc., while output devices may include displays, speakers, vibrators, indicator lights, etc.

[0157] The communication interface 1040 is used to connect a communication module (not shown in the figure) to enable communication between this device and other devices. The communication module can communicate via wired means (such as USB, Ethernet cable, etc.) or wireless means (such as mobile network, WIFI, Bluetooth, etc.).

[0158] Bus 1050 includes a pathway for transmitting information between various components of the device, such as processor 1010, memory 1020, input / output interface 1030, and communication interface 1040.

[0159] It should be noted that although the above-described device only shows the processor 1010, memory 1020, input / output interface 1030, communication interface 1040, and bus 1050, in specific implementations, the device may also include other components necessary for normal operation. Furthermore, those skilled in the art will understand that the above-described device may only include the components necessary for implementing the embodiments of this specification, and not necessarily all the components shown in the figures.

[0160] The electronic devices described above are used to implement the corresponding application thermal repair methods in any of the foregoing embodiments, and have the beneficial effects of the corresponding method embodiments, which will not be repeated here.

[0161] Based on the same inventive concept, corresponding to the methods of any of the above embodiments, this disclosure also provides a non-transitory computer-readable storage medium storing computer instructions for causing the computer to execute the application hotfix method as described in any of the above embodiments.

[0162] The computer-readable medium of this embodiment includes permanent and non-permanent, removable and non-removable media, and information storage can be implemented by any method or technology. Information can be computer-readable instructions, data structures, program modules, or other data. Examples of computer storage media include, but are not limited to, phase-change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technologies, CD-ROM, digital versatile optical disc (DVD) or other optical storage, magnetic tape, magnetic magnetic disk storage or other magnetic storage devices, or any other non-transfer medium that can be used to store information accessible by a computing device.

[0163] The computer instructions stored in the storage medium of the above embodiments are used to cause the computer to execute the application hot-fix method as described in any of the above embodiments, and have the beneficial effects of the corresponding method embodiments, which will not be repeated here.

[0164] Based on the same inventive concept, corresponding to the methods of any of the above embodiments, this application also provides a vehicle, including the application thermal repair device in the above embodiments, the electronic device in the above embodiments, and the computer-readable storage medium in the above embodiments, wherein the vehicle device implements the application thermal repair method described in any of the above embodiments.

[0165] The vehicles described in the above embodiments are used to implement the thermal repair method described in any of the foregoing embodiments, and have the beneficial effects of the corresponding method embodiments, which will not be repeated here.

[0166] It is understood that before using the technical solutions of the various embodiments in this disclosure, users will be informed of the type, scope of use, and usage scenarios of the personal information involved in an appropriate manner, and user authorization will be obtained.

[0167] For example, upon receiving a user's active request, a prompt message is sent to the user to explicitly inform them that the requested operation will require the acquisition and use of the user's personal information. This allows the user to independently choose, based on the prompt message, whether to provide personal information to the software or hardware such as electronic devices, applications, servers, or storage media performing the operations of this disclosed technical solution.

[0168] As an optional but not limited implementation, in response to a user's active request, sending a prompt message to the user can be done via a pop-up window, where the prompt message can be presented in text format. Furthermore, the pop-up window can also include a selection control allowing the user to choose "agree" or "disagree" to provide personal information to the electronic device.

[0169] It is understood that the above notification and user authorization process are merely illustrative and do not constitute a limitation on the implementation of this disclosure. Other methods that comply with relevant laws and regulations may also be applied to the implementation of this disclosure.

[0170] Those skilled in the art should understand that the discussion of any of the above embodiments is merely exemplary and is not intended to imply that the scope of this disclosure (including the claims) is limited to these examples; within the framework of this disclosure, the technical features of the above embodiments or different embodiments can also be combined, the steps can be implemented in any order, and there are many other variations of different aspects of the embodiments of this disclosure as described above, which are not provided in detail for the sake of brevity.

[0171] Additionally, to simplify the description and discussion, and to avoid obscuring the embodiments of this disclosure, the provided drawings may or may not show well-known power / ground connections to integrated circuit (IC) chips and other components. Furthermore, the apparatus may be shown in block diagram form to avoid obscuring the embodiments of this disclosure, and this also takes into account the fact that the details of implementation of these block diagram apparatuses are highly dependent on the platform on which the embodiments of this disclosure will be implemented (i.e., these details should be fully understood by those skilled in the art). While specific details (e.g., circuits) have been set forth to describe exemplary embodiments of this disclosure, it will be apparent to those skilled in the art that the embodiments of this disclosure can be implemented without these specific details or with variations thereof. Therefore, these descriptions should be considered illustrative rather than restrictive.

[0172] Although this disclosure has been described in conjunction with specific embodiments thereof, many substitutions, modifications, and variations of these embodiments will be apparent to those skilled in the art from the foregoing description. For example, other memory architectures (e.g., dynamic RAM (DRAM)) may be used with the embodiments discussed.

[0173] This disclosure is intended to cover all such substitutions, modifications, and variations that fall within the broad scope of the appended claims. Therefore, any omissions, modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this disclosure should be included within the scope of protection of this disclosure.

Claims

1. A thermal repair method, characterized in that, include: Upon receiving the application update instruction and patch path, the hotfix server determines the application to be repaired corresponding to the application update instruction and controls the application to be repaired to start. The hotfix server sends the patch path to the hotfix client corresponding to the application to be fixed. In response to the hotfix client receiving the patch path, the hotfix client performs hotfix processing on the application to be fixed according to the patch path and feeds back the repair result to the hotfix server.

2. The method according to claim 1, characterized in that, The hotfix server sends the patch path to the hotfix client corresponding to the application to be fixed, including: The hotfix server sends a target broadcast to the hotfix client corresponding to the application to be fixed, wherein the target broadcast contains the patch path; The hotfix client uses a broadcast receiver to receive the target broadcast, parses the target broadcast, and obtains the patch path contained in the target broadcast.

3. The method according to claim 1, characterized in that, The response, in which the hotfix client receives the patch path, performs hotfix processing on the application to be fixed according to the patch path, and feeds back the repair result to the hotfix server, includes: In response to the hotfix client receiving the patch path, a temporary foreground service is started, and a countdown begins; The hotfix client obtains the target patch package corresponding to the patch path, performs hotfix processing on the application to be repaired using the target patch package based on the countdown, and feeds back the repair result to the hotfix server.

4. The method according to claim 3, characterized in that, The response to the hotfix client receiving the patch path includes starting a temporary foreground service, including: Upon receiving the patch path, the hotfix client corresponding to the application to be repaired verifies the validity of the patch path and obtains the verification result. In response to the verification result indicating that the patch path is valid, a security window is created and a temporary foreground service is started, along with a countdown.

5. The method according to claim 4, characterized in that, The validity verification of the patch path, and the resulting verification result, includes: The hotfix client searches according to the patch path and obtains the search results; In response to an empty search result, the verification result is determined to be that the patch path is invalid; or, In response to the search result being that the target patch package corresponding to the patch path has been obtained, the target identifier corresponding to the target patch package is obtained, and the verification result is determined based on the target identifier.

6. The method according to claim 5, characterized in that, The step of obtaining the target identifier corresponding to the target patch package and determining the verification result based on the target identifier includes: Obtain the target identifier corresponding to the target patch package, and determine the target application corresponding to the target identifier; In response to the target application being the same as the application to be repaired, the verification result is determined to indicate that the patch path is valid; or... In response to the fact that the target application is different from the application to be repaired, the verification result is determined to be that the patch path is invalid.

7. The method according to claim 3, characterized in that, The hotfix client obtains the target patch package corresponding to the patch path, performs hotfix processing on the application to be repaired using the target patch package based on the countdown, and feeds back the repair result to the hotfix server, including: The hotfix client obtains the target patch package corresponding to the patch path, calls the preset hotfix framework, and uses the hotfix framework to perform hotfix processing on the application to be fixed based on the target patch package. In response to the hotfix client receiving the repair result from the hotfix framework before the countdown ends, the countdown is stopped and the temporary foreground service is stopped; The hotfix client sends the repair result to the hotfix server; In response to the hotfix server receiving the repair result, the repair result is sent to the cloud.

8. The method according to claim 7, characterized in that, After performing hot-fix processing on the application to be fixed using the hot-fix framework based on the target patch package, the method further includes: In response to the countdown ending, if the hotfix client does not receive the repair result from the hotfix framework, the temporary foreground service will be stopped. The hotfix client sends an update failure message to the hotfix server. In response to the hotfix server receiving the update failure information, the update failure information is sent to the cloud.

9. An electronic device, characterized in that, It includes a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor, when executing the program, implements the method as described in any one of claims 1 to 8.

10. A vehicle, characterized in that, The vehicle includes the electronic equipment as described in claim 9.

Images