WO2017193640A1 - 应用更新方法和装置 - Google Patents

应用更新方法和装置 Download PDF

Info

Publication number
WO2017193640A1
WO2017193640A1 PCT/CN2017/072269 CN2017072269W WO2017193640A1 WO 2017193640 A1 WO2017193640 A1 WO 2017193640A1 CN 2017072269 W CN2017072269 W CN 2017072269W WO 2017193640 A1 WO2017193640 A1 WO 2017193640A1
Authority
WO
WIPO (PCT)
Prior art keywords
file
application client
patch
patch file
application
Prior art date
Application number
PCT/CN2017/072269
Other languages
English (en)
French (fr)
Inventor
魏宇峰
饶凌河
李金涛
林孟光
Original Assignee
腾讯科技（深圳）有限公司
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 腾讯科技（深圳）有限公司 filed Critical 腾讯科技（深圳）有限公司
Publication of WO2017193640A1 publication Critical patent/WO2017193640A1/zh
Priority to US16/046,735 priority Critical patent/US10871953B2/en

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00—Arrangements for software engineering
    • G06F8/60—Software deployment
    • G06F8/65—Updates
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/50—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems
    • G06F21/51—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems at application loading time, e.g. accepting, rejecting, starting or inhibiting executable software based on integrity or source reliability
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/50—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems
    • G06F21/57—Certifying or maintaining trusted computer platforms, e.g. secure boots or power-downs, version controls, system software checks, secure updates or assessing vulnerabilities
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00—Arrangements for software engineering
    • G06F8/70—Software maintenance or management
    • G06F8/71—Version control; Configuration management
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/445—Program loading or initiating
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/48—Program initiating; Program switching, e.g. by interrupt
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/34—Network arrangements or protocols for supporting network services or applications involving the movement of software or configuration parameters 

Definitions

  • the present invention relates to the field of computers, and in particular to an application update method and apparatus.
  • the application version update in the prior art usually includes the following two methods:
  • Incremental update mode the application market collects the package information of the application that the client needs to update, performs differential comparison on the server side of the application market, provides the incremental update package download to the client, and adds the incremental update package on the client. Integrate with the local old version installation package into a new version installation package for installation.
  • the complete update method needs to re-download the complete installation package, for a larger installation package requires a long download time and traffic.
  • the application is updated, the current operation of the user needs to be interrupted, the application update efficiency is lowered, and the user experience is seriously affected.
  • Incremental update mode Although the volume of the update package that needs to be downloaded can be reduced by differential comparison, the incremental update mode requires the incremental update package and the local old version installation package on the client side. Convergence will consume more client resources, and the amount of resources it consumes is determined by the local old version installation package size, incremental update package size, and client performance. Moreover, the incremental update mode also needs to interrupt the user's current operation, enter the installation interface to install the application, and seriously reduce the application update efficiency.
  • the embodiment of the present invention provides an application update method and apparatus, so as to at least solve the technical problem that the application update in the related art needs to interrupt the current operation of the user to enter the installation interface, thereby reducing the application update efficiency.
  • an application update method including: an application server generates a patch file according to a class file having a difference between an update version file of an application client and a current version file; the application server generates the Sending the patch file to the application client; the application client detects whether a patch file of the application exists when being started; and the application client is in the application client when detecting the existence of the patch file The patch file is loaded during the running process to update the application client.
  • an application update method including: detecting, when the application client is started, whether there is a patch file of an application, where the patch file is an updated version file and a current version according to an application client. A file generated by a difference between the files of the class file; and when the patch file is detected, the patch file is loaded during the execution of the application client to update the application client.
  • an application updating apparatus including: a detecting unit, configured to detect, when the application client is started, whether there is a patch file of an application, where the patch file is according to an application client. a file generated by updating a class file having a difference between the version file and the current version file; and a first loading unit, configured to load the patch file during the running of the application client when the patch file is detected, so as to apply to the application The client updates.
  • FIG. 5 is a schematic diagram of security verification of a patch file according to an embodiment of the present invention.
  • FIG. 12 is a schematic diagram of another optional application updating apparatus according to an embodiment of the present invention.
  • V1.0 is the current version file of the application client, which includes A.class, B.class, C.class, D.class and other files.
  • Project v2.0 is an updated version file of the application client, which also includes A.class, B.class, C.class, D.class and other files, assuming that the updated version file Project v2.0 has been modified.
  • B.class, D.class as shown by the dotted line in Figure 3.
  • the real-time sending mode or the timed sending mode can be used. Specifically, the real-time sending mode can send the generated patch file to the client immediately after the application server generates the patch file.
  • the timing sending method may be that after the application server generates the patch file, the generated patch file may be sent to the client according to a predetermined time threshold. It should be noted that the predetermined time threshold in the timing transmission mode is small to ensure that no delay is caused to the application client update.
  • the application server preferably sends the generated patch file to the application client in a real-time sending manner.
  • the application client can arrange the patch file patch.dex in front of the related file class.dex in the current version file, as shown in FIG. 4, the left side is the front.
  • the application client can arrange the patch file in front of the related file, so that the patch file can be loaded when the application client runs the patch file.
  • the first type of file is called, and the second type of file of the related file is not called.
  • the second type of file related to the file can be understood as the class file in the current version file of the application client.
  • the first type file of the patch file can be understood as the class file in the update version file of the application client that has been modified relative to the current version file.
  • the two have the same name, and the application client can achieve the purpose of updating the running process of the current version file by using the first type file of the patch file instead of calling the second type file of the related file, thereby achieving the goal.
  • Improve the effectiveness of application updates improve the effectiveness of application updates.
  • the application client loads the patch file during the running process of the application client. Afterwards, the application client can detect in real time whether an instruction to call a class file having the same name is received, and when receiving an instruction to call a class file having the same name, the application client can also detect the class file having the same name. Positional relationship, when it is detected that the patch file is arranged in front of the related file, and the first type file of the patch file and the second type file of the related file have the same name, as shown in FIG. 4, the application client can call The first type of file, not the second type of file.
  • the optional embodiment application client invokes the first type of file by detecting that the patch file is arranged in front of the related file, and the first type of the patch file and the second type of the related file have the same name, instead of Call the second type of file.
  • the second type of file related to the file can be understood as the class file in the current version file of the application client.
  • the first type file of the patch file can be understood as the class file in the update version file of the application client that has been modified relative to the current version file. The two have the same name, and the application client can achieve the purpose of updating the running process of the current version file by using the first type file of the patch file instead of calling the second type file of the related file, thereby solving the problem.
  • the application when the application is updated, it is necessary to interrupt the current operation of the user to enter the installation interface, which leads to a technical problem of reducing the application update efficiency, and achieves an effect of improving the application update efficiency.
  • Step S1102 The application client requests, from the application server, whether the latest patch file of the application client exists.
  • FIG. 5 is a schematic diagram of security verification of a patch file according to an embodiment of the present invention.
  • the application server issues a patch file and applies for security verification of the patch file.
  • the patch file may be patched first. All the files in the jar class.dex, version.txt, etc.
  • the application client can determine whether the detected patch file matches the current version file. It should be noted that the application client detects the patch file and the current version. The content of the file matching is not specifically limited. It may be an update file for detecting whether the patch file is the current version file of the application, etc., and is not illustrated here. By determining whether the patch file matches the current version file, the application client can ensure that the application client can achieve an accurate update and prevent the application client from updating to the wrong version. When the patch file matches the current version file, the application client can load This patch file is used to update the application client. After detecting that the patch file exists, the application client determines whether the patch file matches the current version file, thereby improving the accuracy of the application client update, thereby improving the performance of the updated application client.
  • Step S602 detecting whether a patch file exists locally in the application client. If yes, step S603 is performed; if not, step S607 is performed.
  • Step S603 Determine whether the locally existing patch file matches the current version file of the application client. If yes, step S604 is performed; if not, step S607 is performed.
  • Step S604 performing security verification on the local patch file.
  • Step S606 loading a local patch file.
  • Step S608 the pull communication protocol acquires a remote patch file from the application server.
  • Step S609 determining whether the remote patch file matches the current version file of the application client. If yes, step S610 is performed; if not, it ends.
  • Step S610 downloading a remote patch file.
  • Step S611 determining whether it is necessary to forcibly restart the application client. If the forced start is required, step S612 is performed; if the forced restart is not required, step S615 is performed.
  • Step S612 performing security verification on the remote patch file.
  • step S614 the application client is restarted, and the process proceeds to step S601.
  • step S615 it is waiting for the application client to be restarted next time.
  • each time the application client application starts it will detect whether there is a valid patch file (patch.jar) locally. If not, the initialization is completed according to the normal process. At this time, the version of the application client is the initial version. .
  • the update information of the application client is obtained through the communication protocol with the application server. If the new version information exists, the corresponding patch file is downloaded, and whether the user needs to interrupt the user operation to restart the upgrade through the background setting, or wait for the next The chance of a reboot is silently upgraded.
  • the application client is started again (the current version number of the application client is still the old version number), a new patch file will be detected locally. After the RSA+SHA1 security check is performed on the patch file, the The patch file, version number is upgraded to the new version number, and the version upgrade of the application client is completed.
  • the application client in the embodiment of the present invention may be an application that can run under the Android system, or an application that runs under the IOS system.
  • the embodiment of the present invention is applicable not only to a Java class file but also to an upgrade of an xml resource file, a library file, and the like.
  • the embodiment of the present invention is based on the Android MultiDex subcontracting scheme.
  • the Android application client includes a dex file compiled with a Java class, and the MultiDex splits a dex file into two or more. (For example, classes.dex, classes1.dex...), when the Android application client starts, it will check the MultiDex and load each dex file in turn through DexClassLoader.
  • the Android MultiDex subcontracting principle is used to compile the Java class that needs to be dynamically updated into a separate dex and generate an update package, and the update package is detected during the startup phase of the Android application client, if present,
  • the update package is loaded by DexClassLoader to achieve the purpose of dynamic update, which reduces application client update time and traffic consumption, and greatly improves update efficiency.
  • an embodiment of a method of applying an update method is provided.
  • FIG. 7 is a flowchart of another optional application update method according to an embodiment of the present invention. As shown in FIG. 7, the method may include the following steps:
  • Step S202 detecting whether there is a patch file of the application client when the application client is started, where the patch file is a file generated according to a class file having a difference between the update version file of the application client and the current version file;
  • class files can be separately generated into a dex file and packaged into a patch file patch.jar.
  • the step S204 loading the patch file in the process of the application client running may include: step S2041, arranging the patch file in front of the related file in the current version file, so that the patch file is in the The first type of file is called when the second type of file of one type of file and the related file has the same name, and the second type of file is not called.
  • a DexClassLoader can contain multiple dex files. Each dex file is an Element. Multiple dex files are arranged into an ordered array of dexElements. When looking for a class, the dex files are traversed in order. If the same class exists in different dex, then the class of the dex file listed above will be preferred. Therefore, you only need to package the class that needs to be updated into a dex (for example, patch.dex shown in Figure 4), and then insert this dex into the front of Elements, you can implement dynamic update and upgrade of the class.
  • a dex for example, patch.dex shown in Figure 4
  • the application client can detect in real time whether an instruction to call a class file having the same name is received, and an instruction to call a class file having the same name is received.
  • the application client can also detect the location relationship of the class file having the same name.
  • the alternative embodiment can invoke the first type of file without invoking the second type of file.
  • the optional embodiment calls the first type of file without calling the second when it is detected that the patch file is arranged in front of the related file, and the first type of the file of the patch file and the second type of the related file have the same name.
  • the second type of file related to the file can be understood as the class file in the current version file of the application client.
  • the first type file of the patch file can be understood as the class file in the update version file of the application client that has been modified relative to the current version file. Both have the same name.
  • the optional embodiment can update the application client by using the current version file running process on the application client by calling the first type file of the patch file instead of calling the second type file of the related file.
  • the purpose of the invention is to solve the technical problem that the user needs to interrupt the current operation of the user to enter the installation interface and reduce the application update efficiency, and achieve the effect of improving the application update efficiency.
  • the optional embodiment may further include the following steps:
  • Step S2062 requesting, from the application server, whether the latest patch file of the application client exists
  • Step S2064 If the latest patch file exists, obtain the latest patch file from the application server.
  • step S2066 the latest patch file is loaded after the application client is started again to update the application client.
  • detecting whether a patch file exists when the application client is started may be If the patch file is not locally generated, the optional embodiment may request the latest patch file of the application client from the application server, where the application server can support and maintain the application client. .
  • the application client when the application client is started, the local patch file is detected, and after the detected patch file is loaded in the application client process, the application client may also request the latest version file of the application client from the application server.
  • the local patch file loaded during the application client running process may not be the latest version, that is, the application server may release the updated version file of the application client to the application client during the process of loading the patch file.
  • the optional embodiment may also request the latest patch file of the application client from the server to achieve the purpose of updating the application client.
  • the application client may obtain the latest patch file from the application server, and after the application client is restarted, the application client may be loaded during the running process of the application client. The latest patch file to update the application client.
  • the optional embodiment can ensure that the application client is updated to the latest version during the running process by requesting the latest patch file of the application client from the application server and loading the latest patch file during the running of the application client. Achieve the effect of improving the efficiency of application updates.
  • the optional embodiment may further include: Step S2031, the application client performs the patch file The security verification; the step S204 loading the patch file in the process of the application client running may include: Step S2042, loading the patch file during the running of the application client when the security verification is passed.
  • the application client may perform security check on the detected patch file to ensure that the patch file loaded during the application client running process is a secure and reliable file, thereby enabling Improve the security and reliability of the application client.
  • the optional embodiment does not specifically limit the specific content of the security check of the patch file by the application client, and may include, but is not limited to, verifying whether the patch file contains doubts. Like virus files, etc., no more examples are given here.
  • the optional embodiment may load the patch file during the running of the application client, so as to implement the purpose of updating the application client.
  • the patch file since the patch file is downloaded as a jar file and stored in the application client local or application server, the patch file may be tampered with to achieve the purpose of destroying the patch file. Therefore, when the client detects the presence of the patch file and completes the download and each time it is loaded, the RSA signature + SHA1 check mechanism can be used to ensure that the data in the cached patch file is not tampered with.
  • the application server issues a patch file and applies for security check on the patch file. Specifically, you can first perform SHA1 calculation on all files in the patch file, patch.jar, and verify. .txt file; then sign the verify.txt with the private key to generate the verify.signature file.
  • the application client can download the patch file patch.jar from the application server and store it locally. Before loading the patch file patch.jar, you can use the public key to verify the verify.txt file and perform SHA1 check on all the files in the patch file. In the case of verification, the application client loads the patch file. Patch.jar to update the application client.
  • the SHA1 algorithm is a mature algorithm in the prior art, and is not specifically limited in the embodiment of the present invention, and details are not described herein again.
  • the optional embodiment may further include: Step S2032, the application client determines the patch file and Whether the current version file matches; the step S204 loading the patch file in the process of running the application client includes: Step S2043, loading the patch file when the patch file matches the current version file.
  • the application client can determine whether the detected patch file matches the current version file.
  • the optional embodiment detects the patch file and the current application client.
  • the content of the version file is not limited.
  • the detection of the patch file is an update file of the current version of the application client.
  • This alternative embodiment determines the patch file and current Whether the version files match, can ensure that the application client can achieve accurate updates, and avoid the application client update to the wrong version.
  • the optional embodiment can load the patch file to facilitate updating the application client.
  • the optional embodiment can improve the accuracy of the application client update by determining whether the patch file matches the current version file after detecting the existence of the patch file, thereby improving the performance of the updated application client.
  • the method according to the above embodiment can be implemented by means of software plus a necessary general hardware platform, and of course, by hardware, but in many cases, the former is A better implementation.
  • the technical solution of the present invention which is essential or contributes to the prior art, may be embodied in the form of a software product stored in a storage medium (such as ROM/RAM, disk,
  • the optical disc includes a number of instructions for causing a terminal device (which may be a cell phone, a computer, a server, or a network device, etc.) to perform the methods described in various embodiments of the present invention.
  • FIG. 8 is a schematic diagram of an optional application updating apparatus according to an embodiment of the present invention. As shown in FIG. 8, the apparatus may include:
  • a generating unit 12 configured to generate, by the application server, a patch file according to a class file that has a difference between the updated version file of the application client and the current version file;
  • the sending unit 14 is configured to send, by the application server, the generated patch file to the application client;
  • the unit 16 is configured to detect whether a patch file exists when the application client is started, and the first loading unit 18 is configured to: when the application client detects the presence of the patch file, load the patch file during the running of the application client, In order to update the application client.
  • the generating unit 12 in this embodiment may be used to perform step S102 in the first embodiment of the present application.
  • the sending unit 14 in this embodiment may be used to perform step S104 in Embodiment 1 of the present application.
  • the detecting unit 16 in the embodiment may be used to perform step S106 in Embodiment 1 of the present application, and the first loading unit 18 in this embodiment may be used to perform step S108 in Embodiment 1 of the present application.
  • the above modules are the same as the examples and application scenarios implemented by the corresponding steps, but are not limited to the contents disclosed in the above embodiment 1. It should be noted that the foregoing module may be implemented in a hardware environment as shown in FIG. 1 as part of the device, and may be implemented by software or by hardware, where the hardware environment includes a network environment.
  • FIG. 9 is a schematic diagram of another optional application updating apparatus according to an embodiment of the present invention.
  • the generating unit 12 may include: an obtaining module 122 for an application server. Obtaining an update version file and a current version file of the application client; the comparison module 124 is configured to compare the update version file and the current version file of the application client, and obtain a class file having a difference between the update version file of the application client and the current version file. And a packaging module 126 for packaging the class file into a patch file.
  • the obtaining module 122 in this embodiment may be used to perform step S1022 in the first embodiment of the present application.
  • the comparison module 124 in this embodiment may be used to perform step S1024 in Embodiment 1 of the present application.
  • the packaging module 126 in this embodiment may be used to perform step S1026 in Embodiment 1 of the present application.
  • the above modules are the same as the examples and application scenarios implemented by the corresponding steps, but are not limited to the contents disclosed in the above embodiment 1. It should be noted that the foregoing module may be implemented in a hardware environment as shown in FIG. 1 as part of the device, and may be implemented by software or by hardware, where the hardware environment includes a network environment.
  • FIG. 10 is a schematic diagram of another optional application updating apparatus according to an embodiment of the present invention.
  • the first loading unit 18 may include: The module 181 is configured to: the application client arranges the patch file in front of the related file in the current version file, so that when the first type file of the patch file and the second type file of the related file have the same name, the first type file is Called while the second type of file is not called.
  • the arranging module 181 in this embodiment may be used to perform step S1081 in Embodiment 1 of the present application. It should be noted here that the module is the same as the example and application scenario implemented by the corresponding steps, but is not limited to the content disclosed in the above embodiment 1. It should be noted that the module can be implemented in the hardware environment as shown in FIG. 1 as part of the device, and can be implemented by software or by hardware. The hardware environment includes a network environment.
  • FIG. 11 is a schematic diagram of another optional application updating apparatus according to an embodiment of the present invention.
  • the optional embodiment may further include: calling unit 1101, After the application client loads the patch file in the process of running the application client, the application client detects that the patch file is arranged in front of the related file and the first type of the patch file when receiving the class file with the same name.
  • the second type of file of the file and related files has the same name, calling the first type of file instead of calling the second type of file.
  • the calling unit 1101 in this embodiment may be used to perform step S1101 in Embodiment 1 of the present application.
  • the module is the same as the example and application scenario implemented by the corresponding steps, but is not limited to the content disclosed in the above embodiment 1. It should be noted that the module can be implemented in the hardware environment as shown in FIG. 1 as part of the device, and can be implemented by software or by hardware.
  • the hardware environment includes a network environment.
  • the above modules are the same as the examples and application scenarios implemented by the corresponding steps, but are not limited to the contents disclosed in the above embodiment 1. It should be noted that the foregoing module may be implemented in a hardware environment as shown in FIG. 1 as part of the device, and may be implemented by software or by hardware, where the hardware environment includes a network environment.
  • FIG. 13 is a schematic diagram of another optional application updating apparatus according to an embodiment of the present invention.
  • the optional embodiment may further include: a verifying unit 171.
  • the application client performs security check on the patch file after the patch file is detected and the patch file is loaded in the process of running the application client.
  • the first loading unit 18 includes: a first loading module 182. For the security check to pass, the application client loads the patch file during the running of the application client.
  • verification unit 171 in this embodiment may be used to perform step S1071 in Embodiment 1 of the present application
  • first loading module 182 in this embodiment may be used to perform the steps in Embodiment 1 of the present application. S1082.
  • the above modules are the same as the examples and application scenarios implemented by the corresponding steps, but are not limited to the contents disclosed in the above embodiment 1. It should be noted that the foregoing module may be implemented in a hardware environment as shown in FIG. 1 as part of the device, and may be implemented by software or by hardware, where the hardware environment includes a network environment.
  • the determining unit 172 in this embodiment may be used to perform step S1072 in the first embodiment of the present application.
  • the second loading module 183 in this embodiment may be used to perform step S1083 in the first embodiment of the present application. .
  • the above modules are the same as the examples and application scenarios implemented by the corresponding steps, but are not limited to the contents disclosed in the above embodiment 1. It should be noted that the foregoing module may be implemented in a hardware environment as shown in FIG. 1 as part of the device, and may be implemented by software or by hardware, where the hardware environment includes a network environment.
  • the technical problem that the user needs to interrupt the current operation of the user to enter the installation interface and reduce the application update efficiency when the application is updated may be solved, thereby achieving the technical effect of improving the application update efficiency.
  • FIG. 15 is a schematic diagram of an optional application updating apparatus according to an embodiment of the present invention. As shown in FIG. 15, the apparatus may include:
  • the detecting unit 22 is configured to detect whether there is a patch file of the application when the application is started, where the patch file is a file generated according to a class file having a difference between the updated version file of the application and the current version file; and the first loading The unit 24 is configured to load the patch file during the running of the application to detect the presence of the patch file, so as to update the application.
  • the detecting unit 22 in this embodiment may be used to perform step S202 in the first embodiment of the present application.
  • the first loading unit 24 in this embodiment may be used to perform step S204 in Embodiment 1 of the present application. .
  • the foregoing modules are the same as the examples and application scenarios implemented by the corresponding steps, but are not limited to the contents disclosed in the foregoing embodiment 2. It should be noted that the foregoing module may be implemented in a hardware environment as shown in FIG. 1 as part of the device, and may be implemented by software or by hardware, where the hardware environment includes a network environment.
  • FIG. 16 is another alternative in accordance with an embodiment of the present invention.
  • the first loading unit 24 may include: an arranging module 241, configured to arrange the patch file in front of the related file in the current version file, so that the first type in the patch file When the second type of file and the related file have the same name, the first type of file is called, and the second type of file is not called.
  • the arranging module 241 in this embodiment may be used to perform step S2041 in Embodiment 1 of the present application.
  • the foregoing modules are the same as the examples and application scenarios implemented by the corresponding steps, but are not limited to the contents disclosed in the foregoing embodiment 2.
  • the foregoing module may be implemented in a hardware environment as shown in FIG. 1 as part of the device, and may be implemented by software or by hardware, where the hardware environment includes a network environment.
  • FIG. 17 is a schematic diagram of another optional application updating apparatus according to an embodiment of the present invention.
  • the optional embodiment may further include: an invoking unit 261, After the patch file is loaded during the running of the application, when the application receives the calling class file with the same name, it detects that the patch file is arranged in front of the related file, and the first type file of the patch file and the second file of the related file.
  • the class file has the same name, calling the first class file instead of calling the second class file.
  • the calling unit 261 in this embodiment may be used to perform step S2061 in Embodiment 1 of the present application.
  • the foregoing modules are the same as the examples and application scenarios implemented by the corresponding steps, but are not limited to the contents disclosed in the foregoing embodiment 2.
  • the foregoing module may be implemented in a hardware environment as shown in FIG. 1 as part of the device, and may be implemented by software or by hardware, where the hardware environment includes a network environment.
  • FIG. 18 is a schematic diagram of another optional application updating apparatus according to an embodiment of the present invention.
  • the optional embodiment may further include: a requesting unit 262, After the patch file is not detected or the patch file is loaded during the running of the application, the server is requested to request whether the latest patch file exists.
  • the obtaining unit 264 is configured to obtain the latest patch from the server when the latest patch file exists.
  • the patch file 260 is configured to load the latest patch file after the application is restarted to update the application.
  • the requesting unit 262 in this embodiment may be used to perform step S2062 in the first embodiment of the present application.
  • the obtaining unit 264 in this embodiment may be used to perform step S2064 in Embodiment 1 of the present application.
  • the second loading unit 266 in the embodiment may be used to perform step S2066 in Embodiment 1 of the present application.
  • the foregoing modules are the same as the examples and application scenarios implemented by the corresponding steps, but are not limited to the contents disclosed in the foregoing embodiment 2. It should be noted that the foregoing module may be implemented in a hardware environment as shown in FIG. 1 as part of the device, and may be implemented by software or by hardware, where the hardware environment includes a network environment.
  • FIG. 19 is a schematic diagram of another optional application updating apparatus according to an embodiment of the present invention.
  • the optional embodiment may further include: a verifying unit 231. Used to perform security check on the patch file after detecting the existence of the patch file and before loading the patch file during the running of the application.
  • the first loading unit 24 may include: a first loading module 242, configured to load a patch file during the running of the application when the security check is passed.
  • the verification unit 231 in this embodiment may be used to perform the step S2031 in the first embodiment of the present application.
  • the first loading module 242 in this embodiment may be used to perform the steps in the first embodiment of the present application. S2042.
  • the foregoing modules are the same as the examples and application scenarios implemented by the corresponding steps, but are not limited to the contents disclosed in the foregoing embodiment 2.
  • the foregoing module may be implemented in a hardware environment as shown in FIG. 1 as part of the device, and may be implemented by software or by hardware, where the hardware environment includes a network environment.
  • FIG. 20 is a schematic diagram of another optional application updating apparatus according to an embodiment of the present invention.
  • the optional embodiment may further include: a determining unit 232, After the patch file is detected and the patch file is loaded during the running of the application, it is determined whether the patch file matches the current version file.
  • the first loading unit 24 may include: a second loading module 243, configured to load the patch file when the patch file matches the current version file.
  • the determining unit 232 in this embodiment may be used to perform step S2032 in the first embodiment of the present application.
  • the second loading module 243 in the embodiment may be used to perform step S2043 in the first embodiment of the present application. .
  • the foregoing modules are the same as the examples and application scenarios implemented by the corresponding steps, but are not limited to the contents disclosed in the foregoing embodiment 2. It should be noted that the foregoing module may be implemented in a hardware environment as shown in FIG. 1 as part of the device, and may be implemented by software or by hardware, where the hardware environment includes a network environment.
  • the technical problem that the user needs to interrupt the current operation of the user to enter the installation interface and reduce the application update efficiency when the application is updated may be solved, thereby achieving the technical effect of improving the application update efficiency.
  • a terminal for implementing the above application update method is further provided.
  • FIG. 21 is a structural block diagram of a terminal according to an embodiment of the present invention.
  • the terminal may include: one or more (only one shown in the figure) processor 201, memory 203, and transmission device 205.
  • the terminal may further include an input and output device 207.
  • the memory 203 can be used to store software programs and modules, such as the application update method and the program instructions/modules corresponding to the device in the embodiment of the present invention.
  • the processor 201 executes each of the software programs and modules stored in the memory 203.
  • a functional application and data processing that is, implementing the above application update method.
  • Memory 203 can include high speed random access memory, and can also include non-volatile memory, such as one or more magnetic storage devices, flash memory, or other non-volatile solid state memory.
  • memory 203 can further include memory remotely located relative to processor 201, which can be connected to the terminal over a network. Examples of such networks include, but are not limited to, the Internet, intranets, local area networks, mobile communication networks, and combinations thereof.
  • the above described transmission device 205 is used to receive or transmit data via a network, and can also be used for data transmission between the processor and the memory. Specific examples of the above network may include a wired network And wireless network.
  • the transmission device 205 includes a Network Interface Controller (NIC) that can be connected to other network devices and routers via a network cable to communicate with the Internet or a local area network.
  • the transmission device 205 is a Radio Frequency (RF) module for communicating with the Internet wirelessly.
  • NIC Network Interface Controller
  • RF Radio Frequency
  • the memory 203 is used to store an application.
  • the processor 201 may call the application stored in the memory 203 through the transmission device 205 to perform the following steps: the application server generates a patch file according to a class file having a difference between the update version file of the application client and the current version file; the application server generates The patch file is sent to the application client; the application client detects whether a patch file exists when the application client is started; and when the application client detects the existence of the patch file, the patch file is loaded during the running of the application client, so that Update the application client.
  • the processor 201 is further configured to: the application server obtains the updated version file and the current version file of the application; compares the updated version file of the application with the current version file, and obtains a difference between the updated version file of the application and the current version file. Class files; and package the class files into patch files.
  • the processor 201 is further configured to perform the following steps: the application client arranges the patch file in front of the related file in the current version file, so that the first type file of the patch file and the second type file of the related file have the same name. The first type of file is called, and the second type of file is not called.
  • the processor 201 is further configured to: when the application client does not detect the patch file or load the patch file during the running of the application, the application client requests the application server whether the latest patch file exists; if The latest patch file, the application client is Obtain the latest patch file from the application server; the application client loads the latest patch file after the application is restarted to update the application.
  • the processor 201 is further configured to: after the application client detects the existence of the patch file, and before loading the patch file in the process of running the application, the application client performs security verification on the patch file; the application client is in the application.
  • Loading the patch file during the running process includes: when the security check is passed, the application client loads the patch file during the running of the application.
  • the processor 201 is further configured to: after the application client detects the existence of the patch file, and before loading the patch file in the process of running the application, the application client determines whether the patch file matches the current version file; the application client Loading the patch file during the running of the application includes: when the patch file matches the current version file, the application client loads the patch file.
  • the terminal can be a smart phone (such as an Android mobile phone, an iOS mobile phone, etc.), a tablet computer, a palm computer, and a mobile Internet device (MID). Terminal equipment such as PAD.
  • Fig. 21 does not limit the structure of the above electronic device.
  • the terminal may also include more or less components (such as a network interface, display device, etc.) than shown in FIG. 21, or have a different configuration than that shown in FIG.
  • Embodiments of the present invention also provide a storage medium.
  • the foregoing storage medium may be used to execute program code of an application update method.
  • the foregoing storage medium may be located on at least one of the plurality of network devices in the network shown in the foregoing embodiment.
  • the application server generates a patch file according to a class file that differs between the updated version file of the application client and the current version file.
  • the application server sends the generated patch file to the application client
  • the application client detects whether a patch file exists when the application client is started.
  • the storage medium is further configured to store program code for performing the following steps: the application server obtains the updated version file and the current version file of the application; compares the updated version file of the application with the current version file, and obtains an updated version of the application.
  • a class file that differs between the file and the current version file; and the class file is packaged into a patch file.
  • the storage medium is further configured to store program code for performing the following steps: the application client arranges the patch file in front of the related file in the current version file, so that the first type of file in the patch file is related The first type of file has the same name when it is the first type The file is called and the second type of file is not called.
  • the storage medium is further configured to store program code for performing the following steps: after the application client loads the patch file during the running of the application, the application client receives the class file with the same name when the application receives the application, It is detected that the patch file is arranged in front of the related file, and the first type file of the patch file and the second type file of the related file have the same name, and the first type file is called instead of the second type file.
  • the storage medium is further configured to store program code for performing the following steps: the application client requests the application server after the patch file is not detected or after the patch file is loaded during the running of the application, The latest patch file is applied; if the latest patch file exists, the application client obtains the latest patch file from the application server; the application client loads the latest patch file after the application is restarted to update the application.
  • the storage medium is further configured to store program code for performing the following steps: the application client performs the patch file after detecting the existence of the patch file, and before the application loads the patch file, the application client performs the patch file Security verification; the application client loads the patch file during the running of the application, including: when the security verification is passed, the application client loads the patch file during the running of the application.
  • the storage medium is further configured to store program code for performing the following steps: after the application client detects the presence of the patch file, and before loading the patch file during the running of the application, the application client determines the patch file and Whether the current version file matches; the application client loads the patch file during the running of the application, including: when the patch file matches the current version file, the application client loads the patch file.
  • the foregoing storage medium may include, but is not limited to, a USB flash drive, a Read-Only Memory (ROM), and a random access memory (RAM, Random).
  • ROM Read-Only Memory
  • RAM random access memory
  • the integrated unit in the above embodiment if implemented in the form of a software functional unit and sold or used as a stand-alone product, may be stored in the above-described computer readable storage medium.
  • the technical solution of the present invention may contribute to the prior art or all or part of the technical solution may be embodied in the form of a software product stored in a storage medium.
  • a number of instructions are included to cause one or more computer devices (which may be a personal computer, server or network device, etc.) to perform all or part of the steps of the methods described in various embodiments of the present invention.
  • the disclosed client may be implemented in other manners.
  • the device embodiments described above are merely illustrative.
  • the division of the unit is only a logical function division.
  • multiple units or components may be combined or may be Integrate into another system, or some features can be ignored or not executed.
  • the mutual coupling or direct coupling or communication connection shown or discussed may be an indirect coupling or communication connection through some interface, unit or module, and may be electrical or otherwise.
  • the units described as separate components may or may not be physically separated, and the components displayed as units may or may not be physical units, that is, may be located in one place, or may be distributed to multiple network units. Some or all of the units may be selected according to actual needs to achieve the purpose of the solution of the embodiment.
  • each functional unit in each embodiment of the present invention may be integrated into one processing unit, or each unit may exist physically separately, or two or more units may be integrated into one unit.
  • the above integrated unit can be implemented in the form of hardware or soft. The form of the functional unit is implemented.

Landscapes

  • Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • Theoretical Computer Science (AREA)
  • General Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Computer Hardware Design (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Stored Programmes (AREA)
  • Information Transfer Between Computers (AREA)

Abstract

本发明公开了一种应用更新方法和装置。其中，该方法包括：应用服务器根据应用客户端的更新版本文件与当前版本文件之间存在差异的类文件生成补丁文件；应用服务器将生成的补丁文件发送至应用客户端；应用客户端在应用客户端被启动时检测是否存在补丁文件；以及应用客户端在检测到存在补丁文件时，在应用客户端运行的过程中加载补丁文件，以便对应用客户端进行更新。本发明解决了相关技术中应用更新时需要中断用户当前操作进入安装界面导致降低应用更新效率的技术问题。

Description

应用更新方法和装置
本申请要求于2016年05月07日提交中国专利局、申请号为201610297069.4、发明名称“应用更新方法和装置”的中国专利申请的优先权，其全部内容通过引用结合在本申请中。
技术领域
本发明涉及计算机领域，具体而言，涉及一种应用更新方法和装置。
背景技术
目前，随着用户需求的不断增加，应用需要依据用户需求进行版本更新。现有技术中应用版本更新通常包括以下两种方式：
完整更新方式，通过应用市场或者应用内建的自更新功能下载新版本的完整安装包。
增量更新方式，应用市场通过收集客户端需要更新的应用的安装包信息，在应用市场的服务器端进行差分对比，向客户端提供增量更新包下载，并在客户端上将增量更新包与本地旧版本安装包融合成新版本安装包进行安装。
上述两种应用更新方式均需要一个新版本的安装包覆盖安装旧版本安装包以达到更新版本更新的目的。但是，上述两种应用更新方式存在以下缺点：
1、完整更新方式需要重新下载完整的安装包，对于体积较大的安装包需要耗费较长的下载时间和流量。而且，应用更新时需要中断用户当前操作，降低了应用更新效率，严重影响了用户的使用体验。
2、增量更新方式虽然通过差分对比可以减少需要下载的更新包的体积，但是，增量更新方式需要在客户端将增量更新包与本地旧版本安装包 进行融合，会占用较多的客户端资源，其占用资源的多少由本地旧版本安装包大小、增量更新包大小和客户端性能决定。而且，增量更新方式也需要中断用户当前操作，进入安装界面进行应用的安装，严重降低了应用更新效率。
针对上述的问题，目前尚未提出有效的解决方案。
发明内容
本发明实施例提供了一种应用更新方法和装置，以至少解决相关技术中应用更新时需要中断用户当前操作进入安装界面导致降低应用更新效率的技术问题。
根据本发明实施例的一个方面，提供了一种应用更新方法，包括：应用服务器根据应用客户端的更新版本文件与当前版本文件之间存在差异的类文件生成补丁文件；所述应用服务器将生成的所述补丁文件发送至应用客户端；所述应用客户端在被启动时检测是否存在所述应用的补丁文件；以及所述应用客户端在检测到存在所述补丁文件时，在所述应用客户端运行的过程中加载所述补丁文件，以便对所述应用客户端进行更新。
根据本发明实施例的一个方面，还提供了一种应用更新方法，包括：在应用客户端被启动时检测是否存在应用的补丁文件，其中，补丁文件为根据应用客户端的更新版本文件与当前版本文件之间存在差异的类文件而生成的文件；以及在检测到存在补丁文件时，在应用客户端运行的过程中加载补丁文件，以便对应用客户端进行更新。
根据本发明实施例的另一方面，还提供了一种应用更新装置，包括：生成单元，用于应用服务器根据应用客户端的更新版本文件与当前版本文件之间存在差异的类文件生成补丁文件；发送单元，用于应用服务器将生成的补丁文件发送至应用客户端；检测单元，用于应用客户端在被启动时检测是否存在补丁文件；以及第一加载单元，用于应用客户端在检测到存在补丁文件时，在应用客户端运行的过程中加载补丁文件，以便对应用客 户端进行更新。
根据本发明实施例的另一方面，还提供了一种应用更新装置，包括：检测单元，用于在应用客户端被启动时检测是否存在应用的补丁文件，其中，补丁文件为根据应用客户端的更新版本文件与当前版本文件之间存在差异的类文件而生成的文件；以及第一加载单元，用于在检测到存在补丁文件时，在应用客户端运行的过程中加载补丁文件，以便对应用客户端进行更新。
在本发明实施例中，通过在应用客户端被启动时检测是否存在根据应用客户端的更新版本文件与当前版本文件之间存在差异的类文件而生成的补丁文件，并在检测到存在上述补丁文件时，通过在应用客户端运行的过程中加载补丁文件实现对应用客户端进行更新，达到了无需中断用户当前操作亦可以实现应用客户端更新的目的，从而实现了提高应用客户端更新效率的技术效果，进而解决了相关技术中应用更新时需要中断用户当前操作进入安装界面导致降低应用更新效率的技术问题。
附图说明
此处所说明的附图用来提供对本发明的进一步理解，构成本申请的一部分，本发明的示意性实施例及其说明用于解释本发明，并不构成对本发明的不当限定。在附图中：
图1是根据本发明实施例的应用更新方法的硬件环境的示意图；
图2是根据本发明实施例的一种可选的应用更新方法的流程图；
图3是根据本发明实施例的补丁文件的生成过程的示意图；
图4是根据本发明实施例的补丁文件的加载过程的示意图；
图5是根据本发明实施例的对补丁文件进行安全校验的示意图；
图6是根据本发明实施例的一种优选的应用更新方法的流程图；
图7是根据本发明实施例的另一种可选的应用更新方法的流程图；
图8是根据本发明实施例的一种可选的应用更新装置的示意图；
图9是根据本发明实施例的另一种可选的应用更新装置的示意图；
图10是根据本发明实施例的另一种可选的应用更新装置的示意图；
图11是根据本发明实施例的另一种可选的应用更新装置的示意图；
图12是根据本发明实施例的另一种可选的应用更新装置的示意图；
图13是根据本发明实施例的另一种可选的应用更新装置的示意图；
图14是根据本发明实施例的另一种可选的应用更新装置的示意图；
图15是根据本发明实施例的一种可选的应用更新装置的示意图；
图16是根据本发明实施例的另一种可选的应用更新装置的示意图；
图17是根据本发明实施例的另一种可选的应用更新装置的示意图；
图18是根据本发明实施例的另一种可选的应用更新装置的示意图；
图19是根据本发明实施例的另一种可选的应用更新装置的示意图；
图20是根据本发明实施例的另一种可选的应用更新装置的示意图；以及
图21是根据本发明实施例的一种终端的结构框图。
具体实施方式
为了使本技术领域的人员更好地理解本发明方案，下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本发明一部分的实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都应当属于本发明保护的范围。
需要说明的是，本发明的说明书和权利要求书及上述附图中的术语 “第一”、“第二”等是用于区别类似的对象，而不必用于描述特定的顺序或先后次序。应该理解这样使用的数据在适当情况下可以互换，以便这里描述的本发明的实施例能够以除了在这里图示或描述的那些以外的顺序实施。此外，术语“包括”和“具有”以及他们的任何变形，意图在于覆盖不排他的包含，例如，包含了一系列步骤或单元的过程、方法、系统、产品或设备不必限于清楚地列出的那些步骤或单元，而是可包括没有清楚地列出的或对于这些过程、方法、产品或设备固有的其它步骤或单元。
实施例1
根据本发明实施例，提供了一种应用更新方法的方法实施例。
可选地，在本实施例中，上述应用更新方法可以应用于如图1所示的由服务器102和终端104所构成的硬件环境中。如图1所示，服务器102通过网络与终端104进行连接，上述网络包括但不限于：广域网、城域网或局域网，终端104并不限定于PC、手机、平板电脑等。本发明实施例的应用更新方法可以由服务器102和终端104共同执行。
图2是根据本发明实施例的一种可选的应用更新方法的流程图，如图2所示，该方法可以包括以下步骤：
步骤S102，应用服务器根据应用客户端的更新版本文件与当前版本文件之间存在差异的类文件生成补丁文件；
步骤S104，应用服务器将生成的补丁文件发送至应用客户端；
步骤S106，应用客户端在被启动时检测是否存在补丁文件；
步骤S108，应用客户端在检测到存在补丁文件时，在应用客户端运行的过程中加载补丁文件，以便对应用客户端进行更新。
通过上述步骤S102至步骤S108，通过应用服务器根据应用客户端的更新版本文件与当前版本文件之间存在差异的类文件生成补丁文件并发送至应用客户端，应用客户端在应用客户端被启动时检测是否存在补丁文 件，并在检测到存在上述补丁文件时，通过在应用客户端运行的过程中加载补丁文件实现对应用客户端进行更新，达到了无需中断用户当前操作亦可以实现应用客户端更新的目的，进而解决了相关技术中应用更新时需要中断用户当前操作进入安装界面导致降低应用更新效率的技术问题，实现了提高应用更新效率的技术效果。
需要说明的是，由应用服务器和应用客户端可以组成应用更新系统，在该系统中应用服务器与应用客户端之间通信连接，包括有线连接和无线连接。应用服务器可以对应用提供数据支持和维护，应用客户端可以安装在任意形式的终端设备上，终端设备可以是手机终端、也可以是电脑终端等。本发明实施例对应用客户端的类型不做具体限定，比如，即时通信类应用等。
在步骤S102提供的技术方案中，当应用客户端存在更新版本文件时，应用服务器可以根据应用客户端的更新版本文件与当前版本文件生成补丁文件，可选地，具体生成过程可以包括以下步骤：
步骤S1022，应用服务器获取应用客户端的更新版本文件和当前版本文件；
步骤S1024，比对应用客户端的更新版本文件和当前版本文件，获取应用客户端的更新版本文件和当前版本文件之间存在差异的类文件；
步骤S1026，将类文件打包成补丁文件。
需要说明的是，应用客户端的当前版本文件可以为该应用客户端启动并正在运行的版本文件，更新版本文件可以为该应用客户端运行的当前版本文件的版本升级文件。比如，应用客户端启动并运行的当前版本文件为V1.0，则该应用客户端的更新版本文件可以为V2.0。还需要说明的是，更新版本文件可以为对当前版本文件中的一个或者多个类文件进行更新后得到的版本文件，则相应地更新版本文件与当前版本文件之间可以存在一个或者多个差异的类文件，本发明实施例可以将这些差异的类文件打包成 补丁文件，利用该补丁文件可以对应用客户端进行更新。
在实际应用场景中，根据应用客户端的更新版本文件与当前版本文件之间存在差异的类文件生成文件补丁文件的具体过程可以如图3所示，需要说明的是，图3所示中的Project v1.0为应用客户端的当前版本文件，其内包括有A.class、B.class、C.class、D.class等类文件。Project v2.0为应用客户端的更新版本文件，其内也包括有A.class、B.class、C.class、D.class等类文件，假设更新版本文件Project v2.0发生过修改的类文件为B.class、D.class，如图3所示虚线框所示。通过比对应用客户端的更新版本文件Project v2.0与当前版本文件Project v1.0之间存在差异的类文件，得到存在差异的类文件Path内包括有B.class、D.class，则可以将这些类文件单独生成dex文件，并将其打包成补丁文件patch.jar。
在步骤S104提供的技术方案中，应用服务器在生成补丁文件之后可以将生成的补丁文件发送至应用客户端，以供应用客户端在启动过程中利用补丁文件对应用客户端进行更新。可选地，应用服务器还可以对生成的补丁文件进行本地缓存，以便于节省应用客户端的存储空间，当应用客户端需要利用补丁文件进行更新时可以从应用服务器缓存中请求补丁文件。还需要说明的是，应用服务器可以利用应用服务器与应用客户端之间的通信连接将生成的补丁文件发送至应用客户端，其中，应用服务器与应用客户端之间的通信连接可以为有线连接，也可以为无线连接。应用服务器利用通信连接向应用客户端发送补丁文件可以采用实时发送方式，也可以采用定时发送方式，具体地，实时发送方式可以为当应用服务器生成补丁文件后立即将生成的补丁文件发送至客户端；定时发送方式可以为当应用服务器生成补丁文件后可以按照预定的时间阈值将生成的补丁文件发送至客户端。需要说明的是，定时发送方式中的预定时间阈值很小，以保证不会对应用客户端更新造成延迟。为了保证应用客户端更新的实时性，本发明实施例中应用服务器优选地采用实时发送方式将生成的补丁文件发送至应用客户端。
在步骤S106提供的技术方案中，应用客户端在启动并运行当前版本文件的过程中，可以实时检测是否存在补丁文件，其中，补丁文件可以为根据应用客户端的更新版本文件与当前版本文件之间存在差异的类文件而生成的文件，以便于在检测到存在补丁文件时利用该补丁文件对应用客户端进行更新。需要说明的是，应用客户端检测到的补丁文件可以是一个，也可以是多个，应用客户端可以利用这些补丁文件可以对应用客户端进行更新。还需要说明的是，应用客户端在被启动时可以检测应用客户端本地是否存在补丁文件，应用客户端本地可以是应用客户端内存空间或者缓存空间。
在步骤S108提供的技术方案中，如果在应用客户端被启动时应用客户端检测到存在一个或者多个补丁文件时，应用客户端可以在应用客户端运行过程中加载这些补丁文件，以实现对应用客户端进行更新的目的。需要说明的是，应用客户端在运行当前版本文件的过程中，通过加载用于更新应用客户端的补丁文件，可以实现在运行当前版本过程中即可以完成对该应用客户端的更新，从而达到了在应用客户端运行过程中无需中断用户当前操作亦可以实现应用客户端进行更新的目的，进而解决了相关技术中应用更新时需要中断用户当前操作进入安装界面导致降低应用更新效率的技术问题，实现了提高应用更新效率的技术效果。
作为一种可选的实施例，步骤S108应用客户端在应用客户端运行的过程中加载补丁文件可以包括：步骤S1081，应用客户端将补丁文件排列在当前版本文件中的相关文件的前面，以使得在补丁文件的第一类文件和相关文件的第二类文件具有相同名称时第一类文件被调用，而第二类文件不被调用。
需要说明的是，应用客户端的当前版本文件中的相关文件可以包括但并不限于应用客户端运行过程所需的类文件，相关文件的个数可以是一个，也可以是多个。该可选实施例中补丁文件的第一类文件与相关文件的第二类文件可以具有相同名称，如图4所示，补丁文件patch.dex的第一类文 件名称为Foo.class，相关文件class.dex的第二类文件名称也为Foo.class，即补丁文件patch.dex的第一类文件与相关文件class.dex的第二类文件具有相同名称，则此时应用客户端可以将补丁文件patch.dex排列在当前版本文件中的相关文件class.dex的前面，如图4所示图左为前面。当补丁文件的第一类文件和相关文件的第二类文件具有相同名称时，应用客户端通过将补丁文件排列在相关文件的前面，可以使得应用客户端运行过程中加载补丁文件时补丁文件的第一类文件被调用，而相关文件的第二类文件不被调用。相关文件的第二类文件可以理解为应用客户端当前版本文件中的类文件，补丁文件的第一类文件可以理解为应用客户端的更新版本文件中相对于当前版本文件发生过修改的类文件，两者具有相同名称，应用客户端通过调用补丁文件的第一类文件，而不调用相关文件的第二类文件，可以达到在应用客户端以当前版本文件运行过程进行更新的目的，进而达到了提高应用更新效率的效果。
在实际应用场景中，在应用客户端被启动时，应用客户端如果检测到存在有效的补丁文件，则可以通过DexClassLoader的方式加载检测到的补丁文件。一个DexClassLoader可以包含多个dex文件，每个dex文件是一个Element，多个dex文件排列成一个有序的数组dexElements，当找类的时候，会按顺序遍历dex文件。如果在不同的dex中有相同的类存在，那么会优先选择排在前面的dex文件的类。因此只需要把需要更新的类打包到一个dex(例如图4所示的patch.dex)中去，然后把这个dex插入到Elements的最前面，则可实现类的动态更新升级。
作为一种可选的实施例，在步骤S108之后，也即应用客户端在应用客户端运行的过程中加载补丁文件之后，该可选实施例还可以包括：步骤S1101，应用客户端在接收到调用具有相同名称的类文件时，检测到补丁文件排列在相关文件的前面、且补丁文件的第一类文件和相关文件的第二类文件具有相同名称，调用第一类文件，而不调用第二类文件。
需要说明的是，应用客户端在应用客户端运行的过程中加载补丁文件 之后，该应用客户端可以实时检测是否接收到调用具有相同名称的类文件的指令，在接收到调用具有相同名称的类文件的指令时，该应用客户端还可以检测具有相同名称的类文件的位置关系，当检测到补丁文件排列在相关文件的前面、且补丁文件的第一类文件和相关文件的第二类文件具有相同名称时，如图4所示的情况，该应用客户端可以调用第一类文件，而不调用第二类文件。
该可选实施例应用客户端通过在检测到补丁文件排列在相关文件的前面、且补丁文件的第一类文件和相关文件的第二类文件具有相同名称时，调用第一类文件，而不调用第二类文件。相关文件的第二类文件可以理解为应用客户端当前版本文件中的类文件，补丁文件的第一类文件可以理解为应用客户端的更新版本文件中相对于当前版本文件发生过修改的类文件，两者具有相同名称，该应用客户端通过调用补丁文件的第一类文件，而不调用相关文件的第二类文件，可以达到在应用客户端以当前版本文件运行过程进行更新的目的，进而解决了相关技术中应用更新时需要中断用户当前操作进入安装界面导致降低应用更新效率的技术问题，达到了提高应用更新效率的效果。
作为一种可选的实施例，应用客户端在未检测到补丁文件时，或者，应用客户端在应用客户端运行的过程中加载补丁文件之后，该可选实施例还可以包括以下步骤：
步骤S1102，应用客户端向应用服务器请求是否存在应用客户端最新的补丁文件；
步骤S1104，若存在最新的补丁文件，应用客户端则从应用服务器获取最新的补丁文件；
步骤S1106，应用客户端在被再次启动之后加载最新的补丁文件，以便对应用客户端进行更新。
需要说明的是，应用客户端在被启动时检测是否存在补丁文件可以为 检测应用客户端的本地是否存在补丁文件，若本地不存在补丁文件，则该可选实施例可以向应用服务器请求该应用客户端的最新的补丁文件。或者，当应用客户端在被启动时检测到本地存在补丁文件，在应用客户端运行过程中加载检测到的补丁文件后，该应用客户端还可以向应用服务器请求该应用客户端的最新的版本文件，此处需要说明的是，应用客户端运行过程中加载的该应用客户端本地的补丁文件可能不是最新版本的，也即在加载补丁文件过程中应用服务器可能又向应用客户端发布了该应用客户端的更新版本文件，则该应用客户端也可以向应用服务器请求该最新的补丁文件，以达到对应用客户端进行更新的目的。当应用服务器中存在最新的补丁文件时，该应用客户端可以从应用服务器中获取该最新的补丁文件，并在该应用客户端被再次启动之后，在运行过程中应用客户端可以加载该最新的补丁文件，以便对该应用客户端进行更新。
该可选实施例应用客户端通过从应用服务器中请求最新的补丁文件，并在应用客户端运行过程中加载该最新的补丁文件，能够保证使得应用客户端在运行过程中更新至最新版本，进而达到提高应用更新效率的效果。
作为一种可选的实施例，应用客户端在检测到存在补丁文件之后，且在应用客户端运行的过程中加载补丁文件之前，该可选实施例还可以包括：步骤S1071，应用客户端对补丁文件进行安全校验；步骤S108在应用客户端运行的过程中加载补丁文件可以包括：步骤S1082，在安全校验通过时，应用客户端在应用客户端运行的过程中加载补丁文件。
需要说明的是，应用客户端在检测到存在补丁文件之后，该应用客户端可以对该检测到的补丁文件进行安全校验，以保证应用客户端运行过程中加载的补丁文件为安全可靠的文件，进而能够提高应用客户端的安全性和可靠性。需要说明的是，该应用客户端对补丁文件进行安全校验的具体内容不做具体限定，其可以是包括但并不限于校验补丁文件是否包含疑似病毒文件等，此处不再一一举例说明。应用客户端在检测到存在补丁文件，且对补丁文件进行安全校验通过时，该应用客户端可以在应用客户端运行 过程中加载该补丁文件，以便于实现对应用客户端进行更新的目的。
在实际应用场景中，由于补丁文件是以jar文件的形式下载并存储在客户端本地或者服务器中，存在可能被篡改从而达到破坏补丁文件的目的。因此，当应用客户端在检测到存在补丁文件，并在下载完成以及每次加载时，可以通过RSA签名+SHA1校验的机制，来确保缓存的补丁文件中的数据不被篡改。图5是根据本发明实施例的对补丁文件进行安全校验的示意图，如图5所示，应用服务器发布补丁文件并申请对补丁文件进行安全校验，具体地，可以首先对补丁文件patch.jar中的所有文件class.dex、version.txt等做SHA1计算，生成verify.txt文件；然后使用私钥对verify.txt签名，生成verify.signature文件。应用客户端可以从应用服务器下载补丁文件patch.jar，并将其存储在客户端本地。在加载补丁文件patch.jar之前可以使用公钥校验verify.txt文件，并对补丁文件patch.jar中的所有文件做SHA1校验，在校验通过的情况下，应用客户端加载该补丁文件patch.jar以进行更新。需要说明的是，SHA1算法为现有技术中的成熟算法，本发明实施例对其不做具体限定，此处也不再赘述。
作为一种可选的实施例，应用客户端在检测到存在补丁文件之后，且在应用客户端运行的过程中加载补丁文件之前，该可选实施例还可以包括：步骤S1072，应用客户端判断补丁文件与当前版本文件是否匹配；步骤S108在应用客户端运行的过程中加载补丁文件包括：步骤S1083，在补丁文件与当前版本文件匹配时，应用客户端加载补丁文件。
需要说明的是，应用客户端在检测到存在补丁文件之后，该应用客户端可以判断检测到的补丁文件与当前版本文件是否匹配，需要说明的是，该应用客户端对检测补丁文件与当前版本文件是否匹配的内容不做具体限定，其可以为检测补丁文件是否为该应用当前版本文件的更新文件等，此处不再一一举例说明。该应用客户端通过判断补丁文件与当前版本文件是否匹配，能够保证应用客户端可以实现准确更新，避免应用客户端更新到错误版本。当补丁文件与当前版本文件匹配时，该应用客户端可以加载 该补丁文件，以便于对应用客户端进行更新。该应用客户端通过在检测到存在补丁文件之后，判断该补丁文件是否与当前版本文件匹配，能够提高应用客户端更新的准确度，进而提高更新后的应用客户端的性能。
本发明还提供了一种优选实施例，图6是根据本发明实施例的一种优选的应用更新方法的流程图，如图6所示，该优选实施例可以包括以下步骤：
步骤S601，应用客户端被启动。
步骤S602，检测应用客户端本地是否存在补丁文件。其中，若存在，则执行步骤S603；若不存在，则执行步骤S607。
步骤S603，判断本地存在的补丁文件与该应用客户端当前版本文件是否匹配。其中，若匹配，则执行步骤S604；若不匹配，则执行步骤S607。
步骤S604，对本地补丁文件进行安全校验。
步骤S605，判断安全校验是否通过。其中，若通过，则执行步骤S606；若不通过，则执行步骤S607。
步骤S606，加载本地的补丁文件。
步骤S607，完成应用客户端的初始化。
步骤S608，拉取通信协议从应用服务器获取远程的补丁文件。
步骤S609，判断远程的补丁文件是否与该应用客户端当前版本文件是否匹配。其中，若匹配，则执行步骤S610；若不匹配，则结束。
步骤S610，下载远程的补丁文件。
步骤S611，判断是否需要强制重启该应用客户端。其中，若需要强制启动，则执行步骤S612；若不需要强制重启，则执行步骤S615。
步骤S612，对远程的补丁文件进行安全校验。
步骤S613，判断安全校验是否通过。其中，若通过，则执行步骤S614； 若不通过，则结束。
步骤S614，重启应用客户端，跳转执行步骤S601。
步骤S615，等待下次重启应用客户端。
上述步骤可以概括为：应用客户端应用每次启动时，会检测本地是否存在有效的补丁文件(patch.jar)，如果没有，则按正常的流程完成初始化，此时应用客户端的版本为初始版本。在完成启动后，通过与应用服务器的通信协议获取应用客户端的更新信息，如果存在新版本信息，则下载相应的补丁文件，并可通过后台设置是否需要打断用户操作强制重启升级，还是等待下次重启的机会静默升级。当应用客户端被再次启动时(此时应用客户端当前版本号依旧为旧版本号)，会检测到本地存在新的补丁文件，在对补丁文件进行RSA+SHA1安全性校验后，加载该补丁文件，版本号升级到新版本号，完成应用客户端的版本升级。
本发明实施例中的应用客户端可以为能够在Android系统下运行的应用，也可以为在IOS系统下运行的应用。而且，本发明实施例不仅适用于Java类文件，还可以适用于xml资源文件、库文件等的升级。以Android系统为例，本发明实施例基于Android MultiDex分包方案，一般情况下Android应用客户端都包含一个有Java类编译而成的dex文件，MultiDex即将一个dex文件拆分成两个或者多个(例如classes.dex、classes1.dex...)，在Android应用客户端启动的时候，会进行MultiDex的检查，并通过DexClassLoader依次加载各个dex文件。
在本发明实施例中，利用Android MultiDex分包原理，将需要动态更新的Java类编译到一个单独的dex中并生成更新包，在Android应用客户端启动的阶段，进行更新包的检测，如果存在更新包，则通过DexClassLoader加载，以达到动态更新的目的，减少了应用客户端更新时间和流量消耗，极大地极高了更新效率。
需要说明的是，由于Android虚拟机在应用客户端Apk被安装的时候， 会为类加上校验标签，从而导致两个相关联的类在不同的dex文件中就会报错。为了防止类被加上校验标签，达到通过dex文件动态更新应用客户端的目的，本发明实施例可以在项目编译后的所有java class文件的构造方法中插入以下几行代码：
If(AntiVerifyConfig.DO_VERIFY_CLASSES){
AntiLazyLoad.foo()；}
需要说明的是，对于前述的各方法实施例，为了简单描述，故将其都表述为一系列的动作组合，但是本领域技术人员应该知悉，本发明并不受所描述的动作顺序的限制，因为依据本发明，某些步骤可以采用其他顺序或者同时进行。其次，本领域技术人员也应该知悉，说明书中所描述的实施例均属于优选实施例，所涉及的动作和模块并不一定是本发明所必须的。
通过以上的实施方式的描述，本领域的技术人员可以清楚地了解到根据上述实施例的方法可借助软件加必需的通用硬件平台的方式来实现，当然也可以通过硬件，但很多情况下前者是更佳的实施方式。基于这样的理解，本发明的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质(如ROM/RAM、磁碟、光盘)中，包括若干指令用以使得一台终端设备(可以是手机，计算机，服务器，或者网络设备等)执行本发明各个实施例所述的方法。
实施例2
根据本发明实施例，提供了一种应用更新方法的方法实施例。
可选地，在本实施例中，上述应用更新方法也可以应用于如图1所示的由服务器102和终端104所构成的硬件环境中。本发明实施例的应用更新方法可以由服务器102来执行，也可以由终端104来执行，还可以是由服务器102和终端104共同执行。其中，终端104执行本发明实施例的应用更新方法也可以是由安装在其上的应用客户端来执行。
图7是根据本发明实施例的另一种可选的应用更新方法的流程图，如图7所示，该方法可以包括以下步骤：
步骤S202，在应用客户端被启动时检测是否存在应用客户端的补丁文件，其中，补丁文件为根据应用客户端的更新版本文件与当前版本文件之间存在差异的类文件而生成的文件；
步骤S204，在检测到存在补丁文件时，在应用客户端运行的过程中加载补丁文件，以便对应用客户端进行更新。
通过上述步骤S202至步骤S204，通过在应用客户端被启动时检测是否存在根据应用客户端的更新版本文件与当前版本文件之间存在差异的类文件而生成的补丁文件，并在检测到存在上述补丁文件时，通过在应用客户端运行的过程中加载补丁文件实现对应用客户端进行更新，达到了无需中断用户当前操作亦可以实现应用客户端更新的目的，进而解决了相关技术中应用更新时需要中断用户当前操作进入安装界面导致降低应用更新效率的技术问题，实现了提高应用更新效率的技术效果。
在步骤S202提供的技术方案中，本发明实施例对应用客户端的类型不做具体限定，其可以是安装在客户端或者服务器中的任意类型的应用客户端，比如，即时通信类应用客户端等。本发明实施例中应用客户端在被启动时运行的版本文件为当前版本文件，在应用客户端启动并运行当前版本文件的过程中，可以实时检测是否存在该应用客户端的补丁文件，其中，补丁文件可以为根据应用客户端的更新版本文件与当前版本文件之间存在差异的类文件而生成的文件，需要说明的是，应用客户端的当前版本文件可以为该应用客户端启动并正在运行的版本文件，更新版本文件可以为该应用客户端运行的当前版本文件的版本升级文件。比如，应用客户端启动并运行的当前版本文件为V1.0，则该应用客户端的更新版本文件可以为V2.0。还需要说明的是，更新版本文件可以为对当前版本文件中的一个或者多个类文件进行更新后得到的版本文件，则相应地更新版本文件与当前版本文件之间可以存在一个或者多个差异的类文件，本发明实施例可以将 这些差异的类文件生成一个或者多个补丁文件，利用这些补丁文件可以对应用客户端进行更新。需要说明的是，在应用客户端被启动时检测到的应用客户端的补丁文件可以是一个，也可以是多个。
在实际应用客户端场景中，根据应用客户端的更新版本文件与当前版本文件之间存在差异的类文件生成文件补丁文件的具体过程可以如图3所示，需要说明的是，图3所示中的Project v1.0为应用客户端的当前版本文件，其内包括有A.class、B.class、C.class、D.class等类文件。Project v2.0为应用客户端的更新版本文件，其内也包括有A.class、B.class、C.class、D.class等类文件，假设更新版本文件Project v2.0发生过修改的类文件为B.class、D.class，如图3所示虚线框所示。通过比对应用客户端的更新版本文件Project v2.0与应用客户端的当前版本文件Project v1.0之间存在差异的类文件，得到存在差异的类文件Path内包括有B.class、D.class，则可以将这些类文件单独生成dex文件，并将其打包成补丁文件patch.jar。
在步骤S204提供的技术方案中，如果在应用客户端被启动时检测到存在一个或者多个补丁文件时，本发明实施例可以在应用客户端运行过程中加载这些补丁文件，以实现对其进行更新的目的。需要说明的是，本发明实施例在运行当前版本文件的过程中，通过加载用于更新应用客户端的补丁文件，可以实现在运行当前版本过程中即可以完成对该应用客户端的更新，从而达到了在应用客户端运行过程中无需中断用户当前操作亦可以实现应用客户端进行更新的目的，进而解决了相关技术中应用更新时需要中断用户当前操作进入安装界面导致降低应用更新效率的技术问题，实现了提高应用客户端更新效率的技术效果。
作为一种可选的实施例，步骤S204在应用客户端运行的过程中加载补丁文件可以包括：步骤S2041，将补丁文件排列在当前版本文件中的相关文件的前面，以使得在补丁文件的第一类文件和相关文件的第二类文件具有相同名称时第一类文件被调用，而第二类文件不被调用。
需要说明的是，应用客户端的当前版本文件中的相关文件可以包括但 并不限于应用客户端运行过程所需的类文件，相关文件的个数可以是一个，也可以是多个。该可选实施例中补丁文件的第一类文件与相关文件的第二类文件可以具有相同名称，如图4所示，补丁文件patch.dex的第一类文件名称为Foo.class，相关文件class.dex的第二类文件名称也为Foo.class，即补丁文件patch.dex的第一类文件与相关文件class.dex的第二类文件具有相同名称，则此时该可选实施例可以将补丁文件patch.dex排列在当前版本文件中的相关文件class.dex的前面，如图4所示图左为前面。当补丁文件的第一类文件和相关文件的第二类文件具有相同名称时，该可选实施例通过将补丁文件排列在相关文件的前面，可以使得应用客户端运行过程中加载补丁文件时补丁文件的第一类文件被调用，而相关文件的第二类文件不被调用。相关文件的第二类文件可以理解为应用客户端当前版本文件中的类文件，补丁文件的第一类文件可以理解为应用客户端的更新版本文件中相对于当前版本文件发生过修改的类文件，两者具有相同名称，该可选实施例通过调用补丁文件的第一类文件，而不调用相关文件的第二类文件，可以达到在应用客户端以当前版本文件运行过程对应用客户端进行更新的目的，进而达到了提高应用更新效率的效果。
在实际应用场景中，在应用客户端被启动时，如果检测到存在有效的补丁文件，则可以通过DexClassLoader的方式加载检测到的补丁文件。一个DexClassLoader可以包含多个dex文件，每个dex文件是一个Element，多个dex文件排列成一个有序的数组dexElements，当找类的时候，会按顺序遍历dex文件。如果在不同的dex中有相同的类存在，那么会优先选择排在前面的dex文件的类。因此只需要把需要更新的类打包到一个dex(例如图4所示的patch.dex)中去，然后把这个dex插入到Elements的最前面，则可实现类的动态更新升级。
作为一种可选的实施例，在步骤S204之后，也即在应用客户端运行的过程中加载补丁文件之后，该可选实施例还可以包括：步骤S2061，在应用客户端接收到调用具有相同名称的类文件时，检测到补丁文件排列在相关文件的前面、且补丁文件的第一类文件和相关文件的第二类文件具有 相同名称，调用第一类文件，而不调用第二类文件。
需要说明的是，在应用客户端运行的过程中加载补丁文件之后，该应用客户端可以实时检测是否接收到调用具有相同名称的类文件的指令，在接收到调用具有相同名称的类文件的指令时，该应用客户端还可以检测具有相同名称的类文件的位置关系，当检测到补丁文件排列在相关文件的前面、且补丁文件的第一类文件和相关文件的第二类文件具有相同名称时，如图4所示的情况，该可选实施例可以调用第一类文件，而不调用第二类文件。
该可选实施例通过在检测到补丁文件排列在相关文件的前面、且补丁文件的第一类文件和相关文件的第二类文件具有相同名称时，调用第一类文件，而不调用第二类文件。相关文件的第二类文件可以理解为应用客户端当前版本文件中的类文件，补丁文件的第一类文件可以理解为应用客户端的更新版本文件中相对于当前版本文件发生过修改的类文件，两者具有相同名称，该可选实施例通过调用补丁文件的第一类文件，而不调用相关文件的第二类文件，可以达到在应用客户端以当前版本文件运行过程对应用客户端进行更新的目的，进而解决了相关技术中应用更新时需要中断用户当前操作进入安装界面导致降低应用更新效率的技术问题，达到了提高应用更新效率的效果。
作为一种可选的实施例，在未检测到补丁文件时，或者，在应用客户端运行的过程中加载补丁文件之后，该可选实施例还可以包括以下步骤：
步骤S2062，向应用服务器请求是否存在应用客户端最新的补丁文件；
步骤S2064，若存在最新的补丁文件，则从应用服务器获取最新的补丁文件；
步骤S2066，在应用客户端被再次启动之后加载最新的补丁文件，以便对应用客户端进行更新。
需要说明的是，在应用客户端被启动时检测是否存在补丁文件可以为 检测应用客户端本地是否补丁文件，若本地不存在补丁文件，则该可选实施例可以向应用服务器请求该应用客户端的最新的补丁文件，其中，应用服务器可以对该应用客户端进行支持和维护。或者，当应用客户端被启动时检测到本地存在补丁文件，在应用客户端过程中加载检测到的补丁文件后，该应用客户端还可以向应用服务器请求该应用客户端的最新的版本文件，此处需要说明的是，应用客户端运行过程中加载的本地补丁文件可能不是最新版本的，也即在加载补丁文件过程中应用服务器可能又向应用客户端发布了该应用客户端的更新版本文件，则该可选实施例也可以向服务器请求该应用客户端的最新的补丁文件，以达到对应用客户端进行更新的目的。当应用服务器中存在最新的补丁文件时，该应用客户端可以从应用服务器中获取该最新的补丁文件，并在该应用客户端被再次启动之后，在该应用客户端的运行的过程中可以加载该最新的补丁文件，以便对该应用客户端进行更新。
该可选实施例通过从应用服务器中请求应用客户端的最新的补丁文件，并在应用客户端运行过程中加载该最新的补丁文件，能够保证使得应用客户端在运行过程中更新至最新版本，进而达到提高应用更新效率的效果。
作为一种可选的实施例，在检测到存在补丁文件之后，且在应用客户端运行的过程中加载补丁文件之前，该可选实施例还可以包括：步骤S2031，应用客户端对补丁文件进行安全校验；步骤S204在应用客户端运行的过程中加载补丁文件可以包括：步骤S2042，在安全校验通过时，在应用客户端运行的过程中加载补丁文件。
需要说明的是，在检测到存在补丁文件之后，该应用客户端可以对该检测到的补丁文件进行安全校验，以保证应用客户端运行过程中加载的补丁文件为安全可靠的文件，进而能够提高应用客户端的安全性和可靠性。需要说明的是，该可选实施例对应用客户端对补丁文件进行安全校验的具体内容不做具体限定，其可以是包括但并不限于校验补丁文件是否包含疑 似病毒文件等，此处不再一一举例说明。在检测到存在补丁文件，且对补丁文件进行安全校验通过时，该可选实施例可以在应用客户端运行过程中加载该补丁文件，以便于实现对应用客户端进行更新的目的。
在实际应用场景中，由于补丁文件是以jar文件的形式下载并存储在应用客户端本地或者应用服务器中，存在可能被篡改从而达到破坏补丁文件的目的。因此，当客户端在检测到存在补丁文件，并在下载完成以及每次加载时，可以通过RSA签名+SHA1校验的机制，来确保缓存的补丁文件中的数据不被篡改。如图5所示，应用服务器发布补丁文件并申请对补丁文件进行安全校验，具体地，可以首先对补丁文件patch.jar中的所有文件class.dex、version.txt等做SHA1计算，生成verify.txt文件；然后使用私钥对verify.txt签名，生成verify.signature文件。应用客户端可以从应用服务器下载补丁文件patch.jar，并将其存储在本地。在加载补丁文件patch.jar之前可以使用公钥校验verify.txt文件，并对补丁文件patch.jar中的所有文件做SHA1校验，在校验通过的情况下，应用客户端加载该补丁文件patch.jar，以实现对应用客户端进行更新。需要说明的是，SHA1算法为现有技术中的成熟算法，本发明实施例对其不做具体限定，此处也不再赘述。
作为一种可选的实施例，在检测到存在补丁文件之后，且在应用客户端运行的过程中加载补丁文件之前，该可选实施例还可以包括：步骤S2032，应用客户端判断补丁文件与当前版本文件是否匹配；步骤S204在应用客户端运行的过程中加载补丁文件包括：步骤S2043，在补丁文件与当前版本文件匹配时，加载补丁文件。
需要说明的是，在检测到存在补丁文件之后，该应用客户端可以判断检测到的补丁文件与当前版本文件是否匹配，需要说明的是，该可选实施例对应用客户端检测补丁文件与当前版本文件是否匹配的内容不做具体限定，其可以为检测补丁文件是否为该应用客户端当前版本文件的更新文件等，此处不再一一举例说明。该可选实施例通过判断补丁文件与当前 版本文件是否匹配，能够保证应用客户端可以实现准确更新，避免应用客户端更新到错误版本。当补丁文件与当前版本文件匹配时，该可选实施例可以加载该补丁文件，以便于对应用客户端进行更新。该可选实施例通过在检测到存在补丁文件之后，判断该补丁文件是否与当前版本文件匹配，能够提高应用客户端更新的准确度，进而提高更新后的应用客户端的性能。
需要说明的是，对于前述的各方法实施例，为了简单描述，故将其都表述为一系列的动作组合，但是本领域技术人员应该知悉，本发明并不受所描述的动作顺序的限制，因为依据本发明，某些步骤可以采用其他顺序或者同时进行。其次，本领域技术人员也应该知悉，说明书中所描述的实施例均属于优选实施例，所涉及的动作和模块并不一定是本发明所必须的。
通过以上的实施方式的描述，本领域的技术人员可以清楚地了解到根据上述实施例的方法可借助软件加必需的通用硬件平台的方式来实现，当然也可以通过硬件，但很多情况下前者是更佳的实施方式。基于这样的理解，本发明的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质(如ROM/RAM、磁碟、光盘)中，包括若干指令用以使得一台终端设备(可以是手机，计算机，服务器，或者网络设备等)执行本发明各个实施例所述的方法。
实施例3
根据本发明实施例，还提供了一种用于实施本发明实施例1中的应用更新方法的应用更新装置。图8是根据本发明实施例的一种可选的应用更新装置的示意图，如图8所示，该装置可以包括：
生成单元12，用于应用服务器根据应用客户端的更新版本文件与当前版本文件之间存在差异的类文件生成补丁文件；发送单元14，用于应用服务器将生成的补丁文件发送至应用客户端；检测单元16，用于应用客户端在被启动时检测是否存在补丁文件；以及第一加载单元18，用于应用客户端在检测到存在补丁文件时，在应用客户端运行的过程中加载补丁文件， 以便对应用客户端进行更新。
需要说明的是，该实施例中的生成单元12可以用于执行本申请实施例1中的步骤S102，该实施例中的发送单元14可以用于执行本申请实施例1中的步骤S104，该实施例中的检测单元16可以用于执行本申请实施例1中的步骤S106，该实施例中的第一加载单元18可以用于执行本申请实施例1中的步骤S108。
此处需要说明的是，上述模块与对应的步骤所实现的示例和应用场景相同，但不限于上述实施例1所公开的内容。需要说明的是，上述模块作为装置的一部分可以运行在如图1所示的硬件环境中，可以通过软件实现，也可以通过硬件实现，其中，硬件环境包括网络环境。
作为一种可选的实施例，图9是根据本发明实施例的另一种可选的应用更新装置的示意图，如图9所示，生成单元12可以包括：获取模块122，用于应用服务器获取应用客户端的更新版本文件和当前版本文件；比对模块124，用于比对应用客户端的更新版本文件和当前版本文件，获取应用客户端的更新版本文件和当前版本文件之间存在差异的类文件；以及打包模块126，用于将类文件打包成补丁文件。
需要说明的是，该实施例中的获取模块122可以用于执行本申请实施例1中的步骤S1022，该实施例中的比对模块124可以用于执行本申请实施例1中的步骤S1024，该实施例中的打包模块126可以用于执行本申请实施例1中的步骤S1026。
此处需要说明的是，上述模块与对应的步骤所实现的示例和应用场景相同，但不限于上述实施例1所公开的内容。需要说明的是，上述模块作为装置的一部分可以运行在如图1所示的硬件环境中，可以通过软件实现，也可以通过硬件实现，其中，硬件环境包括网络环境。
作为一种可选的实施例，图10是根据本发明实施例的另一种可选的应用更新装置的示意图，如图10所示，第一加载单元18可以包括：排列 模块181，用于应用客户端将补丁文件排列在当前版本文件中的相关文件的前面，以使得在补丁文件的第一类文件和相关文件的第二类文件具有相同名称时第一类文件被调用，而第二类文件不被调用。
需要说明的是，该实施例中的排列模块181可以用于执行本申请实施例1中的步骤S1081。此处需要说明的是，该模块与对应的步骤所实现的示例和应用场景相同，但不限于上述实施例1所公开的内容。需要说明的是，该模块作为装置的一部分可以运行在如图1所示的硬件环境中，可以通过软件实现，也可以通过硬件实现，其中，硬件环境包括网络环境。
作为一种可选的实施例，图11是根据本发明实施例的另一种可选的应用更新装置的示意图，如图11所示，该可选实施例还可以包括：调用单元1101，用于应用客户端在应用客户端运行的过程中加载补丁文件之后，应用客户端在接收到调用具有相同名称的类文件时，检测到补丁文件排列在相关文件的前面、且补丁文件的第一类文件和相关文件的第二类文件具有相同名称，调用第一类文件，而不调用第二类文件。
需要说明的是，该实施例中的调用单元1101可以用于执行本申请实施例1中的步骤S1101。此处需要说明的是，该模块与对应的步骤所实现的示例和应用场景相同，但不限于上述实施例1所公开的内容。需要说明的是，该模块作为装置的一部分可以运行在如图1所示的硬件环境中，可以通过软件实现，也可以通过硬件实现，其中，硬件环境包括网络环境。
作为一种可选的实施例，图12是根据本发明实施例的另一种可选的应用更新装置的示意图，如图12所示，该可选实施例还可以包括：请求单元1102，用于应用客户端在未检测到补丁文件时或者在应用客户端运行的过程中加载补丁文件之后，应用客户端向应用服务器请求是否存在应用最新的补丁文件；获取单元1104，用于若存在最新的补丁文件，应用客户端则从应用服务器获取最新的补丁文件；第二加载单元1106，用于应用客户端在应用客户端被再次启动之后加载最新的补丁文件，以便对应用客户端进行更新。
需要说明的是，该实施例中的请求单元1102可以用于执行本申请实施例1中的步骤S1102，该实施例中的获取单元1104可以用于执行本申请实施例1中的步骤S1104，该实施例中的第二加载单元1106可以用于执行本申请实施例1中的步骤S1106。
此处需要说明的是，上述模块与对应的步骤所实现的示例和应用场景相同，但不限于上述实施例1所公开的内容。需要说明的是，上述模块作为装置的一部分可以运行在如图1所示的硬件环境中，可以通过软件实现，也可以通过硬件实现，其中，硬件环境包括网络环境。
作为一种可选的实施例，图13是根据本发明实施例的另一种可选的应用更新装置的示意图，如图13所示，该可选实施例还可以包括：校验单元171，用于应用客户端在检测到存在补丁文件之后，且在应用客户端运行的过程中加载补丁文件之前，应用客户端对补丁文件进行安全校验；第一加载单元18包括：第一加载模块182，用于在安全校验通过时，应用客户端在应用客户端运行的过程中加载补丁文件。
需要说明的是，该实施例中的校验单元171可以用于执行本申请实施例1中的步骤S1071，该实施例中的第一加载模块182可以用于执行本申请实施例1中的步骤S1082。
此处需要说明的是，上述模块与对应的步骤所实现的示例和应用场景相同，但不限于上述实施例1所公开的内容。需要说明的是，上述模块作为装置的一部分可以运行在如图1所示的硬件环境中，可以通过软件实现，也可以通过硬件实现，其中，硬件环境包括网络环境。
作为一种可选的实施例，图14是根据本发明实施例的另一种可选的应用更新装置的示意图，如图14所示，该可选实施例还可以包括：判断单元172，用于应用客户端在检测到存在补丁文件之后，且在应用客户端运行的过程中加载补丁文件之前，应用客户端判断补丁文件与当前版本文件是否匹配；第一加载单元18包括：第二加载模块183，用于在补丁文件与当前版本文件匹配时，应用客户端加载补丁文件。
需要说明的是，该实施例中的判断单元172可以用于执行本申请实施例1中的步骤S1072，该实施例中的第二加载模块183可以用于执行本申请实施例1中的步骤S1083。
此处需要说明的是，上述模块与对应的步骤所实现的示例和应用场景相同，但不限于上述实施例1所公开的内容。需要说明的是，上述模块作为装置的一部分可以运行在如图1所示的硬件环境中，可以通过软件实现，也可以通过硬件实现，其中，硬件环境包括网络环境。
通过上述模块，可以解决了相关技术中应用更新时需要中断用户当前操作进入安装界面导致降低应用更新效率的技术问题，进而达到提高应用更新效率的技术效果。
实施例4
根据本发明实施例，还提供了一种用于实施本发明实施例2中的应用更新方法的应用更新装置。图15是根据本发明实施例的一种可选的应用更新装置的示意图，如图15所示，该装置可以包括：
检测单元22，用于在应用被启动时检测是否存在应用的补丁文件，其中，补丁文件为根据应用的更新版本文件与当前版本文件之间存在差异的类文件而生成的文件；以及第一加载单元24，用于在检测到存在补丁文件时，在应用运行的过程中加载补丁文件，以便对应用进行更新。
需要说明的是，该实施例中的检测单元22可以用于执行本申请实施例1中的步骤S202，该实施例中的第一加载单元24可以用于执行本申请实施例1中的步骤S204。
此处需要说明的是，上述模块与对应的步骤所实现的示例和应用场景相同，但不限于上述实施例2所公开的内容。需要说明的是，上述模块作为装置的一部分可以运行在如图1所示的硬件环境中，可以通过软件实现，也可以通过硬件实现，其中，硬件环境包括网络环境。
作为一种可选的实施例，图16是根据本发明实施例的另一种可选的 应用更新装置的示意图，如图16所示，第一加载单元24可以包括：排列模块241，用于将补丁文件排列在当前版本文件中的相关文件的前面，以使得在补丁文件的第一类文件和相关文件的第二类文件具有相同名称时第一类文件被调用，而第二类文件不被调用。
需要说明的是，该实施例中的排列模块241可以用于执行本申请实施例1中的步骤S2041。此处需要说明的是，上述模块与对应的步骤所实现的示例和应用场景相同，但不限于上述实施例2所公开的内容。需要说明的是，上述模块作为装置的一部分可以运行在如图1所示的硬件环境中，可以通过软件实现，也可以通过硬件实现，其中，硬件环境包括网络环境。
作为一种可选的实施例，图17是根据本发明实施例的另一种可选的应用更新装置的示意图，如图17所示，该可选实施例还可以包括：调用单元261，用于在应用运行的过程中加载补丁文件之后，在应用接收到调用具有相同名称的类文件时，检测到补丁文件排列在相关文件的前面、且补丁文件的第一类文件和相关文件的第二类文件具有相同名称，调用第一类文件，而不调用第二类文件。
需要说明的是，该实施例中的调用单元261可以用于执行本申请实施例1中的步骤S2061。此处需要说明的是，上述模块与对应的步骤所实现的示例和应用场景相同，但不限于上述实施例2所公开的内容。需要说明的是，上述模块作为装置的一部分可以运行在如图1所示的硬件环境中，可以通过软件实现，也可以通过硬件实现，其中，硬件环境包括网络环境。
作为一种可选的实施例，图18是根据本发明实施例的另一种可选的应用更新装置的示意图，如图18所示，该可选实施例还可以包括：请求单元262，用于在未检测到补丁文件时或者在应用运行的过程中加载补丁文件之后，向服务器请求是否存在应用最新的补丁文件；获取单元264，用于在存在最新的补丁文件，则从服务器获取最新的补丁文件；第二加载单元266，用于在应用被再次启动之后加载最新的补丁文件，以便对应用进行更新。
需要说明的是，该实施例中的请求单元262可以用于执行本申请实施例1中的步骤S2062，该实施例中的获取单元264可以用于执行本申请实施例1中的步骤S2064，该实施例中的第二加载单元266可以用于执行本申请实施例1中的步骤S2066。
此处需要说明的是，上述模块与对应的步骤所实现的示例和应用场景相同，但不限于上述实施例2所公开的内容。需要说明的是，上述模块作为装置的一部分可以运行在如图1所示的硬件环境中，可以通过软件实现，也可以通过硬件实现，其中，硬件环境包括网络环境。
作为一种可选的实施例，图19是根据本发明实施例的另一种可选的应用更新装置的示意图，如图19所示，该可选实施例还可以包括：校验单元231，用于在检测到存在补丁文件之后，且在应用运行的过程中加载补丁文件之前，对补丁文件进行安全校验。其中，第一加载单元24可以包括：第一加载模块242，用于在安全校验通过时，在应用运行的过程中加载补丁文件。
需要说明的是，该实施例中的校验单元231可以用于执行本申请实施例1中的步骤S2031，该实施例中的第一加载模块242可以用于执行本申请实施例1中的步骤S2042。此处需要说明的是，上述模块与对应的步骤所实现的示例和应用场景相同，但不限于上述实施例2所公开的内容。需要说明的是，上述模块作为装置的一部分可以运行在如图1所示的硬件环境中，可以通过软件实现，也可以通过硬件实现，其中，硬件环境包括网络环境。
作为一种可选的实施例，图20是根据本发明实施例的另一种可选的应用更新装置的示意图，如图20所示，该可选实施例还可以包括：判断单元232，用于在检测到存在补丁文件之后，且在应用运行的过程中加载补丁文件之前，判断补丁文件与当前版本文件是否匹配。其中，第一加载单元24可以包括：第二加载模块243，用于在补丁文件与当前版本文件匹配时，加载补丁文件。
需要说明的是，该实施例中的判断单元232可以用于执行本申请实施例1中的步骤S2032，该实施例中的第二加载模块243可以用于执行本申请实施例1中的步骤S2043。
此处需要说明的是，上述模块与对应的步骤所实现的示例和应用场景相同，但不限于上述实施例2所公开的内容。需要说明的是，上述模块作为装置的一部分可以运行在如图1所示的硬件环境中，可以通过软件实现，也可以通过硬件实现，其中，硬件环境包括网络环境。
通过上述模块，可以解决了相关技术中应用更新时需要中断用户当前操作进入安装界面导致降低应用更新效率的技术问题，进而达到提高应用更新效率的技术效果。
实施例5
根据本发明实施例，还提供了一种用于实施上述应用更新方法的终端。
图21是根据本发明实施例的一种终端的结构框图，如图21所示，该终端可以包括：一个或多个(图中仅示出一个)处理器201、存储器203、以及传输装置205，如图21所示，该终端还可以包括输入输出设备207。
其中，存储器203可用于存储软件程序以及模块，如本发明实施例中的应用更新方法和装置对应的程序指令/模块，处理器201通过运行存储在存储器203内的软件程序以及模块，从而执行各种功能应用以及数据处理，即实现上述的应用更新方法。存储器203可包括高速随机存储器，还可以包括非易失性存储器，如一个或者多个磁性存储装置、闪存、或者其他非易失性固态存储器。在一些实例中，存储器203可进一步包括相对于处理器201远程设置的存储器，这些远程存储器可以通过网络连接至终端。上述网络的实例包括但不限于互联网、企业内部网、局域网、移动通信网及其组合。
上述的传输装置205用于经由一个网络接收或者发送数据，还可以用于处理器与存储器之间的数据传输。上述的网络具体实例可包括有线网络 及无线网络。在一个实例中，传输装置205包括一个网络适配器(Network Interface Controller，NIC)，其可通过网线与其他网络设备与路由器相连从而可与互联网或局域网进行通讯。在一个实例中，传输装置205为射频(Radio Frequency，RF)模块，其用于通过无线方式与互联网进行通讯。
其中，具体地，存储器203用于存储应用程序。
处理器201可以通过传输装置205调用存储器203存储的应用程序，以执行下述步骤：应用服务器根据应用客户端的更新版本文件与当前版本文件之间存在差异的类文件生成补丁文件；应用服务器将生成的补丁文件发送至应用客户端；应用客户端在应用客户端被启动时检测是否存在补丁文件；以及应用客户端在检测到存在补丁文件时，在应用客户端运行的过程中加载补丁文件，以便对应用客户端进行更新。
处理器201还用于执行下述步骤：应用服务器获取应用的更新版本文件和当前版本文件；比对应用的更新版本文件和当前版本文件，获取应用的更新版本文件和当前版本文件之间存在差异的类文件；以及将类文件打包成补丁文件。
处理器201还用于执行下述步骤：应用客户端将补丁文件排列在当前版本文件中的相关文件的前面，以使得在补丁文件的第一类文件和相关文件的第二类文件具有相同名称时第一类文件被调用，而第二类文件不被调用。
处理器201还用于执行下述步骤：应用客户端在应用运行的过程中加载补丁文件之后，应用客户端在应用接收到调用具有相同名称的类文件时，检测到补丁文件排列在相关文件的前面、且补丁文件的第一类文件和相关文件的第二类文件具有相同名称，调用第一类文件，而不调用第二类文件。
处理器201还用于执行下述步骤：应用客户端在未检测到补丁文件时或者在应用运行的过程中加载补丁文件之后，应用客户端向应用服务器请求是否存在应用最新的补丁文件；若存在最新的补丁文件，应用客户端则 从应用服务器获取最新的补丁文件；应用客户端在应用被再次启动之后加载最新的补丁文件，以便对应用进行更新。
处理器201还用于执行下述步骤：应用客户端在检测到存在补丁文件之后，且在应用运行的过程中加载补丁文件之前，应用客户端对补丁文件进行安全校验；应用客户端在应用运行的过程中加载补丁文件包括：在安全校验通过时，应用客户端在应用运行的过程中加载补丁文件。
处理器201还用于执行下述步骤：应用客户端在检测到存在补丁文件之后，且在应用运行的过程中加载补丁文件之前，应用客户端判断补丁文件与当前版本文件是否匹配；应用客户端在应用运行的过程中加载补丁文件包括：在补丁文件与当前版本文件匹配时，应用客户端加载补丁文件。
采用本发明实施例，提供了一种应用更新的方案。通过在应用客户端被启动时检测是否存在根据应用客户端的更新版本文件与当前版本文件之间存在差异的类文件而生成的补丁文件，并在检测到存在上述补丁文件时，通过在应用客户端运行的过程中加载补丁文件实现对应用客户端进行更新，达到了无需中断用户当前操作亦可以实现应用客户端更新的目的，从而实现了提高应用客户端更新效率的技术效果，进而解决了相关技术中应用更新时需要中断用户当前操作进入安装界面导致降低应用更新效率的技术问题。
可选地，本实施例中的具体示例可以参考上述实施例1至实施例4中所描述的示例，本实施例在此不再赘述。
本领域普通技术人员可以理解，图21所示的结构仅为示意，终端可以是智能手机(如Android手机、iOS手机等)、平板电脑、掌上电脑以及移动互联网设备(Mobile Internet Devices，MID)、PAD等终端设备。图21其并不对上述电子装置的结构造成限定。例如，终端还可包括比图21中所示更多或者更少的组件(如网络接口、显示装置等)，或者具有与图21所示不同的配置。
本领域普通技术人员可以理解上述实施例的各种方法中的全部或部分步骤是可以通过程序来指令终端设备相关的硬件来完成，该程序可以存储于一计算机可读存储介质中，存储介质可以包括：闪存盘、只读存储器(Read-Only Memory，ROM)、随机存取器(Random Access Memory，RAM)、磁盘或光盘等。
实施例6
本发明的实施例还提供了一种存储介质。可选地，在本实施例中，上述存储介质可以用于执行应用更新方法的程序代码。
可选地，在本实施例中，上述存储介质可以位于上述实施例所示的网络中的多个网络设备中的至少一个网络设备上。
可选地，在本实施例中，存储介质被设置为存储用于执行以下步骤的程序代码：
S1，应用服务器根据应用客户端的更新版本文件与当前版本文件之间存在差异的类文件生成补丁文件；
S2，应用服务器将生成的补丁文件发送至应用客户端；
S3，应用客户端在应用客户端被启动时检测是否存在补丁文件；
S4，应用客户端在检测到存在补丁文件时，在应用客户端运行的过程中加载补丁文件，以便对应用客户端进行更新。
可选地，存储介质还被设置为存储用于执行以下步骤的程序代码：应用服务器获取应用的更新版本文件和当前版本文件；比对应用的更新版本文件和当前版本文件，获取应用的更新版本文件和当前版本文件之间存在差异的类文件；以及将类文件打包成补丁文件。
可选地，存储介质还被设置为存储用于执行以下步骤的程序代码：应用客户端将补丁文件排列在当前版本文件中的相关文件的前面，以使得在补丁文件的第一类文件和相关文件的第二类文件具有相同名称时第一类 文件被调用，而第二类文件不被调用。
可选地，存储介质还被设置为存储用于执行以下步骤的程序代码：应用客户端在应用运行的过程中加载补丁文件之后，应用客户端在应用接收到调用具有相同名称的类文件时，检测到补丁文件排列在相关文件的前面、且补丁文件的第一类文件和相关文件的第二类文件具有相同名称，调用第一类文件，而不调用第二类文件。
可选地，存储介质还被设置为存储用于执行以下步骤的程序代码：应用客户端在未检测到补丁文件时或者在应用运行的过程中加载补丁文件之后，应用客户端向应用服务器请求是否存在应用最新的补丁文件；若存在最新的补丁文件，应用客户端则从应用服务器获取最新的补丁文件；应用客户端在应用被再次启动之后加载最新的补丁文件，以便对应用进行更新。
可选地，存储介质还被设置为存储用于执行以下步骤的程序代码：应用客户端在检测到存在补丁文件之后，且在应用运行的过程中加载补丁文件之前，应用客户端对补丁文件进行安全校验；应用客户端在应用运行的过程中加载补丁文件包括：在安全校验通过时，应用客户端在应用运行的过程中加载补丁文件。
可选地，存储介质还被设置为存储用于执行以下步骤的程序代码：应用客户端在检测到存在补丁文件之后，且在应用运行的过程中加载补丁文件之前，应用客户端判断补丁文件与当前版本文件是否匹配；应用客户端在应用运行的过程中加载补丁文件包括：在补丁文件与当前版本文件匹配时，应用客户端加载补丁文件。
可选地，本实施例中的具体示例可以参考上述实施例1至实施例4中所描述的示例，本实施例在此不再赘述。
可选地，在本实施例中，上述存储介质可以包括但不限于：U盘、只读存储器(ROM，Read-Only Memory)、随机存取存储器(RAM，Random  Access Memory)、移动硬盘、磁碟或者光盘等各种可以存储程序代码的介质。
上述本发明实施例序号仅仅为了描述，不代表实施例的优劣。
上述实施例中的集成的单元如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在上述计算机可读取的存储介质中。基于这样的理解，本发明的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的全部或部分可以以软件产品的形式体现出来，该计算机软件产品存储在存储介质中，包括若干指令用以使得一台或多台计算机设备(可为个人计算机、服务器或者网络设备等)执行本发明各个实施例所述方法的全部或部分步骤。
在本发明的上述实施例中，对各个实施例的描述都各有侧重，某个实施例中没有详述的部分，可以参见其他实施例的相关描述。
在本申请所提供的几个实施例中，应该理解到，所揭露的客户端，可通过其它的方式实现。其中，以上所描述的装置实施例仅仅是示意性的，例如所述单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，单元或模块的间接耦合或通信连接，可以是电性或其它的形式。
所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。
另外，在本发明各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现，也可以采用软 件功能单元的形式实现。
以上所述仅是本发明的优选实施方式，应当指出，对于本技术领域的普通技术人员来说，在不脱离本发明原理的前提下，还可以做出若干改进和润饰，这些改进和润饰也应视为本发明的保护范围。

Claims (26)

  1. 一种应用更新方法，其中，所述方法包括：
    应用服务器根据应用客户端的更新版本文件与当前版本文件之间存在差异的类文件生成补丁文件；
    所述应用服务器将生成的所述补丁文件发送至所述应用客户端；
    所述应用客户端在被启动时检测是否存在所述补丁文件；以及
    所述应用客户端在检测到存在所述补丁文件时，在所述应用客户端运行的过程中加载所述补丁文件，以便对所述应用客户端进行更新。
  2. 根据权利要求1所述的方法，其中，应用服务器根据应用客户端的更新版本文件与当前版本文件之间存在差异的类文件生成补丁文件包括：
    所述应用服务器获取所述应用客户端的更新版本文件和当前版本文件；
    比对所述应用客户端的更新版本文件和当前版本文件，获取所述应用客户端的更新版本文件和当前版本文件之间存在差异的类文件；以及
    将所述类文件打包成所述补丁文件。
  3. 根据权利要求1所述的方法，其中，所述应用客户端在所述应用客户端运行的过程中加载所述补丁文件包括：
    所述应用客户端将所述补丁文件排列在所述当前版本文件中的相关文件的前面，以使得在所述补丁文件的第一类文件和所述相关文件的第二类文件具有相同名称时所述第一类文件被调用，而所述第二类文件不被调用。
  4. 根据权利要求3所述的方法，其中，所述应用客户端在所述应用客户端运行的过程中加载所述补丁文件之后，所述方法还包括：
    所述应用客户端在接收到调用具有所述相同名称的类文件时，检 测到所述补丁文件排列在所述相关文件的前面、且所述补丁文件的所述第一类文件和所述相关文件的所述第二类文件具有所述相同名称，调用所述第一类文件，而不调用所述第二类文件。
  5. 根据权利要求1所述的方法，其中，所述应用客户端在未检测到所述补丁文件时或者在所述应用客户端运行的过程中加载所述补丁文件之后，所述方法还包括：
    所述应用客户端向所述应用服务器请求是否存在所述应用最新的补丁文件；
    若存在所述最新的补丁文件，所述应用客户端则从所述应用服务器获取所述最新的补丁文件；
    所述应用客户端在所述应用客户端被再次启动之后加载所述最新的补丁文件，以便对所述应用客户端进行更新。
  6. 根据权利要求1所述的方法，其中，
    所述应用客户端在检测到存在所述补丁文件之后，且在所述应用客户端运行的过程中加载所述补丁文件之前，所述方法还包括：所述应用客户端对所述补丁文件进行安全校验；
    所述应用客户端在所述应用客户端运行的过程中加载所述补丁文件包括：在安全校验通过时，所述应用客户端在所述应用客户端运行的过程中加载所述补丁文件。
  7. 根据权利要求1所述的方法，其中，
    所述应用客户端在检测到存在所述补丁文件之后，且在所述应用客户端运行的过程中加载所述补丁文件之前，所述方法还包括：所述应用客户端判断所述补丁文件与所述当前版本文件是否匹配；
    所述应用客户端在所述应用客户端运行的过程中加载所述补丁文件包括：在所述补丁文件与所述当前版本文件匹配时，所述应用客户端加载所述补丁文件。
  8. 一种应用更新方法，其中，所述方法包括：
    在应用客户端被启动时检测是否存在所述应用客户端的补丁文件，其中，所述补丁文件为根据所述应用客户端的更新版本文件与当前版本文件之间存在差异的类文件而生成的文件；以及
    在检测到存在所述补丁文件时，在所述应用客户端运行的过程中加载所述补丁文件，以便对所述应用客户端进行更新。
  9. 根据权利要求8所述的方法，其中，在所述应用客户端运行的过程中加载所述补丁文件包括：
    将所述补丁文件排列在所述当前版本文件中的相关文件的前面，以使得在所述补丁文件的第一类文件和所述相关文件的第二类文件具有相同名称时所述第一类文件被调用，而所述第二类文件不被调用。
  10. 根据权利要求9所述的方法，其中，在所述应用客户端运行的过程中加载所述补丁文件之后，所述方法还包括：
    在所述应用客户端接收到调用具有所述相同名称的类文件时，检测到所述补丁文件排列在所述相关文件的前面、且所述补丁文件的所述第一类文件和所述相关文件的所述第二类文件具有所述相同名称，调用所述第一类文件，而不调用所述第二类文件。
  11. 根据权利要求8所述的方法，其中，在未检测到所述补丁文件时或者在所述应用客户端运行的过程中加载所述补丁文件之后，所述方法还包括：
    向应用服务器请求是否存在所述应用客户端最新的补丁文件；
    若存在所述最新的补丁文件，则从所述应用服务器获取所述最新的补丁文件；
    在所述应用客户端被再次启动之后加载所述最新的补丁文件，以便对所述应用客户端进行更新。
  12. 根据权利要求8所述的方法，其中，
    在检测到存在所述补丁文件之后，且在所述应用客户端运行的过 程中加载所述补丁文件之前，所述方法还包括：对所述补丁文件进行安全校验；
    在所述应用客户端运行的过程中加载所述补丁文件包括：在安全校验通过时，在所述应用客户端运行的过程中加载所述补丁文件。
  13. 根据权利要求8所述的方法，其中，
    在检测到存在所述补丁文件之后，且在所述应用客户端运行的过程中加载所述补丁文件之前，所述方法还包括：判断所述补丁文件与所述当前版本文件是否匹配；
    在所述应用客户端运行的过程中加载所述补丁文件包括：在所述补丁文件与所述当前版本文件匹配时，在所述应用客户端运行的过程中加载所述补丁文件。
  14. 一种应用更新装置，其中，所述装置包括：
    生成单元，被设置为应用服务器根据应用客户端的更新版本文件与当前版本文件之间存在差异的类文件生成补丁文件；
    发送单元，被设置为所述应用服务器将生成的所述补丁文件发送至所述应用客户端；
    检测单元，被设置为所述应用客户端在被启动时检测是否存在所述补丁文件；以及
    第一加载单元，被设置为所述应用客户端在检测到存在所述补丁文件时，在所述应用客户端运行的过程中加载所述补丁文件，以便对所述应用客户端进行更新。
  15. 根据权利要求14所述的装置，其中，所述生成单元包括：
    获取模块，被设置为所述应用服务器获取所述应用客户端的更新版本文件和当前版本文件；
    比对模块，被设置为比对所述应用客户端的更新版本文件和当前版本文件，获取所述应用客户端的更新版本文件和当前版本文件之间存在差异的类文件；以及
    打包模块，被设置为将所述类文件打包成所述补丁文件。
  16. 根据权利要求14所述的装置，其中，所述第一加载单元包括：
    排列模块，被设置为所述应用客户端将所述补丁文件排列在所述当前版本文件中的相关文件的前面，以使得在所述补丁文件的第一类文件和所述相关文件的第二类文件具有相同名称时所述第一类文件被调用，而所述第二类文件不被调用。
  17. 根据权利要求16所述的装置，其中，所述装置还包括：
    调用单元，被设置为所述应用客户端在所述应用客户端运行的过程中加载所述补丁文件之后，所述应用客户端在接收到调用具有所述相同名称的类文件时，检测到所述补丁文件排列在所述相关文件的前面、且所述补丁文件的所述第一类文件和所述相关文件的所述第二类文件具有所述相同名称，调用所述第一类文件，而不调用所述第二类文件。
  18. 根据权利要求14所述的装置，其中，所述装置还包括：
    请求单元，被设置为所述应用客户端在未检测到所述补丁文件时或者在所述应用客户端运行的过程中加载所述补丁文件之后，所述应用客户端向所述应用服务器请求是否存在所述应用最新的补丁文件；
    获取单元，被设置为若存在所述最新的补丁文件，所述应用客户端则从所述应用服务器获取所述最新的补丁文件；
    第二加载单元，被设置为所述应用客户端在所述应用客户端被再次启动之后加载所述最新的补丁文件，以便对所述应用客户端进行更新。
  19. 根据权利要求14所述的装置，其中，
    所述装置还包括：校验单元，被设置为所述应用客户端在检测到存在所述补丁文件之后，且在所述应用客户端运行的过程中加载所述补丁文件之前，所述应用客户端对所述补丁文件进行安全校验；
    所述第一加载单元包括：第一加载模块，被设置为在安全校验通过时，所述应用客户端在所述应用客户端运行的过程中加载所述补丁文件。
  20. 根据权利要求14所述的装置，其中，
    所述装置还包括：判断单元，被设置为所述应用客户端在检测到存在所述补丁文件之后，且在所述应用客户端运行的过程中加载所述补丁文件之前，所述应用客户端判断所述补丁文件与所述当前版本文件是否匹配；
    所述第一加载单元包括：第二加载模块，被设置为在所述补丁文件与所述当前版本文件匹配时，所述应用客户端加载所述补丁文件。
  21. 一种应用更新装置，其中，所述装置包括：
    检测单元，被设置为在应用客户端被启动时检测是否存在所述应用客户端的补丁文件，其中，所述补丁文件为根据所述应用客户端的更新版本文件与当前版本文件之间存在差异的类文件而生成的文件；以及
    第一加载单元，被设置为在检测到存在所述补丁文件时，在所述应用客户端运行的过程中加载所述补丁文件，以便对所述应用客户端进行更新。
  22. 根据权利要求21所述的装置，其中，所述第一加载单元包括：
    排列模块，被设置为将所述补丁文件排列在所述当前版本文件中的相关文件的前面，以使得在所述补丁文件的第一类文件和所述相关文件的第二类文件具有相同名称时所述第一类文件被调用，而所述第二类文件不被调用。
  23. 根据权利要求22所述的装置，其中，所述装置还包括：
    调用单元，被设置为在所述应用客户端运行的过程中加载所述补丁文件之后，在所述应用客户端接收到调用具有所述相同名称的类文 件时，检测到所述补丁文件排列在所述相关文件的前面、且所述补丁文件的所述第一类文件和所述相关文件的所述第二类文件具有所述相同名称，调用所述第一类文件，而不调用所述第二类文件。
  24. 根据权利要求21所述的装置，其中，所述装置还包括：
    请求单元，被设置为在未检测到所述补丁文件时或者在所述应用客户端运行的过程中加载所述补丁文件之后，向应用服务器请求是否存在所述应用客户端最新的补丁文件；
    获取单元，被设置为在存在所述最新的补丁文件，则从所述应用服务器获取所述最新的补丁文件；
    第二加载单元，被设置为在所述应用客户端被再次启动之后加载所述最新的补丁文件，以便对所述应用客户端进行更新。
  25. 根据权利要求21所述的装置，其中，
    所述装置还包括：校验单元，被设置为在检测到存在所述补丁文件之后，且在所述应用客户端运行的过程中加载所述补丁文件之前，对所述补丁文件进行安全校验；
    所述第一加载单元包括：第一加载模块，被设置为在安全校验通过时，在所述应用客户端运行的过程中加载所述补丁文件。
  26. 根据权利要求21所述的装置，其中，
    所述装置还包括：判断单元，被设置为在检测到存在所述补丁文件之后，且在所述应用客户端运行的过程中加载所述补丁文件之前，判断所述补丁文件与所述当前版本文件是否匹配；
    所述第一加载单元包括：第二加载模块，被设置为在所述补丁文件与所述当前版本文件匹配时，在所述应用客户端运行的过程中加载所述补丁文件。
PCT/CN2017/072269 2016-05-07 2017-01-23 应用更新方法和装置 WO2017193640A1 (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
US16/046,735 US10871953B2 (en) 2016-05-07 2018-07-26 Application update method and apparatus

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN201610297069.4A CN107346252B (zh) 2016-05-07 2016-05-07 应用更新方法和装置
CN201610297069.4 2016-05-07

Related Child Applications (1)

Application Number Title Priority Date Filing Date
US16/046,735 Continuation-In-Part US10871953B2 (en) 2016-05-07 2018-07-26 Application update method and apparatus

Publications (1)

Publication Number Publication Date
WO2017193640A1 true WO2017193640A1 (zh) 2017-11-16

Family

ID=60252926

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2017/072269 WO2017193640A1 (zh) 2016-05-07 2017-01-23 应用更新方法和装置

Country Status (3)

Country Link
US (1) US10871953B2 (zh)
CN (1) CN107346252B (zh)
WO (1) WO2017193640A1 (zh)

Cited By (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN107992749A (zh) * 2017-12-11 2018-05-04 北京奇虎科技有限公司 一种检测补丁包冲突的方法及装置
CN108399080A (zh) * 2018-03-05 2018-08-14 深圳市华讯方舟软件信息有限公司 一种Android App热更新方法
CN110874250A (zh) * 2019-11-20 2020-03-10 杭州天宽科技有限公司 工具厂商与app端的转换方法、系统、装置及存储介质
CN111316230A (zh) * 2018-07-19 2020-06-19 华为技术有限公司 一种补丁包生成方法及设备
CN112306553A (zh) * 2019-07-29 2021-02-02 腾讯科技（深圳）有限公司 安装包文件中扩展信息的处理方法、装置、及电子设备
CN113553090A (zh) * 2021-07-26 2021-10-26 网易（杭州）网络有限公司 客户端应用程序的更新控制方法及装置
WO2021223658A1 (zh) * 2020-05-07 2021-11-11 支付宝(杭州)信息技术有限公司 小程序的更新

Families Citing this family (17)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP6759169B2 (ja) * 2017-09-11 2020-09-23 株式会社東芝 情報処理装置、情報処理方法、および情報処理プログラム
CN110069729B (zh) * 2017-11-15 2022-07-01 上海优扬新媒信息技术有限公司 一种应用的离线缓存方法和系统
CN108039945A (zh) * 2017-12-11 2018-05-15 北京奇虎科技有限公司 一种补丁包的签名方法、校验方法及装置
CN108874437B (zh) * 2018-04-26 2022-01-21 深圳爱加密科技有限公司 一种android应用程序的在线云更新方法
CN111897555B (zh) * 2019-05-06 2024-06-07 阿里巴巴集团控股有限公司 客户端的动态更新方法、装置、系统及终端设备
CN110297666B (zh) * 2019-06-21 2022-06-17 百度在线网络技术（北京）有限公司 热修复方法、装置、系统及存储介质
CN110333892B (zh) * 2019-06-28 2022-12-13 百度在线网络技术（北京）有限公司 应用程序的补丁的生成方法、装置、设备和存储介质
CN112394969B (zh) * 2019-08-14 2023-04-28 华为技术有限公司 一种补丁发布的方法、服务器及终端设备
KR20210029621A (ko) * 2019-09-06 2021-03-16 삼성전자주식회사 전자 장치에서 어플리케이션 업데이트 시 런타임 성능 개선 방법 및 장치
CN113312066B (zh) * 2020-02-27 2022-07-26 福建省天奕网络科技有限公司 动态热更新方法、存储介质
CN113672248A (zh) * 2020-05-14 2021-11-19 武汉斗鱼鱼乐网络科技有限公司 一种补丁获取方法、装置、服务端及存储介质
CN111767539A (zh) * 2020-05-15 2020-10-13 上海趣蕴网络科技有限公司 一种apk安全系统及安全校验方法
CN111698297B (zh) * 2020-05-27 2022-04-05 重庆安捷诺科技有限公司 一种可升级的电子桌牌控制方法
CN112613915B (zh) * 2020-12-29 2022-11-22 上海触乐信息科技有限公司 用于支持双版本广告插件切换的方法、装置及电子设备
US11403093B1 (en) * 2021-04-28 2022-08-02 Oracle International Corporation Application modification with proxy service process
CN113779939B (zh) * 2021-09-14 2024-02-27 成都海光核电技术服务有限公司 一种文档热补丁的生成方法、使用方法及文档热补丁装置
CN113741943B (zh) * 2021-11-08 2022-03-18 湘投云储科技有限公司 一种嵌入式设备程序升级系统及方法

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN1399737A (zh) * 1999-09-24 2003-02-26 凤凰技术有限公司 便于组件选择的软件开发系统
US20130311599A1 (en) * 2012-05-17 2013-11-21 International Business Machines Corporation Updating Web Resources
CN103442026A (zh) * 2013-02-05 2013-12-11 华为技术有限公司 一种应用程序处理方法、装置和系统
CN104077162A (zh) * 2014-06-30 2014-10-01 北京奇虎科技有限公司 移动终端应用模板的更新、发布方法及装置

Family Cites Families (20)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7409685B2 (en) * 2002-04-12 2008-08-05 Hewlett-Packard Development Company, L.P. Initialization and update of software and/or firmware in electronic devices
US8205193B2 (en) * 2001-06-11 2012-06-19 Hewlett-Packard Development Company, L.P. Runtime updating of virtual machine class files
CN100422931C (zh) * 2005-02-05 2008-10-01 西安大唐电信有限公司 一种软件功能更新的方法及系统
US8230415B1 (en) * 2007-03-13 2012-07-24 Juniper Networks, Inc. On-demand advertising of software packages
CN102141919B (zh) * 2010-01-28 2013-03-13 北京邮电大学 模块化java应用软件在线更新系统及方法
US20110321024A1 (en) * 2010-06-28 2011-12-29 Nokia Corporation Method and apparatus for updating an executing application
CN102402427B (zh) * 2010-09-09 2015-09-02 阿里巴巴集团控股有限公司 一种Java应用程序的更新方法及装置
US9043778B2 (en) * 2011-12-01 2015-05-26 Tencent Technology (Shenzhen) Company Limited Method and system for upgrading software
US9223564B2 (en) * 2012-01-26 2015-12-29 Avago Technologies General Ip (Singapore) Pte. Ltd. Update systems responsive to ongoing processing at a storage system
US9210211B2 (en) * 2012-05-10 2015-12-08 Hulu, LLC Remote automated updates for an application
CN103428188A (zh) * 2012-05-25 2013-12-04 北京小米科技有限责任公司 一种文件更新方法、装置及相关设备
CN103677877B (zh) * 2012-09-12 2018-01-30 腾讯科技（深圳）有限公司 一种本地广告软件开发包升级的方法及装置
CN104252364B (zh) * 2013-06-25 2017-09-12 腾讯科技（深圳）有限公司 增量更新的方法、设备及系统
US8997075B2 (en) * 2013-07-23 2015-03-31 Red Hat, Inc. System and method for dynamic class management
WO2015069912A1 (en) * 2013-11-06 2015-05-14 Improvement Interactive, LLC Dynamic application version selection
CN103701930A (zh) * 2014-01-07 2014-04-02 浙江大学 一种移动应用程序的实时更新方法及系统
US9329856B2 (en) * 2014-03-19 2016-05-03 International Business Machines Corporation Managing a code load
CN104156247A (zh) * 2014-08-14 2014-11-19 广州金山网络科技有限公司 一种应用升级方法及装置
CN105373396B (zh) * 2015-08-14 2018-01-05 腾讯科技（深圳）有限公司 插件平台中的插件更新加载方法和装置
CN105320554A (zh) * 2015-12-11 2016-02-10 网易（杭州）网络有限公司 程序更新的方法、用于程序更新的客户端及系统

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN1399737A (zh) * 1999-09-24 2003-02-26 凤凰技术有限公司 便于组件选择的软件开发系统
US20130311599A1 (en) * 2012-05-17 2013-11-21 International Business Machines Corporation Updating Web Resources
CN103442026A (zh) * 2013-02-05 2013-12-11 华为技术有限公司 一种应用程序处理方法、装置和系统
CN104077162A (zh) * 2014-06-30 2014-10-01 北京奇虎科技有限公司 移动终端应用模板的更新、发布方法及装置

Cited By (12)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN107992749A (zh) * 2017-12-11 2018-05-04 北京奇虎科技有限公司 一种检测补丁包冲突的方法及装置
CN108399080A (zh) * 2018-03-05 2018-08-14 深圳市华讯方舟软件信息有限公司 一种Android App热更新方法
CN111316230A (zh) * 2018-07-19 2020-06-19 华为技术有限公司 一种补丁包生成方法及设备
CN111316230B (zh) * 2018-07-19 2021-08-03 华为技术有限公司 一种补丁包生成方法及设备
US11321080B2 (en) 2018-07-19 2022-05-03 Huawei Technologies Co., Ltd. Patch package generation method and device
CN112306553A (zh) * 2019-07-29 2021-02-02 腾讯科技（深圳）有限公司 安装包文件中扩展信息的处理方法、装置、及电子设备
CN112306553B (zh) * 2019-07-29 2024-06-04 腾讯科技（深圳）有限公司 安装包文件中扩展信息的处理方法、装置、及电子设备
CN110874250A (zh) * 2019-11-20 2020-03-10 杭州天宽科技有限公司 工具厂商与app端的转换方法、系统、装置及存储介质
CN110874250B (zh) * 2019-11-20 2023-05-02 杭州天宽科技有限公司 工具厂商与app端的转换方法、系统、装置及存储介质
WO2021223658A1 (zh) * 2020-05-07 2021-11-11 支付宝(杭州)信息技术有限公司 小程序的更新
CN113553090A (zh) * 2021-07-26 2021-10-26 网易（杭州）网络有限公司 客户端应用程序的更新控制方法及装置
CN113553090B (zh) * 2021-07-26 2023-07-25 网易（杭州）网络有限公司 客户端应用程序的更新控制方法及装置

Also Published As

Publication number Publication date
US20180373523A1 (en) 2018-12-27
CN107346252A (zh) 2017-11-14
CN107346252B (zh) 2021-05-25
US10871953B2 (en) 2020-12-22

Similar Documents

Publication Publication Date Title
WO2017193640A1 (zh) 应用更新方法和装置
US10715335B2 (en) Methods and apparatus to provide for efficient and secure software updates
US10127057B2 (en) Method and apparatus for dynamically implementing application function
US9965270B2 (en) Updating computer firmware
JP6319609B2 (ja) 信頼できるカーネル起動方法および装置
KR101066779B1 (ko) 컴퓨팅 장치의 보안 부팅
WO2017166446A1 (zh) 漏洞修复方法和装置
CN105786538B (zh) 基于安卓系统的软件升级方法和装置
WO2017071207A1 (zh) 一种应用安装方法、相关装置及应用安装系统
US20060026693A1 (en) Method, apparatus, and product for asserting physical presence with a trusted platform module in a hypervisor environment
WO2019062703A1 (zh) 升级方法、嵌入式系统
CN111159700A (zh) 一种基于uefi系统的计算机远程安全启动方法及系统
JP2013152717A (ja) 仮想マシン内でトラストチェーンを構築する方法
CN110058867B (zh) 应用程序镜像打包、安装方法及计算机装置、存储介质
KR102134491B1 (ko) 보호된 데이터 세트의 네트워크 기반 관리 기법
US10404568B2 (en) Agent manager for distributed transaction monitoring system
WO2016202204A1 (zh) 一种下载应用的方法和装置
WO2014134989A2 (zh) 一种Android终端及其实现升级的方法
WO2016146032A1 (zh) 电缆调制解调器安全方法及系统
JP7439067B2 (ja) ファイルシステムの検証とインストール
CN110263532B (zh) 可信计算方法、设备及系统
CN111090442B (zh) 一种应用更新方法、装置和存储介质
WO2021139261A1 (zh) 应用部署方法、装置及介质
CN112379938A (zh) 一种基于国产操作系统的跨浏览器安全调用本地应用方法
CN111400771A (zh) 目标分区的校验方法及装置、存储介质、计算机设备

Legal Events

Date Code Title Description
NENP Non-entry into the national phase

Ref country code: DE

121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 17795266

Country of ref document: EP

Kind code of ref document: A1

122 Ep: pct application non-entry in european phase

Ref document number: 17795266

Country of ref document: EP

Kind code of ref document: A1