Hot repair method, system, device and equipment for Android application

Abstract

The embodiment of the invention provides an Android application-oriented hot repair method, system, device and equipment, relates to the technical field of information, and is applied to a client. The hot repair method comprises the following steps: responding to a received software repair update notification oriented to the Android application, and requesting a server to download a software service pack of the Android application; in response to the received downloading address returned by the server side, downloading the software service pack from the downloading address; generating a complete repair file based on the software service pack; starting a restart monitoring service for the Android application to wait for an application restart opportunity, and restarting the Android application when it is monitored that the Android application conforms to the application restart opportunity; and after the Android application is restarted, loading the repair file to complete the hot repair of the Android application. According to the application, a mechanism that the server actively pushes the repair and update notification of the Android application is adopted, so that real-time issuing of the software service pack is realized; and meanwhile, a restart monitoring service is introduced, and an opportunity is automatically selected to complete application restart, so that the hot repair efficiency is greatly improved.

Description

Technical Field

[0001] The present application relates to the field of information technology, and in particular to a hot repair method, system, device and equipment for Android applications. Background Art

[0002] With the rapid development of mobile internet technology, the number of Android apps has exploded. Consequently, with such a massive application volume, rapid app iteration and emergency fixes have become significant challenges for developers. Traditional app updates rely on the app market's release process. Specifically, after fixing a behavioral unexpected glitch (BUG) or adding a new feature, developers must repackage the Android application package (APK) and submit it to major app markets for review. Only after approval can users receive an update notification and manually download and install it. However, this process presents numerous challenges, including: 1) App market review cycles are lengthy, making it difficult to meet the needs of emergency fixes; 2) users must download and reinstall the full APK, which some users may choose to delay due to data or time constraints, resulting in the long-term existence of high-risk bugs; and 3) frequent full updates can reduce user retention and impact product competitiveness. To address these issues, hotfix technology has emerged. This technology allows developers to dynamically fix bugs or update features by issuing patch packages without republishing the APK, significantly shortening the repair cycle and improving the user experience.

[0003] In related technologies, hotfixes are typically implemented through class loading. Specifically, the repaired class code corresponding to an Android application is packaged as an external Dex file. While the Android application is running, the client on which the Android application is installed periodically checks whether a repair package for the Android application exists. If a repair package exists, the client loads the external Dex file through DexClassLoader to replace the problematic class code in the Android application. After the replacement, the user is prompted to restart the application to implement the bug fix or function update for the Android application.

[0004] However, the above class loading hot repair solution has the problem of low hot repair efficiency. Summary of the Invention

[0005] The present application provides a hot repair method, system, device and equipment for Android applications to improve the efficiency of hot repair.

[0006] In a first aspect, an embodiment of the present application provides a hot repair method for Android applications, which is applied to a client. The hot repair method includes:

[0007] In response to receiving a software repair and update notification for an Android application, requesting the server to download a software patch package for the Android application;

[0008] In response to receiving the download address of the software patch package returned by the server, download the software patch package from the download address;

[0009] Generate complete repair files based on the software patch package;

[0010] Start the restart monitoring service for Android applications and wait for the application restart time. When the Android application is detected to meet the application restart time, restart the Android application.

[0011] After the Android application is restarted, the repair file is loaded to complete the hot repair of the Android application.

[0012] In one possible implementation, a software patch package includes a marker file for identifying whether each file in the version file of an Android application has changed. Based on the software patch package, a complete repair file is generated, including: traversing each file in the previous version file of the Android application, and based on the marker file, dividing each file in the previous version file into changed files and unchanged files, where the changed files include newly added files; for the changed files, based on a synthesis algorithm, a synthetic file is generated according to the software patch package and the changed files; the synthetic file is saved to the DEX file directory of the current version, and the unchanged files are copied to the file directory of the current version to obtain a complete repair file.

[0013] In one possible implementation, when it is detected that the Android application meets the application restart timing, the Android application is restarted, including: when it is detected that the Android application is in a background suspended state and no key operations are performed, the context information of the current page of the Android application is saved locally, and the Android application is restarted; correspondingly, a repair file is loaded to complete the hot repair of the Android application, including: loading the repair file and restoring the page state of the Android application according to the context information saved locally to complete the hot repair of the Android application.

[0014] In one possible implementation, loading the repair file includes: determining whether a new software patch package exists on the server; if no new software patch package exists on the server, checking whether a complete repair file exists locally; if a complete repair file exists locally, loading the repair file.

[0015] In a possible implementation, the hot repair method for Android applications further includes: if a new software patch package exists on the server, downloading the software patch package from the download address is executed; if a complete patch file does not exist locally, terminating the current hot repair process.

[0016] In a possible implementation, the downloaded software patch package is generated based on the file difference between the version file of the current repair version and the version file of the previous repair version.

[0017] In a second aspect, the present application provides a hotfix system for Android applications, comprising:

[0018] A client, configured to execute the method as described in any one of the first aspects;

[0019] The server is used to manage the patch packages uploaded by the developer, push software fix update notifications for Android applications to the client, and respond to requests from the client to download software patch packages for Android applications.

[0020] In one possible implementation, the hot repair system for Android applications also includes a development end, which is used to generate a software patch package corresponding to the current repair version based on the file difference between the version file of the current repair version of the Android application and the version file of the previous repair version. The software patch package contains a marker file that identifies whether the file has changed.

[0021] In a third aspect, the present application provides a hot repair device for Android applications, which is applied to a client. The hot repair device for Android applications includes:

[0022] An update request module, configured to request the server to download a software patch package for the Android application in response to receiving a software repair update notification for the Android application;

[0023] The patch download module is used to download the software patch package from the download address when receiving the download address of the software patch package returned by the server;

[0024] Patch synthesis module, used to generate complete repair files based on software patch packages;

[0025] The restart monitoring module is used to start the restart monitoring service for the Android application and wait for the application restart time, and restart the Android application when it is detected that the Android application meets the application restart time; and after the Android application is restarted, the repair file is loaded to complete the hot repair of the Android application.

[0026] In a third aspect, the present application provides an electronic device, comprising: a processor, and a memory communicatively connected to the processor;

[0027] Memory for storing computer-executable instructions;

[0028] A processor is configured to execute computer-executable instructions stored in a memory to implement the method described in any one of the first aspects.

[0029] In a fourth aspect, the present application provides a computer-readable storage medium, which stores computer-executable instructions. When the computer-executable instructions are executed, they are used to implement any of the methods described in the first aspect.

[0030] In a fifth aspect, the present application provides a computer program product, comprising a computer program, which implements the method described in any one of the first aspects when executed.

[0031] The present application provides a hot repair method, system, device and equipment for Android applications, which are applied to the client, wherein the hot repair method includes: in response to receiving a software repair and update notification for the Android application, requesting the server to download the software patch package of the Android application; in response to receiving the download address of the software patch package returned by the server, downloading the software patch package from the download address; generating a complete repair file based on the software patch package; starting a restart monitoring service for the Android application to wait for the application restart time, and restarting the Android application when it is detected that the Android application meets the application restart time; after the Android application is restarted, loading the repair file to complete the hot repair of the Android application. In this process, by adopting a mechanism in which the server actively pushes the software repair and update notification of the Android application, replacing the traditional client polling method, the real-time and accurate distribution of the software patch package is achieved; at the same time, an intelligent restart monitoring service is introduced to automatically select the appropriate time to complete the application restart, which not only solves the response delay and human dependence problems existing in traditional hot repair technology, but also greatly improves the hot repair efficiency while ensuring application stability by optimizing the patch distribution and effectiveness mechanism. This efficient and reliable hot repair method not only meets the needs of rapid iteration of Android applications, but also ensures system security and significantly improves the user experience. BRIEF DESCRIPTION OF THE DRAWINGS

[0032] The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate embodiments consistent with the present application and, together with the description, serve to explain the principles of the present application.

[0033] Figure 1 A schematic diagram of an application scenario of a hot repair method for Android applications provided by an exemplary embodiment of the present application;

[0034] Figure 2 A schematic diagram of a process flow of a hot repair method for Android applications provided by an exemplary embodiment of the present application;

[0035] Figure 3 A schematic diagram of a process of restarting monitoring provided by an exemplary embodiment of the present application;

[0036] Figure 4 A schematic diagram of a hot repair system for Android applications provided by an exemplary embodiment of the present application;

[0037] Figure 5 A schematic diagram of the structure of a server provided by an exemplary embodiment of the present application;

[0038] Figure 6 A schematic diagram of a workflow of a publishing and updating unit provided for an exemplary embodiment of the present application;

[0039] Figure 7 Another workflow diagram of the publishing and updating unit provided by the exemplary embodiment of the present application;

[0040] Figure 8 A schematic structural diagram of a client provided for an exemplary embodiment of the present application;

[0041] Figure 9 Another structural diagram of a hot repair system for Android applications provided by an exemplary embodiment of the present application;

[0042] Figure 10 A schematic diagram of the structure of a development terminal provided for an exemplary embodiment of the present application;

[0043] Figure 11 A schematic diagram of a workflow of a patch construction unit provided for an exemplary embodiment of the present application;

[0044] Figure 12 Another structural diagram of a client provided for an exemplary embodiment of the present application;

[0045] Figure 13 A simplified schematic diagram of Android application hotfix provided for an exemplary embodiment of the present application;

[0046] Figure 14 An architectural diagram of a hot repair system for Android applications provided by an exemplary embodiment of the present application;

[0047] Figure 15 A schematic structural diagram of a hot repair device for Android applications provided by an exemplary embodiment of the present application;

[0048] Figure 16 A schematic structural diagram of an electronic device provided as an exemplary embodiment of the present application.

[0049] The above drawings illustrate specific embodiments of the present application, which will be described in more detail below. These drawings and the textual description are not intended to limit the scope of the present application in any way, but rather to illustrate the concepts of the present application to those skilled in the art by reference to specific embodiments. DETAILED DESCRIPTION

[0050] Exemplary embodiments will be described in detail herein, with examples illustrated in the accompanying drawings. In the following description, when referring to the drawings, identical numerals in different figures represent identical or similar elements, unless otherwise indicated. The embodiments described in the following exemplary embodiments are not intended to represent all embodiments consistent with the present application. Rather, they are merely examples of apparatus and methods consistent with certain aspects of the present application, as detailed in the appended claims.

[0051] The terms "first", "second" etc. in the specification and claims of the present application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequential order. It should be understood that the data used in this way can be interchangeable in appropriate circumstances, so that the embodiments of the present application described herein can, for example, be implemented in an order other than those illustrated or described herein. In addition, the terms "including" and "having" and any of their variations are intended to cover non-exclusive inclusions, for example, the process, system, product or equipment comprising a series of steps or units is not necessarily limited to those steps or units clearly listed, but may include other steps or units that are not clearly listed or that are inherent to these processes, products or equipment.

[0052] It should be noted that the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, stored data, displayed data, etc.) involved in this application are all information and data authorized by the user or fully authorized by all parties, and the collection, use and processing of relevant data must comply with relevant laws, regulations and standards, and provide corresponding operation entrances for users to choose to authorize or refuse.

[0053] First, let’s explain the terms involved in this application:

[0054] APK: The installation package of an Android application, which contains all the code, resources and configuration files of the application. An APK contains one or more Dex files, shared object library (SO) files and multiple resource files. Among them, Dex files are class files of Java code, SO files are dynamic link library files called by the underlying layer, and resource files are some layout, pictures, multimedia and other files.

[0055] APK signing: It is an important operation for packaging installable files of Android applications. By digitally signing the application's APK, the integrity and security of the application can be ensured.

[0056] AndroidManifest file: It is the configuration manifest file of the Android application, which is used to describe the component structure, permission requirements, Software Development Kit (SDK) version requirements and other information of the application. It is also one of the entry files of the Android application.

[0057] Code obfuscation: This is a common security measure used to protect application source code from reverse engineering and malicious decompilation. By obfuscating the code, the source code becomes difficult to understand and analyze, making it more difficult for attackers to reverse engineer the application.

[0058] MultiDex: When the Android system was first designed, it was not considered that the number of methods of an application would exceed 65536. With the development of mobile application technology, this limit is far from meeting the needs of the project. MultiDex allows applications to include multiple Dex files in a single APK file, one main Dex file and multiple slave Dex files, thereby expanding the method number limit and ensuring that the application can run normally.

[0059] Differential package: refers to a technology used for software or firmware updates. It generates a smaller patch package by comparing the differences between the old and new versions. The patch package can be used to quickly and efficiently upgrade the old version files to the new version.

[0060] Instrumentation: It is a technology that dynamically adds, modifies, and replaces source code to achieve the effect of functional expansion.

[0061] Publish-subscribe pattern: It is a behavioral design pattern used to define a one-to-many dependency relationship between objects. When the state of an object (publisher) changes, all its dependents (subscribers) will be notified and automatically updated.

[0062] Class loader: Responsible for loading Java class files and converting them into Class type objects. The Android virtual machine mainly includes three class loaders: BootClassLoader, PathClassLoader, and DexClassLoader. Among them, DexClassLoader can be used to load Dex files in external directories.

[0063] The four major components of Android: Activity, Service, Broadcast Receiver and Content Provider, are the four core building blocks of the Android application system. These four components work together to build the functionality and structure of the entire application.

[0064] Proxy pattern: It is a structural design pattern that controls access to another object through a proxy class. Additional operations can be performed before or after accessing the object, thereby achieving control, protection or enhancement of the proxied object.

[0065] Cold start: refers to the process of restarting the application after the application has completed bug repair or updated functions.

[0066] Baseline package: In the hot fix scenario, the APK version currently uploaded to the app store will be used as the baseline package. Each subsequent hot fix package generated will be based on the current online version APK package.

[0067] In related technologies, when implementing hot fixes for Android applications using class loading, the client is relied upon to proactively request a check for the existence of a software patch package, resulting in significant delays in detecting the software patch package and failing to meet the timeliness requirements for urgent bug fixes. Furthermore, hot fixes typically require a cold restart to take effect, meaning that after the application is repaired, the user must manually close the application and restart the Android application for the repair to take effect. This not only requires the user to manually restart the application to complete the repair, but also, due to the uncertainty of user operations (such as delayed restarts or forgotten restarts), critical patches may not take effect for a long time. This design flaw of dual reliance (relying on both polling detection and manual restarts) not only significantly reduces the real-time and reliability of hot fixes, but also unnecessarily prolongs the time the system is exposed to potential security risks, seriously affecting the efficiency of hot fixes.

[0068] In order to solve the above problems, the embodiment of the present application provides a hot repair solution for Android applications. By establishing an active push mechanism on the server side, a software repair update notification is sent to the client in real time when a software update is detected, replacing the inefficient client polling check, and ensuring the timeliness of the software patch package distribution; after the client receives the software repair update notification, the software patch package download process is immediately triggered to obtain the software patch package, and a complete repair file is generated based on the software patch package; at the same time, an intelligent restart monitoring service is introduced to automatically select the appropriate time to complete the application restart without manual operation by the user; and the repair file is seamlessly loaded during the application restart process to realize the automatic completion of hot repair. Through the dual optimization of "active push + intelligent restart", the efficiency of hot repair is significantly improved while ensuring stability. This efficient and reliable hot repair method not only meets the needs of rapid iteration of Android applications, but also ensures system security and significantly improves the user experience.

[0069] Figure 1 Schematic diagram of the application scenario of the hot repair method for Android applications provided by the exemplary embodiment of this application. Figure 1As shown, the application scenario includes a client 11 and a server 12, wherein the number of the client 11 can be at least one. In actual application, upon receiving a software repair and update notification for an Android application, the client 11 executes the hot repair method for the Android application provided in this application to complete the hot repair of the Android application.

[0070] It should be noted that the server 12 can also be replaced by a server cluster or other computing devices with a certain computing power. The client 11 can be a smart phone, tablet computer, smart wearable device or other smart terminal device supporting Android operating system.

[0071] The following combination Figure 1 For application scenarios, refer to Figure 2 To describe the hot repair method for Android applications according to the exemplary embodiment of this application. It should be noted that the above application scenarios are only shown to facilitate understanding of the spirit and principles of this application, and the implementation of this application is not affected by Figure 1 The application scenarios shown are limited. It should be noted that the following specific embodiments can be combined with each other, and the same or similar concepts or processes may not be repeated in some embodiments. The embodiments of the present application will be described below in conjunction with the accompanying drawings.

[0072] Figure 2 A flow chart of a hot repair method for Android applications provided by an exemplary embodiment of this application. The hot repair method for Android applications provided by an embodiment of this application is applied to the client. Figure 2 As shown, the hot repair method for Android applications includes the following steps:

[0073] S201 : In response to receiving a software repair and update notification for an Android application, request a server to download a software patch package for the Android application.

[0074] For example, a developer has released a baseline version of an Android application, such as base.apk. If it is later discovered that the released application has bugs that need to be urgently fixed, such as crashes, security vulnerabilities, or emergency functions, it is necessary to modify the project source code, output a software patch package, and upload the software patch package to the server; accordingly, the server stores the received software patch package and pushes the update message of the Android application software to the client that has installed the Android application; correspondingly, the client responds to receiving the software repair and update notification for the Android application, automatically triggers the update check process, constructs a request containing parameters such as the current application version number and device identifier (ID), and initiates a request to the server to download the software patch package of the Android application.

[0075] S202: In response to receiving the download address of the software patch package returned by the server, download the software patch package from the download address.

[0076] For example, after receiving the client request, the server parses the client version information and matches the corresponding patch package; if there is an available software patch package, the server returns the unique download address of the software patch package, such as a Content Delivery Network (CDN) address or a Hypertext Transfer Protocol Secure (HTTPS) link; correspondingly, the client downloads the software patch package from the specified Uniform Resource Locator (URL) based on the returned address through multi-threaded download technology, such as the OkHttp library.

[0077] S203: Generate a complete repair file based on the software patch package.

[0078] Accordingly, considering that the software patch package downloaded from the server is an incremental file after the Android application is repaired, it is not a complete loadable file, so it needs to be restored into a complete file. For each patch version repair, a full installation package file will be generated in the external directory of the terminal, such as a mobile phone. Then, when the Android application is started, it will be guided to load the relevant files in the external directory, thereby completing the hot repair of the application.

[0079] For example, after the client completes the download, it calls a local differential merge tool, such as a file synthesis algorithm, to merge the patch package with the locally installed base.apk at the file level; during the merging process, the incremental data in the patch package, such as .dex, .so, resource files, etc., are dynamically applied to the original APK to generate a complete repair file without reinstalling the APK.

[0080] Optionally, before generating a complete repair file based on the software patch package, the software patch package is also verified. Specifically, the developer uses a private key to generate a digital signature (such as RSA-SHA256) for the software patch package. After the client downloads the software patch package and the signature file, it decrypts the signature using a preset public key and recalculates the hash value of the software patch package. If the two are consistent, it is determined that the software patch package has not been tampered with and the source is trustworthy.

[0081] S204: Start a restart monitoring service for the Android application to wait for an application restart opportunity, and restart the Android application when it is detected that the Android application meets the application restart opportunity.

[0082] For example, the client starts a background listening service to monitor the status of the Android application in real time; when it is detected that the status of the Android application meets the set conditions, it is determined that the Android application meets the application restart time and the Android application is restarted immediately, for example, by terminating the current process through Process.killProcess(Process.myPid()) to avoid interface freeze or data loss caused by forced termination, and automatically starts a new process according to android:persistent="true" (optional) or the Intent.FLAG_ACTIVITY_NEW_TASK flag defined in AndroidManifest.xml.

[0083] S205: After the Android application is restarted, the repair file is loaded to complete the hot repair of the Android application.

[0084] Accordingly, after the Android application is restarted, the repair file is loaded to replace the old bug file and resources, so that the repair takes effect, thereby completing the hot repair of the application.

[0085] The hot repair method for Android applications provided in the embodiment of the present application adopts a mechanism in which the server actively pushes software repair and update notifications of Android applications, replacing the traditional client polling method, thereby realizing real-time and accurate distribution of software patch packages; at the same time, an intelligent restart monitoring service is introduced to automatically select the appropriate time to complete the application restart, which not only solves the response delay and human dependence problems existing in traditional hot repair technologies, but also greatly improves the hot repair efficiency while ensuring application stability by optimizing the patch distribution and effectiveness mechanism. This efficient and reliable hot repair method not only meets the needs of rapid iteration of Android applications, but also ensures system security and significantly improves the user experience.

[0086] In some embodiments, the software patch package includes a marker file for identifying whether each file in the version file of the Android application has changed. Based on the software patch package, a complete repair file is generated, including: traversing each file in the previous version file of the Android application, and based on the marker file, dividing each file in the previous version file into changed files and unchanged files, where the changed files include newly added files; for the changed files, based on a synthesis algorithm, a synthetic file is generated according to the software patch package and the changed files; the synthetic file is saved to the DEX file directory of the current version, and the unchanged files are copied to the file directory of the current version to obtain a complete repair file.

[0087] For example, first parse the marker file in the software patch package, such as patchInfo.txt, and classify the old version files into changed files and unchanged files based on the file change identifiers of whether each file in the version file of the Android application recorded in patchInfo.txt has changed; for changed files (including new files), the software patch package and the old version files are recombined through a synthesis algorithm, such as a binary differential synthesis algorithm, to generate a new synthesized file; for unchanged files, they are directly copied from the old version directory; all processed files are organized and stored according to the version number in a new repair directory, such as / data / data / pkgname / files / patch_v2 / , to obtain a complete repair file, and the old version directory is simultaneously cleaned up to release storage space.

[0088] The embodiment of the present application accurately identifies the changed content by marking files and only performs synthesis operations on the changed files, which effectively reduces the time consumption of patch processing and greatly improves the efficiency of hot repair. At the same time, it adopts a strategy that combines incremental updates with full reorganization to significantly reduce the size of the patch package while ensuring the integrity of the repair, thereby greatly saving user traffic consumption. In addition, through versioned directory management, the intelligent replacement and cleaning of old and new files are realized, which not only ensures the atomicity of the repair process but also reduces the redundant occupation of storage space.

[0089] In some embodiments, when it is monitored that the Android application meets the application restart timing, the Android application is restarted, including: when it is monitored that the Android application is in a background suspended state and no key operations are performed, the context information of the current page of the Android application is saved locally, and the Android application is restarted; correspondingly, a repair file is loaded to complete the hot repair of the Android application, including: loading the repair file and restoring the page state of the Android application according to the context information saved locally to complete the hot repair of the Android application.

[0090] For example, Figure 3 A flowchart of restart monitoring provided by an exemplary embodiment of the present application. Figure 3 As shown, restarting the monitor specifically includes the following steps:

[0091] S301. Start the restart monitoring service.

[0092] S302: Determine whether the Android application is in a background suspended state.

[0093] If yes, execute S303;

[0094] If not, execute S302.

[0095] S303: Determine whether the Android application is performing a key operation.

[0096] Key operations include but are not limited to music playing or file downloading.

[0097] If yes, execute S302;

[0098] If not, execute S304.

[0099] S304: Save the context information of the current page of the Android application to the local computer, and restart the Android application.

[0100] For example, context information such as the current Activity stack, page scroll position, or form data is serialized and stored locally.

[0101] S305 : Load the repair file and restore the page state of the Android application according to the context information saved locally to complete the hot repair of the Android application.

[0102] For example, the repair file is loaded first to complete the hot repair, and the page state before the restart is accurately restored based on the saved context data.

[0103] Optionally, when the restart monitoring service does not detect a suitable restart opportunity within a preset time, such as 30 minutes, a gradual intervention process will be initiated. Specifically, you can try to perform a smooth restart when the application switches to the background (retaining a 1-second transition animation); if it still cannot be completed, trigger a user-friendly prompt mechanism, such as a system notification prompting "The application requires important updates, it is recommended to complete it in time." The notification has the following features: 1) Intelligently identify and avoid full-screen usage scenarios such as calls and navigation; 2) Provide a delay option of "process later"; 3) Automatically adapt to the system theme style. Accordingly, when the user selects "Update now", the system will automatically save the current working status (including unsubmitted form data, etc.) and execute the safe restart process after, for example, a 3-second countdown prompt.

[0104] The embodiment of the present application ensures the optimization of the restart timing by accurately identifying the background suspension state and avoiding the critical operation period, so as to minimize the impact of the hot repair process on user use; secondly, it adopts a complete context information preservation solution, which can effectively restore the page status, data content and interaction progress before the application is restarted, realizes the seamless connection between hot repair and state recovery, and effectively improves the reliability of hot repair.

[0105] In some embodiments, loading the repair file includes: determining whether there is a new software patch package on the server; if there is no new software patch package on the server, checking whether there is a complete repair file locally; if there is a complete repair file locally, loading the repair file.

[0106] For example, the version information and application information of the locally stored software patch package are obtained, the request parameters are encapsulated, and a request is made to the server to download the software patch package of the Android application; after the server receives the client request, it parses the client version information and matches the corresponding patch package; if there is a new software patch package on the server, the unique download address of the software patch package is returned; if there is no new software patch package on the server, a prompt message or status code indicating that there is no new software patch package is returned; correspondingly, after the client determines that there is no new software patch package on the server based on the prompt message or status code, it verifies whether there is a complete repair file locally, such as calculating the SHA-256 checksum of the file, and comparing it with the pre-stored hash value (such as recorded in metadata.json), so as to determine whether the locally stored repair file is complete; if the verification determines that a complete repair file exists locally, the repair file is loaded.

[0107] In some embodiments, the hot repair method for Android applications further includes: if a new software patch package exists on the server, downloading the software patch package from a download address is executed; if a complete patch file does not exist locally, terminating the current hot repair process.

[0108] Correspondingly, if there is a new software patch package on the server, that is, if the download address of the new software patch package is received from the server, execute Figure 2 Follow the steps to download the software patch package from the download address.

[0109] Accordingly, if the complete patch file does not exist locally, the hotfix process is terminated to avoid loading a damaged file and causing the Android application to crash.

[0110] In the embodiment of the present application, before loading the repair file, the server is again confirmed to see whether there is a new software patch package. When the new software patch package is detected on the server, the software patch package download process is immediately triggered to ensure that the latest repair file is always loaded in the end, effectively solving the problem of incomplete repair caused by version lag in traditional solutions. In addition, by implementing strict integrity checks on the loaded repair files, the risk of file damage or tampering is effectively reduced. This dual protection mechanism not only ensures the timeliness of hot repair, but also greatly improves the security and reliability of the repair process.

[0111] Considering that in related technologies, a differential comparison method based on a baseline package is usually adopted to generate a software patch package, but as the number of version iterations increases, a difference comparison is performed with the baseline package each time, resulting in the accumulated modified content continuing to expand the size of the software patch package; this linear growth of patch files will not only significantly increase the download time, especially in a weak network environment, but also occupy too many resources in the storage space of the terminal device. Long-term accumulation may cause storage pressure on mobile devices such as mobile phones, thereby affecting the overall system performance; especially in the scenario of frequent hot repairs, this design defect will lead to the dual problems of a surge in network traffic consumption and a decrease in storage space utilization, seriously affecting the user experience and device operation efficiency. Therefore, in some embodiments, the downloaded software patch package is generated based on the file difference between the version file of the current repair version and the version file of the previous repair version.

[0112] For example, when generating a software patch package, the patch package is generated by comparing the differences between two adjacent repair versions of APK, and marking whether each file in the APK has changed, and saving it to patchInfo.txt. Since only the file differences between two adjacent repair versions are retained, the problem of the increasing size of the software patch package is effectively improved. This is of positive significance for reducing the download time of the software patch package and the space occupied by the software patch package in the memory of the terminal device.

[0113] In summary, this application has at least the following advantages:

[0114] 1. By adopting a mechanism in which the server actively pushes software repair and update notifications for Android applications, replacing the traditional client-side polling method, the real-time and accurate distribution of software patch packages is achieved. At the same time, an intelligent restart monitoring service is introduced to automatically select the appropriate time to complete application restart. This not only solves the response delay and human dependency problems of traditional hot fix technology, but also greatly improves hot fix efficiency while ensuring application stability by optimizing patch distribution and validation mechanisms. This efficient and reliable hot fix method not only meets the needs of rapid iteration of Android applications, but also ensures system security and significantly improves the user experience.

[0115] Second, by marking files to accurately identify changes, only performing synthesis operations on changed files effectively reduces patch processing time and greatly improves hot repair efficiency. At the same time, a strategy combining incremental updates with full reorganization ensures repair integrity while significantly reducing the size of the patch package, greatly saving user traffic consumption. In addition, through versioned directory management, intelligent replacement and cleanup of old and new files are achieved, which not only ensures the atomicity of the repair process but also reduces redundant storage space.

[0116] Third, by confirming with the server again whether there is a new software patch package before loading the repair file, when a new software patch package is detected on the server, the software patch package download process is immediately triggered to ensure that the latest repair file is always loaded in the end, effectively solving the problem of incomplete repair caused by version lag in traditional solutions; in addition, by implementing strict integrity checks on the loaded repair files, the risk of file damage or tampering is effectively reduced. This dual protection mechanism not only ensures the timeliness of hot repairs, but also greatly improves the security and reliability of the repair process.

[0117] 4. Since the downloaded software patch package is generated based on the file difference between the version file of the current repair version and the version file of the previous repair version, the problem of the increasing size of the software patch package is effectively improved. This is of positive significance for reducing the download time of the software patch package and the space occupied by the software patch package in the terminal device memory.

[0118] For example, Figure 4 A schematic diagram of a hot repair system for Android applications provided by an exemplary embodiment of this application. Figure 4 As shown, the hot repair system 40 for Android applications includes a client 41 and a server 42, wherein:

[0119] The client 41 is configured to execute the method described in any one of the above embodiments;

[0120] The server 42 is used to manage the patch packages uploaded by the developer, push software repair and update notifications for Android applications to the client, and respond to requests from the client to download software patch packages for Android applications.

[0121] For example, Figure 5 A schematic diagram of the structure of the server provided by the exemplary embodiment of this application. Figure 5 As shown, the server 42 includes a publishing and updating unit 421, which includes a version checker 4211, a patch package manager 4212, a message pusher 4213 and a file transmitter 4214, wherein:

[0122] The release and update unit 421 is mainly used to manage the version of the software patch package and push the software update message to the client on which the Android application is installed; the version checker 4211 is mainly used to match the corresponding version of the software patch package according to the client's request; the patch package manager 4212 is mainly used to add, delete, modify and check the software patch package to facilitate the management of the software patch package; the message pusher 4213 is mainly used to push the update message to the client in real time based on the communication protocol of the publish-subscribe model; the file transmitter 4214 is mainly used for the network transmission of the software patch package to complete the upload and download of files.

[0123] For example, Figure 6 A schematic diagram of a workflow of a publishing and updating unit provided by an exemplary embodiment of the present application. Figure 6 As shown, the workflow for publishing update units is as follows:

[0124] S601: In response to a request for downloading a software patch package sent by a client, obtain request parameter information.

[0125] The request parameter information includes the application ID appid, the application version number appVersion, and the client's current patch version number patchVersion.

[0126] S602: Match and query the corresponding software patch package management directory according to the request parameter information.

[0127] For example, based on appid and appVersion, locate the corresponding application version patch package management directory stored on the server (such as path: / patches / {appid} / {appVersion} / ).

[0128] S603: Determine whether there is a new software patch package.

[0129] For example, the latest patch version number of the server (such as reading latest_patch_version.txt from a directory) is compared with the client patchVersion to determine whether a new software patch package exists.

[0130] If yes, execute S604;

[0131] If not, execute S605.

[0132] S604: Send the download address of the software patch package to the client.

[0133] Correspondingly, the client downloads the file stream according to the download address.

[0134] S605: Determine whether to roll back the software patch package.

[0135] For example, if the server marks the current software patch package as risky (e.g., recorded in the configuration file rollback_list.json), it queries the version number of the previous stable software patch package for the application version and returns the download address of the old software patch package (e.g., patch_v{rollback_version}.zip).

[0136] If yes, execute S604;

[0137] If not, execute S606.

[0138] S606: Send an error code to the client.

[0139] For example, if there is no new software patch package and no rollback is required, an error code such as "HTTP 404NotFound" or a custom error code "PATCH_NOT_AVAILABLE" is returned, along with an error description such as "Currently no patch is available".

[0140] For example, Figure 7 Another workflow diagram of the publishing and updating unit provided by the exemplary embodiment of the present application. Figure 7 As shown, the workflow for publishing update units is as follows:

[0141] S701. Obtain the software patch package uploaded by the development end.

[0142] S702: Based on the relevant information of the software patch package, store the software patch package in a corresponding file management directory.

[0143] The software patch package information includes appid, appVersion, and the version number of the software patch package.

[0144] S703: Push software repair and update notification to the client.

[0145] Correspondingly, the client receives the software repair and update notification for the Android application and requests the server to download the software patch package of the Android application.

[0146] For example, Figure 8 A schematic diagram of the structure of the client provided by the exemplary embodiment of this application. Figure 8 As shown, the client 41 includes a check and update unit 411, which includes a request updater 4111, a patch downloader 4112, a patch verifier 4113, a patch synthesizer 4114, and a restart listener 4115. The check and update unit 411 is used to check and update the software patch package; the request updater 4111 is used to obtain local application device information and software patch package version information, construct request parameter information, and initiate a request to download the software patch package of the Android application based on the request parameter information; the patch downloader 4112 is used to download the software patch package from the download address returned by the server; the patch verifier 4113 is used to verify the signature of the software patch package to prevent the file from being maliciously tampered with; the patch synthesizer 4114 is used to generate a complete repair file based on the software patch package; and the restart listener 4115 is used to start the restart monitoring service for the Android application to wait for the application restart opportunity, and restart the Android application when it is detected that the Android application meets the application restart opportunity.

[0147] Figure 9 Another structural diagram of the hot repair system for Android applications provided by the exemplary embodiment of this application. Figure 9 As shown, the hot repair system 40 for Android applications also includes a development end 43, which is used to generate a software patch package corresponding to the current repair version based on the file difference between the version file of the current repair version of the Android application and the version file of the previous repair version. The software patch package contains a marker file that identifies whether the file has changed.

[0148] For example, Figure 10 A schematic diagram of the structure of the development end provided by the exemplary embodiment of this application. Figure 10 As shown, the development end 43 includes a patch construction unit 431, which includes a manifest file modifier 4311, a resource identifier encoder 4312, a code obfuscation configurator 4313 and a patch generator 4314, wherein:

[0149] The patch building unit 431 is a functional module mainly used in the Android application packaging and building process. It outputs a software patch package by executing a custom plug-in task during the building process.

[0150] Manifest file modifier 4311 is mainly used to complete two tasks. The first task is to replace the original Application class. The main reason is that patches are loaded in the Application class. Therefore, by customizing an Application class and proxying the original class, the loading of the software patch package is controlled; the second task is to embed the component proxy class in the manifest file in advance for the case of adding four new components, and operate the new components through static proxy. Among them, the manifest file is the startup entry file of the Android application and can only exist in the original APK. Therefore, it needs to be modified when building the baseline APK.

[0151] The resource identifier encoder 4312 is mainly used to ensure that the resource ID generated by the same resource remains unchanged each time it is packaged, to prevent the change of the resource ID from affecting the loading of application resources.

[0152] Code Obfuscation Configurator 4313 is mainly used to modify the obfuscation rules during packaging and automatically add classes that do not need to be obfuscated to the proguard.pro file.

[0153] The patch generator 4314 is mainly used to calculate the differential file and generate the software patch package based on the difference between the APK files before and after the repair.

[0154] For example, Figure 11 A schematic diagram of a work flow of a patch construction unit provided by an exemplary embodiment of the present application. Figure 11As shown, the workflow of the patch building unit is as follows:

[0155] S1101. Obtain the resource mapping file, MultiDex file, and obfuscation file of the baseline APK as an input baseline for building the software patch package.

[0156] S1102. Modify the manifest file and pre-embed components.

[0157] For example, replace the system Application class with a custom proxy class to control the patch loading entry; if the patch involves adding four new components (Activity / Service, etc.), embed the static proxy class of the component in AndroidManifest.xml.

[0158] S1103: Fix the original resource ID and encode the newly added resource.

[0159] For example, the ID encoding rules of existing resources in the base APK are locked to ensure that the resource IDs of the patch and base package are consistent; unique IDs are assigned to newly added resources to avoid conflicts with existing resources.

[0160] S1104: Determine whether to enable code obfuscation.

[0161] If yes, execute S1105;

[0162] If not, execute S1106.

[0163] S1105. Add configuration according to the obfuscation rules.

[0164] For example, dynamically modify the proguard.pro file to automatically add classes that do not need to be obfuscated, such as patch loaders and proxy classes.

[0165] S1106: Mark file changes and generate build information.

[0166] For example, the file differences of the APK before and after the repair are compared, and a change marker file (such as patchInfo.txt) is generated to record the list of newly added / modified / deleted files for subsequent difference calculation.

[0167] S1107: Generate and sign a repaired APK.

[0168] For example, the APK building task is completed, a repaired APK file (such as fix.apk) is generated, and the server private key is used to digitally sign it to ensure the integrity and source of the patch package.

[0169] S1108. Calculate the differential file and output the software patch package.

[0170] For example, a differential algorithm is used to generate a software patch package based on the file differences between the current repaired version of APK and the last repaired version of APK.

[0171] Considering related technologies, hotfixes can also be implemented through underlying replacement techniques. Specifically, hotfixes are implemented by dynamically replacing Java code at the Android Native layer. This solution can fix bugs in real time, but does not support replacing resource files and SO files, resulting in poor compatibility. Some hotfix solutions only support modifying class files, but do not support adding four new components to an application, which has certain limitations. Alternatively, some hotfix solutions, such as the Amigo framework, generate and load a full APK file to perform hotfixes. In addition to supporting repairs to class files, SO files, and resource files, it also supports adding new components to an application, achieving a near-complete fix. The software patch implementation solution supports both a later restart and an immediate restart. However, this solution requires the use of a full APK file, resulting in a larger patch package size, which is not conducive to downloading. Furthermore, for the patch implementation solution, if an immediate restart is selected, the application will crash and restart, resulting in a poor user experience and also presenting security issues.

[0172] Therefore, based on the above embodiments, in some embodiments, the client further includes a patch loading unit. For example, Figure 12 Another structural diagram of the client provided by the exemplary embodiment of this application. Figure 12 As shown, the client 41 also includes a patch loading unit 412, which includes a Dex file loader 4121, a resource file loader 4122, and an SO file loader 4123. Among them, the patch loading unit 412 is used to load the complete repair file; the Dex file loader 4121 is used to load the Dex file, which mainly includes two situations, one is the repaired Bug class, and the other is the newly added Android component. A Dex file generally contains multiple class files. Among them, for the repaired Bug class, its core principle is to modify the class loading order of the Dex file, and its hot repair process can be simplified as follows Figure 13 Specifically, refer to Figure 13On the development side, a file difference algorithm is used to generate a software patch package and upload it to the server to publish the update unit. The client downloads the patch file from the server and uses a file merging algorithm to generate a complete repair file. When the APP application is started, all Dex files in the installation directory are added to the element-splitting array of the PathList object, such as the elements array, to store the loading information of the Dex files. For the class loading mechanism of Android applications, the same class file will only be loaded once, so the repaired Dex file is placed at the head of the elements array, and only the repaired class files in the patch package are loaded. For example, the workflow of the Dex file loader includes: 1) instantiating the class loader DexClassLoader to load the dex files in the patch package; 2) obtaining the dex elements array loaded by the external patch package through reflection; 3) obtaining the dex elements array loaded by the system through reflection; 4) merging the patch package and the system's elements array and placing the patch package array at the head of the array; 5) assigning the elements array to the system's pathList through reflection.

[0173] Accordingly, the core principle of the loading mechanism for new Android components is to manipulate the newly added components with the help of pre-installed proxy classes. For example, taking the Activity component as an example, a static proxy mode is adopted in the host APK, using ProxyActivity to proxy the newly added Activity component. In specific implementation, ProxyActivity is used to statically proxy the newly added Activity component and override the Activity's lifecycle-related methods, such as onCreate(), onStart(), and onResume(). It also overrides methods such as acquiring resources, setting themes, and handling key events. At this point, ProxyActivity essentially acts as an "empty shell," its main function being to obtain the newly added Activity instance within the software patch package through reflection in its own onCreate() method. Subsequently, within the ProxyActivity proxy class, the lifecycle methods of the original Activity component are called to give the newly added Activity component a complete lifecycle effect. In short, ProxyActivity is primarily responsible for providing the necessary Context environment, while the newly added Activity component uses this proxy class to execute its own business logic and functions. For Android's other three core components, Service, BroadcastReceiver, and ContentProvider, their implementation principles are similar to those of the Activity component. They all use a static proxy mechanism to complete the loading and life cycle management of new components through preset proxy classes.

[0174] The principles of resource file loader 4122 and SO file loader 4123 are similar to those of Dex file loader 4121, and are also mainly implemented through reflection. Among them, resource files are usually saved in the res and assets directories of the project, and the system loads resources through an instance of the Resources class. In order to load external resource files, the resource files in the local installation directory are mainly replaced through the reflection mechanism. For example, the workflow of the resource file loader includes: 1) Reflection obtains the LoaderApk container held by the ActivityThread object; 2) Traverses the LoaderApk object and reflectively replaces the mResDir attribute with the storage path of the patch package; 3) Instantiates a new AssetManager object; 4) Reflectively calls the addAssetPath method to load the patch resource file into the new AssetManager object; 5) Reflection obtains the Resources container object held by ResourcesManager; 6) Traverses the Resources container object and replaces the object attribute with the new AssetManager.

[0175] Accordingly, since SO files are compiled dynamic link libraries containing precompiled code and data, they are typically stored in the libs directory for dynamic loading and use by applications at runtime. There are two ways to load SO files: calling the System.loadLibrary method and the System.load method. The former can only load SO files in the libs folder under the application's installation directory, while the latter can load SO files from a specified directory. Both methods require first obtaining an array of SO file paths and then calling the native method nativeLoad to complete the loading. Therefore, this array can be obtained through reflection, and the SO files in the software patch package can then be inserted into the array header. To account for compatibility issues across different Android versions, versions prior to Android 23 require the nativeLibraryDirectories array, while later versions require the nativeLibraryPathElements array. When loading an SO file, the system traverses this array. Once the corresponding SO file is found, subsequent files are no longer loaded. For example, the workflow of the SO file loader 4123 includes: 1) obtaining the device Android API version number; 2) determining whether the version number is a version before Android 23; 3) if the version number is a version before Android 23, then obtaining the array nativeLibraryPathElements[] by reflection; 4) if the version number is a version after Android 23, then obtaining the array nativeLibraryDirectories[] by reflection; 5) inserting the so file in the software patch package into the array header.

[0176] The embodiment of the present application, by utilizing the reflection mechanism and combining the loading principles of different types of files in the Android system, realizes the loading of Dex files, resource files and SO files, and can accurately realize the dynamic loading of various types of files, providing solid technical support for software hot repair and function expansion; in terms of component management, by pre-embedding the proxy class declarations of the four major Android components in the application manifest file, when a new component is needed, the static proxy mode is used, and these pre-embedded proxy classes are used to proxy the actual new components. This method not only supports the flexible addition of new components in the software patch package, but also greatly optimizes the design of the patch package. Specifically, it fully considers the balance between the size and functional scope of the software patch package. On the one hand, through refined resource management and code optimization, the size of the patch package is ensured to be as small as possible, thereby reducing the cost of user download and installation; on the other hand, with the help of the above-mentioned loading mechanism and component proxy strategy, comprehensive functional repair and expansion are achieved, ensuring the completeness of the patch package at the functional level. Thereby improving the efficiency of hot repair, while effectively improving the problems of excessive patch package size and inflexible function updates in the existing technical solutions, and providing users with a smoother and more efficient application experience.

[0177] For example, Figure 14 This is an architectural diagram of a hot repair system for Android applications provided by an exemplary embodiment of this application. Figure 14 As shown in the figure, the hot fix system for Android applications mainly consists of four parts: a patch building unit, a release and update unit, a check and update unit, and a patch loading unit. The patch building unit is deployed on the development side, the release and update unit is deployed on the server side, and the check and update unit and patch loading unit are deployed on the client side. The check and update unit and the patch loading unit can be summarized as the client hot fix SDK. The patch building unit is implemented based on an Android code building tool and is mainly used to build Android projects on the development side. It contains a manifest file modifier, a resource identifier encoder, a code obfuscation configurator, and a patch generator. It uploads the generated software patch package to the server release and update unit. The release and update unit is mainly used to manage patch packages, perform version verification on client requests, upload and download patch package files, and push patch package update messages in real time. The Android client hot fix SDK mainly includes the check and update unit and the patch loading unit. The check and update unit is mainly used for patch package download and installation, including requesting updates, downloading patch packages, patch package security verification, patch package synthesis, and checking the restart status. After the application restarts, the patch loading unit is mainly used to load the synthesized patch file and complete the loading of bug class files, resource files, SO library files, and the four new components.

[0178] The following are device embodiments of the present application, which can be used to implement the method embodiments of the present application. For details not disclosed in the device embodiments of the present application, please refer to the method embodiments of the present application.

[0179] Figure 15 A schematic diagram of a structure of a hot repair device for Android applications provided by an exemplary embodiment of the present application. The hot repair device for Android applications provided by an embodiment of the present application is applied to a client. Figure 15 As shown, the hot repair device 150 for Android applications includes an update request module 151, a patch download module 152, a patch synthesis module 153 and a restart monitoring module 154, wherein:

[0180] The update request module 151 is configured to request the server to download the software patch package of the Android application in response to receiving a software repair and update notification for the Android application;

[0181] The patch download module 152 is configured to download the software patch package from the download address in response to receiving the download address of the software patch package returned by the server;

[0182] The patch synthesis module 153 is used to generate a complete repair file based on the software patch package;

[0183] The restart monitoring module 154 is used to start the restart monitoring service for the Android application and wait for the application restart time, and restart the Android application when it is detected that the Android application meets the application restart time; and after the Android application is restarted, load the repair file to complete the hot repair of the Android application.

[0184] In one possible implementation, the software patch package includes a marker file for identifying whether each file in the version file of the Android application has changed. The patch synthesis module 153 can be specifically used to: traverse each file in the previous version file of the Android application, and based on the marker file, divide each file in the previous version file into changed files and unchanged files, where the changed files include newly added files; for the changed files, based on the synthesis algorithm, generate a synthesized file based on the software patch package and the changed files; save the synthesized file to the DEX file directory of the current version, and copy the unchanged files to the file directory of the current version to obtain a complete repair file.

[0185] In one possible implementation, the restart monitoring module 154 can be specifically used to: when it is detected that the Android application is in a background suspended state and no key operations are performed, save the context information of the current page of the Android application locally and restart the Android application; correspondingly, the restart monitoring module 154 can also be used to: load the repair file, and restore the page status of the Android application based on the context information saved locally to complete the hot repair of the Android application.

[0186] In one possible implementation, the restart monitoring module 154 can also be used to: determine whether there is a new software patch package on the server; if there is no new software patch package on the server, check whether there is a complete repair file locally; if there is a complete repair file locally, load the repair file.

[0187] In a possible implementation, the restart monitoring module 154 may also be used to: when a new software patch package exists on the server, execute the step of downloading the software patch package from the download address; when a complete patch file does not exist locally, end the current hot fix process.

[0188] In a possible implementation, the downloaded software patch package is generated based on the file difference between the version file of the current repair version and the version file of the previous repair version.

[0189] The hot repair device for Android applications provided in the embodiment of the present application can execute the technical solution shown in the above-mentioned embodiment of the hot repair method for Android applications. Its implementation principle and beneficial effects are similar and will not be repeated here.

[0190] It should be noted that for the aforementioned method embodiments, for the sake of simplicity, they are all expressed as a series of action combinations, but those skilled in the art should be aware that this application is not limited by the order of the actions described, because according to this application, certain steps can be performed in other orders or simultaneously. Secondly, those skilled in the art should also be aware that the embodiments described in this specification are all optional embodiments, and the actions and modules involved are not necessarily required by this application.

[0191] It should be further noted that, although the various steps in the flowchart are shown in sequence as indicated by the arrows, these steps are not necessarily performed in the order indicated by the arrows. Unless otherwise specified herein, there is no strict order restriction on the execution of these steps, and these steps may be performed in other orders. Moreover, at least a portion of the steps in the flowchart may include multiple sub-steps or multiple stages, and these sub-steps or stages are not necessarily performed at the same time, but may be performed at different times. The execution order of these sub-steps or stages is not necessarily to be performed in sequence, but may be performed in turn or alternately with other steps or at least a portion of the sub-steps or stages of other steps.

[0192] It should be noted that the above-described device embodiments are merely illustrative, and the device of the present application may also be implemented in other ways. Furthermore, it should be understood that the division of the various modules of the above-described device is merely a division of logical functions. In actual implementation, they may be fully or partially integrated into a single physical entity, or physically separated. Furthermore, these modules may all be implemented in the form of software called by a processing element; or all in the form of hardware; or some modules may be implemented in the form of software called by a processing element, and some modules may be implemented in the form of hardware. For example, the restart monitoring module may be a separate processing element, or it may be integrated into a chip of the above-described device. Furthermore, it may be stored in the form of program code in the memory of the above-described device, and called by a processing element of the above-described device to perform the functions of the restart monitoring module. The implementation of other modules is similar. Furthermore, these modules may all or partly be integrated together, or implemented independently. The processing element here may be an integrated circuit with signal processing capabilities. During implementation, each step of the above-described method or each of the above modules may be performed by hardware integrated logic circuits in the processor element or by software instructions.

[0193] For example, the above modules can be one or more integrated circuits configured to implement the above methods, such as one or more application-specific integrated circuits (ASICs), one or more microprocessors (DSPs), or one or more field programmable gate arrays (FPGAs). For another example, when a module is implemented by scheduling program code through a processing element, the processing element can be a general-purpose processor, such as a central processing unit (CPU) or other processor that can call program code. For another example, these modules can be integrated together and implemented in the form of a system-on-a-chip (SOC).

[0194] In the above embodiments, it can be implemented in whole or in part by software, hardware, firmware or any combination thereof. When software is used for implementation, it can be implemented in whole or in part in the form of a computer program product. The computer program product includes one or more computer instructions. When the computer instructions are loaded and executed on a computer, the process or function according to the embodiment of the present application is generated in whole or in part. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable devices. The computer instructions can be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another computer-readable storage medium. For example, the computer instructions can be transmitted from a website, computer, server or data center to another website, computer, server or data center by wired (such as coaxial cable, optical fiber, digital subscriber line (DSL)) or wireless (such as infrared, wireless, microwave, etc.) mode. The computer-readable storage medium can be any available medium that a computer can access or a data storage device such as a server or data center that includes one or more available media integrations. Available media may be magnetic media (eg, floppy disks, hard disks, magnetic tapes), optical media (eg, Digital Video Discs (DVDs)), or semiconductor media (eg, solid state disks (SSDs)).

[0195] Figure 16 This is a schematic diagram of the structure of an electronic device provided by an exemplary embodiment of the present application. Figure 16 As shown, the electronic device 160 of this embodiment includes:

[0196] At least one processor 161; and a memory 162 communicatively connected to the at least one processor;

[0197] The memory 162 stores instructions that can be executed by the at least one processor 161 , and the instructions are executed by the at least one processor 161 to enable the electronic device to execute the method as described in any of the above embodiments.

[0198] Optionally, the memory 162 may be independent or integrated with the processor 161 .

[0199] The memory 162 may include a high-speed random access memory (RAM), and may also include a non-volatile memory (non-volatile memory), such as at least one disk memory.

[0200] The processor 161 may be a central processing unit (CPU), an application-specific integrated circuit (ASIC), or one or more integrated circuits configured to implement the embodiments of the present application. Specifically, when implementing the hot repair method for Android applications described in the aforementioned method embodiment, the electronic device may be, for example, an electronic device with processing capabilities, such as a server.

[0201] Optionally, the electronic device may further include a communication interface 163. In a specific implementation, if the communication interface 163, the memory 162, and the processor 161 are implemented independently, the communication interface 163, the memory 162, and the processor 161 may be interconnected via a bus and communicate with each other. The bus may be an Industry Standard Architecture (ISA) bus, a Peripheral Component Interconnect (PCI) bus, or an Extended Industry Standard Architecture (EISA) bus. Buses can be divided into address buses, data buses, control buses, etc., but this does not mean that there is only one bus or only one type of bus.

[0202] Optionally, in a specific implementation, if the communication interface 163, the memory 162 and the processor 161 are integrated on a chip, the communication interface 163, the memory 162 and the processor 161 can complete communication through an internal interface.

[0203] The implementation principle and technical effects of the electronic device provided in this embodiment can be found in the aforementioned embodiments and will not be described in detail here.

[0204] An embodiment of the present application also provides a computer-readable storage medium, which stores computer execution instructions. When the computer execution instructions are executed, they are used to implement the method steps in the above method embodiment. The specific implementation method and technical effects are similar and will not be repeated here.

[0205] The computer-readable storage medium may 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 computer-readable storage medium may be any available medium that can be accessed by a general-purpose or special-purpose computer.

[0206] An exemplary readable storage medium is coupled to the processor, enabling the processor to read information from and write information to the readable storage medium. Alternatively, the readable storage medium may be an integral part of the processor. The processor and the readable storage medium may be located in an application-specific integrated circuit. Alternatively, the processor and the readable storage medium may be discrete components within a hotfix device for Android applications.

[0207] An embodiment of the present application also provides a computer program product, including a computer program. When the computer program is executed, the method steps in the above method embodiment are implemented. The specific implementation method and technical effects are similar and will not be repeated here.

[0208] In the above embodiments, the description of each embodiment has its own emphasis. For parts not described in detail in a particular embodiment, please refer to the relevant description of other embodiments. The technical features of the above embodiments can be combined in any way. To keep the description concise, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this specification.

[0209] Those skilled in the art will readily appreciate other embodiments of the present application after considering the specification and practicing the invention disclosed herein. This application is intended to cover any variations, uses, or adaptations of the present application that follow the general principles of the present application and include common knowledge or customary techniques in the art not disclosed herein. The description and examples are to be considered as exemplary only, and the true scope and spirit of the present application are indicated by the following claims.

[0210] It should be understood that the present application is not limited to the exact structure described above and shown in the drawings, and that various modifications and changes may be made without departing from the scope thereof. The scope of the present application is limited only by the appended claims.

Claims

1. A hot repair method for Android applications, characterized in that: Applied to the client, the hot repair method includes: In response to receiving a software repair and update notification for an Android application, requesting a server to download a software patch package for the Android application; In response to receiving the download address of the software patch package returned by the server, downloading the software patch package from the download address; Generate a complete repair file based on the software patch package; Start a restart monitoring service for the Android application to wait for an application restart opportunity, and restart the Android application when monitoring that the Android application meets the application restart opportunity; After the Android application is restarted, the repair file is loaded to complete the hot repair of the Android application.

2. The thermal repair method according to claim 1, characterized in that The software patch package includes a marker file for identifying whether each file in the version file of the Android application has changed. The generating of a complete repair file based on the software patch package includes: Traversing each file in the previous version file of the Android application, and dividing each file in the previous version file into changed files and unchanged files based on the marker file, wherein the changed files include newly added files; For the changed file, generating a composite file according to the software patch package and the changed file based on a composite algorithm; The synthesized file is saved to the DEX file directory of the current version, and the unchanged file is copied to the file directory of the current version to obtain a complete repair file.

3. The thermal repair method according to claim 1 or 2, characterized in that: When monitoring that the Android application meets the application restart timing, restarting the Android application includes: When it is detected that the Android application is in a background suspended state and no key operations are performed, the context information of the current page of the Android application is saved locally and the Android application is restarted; Correspondingly, the loading of the repair file to complete the hot repair of the Android application includes: The repair file is loaded, and the page state of the Android application is restored according to the context information saved locally to complete the hot repair of the Android application.

4. The thermal repair method according to claim 3, characterized in that: The loading of the repair file includes: Determine whether there is a new software patch package on the server; If the server does not have a new software patch package, then check whether a complete repair file exists locally; If a complete repair file exists locally, the repair file is loaded.

5. The thermal repair method according to claim 4, characterized in that: Also includes: If there is a new software patch package on the server, executing the step of downloading the software patch package from the download address; If the complete patch file does not exist locally, the current hotfix process ends.

6. The thermal repair method according to claim 1 or 2, characterized in that: The downloaded software patch package is generated based on the file differences between the version files of the current repair version and the version files of the previous repair version.

7. A hot repair system for Android applications, characterized in that: include: A client, configured to execute the method according to any one of claims 1 to 6; The server is used to manage the patch packages uploaded by the developer, push software repair and update notifications for Android applications to the client, and respond to requests from the client to download software patch packages for the Android applications.

8. The thermal repair system according to claim 7, characterized in that: It also includes a development end, which is used to generate a software patch package corresponding to the current repair version based on the file difference between the version file of the current repair version of the Android application and the version file of the previous repair version, and the software patch package contains a marker file that identifies whether the file has changed.

9. A hot repair device for Android applications, characterized in that: Applied to the client, the hot repair device includes: An update request module is configured to, in response to receiving a software repair and update notification for an Android application, request a server to download a software patch package for the Android application; a patch download module, configured to download the software patch package from the download address in response to receiving the download address of the software patch package returned by the server; A patch synthesis module, used to generate a complete repair file based on the software patch package; The restart monitoring module is used to start the restart monitoring service for the Android application and wait for the application restart time, and restart the Android application when it is monitored that the Android application meets the application restart time; and after the Android application is restarted, load the repair file to complete the hot repair of the Android application.

10. An electronic device, characterized in that: include: a processor, and a memory communicatively connected to the processor; The memory is used to store computer-executable instructions; The processor is configured to execute the computer-executable instructions to implement the method according to any one of claims 1 to 6.

Images