Hotfix Patch Management for Dependent SDKs
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Conventional hotfix methods for software maintenance often result in conflicts between patches for multiple SDKs accessed by the same Android Application Package (APK), leading to hotfix failures.
Innovation Solution
A method and apparatus for performing hotfixes on multiple SDKs with dependency relationships, involving compilation of each SDK to generate compiled files with stubs for to-be-fixed methods, determining method existence across SDKs, retaining and deleting stubs as necessary, and generating and sending a hotfix patch to an access terminal.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Ease of manufacture
If hotfix scheme for a single SDK is reused to hotfix each SDK one by one, then hotfix can be applied to individual SDKs, but conflicts between hotfix patches of multiple SDKs occur leading to hotfix failure
Solution Approach 1:
The patent segments the hotfix process by SDK, compiling each SDK separately to generate its own compiled file with stubs. This segmentation allows independent analysis and management of each SDK's hotfix requirements, preventing conflicts that arise from applying generic hotfix schemes to multiple SDKs simultaneously.
Solution Approach 2:
The patent introduces an intermediary mechanism - the stub - that acts as a placeholder in compiled files. Stubs serve as intermediaries between the hotfix patch and the actual method implementations, enabling controlled integration of hotfixes across multiple SDKs with dependency relationships without direct conflicts.
2Adaptability or versatility
If stubs for to-be-fixed methods are retained in all compiled files of multiple SDKs, then each SDK maintains its independence, but duplicate stubs cause conflicts between hotfix patches
Solution Approach 1:
The patent extracts duplicate stubs from compiled files of SDKs that share common to-be-fixed methods. By identifying and removing redundant stubs while retaining them in at least one SDK's compiled file, the system reduces stub management complexity and prevents hotfix conflicts without completely sacrificing SDK independence.
Solution Approach 2:
The patent applies local quality by making stub retention decisions specific to each SDK's context. Instead of uniformly retaining or removing stubs across all SDKs, the system selectively manages stubs based on individual SDK requirements and their dependency relationships, optimizing both independence and conflict prevention.
3Reliability
If comprehensive analysis of all SDKs is performed to identify duplicate methods, then conflicts can be prevented, but compilation time and processing overhead increase
Solution Approach 1:
The patent performs preliminary action by compiling each SDK separately to generate compiled files with stubs before final integration. This preliminary compilation stage allows systematic analysis of method signatures and identification of duplicate to-be-fixed methods across SDKs, enabling conflict prevention while organizing the complexity in a manageable sequence.
Data Source
AI summary
A hotfix method and apparatus are provided. The method comprises: compiling each SDK to obtain a compiled file of each SDK, a project to be fixed comprising at least two SDKs having a dependency relationship, and the compiled file of each SDK comprising an instrumentation code of each method to be fixed; if target methods to be fixed exist in the plurality of SDKs, retaining the instrumentation codes of said target methods in one of the SDKs, and deleting the instrumentation codes of said target methods in other SDKs; generating a hotfix patch, the hotfix patch comprising a patch corresponding to the instrumentation code of each method to be fixed; and when an access end accesses the compiled file of the at least one SDK of the project to be fixed, sending the hotfix patch to the access end.