Application software hot repair method, device, equipment, vehicle and storage medium

Abstract

The application relates to an application software hot repair method, device, equipment, vehicle and storage medium, and the method comprises the following steps: when online application software is started on a target operating system, if an incremental differential package based on a data packet request and issued by a cloud is detected, a repair code in the incremental differential package is read; according to the repair code, a target stake point is determined in each code stake point in the online application software; the target code marked by the target stake point and the target stake point code preburied at the entrance of the target code are determined from the online application software; when a calling request of the target code is detected, the target stake point code is run to intercept the calling request, and the calling request is routed to the calling repair code, so that the target business logic corresponding to the target code is realized. According to the method, the target code of a single fault can be quickly and accurately replaced by the repair code in the state that the online application software is started and continuously runs, the application does not need to be reinstalled or restarted, and the repair efficiency is improved.

Description

Technical Field

[0001] This invention relates to the field of software engineering technology, and specifically to a method, apparatus, equipment, vehicle, and storage medium for hot-fixing application software. Background Technology

[0002] After an Android application is released and downloaded and installed by users, it may crash due to code defects or other issues during use. In order to avoid interrupting the user experience, it is necessary to fix the problem in a timely manner.

[0003] In existing technologies, most Android application troubleshooting methods involve updating the entire package or unpacking and repackaging the Android Application Package (APK) and reinstalling it.

[0004] However, this method of fault repair using existing technologies is not timely. Summary of the Invention

[0005] One objective of this invention is to provide a hot-repair method for application software, thereby solving the problem that application software needs to be re-downloaded and reinstalled after a failure, resulting in poor timeliness of fault repair in the prior art; a second objective is to provide a hot-repair device for application software; a third objective is to provide an electronic device; a fourth objective is to provide a vehicle; and a fifth objective is to provide a computer-readable storage medium.

[0006] To achieve the above objectives, the technical solution adopted by the present invention is as follows:

[0007] A hotfix method for application software, comprising:

[0008] When an online application starts on the target operating system and sends a data packet request to the cloud, if an incremental differential packet sent by the cloud based on the data packet request is detected, the repair code in the incremental differential packet is read.

[0009] Based on the repair code, the target stub is determined among the various code stubs in the online application software;

[0010] The target code marked by the target stake point and the target stake point code pre-embedded at the entry point of the target code are determined from the online application software;

[0011] When a call request for the target code is detected, the target stub code is run to intercept the call request and the call request is routed to call the repair code to implement the target business logic corresponding to the target code.

[0012] Furthermore, determining the target stub among the various code stubs within the online application software based on the repair code includes:

[0013] Read the stub mapping table from the incremental differential package. The stub mapping table is used to represent the correspondence between each piece of code and code stubs in the online application software. Each piece of code is used to implement the corresponding business logic when executed.

[0014] Based on the identification information of the repair code, determine the mapping stub corresponding to the identification information from the stub mapping table;

[0015] The mapping stub is located among the various code stubs and determined as the target stub.

[0016] Furthermore, it also includes:

[0017] Before the online application software is launched, obtain the executable file of the online application software;

[0018] Extract the first metadata corresponding to each class in the executable file, and the second metadata corresponding to each code segment in each class;

[0019] Based on the first metadata and the second metadata, each code segment is classified to determine repairable and unrepairable code.

[0020] The unrepairable code is filtered out to obtain the remaining repairable code;

[0021] The bytecode instructions of the executable file are modified by bytecode instrumentation to pre-embed stub code at the entry point of each repairable code.

[0022] Furthermore, it also includes:

[0023] Based on the identification information of the repairable code and the identification information of each code stub, the stub mapping table is constructed.

[0024] Furthermore, the repair code in the incremental differential package is the difference code extracted from the repaired application software after performing a differential comparison between each segment of code in the online application software and each segment of code in the repaired application software.

[0025] The repaired version of the application software is generated by compiling the target code in the online application software after code repair.

[0026] Furthermore, reading the repair code from the incremental differential packet includes:

[0027] The incremental differential packets sent from the cloud are verified, and the verification operation includes at least one of data packet validity verification and data packet integrity verification.

[0028] If the verification is successful, the incremental differential packet is decrypted to read the repair code;

[0029] If the verification fails, the incremental differential packet will be discarded.

[0030] Furthermore, it also includes: constructing an independent class loader, which is isolated from the host application class loader, the host application class loader being used to load the online application software; and loading the incremental differential package in the independent class loader.

[0031] Furthermore, it also includes: monitoring the execution status of the repair code after it is invoked; if the repair code encounters an abnormal state after it is invoked, stopping the execution of the target stub code, the abnormal state including at least one of runtime crash and application unresponsiveness; and switching the invocation request back to invoking the target code.

[0032] Furthermore, it also includes: if the target operating system is an Android operating system, obtaining the system version information of the Android operating system; based on the system version information, determining a target compatibility adaptation strategy from various preset compatibility adaptation strategies, wherein the preset compatibility adaptation strategy includes at least one of optimizing the executable file loading process, reverting the repair code compiled into machine code to the bytecode interpretation execution mode before compilation, and adjusting the storage directory of the repair code; and using the target compatibility adaptation strategy to execute the repair code in the Android operating system.

[0033] An application software hotfix device, comprising:

[0034] The detection module is used to read the repair code in the incremental differential packet when the online application software starts on the target operating system and sends a data packet request to the cloud.

[0035] The determination module is used to determine the target stub among the various code stubs in the online application software based on the repair code.

[0036] The acquisition module is used to determine the target code marked by the target stake point and the target stake point code pre-embedded at the entry point of the target code from the online application software;

[0037] The calling module is used to intercept the calling request by running the target stub code when the calling request of the target code is detected, and to route the calling request to call the repair code in order to realize the target business logic corresponding to the target code.

[0038] An electronic device includes: a memory and at least one processor; the memory stores computer-executable instructions; the processor executes the computer-executable instructions stored in the memory, causing the processor to perform the method described above.

[0039] A vehicle includes a vehicle body and the aforementioned electronic equipment disposed in the vehicle body.

[0040] A computer-readable storage medium storing computer-executable instructions, which, when executed by a processor, are used to implement the above-described method.

[0041] The beneficial effects of this invention are:

[0042] (1) Real-time repair without restart, short repair time, and no user awareness: Based on dynamic routing of staking agent, there is no need to restart the application or exit the page. Online faults are repaired in seconds without interrupting the user's use;

[0043] (2) Precise repair granularity and lightweight design: Incremental differential packages are formed by incremental differential processing at the single code level. Only the repair code with differences is distributed to the cloud. The incremental differential package is much smaller than the whole package / class level repair, saving traffic and storage resources.

[0044] (3) Zero source code intrusion and strong adaptability: Automatic instrumentation during the compilation stage of application software, without the need to modify business source code, and compatible with Android 4.4 to the latest version, with strong compatibility and high adaptability;

[0045] (4) High stability and no class loading conflicts: Independent class loader isolation mechanism to avoid conflicts between host and incremental differential package classes and resources; built-in exception rollback mechanism to prevent secondary crashes caused by repair.

[0046] (5) Reuse bytecode instrumentation core capabilities and have strong scalability: On the basis of existing instrumentation technology, it expands repair capabilities and can be compatible with integrated deployment of multiple capabilities such as monitoring, embedding, and hot repair. Attached Figure Description

[0047] Figure 1 A flowchart of the application software hotfix method provided in the embodiments of this application;

[0048] Figure 2 A flowchart of compiler bytecode instrumentation preprocessing provided for embodiments of this application;

[0049] Figure 3 A flowchart for generating single-segment code-level incremental differential packets is provided for embodiments of this application;

[0050] Figure 4 This is a schematic diagram of a terminal runtime hot-repair process without restart provided in an embodiment of this application;

[0051] Figure 5 This is a schematic diagram of the overall process of the application software hotfix method provided in the embodiments of this application;

[0052] Figure 6 This is a schematic diagram of the structure of the application software hot repair device provided in the embodiments of this application;

[0053] Figure 7 A schematic diagram of the structure of the electronic device provided in this application. Detailed Implementation

[0054] The embodiments of the present invention will be described below with reference to the accompanying drawings and preferred embodiments. Those skilled in the art can easily understand other advantages and effects of the present invention from the content disclosed in this specification. The present invention can also be implemented or applied through other different specific embodiments, and various details in this specification can also be modified or changed based on different viewpoints and applications without departing from the spirit of the present invention. It should be understood that the preferred embodiments are only for illustrating the present invention and not for limiting the scope of protection of the present invention.

[0055] It should be noted that the illustrations provided in the following embodiments are only schematic representations of the basic concept of the present invention. Therefore, the drawings only show the components related to the present invention and are not drawn according to the actual number, shape and size of the components in the actual implementation. In the actual implementation, the form, quantity and proportion of each component can be arbitrarily changed, and the layout of the components may also be more complex.

[0056] In the field of Android application online operation and maintenance technology, application software is mainly deployed on the terminal side and relies on network and cloud services to complete business processing. For example, in the business scenario of in-vehicle navigation services, the navigation application installed on the car's infotainment system needs to continuously send data packet requests to the cloud to obtain real-time traffic conditions and provide voice broadcasts after startup. In such scenarios, application software often has characteristics such as high user usage time and the need to maintain business stability during use, without application crashes or freezes. Once a defect occurs in a certain business logic of the application software, it may cause page crashes, process freezes, or abnormal navigation results, preventing users from continuing to use the application normally. Therefore, fault repair for application software must take effect as soon as possible to avoid interrupting the current business process.

[0057] In related technologies, most online fault repair solutions for Android applications revolve around full package updates, repackaging and reinstalling, or runtime status monitoring based on bytecode instrumentation. Full package update solutions involve modifying the application code after discovering an online issue, generating a new installation package, and then guiding users to download and install it through app stores, gray-scale distribution channels, or pop-up upgrade mechanisms. Repackaging and reinstalling solutions replace the original installation content by repackaging, or require users to restart the application for the new logic to take effect. The working principle of these solutions is essentially replacing the problematic code with the entire application version. While this can achieve defect coverage, the updated content usually contains a large amount of unchanged code and resources, resulting in a large update package size, significant download time in weak network environments, and uncertainty regarding whether users will upgrade in time, making it impossible to immediately resolve the fault after discovery. Bytecode instrumentation-based solutions insert monitoring logic into application bytecode during the compilation or packaging phase to collect code calls, exception stacks, performance metrics, or crash information. The runtime logs are then reported to the cloud for analysis. This approach focuses on discovering and locating problems rather than directly changing the code execution logic. Therefore, the instrumentation results typically serve observation and recording functions and cannot switch the original code to the new fix code while the application is running. Even if some highly extensible solutions exist, they often require replacing a large number of classes or modules, resulting in coarse-grained fixes and potential additional compatibility risks.

[0058] Meanwhile, the different system versions, vendor-customized environments, and complex multi-page, multi-threaded business processes within the Android ecosystem make it difficult to balance real-time performance, precision, and stability by simply relying on overall replacement or monitoring-based instrumentation. Especially when the application is already running and interacting with the cloud, the above solutions cannot directly establish a precise repair path around a single fault code, resulting in significant drawbacks such as extended repair time, broad impact, high resource consumption, and heavy adaptation pressure.

[0059] In view of this, the embodiments of this application provide an application software hot repair scheme, which takes the terminal's online request to the cloud and the receipt of incremental differential packets as the trigger basis, locates the target code with abnormality based on the incremental differential packets, and uses the target stub code pre-embedded at the entry point of the target code as the execution entry point, thereby completing the targeted correction of the target business logic during the application's operation, so as to realize the application software method-level hot repair.

[0060] The technical solution of this application and how the technical solution of this application solves the above-mentioned technical problems are described in detail below with specific embodiments. The following specific embodiments can be combined with each other, and the same or similar concepts or processes may not be described again in some embodiments.

[0061] Figure 1The flowchart illustrates the application software hotfix method provided in this application embodiment. The executing entity of this method can be the online application software itself running on the terminal, or it can be a hotfix management module, runtime loading module, or patch scheduling module integrated within the online application software. Figure 1 As shown, the method specifically includes:

[0062] Step 110: When the online application software starts on the target operating system and sends a data packet request to the cloud, if an incremental differential packet sent by the cloud based on the data packet request is detected, the repair code in the incremental differential packet is read.

[0063] Step 120: Based on the repair code, identify the target stub among the various code stubs in the online application software.

[0064] Step 130: Determine the target code marked on the target stake point and the target stake point code pre-embedded at the target code entry point from the online application software.

[0065] Step 140: When a call request for the target code is detected, run the target stub code to intercept the call request and route the call request to the call repair code to implement the target business logic corresponding to the target code.

[0066] In traditional Android application hotfix scenarios, it is necessary to unpack and repackage the Android Application Package (APK) and reinstall it. This method cannot perform a repair without restarting while the application is already installed and running, resulting in poor repair timeliness and inability to handle high-risk online faults in emergencies. Traditional Android application hotfix has at least the following drawbacks:

[0067] 1. Limited functionality and lack of hotfix capability: Traditional technologies only monitor and instrument the code, and cannot fix online application crashes or logical defects. They cannot solve the core problems of Android application failures requiring version updates and poor user experience.

[0068] 2. No incremental update mechanism: Traditional technology injects the full executable file (Dalvik Executable, dex), without the ability to compare code differences or generate incremental differential packages. If used for code updates, it will result in an excessively large update package size, consuming user traffic and device storage resources.

[0069] 3. No precise single-segment code-level repair: Existing instrumentation is function-level monitoring injection, which does not support single-segment code-level replacement, cannot achieve minimum-scope repair, and is prone to class loading conflicts and compatibility issues.

[0070] 4. Relies on repackaging and reinstallation, unable to fix online in real time: Existing technology requires unpacking and repackaging the APK and reinstalling it, which cannot be done without restarting while the application is already installed and running. The repair timeliness is poor and it cannot handle high-risk online faults in an emergency.

[0071] 5. No dedicated compatibility adaptation for hotfix: It has not been adapted for different Android versions' class loading mechanisms, Android Runtime (ART) virtual machines, and sub-package architecture, and cannot adapt to hotfix scenarios of all Android versions.

[0072] The Android hotfix method in this application, which combines bytecode instrumentation, code replacement, and incremental differential, can perform hotfix on application software loaded in the Android operating system without interrupting the operation of the application software, thus achieving online application fault repair without source code modification, without restart, and with small incremental size.

[0073] For step 110 above, the target operating system can be any distribution of the Android operating system. After the terminal is powered on or the application process is launched, the online application software enters the running state and sends a data packet request to the cloud service.

[0074] The data packet request can be used to verify whether there are new incremental differential packets in the cloud. For example, if the application software adds the version identifier of the existing incremental differential packet A to the data packet request, the cloud will extract the version identifier after receiving the data packet request and compare it with the version identifier of the incremental differential packet B stored in the cloud. If they match, it means that there are no new incremental differential packets in the cloud at the moment; if they do not match, the cloud can send the incremental differential packet B to the terminal side for the online application software.

[0075] In this embodiment, the incremental differential packet carries the stub mapping table and repair code. Its small size facilitates online application software to receive and perform incremental repairs. In contrast, traditional application software repair update packages are too large, consuming user bandwidth and device storage resources.

[0076] The stub mapping table represents the correspondence between each piece of code in the online application software, the class in which each piece of code belongs, and each stub used to mark each piece of code. Different pieces of code are used to implement corresponding business logic during execution.

[0077] The specific process of forming an incremental differential package can be as follows: When developers discover code logic defects, crashes, or other faults in online application software, they only fix the corresponding code segment in the application software (for example, update a certain line of code in the code segment), then compile and generate a fixed version of the application software and upload it to the cloud. The cloud compares the fixed version of the application software with the current online application software, extracts the difference-causing code from the fixed version of the application software, and then uses these fixed codes, the matching stub mapping table, and the necessary metadata to construct differential content, which is then compressed, signed, and encrypted to form an incremental differential package.

[0078] After receiving the incremental differential packet sent from the cloud, the application software installed on the terminal can save the incremental differential packet to the application's private directory or memory buffer, and perform integrity verification, signature verification and decryption processing to reduce the risk of data corruption or content tampering during transmission.

[0079] In this embodiment, when the application software reads the stub mapping table and repair code in the incremental differential package, it can load the repair code through a class loader, Dalvik executable loading component, or local patch interpreter, and parse the stub mapping table into a locally queryable data structure, such as a key-value mapping table, an index table, or a hash table.

[0080] The stub mapping table establishes the association between class identifiers, code identifiers, and stub identifiers, which is used by online application software to quickly locate target stubs that need to be enabled and repaired during runtime.

[0081] In one possible embodiment, the stub mapping table is generated based on the bytecode instrumentation results during the compilation phase of the online application software and is stored locally along with the original application package. The incremental differential packet can carry the incrementally updated mapping information, allowing the terminal to obtain the latest mapping relationship through incremental merging.

[0082] In another possible implementation, the entire stub mapping table is stored in the incremental differential packet, and the terminal directly parses and replaces the local old mapping table.

[0083] In this embodiment, the repair code is used to replace the original target code to implement the target business logic. It can be encapsulated as a static method, instance method, or bridge method in the patch class, and the method body contains the verified repaired business code. By receiving and reading the incremental differential package while the application is already started and running, the repair capability can be injected into the runtime environment in a timely manner without reinstalling the entire package or forcing the user to restart the application. This establishes a data and execution foundation for subsequent precise repairs at the single-segment code level.

[0084] Regarding step 120 above, after completing the incremental differential package reading, the execution entity of this method can extract the code identifier and class identifier from the metadata of the repair code.

[0085] Among them, the class identifier is used to represent the class to which the repair code belongs, and the code identifier is used to represent at least one of the specific code name, code signature and bytecode instruction set to ensure the uniqueness of the location.

[0086] The stub mapping table pre-records the stub information corresponding to each repairable code. Therefore, the code identifier and class identifier of the repairable code can be used as search conditions to match and search in each stub record item of the stub mapping table to determine the target stub.

[0087] Among them, the target stub is used as the entry point for interception and routing. It corresponds to the target stub code pre-embedded in the target code in order to determine the repair path that should be invoked.

[0088] In some implementations, a stub mapping table can be read from the incremental differential package; then, based on the identification information of the repair code, the mapping stub corresponding to the identification information can be determined from the stub mapping table; and the mapping stub can be searched among the various code stubs to determine the target stub.

[0089] The stub mapping table is used to represent the correspondence between each piece of code and the code stub in the online application software. Each piece of code is used to implement the corresponding business logic when it is executed.

[0090] Each piece of code corresponds to a stub, which allows you to find that piece of code in the online application.

[0091] In practical implementation, a stub can be pre-embedded in each code segment of the application software. For example, code segment 1 pre-embeds stub ①, code segment 2 pre-embeds stub ②, and code segment 3 pre-embeds stub ③. Assume the following relationships exist in the stub mapping table:

[0092] Class L1 → Code Segment 1 → Stub ①

[0093] Class L2 → Code Segment 2 → Stub ②

[0094] Class L2 → Code Segment 3 → Stub ③

[0095] If the code identifier corresponding to a certain piece of repair code is "1" and the corresponding class identifier is "L1", then it can be determined that stub ① among stub ①, stub ② and stub ③ is the mapping stub, that is, the target stub.

[0096] In other implementations, after determining the target stub, the executor of this method can bind the target stub identifier to the currently loaded repair code and write the binding result to the runtime repair registry. This repair registry can reside in memory or be written to lightweight local storage to support rapid recovery after a short-term rebuild of the application process.

[0097] Regarding step 130 above, after determining the target pile point, the pile point code pre-embedded in the target pile point is determined to be the target pile point code.

[0098] The target code refers to the methods in the online application software that originally carried out specific target business logic, such as navigation voice broadcasting methods, page data rendering methods, or interface response processing methods. The target business logic represents the business processing results that the target code should have originally achieved. After the fix, it is implemented by the repair code. Therefore, the target code and the repair code correspond to each other in terms of business semantics. The only difference is that the original flawed logic is replaced by the repaired logic in the implementation code.

[0099] Target stub code is code pre-embedded at the entry point of target code during the application software's compilation phase through bytecode instrumentation. This target stub code is executed at runtime to perform interception and routing control. Specifically, before the application software is packaged and released, bytecode scanning can be performed on repairable code within a preset range, and uniformly formatted stub logic can be inserted at the entry point of each repairable code, such as inserting patch enable judgments and reading target stub identifiers. After instrumentation, a stub mapping table is generated based on code identifiers, class identifiers, and stub identifiers, and the instrumented bytecode is written back to the application package to ensure that the online application has runtime hotfix integration capabilities upon release.

[0100] In this embodiment, when the target code does not experience a business failure, or when the terminal does not obtain repair code to fix the target code, the target stub code will not run, that is, it will not intercept the call request to call the target code.

[0101] In addition, the target stub code is pre-embedded at the entry point of the target code, so that it can get the opportunity to run before the original business statement in the target code each time it is called. In this way, if the target code has a business failure, the target stub code will run before the original business statement. Once the target stub code runs, it will accurately intercept the call request and execute the routing logic, so that the original business statement waiting to be run will no longer run, thus preventing the failure from worsening.

[0102] In addition, it should be noted that the Android application development process can be divided into three major stages: (1) code writing stage, at which time the developer writes the source code; (2) compilation stage, in which the source code is compiled into intermediate .class files, and then further into .dex files that the Android operating system recognizes; (3) packaging and signing, in which the .dex files, resources, manifest files, etc. are packaged into an APK and signed.

[0103] Regarding step 140 above, when any business thread, UI thread, background task thread, or system callback thread initiates a call to the target code during application operation, the processor will execute the target stub code first because the target stub code has been pre-embedded at the target code entry point.

[0104] After the target stub code is executed, it can first check whether the binding relationship between the repair code corresponding to the target stub has been activated in the current application software; if it has not been activated, the call request is allowed to continue to enter the target code along the original execution path; if it has been activated, the call request is intercepted to prevent the defective logic of the original target code from continuing to execute.

[0105] Since the target stub code is used to intercept call requests that invoke the target code and route the intercepted call requests to the entry control code of the repair code, it undertakes the function of execution flow redirection at runtime. In specific implementation, the target stub code can encapsulate the parameter list in the call request into an array of objects, and pass the instance object, class object, thread identifier, and context handle together to the repair dispatcher. The repair dispatcher then calls the corresponding repair code according to the binding relationship between the target stub and the repair code.

[0106] In addition, if the target code has a return value, the repair code can return the result value to the original caller after type conversion after execution, so that the caller still perceives it as a normal call; if the target code has no return value, the repair code will end the distribution process after completing the corresponding business action.

[0107] The application software hotfix method provided in this application combines cloud-based incremental delivery capabilities, bytecode instrumentation capabilities pre-embedded during compilation, and runtime call request interception and routing capabilities to establish a complete hotfix chain from incremental differential packet reception, instrumentation point location, target code identification to repair code execution. This enables online applications to perform fast, accurate, and low-intrusion logic replacement on single target code segments while they are already running. Therefore, it not only solves the problems of prolonged whole-package updates, large impact, uncertain user upgrades, and the inability of monitoring-type instrumentation to directly repair runtime logic in traditional technologies, but also maintains business process continuity and repair execution stability in complex machine models, complex system versions, and multi-threaded call environments.

[0108] In some embodiments, before the online application software starts, the executable file of the online application software can be obtained; and the first metadata corresponding to each class in the executable file and the second metadata corresponding to each code segment in each class can be extracted; then, the code segments are classified based on the first metadata and the second metadata to determine the repairable code and the unrepairable code; finally, the unrepairable code is filtered out to obtain the repairable code, and finally, the bytecode instructions of the executable file are modified by bytecode instrumentation to pre-embed instrumentation code at the entry point of each repairable code.

[0109] In this embodiment, the executable file is used to carry the bytecode content generated by the online application software during the compilation stage, and can be a DEX file after compilation.

[0110] The first metadata is used to characterize the class's ownership information, access attributes, inheritance relationship, or class identifier. The second metadata is used to characterize the code name, code signature, parameter types, return type, access control attributes, and whether the code segment is encapsulated as a constructor, abstract method, or static method. When classifying code based on the above metadata, preset repair rules can be used to determine whether the code segment can be replaced, instrumented, or redirected by subsequent hotfix logic. For example, screening can be performed based on whether the class containing the code is a system class, whether it involves native calls, and whether it has non-rewriteable characteristics. Thus, a code segment that meets the repair conditions is identified as repairable code, and another code segment that does not meet the conditions is identified as unrepairable code.

[0111] After filtering out unrepairable code, a set of code segments that match the subsequent incremental differential package construction, stub mapping, and repair code binding can be retained.

[0112] In this embodiment, the metadata extraction process can be completed by parsing the bytecode structure, establishing a class-level metadata record for each class, and enumerating all code within the class to form a code-level metadata record.

[0113] By adopting this embodiment, repairable code can be quickly identified without affecting the overall application structure, and invalid processing of unrepairable code can be avoided, thereby reducing processing overhead and runtime adaptation risks. At the same time, since the target code is limited to the set of repairable code segments, the replacement and routing of subsequent repair code are more accurate, which helps to shorten the time for fault repair to take effect and improve the stability of online applications in complex terminal environments.

[0114] In addition, in some embodiments, after the classification and filtering of repairable and unrepairable code is completed, a stub mapping table can be constructed based on the identification information of the repairable code and the identification information of each code stub.

[0115] Bytecode instrumentation refers to the targeted rewriting of compiled bytecode without altering the original business logic of the executable file, embedding stub code at the entry point of repairable code. Bytecode instructions, as the processed objects, are output by the compiler when building the application package. The instrumentation process can be based on the ASM (Abstract Syntax Tree) framework, parsing class files one by one and injecting code snippets for call interception and routing at the entry point of repairable code. The stub code is used to take over control at the very first moment the code segment is invoked; therefore, its insertion position is usually close to the beginning of the code segment to ensure that the identification of the repair branch is completed before the original business logic is executed.

[0116] In practice, after filtering for fixable code, the instrumenter loads the bytecode of the target class and identifies the corresponding code signature. Then, it locates the code entry point based on code access permissions, parameter list, and return value type. The inserted stub code saves the execution context of that code and generates a corresponding stub identifier, enabling subsequent runtime to perform precise matching based on this identifier.

[0117] Among them, the code identifier is used to uniquely represent the code itself, the class identifier of the code is used to represent the class to which the code belongs, and the stub identifier is used to represent the stub code pre-embedded at the entrance. The three together constitute the index basis of the mapping relationship.

[0118] In this embodiment, the stub mapping table can be stored in the form of a key-value table, hash table, or persistent metadata file, and packaged together with the application software to enable quick retrieval of target stubs and their associated code segments during runtime.

[0119] In this embodiment, the instrumented executable file is loaded into the runtime environment after the application starts. When a code call reaches the entry point, the stub code is executed first, and then the class and identifier information corresponding to that code are located according to the stub mapping table, thereby supporting the routing switch of subsequent repair code. This method establishes a definite correspondence between each repairable code and its entry stub, enabling single-segment code-level repair without reinstalling the entire package and reducing interference with unaffected code. Using this method, hotfix localization is more precise, runtime switching is more timely, and the mapping relationship is clear and stable, which helps reduce compatibility risks and search overhead in online fault handling.

[0120] For example, Figure 2This is a flowchart illustrating the compiler bytecode instrumentation preprocessing process provided in an embodiment of this application. This bytecode instrumentation preprocessing can be executed by a compile-time instrumentation pre-embedding module. Specifically, the compile-time instrumentation pre-embedding module may include a dex traversal and parsing unit, an automatic stub insertion unit, and a stub mapping table generation unit. The entire process, through integrated bytecode instrumentation capabilities, is automatically executed during the application compilation and packaging phase, requiring no manual modification of the source code. Figure 2 As shown, it includes the following steps:

[0121] S11: Traversal and parsing of .dex files.

[0122] After the application APK is compiled and generates .dex files, the dex traversal and parsing unit automatically parses all classes.dex files, extracts the full class names, code names, code signatures and bytecode instruction sets, and filters and encapsulates them into unrepairable code such as constructors and static initialization methods.

[0123] S12: Automatic insertion of stake points.

[0124] The automatic stub insertion unit is based on the ASM bytecode manipulation framework. It inserts proxy stub code at the entry point of repairable code. The stub code only contains code call interception and routing logic, does not modify the original business instructions, and does not affect the normal operation of the application.

[0125] S13: Mapping table generation.

[0126] The stub mapping table generation unit generates an encrypted stub mapping table, which records the correspondence between class name, code signature, and stub ID. This table is packaged into the assets directory along with the application APK and serves as the matching basis for runtime repair.

[0127] S14: Compile and package.

[0128] After instrumentation is completed, the online baseline APK is compiled and generated normally, and then released to the app store. The terminal side can start the online application software by downloading and installing the online baseline APK from the app store.

[0129] In some embodiments, when developers discover code logic defects, crashes, or other faults in online application software, they only fix the corresponding code and compile a fixed version of the application software. The repair code in the incremental difference package is the difference code extracted from the fixed version of the application software after comparing the code segments in the online application software with the code segments in the fixed version of the application software.

[0130] Among them, the repaired version of the application software is generated by compiling the target code in the online application software after code repair. The target code and the difference code have the same signature, and the bytecode instructions of the target code are different from the bytecode instructions of the difference code.

[0131] It should be noted that in practical applications, a piece of code may be encapsulated as a specific execution method. Therefore, a piece of "code" in this application can also be represented or referred to as a "method".

[0132] In this embodiment, developers can fix the abnormal code causing business anomalies on the application development device, and then compile it to generate a fixed version of the application software. The application development device can perform differential comparison between the software installation packages of the online application software and the fixed version of the application software, extract the difference code, and package it together with the stub mapping table to form an incremental differential package.

[0133] The application development equipment can encrypt the incremental differential packet and upload it to the cloud.

[0134] In this embodiment, the patched application software carries the code content after the defect has been corrected and serves as the source of the repair logic to be distributed. Code signing is used to map the same-named and same-parameter code in the online application software and the patched application software, enabling comparison at the same granularity. Bytecode instructions represent the executable instruction sequence after compilation, a stub mapping table establishes the correspondence between code, classes, and stubs, incremental differential packages encapsulate the repair code and its corresponding mapping information, and the cloud receives uploaded content and distributes it upon terminal request.

[0135] In the specific implementation process, taking the application development device on the developer's side as the execution subject as an example, after the application development device obtains the repaired version of the application software provided by the developer, it can first parse the class file information in its installation package or executable file, then locate the corresponding second code segment in the online application software based on the code signature, and compare the bytecode instructions of the first code segment in the repaired application software with the second code segment in the online application software line by line. If a difference is detected, the first code in the repaired application software is regarded as the difference code, and it is extracted as the repair code. Subsequently, the repair code and the stub mapping table are encapsulated to form an incremental differential package for hot repair distribution.

[0136] During differential comparison, the signatures of the first code segment in the first repair package application software and the second code segment in the online application software are identical.

[0137] In addition, incremental differential packets can be encrypted using symmetric or asymmetric encryption before being uploaded to the cloud to prevent content leakage or tampering during transmission. The encrypted incremental differential packets are stored in the cloud and sent out when requested by the terminal application, allowing the terminal to obtain the corresponding repair logic without reinstalling the entire packet.

[0138] For example, Figure 3The flowchart for generating a single-segment code-level incremental differential packet is provided in an embodiment of this application. This single-segment code-level incremental differential packet generation process can be executed by an application development device. The application development device may include a differential packet generation module, which can be specifically divided into a bytecode difference comparison unit, an incremental differential packet packaging unit, and a differential packet encryption unit, to perform the following steps:

[0139] S21: Bytecode difference comparison.

[0140] The bytecode difference comparison unit loads the APKs of the online application software and the repaired application software, and compares the bytecode instructions line by line based on the code signature for precise matching. It extracts only the difference code where the bytecode instructions have been modified and filters out the code with no difference.

[0141] S22: Incremental packaging.

[0142] The incremental difference package packaging unit packages the bytecode of the difference code and stub matching information into an incremental difference package. The file format is a custom .patch format, and redundant resources and class files are removed.

[0143] S23: Cryptographic signature.

[0144] The differential packet encryption unit uses a combination of Advanced Encryption Standard (AES) symmetric encryption and asymmetric encryption algorithm signature to encrypt the incremental differential packet, preventing tampering and reverse engineering. After encryption, the packet is sent to the cloud server.

[0145] This application's embodiments avoid redundant transmission of irrelevant code through difference comparison and, by encapsulating it together with a stub mapping table, ensure accurate location of the target code in subsequent content delivery. Encryption before uploading to the cloud further enhances the security of the repaired content during transmission and storage. This enables rapid repair of the target code while the application is running online, reduces update package size, shortens fault convergence time, and minimizes the impact on user business continuity.

[0146] In other embodiments, after the Android application on the terminal side starts and obtains the incremental differential packet from the cloud, it can perform a verification operation on the incremental differential packet sent from the cloud. If the verification is successful, the incremental differential packet is decrypted to read the stub mapping table and repair code; if the verification fails, the incremental differential packet is discarded. The verification operation includes at least one of data packet validity verification and data packet integrity verification.

[0147] In this embodiment, the data packet validity check is used to determine whether the incremental differential packet meets the preset format, version rules or source authentication conditions, and the data packet integrity check is used to determine whether the incremental differential packet is missing, damaged or tampered with during transmission, thereby preventing abnormal data from entering the subsequent parsing link.

[0148] For example, data packet validity can be verified by checking the digital signature; data packet integrity can be verified by checking the MD5 value of the incremental differential packet using the Message-Digest Algorithm Version 5 (MD5).

[0149] Specifically, in actual processing, after receiving the incremental differential packet from the cloud, the terminal first reads the packet header information, length field, and verification field or digital signature field, and compares them with the locally stored verification rules to complete the legality judgment. Simultaneously, it can perform hash digest comparison, fragmentation verification, or reassembly verification on the packet body to confirm that no transmission errors have occurred. If the verification is successful, the terminal decrypts the incremental differential packet using a pre-agreed key to obtain the parsable data content and extracts the stub mapping table and repair code. If any verification fails, the parsing and loading of the incremental differential packet is terminated, and it is discarded directly to avoid invalid data affecting application operation.

[0150] This application's embodiments add a verification step before decryption and reading, ensuring that the terminal only proceeds to the subsequent parsing process after confirming that the incremental differential packet source is trustworthy and its content is complete. This guarantees the reliable loading of the stub mapping table and the repair code. Since abnormal incremental differential packets that fail verification are filtered before entering the repair link, the risk of repair failure caused by illegal distribution, transmission corruption, or content tampering can be reduced, thus improving the security, stability, and controllability of the online hot repair process.

[0151] Furthermore, in some embodiments, after the incremental differential package verification passes, an independent class loader can be constructed, and the incremental differential package can be loaded in the independent class loader. The independent class loader is isolated from the host application class loader, which is used to load online application software.

[0152] In this embodiment, the independent class loader refers to a class loading mechanism created at runtime specifically for handling incremental differential package parsing and loading tasks. Its loading scope is limited to differential repair content, and it is isolated from the host application class loader in terms of class search path, class parsing results, and loading namespace, so as to avoid duplicate definition, version confusion, or resource conflicts between classes in the incremental differential package and existing classes on the host side.

[0153] The host application class loader is used to load the original business classes, resource classes, and runtime dependencies of the application software, so that the original logic of the application is still maintained by the host side.

[0154] In practical implementation, an independent class loader can be instantiated during application runtime based on the loading requirements of the incremental differential package, and a dedicated loading path, cache directory, and dependency boundary can be configured for it, ensuring that it can only access the repair code within the incremental differential package. Subsequently, the decrypted incremental differential package is written to a preset storage location, and the independent class loader loads and parses its bytecode content to generate the corresponding runtime class object.

[0155] Because the host application class loader and the independent class loader are isolated from each other, classes already loaded on the host side will not be overwritten by classes with the same name in the incremental differential package, and the repair logic in the incremental differential package will not pollute the original class space of the host application. Therefore, repair content can be introduced without affecting the main operation of the application.

[0156] In this embodiment, the incremental differential package is loaded in an independent class loader, and the repair class and the host class are separated at runtime. This ensures that the repair logic takes effect in a timely manner while reducing the risks of class conflicts, code segment overriding anomalies, and compatibility degradation. Therefore, in scenarios where the application is already started and running, stable loading and invocation of the repair code can be achieved, improving the reliability and maintainability of the hotfix process.

[0157] Furthermore, in some embodiments, when a call request is routed to call the repair code to implement the business logic corresponding to the target code, the execution status of the repair code after it is called can be monitored; if the repair code encounters an abnormal state after it is called, the execution of the target stub code is stopped; and then the call request is switched back to call the target code.

[0158] Abnormal states include at least one of runtime crashes and application unresponsiveness.

[0159] In this embodiment, "abnormal state" is used to describe the abnormal execution situation that may occur after the repair code is called, and it can be used as a rollback trigger condition.

[0160] Once a terminal-side call request is routed to the fix code, a monitoring mechanism can be simultaneously established to monitor the execution status of the fix code. This monitoring includes code return results, thread liveness status, exception throwing status, message loop response status, and runtime feedback after foreground / background switching. If the fix code crashes, terminates abnormally, or fails to respond within a preset time, it is determined to be in an abnormal state, and the execution of the target stub code corresponding to that fix code is immediately stopped to prevent subsequent calls from entering the error fix logic.

[0161] Afterwards, the routing relationship of the call request is reset to point to the target code, so that subsequent similar calls will return to the original business code path for execution.

[0162] Figure 4 This is a schematic diagram of a hot-repair process without restarting during terminal operation provided in an embodiment of this application. This repair process can be executed by the repair execution module on the terminal side. When the Android application software (i.e., the online application software) on the terminal side starts, the repair is automatically completed through the repair execution module. The entire process is imperceptible to the user and does not require restarting the Android application software. Figure 4 As shown, it includes the following steps:

[0163] S31: Differential packet acquisition and verification.

[0164] Online applications can proactively request incremental differential packets from the cloud. After downloading, they verify the MD5 value and digital signature of the file. If the verification fails, the file is discarded. If the verification is successful, the file is stored in the application's private directory to prevent external illegal file injection.

[0165] S32: Isolation Load Decryption.

[0166] The incremental differential package verification and decryption unit in the execution module has been fixed to decrypt incremental differential packages. By constructing an independent class loader, which is isolated from the host application class loader, issues such as duplicate class loading and resource ID conflicts are avoided.

[0167] S33: Dynamic route replacement via code.

[0168] The code dynamic routing unit in the repair execution module reads the stub mapping table, matches the target repair code, intercepts the call of the original target code through the stub proxy, and dynamically routes the execution logic to the repair code in the differential package, realizing the real-time replacement of single-segment abnormal code.

[0169] S34: Abnormal rollback control.

[0170] The exception rollback unit in the repair execution module monitors the running status of the repair code in real time. If an exception such as a crash or application not responding (ANR) occurs, the routing is immediately cut off, the original code logic is restored, and the repair exception log is reported to ensure the availability of the application's core functions.

[0171] In this embodiment, if an anomaly occurs during the execution of the repair code, the continuous propagation of the abnormal repair logic can be blocked in a timely manner, and the call request can be quickly restored to the target code. This reduces the impact of hot repair failure on application stability, reduces page freezes, function interruptions and business link failures caused by error repair, and improves the rollbackability and overall availability of online repair.

[0172] In some embodiments, since the Android operating system has different versions, a compatibility adaptation module can be used to perform differentiated adaptation for different Android systems to execute the aforementioned application hotfix process. Specifically, if the target operating system is Android, the compatibility adaptation module can obtain the system version information of the Android operating system; and based on the system version information, determine the target compatibility adaptation strategy from various preset compatibility adaptation strategies; then, using the target compatibility adaptation strategy, execute the fix code in the Android operating system.

[0173] The preset compatibility adaptation strategies include at least one of the following: optimizing the executable file loading process, reverting the repair code compiled into machine code to the bytecode interpretation execution mode before compilation, and adjusting the storage directory of the repair code.

[0174] In this embodiment, the system version information is used to represent the version number of the current Android operating system. For example, it can be divided into Android 4.4 and below (running on the Dalvik virtual machine), Android 5.0 and above (running on the ART virtual machine), Android 9+, and Android 14.

[0175] For example, for Android versions 4.4 and below running on the Dalvik virtual machine, the executable file loading process can be optimized. When the Dalvik virtual machine installs or loads online applications, it pre-optimizes the .dex file. This process strictly verifies internal dependencies. If it finds that a class references a "method" (encapsulated by a piece of code) of another class, but that class originally did not have this "method" (because it was later "replaced" by stub code through routing), the verification will fail, directly causing the application to crash. Therefore, by optimizing the loading process of executable files (such as .dex files), it can be ensured that, from the perspective of the Dalvik virtual machine, all direct references between classes are legal and existent, thereby ensuring that hotfix methods are compatible with the Dalvik virtual machine (Android 4.4 and below).

[0176] For Android 5.0 and above running on the ART virtual machine, because the ART virtual machine supports AOT compilation (meaning the application is pre-compiled during installation), the code segments encapsulated as "methods" have already been compiled into machine code. If only the pointers to these "methods" are replaced at the Java / Kotlin level, but the ART virtual machine is already executing its pre-compiled older version of machine code, the fix may not take effect. Therefore, it's necessary to adapt to the AOT compilation mechanism, allowing the ART virtual machine to revert the specified "methods," which have already been compiled into machine code, to bytecode interpretation execution mode. This way, the stubs inserted into the target code will take effect, intercepting and routing to the fix code during interpretation execution.

[0177] For Android 9+ privacy restrictions and higher versions of Android operating systems such as Android 14, which have tightened application permissions and enhanced security protection and loading controls, it is necessary to adjust the private directory loading logic to adapt to system permission rules. For example, in Android 9+, the system restricts the execution permissions of files in the private directory of an app. If you directly put the executable code (i.e., the fix code) in the private directory and try to load it, the system may not allow it. Therefore, adjusting the storage directory of the fix code means changing the storage location of the fix code to the path of executable code that the system explicitly allows to be loaded, so as to avoid triggering security restrictions.

[0178] This application embodiment selects the corresponding adaptation strategy based on system version information, which enables the hotfix process to avoid loading and permission differences between different Android versions, reduces fix failures, crashes or unresponsiveness caused by inconsistent system compatibility, and improves the execution stability of the fix code and the efficiency of online fault convergence.

[0179] Figure 5 This is a schematic diagram of the overall process of the application software hotfix method provided in the embodiments of this application, such as... Figure 5 As shown, it includes the following steps:

[0180] Step 51: Pre-installation of instrumentation during compilation.

[0181] Step 511: During compilation, the instrumentation pre-embedded module performs dex traversal → instrumentation insertion → mapping table generation.

[0182] Step 512: Generate an online baseline APK and publish it to the app store.

[0183] Step 52: If the online application malfunctions, obtain a fixed APK provided by the developer.

[0184] Step 53: Incremental differential packet generation.

[0185] Step 531: The differential packet generation module performs difference comparison → incremental packaging → encrypted signing.

[0186] Step 54: Repair during terminal runtime.

[0187] Step 541: Repair the execution module's execution verification and decryption → isolate loading → code replacement → exception rollback.

[0188] Step 55: Compatibility adaptation.

[0189] Step 551: The compatibility adaptation module performs adaptation for different virtual machines or Android operating system versions.

[0190] The execution of this repair method involves four core modules: a compile-time instrumentation module, a differential package generation module, a repair execution module, and a compatibility adaptation module. The specific process is as follows:

[0191] 1. Compile-time bytecode instrumentation: Traverse all class methods in the application's .dex file, automatically insert stub proxy markers into the repairable code, generate a stub mapping table, and do not modify the original business logic;

[0192] 2. Baseline and Repair Package Differential Processing: Compare the bytecode of the online application software APK and the repaired APK, extract the difference code to generate a lightweight incremental differential package, encrypt it and send it to the terminal;

[0193] 3. Terminal differential packet verification and loading: The terminal verifies the integrity and legality of the differential packet, decrypts it, and loads it into the application's independent class loader, which is isolated from the host class loader to avoid class conflicts;

[0194] 4. Runtime-based, restart-free single-segment code-level replacement: By intercepting target code calls through stub proxies, the code is dynamically routed to incremental differential packages to repair the code, achieving real-time replacement at the single-segment code level without restarting the application;

[0195] 5. Repair status management and rollback: Record the repair execution status. If the repair fails, the rollback mechanism will be automatically triggered to restore the original method logic and ensure application stability.

[0196] This embodiment marks and pre-embeds bytecode instrumentation in the target code of the online application software during the compilation phase. In case of failure, it generates a single-segment code-level incremental differential package. At runtime, it achieves code replacement without restarting based on the Android class loading mechanism. The entire process does not require modification of the application source code, repackaging and installation, or restarting the application. At the same time, it avoids class loading conflicts and version compatibility issues.

[0197] The repair method provided in this application is applied to online fault emergency repair scenarios for Android applications. It supports native Android applications written in Java / Kotlin and is compatible with Android 4.4 and above. It overcomes the technical problems of traditional bytecode instrumentation technology, which is only used for monitoring and lacks hot-repair capabilities, as well as the large update size, application restart requirement, coarse-grained repair, class loading conflicts, and poor compatibility of traditional Android hot-repair methods. This repair method has the following effects:

[0198] 1. Precise repair granularity and lightweight design: Employing single-segment code-level incremental differential repair, only the difference code bytecode is distributed, and the differential package size is much smaller than the whole package / class-level repair, saving traffic and storage resources;

[0199] 2. Real-time repair without restart, seamless for users: Based on dynamic routing of stub agents, online faults are repaired in seconds without restarting the application or exiting the page, without interrupting user access;

[0200] 3. Zero source code intrusion and strong adaptability: Automatic instrumentation during compilation, no need to modify business source code, supports Android 4.4 to the latest version, and is compatible with ART / Dalvik virtual machines, multiple packages, and component-based architecture;

[0201] 4. High stability and no class loading conflicts: Independent class loader isolation mechanism avoids conflicts between host and repair package classes and resources, and built-in exception rollback mechanism prevents repair from causing secondary crashes;

[0202] 5. Reuses core bytecode instrumentation capabilities with strong scalability: Expands repair capabilities based on existing instrumentation technology, and is compatible with integrated deployment of multiple capabilities such as monitoring, data entry, and hotfix.

[0203] Figure 6 This is a schematic diagram of the application software hot-repair device provided in the embodiments of this application, such as... Figure 6 As shown, the application software hotfix device 60 includes:

[0204] The detection module 601 is used to read the repair code in the incremental differential packet when the online application software starts on the target operating system and sends a data packet request to the cloud. If the incremental differential packet sent by the cloud based on the data packet request is detected, the module 601 is used to read the repair code in the incremental differential packet.

[0205] The determination module 602 is used to determine the target stub among various code stubs in the online application software based on the repair code.

[0206] The acquisition module 603 is used to determine the target code marked by the target stake point and the target stake point code pre-embedded at the target code entry point from the online application software.

[0207] The calling module 604 is used to run the target stub code to intercept the call request when a call request for the target code is detected, and to route the call request to the call repair code to implement the target business logic corresponding to the target code.

[0208] Optionally, the module can be specifically used for:

[0209] Read the stub mapping table from the incremental differential package. The stub mapping table is used to represent the correspondence between each piece of code in the online application software and the code stub used to mark the code. Each piece of code is used to implement the corresponding business logic when it is executed.

[0210] Based on the identification information of the repair code, determine the mapping stub corresponding to the identification information from the stub mapping table;

[0211] Find the mapping stub among the various code stubs and determine it as the target stub.

[0212] Optionally, the application software hotfix device 60 also includes a screening module for:

[0213] Obtain the executable file of the online application software before it starts;

[0214] Extract the first metadata corresponding to each class in the executable file, and the second metadata corresponding to each code segment in each class;

[0215] Based on the first and second metadata, each code segment is classified to determine the repairable and unrepairable code.

[0216] The unrepairable code is filtered out to obtain the remaining repairable code;

[0217] By instrumenting bytecode, the bytecode instructions of the executable file are modified to pre-embed stub code at the entry point of each patchable code.

[0218] Optionally, the application software hotfix device 60 also includes a table building module for: building a stub mapping table based on the identification information of the repairable code and the identification information of each code stub.

[0219] Optionally, the repair code in the incremental difference package is the difference code extracted from the repaired application software after comparing the code segments in the online application software with the code segments in the repaired application software; wherein, the repaired application software is generated by compiling the target code in the online application software after code repair.

[0220] Optionally, the detection module can be specifically used to: perform verification operations on the incremental differential packets issued from the cloud; if the verification is successful, decrypt the incremental differential packets to read the stub mapping table and repair code; if the verification fails, discard the incremental differential packets. The verification operation includes at least one of data packet validity verification and data packet integrity verification.

[0221] Optionally, the application software hotfix device 60 also includes a loading module for constructing an independent class loader and loading incremental differential packages in the independent class loader. The independent class loader is isolated from the host application class loader, which is used to load online application software.

[0222] Optionally, the application software hotfix device 60 further includes a monitoring module for monitoring the execution status of the fix code after it is invoked; if the fix code encounters an abnormal state after being invoked, the target stub code is stopped from running; and the invocation request is switched back to the target code. The abnormal state includes at least one of runtime crashes and application unresponsiveness.

[0223] Optionally, the application software hotfix device 60 also includes a compatibility adapter module for:

[0224] If the target operating system is Android, then obtain the Android operating system version information;

[0225] Based on system version information, the target compatibility adaptation strategy is determined from various preset compatibility adaptation strategies. The preset compatibility adaptation strategies include at least one of the following: optimizing the executable file loading process, reverting the repair code compiled into machine code to the bytecode interpretation execution mode before compilation, and adjusting the storage directory of the repair code.

[0226] By leveraging target compatibility adaptation strategies, fix code is executed within the Android operating system.

[0227] The application software hot repair device provided in this embodiment can execute the method provided in the above method embodiment. Its implementation principle and technical effect are similar, and will not be described in detail here.

[0228] Figure 7 A schematic diagram of the structure of the electronic device provided in this application. Figure 7 As shown, the electronic device 701 provided in this embodiment includes at least one processor 702 and a memory 703. Optionally, the electronic device 701 further includes a communication interface 704. The processor 702, memory 703, and communication interface 704 are connected via a bus 705.

[0229] In a specific implementation, at least one processor 702 executes computer execution instructions stored in memory 703, causing at least one processor 702 to perform the above-described method.

[0230] The specific implementation process of processor 702 can be found in the above method embodiments, and its implementation principle and technical effect are similar. It will not be repeated here.

[0231] In the above embodiments, it should be understood that the processor can be a Central Processing Unit (CPU), or other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), etc. The general-purpose processor can be a microprocessor or any conventional processor. The steps of the method disclosed in this invention can be directly implemented by a hardware processor, or implemented by a combination of hardware and software modules within the processor.

[0232] The memory may include random access memory (RAM) and may also include non-volatile memory (NVM), such as at least one disk storage device.

[0233] The bus can be an Industry Standard Architecture (ISA) bus, a Peripheral Component Interconnect (PCI) bus, or an Extended Industry Standard Architecture (EISA) bus, etc. Buses can be categorized as address buses, data buses, control buses, etc. For ease of illustration, the buses shown in the accompanying drawings are not limited to a single bus or a single type of bus.

[0234] This application also provides a vehicle, which includes a vehicle body and the aforementioned electronic device disposed in the vehicle body, the electronic device being capable of performing various steps in the application software hot-repair method provided in the above embodiments.

[0235] This application also provides a computer-readable storage medium storing computer-executable instructions, which, when executed by a processor, implement the above-described method.

[0236] The aforementioned readable storage medium can be implemented by any type of volatile or non-volatile storage device or a combination thereof, such as static random access memory (SRAM), electrically erasable programmable read-only memory (EEPROM), erasable programmable read-only memory (EPROM), programmable read-only memory (PROM), read-only memory (ROM), magnetic storage, flash memory, magnetic disk, or optical disk. The readable storage medium can be any available medium accessible to a general-purpose or special-purpose computer.

[0237] An exemplary readable storage medium is coupled to a processor, enabling the processor to read information from and write information to the readable storage medium. Of course, the readable storage medium can also be a component of the processor. The processor and the readable storage medium can reside in an Application Specific Integrated Circuit (ASIC). Alternatively, the processor and the readable storage medium can exist as discrete components in the device.

[0238] The division of units is merely a logical functional division; in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be indirect coupling or communication connection through some interfaces, devices, or units, and may be electrical, mechanical, or other forms.

[0239] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0240] In addition, the functional units in the various embodiments of the present invention can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit.

[0241] If a function is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this invention, or the part that contributes to the prior art, or a part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods of the various embodiments of this invention. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0242] Those skilled in the art will understand that all or part of the steps of the above-described method embodiments can be implemented by hardware related to program instructions. The aforementioned program can be stored in a computer-readable storage medium. When executed, the program performs the steps of the above-described method embodiments. The aforementioned storage medium includes various media capable of storing program code, such as ROM, RAM, magnetic disks, or optical disks.

[0243] Finally, it should be noted that other embodiments of the invention will readily occur to those skilled in the art upon consideration of the specification and practice of the invention disclosed herein. This invention is intended to cover any variations, uses, or adaptations of the invention that follow the general principles of the invention and include common knowledge or customary techniques in the art not disclosed herein, and is not limited to the precise structures described above and shown in the accompanying drawings, and various modifications and changes can be made without departing from its scope. The scope of the invention is limited only by the appended claims.

[0244] The above embodiments are merely preferred embodiments provided to fully illustrate the present invention, and the scope of protection of the present invention is not limited thereto. Equivalent substitutions or modifications made by those skilled in the art based on the present invention are all within the scope of protection of the present invention.

Claims

1. A method for hotfixing application software, characterized in that, include: When an online application starts on the target operating system and sends a data packet request to the cloud, if an incremental differential packet sent by the cloud based on the data packet request is detected, the repair code in the incremental differential packet is read. Based on the repair code, the target stub is determined among the various code stubs in the online application software; The target code marked by the target stake point and the target stake point code pre-embedded at the entry point of the target code are determined from the online application software; When a call request for the target code is detected, the target stub code is run to intercept the call request and the call request is routed to call the repair code to implement the target business logic corresponding to the target code.

2. The method according to claim 1, characterized in that, The step of determining the target stub among the various code stubs within the online application software based on the repair code includes: Read the stub mapping table from the incremental differential package. The stub mapping table is used to represent the correspondence between each piece of code and code stubs in the online application software. Each piece of code is used to implement the corresponding business logic when executed. Based on the identification information of the repair code, determine the mapping stub corresponding to the identification information from the stub mapping table; The mapping stub is located among the various code stubs and determined as the target stub.

3. The method according to claim 1, characterized in that, Also includes: Before the online application software is launched, obtain the executable file of the online application software; Extract the first metadata corresponding to each class in the executable file, and the second metadata corresponding to each code segment in each class; Based on the first metadata and the second metadata, each code segment is classified to determine repairable and unrepairable code. The unrepairable code is filtered out to obtain the remaining repairable code; The bytecode instructions of the executable file are modified by bytecode instrumentation to pre-embed stub code at the entry point of each repairable code.

4. The method according to claim 3, characterized in that, Also includes: Based on the identification information of the repairable code and the identification information of each code stub, a stub mapping table is constructed.

5. The method according to claim 1, characterized in that, The repair code in the incremental differential package is the difference code extracted from the repaired application software after comparing the code segments in the online application software with the code segments in the repaired application software. The repaired version of the application software is generated by compiling the target code in the online application software after code repair.

6. The method according to claim 1, characterized in that, The step of reading the repair code from the incremental differential packet includes: The incremental differential packets sent from the cloud are verified, and the verification operation includes at least one of data packet validity verification and data packet integrity verification. If the verification is successful, the incremental differential packet is decrypted to read the repair code; If the verification fails, the incremental differential packet will be discarded.

7. The method according to claim 1, characterized in that, Also includes: Construct an independent class loader, which is isolated from the host application class loader. The host application class loader is used to load the online application software. The incremental differential package is loaded in the independent class loader.

8. The method according to claim 1, characterized in that, Also includes: Monitor the execution status of the fix code after it is invoked; If the repair code encounters an abnormal state after being invoked, the execution of the target stub code is stopped. The abnormal state includes at least one of runtime crash and application unresponsiveness. Switch the call request back to calling the target code.

9. The method according to claim 1, characterized in that, Also includes: If the target operating system is Android, then obtain the system version information of the Android operating system; Based on the system version information, a target compatibility adaptation strategy is determined from various preset compatibility adaptation strategies. The preset compatibility adaptation strategies include at least one of the following: optimizing the executable file loading process, reverting the repair code compiled into machine code to the bytecode interpretation execution mode before compilation, and adjusting the storage directory of the repair code. The fix code is executed in the Android operating system using the target compatibility adaptation strategy.

10. An application software hotfix device, characterized in that, include: The detection module is used to read the repair code in the incremental differential packet when the online application software starts on the target operating system and sends a data packet request to the cloud. The determination module is used to determine the target stub among the various code stubs in the online application software based on the repair code. The acquisition module is used to determine the target code marked by the target stake point and the target stake point code pre-embedded at the entry point of the target code from the online application software; The calling module is used to intercept the calling request by running the target stub code when the calling request of the target code is detected, and to route the calling request to call the repair code in order to realize the target business logic corresponding to the target code.

11. An electronic device, characterized in that, include: Memory and at least one processor; The memory stores computer-executed instructions; The processor executes computer execution instructions stored in the memory, causing the processor to perform the method as described in any one of claims 1-9.

12. A vehicle, characterized in that, include: The vehicle body and the electronic device as described in claim 11 disposed in the vehicle body.

13. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer-executable instructions, which, when executed by a processor, are used to implement the method as described in any one of claims 1-9.

Images