WO2023065823A1

WO2023065823A1 - Software development kit fixing method, terminal, server and device

Info

Publication number: WO2023065823A1
Application number: PCT/CN2022/115415
Authority: WO
Inventors: 魏君成
Original assignee: 北京字节跳动网络技术有限公司
Priority date: 2021-10-20
Filing date: 2022-08-29
Publication date: 2023-04-27
Also published as: CN113961226A; CN113961226B

Abstract

Provided in the present disclosure are a software development kit fixing method, a terminal, a server, a device and a storage medium. On a server side, patches can be separately generated for various versions of SDKs, so as to ensure the independence of the SDKs, and as independent information, identifiers of the SDKs are brought into generated management-type information, thereby facilitating the smooth conducting of a subsequent patch merging operation. For a plurality of different versions of associated SDKs, patches of all the SDKs can be issued in one step. The independent patches are fused on a terminal side, and the SDKs are then fixed, such that different applications that access the SDKs can receive corresponding patches, so as to perform overall fix on a middleground tool that comprises all the SDKs; thus, not only can a hot fix workload and resource consumption be greatly reduced, but the independence, association and dependence between the SDKs can also be effectively taken into consideration, thereby greatly avoiding a fix failure caused by the association between the SDKs, and facilitating an improvement in a success rate of hot fix.

Description

A software development kit repair method, terminal, server and equipment

This application claims the priority of the Chinese patent application submitted to the State Intellectual Property Office on October 20, 2021, with the application number 202111222884.1, and the application name is "a software development kit repair method, terminal, server and equipment", all of which The contents are incorporated by reference in this application.

technical field

The present disclosure relates to the technical field of software maintenance, and in particular, relates to a method for repairing a software development kit, a terminal, a server and a device, and a storage medium storing readable computer programs.

Background technique

At present, the APP-level hot-fix solutions on the market are approaching maturity, but there are relatively few hot-fix solutions at the Software Development Kit (SDK) level, especially for middle-end tools, such as game middle-end , it is necessary to provide different functions according to different game access requirements, so it is necessary to provide multiple SDKs that are independent of each other but have dependencies. After the SDK is componentized, most of these SDKs have their own independent tool versions, which can be used The access party reassembles the access according to certain rules.

At present, most of the hot repairs of middle-end tools are to repair each SDK separately, or combine different SDKs as a whole for repair, and as the number of SDKs increases, the number of combinations increases exponentially, resulting in hot repair work The volume is large, the resource consumption is serious, and it is difficult to estimate the dependencies and correlations between SDKs.

Contents of the invention

Embodiments of the present disclosure at least provide a method for repairing a software development kit, a terminal, a server, a device, and a storage medium.

An embodiment of the present disclosure provides a method for repairing a software development kit, which is applied to a terminal. The terminal includes a plurality of software development kit SDKs, and at least some of the SDKs in the plurality of SDKs have different version numbers. The methods include:

Obtain a repair patch generated by the server for each SDK in the plurality of SDKs;

Based on the local patch of each SDK in the terminal and the plurality of repair patches, determine the latest patch for each SDK;

Decrypt and decompress the latest patch for each SDK to obtain the executable file corresponding to each latest patch;

Merging multiple executable files to obtain a fusion patch package for the multiple SDKs;

Repair the multiple SDKs by using the fusion patch package.

In an optional implementation manner, the determination of the latest patch for each SDK based on the local patch of each SDK in the terminal and the plurality of repair patches includes:

For each repair patch, based on the identification information of the SDK to which the repair patch belongs recorded in the management information of the repair patch, determine the local patch stored in the terminal corresponding to the repair patch;

Detect whether the repair patch is consistent with the corresponding local patch;

If the repair patch is inconsistent with the corresponding local patch, make sure that the repair patch is the latest patch of the corresponding SDK;

If the repair patch is consistent with the corresponding local patch, determine that the local patch corresponding to the repair patch is the latest patch of the corresponding SDK.

In an optional implementation manner, after determining that the repair patch is the latest patch of the corresponding SDK if the repair patch is inconsistent with the corresponding local patch, the method includes:

Delete the local patch corresponding to the repair patch.

In an optional implementation manner, the following steps are used to detect whether the repair patch is consistent with the corresponding local patch:

Calculate the digest algorithm value of the repair patch and the digest algorithm value of the corresponding local patch respectively;

If the digest algorithm value of the repair patch is consistent with the digest algorithm value of the corresponding local patch, it is determined that the repair patch is consistent with the corresponding local patch.

In an optional implementation manner, the merging of the determined multiple executable files to obtain a fusion patch package for the multiple SDKs includes:

Rename multiple executable files according to the order in which they are decompressed and decrypted;

Fusion is performed according to the renamed executable file to obtain fusion patch packages for the plurality of SDKs.

In an optional implementation manner, before using the fusion patch package to repair the multiple SDKs, the method includes:

Determine the historical patch information generated by loading the historical patch package during the previous repair before this repair;

Clear the historical patch information.

In an optional implementation manner, using the fusion patch package to repair the multiple SDKs includes:

The fusion patch package is loaded, and effective patch information generated when the fusion patch package is loaded is recorded.

In an optional implementation manner, the multiple SDKs include a main SDK and a function SDK that is accessed according to a function that the terminal needs to implement, and the accessed function SDK depends on the existence of the main SDK.

An embodiment of the present disclosure provides a method for repairing a software development kit, which is applied to a server, and the method includes:

Generate a corresponding repair patch for each SDK in the plurality of SDKs, wherein the version numbers of at least some of the SDKs in the plurality of SDKs are different;

According to the identification information of each SDK and the corresponding repair method, determine the management information of each repair patch;

After receiving the patch request from the terminal, the generated repair patches and the management information corresponding to each repair patch are sent to the terminal.

An embodiment of the present disclosure also provides a terminal, the terminal includes multiple software development kit SDKs, at least some of the SDKs have different version numbers, and the terminal includes:

An acquisition module, configured to acquire a repair patch generated by the server for each SDK in the plurality of SDKs;

The first determination module is used to determine the latest patch for each SDK based on the local patch of each SDK in the terminal and the plurality of repair patches;

The second determining module is used to decrypt and decompress the determined latest patch for each SDK, and obtain the executable file corresponding to each latest patch;

A fusion module, configured to fuse the determined multiple executable files to obtain fusion patch packages for the multiple SDKs;

A repair module, configured to repair the plurality of SDKs by using the fusion patch package.

In an optional implementation manner, the first determination module is specifically configured to:

In an optional implementation manner, the first determination module is also used for:

Delete the local patch corresponding to the repair patch.

In an optional implementation manner, the first determination module is configured to detect whether the repair patch is consistent with the corresponding local patch through the following steps:

In an optional implementation manner, the fusion module is specifically used for:

Renaming the identified multiple executable files according to the order in which they are decompressed and decrypted;

Fusion patch packages of the plurality of SDKs are fused according to the renamed executable files.

In an optional implementation manner, the terminal further includes a clearing module, and the clearing module is used for:

Clear the historical patch information.

In an optional implementation manner, the repair module is specifically used for:

An embodiment of the present disclosure also provides a server, and the server includes:

A generation module, configured to generate a corresponding repair patch for each SDK in the plurality of SDKs, wherein the version numbers of at least some of the SDKs in the plurality of SDKs are different;

The information determination module is used to determine the management information of each repair patch according to the identification information of each SDK and the corresponding repair method;

The sending module is configured to, after receiving the patch request from the terminal, send the generated repair patches and the management information corresponding to each repair patch to the terminal.

An embodiment of the present disclosure also provides an electronic device, including: a processor, a memory, and a bus, the memory stores machine-readable instructions executable by the processor, and when the electronic device is running, the processor and the The memories communicate with each other through the bus, and when the machine-readable instructions are executed by the processor, the above-mentioned steps in the method for repairing the software development kit are executed.

An embodiment of the present disclosure further provides a computer storage medium, on which a computer program is stored, and when the computer program is run by a processor, the steps in the above method for repairing the software development kit are executed.

In the software development kit repair method, terminal, server, device, and storage medium provided by the embodiments of the present disclosure, the server generates a corresponding repair patch for each SDK in multiple SDKs, and according to the identification information of each SDK and the corresponding repair method , determine the management information of each repair patch, after receiving the patch request from the terminal, send the generated multiple repair patches and the management information corresponding to each repair patch to the terminal, and the terminal obtains the server for multiple software development The repair patch generated by each SDK in the toolkit SDK, based on the local patch of each SDK in the terminal and the plurality of repair patches, determine the latest patch for each SDK, and determine the latest patch for each SDK. The latest patches of the SDKs are fused to obtain a fusion patch package for the multiple SDKs, and the multiple SDKs are repaired using the fusion patch package.

In this way, patches can be generated separately for each version of the SDK on the server side to ensure the independence of the SDK, and the SDK logo can be brought into the generated management information as independent information, which is conducive to the smooth progress of subsequent patch merging operations. Multiple SDKs of different versions and related to each other can issue patches for all SDKs at one time, and then repair each SDK after merging the independent patches on the terminal side, so that different applications that access each SDK can receive the corresponding patches to repair the middle-end tools including all SDKs as a whole, which can not only greatly reduce the workload of hot repair and resource consumption, but also effectively take into account the independence, correlation and dependence between SDKs It greatly avoids repair failures caused by the correlation between SDKs, which is conducive to improving the success rate of hot repairs.

In order to make the above-mentioned objects, features and advantages of the present disclosure more comprehensible, preferred embodiments will be described in detail below together with the accompanying drawings.

Description of drawings

In order to illustrate the technical solutions of the embodiments of the present disclosure more clearly, the following will briefly introduce the accompanying drawings used in the embodiments. The accompanying drawings here are incorporated into the specification and constitute a part of the specification. The drawings show the embodiments consistent with the present disclosure, and are used together with the description to explain the technical solution of the present disclosure. It should be understood that the following drawings only show some embodiments of the present disclosure, and therefore should not be regarded as limiting the scope. For those skilled in the art, they can also make From these figures are obtained other related figures.

FIG. 1 is a schematic diagram of an application scenario of an embodiment of the present disclosure;

FIG. 2 is a flow chart of a method for repairing a software development kit provided by an embodiment of the present disclosure;

FIG. 3 is a flowchart of a method for repairing a software development kit provided by an embodiment of the present disclosure;

FIG. 4 is a flowchart of another method for repairing a software development kit provided by an embodiment of the present disclosure;

FIG. 5 is a schematic diagram of a server provided by an embodiment of the present disclosure;

FIG. 6 is one of schematic diagrams of a terminal provided by an embodiment of the present disclosure;

FIG. 7 is a second schematic diagram of a terminal provided by an embodiment of the present disclosure;

Fig. 8 is a schematic diagram of an electronic device provided by an embodiment of the present disclosure.

Detailed ways

In order to make the purpose, technical solutions and advantages of the embodiments of the present disclosure clearer, the technical solutions in the embodiments of the present disclosure will be clearly and completely described below in conjunction with the accompanying drawings in the embodiments of the present disclosure. Obviously, the described embodiments are only It is a part of the embodiments of the present disclosure, but not all of them. The components of the disclosed embodiments generally described and illustrated in the figures herein may be arranged and designed in a variety of different configurations. Accordingly, the following detailed description of the embodiments of the present disclosure provided in the accompanying drawings is not intended to limit the scope of the claimed disclosure, but merely represents selected embodiments of the present disclosure. Based on the embodiments of the present disclosure, all other embodiments obtained by those skilled in the art without creative effort shall fall within the protection scope of the present disclosure.

It should be noted that like numerals and letters denote similar items in the following figures, therefore, once an item is defined in one figure, it does not require further definition and explanation in subsequent figures.

The term "and/or" in this article only describes an association relationship, which means that there can be three kinds of relationships, for example, A and/or B can mean: there is A alone, A and B exist at the same time, and B exists alone. situation. In addition, the term "at least one" herein means any one of a variety or any combination of at least two of the more, for example, including at least one of A, B, and C, which may mean including from A, Any one or more elements selected from the set formed by B and C.

After research, it is found that currently, the hot repair solutions for the APP level on the market are approaching maturity, but there are relatively few hot repair solutions for the software development kit (Software Development Kit, SDK) level, especially for middle-end tools. For example, the game platform needs to provide different functions according to different game access requirements, so it is necessary to provide multiple SDKs that are independent of each other but have dependencies. After the SDK is componentized, most of these SDKs have their own independent tools. Versions can be reassembled and accessed by the accessing party according to certain rules.

Based on the above research, this disclosure provides a software development toolkit repair method, which can generate patches for each version of the SDK separately on the server side to ensure the independence of the SDK, and bring the SDK logo as independent information to the generated management In the class information, it is conducive to the smooth progress of subsequent patch merging operations. For multiple SDKs of different versions and associated multiple SDKs, all SDK patches can be issued at one time. After the independent patches are integrated on the terminal side Then repair each SDK, so that different applications connected to each SDK can receive corresponding patches, so as to perform overall repairs on the middle platform tools including all SDKs, which can not only greatly reduce the workload and resource consumption of hot repairs, but also It can effectively take into account the independence, correlation and dependence between SDKs, greatly avoid repair failures caused by the correlation between SDKs, and help improve the success rate of hot repair.

In order to facilitate the understanding of this embodiment, a toolkit repair method disclosed in the embodiments of the present disclosure is firstly introduced in detail. The execution subject of the toolkit repair method provided in the embodiments of the present disclosure is generally a computer device with certain computing capabilities. The computer equipment includes, for example: terminal equipment or server or other processing equipment, and the terminal equipment can be user equipment (User Equipment, UE), mobile equipment, user terminal, terminal, cellular phone, cordless phone, personal digital assistant (Personal Digital Assistant, PDA), handheld devices, computing devices, vehicle-mounted devices, wearable devices, etc. In some possible implementation manners, the method for repairing the toolkit may be implemented by the processor invoking computer-readable instructions stored in the memory.

Please refer to FIG. 1 . FIG. 1 is a schematic diagram of an application scenario of an embodiment of the present disclosure. As shown in Figure 1, with the development of Internet technology, various terminals have entered people's lives, such as various mobile terminals, wearable smart terminals, fixed terminals, etc. When people use various terminals , most of them need to install and upgrade various functional applications and tool applications, etc. Developers will develop various application files required by users and patch files for upgrading and repairing applications on the background server side, and will develop application files and patch files and uploaded to an application platform for managing applications, such as various application stores, etc., users can download application files and patch files from the application platform to install the application and perform operations such as repairing the application.

Please refer to FIG. 2 . FIG. 2 is a flowchart of a method for repairing a software development kit provided by an embodiment of the present disclosure. The method for repairing the software development kit provided by the embodiment of the present disclosure can be applied to the server shown in FIG. 1, and as shown in FIG. 2, the method includes:

S201: Generate a corresponding repair patch for each of the multiple SDKs, where at least some of the SDKs have different version numbers.

In this step, the target application may be installed in the terminal, and the target application includes multiple software development kit SDKs. Further, the multiple SDKs may include the main SDK and a function SDK that is accessed according to the functions required by the terminal. Among the multiple SDKs, At least some of the SDKs have different version numbers. When the target application needs to be upgraded or repaired, especially when at least some of the multiple SDKs need to be repaired or upgraded, a corresponding repair patch can be generated for each SDK.

Wherein, a corresponding repair patch is generated for each SDK, that is, a repair patch is separately generated for each SDK.

Further, when some SDKs do not need to be repaired, the repair patches corresponding to them can be the patches from the last repair.

S202: Determine the management class information of each repair patch according to the identification information of each SDK and the corresponding repair method.

In this step, according to the identification information of each SDK and the corresponding repair method, such as the name of the SDK, the method to be repaired in the SDK (the old method with problems) and the corresponding repair method (the new one can replace the old method) new method for repairing), determine the management class information for each repair patch.

Wherein, the management class information of each repair patch may be recorded through Java source code.

S203: After receiving the patch request from the terminal, send the generated repair patches and the management information corresponding to each repair patch to the terminal.

In this step, after receiving the patch request sent by the terminal for downloading the patch, in response to the patch request, the generated repair patches and the management information corresponding to each repair patch are packaged and sent to the terminal.

Among them, on the server side, for each SDK, after it changes, a corresponding repair patch can be generated each time. With the accumulation of time and version changes, each SDK may have multiple fixes. Patches, therefore, in order to facilitate management, different priorities can be configured for each repair patch generated according to the generation time. The closer the repair patch generation time is to the current server clock time, the higher the priority of the repair patch. Correspondingly, When issuing a patch, that is, when the patch needs to be sent to the terminal or uploaded to the management platform, compare the priorities of all the repair patches in the SDK, and determine that the repair patch with the highest priority is the repair patch to be sent to the terminal or uploaded to the management platform.

Specifically, after receiving the patch request from the terminal, the determined repair patch with the highest priority and the management information corresponding to each repair patch can be sent to the terminal, that is, when there are multiple repair patches in the current SDK, the priority The highest level patch is sent to the terminal.

Sending the repair patch and the management class information corresponding to the repair patch together can ensure the correspondence between the patch and the patch management class, which is convenient for subsequent use.

The method for repairing the software development kit provided by the embodiment of the present disclosure generates a corresponding repair patch for each SDK in multiple SDKs, and determines the management information of each repair patch according to the identification information of each SDK and the corresponding repair method. , after receiving the patch request from the terminal, sending the generated repair patches and the management information corresponding to each repair patch to the terminal.

In this way, on the server side, patches can be generated separately for each version of the SDK to ensure the independence of the SDK, and the SDK logo can be brought into the generated management information as independent information, which is conducive to the smooth progress of subsequent patch merging operations. Different versions and associated multiple SDKs can issue patches for all SDKs at one time.

Please refer to FIG. 3 at the same time. FIG. 3 is a flowchart of a method for repairing a software development kit provided by an embodiment of the present disclosure. The software development kit repair method provided by the embodiment of the present disclosure is applied to the terminal as shown in Figure 1. The terminal includes multiple software development kit SDKs, at least some of which have different version numbers, as shown in Figure 3 , methods include:

S301: Obtain a repair patch generated by the server for each of the multiple SDKs.

Wherein, the obtained repair patches, as shown in FIG. 1 , may be obtained from the application platform, but not limited thereto, and may also be directly obtained from the server in other real-time manners.

Among them, multiple SDKs can be multiple SDKs that make up middle-end tools, which can include the main SDK, and multiple functional SDKs that are connected to the main SDK and accessed according to the functions that the terminal needs to achieve. The accessed functional SDKs depend on In addition, there may also be dependencies between multiple functional SDKs.

Wherein, the file type of the repair patch may be a jar file.

Wherein, the repair patch obtained may be a packaged file sent by the receiving server, which includes repair patches of each SDK.

S302: Determine the latest patch for each SDK based on the local patch and multiple repair patches of each SDK in the terminal.

In this step, after obtaining multiple repair patches, you can compare the repair patches corresponding to each SDK with the local patches by comparing the multiple repair patches with the local patches of each SDK in the terminal. , and determine the latest patch of each SDK according to the comparison result of the repair patch and the local patch.

Wherein, the file types of the local patch and multiple repair patches of each SDK in the terminal, and the determined latest patch are all jar files.

Among them, determining the latest patch of each SDK may be after receiving the file sent by the server, for example, after receiving the file package sent by the server, comparing the management information in the file package with the local patch to determine the latest patch .

Correspondingly, in some specific implementation manners, for determining the latest patch for each SDK, the following steps may be taken:

For each repair patch, based on the identification information of the SDK to which the repair patch belongs recorded in the management information of the repair patch, determine the local patch corresponding to the repair patch and stored in the terminal; detect the repair patch and the corresponding local Whether the patch is consistent; if the repair patch is inconsistent with the corresponding local patch, determine that the repair patch is the latest patch of the corresponding SDK; if the repair patch is consistent with the corresponding local patch, determine that the local patch corresponding to the repair patch is the corresponding The latest patch for the SDK.

Here, when it is necessary to determine the latest patch of each SDK, the management information of each repair patch can be extracted from the received file, and for each repair patch, according to the records in the management information of the repair patch, The identification information of the SDK to which the repair patch belongs determines the SDK to which the repair patch belongs, and then determines the local patch stored in the terminal by the SDK to which the repair patch belongs, and then compares the repair patch with the local patch to detect the repair Whether the patch is consistent with the corresponding local patch. If the repair patch is inconsistent with the corresponding local patch, the repair patch is considered to be the latest patch of the corresponding SDK. If the repair patch is consistent with the corresponding local patch, it can be considered to be the same as the repair patch The local patch corresponding to the patch is already the latest patch of the SDK.

Among them, in order to ensure the correspondence between the patch and the patch management class, as well as the convenience here, when the repair patch is obtained, the management class information corresponding to the repair patch can be obtained together, that is, the received packaged file can include records A file with administrative information.

Specifically, when comparing the repair patch with the corresponding local patch, the following steps may be used to detect whether the repair patch is consistent with the corresponding local patch:

Calculate the digest algorithm value of the repair patch and the digest algorithm value of the corresponding local patch respectively; if the digest algorithm value of the repair patch is consistent with the digest algorithm value of the corresponding local patch, determine that the repair patch is consistent with the corresponding local patch.

In this step, when detecting whether the repair patch is consistent with the corresponding local patch, the digest algorithm value of the repair patch and the digest algorithm value of the corresponding local patch can be calculated respectively, and then by comparing the digest algorithm value of the repair patch with the corresponding The size of the digest algorithm value of the local patch, and check whether the repair patch is consistent with the corresponding local patch. If the digest algorithm value of the repair patch is equal to the digest algorithm value of the corresponding local patch, the repair patch and the corresponding local patch can be determined. The local patches are the same.

Wherein, the digest algorithm value of the repair patch and the corresponding digest algorithm value of the local patch may be the MD5 value of the repair patch and the corresponding MD5 value of the local patch.

Further, when it is determined that the repair patch is inconsistent with the corresponding local patch, it can be considered that the local patch is an old version of the patch and needs to be repaired. In order to avoid the impact of the local patch on the repair process and reduce the memory usage of the terminal, etc. , after determining that the repair patch is the latest patch of the corresponding SDK if the repair patch is inconsistent with the corresponding local patch, the method includes:

Delete the local patch corresponding to the repair patch.

In this way, when the repair patch is inconsistent with the corresponding local patch, and the repair patch is determined to be the latest patch of the corresponding SDK, the local patch corresponding to the repair patch can be deleted, so as to avoid the impact caused when the patch is used.

S303: Decrypt and decompress the determined latest patch for each SDK to obtain an executable file corresponding to each latest patch.

In this step, after determining the latest patch of each SDK, that is, the retained local patch and the newly downloaded repair patch, all the latest patches can be decrypted and decompressed, so as to obtain the executable file where the patch is located.

Wherein, the type of the executable file is a dex file.

S304: Merge the determined multiple executable files to obtain a fusion patch package for multiple SDKs.

In this step, after obtaining the executable file where the patch is located, multiple executable files can be fused to obtain a fusion patch package. Further, all executable files (repair files and local files) can be deleted to prevent The decrypted patch code leaked.

Among them, the file type of the fusion patch package of multiple SDKs is a jar file.

S305: Use the fusion patch package to repair multiple SDKs.

In this step, the obtained integrated patch package can be loaded with a class loader to make the integrated patch package take effect, so as to complete the repair of multiple SDKs.

Among them, after obtaining the fusion patch package for multiple SDKs, when loading the fusion patch package, the loading method can be determined according to the status of the terminal. Detect whether the Android system of the terminal is version 5.0 or lower. If so, you need to add each independent executable file in the fusion patch package of multiple SDKs to the path of the class loader to ensure that all patches will be merged after synthesis. Load and run.

The software development kit repair method provided by the embodiment of the present disclosure obtains the repair patch generated by the server for each SDK in multiple SDKs; based on the local patch and multiple repair patches of each SDK in the terminal, determine the The latest patch of the SDK; decrypt and decompress the determined latest patch for each SDK to obtain the executable file corresponding to each latest patch; merge the determined executable files to obtain the Fusion patch package; use the fusion patch package to fix multiple SDKs.

In this way, each SDK is repaired after the independent patches are integrated on the terminal side, so that different applications connected to each SDK can receive the corresponding patches, so as to perform overall repairs on the middle platform tools including all SDKs, not only can It greatly reduces the workload and resource consumption of hot repair, and can effectively take into account the independence, correlation and dependence between SDKs, avoiding repair failures caused by the correlation between SDKs, and improving the efficiency of hot repair. Success rate.

Please refer to FIG. 4 . FIG. 4 is a flow chart of another method for repairing a software development kit provided by an embodiment of the present disclosure. The software development kit repair method provided by the embodiment of the present disclosure is applied to the terminal as shown in Figure 1. The terminal includes multiple software development kit SDKs, at least some of which have different version numbers, as shown in Figure 4 , methods include:

S401: Obtain a repair patch generated by the server for each of the multiple SDKs.

S402: Determine the latest patch for each SDK based on the local patch and multiple repair patches of each SDK in the terminal.

S403: Decrypt and decompress the determined latest patch for each SDK to obtain an executable file corresponding to each latest patch.

S404: Merge the determined multiple executable files to obtain a fusion patch package for multiple SDKs.

S405: Determine the historical patch information generated by loading the historical patch package during the last repair before this repair.

In this step, before using the fusion patch package to repair multiple SDKs, it is necessary to determine the product of the last repair before this repair, that is, the historical patch information generated by the last loading of the fusion patch package.

S406: Clear historical patch information.

In this step, the historical patch information is cleared, that is, the product generated by loading the fusion patch package last time is cleared, so as not to affect the loading and repairing of the fusion patch this time.

Among them, only under the premise that there are at least some inconsistencies between the local patches of each SDK and multiple repair patches in the terminal, will the historical patch information be cleared, that is, the premise that the local patches of the terminal are updated The historical patch information will be cleared only if the terminal is disabled. If the local patch of the terminal is not updated, there is no need to clear the historical patch information.

S407: Use the fusion patch package to repair multiple SDKs.

Wherein, the description of step S401 to step S404 and step S407 can refer to the description of step S301 to step S305, and can achieve the same technical effect and solve the same technical problem, and will not be repeated here.

Next, this embodiment will be further described in conjunction with specific implementation methods.

In an optional implementation manner, step S404 includes:

Rename the determined executable files according to the order of the decompressed and decrypted files; merge the renamed executable files into multiple SDK fusion patch packages.

In this step, after decrypting and decompressing the executable file of each latest patch, the sort order of each executable file after decompression and decryption can be identified, and then it can be renamed according to the sort order of each executable file, Then merge the renamed executable files into a fusion patch package.

In an optional implementation manner, step S405 includes:

Load the fusion patch package, and record the effective patch information generated when the fusion patch package is loaded.

Further, after recording and loading the fusion patch package to generate effective patch information, according to the recorded effective patch information, determine the patch that has not taken effect, and send the management information of the patch that has not taken effect to the server, requesting to re-download the repair patch.

The software development kit repair method provided by the embodiment of the present disclosure obtains the repair patch generated by the server for each SDK in multiple SDKs; based on the local patch and multiple repair patches of each SDK in the terminal, determine the The latest patch of the SDK; decrypt and decompress the determined latest patch for each SDK to obtain the executable file corresponding to each latest patch; merge the determined executable files to obtain the The fusion patch package; determine the historical patch information generated by loading the historical patch package during the last repair before this repair; clear the historical patch information; use the fusion patch package to repair multiple SDKs.

In this way, each SDK is repaired after the independent patches are integrated on the terminal side, so that different applications connected to each SDK can receive the corresponding patches, so as to perform overall repairs on the middle platform tools including all SDKs, not only can It greatly reduces the workload and resource consumption of hot repair, and can effectively take into account the independence, correlation and dependence between SDKs, greatly avoiding repair failures caused by the correlation between SDKs, and is conducive to improving the efficiency of hot repair. Success rate, before repairing, delete the products generated by previous repairs, reduce the impact of products generated by previous repairs on this repair, and further improve the efficiency and success rate of hot repairs.

Those skilled in the art can understand that in the above method of specific implementation, the writing order of each step does not mean a strict execution order and constitutes any limitation on the implementation process. The specific execution order of each step should be based on its function and possible The inner logic is OK.

Based on the same inventive concept, the embodiments of the present disclosure also provide servers and terminals corresponding to the software development toolkit repair methods respectively. Since the problem solving principles of the server and the terminal in the embodiments of the present disclosure are the same as those of the above-mentioned toolkit repair methods in the embodiments of the present disclosure The method is similar, so the implementation of the device can refer to the implementation of the method, and the repetition will not be repeated.

Please refer to FIG. 5 , which is a schematic diagram of a server provided by an embodiment of the present disclosure. The server 500 provided in the embodiment of the present disclosure includes:

A generating module 500, configured to generate a corresponding repair patch for each of the multiple SDKs, wherein at least some of the SDKs have different version numbers;

An information determination module 510, configured to determine the management class information of each repair patch according to the identification information of each SDK and the corresponding repair method;

The sending module 530 is configured to, after receiving the patch request from the terminal, send the generated repair patches and the management information corresponding to each repair patch to the terminal.

For the description of the processing flow of each module in the device and the interaction flow between the modules, reference may be made to the relevant description in the above method embodiment, and details will not be described here.

The server provided by the embodiment of the present disclosure can separately generate patches for each version of the SDK to ensure the independence of the SDK, and bring the identification of the SDK as independent information to the generated management information, which is conducive to the smooth operation of subsequent patch merging For different versions and associated multiple SDKs, patches for all SDKs can be delivered at one time.

Referring to FIG. 6 to FIG. 7 , FIG. 6 is one of schematic diagrams of a terminal provided by an embodiment of the present disclosure, and FIG. 7 is a second schematic diagram of a terminal provided by an embodiment of the present disclosure. The terminal includes a plurality of software development kit SDKs, at least some of which have different version numbers. As shown in FIG. 6, the terminal 600 provided by the embodiment of the present disclosure includes:

The obtaining module 610 is configured to determine the latest patch for each SDK based on the local patch of each SDK in the terminal and the plurality of repair patches.

The first determining module 620 is configured to determine the latest patch for each SDK based on the local patch of each SDK in the terminal and the plurality of repair patches.

The second determination module 630 is configured to decrypt and decompress the determined latest patch for each SDK, and obtain the executable file corresponding to each latest patch.

A fusion module 640, configured to fuse the determined multiple executable files to obtain fusion patch packages for the multiple SDKs;

The repair module 650 is configured to use the fusion patch package to repair the multiple SDKs.

In an optional implementation manner, the first determining module 620 is specifically configured to:

In an optional implementation manner, the first determining module 620 is also configured to:

Delete the local patch corresponding to the repair patch.

In an optional implementation manner, the first determination module 620 is configured to detect whether the repair patch is consistent with the corresponding local patch through the following steps:

In an optional implementation manner, the fusion module 640 is specifically used for:

In an optional implementation manner, the terminal further includes a clearing module 660, and the clearing module 660 is configured to:

Clear the historical patch information.

In an optional implementation manner, the repair module 650 is specifically used for:

The terminal provided by the embodiment of the present disclosure can repair each SDK after merging the received independent patches, so that different applications connected to each SDK can receive corresponding patches, so that the middle platform including all SDKs The overall repair of the tool can not only greatly reduce the workload and resource consumption of hot repair, but also effectively take into account the independence, correlation and dependence between SDKs, and greatly avoid repair failures caused by the correlation between SDKs , which is conducive to improving the success rate of thermal repair.

Based on the same technical idea, an embodiment of the present disclosure also provides an electronic device. The embodiment of the present disclosure also provides an electronic device 800, as shown in FIG. 8, which is a schematic structural diagram of the electronic device 800 provided by the embodiment of the present disclosure, including:

Processor 810, memory 820, and bus 830; memory 820 is used to store and execute instructions, including memory 821 and external memory 822; memory 821 here is also called internal memory, and is used for temporarily storing operation data in processor 810, and The data exchanged by the external memory 822 such as a hard disk, the processor 810 exchanges data with the external memory 822 through the memory 821, and when the electronic device 800 is running, the processor 810 communicates with the memory 820 through the bus 830, so that The processor 810 may execute the steps of the software development kit repair method shown in FIG. 2 or FIG. 3 and FIG. 4 above.

An embodiment of the present disclosure also provides a computer storage medium, on which a computer program is stored, and when the computer program is run by a processor, the software development kit repair method shown in FIG. 2 or FIG. 3 and FIG. 4 is executed. step. Wherein, the storage medium may be a volatile or non-volatile computer and storage medium.

An embodiment of the present disclosure also provides a computer program product, the computer program product carries a program code, and the instructions included in the program code can be used to execute the steps of the method for repairing the software development kit described in the above method embodiment, specifically, Refer to the foregoing method embodiments, and details are not repeated here.

Wherein, the above-mentioned computer program product may be specifically implemented by means of hardware, software or a combination thereof. In an optional embodiment, the computer program product is embodied as a computer storage medium, and in another optional embodiment, the computer program product is embodied as a software product, such as a software development kit (Software Development Kit, SDK) etc. wait.

Those skilled in the art can clearly understand that for the convenience and brevity of the description, the specific working process of the storage medium, device and equipment described above can refer to the corresponding process in the foregoing method embodiment, which will not be repeated here. In the several embodiments provided in the present disclosure, it should be understood that the disclosed storage medium, device, device and method may be implemented in other ways. The device embodiments described above are only illustrative. For example, the division of the units is only a logical function division. In actual implementation, there may be other division methods. For example, multiple units or components can be combined or It may be integrated into another device, or some features may be omitted, or not implemented. In another point, the mutual coupling or direct coupling or communication connection shown or discussed may be through some communication interfaces, and the indirect coupling or communication connection of devices or units may be in electrical, mechanical or other forms.

The units described as separate components may or may not be physically separated, and the components shown as units may or may not be physical units, that is, they may be located in one place, or may be distributed to multiple network units. Part or all of the units can be selected according to actual needs to achieve the purpose of the solution of this embodiment.

In addition, each functional unit in each embodiment of the present disclosure may be integrated into one processing unit, each unit may exist separately physically, or two or more units may be integrated into one unit.

If the functions described above are realized in the form of software function units and sold or used as independent products, they can be stored in a non-volatile computer and storage medium executable by a processor. Based on this understanding, the technical solution of the present disclosure is essentially or the part that contributes to the prior art or the part of the technical solution can be embodied in the form of a software product, and the computer software product is stored in a storage medium, including Several instructions are used to make a computer device (which may be a personal computer, a server, or a network device, etc.) execute all or part of the steps of the methods described in various embodiments of the present disclosure. The aforementioned storage media include: U disk, mobile hard disk, read-only memory (Read-Only Memory, ROM), random access memory (Random Access Memory, RAM), magnetic disk or optical disc and other media that can store program codes. .

Finally, it should be noted that: the above-mentioned embodiments are only specific implementations of the present disclosure, and are used to illustrate the technical solutions of the present disclosure, rather than limit them, and the protection scope of the present disclosure is not limited thereto, although referring to the aforementioned The embodiments have described the present disclosure in detail, and those skilled in the art should understand that any person familiar with the technical field can still modify the technical solutions described in the foregoing embodiments within the technical scope disclosed in the present disclosure Changes can be easily imagined, or equivalent replacements can be made to some of the technical features; and these modifications, changes or replacements do not make the essence of the corresponding technical solutions deviate from the spirit and scope of the technical solutions of the embodiments of the present disclosure, and should be included in this disclosure. within the scope of protection. Therefore, the protection scope of the present disclosure should be defined by the protection scope of the claims.

Claims

A method for repairing a software development kit, characterized in that it is applied to a terminal, and the terminal includes a plurality of software development kit SDKs, and at least part of the SDKs in the plurality of SDKs have different version numbers, and the method includes :

Obtain a repair patch generated by the server for each SDK in the plurality of SDKs;

Determine the latest patch for each SDK based on the local patch and multiple repair patches of each SDK in the terminal;

Decrypt and decompress the latest patch for each SDK to obtain the executable file corresponding to each latest patch;

Merging multiple executable files to obtain a fusion patch package for the multiple SDKs;

Repair the multiple SDKs by using the fusion patch package.
The method according to claim 1, wherein the determination of the latest patch for each SDK based on the local patch of each SDK in the terminal and the plurality of repair patches includes:

For each repair patch, based on the identification information of the SDK to which the repair patch belongs recorded in the management information of the repair patch, determine the local patch stored in the terminal corresponding to the repair patch;

Detect whether the repair patch is consistent with the corresponding local patch;

If the repair patch is inconsistent with the corresponding local patch, make sure that the repair patch is the latest patch of the corresponding SDK;

If the repair patch is consistent with the corresponding local patch, determine that the local patch corresponding to the repair patch is the latest patch of the corresponding SDK.
The method according to claim 2, wherein if the repair patch is inconsistent with the corresponding local patch, after determining that the repair patch is the latest patch of the corresponding SDK, the method includes:

Delete the local patch corresponding to the repair patch.
The method according to claim 2, characterized in that, whether the repair patch is consistent with the corresponding local patch is detected by the following steps:

Calculate the digest algorithm value of the repair patch and the digest algorithm value of the corresponding local patch respectively;

If the digest algorithm value of the repair patch is consistent with the digest algorithm value of the corresponding local patch, it is determined that the repair patch is consistent with the corresponding local patch.
The method according to claim 1, wherein said merging a plurality of executable files to obtain a fusion patch package for said plurality of SDKs comprises:

Rename multiple executable files according to the order in which they are decompressed and decrypted;

Fusion is performed according to the renamed executable file to obtain fusion patch packages for the plurality of SDKs.
The method according to claim 1, wherein, before using the fusion patch package to repair the plurality of SDKs, the method comprises:

Determine the historical patch information generated by loading the historical patch package during the previous repair before this repair;

Clear the historical patch information.
The method according to claim 1, characterized in that, using the fusion patch package to repair the plurality of SDKs includes:

The fusion patch package is loaded, and effective patch information generated when the fusion patch package is loaded is recorded.
The method according to any one of claims 1-7, wherein the multiple SDKs include a main SDK and a function SDK that is accessed according to the functions that the terminal needs to implement, and the function SDKs that are accessed depend on exists in the main SDK.
A method for repairing a software development kit is characterized in that it is applied to a server, and the method includes:

Generate a corresponding repair patch for each SDK in the plurality of SDKs, wherein the version numbers of at least some of the SDKs in the plurality of SDKs are different;

According to the identification information of each SDK and the corresponding repair method, determine the management information of each repair patch;

After receiving the patch request from the terminal, the generated repair patches and the management information corresponding to each repair patch are sent to the terminal.
A terminal, characterized in that the terminal includes a plurality of SDKs, at least some of the SDKs have different version numbers, and the terminal includes:

An acquisition module, configured to acquire a repair patch generated by the server for each SDK in the plurality of SDKs;

The first determination module is used to determine the latest patch for each SDK based on the local patch of each SDK in the terminal and the plurality of repair patches;

The second determining module is used for decrypting and decompressing the latest patches of each SDK to obtain the executable file corresponding to each latest patch;

A fusion module, configured to fuse multiple executable files to obtain fusion patch packages for the multiple SDKs;

A repair module, configured to repair the plurality of SDKs by using the fusion patch package.
A server, characterized in that the server includes:

A generation module, configured to generate a corresponding repair patch for each SDK in the plurality of SDKs, wherein the version numbers of at least some of the SDKs in the plurality of SDKs are different;

The information determination module is used to determine the management information of each repair patch according to the identification information of each SDK and the corresponding repair method;

The sending module is configured to, after receiving the patch request from the terminal, send the generated repair patches and the management information corresponding to each repair patch to the terminal.
An electronic device, characterized in that it includes: a processor, a memory, and a bus, the memory stores machine-readable instructions executable by the processor, and when the electronic device is running, the connection between the processor and the memory Communication through the bus, when the machine-readable instructions are executed by the processor, the software development kit repair method according to any one of claims 1 to 8 is executed, or the software described in claim 9 is executed Steps to develop a repair method for the kit.
A computer-readable storage medium, characterized in that a computer program is stored on the computer-readable storage medium, and when the computer program is run by a processor, the software development kit according to any one of claims 1 to 9 is executed Repair method.