Method, device, terminal, equipment, system and medium for repairing SDK
By generating SDK repair strategies through the platform's calculation of anomaly impact parameters and tiered processing rules, the differences in SDK repair needs among different channels are resolved, achieving targeted and efficient SDK repair.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Patents(China)
- Current Assignee / Owner
- CHINA UNIONPAY
- Filing Date
- 2022-08-26
- Publication Date
- 2026-06-16
Smart Images
Figure CN115543404B_ABST
Abstract
Description
Technical Field
[0001] This application belongs to the field of data processing, and in particular relates to a method, apparatus, terminal, device, system and medium for repairing an SDK. Background Technology
[0002] A Software Development Kit (SDK) is a toolkit that provides a specific function for a software framework, hardware platform, operating system, or application. SDKs can be embedded into various hosts such as software frameworks, hardware platforms, operating systems, or applications. When running alongside a host, SDKs may encounter errors, requiring bug fixes to ensure proper functioning.
[0003] However, due to the different channel providers, their development methods and host environments also vary, and the defects that appear in the SDK may also be different. A single SDK fix is unlikely to meet the SDK fix needs of different channel providers. Summary of the Invention
[0004] This application provides an SDK repair method, apparatus, terminal, device, system, and medium that can meet the SDK repair needs of different channel partners.
[0005] In a first aspect, embodiments of this application provide an SDK repair method applied to a repair platform. The method includes: acquiring Software Development Kit (SDK) information, host information, and SDK exception information for different exception types; obtaining exception impact parameters corresponding to each exception type of the target SDK based on the SDK information, host information, and SDK exception information for each exception type, wherein the target SDK corresponds to the host program indicated by the host information and the SDK version indicated by the SDK information; obtaining a target SDK repair strategy based on the exception impact parameters corresponding to each exception type of the target SDK and preset exception classification processing rules, wherein the target SDK repair strategy includes SDK repair strategies for exception levels corresponding to the exception impact parameters in the exception classification processing rules; and sending the target SDK repair strategy to a user terminal so that the user terminal executes the target SDK repair strategy to repair the target SDK.
[0006] Secondly, embodiments of this application provide an SDK repair method applied to a user terminal. The method includes: providing a repair platform with Software Development Kit (SDK) information, host information, and SDK exception information for different exception types, so that the repair platform obtains a target SDK repair strategy based on exception impact parameters corresponding to each exception type of the target SDK and preset exception classification processing rules. The target SDK repair strategy includes an SDK repair strategy for the exception level corresponding to the exception impact parameters in the exception classification processing rules. The target SDK corresponds to the host program indicated by the host information and the SDK version indicated by the SDK information. The exception impact parameters corresponding to each exception type of the target SDK are obtained based on the SDK information, host information, and SDK exception information for each exception type. The method also includes obtaining the target SDK repair strategy from the repair platform and executing the target SDK repair strategy to repair the target SDK.
[0007] Thirdly, embodiments of this application provide an SDK repair device applied to a repair platform. The device includes: an acquisition module for acquiring Software Development Kit (SDK) information, host information, and SDK exception information for different exception types; a calculation module for obtaining exception impact parameters corresponding to each exception type of the target SDK based on the SDK information, host information, and SDK exception information for each exception type, wherein the target SDK corresponds to the host program indicated by the host information and the SDK version indicated by the SDK information; a strategy configuration module for obtaining a target SDK repair strategy based on the exception impact parameters corresponding to each exception type of the target SDK and preset exception classification processing rules, wherein the target SDK repair strategy includes SDK repair strategies for exception levels corresponding to the exception impact parameters in the exception classification processing rules; and a distribution module for distributing the target SDK repair strategy to a user terminal, so that the user terminal executes the target SDK repair strategy to repair the target SDK.
[0008] Fourthly, embodiments of this application provide a user terminal, including: a sending module, configured to provide a repair platform with software development kit (SDK) information, host information, and SDK exception information of different exception types, so that the repair platform obtains a target SDK repair strategy based on exception impact parameters corresponding to each exception type of the target SDK and preset exception classification processing rules. The target SDK repair strategy includes an SDK repair strategy for the exception level corresponding to the exception impact parameters in the exception classification processing rules. The target SDK corresponds to the host program indicated by the host information and the SDK version indicated by the SDK information. The exception impact parameters corresponding to each exception type of the target SDK are obtained based on the SDK information, host information, and SDK exception information of each exception type; a receiving module, configured to obtain the target SDK repair strategy from the repair platform; and an execution module, configured to execute the target SDK repair strategy to repair the target SDK.
[0009] Fifthly, embodiments of this application provide an electronic device applied to a repair platform. The electronic device includes: a processor and a memory storing computer program instructions; when the processor executes the computer program instructions, it implements the repair method of the SDK of the first aspect.
[0010] In a sixth aspect, embodiments of this application provide a user terminal, including: a processor and a memory storing computer program instructions; the processor executes the computer program instructions to implement the repair method of the SDK in the second aspect.
[0011] In a seventh aspect, embodiments of this application provide an SDK repair system, comprising: a repair platform for executing the SDK repair method of the first aspect; and a user terminal for executing the SDK repair method of the second aspect.
[0012] Eighthly, embodiments of this application provide a computer-readable storage medium storing computer program instructions, which, when executed by a processor, implement the repair method of the SDK of the first aspect or the repair method of the SDK of the second aspect.
[0013] This application provides an SDK repair method, apparatus, terminal, device, system, and medium. The repair platform can obtain anomaly impact parameters characterizing the impact of different anomaly types on the SDK based on SDK information, host information, and collected SDK anomaly information of different anomaly types. Based on the anomaly impact parameters corresponding to each anomaly type and preset anomaly classification processing rules, it obtains an SDK repair strategy corresponding to the anomaly level and sends it to the user terminal. The user terminal can execute the SDK repair strategy corresponding to the anomaly level to repair the SDK. Different host information corresponds to different host programs, different host programs correspond to different channel providers, and different versions of SDKs also correspond to different SDK information. Different versions of SDKs embedded in host programs of different channel providers generate different SDK anomaly information. By collecting SDK anomaly information, an SDK repair strategy corresponding to the anomaly level of each version of SDK embedded in the host program of each channel provider can be obtained. That is, an appropriate SDK repair strategy can be automatically assigned to different versions of SDKs embedded in host programs of different channel providers, thereby meeting the repair needs of SDKs from different channel providers. Attached Figure Description
[0014] To more clearly illustrate the technical solutions of the embodiments of this application, the accompanying drawings used in the embodiments of this application will be briefly introduced below. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.
[0015] Figure 1This is a schematic diagram illustrating an example application scenario of the repair method of the SDK provided in the embodiments of this application;
[0016] Figure 2 This is a schematic diagram illustrating another example of an application scenario for the repair method of the SDK provided in the embodiments of this application;
[0017] Figure 3 A flowchart illustrating a repair method for an SDK provided in an embodiment of the first aspect of this application;
[0018] Figure 4 A flowchart of a repair method for an SDK provided in another embodiment of the first aspect of this application;
[0019] Figure 5 A flowchart illustrating a repair method for an SDK provided in yet another embodiment of the first aspect of this application;
[0020] Figure 6 A flowchart illustrating a repair method for an SDK provided in an embodiment of the second aspect of this application;
[0021] Figure 7 A flowchart illustrating a repair method for an SDK provided in another embodiment of the second aspect of this application;
[0022] Figure 8 A flowchart illustrating a repair method for an SDK provided in yet another embodiment of the second aspect of this application;
[0023] Figure 9 A logical schematic diagram illustrating an example of a repair method for the SDK provided in an embodiment of this application;
[0024] Figure 10 A schematic diagram of the structure of a repair device for an SDK provided in an embodiment of the third aspect of this application;
[0025] Figure 11 This is a schematic diagram of the structure of a user terminal provided in an embodiment of the fourth aspect of this application;
[0026] Figure 12 This is a schematic diagram of the structure of an electronic device provided according to an embodiment of the fifth aspect of this application. Detailed Implementation
[0027] The features and exemplary embodiments of various aspects of this application will be described in detail below. To make the objectives, technical solutions, and advantages of this application clearer, the application will be further described in detail below with reference to the accompanying drawings and specific embodiments. It should be understood that the specific embodiments described herein are only intended to explain this application and not to limit it. For those skilled in the art, this application can be implemented without some of these specific details. The following description of the embodiments is merely to provide a better understanding of this application by illustrating examples.
[0028] A Software Development Kit (SDK) is a toolkit that provides a specific function for a software framework, hardware platform, operating system, or application. SDKs can be embedded into various host systems such as software frameworks, hardware platforms, operating systems, or applications from different channels. When running alongside a host, an SDK may encounter exceptions, requiring fixes to ensure proper functioning. However, due to differences in channel providers, their development methods, and host environments, the defects encountered by the SDK may vary, making it difficult to meet the diverse needs of different channel providers for SDK fixes.
[0029] This application provides a method, apparatus, terminal, device, system, and medium for repairing an SDK. The repair platform can obtain anomaly impact parameters characterizing the impact of different anomaly types on the SDK based on SDK information, host information, and collected SDK anomaly information of different anomaly types. Based on the anomaly impact parameters corresponding to each anomaly type and preset anomaly classification processing rules, it obtains an SDK repair strategy corresponding to the anomaly level and sends it to the user terminal. The user terminal can execute the SDK repair strategy corresponding to the anomaly level to repair the SDK. Different channel providers have different host information, different SDK versions have different SDK information, and different channel providers and different SDK versions generate different SDK anomaly information. Through this different information, an SDK repair strategy corresponding to the anomaly level for each channel provider and each SDK version can be obtained. That is, different channel providers and different SDK versions can obtain corresponding adapted SDK repair strategies, which can meet the SDK repair needs of different channel providers.
[0030] The SDK repair method provided in this application can be applied to SDK repair scenarios, and may involve repair platforms and user terminals. Figure 1 This is a schematic diagram illustrating an example application scenario of the repair method of the SDK provided in this application embodiment. For example... Figure 1 As shown, user terminal 11 can communicate and interact with repair platform 12.
[0031] User terminal 11 has at least one host program 111 and at least one SDK 112. Multiple different host programs 111 can exist in the same user terminal, each corresponding to a different channel. SDK 112 can be embedded in the host program 111, and the host program 111 can call SDK 112 to use the functions provided by SDK 112. User terminal 11 may specifically include mobile phones, tablets, computers, smart wearable devices, etc., and is not limited thereto. SDK 112 can act as an information provider, providing the repair platform 12 with SDK information, SDK exception information, and host information of the host program 111 containing SDK 112. User terminal 11 can obtain targeted SDK repair strategies from the repair platform 12 and execute these strategies to repair SDK 112, which is the object of repair.
[0032] The repair platform 12 can be a backend system for providing SDK repair services to user terminals, and may include one or more electronic devices. These electronic devices may include servers, gateways, routers, etc., and the type and number of electronic devices in the repair platform 12 are not limited here. The repair platform 12 can provide SDK repair services to multiple user terminals 11. The host programs 111 in different user terminals may be the same or different. The repair platform 12 can maintain the correspondence between different channel providers, host programs, users, SDKs, SDK exception information, and SDK repair strategies, and can classify and summarize the exception types of SDK exceptions, and perform actions such as alarms and prompts. The repair platform 12 can issue targeted repair strategies to different user terminals 11 for the SDKs 112 that need repair in that user terminal 11. Furthermore, the repair platform 12 can issue targeted repair strategies to user terminals through full rollout, gray-scale rollout, or targeted user rollout, which is not limited here.
[0033] In some embodiments, the repair method of the SDK provided in this application may also involve a channel platform. Figure 2 This is a schematic diagram illustrating another example of an application scenario for the repair method of the SDK provided in the embodiments of this application. For example... Figure 2 As shown, the channel platform 13 can communicate and interact with the repair platform 12.
[0034] Channel platform 13 can serve as an auditing platform for SDK repair strategies and may include one or more electronic devices. These electronic devices may include servers, gateways, routers, etc., and the type and number of electronic devices in channel platform 13 are not limited here. Each channel partner can open an account on channel platform 13 to audit the SDK repair strategies provided by SDK 112 embedded in the host program 111 for the channel partner. The SDK repair strategies provided for SDK 112 embedded in the host program 111 can first be sent to channel platform 13 corresponding to the host program 111 for auditing. Only after channel platform 13 approves the SDK repair strategy will repair platform 12 distribute the SDK repair strategy to user terminal 11. In some examples, channel platform 13 may also provide SDK anomaly information to repair platform 12.
[0035] The following describes the repair methods, devices, terminals, equipment, systems, and media of the SDK in this application.
[0036] The first aspect of this application provides a repair method for an SDK that can be applied to a repair platform, meaning that the repair method of the SDK can be executed by the repair platform. Figure 3 A flowchart illustrating a repair method for an SDK provided in an embodiment of the first aspect of this application. Figure 3 As shown, the repair method of this SDK may include steps S201 to S204.
[0037] In step S201, SDK information, host information, and SDK exception information of different exception types are obtained.
[0038] SDK information includes basic SDK information, such as the SDK version, which is not limited here. SDK information may indicate the SDK version. Host information includes information about the host program embedded in the SDK, such as the host program identifier, the channel identifier of the host program, and the host program environment information, which is not limited here. Host information may indicate the host program, and the host program and the channel have a corresponding relationship. Exception types are the exception types of the SDK, which can be set according to scenarios, requirements, experience, etc. For example, exception types may include, but are not limited to, data exception types, file input / output exception types, business unreachability exception types, and crash exception types. One SDK exception message corresponds to one SDK exception. One SDK exception message includes information related to an exception that occurred in the SDK, such as the SDK exception description, the channel identifier of the host program embedded in the SDK where the exception occurred, whether the SDK exception was reported by the channel, the SDK launch time, the users affected by the SDK exception, the types of terminals affected by the SDK exception, the business success rate of the SDK where the exception occurred, and the business importance of the SDK where the exception occurred, which is not limited here.
[0039] In some examples, SDK exception information includes first SDK exception information and / or second SDK exception information. The first SDK exception information is provided by the user terminal, and the second SDK exception information is provided by the channel platform. Furthermore, the first SDK exception information can be provided by the SDK on the user terminal where the exception occurred. The first SDK exception information can be obtained from the SDK logs on the user terminal, and the second SDK exception information can be obtained from the channel platform logs. The first SDK exception information may also include event tracking information to facilitate subsequent analysis and tracing back to the location, time, and cause of the SDK exception. The second SDK exception information may be exception information and runtime information entered by technical personnel from the channel platform.
[0040] In step S202, based on the SDK information, host information, and SDK exception information for each exception type, the exception impact parameters corresponding to each exception type of the target SDK are obtained.
[0041] The target SDK corresponds to the host program indicated by the host information and the SDK version indicated by the SDK information. The target SDK can be determined based on the host information and SDK information. Different target SDKs may have different SDK exception information, and the impact of different SDK exception information on the SDK will also differ. Exception impact parameters characterize the degree of impact of SDK exceptions on the SDK. The exception impact parameter corresponding to each exception type of the target SDK guarantees the degree of impact of SDK exceptions of that type on the target SDK. Different exception types of different target SDKs may correspond to different exception impact parameters; for example, different versions of SDKs in different host programs may correspond to different exception types with different exception impact parameters. The same exception type of different target SDKs may correspond to different exception impact parameters; for example, different versions of SDKs in different host programs may correspond to different exception types with different exception impact parameters; the same version of SDKs in different host programs may correspond to different exception types with different exception impact parameters; and different versions of SDKs in the same host program may correspond to different exception types with different exception impact parameters.
[0042] Anomaly impact parameters can be parameters calculated using a standardization algorithm that characterize the degree of impact of SDK anomalies on the SDK; that is, the anomaly impact parameters are standardized and comparable. For example, the anomaly impact parameters corresponding to different anomaly types of different target SDKs are comparable. In some examples, corresponding calculated values and weights can be pre-set for at least some SDK anomaly information to establish a unified standard, thereby making the anomaly impact parameters corresponding to different anomaly types under different target SDKs, calculated using a weighting algorithm, standardized and comparable.
[0043] In step S203, a target SDK repair strategy is obtained based on the exception impact parameters corresponding to each exception type of the target SDK and the preset exception classification and processing rules.
[0044] The anomaly classification and handling rules can include the correspondence between anomaly type, anomaly impact parameters, anomaly level, and SDK repair strategy. The target SDK repair strategy includes the SDK repair strategy corresponding to the anomaly level in the anomaly classification and handling rules. That is, based on the anomaly impact parameters corresponding to each anomaly type of the target SDK, the anomaly level and SDK repair strategy corresponding to the anomaly type and impact parameters of the target SDK can be determined in the anomaly classification and handling rules, and the determined SDK repair strategy can then be used as the target SDK repair strategy.
[0045] The anomaly level reflects the severity of the anomaly, and different anomaly levels correspond to different target SDK repair strategies. The higher the severity of the anomaly, the more comprehensive the repair required by the SDK strategy. Similarly, for a lower severity anomaly, a less comprehensive SDK repair strategy can be used to fix it. In other words, the higher the anomaly level, the more comprehensive the repair required by the SDK strategy.
[0046] The exception classification handling rules can record multiple SDK repair strategies. Different SDK repair strategies have different repair levels and can repair SDK exceptions of varying severity. The exception classification handling rules can be used to select the appropriate SDK repair strategy for the target SDK. For example, suppose there are two SDKs, SDK1 and SDK2. Based on the exception type and exception impact parameters of the two SDKs, SDK1 is determined to have an exception level of three, and SDK2 to have an exception level of one. Since the severity of an exception at level three is higher than that at level one, a higher-level SDK repair strategy is assigned to SDK1, and a lower-level SDK repair strategy is assigned to SDK2.
[0047] In some examples, the target SDK repair strategy may include, but is not limited to, one or more of the following: first file, second file, and third file.
[0048] The first file includes cache data clearing instructions, which instruct the clearing of data from at least one cache folder corresponding to the target SDK. These instructions can be further subdivided into different levels of sub-instructions based on the relative severity of the repair. For example, a cache data clearing instruction might include a first sub-instruction and a second sub-instruction. The first sub-instruction can be used to instruct the clearing of data from a specific cache folder corresponding to the target SDK, while the second sub-instruction can be used to instruct the clearing of data from all cache folders corresponding to the target SDK. Compared to the first sub-instruction, the second sub-instruction provides a higher level of repair. Cache data clearing instructions can be implemented using command statements, and the type of command statement is not limited here.
[0049] The second document includes exception source blocking instructions. These instructions instruct the on / off state of at least one business function and / or sub-business function of the target SDK. The SDK may have multiple business functions, and each business function may also have at least one sub-business function. The business functions and sub-business functions may be structured in a tree structure. Correspondingly, the on / off states of the business functions and sub-business functions may also be structured in a tree structure. Each business function and sub-business function can be controlled to be enabled or disabled by setting its on / off state.
[0050] Anomaly source blocking instructions can be categorized into different levels based on the relative degree of repair. Different anomaly types and impact parameters result in different anomaly levels, each corresponding to a different anomaly source blocking instruction. These instructions indicate the closure of different business functions and / or sub-business functions. For example, at an anomaly level of two, the anomaly source blocking instruction in the second file instructs that the on / off state of both business function 1 and business function 2 in the target SDK be set to the off state; at an anomaly level of one, the instruction in the second file instructs that the on / off state of business function 1 in the target SDK be set to the off state. In some examples, the on / off state settings for business functions can be implemented as strings, such as "111110," which indicates that the sixth business function out of six is set to the off state. Anomaly source blocking instructions can execute configuration actions during the initialization of business functions and / or sub-business functions.
[0051] The third file includes patch files, which are used to upgrade and fix the target SDK. Patch files contain difference files between the SDK files before and after the fix. Patch files can fix specific areas of the SDK that need fixing. In some examples, the third file may be an APK file.
[0052] In some examples, the target SDK remediation strategy includes a third file. The remediation platform can generate a patch file. Specifically, the remediation platform can obtain the pre-remediation SDK archive file and the post-remediation SDK archive file of the target SDK; obtain a first class file and a second class file, the first class file including the class files in the pre-remediation SDK archive file, and the second class file including the class files in the post-remediation SDK archive file; use a comparison algorithm to compare the first class file and the second class file to obtain a third class file, the third class file including the class files that differ between the second class file and the first class file; and convert the third class file into a patch file.
[0053] The SDK archive files before and after repair can be either ARR or JAR files. If they are ARR files, they can be decompressed to extract the JAR file. The JAR file includes class files and a manifest file; these can also be decompressed to extract the class files, resulting in the first and second class files. The third class file can be compressed into a JAR file and then converted into a DEX file using the Gradletransform Application Programming Interface (API). The DEX file is the patch file. This DEX file is readable; when scanned, it contains readable statements and classes, facilitating review and preventing situations where the patch cannot be restored to readable form.
[0054] The third file enables hot-fixing of the SDK. The patch file in the third file can be different for different versions of the SDK embedded in different host programs.
[0055] The first, second, and third files mentioned above can also be combined with each other. In some examples, the repair level of the target SDK repair strategy obtained by combining two or more files is higher than the repair level of the target SDK repair strategy corresponding to any one of the two or more files. For example, the repair level of the target SDK repair strategy including the first and second files is higher than the repair level of the target SDK repair strategy including only the first file.
[0056] In step S204, a target SDK repair policy is sent to the user terminal so that the user terminal can execute the target SDK repair policy to repair the target SDK.
[0057] Specifically, the repair platform can distribute the target SDK repair policy to the user terminals where the target SDK is located. There is no limit to the number of user terminals where the target SDK is located; the repair platform can distribute the target SDK repair policy to all user terminals where the target SDK is located, or it can use a phased distribution approach, distributing the target SDK repair policy to user terminals where the target SDK is located in batches, or it can distribute the target SDK repair policy to specific user terminals where the target SDK is located. The target SDK repair policy can be sent to the user terminal as a file or in other forms; the form of the target SDK repair policy is not limited here.
[0058] After the user terminal obtains the target SDK repair policy, it executes the target SDK repair policy to repair the target SDK.
[0059] In some examples, the user terminal can establish a dedicated repair process to execute the target SDK repair strategy; that is, the target SDK repair strategy is executed by the repair process. This repair process is independent of the target SDK process. Even if the target SDK process is interrupted, the repair process can record the repair progress, unaffected by the interruption of the target SDK process. When the target SDK process restarts, the repair can continue according to the repair progress without having to start the repair process again, thus improving the efficiency of SDK repair.
[0060] In this embodiment, the repair platform can obtain anomaly impact parameters characterizing the impact of different anomaly types on the SDK based on SDK information, host information, and collected SDK anomaly information of different anomaly types. Based on the anomaly impact parameters corresponding to each anomaly type and preset anomaly classification processing rules, it obtains an SDK repair strategy corresponding to the anomaly level and sends it to the user terminal. The user terminal can execute the SDK repair strategy corresponding to the anomaly level to repair the SDK. Different host information corresponds to different host programs, different host programs correspond to different channel providers, and different versions of SDKs also correspond to different SDK information. Different versions of SDKs embedded in host programs of different channel providers generate different SDK anomaly information. By collecting SDK anomaly information, an SDK repair strategy corresponding to the anomaly level of each version of SDK embedded in the host program of each channel provider can be obtained. That is, an appropriate SDK repair strategy can be automatically assigned to different versions of SDKs embedded in host programs of different channel providers, thereby meeting the repair needs of SDKs from different channel providers.
[0061] In some embodiments, the anomaly impact parameter for each anomaly type can be determined by combining the impact of each anomaly type on the SDK and the number of times each anomaly type occurs in the SDK. Furthermore, the target SDK repair strategy can be determined based on the anomaly type with the largest anomaly impact parameter value, the anomaly impact parameter for that anomaly type, and anomaly classification handling rules. Figure 4 A flowchart of a repair method for an SDK provided in another embodiment of the first aspect of this application. Figure 4 and Figure 3 The difference is that, Figure 3 Step S202 can be further refined as follows: Figure 4 Steps S2021 to S2024 in the process, Figure 3 Step S203 can be further refined as follows: Figure 4 Steps S2031 and S2032 in the process.
[0062] In step S2021, the target SDK is determined based on the SDK information and the host information, and the feature information and the weight of the feature information in the SDK exception information of each exception type of the target SDK are obtained.
[0063] The repair platform will obtain a large amount of SDK information, host information, and SDK exception information. In order to provide appropriate SDK repair strategies for different versions of SDKs embedded in different host programs, for a version of SDK embedded in a host program, it is necessary to obtain an SDK repair strategy that is appropriate for the SDK based on the SDK exception information related to the SDK.
[0064] Based on the SDK information and host information, the SDK version and the host program embedded in the SDK can be determined, thus identifying the target SDK. SDK information, host information, and SDK exception information are obtained in groups; that is, for each SDK exception, corresponding SDK information, host information, and SDK exception information can be provided. Once the target SDK is identified, SDK exception information for each exception type of the target SDK can be aggregated. In addition to exception descriptions, SDK exception information may also include characteristic information, which can characterize at least some features of the SDK exception. In some examples, characteristic information may include, but is not limited to, the channel identifier of the host program embedded in the SDK that caused the exception, whether the SDK exception received feedback from the channel, the SDK's launch time, the users affected by the SDK exception, the types of terminals affected by the SDK exception, the business success rate of the SDK that caused the exception, and the business importance of the SDK that caused the exception.
[0065] Weights can be pre-set for feature information. Different types of feature information can have different weights. The weight settings can be determined based on application scenarios, requirements, experience, etc., and are not limited here. The sum of the weights of all types of feature information can be 1.
[0066] In step S2022, based on the feature information and the weight of the feature information, the anomaly impact factor corresponding to each anomaly type of the target SDK is calculated.
[0067] For SDK anomaly information of a given anomaly type, the product of the value of each category of feature information and its respective weight can be calculated first. The sum of these products is then used to determine the anomaly impact factor corresponding to that anomaly type in the target SDK. In some examples, the value of the feature information can be its original value. In other examples, the value of the feature information can be the original value after processing, such as after normalization or standardization, or determined according to a preset classification rule based on the category to which the original value of each category of feature information belongs.
[0068] For example, the characteristic information includes the channel identifier of the host program embedded in the SDK that caused the exception, whether the SDK received feedback from the channel, the business success rate of the SDK that caused the exception, and the business importance of the SDK that caused the exception. For example, for a specific exception type of the target SDK, the channel identifier of the host program embedded in the SDK that caused the exception is AA, the SDK received feedback from the channel, the business success rate of the SDK that caused the exception is 85%, and the business importance of the SDK that caused the exception is medium. The preset classification rules are shown in Tables 1 to 4 below. Table 1 represents the classification rules based on the original value of the channel identifier of the host program embedded in the SDK that caused the exception; Table 2 represents the classification rules based on the original value of whether the SDK received feedback from the channel; Table 3 represents the classification rules based on the business success rate of the SDK that caused the exception; and Table 4 represents the classification rules based on the business importance of the SDK that caused the exception.
[0069] Table 1
[0070]
[0071] Table 2
[0072]
[0073] Table 3
[0074]
[0075] Table 4
[0076]
[0077] If the channel identifier of the host program embedded in the SDK that caused the exception, whether the exception occurred was reported by the channel, the business success rate of the SDK that caused the exception, and the business importance of the SDK that caused the exception have corresponding weights of d1, d2, d3, and d4, respectively, then according to Table 1 and Table 4 above, the exception impact factor α corresponding to this exception type of the target SDK can be obtained according to the following formula (1):
[0078] α= c1×d1+ c3×d2+ c7×d3+ c9×d4 (1)
[0079] An anomaly impact factor corresponding to an anomaly type can characterize the impact of SDK anomalies of that type on the SDK. This impact reflects the influence of the anomaly type on the SDK in terms of feature information.
[0080] In step S2023, the output ratio corresponding to each exception type of the target SDK is calculated based on the number of SDK exception information for each exception type of the target SDK and the total number of SDK exception information.
[0081] The output ratio for a specific exception type in the target SDK represents the proportion of that exception type among all exception types in the target SDK. Specifically, the output ratio for a specific exception type in the target SDK can be the ratio of the number of SDK exception messages of that exception type to the total number of SDK exception messages of all exception types in the target SDK. For example, if the target SDK has n exception types, and the number of exception messages for each of the n exception types is... to Then the output ratio corresponding to the i-th anomaly type can be obtained according to the following formula (2):
[0082] (2)
[0083] in, This represents the output ratio corresponding to the i-th anomaly type; The number of exception messages for the first exception type; Let n be the number of exception messages for the i-th exception type, where 1 ≤ i ≤ n; This represents the number of exception messages for the nth exception type.
[0084] In step S2024, the abnormal impact parameters corresponding to each abnormal type of the target SDK are calculated using the abnormal impact factor and output ratio corresponding to each abnormal type of the target SDK.
[0085] In addition to reflecting the impact of the anomaly type on the SDK in terms of feature information, the anomaly impact parameter can also reflect the impact of the proportion of the anomaly type appearing among all anomaly types in the SDK. The product of the anomaly impact factor corresponding to an anomaly type of the target SDK and the output ratio corresponding to that anomaly type can be used as the anomaly impact parameter corresponding to that anomaly type of the target SDK. For example, the anomaly impact parameter corresponding to the i-th anomaly type can be obtained according to the following formula (3):
[0086] (3)
[0087] in, For the i-th exception type, the exception impact parameter is used. This is the abnormality impact factor corresponding to the i-th abnormality type; Let be the output ratio corresponding to the i-th anomaly type.
[0088] In step S2031, the target anomaly type is determined based on the anomaly impact parameters corresponding to each anomaly type.
[0089] The target anomaly type is the anomaly type corresponding to the anomaly impact parameter with the largest value. For example, suppose the target SDK has SDK anomaly information with four anomaly types. The values of the anomaly impact parameters corresponding to the first anomaly type to the fourth anomaly type are f1, f2, f3 and f4 respectively. If f2 < f4 < f1 < f3, then the target anomaly type is the third anomaly type.
[0090] In step S2032, based on the anomaly classification processing rules, the anomaly level corresponding to the target anomaly type and the anomaly impact parameter of the target anomaly type is determined, and the target SDK repair strategy is determined based on the anomaly level.
[0091] The exception impact parameter corresponding to each exception type of the target SDK guarantees the degree of impact of that type of SDK exception on the target SDK. The exception type corresponding to the exception impact parameter with the largest value is the exception type that has the greatest impact on the target SDK among all exception types. The target exception type and its corresponding exception impact parameter can reflect which type of SDK exception mainly caused the impact on the target SDK, and the degree of impact of that type of SDK exception on the target SDK. Different target exception types and different values of exception impact parameters may correspond to different exception levels in the exception classification and handling rules, and the corresponding target SDK repair strategies may also be different.
[0092] For example, suppose the exception types include four types: data exception, file input / output exception, service unreachability exception, and crash exception. If the target exception type is a data exception or a file input / output exception, the exception level can be minor, and the corresponding target SDK repair strategy can include the first file in the above embodiments; if the target exception type is a service unreachability exception, the exception level can be medium, and the corresponding target SDK repair strategy can include the second file in the above embodiments; if the target exception type is a crash exception, the exception level can be severe, and the corresponding target SDK repair strategy can include the third file in the above embodiments.
[0093] In some embodiments, to ensure that the target SDK repair policy is delivered to the user terminal and only applies to the target SDK, a signature reflecting the host program (i.e., the channel provider) can be added to the target SDK repair policy. Specifically, the target SDK repair policy may also include a first signature file. The repair platform can generate the first signature based on the host information, and generate a first signature file based on the first signature. The first signature file includes the first signature. The signature algorithm used to generate the first signature is not limited here; for example, the first signature can be generated using the SM3 signature algorithm based on the host information.
[0094] After obtaining the target SDK repair policy, the user terminal can verify the first signature to determine the target SDK for which the repair policy applies, and then execute the target SDK repair policy to repair the target SDK. The host program can be invoked to verify the first signature. Successful verification indicates that the host program possesses the target SDK and can repair the target SDK embedded in the host program; failure to verify indicates that the host program does not possess the target SDK and will not repair the SDK embedded in the host program.
[0095] In some embodiments, after the repair platform obtains the target SDK repair strategy, the repair platform can send the target SDK repair strategy to the channel platform for review. Only if the channel platform approves the review will the target SDK repair strategy be sent to the user terminal to ensure the security of the target SDK repair strategy. Figure 5 A flowchart of a repair method for an SDK provided in yet another embodiment of the first aspect of this application. Figure 5 and Figure 3 The difference is that, Figure 5 The repair method for the SDK shown may further include steps S205 and S206. Figure 3 Step S204 can be further refined as follows: Figure 5 Step S2041 in the process.
[0096] In step S205, the target SDK repair strategy is sent to the channel platform.
[0097] The channel platform receives the target SDK repair strategy, can scan the target SDK repair strategy to obtain its content, and then review the target SDK repair strategy.
[0098] If the target SDK remediation strategy is approved, the channel platform authorizes the strategy, generates a second signature based on the host information, and then generates a second signature file containing the second signature. The channel platform adds the second signature file to the target SDK remediation strategy and sends the strategy back to the remediation platform. In some examples, the channel platform can use its own signature algorithm to sign the hash value of the target SDK remediation strategy using the host information, thus obtaining the second signature.
[0099] If a target SDK remediation strategy fails the review, the channel platform will not authorize it. The channel platform can send a notification message to the remediation platform informing them of the failure. If the channel platform detects that the target SDK remediation strategy is not authorized, the remediation platform must not issue the target SDK remediation strategy.
[0100] In step S206, the target SDK repair strategy is received from the channel platform.
[0101] The feedback target SDK remediation strategy includes a second signing file. This second signing file contains a second signature. The second signature is generated by the channel platform based on host information after scanning and authorizing the target SDK remediation strategy.
[0102] In step S2041, the target SDK repair strategy fed back by the channel platform is sent to the user terminal.
[0103] The repair platform can interact with channel platforms, allowing them to review target SDK repair strategies. Only after channel platform approval is the repair platform permitted to distribute the target SDK repair strategy to user terminals, ensuring the security of the target SDK repair strategy. Furthermore, channel platforms can identify the channel to which the target SDK's host application belongs through a second signature. When a user terminal receives the target SDK repair strategy, it can verify the second signature using the host application's host information. The target SDK repair strategy only applies to target SDKs within host applications whose signatures have been verified, ensuring the targeted effectiveness of the target SDK repair strategy.
[0104] The second aspect of this application provides a repair method for an SDK that can be applied to a user terminal, that is, the repair method of the SDK can be executed by the user terminal. Figure 6 A flowchart illustrating a repair method for an SDK provided in an embodiment of the second aspect of this application. For example... Figure 6 As shown, the repair method of this SDK may include steps S301 and S302.
[0105] In step S301, the software development kit (SDK) information, host information, and SDK exception information of different exception types are provided to the repair platform so that the repair platform can obtain the target SDK repair strategy based on the exception impact parameters corresponding to each exception type of the target SDK and the preset exception classification and processing rules.
[0106] The target SDK remediation strategy includes SDK remediation strategies for the exception levels corresponding to the exception impact parameters in the exception classification handling rules. The target SDK corresponds to the host program indicated by the host information and the SDK version indicated by the SDK information. The exception impact parameters corresponding to each exception type of the target SDK are obtained based on the SDK information, host information, and SDK exception information for each exception type.
[0107] In step S302, the target SDK repair strategy is obtained from the repair platform and the target SDK repair strategy is executed to repair the target SDK.
[0108] In some examples, during initialization, the target SDK can establish a repair process and send host information, SDK information, user information, etc., to the repair platform. The repair platform can then use the host and SDK information to find the target SDK repair policy corresponding to those information and issue the target SDK repair policy. The user terminal downloads the target SDK repair policy from the repair platform and executes the policy through the repair process to repair the target SDK.
[0109] In some examples, the target SDK remediation strategy includes, but is not limited to, one or more of the following: first file, second file, and third file.
[0110] The first file includes cache data clearing instructions, which instruct the clearing of data in at least one cache folder corresponding to the target SDK. When the target SDK repair strategy includes the first file, the user terminal can clear dirty data in the target SDK's cache folder according to the cache data clearing instructions.
[0111] The second document includes an anomaly source blocking instruction, which instructs that the on / off state of at least one service function and / or sub-service function of the target SDK be set to the off state. When the target SDK repair strategy includes the second document, the user terminal can set the on / off state of the service function and / or sub-service function indicated by the anomaly source blocking instruction to the off state according to the anomaly source blocking instruction.
[0112] The third file includes patch files, which are used to upgrade and repair the target SDK. When the target SDK repair strategy includes a third file, the user terminal can extract the patch files from the third file and load the repaired classes according to the class loading method to complete the target SDK repair.
[0113] In some examples, the target SDK repair strategy includes a third file, the patch file is converted from a third class file, the third class file includes class files that differ from the second class file and the first class file, the first class file includes class files from the target SDK's pre-repair SDK archive file, and the second class file includes class files from the target SDK's post-repair SDK archive file.
[0114] The specific contents of the first, second, and third documents mentioned above can be found in the relevant descriptions in the above embodiments, and will not be repeated here.
[0115] The specific details of steps S301 and S302 can be found in the relevant descriptions in the above embodiments, and will not be repeated here.
[0116] In this embodiment, the repair platform can obtain anomaly impact parameters characterizing the impact of different anomaly types on the SDK based on SDK information, host information, and collected SDK anomaly information of different anomaly types. Based on the anomaly impact parameters corresponding to each anomaly type and preset anomaly classification processing rules, it obtains an SDK repair strategy corresponding to the anomaly level and sends it to the user terminal. The user terminal can execute the SDK repair strategy corresponding to the anomaly level to repair the SDK. Different host information corresponds to different host programs, different host programs correspond to different channel providers, and different versions of SDKs also correspond to different SDK information. Different versions of SDKs embedded in host programs of different channel providers generate different SDK anomaly information. By collecting SDK anomaly information, an SDK repair strategy corresponding to the anomaly level of each version of SDK embedded in the host program of each channel provider can be obtained. That is, an appropriate SDK repair strategy can be automatically assigned to different versions of SDKs embedded in host programs of different channel providers, thereby meeting the repair needs of SDKs from different channel providers.
[0117] In some embodiments, the anomaly impact parameter corresponding to each type of anomaly in the target SDK is calculated using the anomaly impact factor and output ratio corresponding to each anomaly type of the target SDK. The output ratio corresponding to each anomaly type of the target SDK is calculated based on the number of SDK anomaly information for each anomaly type of the target SDK and the total number of SDK anomaly information. The anomaly impact factor corresponding to each anomaly type of the target SDK is calculated based on the feature information in the SDK anomaly information for each anomaly type of the target SDK, and the weight of the feature information. For details on this part, please refer to the relevant descriptions in the above embodiments, which will not be repeated here.
[0118] In some embodiments, the anomaly level corresponding to the target SDK repair strategy is obtained based on the anomaly classification and processing rules, the target anomaly type, and the anomaly impact parameter of the target anomaly type. The target anomaly type is the anomaly type corresponding to the anomaly impact parameter with the largest value. For details on this, please refer to the relevant descriptions in the above embodiments, which will not be repeated here.
[0119] In some embodiments, the target SDK repair strategy further includes a first signature file, which includes a first signature generated by the repair platform based on host information. For details, please refer to the relevant descriptions in the above embodiments, which will not be repeated here.
[0120] After obtaining the target SDK repair strategy from the repair platform, the user terminal can call the host program indicated by the host information to verify the first signature. If the host program indicated by the host information successfully verifies the first signature, the target SDK repair strategy will be executed to repair the target SDK. The verification algorithm for the first signature can be agreed upon in advance between the user terminal and the repair platform, and is not limited here. The repair platform can generate the first signature using the agreed private key, and the user terminal can verify the first signature using the agreed public key. This verifies both the integrity of the target SDK repair strategy and whether it has been tampered with, and also verifies the uniqueness of the target SDK repair strategy for the host program (i.e., the channel provider), thereby ensuring the content security of the target SDK repair strategy and the access security of the channel provider.
[0121] In some embodiments, the target SDK repair strategy further includes a second signature file, which includes a second signature. The second signature is generated by the channel platform based on the host information after scanning the target SDK repair strategy and determining authorization. For details, please refer to the relevant descriptions in the above embodiments, which will not be repeated here. Figure 7 A flowchart of a repair method for an SDK provided in another embodiment of the second aspect of this application. Figure 7 and Figure 6 The difference is that, Figure 6 Step S302 can be further refined as follows: Figure 7 Steps S3021 to S3023 in the process.
[0122] In step S3021, the target SDK repair strategy is obtained from the repair platform.
[0123] In step S3022, the host program indicated by the host information is invoked to verify the second signature.
[0124] The verification algorithm for the second signature can be pre-agreed upon by the user terminal and the channel platform, and is not limited here. The channel platform can generate the second signature using the agreed private key, and the user terminal can verify the second signature using the agreed public key. This verifies three aspects: first, the integrity of the target SDK repair strategy and whether it has been tampered with; second, the uniqueness of the target SDK repair strategy to the host program (i.e., the channel party); and third, the channel party's approval of the target SDK repair strategy, thereby ensuring the content security of the target SDK repair strategy and the access security of the channel party.
[0125] In step S3023, if the host program, as indicated by the host information, successfully verifies the second signature, the target SDK repair strategy is executed to repair the target SDK.
[0126] In some embodiments, the user terminal may establish a repair process, obtain the target SDK repair strategy from the repair platform through the repair process, and execute the target SDK repair strategy to repair the target SDK. This repair process is independent of the target SDK process, which can minimize the impact of the target SDK process on the SDK repair and improve the SDK repair efficiency. Figure 8 A flowchart of a repair method for an SDK provided in yet another embodiment of the second aspect of this application. Figure 8 and Figure 6 The difference is that, Figure 6 Step S302 can be further refined as follows: Figure 8 Steps S3024 to S3026 in the process.
[0127] In step S3024, the process of the target SDK is monitored by the repair process.
[0128] In step S3025, if the target SDK process is stopped and the target SDK repair strategy is not downloaded before the target SDK repair is completed, the target SDK repair strategy will continue to be downloaded through the repair process until the target SDK repair strategy is downloaded and then the repair process is interrupted. When the target SDK process is restarted, the target SDK repair strategy will be executed through the repair process to repair the target SDK.
[0129] After downloading the target SDK repair strategy, you can encrypt and save the main repair content in the target SDK repair strategy, such as cache data clearing instructions, abnormal source blocking instructions, patch files, etc.
[0130] If the repair process is interrupted for other reasons while downloading the target SDK repair strategy, the breakpoint resume function provided by the user terminal's operating system layer can be used to ensure that the user terminal can obtain the complete target SDK repair strategy.
[0131] In step S3026, if the target SDK process is stopped and the target SDK repair strategy has started before the target SDK repair is completed, the repair progress of the target SDK is recorded through the repair process. When the target SDK process is restarted, the repair process continues to repair the target SDK based on the repair progress.
[0132] As can be seen from the above, whether the host program or the target SDK process is alive or not will not affect the user terminal's acquisition of the target SDK repair strategy, ensuring that the target SDK repair strategy is effectively executed and improving the SDK's repair rate.
[0133] To facilitate understanding, the following logic diagram illustrating the interaction between the user terminal, the repair platform, and the channel platform will explain the SDK's repair methods. Figure 9 This is a logical diagram illustrating an example of a repair method for the SDK provided in an embodiment of this application. Figure 9 As shown, the user terminal 41 contains a host program 411 and an SDK 412. The SDK 412 is embedded in the host program 411, and the user terminal 41 can establish a repair process 413. The repair platform 42 has log analysis function 421, policy configuration function 422, and file management function 423. The channel platform 43 has channel log provision function 431, policy content review function 432, and policy signing function 433.
[0134] The repair platform 42 can obtain SDK logs from SDK 412, which may include host information, SDK information, and SDK exception information. The repair platform 42 can also obtain channel logs from the channel platform 43, whose channel log provision function 431 provides channel logs. The log analysis function 421 in the repair platform 42 can extract host information, SDK information, and SDK exception information from the logs. The policy configuration function 422 can obtain host information, SDK information, and SDK exception information from the log analysis function 421, determine the exception level based on the host information, SDK information, and SDK exception information, and determine the target SDK repair strategy corresponding to the exception level. The file management function 423 manages various SDK repair strategies. The policy configuration function 422 can obtain the target SDK repair strategy from the file management function 423. The repair platform 42 sends the target SDK repair strategy to the channel platform 43. Channel platform 43 reviews the target SDK repair strategy through policy content review function 432. If the review is successful, it signs the target SDK repair strategy through policy signing function 433 and sends the signed target SDK repair strategy back to repair platform 42. SDK 412 can send host information and SDK information to repair platform to trigger repair platform 42 to provide target SDK repair strategy to user terminal 41. SDK 412 can start repair process 413, which downloads target SDK repair strategy from repair platform 42. User terminal 41 verifies the signature in target SDK repair strategy through repair process 413. After successful verification, it executes the target SDK repair strategy to repair SDK 412.
[0135] It should be noted that the acquisition, storage, use, and processing of information and data in this application have all been authorized by the user or relevant organization and comply with the relevant provisions of national laws and regulations.
[0136] A third aspect of this application provides a repair device for an SDK. Figure 10This is a schematic diagram of the structure of a repair device for an SDK provided in an embodiment of the third aspect of this application. Figure 10 As shown, the repair device 500 of the SDK may include an acquisition module 501, a calculation module 502, a policy configuration module 503, and a distribution module 504.
[0137] The acquisition module 501 can be used to acquire SDK information, host information, and SDK exception information of different exception types.
[0138] The calculation module 502 can be used to obtain the exception impact parameters corresponding to each exception type of the target SDK based on the SDK information, host information and SDK exception information for each exception type.
[0139] The target SDK corresponds to the host program indicated by the host information and the SDK version indicated by the SDK information.
[0140] The strategy configuration module 503 can be used to obtain the target SDK repair strategy based on the exception impact parameters corresponding to each exception type of the target SDK and the preset exception classification and processing rules.
[0141] In some examples, the target SDK remediation strategy includes one or more of the following:
[0142] The first file includes a cache data clearing instruction, which is used to instruct the clearing of data in at least one cache folder corresponding to the target SDK;
[0143] The second document includes an anomaly source blocking instruction, which is used to instruct the switch state of at least one business function and / or sub-business function of the target SDK to be set to the off state.
[0144] The third file includes patch files, which are used to upgrade and fix the target SDK.
[0145] The target SDK repair strategy includes SDK repair strategies for the exception levels corresponding to the exception impact parameters in the exception classification handling rules.
[0146] The distribution module is used to distribute the target SDK repair policy to the user terminal, so that the user terminal can execute the target SDK repair policy to repair the target SDK.
[0147] In some examples, the target SDK repair strategy is executed by a repair process established by the user terminal, and the repair process is independent of the target SDK process.
[0148] In this embodiment, the repair platform can obtain anomaly impact parameters characterizing the impact of different anomaly types on the SDK based on SDK information, host information, and collected SDK anomaly information of different anomaly types. Based on the anomaly impact parameters corresponding to each anomaly type and preset anomaly classification processing rules, it obtains an SDK repair strategy corresponding to the anomaly level and sends it to the user terminal. The user terminal can execute the SDK repair strategy corresponding to the anomaly level to repair the SDK. Different host information corresponds to different host programs, different host programs correspond to different channel providers, and different versions of SDKs also correspond to different SDK information. Different versions of SDKs embedded in host programs of different channel providers generate different SDK anomaly information. By collecting SDK anomaly information, an SDK repair strategy corresponding to the anomaly level of each version of SDK embedded in the host program of each channel provider can be obtained. That is, an appropriate SDK repair strategy can be automatically assigned to different versions of SDKs embedded in host programs of different channel providers, thereby meeting the repair needs of SDKs from different channel providers.
[0149] In some embodiments, the calculation module 502 can be used to: determine the target SDK based on SDK information and host information, and obtain the feature information and weight of the feature information in the SDK anomaly information of each anomaly type of the target SDK; calculate the anomaly impact factor corresponding to each anomaly type of the target SDK based on the feature information and the weight of the feature information; calculate the output ratio corresponding to each anomaly type of the target SDK based on the number of SDK anomaly information of each anomaly type of the target SDK and the total number of SDK anomaly information; and calculate the anomaly impact parameter corresponding to each anomaly type of the target SDK using the anomaly impact factor and output ratio corresponding to each anomaly type of the target SDK.
[0150] In some embodiments, the strategy configuration module 503 can be used to: determine the target anomaly type based on the anomaly impact parameter corresponding to each anomaly type, wherein the target anomaly type is the anomaly type corresponding to the anomaly impact parameter with the largest value; determine the anomaly level corresponding to the target anomaly type and the anomaly impact parameter of the target anomaly type according to the anomaly classification processing rules; and determine the target SDK repair strategy based on the anomaly level.
[0151] In some embodiments, the target SDK repair strategy includes a third file. The SDK repair apparatus 500 may also include a patch generation module.
[0152] The patch generation module can be used to: obtain the pre-fix SDK archive file and the post-fix SDK archive file of the target SDK; obtain the first class file and the second class file, the first class file including the class files in the pre-fix SDK archive file and the second class file including the class files in the post-fix SDK archive file; use a comparison algorithm to compare the first class file and the second class file to obtain the third class file, the third class file including the class files that differ from the second class file and the first class file; and convert the third class file into a patch file.
[0153] In some embodiments, the target SDK remediation strategy further includes a first signature file. The SDK remediation apparatus may also include a first signature module. The first signature module can be used to: generate a first signature based on host information; and generate a first signature file based on the first signature, the first signature file including the first signature.
[0154] In some embodiments, the repair apparatus of the SDK may further include a receiving module.
[0155] The aforementioned distribution module 504 can also be used to: send the target SDK repair strategy to the channel platform.
[0156] The receiving module can be used to: receive the target SDK repair strategy fed back by the channel platform. The feedback target SDK repair strategy includes a second signature file, which includes a second signature. The second signature is generated by the channel platform based on the host information after scanning the target SDK repair strategy and authorizing it.
[0157] The aforementioned distribution module 504 can be used to: distribute the target SDK repair strategy fed back by the channel platform to the user terminal.
[0158] The fourth aspect of this application provides a user terminal. Figure 11 This is a schematic diagram of the structure of a user terminal provided according to an embodiment of the fourth aspect of this application. Figure 11 As shown, the user terminal 600 may include a sending module 601, a receiving module 602, and an execution module 603.
[0159] The sending module 601 can be used to provide the repair platform with SDK information, host information and SDK exception information of different exception types, so that the repair platform can obtain the target SDK repair strategy based on the exception impact parameters corresponding to each exception type of the target SDK and the preset exception classification and processing rules.
[0160] The target SDK remediation strategy includes SDK remediation strategies for the exception levels corresponding to the exception impact parameters in the exception classification handling rules. The target SDK corresponds to the host program indicated by the host information and the SDK version indicated by the SDK information. The exception impact parameters corresponding to each exception type of the target SDK are obtained based on the SDK information, host information, and SDK exception information for each exception type.
[0161] The receiving module 602 can be used to obtain the target SDK repair strategy from the repair platform.
[0162] In some examples, the target SDK remediation strategy includes one or more of the following:
[0163] The first file includes a cache data clearing instruction, which is used to instruct the clearing of data in at least one cache folder corresponding to the target SDK;
[0164] The second document includes an anomaly source blocking instruction, which is used to instruct the switch state of at least one business function and / or sub-business function of the target SDK to be set to the off state.
[0165] The third file includes patch files, which are used to upgrade and fix the target SDK.
[0166] In some examples, the target SDK repair strategy includes a third file, the patch file is converted from a third class file, the third class file includes class files that differ from the second class file and the first class file, the first class file includes class files from the target SDK's pre-repair SDK archive file, and the second class file includes class files from the target SDK's post-repair SDK archive file.
[0167] Execution module 603 can be used to execute target SDK repair strategies to repair the target SDK.
[0168] In this embodiment, the repair platform can obtain anomaly impact parameters characterizing the impact of different anomaly types on the SDK based on SDK information, host information, and collected SDK anomaly information of different anomaly types. Based on the anomaly impact parameters corresponding to each anomaly type and preset anomaly classification processing rules, it obtains an SDK repair strategy corresponding to the anomaly level and sends it to the user terminal. The user terminal can execute the SDK repair strategy corresponding to the anomaly level to repair the SDK. Different host information corresponds to different host programs, different host programs correspond to different channel providers, and different versions of SDKs also correspond to different SDK information. Different versions of SDKs embedded in host programs of different channel providers generate different SDK anomaly information. By collecting SDK anomaly information, an SDK repair strategy corresponding to the anomaly level of each version of SDK embedded in the host program of each channel provider can be obtained. That is, an appropriate SDK repair strategy can be automatically assigned to different versions of SDKs embedded in host programs of different channel providers, thereby meeting the repair needs of SDKs from different channel providers.
[0169] In some embodiments, the anomaly impact parameter corresponding to each type of anomaly in the target SDK is calculated using the anomaly impact factor and output ratio corresponding to each anomaly type in the target SDK. The output ratio corresponding to each anomaly type in the target SDK is calculated based on the number of SDK anomaly information for each anomaly type and the total number of SDK anomaly information. The anomaly impact factor corresponding to each anomaly type in the target SDK is calculated based on the feature information in the SDK anomaly information for each anomaly type in the target SDK, and the weights of the feature information.
[0170] In some embodiments, the anomaly level corresponding to the target SDK repair strategy is obtained based on the anomaly classification and handling rules, the target anomaly type, and the anomaly impact parameter of the target anomaly type. The target anomaly type is the anomaly type corresponding to the anomaly impact parameter with the largest value.
[0171] In some embodiments, the target SDK repair strategy further includes a first signature file, which includes a first signature generated by the repair platform based on host information.
[0172] The aforementioned execution module 603 can also be used to: call the host program indicated by the host information to verify the first signature; and if the host program indicated by the host information successfully verifies the first signature, execute the target SDK repair strategy to repair the target SDK.
[0173] In some embodiments, the target SDK remediation policy further includes a second signature file, which includes a second signature generated by the channel platform based on host information after scanning the target SDK remediation policy and determining authorization.
[0174] The aforementioned execution module 603 can also be used to: call the host program indicated by the host information to verify the second signature, and if the host program indicated by the host information successfully verifies the second signature, execute the target SDK repair strategy to repair the target SDK.
[0175] In some embodiments, the execution module 603 can be used to: establish a repair process, wherein the repair process is independent of the target SDK process; obtain the target SDK repair strategy from the repair platform through the repair process, and execute the target SDK repair strategy to repair the target SDK.
[0176] In some embodiments, the execution module 603 can be used to: monitor the target SDK process through the repair process; if the target SDK process is stopped and the target SDK repair strategy has not been downloaded before the target SDK repair is completed, the repair process continues to download the target SDK repair strategy until the target SDK repair strategy is downloaded and then the repair process is interrupted; when the target SDK process is restarted, the repair process executes the target SDK repair strategy to repair the target SDK; if the target SDK process is stopped and the target SDK repair strategy has been started before the target SDK repair is completed, the repair process records the target SDK repair progress; when the target SDK process is restarted, the repair process continues to repair the target SDK based on the repair progress.
[0177] The fifth aspect of this application also provides an electronic device. Figure 12 This is a schematic diagram of the structure of an electronic device provided according to an embodiment of the fifth aspect of this application. Figure 12 As shown, the electronic device 700 includes a memory 701, a processor 702, and a computer program stored in the memory 701 and executable on the processor 702.
[0178] In one example, the processor 702 described above may include a central processing unit (CPU), or an application-specific integrated circuit (ASIC), or one or more integrated circuits that can be configured to implement the embodiments of this application.
[0179] Memory 701 may include read-only memory (ROM), random access memory (RAM), disk storage media device, optical storage media device, flash memory device, electrical, optical, or other physical / tangible memory storage device. Therefore, typically, memory includes one or more tangible (non-transitory) computer-readable storage media (e.g., memory devices) encoded with software including computer-executable instructions, and when the software is executed (e.g., by one or more processors), it is operable to perform the operations described with reference to the repair method of the SDK according to the first aspect embodiment of this application.
[0180] The processor 702 runs a computer program corresponding to the executable program code by reading the executable program code stored in the memory 701, so as to implement the SDK repair method in the first aspect embodiment described above.
[0181] In some examples, the electronic device 700 may also include a communication interface 703 and a bus 704. For example, Figure 12 As shown, the memory 701, processor 702, and communication interface 703 are connected through bus 704 and complete communication with each other.
[0182] The communication interface 703 is mainly used to enable communication between various modules, devices, units, and / or equipment in the embodiments of this application. Input devices and / or output devices can also be connected through the communication interface 703.
[0183] Bus 704 includes hardware, software, or both, that couples components of electronic device 700 together. For example, and not as a limitation, bus 704 may include an Accelerated Graphics Port (AGP) or other graphics bus, an Enhanced Industry Standard Architecture (EISA) bus, a Front Side Bus (FSB), a Hyper Transport (HT) interconnect, an Industry Standard Architecture (ISA) bus, an Infinite Bandwidth Interconnect, a Low Pin Count (LPC) bus, a memory bus, a Micro Channel Architecture (MCA) bus, a Peripheral Component Interconnect (PCI) bus, a PCI-Express (PCI-E) bus, a Serial Advanced Technology Attachment (SATA) bus, a Video Electronics Standards Association Local Bus (VLB) bus, or other suitable buses, or a combination of two or more of these. Where appropriate, bus 704 may include one or more buses. Although specific buses are described and illustrated in the embodiments of this application, this application considers any suitable bus or interconnection.
[0184] A sixth aspect of this application provides a user terminal that may include a memory, a processor, and a computer program stored in the memory and executable on the processor.
[0185] The memory includes one or more tangible (non-transitory) computer-readable storage media (e.g., memory devices) encoded with software including computer-executable instructions, and when the software is executed (e.g., by one or more processors), it is operable to perform operations described with reference to the repair method of the SDK according to the second aspect of the present application.
[0186] The processor runs a computer program corresponding to the executable program code by reading the executable program code stored in the memory, in order to implement the SDK repair method in the second aspect embodiment described above.
[0187] In some examples, the user terminal may also include a communication interface and a bus. The memory, processor, and communication interface can be connected via the bus to communicate with each other.
[0188] The connection relationships and specific implementations of the memory, processor, communication interface and bus can be found in the connection relationships and specific implementations of the memory 701, processor 702, communication interface 703 and bus 704 in the electronic device in the above embodiments, and will not be repeated here.
[0189] The seventh aspect of this application provides an SDK repair system, which may include the repair platform and user terminal described in the above embodiments. The repair platform can execute the SDK repair method described in the first aspect embodiment, and the user terminal can execute the SDK repair method described in the second aspect embodiment. For details, please refer to the relevant descriptions in the above embodiments, and the same technical effects can be achieved. To avoid repetition, further details are omitted here.
[0190] In some embodiments, the repair system of the SDK may also include the channel platform in the above embodiments. The channel platform can execute the steps executed by the channel platform in the above embodiments. For details, please refer to the relevant descriptions in the above embodiments, and it can achieve the same technical effect. To avoid repetition, it will not be described again here.
[0191] The eighth aspect of this application provides a computer-readable storage medium storing computer program instructions. When executed by a processor, these instructions can implement the SDK repair method in the embodiments of the first aspect or the SDK repair method in the embodiments of the second aspect, achieving the same technical effect. To avoid repetition, further details are omitted here. The aforementioned computer-readable storage medium may include non-transitory computer-readable storage media, such as read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks, etc., and is not limited thereto.
[0192] This application embodiment can also provide a computer program product, in which the instructions are executed by the processor of an electronic device, causing the electronic device to perform the SDK repair method in the first aspect embodiment or the SDK repair method in the second aspect embodiment. For details, please refer to the relevant descriptions in the above embodiments, and the same technical effect can be achieved. To avoid repetition, it will not be described again here.
[0193] It should be clarified that the various embodiments in this specification are described in a progressive manner, and the same or similar parts between the various embodiments can be referred to mutually. Each embodiment focuses on describing the differences from other embodiments. For the device embodiments, equipment embodiments, user terminal embodiments, system embodiments, computer-readable storage medium embodiments, and computer program product embodiments, the relevant parts can be referred to the description section of the method embodiments. This application is not limited to the specific steps and structures described above and shown in the figures. Those skilled in the art can make various changes, modifications, and additions, or change the order of steps, after understanding the spirit of this application. Furthermore, for the sake of brevity, detailed descriptions of known methods and techniques are omitted here.
[0194] The aspects of this application have been described above with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of this application. It should be understood that each block in the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, or other programmable data processing apparatus to produce a machine such that these instructions, executable via the processor of the computer or other programmable data processing apparatus, enable the implementation of the functions / actions specified in one or more blocks of the flowchart illustrations and / or block diagrams. Such a processor can be, but is not limited to, a general-purpose processor, a special-purpose processor, a special application processor, or a field-programmable logic circuit. It is also understood that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, can also be implemented by dedicated hardware performing the specified functions or actions, or can be implemented by a combination of dedicated hardware and computer instructions.
[0195] Those skilled in the art will understand that the above embodiments are exemplary and not restrictive. Different technical features appearing in different embodiments can be combined to achieve beneficial effects. Based on a study of the drawings, specification, and claims, those skilled in the art should be able to understand and implement other variations of the disclosed embodiments. In the claims, the term "comprising" does not exclude other means or steps; the quantifier "a" does not exclude a plurality; the terms "first" and "second" are used to identify names and not to indicate any particular order. No reference numerals in the claims should be construed as limiting the scope of protection. The functionality of multiple parts appearing in the claims can be implemented by a single hardware or software module. The appearance of certain technical features in different dependent claims does not mean that these technical features cannot be combined to achieve beneficial effects.
Claims
1. A method for repairing an SDK, characterized in that, Applied to a repair platform, the method includes: Obtain Software Development Kit (SDK) information, host information, and SDK exception information for different exception types; Based on the SDK information, the host information, and the SDK anomaly information for each anomaly type, an anomaly impact parameter corresponding to each anomaly type of the target SDK is obtained. The target SDK corresponds to the host program indicated by the host information and the SDK version indicated by the SDK information. The anomaly impact parameter is calculated using the anomaly impact factor and output ratio corresponding to each anomaly type of the target SDK. The anomaly impact factor characterizes the impact of the SDK anomaly of the anomaly type on the SDK in terms of feature information dimension, and the output ratio characterizes the proportion of the anomaly type appearing in all anomaly types of the target SDK. Based on the exception impact parameters corresponding to each exception type of the target SDK and the preset exception classification and processing rules, a target SDK repair strategy is obtained. The target SDK repair strategy includes the SDK repair strategy for the exception level corresponding to the exception impact parameters in the exception classification and processing rules. The target SDK repair policy is sent to the user terminal so that the user terminal executes the target SDK repair policy to repair the target SDK.
2. The method according to claim 1, characterized in that, The step of obtaining the exception impact parameters corresponding to each exception type of the target SDK based on the SDK information, the host information, and the SDK exception information for each exception type includes: Based on the SDK information and the host information, the target SDK is determined, and the feature information and weight of the feature information in the SDK exception information for each exception type of the target SDK are obtained. Based on the feature information and the weights of the feature information, the anomaly impact factor corresponding to each anomaly type of the target SDK is calculated; Based on the number of SDK exception information for each exception type of the target SDK and the total number of SDK exception information, the output ratio corresponding to each exception type of the target SDK is calculated; Using the anomaly impact factor and output ratio corresponding to each anomaly type of the target SDK, the anomaly impact parameter corresponding to each anomaly type of the target SDK is calculated.
3. The method according to claim 1, characterized in that, The target SDK repair strategy is derived based on the exception impact parameters corresponding to each exception type of the target SDK and the preset exception classification and processing rules, including: Based on the anomaly impact parameter corresponding to each anomaly type, a target anomaly type is determined, wherein the target anomaly type is the anomaly type corresponding to the anomaly impact parameter with the largest value; Based on the aforementioned anomaly classification and processing rules, the anomaly level corresponding to the target anomaly type and the anomaly impact parameter of the target anomaly type is determined, and the target SDK repair strategy is determined based on the anomaly level.
4. The method according to claim 1, characterized in that, The target SDK remediation strategy includes one or more of the following: A first file, the first file including a cache data clearing instruction, the cache data clearing instruction being used to instruct the clearing of data in at least one cache folder corresponding to the target SDK; The second document includes an anomaly source blocking instruction, which is used to instruct the switch state of at least one business function and / or sub-business function of the target SDK to be set to the off state; The third file includes a patch file, which is used to upgrade and repair the target SDK.
5. The method according to claim 4, characterized in that, The target SDK repair strategy includes the third file. The method further includes: Obtain the pre-repair SDK archive file and the post-repair SDK archive file of the target SDK; Obtain a first class file and a second class file, wherein the first class file includes class files in the SDK archive file before repair, and the second class file includes class files in the SDK archive file after repair; Using a comparison algorithm, the first class file and the second class file are compared to obtain a third class file, which includes class files that differ from the second class file and the first class file; Convert the third class file into the patch file.
6. The method according to claim 1, characterized in that, The target SDK repair strategy also includes a first signature file. The method further includes: Based on the host information, a first signature is generated; A first signature file is generated based on the first signature, and the first signature file includes the first signature.
7. The method according to claim 1, characterized in that, After obtaining the target SDK repair strategy based on the anomaly impact factor of each type of SDK anomaly information according to the preset anomaly classification and processing rules, the strategy further includes: Send the target SDK repair strategy to the channel platform; The system receives the target SDK repair strategy fed back from the channel platform. The target SDK repair strategy fed back includes a second signature file, which includes a second signature. The second signature is generated by the channel platform based on the host information after scanning the target SDK repair strategy and authorizing it. The step of sending the target SDK repair strategy to the user terminal includes: The target SDK repair strategy fed back by the channel platform is sent to the user terminal.
8. The method according to claim 1, characterized in that, The target SDK repair strategy is executed by a repair process established by the user terminal, and the repair process is independent of the target SDK process.
9. A method for repairing an SDK, characterized in that, Applied to a user terminal, the method includes: The repair platform is provided with Software Development Kit (SDK) information, host information, and SDK anomaly information for different anomaly types. This enables the repair platform to obtain a target SDK repair strategy based on the anomaly impact parameters corresponding to each anomaly type of the target SDK and preset anomaly classification and processing rules. The target SDK repair strategy includes the SDK repair strategy for the anomaly level corresponding to the anomaly impact parameters in the anomaly classification and processing rules. The target SDK corresponds to the host program indicated by the host information and the SDK version indicated by the SDK information. The anomaly impact parameters corresponding to each anomaly type of the target SDK are obtained based on the SDK information, the host information, and the SDK anomaly information for each anomaly type. The anomaly impact parameters are calculated using the anomaly impact factor and output ratio corresponding to each anomaly type of the target SDK. The anomaly impact factor characterizes the impact of the SDK anomaly of the anomaly type on the SDK in terms of feature information dimension, and the output ratio characterizes the proportion of the anomaly type appearing among all anomaly types of the target SDK. Obtain the target SDK repair strategy from the repair platform and execute the target SDK repair strategy to repair the target SDK.
10. The method according to claim 9, characterized in that, The output ratio corresponding to each anomaly type of the target SDK is calculated based on the number of SDK anomaly information for each anomaly type of the target SDK and the total number of SDK anomaly information; the anomaly impact factor corresponding to each anomaly type of the target SDK is calculated based on the feature information in the SDK anomaly information for each anomaly type of the target SDK and the weight of the feature information.
11. The method according to claim 9, characterized in that, The anomaly level corresponding to the target SDK repair strategy is obtained based on the anomaly classification and processing rules, the target anomaly type, and the anomaly impact parameter of the target anomaly type. The target anomaly type is the anomaly type corresponding to the anomaly impact parameter with the largest value.
12. The method according to claim 9, characterized in that, The target SDK remediation strategy includes one or more of the following: A first file, the first file including a cache data clearing instruction, the cache data clearing instruction being used to instruct the clearing of data in at least one cache folder corresponding to the target SDK; The second document includes an anomaly source blocking instruction, which is used to instruct the switch state of at least one business function and / or sub-business function of the target SDK to be set to the off state; The third file includes a patch file, which is used to upgrade and repair the target SDK.
13. The method according to claim 12, characterized in that, The target SDK repair strategy includes the third file, the patch file is converted from the third class file, the third class file includes class files that differ from the second class file and the first class file, the first class file includes class files in the pre-repair SDK archive file of the target SDK, and the second class file includes class files in the post-repair SDK archive file of the target SDK.
14. The method according to claim 9, characterized in that, The target SDK repair strategy also includes a first signature file, which includes a first signature generated by the repair platform based on the host information. After obtaining the target SDK repair strategy from the repair platform, the method further includes: The host program indicated by the host information is invoked to verify the first signature; The step of implementing the target SDK repair strategy to repair the target SDK includes: If the host program, as indicated by the host information, successfully verifies the first signature, the target SDK repair strategy is executed to repair the target SDK.
15. The method according to claim 9, characterized in that, The target SDK repair strategy also includes a second signature file, which includes a second signature generated by the channel platform based on the host information after scanning the target SDK repair strategy and determining authorization. After obtaining the target SDK repair strategy from the repair platform, the method further includes: The host program indicated by the host information is invoked to verify the second signature; The step of implementing the target SDK repair strategy to repair the target SDK includes: If the host program, as indicated by the host information, successfully verifies the second signature, the target SDK repair strategy is executed to repair the target SDK.
16. The method according to any one of claims 9 to 15, characterized in that, The step of obtaining the target SDK repair strategy from the repair platform and executing the target SDK repair strategy to repair the target SDK includes: Establish a repair process, which is independent of the target SDK process; The repair process obtains the target SDK repair strategy from the repair platform and executes the target SDK repair strategy to repair the target SDK.
17. The method according to claim 16, characterized in that, The step of obtaining the target SDK repair strategy from the repair platform through the repair process and executing the target SDK repair strategy to repair the target SDK includes: The repair process monitors the process of the target SDK. If the process of the target SDK is stopped and the target SDK repair strategy is not downloaded before the target SDK repair is completed, the target SDK repair strategy will continue to be downloaded through the repair process until the target SDK repair strategy is downloaded and then the repair process will be interrupted. When the process of the target SDK is restarted, the target SDK repair strategy will be executed through the repair process to repair the target SDK. If the process of the target SDK is stopped and the target SDK repair strategy has been started before the target SDK repair is completed, the repair process records the repair progress of the target SDK. When the process of the target SDK is restarted, the repair process continues to repair the target SDK based on the repair progress.
18. A repair device for an SDK, characterized in that, The device, applied to a repair platform, includes: The acquisition module is used to acquire software development kit (SDK) information, host information, and SDK exception information for different exception types. The calculation module is used to obtain the abnormal impact parameter corresponding to each abnormal type of the target SDK based on the SDK information, the host information, and the SDK abnormal information of each abnormal type. The target SDK corresponds to the host program indicated by the host information and the SDK version indicated by the SDK information. The abnormal impact parameter is calculated using the abnormal impact factor and output ratio corresponding to each abnormal type of the target SDK. The abnormal impact factor characterizes the impact of the SDK abnormality of the abnormal type on the SDK in the dimension of feature information, and the output ratio characterizes the proportion of the abnormal type appearing in all abnormal types of the target SDK. The strategy configuration module is used to obtain a target SDK repair strategy based on the exception impact parameter corresponding to each exception type of the target SDK and the preset exception classification and processing rules. The target SDK repair strategy includes the SDK repair strategy for the exception level corresponding to the exception impact parameter in the exception classification and processing rules. The delivery module is used to deliver the target SDK repair policy to the user terminal, so that the user terminal executes the target SDK repair policy to repair the target SDK.
19. A user terminal, characterized in that, include: The sending module is used to provide the repair platform with Software Development Kit (SDK) information, host information, and SDK anomaly information of different anomaly types. This enables the repair platform to obtain a target SDK repair strategy based on the anomaly impact parameters corresponding to each anomaly type of the target SDK and preset anomaly classification and processing rules. The target SDK repair strategy includes an SDK repair strategy for the anomaly level corresponding to the anomaly impact parameters in the anomaly classification and processing rules. The target SDK corresponds to the host program indicated by the host information and the SDK version indicated by the SDK information. The anomaly impact parameters corresponding to each anomaly type of the target SDK are obtained based on the SDK information, the host information, and the SDK anomaly information of each anomaly type. The anomaly impact parameters are calculated using the anomaly impact factor and output ratio corresponding to each anomaly type of the target SDK. The anomaly impact factor characterizes the impact of the SDK anomaly of the anomaly type on the SDK in terms of feature information dimension, and the output ratio characterizes the proportion of the anomaly type appearing among all anomaly types of the target SDK. The receiving module is used to obtain the target SDK repair strategy from the repair platform; The execution module is used to execute the target SDK repair strategy to repair the target SDK.
20. An electronic device, characterized in that, The electronic device, used in a repair platform, includes a processor and a memory storing computer program instructions. When the processor executes the computer program instructions, it implements the repair method of the SDK as described in any one of claims 1 to 8.
21. A user terminal, characterized in that, include: Processor and memory storing computer program instructions; When the processor executes the computer program instructions, it implements the repair method of the SDK as described in any one of claims 9 to 17.
22. A repair system for an SDK, characterized in that, include: A repair platform for performing the repair method of the SDK as described in any one of claims 1 to 8; A user terminal is used to execute the repair method of the SDK as described in any one of claims 9 to 17.
23. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer program instructions that, when executed by a processor, implement the repair method of the SDK as described in any one of claims 1 to 17.