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 updating instruction and a patch path are received, a hot repair server determines a to-be-repaired application corresponding to the application updating instruction, and the patch path is sent to a hot repair client corresponding to the to-be-repaired application; in response to the patch path received by the hot repair client, starting a temporary foreground service; and the hot repair client obtains a target service pack corresponding to the patch path, and performs hot repair processing on the to-be-repaired application by using the target service pack. In the hot repair process, no matter whether the user switches the to-be-repaired application to the background or not, the to-be-repaired application is regarded as the foreground application, then the limitation that the application in the background state in the Android system starts the service is relieved, the problem that the hot repair process is interrupted is avoided, and the hot repair processing success rate is increased.

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] As the Android operating system continues to evolve, in order to optimize battery life and system performance, increasingly strict restrictions have been imposed on the background behavior of applications, such as prohibiting any application in the background from starting services.

[0003] However, since completing a hotfix process takes some time, users are very likely to switch the current application to the background during this period. When the hotfix is ​​completed, the application is already in the background and cannot start the service to send the repair results back to the application's main process, resulting in the hotfix process being interrupted and having a low failure rate. 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 in the current Android system application hotfix process, the result notification service fails to start because the application is switched to the background during patch installation, which ultimately causes the entire hotfix process to be interrupted or the status to be unknown.

[0005] To achieve the above objectives, a first aspect of this disclosure provides a method for applying thermal repair, the method comprising: 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 sends the patch path to the hotfix client corresponding to the application to be repaired. In response to the hotfix client receiving the patch path, a temporary foreground service is started; 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.

[0006] Based on the same inventive concept, a second aspect of this disclosure proposes an application of a thermal repair device, comprising: The data sending module is configured to receive an application update instruction and a 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. The foreground service startup module is configured to start a temporary foreground service in response to the hotfix client receiving the patch path; The hotfix processing module is configured to obtain the target patch package corresponding to the patch path from the hotfix client and use the target patch package to perform hotfix processing on the application to be repaired.

[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. After the hotfix client receives the patch path, it starts a temporary foreground service, so that the application to be fixed is always in the foreground during the hotfix process. That is, during the hotfix process, regardless of whether the user switches the application to be fixed to the background, the application to be fixed is regarded as the 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 hotfix process, and improves the success rate of hotfix processing. 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 schematic flowchart of another embodiment of the application of the thermal repair method 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] In modern mobile application development, hotfix technology has become an indispensable operation and maintenance tool. It allows developers to fix bugs or make minor functional adjustments to already launched applications online without releasing a new version, greatly improving problem response speed and user experience.

[0020] Android 8.0 imposes restrictions on background app behavior, specifically prohibiting any app in the background from starting a service. When an app is not in the foreground—that is, when the user switches to another app or returns to the home screen—if it attempts to start a service using the `startService()` method, the system will throw an `IllegalStateException`, causing the app to crash or the service to fail to start.

[0021] This system-level limitation clashes sharply with the Tinker framework's internal workflow, as completing a hotfix process can take a considerable amount of time, potentially two minutes or longer. During this period, users are highly likely to switch the current application to the background. When the hotfix is ​​complete, because the application is already in the background, it cannot start the service to send the repair results back to the main application process.

[0022] At this point, the application's main process will never receive a callback indicating successful patch installation. Furthermore, the patch may have actually been successfully merged, but the application itself is unaware of this and cannot trigger subsequent patch loading logic. Additionally, the upper-level system initiates an update, but without receiving explicit success or failure feedback, it cannot determine the outcome of the update and therefore cannot display a message to the user such as "Update successful, please restart the application" or "Update failed."

[0023] In other words, during the current hotfix process for Android system applications, 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.

[0024] Based on the above description, this embodiment proposes a thermal repair 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 sends the patch path to the hotfix client corresponding to the application to be repaired.

[0025] 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.

[0026] 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.

[0027] 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.

[0028] 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.

[0029] 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.

[0030] 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.

[0031] 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.

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

[0033] 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.

[0034] Step 103: 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.

[0035] 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.

[0036] 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 102, which involves the hotfix client receiving the patch path and starting the temporary foreground service, specifically includes: Step 1021: 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 1022: 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.

[0037] 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.

[0038] 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.

[0039] 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.

[0040] 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.

[0041] 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().

[0042] 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 1021, and the obtaining of the verification result, specifically includes: Step 10211: The hotfix client searches according to the patch path and obtains the search results; Step 10212: In response to the search result being empty, determine that the verification result indicates the patch path is invalid; or, Step 10213: 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.

[0043] 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.

[0044] 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.

[0045] 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.

[0046] 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.

[0047] 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.

[0048] 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.

[0049] 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.

[0050] 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.

[0051] 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 103, 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 1031: The hotfix client obtains the target patch package corresponding to the patch path and calls the preset hotfix framework; Step 1032: 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.

[0052] 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.

[0053] 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.

[0054] 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.

[0055] 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 1032, the following steps are also included: Step 10A: The hotfix framework sends the repair result back to the hotfix client; Step 10B: In response to the hotfix client receiving the repair result, the temporary foreground service is stopped.

[0056] 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.

[0057] 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.

[0058] 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.

[0059] 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.

[0060] 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.

[0061] 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 10B, the process also includes: Step 10C: The hotfix client sends the repair result to the hotfix server; Step 10D: In response to the hotfix server receiving the repair result, the repair result is sent to the cloud; Step 10E: After the cloud confirms that the repair result has been received, it displays the repair result.

[0062] 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.

[0063] 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.

[0064] 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.

[0065] 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.

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

[0067] 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.

[0068] 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.

[0069] Based on the same inventive concept, another embodiment of this disclosure provides a method for applying thermal repair, such as... Figure 2 As shown, Figure 2 The flowchart of the application hotfix method is shown. The hotfix process includes an upper-layer system, a hotfix server, an application to be fixed, a hotfix client, and a hotfix framework. The hotfix client includes a central controller and a temporary foreground service module. The hotfix framework includes a hotfix module, which is also a result feedback module.

[0070] Specifically, the upper-layer system is the LOTA system, the hotfix service is hotfixservice, the application activity to be repaired is the application activity, the hotfix client is hotfixclient, the central controller is TinkerManager, the temporary foreground service module is PatchInstallForegroundService, the hotfix framework is the Tinker framework, the hotfix module is TinkerPatchService, and the result feedback module is TinkerResultService.

[0071] The method specifically includes: When the LOTA system detects the target patch package for the application to be repaired, it indicates that the application needs to be updated. At this point, the LOTA system downloads and stores the target patch package, and sends an application update command along with the patch path of the target patch package to the hotfixservice.

[0072] The hotfix server launches the application interface and passes the patch path to the active application client to be patched. The active application client calls applyLotaPatch(path). TinkerManager calls startService() to start a temporary foreground service and create a secure window. After receiving the control command, PatchInstallForegroundService creates and promotes itself to the foreground service via onCreate(). Finally, TinkerManager calls the Tinker framework and calls TinkerinstalleronReceiveUpgradePatch() to begin the asynchronous, time-consuming patch installation process, i.e., the hotfix process.

[0073] TinkerPatchService performs the most crucial and time-consuming patch merging operation, which combines the downloaded patch files 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 process, 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.

[0074] Once TinkerManager receives the repair results, it calls stopService() to immediately stop the foreground service and destroy the security window. TinkerManager then sends the repair results back to hotfixservice, which in turn sends them back to the LOTA system.

[0075] In this embodiment, by actively creating a foreground environment, the service startup calls in the Tinker process become completely legitimate, fundamentally solving the problem of hotfix process interruption and increasing the hotfix success rate to nearly 100%. Furthermore, the entire solution requires no modification to the Tinker framework source code; instead, it employs external encapsulation and enhancement, resulting in strong compatibility. Future version upgrades of Tinker can be easily kept up with, and it can also be conveniently replaced with other hotfix frameworks with similar issues.

[0076] In this embodiment, the lifecycle of the foreground service is strictly limited to a very short time window—the time between calling Tinker and receiving the Tinker callback. Once the process ends, resources are released immediately, with negligible impact on the user's device's battery life and performance. Furthermore, the entire assurance process is transparent to the user. Users can switch freely between applications as usual without worrying about interrupting ongoing background updates.

[0077] 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.

[0078] 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.

[0079] 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.

[0080] 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 201: Upon receiving the patch path, the hotfix client corresponding to the application to be repaired starts a temporary foreground service and begins a countdown.

[0081] 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.

[0082] 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.

[0083] 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.

[0084] 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.

[0085] 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.

[0086] 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.

[0087] 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.

[0088] 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.

[0089] 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.

[0090] Step 202: 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.

[0091] 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.

[0092] 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.

[0093] 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.

[0094] Step 203: 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.

[0095] 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.

[0096] 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.

[0097] The above scheme involves receiving a patch path, and the hotfix client corresponding to the application to be repaired starts a temporary foreground service and begins a countdown. The hotfix client obtains the target patch package corresponding to the patch path, calls a preset hotfix framework, and uses the framework to perform hotfix processing on the application to be repaired based on the target patch package. By starting a temporary foreground service, 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 be repaired to the background, it is always treated as a foreground application, thus removing the restriction on starting services for background applications in the Android system, avoiding interruptions during hotfix processing, and improving the success rate of hotfix processing. If the hotfix client does not receive a repair result from the hotfix framework when the countdown ends, it stops the temporary foreground service. By starting a countdown when starting the temporary foreground service, 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 call back the repair result due to system crashes or other reasons. This stops the temporary foreground service, preventing the temporary foreground service from being constantly suspended and wasting resources. Meanwhile, since the temporary foreground service will continuously consume the user's device power while running, the temporary foreground service will be shut down if no repair result is received by the end of the countdown to avoid continuous power consumption.

[0098] 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 201, the repair client corresponding to the application to be repaired starts the temporary foreground service and begins a countdown, including: Step 2011: Upon receiving the patch path, the hotfix client corresponding to the application to be repaired starts a temporary foreground service; In step 2012, the hotfix client registers a callback function in the hotfix framework through a message processing class and starts a countdown.

[0099] 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.

[0100] 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.

[0101] 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 203, the method further includes: Step 20A: The hotfix client sends an update failure message to the hotfix server; Step 20B: In response to the hotfix server receiving the update failure information, the update failure information is sent to the cloud.

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

[0103] 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.

[0104] 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.

[0105] 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 202, the method further includes: Step 20a: 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.

[0106] In practice, 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 terminated.

[0107] 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 20a1: Monitor the hotfix framework through the callback function; Step 20a2: 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.

[0108] In practice, when starting the temporary foreground service, the hotfix client calls a message processing class, which registers a callback function within the hotfix framework. Therefore, the hotfix framework can be monitored through these callback functions.

[0109] 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.

[0110] 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.

[0111] 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.

[0112] Based on the same inventive concept, another embodiment of this disclosure provides an application hotfix method, describing a complete hotfix processing flow, and simultaneously addressing the problems of insufficient overall reliability in the current hotfix system caused by improper triggering methods, lack of execution process guarantees, and missing feedback links. The method includes: Step 301: 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.

[0113] 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.

[0114] 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.

[0115] 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.

[0116] 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.

[0117] 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.

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

[0119] 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.

[0120] 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.

[0121] 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.

[0122] Step 303: 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.

[0123] 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.

[0124] 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.

[0125] Through the above scheme, 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 startup of the application to be repaired. After receiving the application update instruction, the hotfix server controls the startup of the application to be repaired, avoiding the situation where only a broadcast is sent to the application to be repaired, which could result in the application not starting and remaining in the background, thus violating Android's background restriction issues. Simultaneously, the hotfix server sends the patch path to the hotfix client corresponding to the application to be repaired. Upon receiving the patch path, the hotfix client 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 chain. This avoids process interruptions and unknown results caused by loose module collaboration and state black boxes, improving the integrity and reliability of the hotfix process.

[0126] 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 302, the hotfix server sends the patch path to the hotfix client corresponding to the application to be repaired, specifically including: Step 3021: 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 3022: 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.

[0127] 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.

[0128] 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.

[0129] 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.

[0130] In some embodiments, during the hotfix process of an Android system application, there is a problem that the result notification service may fail 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 303, 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 3031: In response to the hotfix client receiving the patch path, a temporary foreground service is started and a countdown begins; Step 3032: 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.

[0131] 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.

[0132] 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.

[0133] 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.

[0134] 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.

[0135] 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.

[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, and only after confirming that the patch path is valid can it start the temporary foreground service. That is, step 3031, which involves the hotfix client receiving the patch path and starting the temporary foreground service, specifically includes: Step 30311: 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 30312: 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 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.

[0138] 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.

[0139] 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.

[0140] 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.

[0141] 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().

[0142] 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 30311, and the obtaining of the verification result, specifically includes: Step 30A: The hotfix client searches according to the patch path and obtains the search results; Step 30B: In response to the search result being empty, determine that the verification result indicates the patch path is invalid; or, Step 30C: 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.

[0143] 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.

[0144] 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.

[0145] 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.

[0146] 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.

[0147] 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.

[0148] 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.

[0149] 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.

[0150] 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.

[0151] 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 3032, 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 30321: 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 30322: 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 30323: The hotfix client sends the repair result to the hotfix server; Step 30324: In response to the hotfix server receiving the repair result, the repair result is sent to the cloud.

[0152] 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.

[0153] 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.

[0154] 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.

[0155] 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.

[0156] 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.

[0157] 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.

[0158] 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.

[0159] 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.

[0160] 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.

[0161] 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.

[0162] 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.

[0163] 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.

[0164] 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 30321, the process further includes: Step 3032A: 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 3032B: The hotfix client sends an update failure message to the hotfix server; Step 3032C: In response to the hotfix server receiving the update failure information, the update failure information is sent to the cloud.

[0165] 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.

[0166] 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.

[0167] 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.

[0168] 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.

[0169] 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.

[0170] 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.

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

[0172] refer to Figure 3 , Figure 3 The application of thermal repair device as an example includes: The data sending module 301 is configured to receive an application update instruction and a patch path, and the hot repair server determines the application to be repaired corresponding to the application update instruction and sends the patch path to the hot repair client corresponding to the application to be repaired. The foreground service startup module 302 is configured to start a temporary foreground service in response to the hotfix client receiving the patch path. The hotfix processing module 303 is configured to obtain the target patch package corresponding to the patch path from the hotfix client and use the target patch package to perform hotfix processing on the application to be repaired.

[0173] In some embodiments, the foreground service startup module 302 is specifically configured as follows: In response to the hotfix client receiving the patch path, the validity of the patch path is verified, and a verification result is obtained; 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.

[0174] In some embodiments, the foreground service startup module 302 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.

[0175] In some embodiments, the foreground service startup module 302 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.

[0176] In some embodiments, the thermal repair processing module 303 is specifically configured as follows: The hotfix client obtains the target patch package corresponding to the patch path and calls the preset hotfix framework; Using the hotfix framework, the target patch package and the application to be repaired are synthesized and repaired to obtain the repaired application.

[0177] In some embodiments, the apparatus further includes a foreground service stop module, which is configured to: The hotfix framework sends the repair results back to the hotfix client; In response to the hotfix client receiving the repair result, the temporary foreground service is stopped.

[0178] In some embodiments, the apparatus further includes a display module, the display module being configured to: The hotfix client sends the repair result to the hotfix server; Upon receiving the repair result, the hotfix server sends the repair result to the cloud; Once the cloud platform confirms that it has received the repair result, it displays the repair result.

[0179] In some embodiments, the apparatus further includes a monitoring module, the monitoring module being configured to: In response to the repair result being a successful update, the startup status of the application to be repaired is monitored; The system detected that the application to be repaired had restarted, and then displayed the repaired application.

[0180] 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.

[0181] 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.

[0182] 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.

[0183] 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.

[0184] 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.

[0185] 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.

[0186] 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.

[0187] 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.).

[0188] 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.

[0189] 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.

[0190] 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.

[0191] 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.

[0192] 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.

[0193] 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.

[0194] 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.

[0195] 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.

[0196] 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.

[0197] 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.

[0198] 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.

[0199] 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.

[0200] 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.

[0201] 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.

[0202] 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.

[0203] 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 an 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. In response to the hotfix client receiving the patch path, a temporary foreground service is started; 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.

2. The method according to claim 1, characterized in that, The response to the hotfix client receiving the patch path includes starting a temporary foreground service, including: In response to the hotfix client receiving the patch path, the validity of the patch path is verified, and a verification result is obtained; 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.

3. The method according to claim 2, 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.

4. The method according to claim 3, 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.

5. The method according to claim 1, characterized in that, 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, including: The hotfix client obtains the target patch package corresponding to the patch path and calls the preset hotfix framework; Using the hotfix framework, the target patch package and the application to be repaired are synthesized and repaired to obtain the repaired application.

6. The method according to claim 5, characterized in that, After the application to be repaired is repaired, the following is also included: The hotfix framework sends the repair results back to the hotfix client; In response to the hotfix client receiving the repair result, the temporary foreground service is stopped.

7. The method according to claim 6, characterized in that, Following the cessation of temporary front desk services, the following also applies: The hotfix client sends the repair result to the hotfix server; Upon receiving the repair result, the hotfix server sends the repair result to the cloud; Once the cloud platform confirms that it has received the repair result, it displays the repair result.

8. The method according to claim 7, characterized in that, Following the presentation of the repair results, the following is also included: In response to the repair result being a successful update, the startup status of the application to be repaired is monitored; The system detected that the application to be repaired had restarted, and then displayed the repaired application.

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