Application packaging processing method, storage medium and electronic equipment

Abstract

The invention provides an application packaging processing method, a storage medium and electronic equipment, and is applied to the technical field of software application. According to the method, a full-process closed-loop mechanism of the front stage, the middle stage and the rear stage of packaging is constructed; before packaging, application codes and key parameters are subjected to security detection; in the packaging process, grammar and semantic errors are deeply recognized through a regular engine, an abstract syntax tree and data flow analysis, and a diagnosis report is generated; and after packaging, executing an automatic test by utilizing the matched test case to obtain an application test result. Based on the diagnosis report and the test result, whether repackaging is needed or not is intelligently analyzed, packaging parameters and test cases are adjusted according to the error types and fed back to a safety detection link in a circulating mode, automatic error recognition and self-adaptive optimization are achieved, and therefore the safety and reliability of application packaging are effectively improved, and the development risk is reduced.

Description

Technical Field

[0001] This invention relates to the field of software application technology, and in particular to an application packaging processing method, storage medium, and electronic device. Background Technology

[0002] With the rapid development of mobile applications, especially large-scale Android projects, application build processes face increasingly complex challenges. Traditional build processes typically rely on fixed build parameters preset during the development phase, such as signature configurations, environment variables, resource files, and dependency versions. This parameter configuration method is relatively rigid and struggles to adapt to dynamic changes in runtime resources, leading to low resource utilization and even resource idleness or overload. Furthermore, the large scale of projects results in longer build times, increasing the overall development cycle and delivery risks.

[0003] Furthermore, parameter conflicts and compatibility issues are common, typically requiring engineers to manually backtrack through build logs, which is inefficient and prone to errors. Security and compliance issues are often discovered only after application deployment, resulting in high remediation costs and severely impacting application stability and user experience. On the other hand, parameter tuning is highly experience-dependent, lacking a systematic, data-driven iterative mechanism, making continuous optimization difficult.

[0004] Therefore, how to achieve intelligent processing of the entire application packaging process and reduce application development risks has become a technical problem that urgently needs to be solved by those skilled in the art. Summary of the Invention

[0005] In view of the above problems, the present invention provides an application packaging processing method, storage medium, and electronic device that overcomes or at least partially solves the above problems, the technical solution of which is as follows:

[0006] An application packaging processing method includes:

[0007] Pre-packaging stage: Perform security checks on the packaging parameters and target code in the application code to be packaged, and obtain the check results;

[0008] Packaging stage: If the detection result is passed, the application code is packaged to generate a packaged executable file. During the packaging process, a regular expression engine is used to match syntax error patterns, an abnormal node is marked by combining an abstract syntax tree, and semantic errors are tracked using data flow analysis to generate a diagnostic report.

[0009] Post-packaging stage: Automated testing is performed using target test cases that match the executable file to obtain application test results; based on the application test results and the diagnostic report, it is analyzed whether there are packaging errors that require repackaging; if so, the packaging parameters and / or the target test cases are adjusted according to the error type of the packaging error, and the process returns to the step of executing the packaging parameters and target code in the application code to be packaged to perform security checks and obtain the detection results.

[0010] A computer-readable storage medium having a program stored thereon, which, when executed by a processor, implements the application packaging processing method described above.

[0011] An electronic device includes at least one processor, at least one memory connected to the processor, and a bus; wherein the processor and the memory communicate with each other via the bus; the processor is used to call program instructions in the memory to execute the application packaging processing method.

[0012] By employing the above technical solutions, the present invention provides an application packaging processing method, storage medium, and electronic device. Through security detection of application code and key parameters before packaging, generating diagnostic reports by combining deep analysis of syntax and semantics during packaging, and intelligent feedback adjustment based on automated test results after packaging, this full-link closed-loop mechanism realizes automated error identification and adaptive optimization, significantly improving the security and reliability of application packaging, thereby effectively reducing application development risks.

[0013] The above description is merely an overview of the technical solution of the present invention. In order to better understand the technical means of the present invention and to implement it in accordance with the contents of the specification, and in order to make the above and other objects, features and advantages of the present invention more apparent and understandable, specific embodiments of the present invention are described below. Attached Figure Description

[0014] Various other advantages and benefits will become apparent to those skilled in the art upon reading the following detailed description of preferred embodiments. The accompanying drawings are for illustrative purposes only and are not intended to limit the invention. Furthermore, the same reference numerals denote the same parts throughout the drawings. In the drawings:

[0015] Figure 1 A flowchart illustrating one embodiment of the application packaging processing method provided by this invention is shown.

[0016] Figure 2 This is a flowchart illustrating a specific implementation of step S100 in the application packaging processing method provided by an embodiment of the present invention;

[0017] Figure 3 The diagram shows a specific implementation of step S220 in the application packaging processing method provided by the present invention.

[0018] Figure 4 The diagram shows a specific implementation of step S230 in the application packaging processing method provided in this embodiment of the invention.

[0019] Figure 5 This is a flowchart illustrating a specific implementation of step S110 in the application packaging processing method provided in this embodiment of the invention;

[0020] Figure 6 The diagram shows a specific implementation of step S120 in the application packaging processing method provided by the present invention. Detailed Implementation

[0021] Exemplary embodiments of the invention will now be described in more detail with reference to the accompanying drawings. While exemplary embodiments of the invention are shown in the drawings, it should be understood that the invention may be implemented in various forms and should not be limited to the embodiments set forth herein. Rather, these embodiments are provided so that this invention will be thorough and complete, and will fully convey the scope of the invention to those skilled in the art.

[0022] like Figure 1 The diagram shows a flowchart of one embodiment of the application packaging processing method provided by this invention. The method may include:

[0023] S100, Pre-packaging stage: Perform security checks on the packaging parameters and target code in the application code to be packaged, and obtain the check results.

[0024] The application code can be the source code of the Android project to be packaged and its related files, including Java / Kotlin code, resource files (such as images, layouts, strings, etc.), Smali decompiled code, and dependency libraries, which are the basic content for building an executable APK.

[0025] The packaging parameters are the configuration items and environment settings used during the build process, including signing configuration (key, certificate), environment variables (JAVA_HOME, ANDROID_HOME, PATH, etc.), dependency version numbers, resource file paths, and build options, which are used to guide the build tools to correctly perform the packaging operation.

[0026] The target code refers to the intermediate or final code output generated during the build process, including the decompiled Smali code, the generated DEX file, and the executable APK file to be tested. It is the object of security detection and automated testing.

[0027] Security testing refers to the static and dynamic analysis process performed on application code, packaging parameters, and target code. It can include environment variable verification, dependency version conflict detection, signature validity verification, code obfuscation resistance detection, sensitive API call analysis, and vulnerability scanning, with the aim of discovering potential security vulnerabilities and compliance risks.

[0028] The detection results refer to the analysis reports and judgment conclusions output by the security detection process, including information such as errors, vulnerabilities, configuration anomalies, code risk points and compliance issues. These are used to guide subsequent packaging operations, automated testing and parameter adjustments to ensure that the build is safe and reliable.

[0029] Specifically, in the pre-packaging stage, the embodiments of the present invention can sequentially perform environment configuration verification, dependency conflict checks, resource file integrity verification, signature validity checks, and security vulnerability scanning on the packaging parameters. Further, API call behavior analysis is performed on core business code (such as Smali files) to generate the second-step detection results. Subsequently, for newly added or modified code, sensitive API and permission compliance tracking is conducted to obtain the detection results.

[0030] S110, Packaging Stage: If the detection result is satisfactory, the application code is packaged to generate a packaged executable file. During the packaging process, a regular expression engine is used to match syntax error patterns, an abnormal node is marked using an abstract syntax tree, and semantic errors are tracked using data flow analysis to generate a diagnostic report.

[0031] The packaging process refers to the process of compiling, linking, and packaging the application's source code, resource files, and dependencies into an executable installation file (APK or AAB) using a build tool (such as Gradle). This packaging process includes multiple steps such as code compilation, resource merging, and signature authentication, ultimately generating an application package that can be installed and run.

[0032] Among them, the executable file refers to the Android application installation package generated through the packaging operation. It is usually in APK (Android Package) or AAB (Android App Bundle) format, containing the application's code, resources and configuration information, and can be recognized and executed by the system on the device.

[0033] This invention can use a predefined regular expression rule library to scan build logs or code text during the packaging process, automatically identify syntax errors that match specific error patterns (such as resource conflicts, missing dependencies, and signature verification failures), so as to locate and handle build problems in a timely manner.

[0034] In the packaging process, this invention can convert the source code into an Abstract Syntax Tree (AST) structure, perform semantic and syntactic analysis on the nodes in the tree, and mark abnormal nodes, such as uninitialized variables, type mismatches, and missing permissions, so as to accurately locate code quality and security issues.

[0035] This invention can detect potential semantic errors, such as uninitialized variables, memory out-of-bounds errors, and thread safety risks, by analyzing the flow path of variables and data in the program during the packaging process, thus helping to discover anomalies and vulnerabilities that may be caused during code execution.

[0036] The diagnostic report refers to a comprehensive error and risk report automatically generated based on multiple detection methods such as regular expression matching, AST analysis, and data flow tracing. The report includes information such as error type, root cause location, handling priority, and automatic remediation suggestions, supporting development and build teams in quickly responding to and fixing issues.

[0037] S120. Post-packaging stage: Execute automated tests using target test cases that match the executable file to obtain application test results.

[0038] Among them, target test cases refer to automated test scripts specifically designed to verify application functionality, performance, and security, which match the currently built executable file and its packaging parameters. Target test cases achieve differentiated adaptation to different environments and channels based on dynamic packaging parameters, accurately covering the areas affected by changes, and ensuring "one script can be reused in multiple environments" and "precise execution of dedicated test cases".

[0039] The application test results refer to the test data and status summary generated after the automated testing framework executes the target test cases. This includes the pass rate, failure rate, skip rate and specific reasons for failure of the test cases. It also covers performance baseline indicators (such as cold start time, frame rate, memory and CPU usage) and security and stability test outputs, which are used to evaluate the quality and stability of the application.

[0040] S130. Based on the application test results and diagnostic report, analyze whether there are any packaging errors that need to be repackaged. If so, proceed to step S140.

[0041] Packaging errors refer to build anomalies or defects that occur during the application packaging process. These may involve environment configuration errors, missing dependencies, resource conflicts, signature failures, code obfuscation issues, etc., causing the generated executable file to fail to build, install, or run correctly. Packaging errors usually require identifying the root cause through diagnostic reports and fixing them by adjusting packaging parameters or correcting the code.

[0042] S140. Adjust the packaging parameters and / or target test cases according to the error type of the packaging error, and return to the execution step S100.

[0043] Error types refer to the standard categories used to classify packaging errors, distinguishing issues of different natures and impacts. Examples include resource conflicts, missing dependencies, signature verification failures, uninitialized variables, memory access violations, and permission deficiencies. Error types help determine the priority of issues, handling strategies, and corresponding specific test cases, thereby enabling intelligent diagnosis and closed-loop optimization.

[0044] It is understood that, in the case of packaging errors that do not require repackaging, the application test results and diagnostic reports show that the current build version is functionally stable, meets performance standards, and is secure and compliant. The packaging process is completed, and the generated executable file can be directly used for subsequent release, deployment, or further integration testing and acceptance. This avoids the waste of resources and time delays caused by repeated packaging, and achieves efficient continuous integration and delivery.

[0045] This invention provides an application packaging method that, through security checks on application code and key parameters before packaging, generating diagnostic reports by combining deep analysis of syntax and semantics during packaging, and intelligent feedback adjustments based on automated test results after packaging, achieves automated error identification and adaptive optimization through a closed-loop mechanism that significantly improves the security and reliability of application packaging, thereby effectively reducing application development risks.

[0046] Optional, based on Figure 1 The method shown is as follows: Figure 2 The diagram shows a specific implementation of step S100 in the application packaging processing method provided in this embodiment of the invention. Step S100 may specifically include:

[0047] S200: Collect packaging parameters from the application code to be packaged.

[0048] S210. Perform environment pre-check, dependency scan, resource compilation, signature verification and security scan on the packaging parameters in sequence to obtain the first detection result.

[0049] Among them, environment pre-check refers to the automated detection and verification of the development environment variables and related configurations required for the build before the application is packaged to ensure that they are correct and meet the requirements.

[0050] Optionally, environmental pre-checks may include verifying the correctness and compliance of environmental variables by validating the packaging parameters.

[0051] Specifically, embodiments of the present invention can detect whether key environment variables have been set correctly (e.g., JAVA_HOME points to a compliant JDK path and ANDROID_HOME points to an SDK path), and verify whether the version and content of the environment variables meet the expected standards (e.g., JDK≥11 and Gradle version meets the requirements), to prevent build failure due to incompatible environments.

[0052] Dependency scanning refers to the automated analysis of all external dependency libraries and components referenced in an application project.

[0053] Optionally, dependency scanning may include checking the consistency of dependencies in the packaging parameters and intercepting sensitive information.

[0054] Specifically, embodiments of the present invention can execute ". / gradlew:app:dependencies --configuration releaseRuntimeClasspath" to generate a dependency tree, parse the dependency tree, detect whether there are multiple version conflicts of the same library (e.g., different modules referencing different versions of Glide), ensure that dependency versions are consistent, integrate Gradle plugins (such as dependencyCheck), terminate the build when a conflict occurs, and scan build parameters and configuration files (such as gradle.properties) to promptly discover sensitive information such as hard-coded keys and API_KEYs, prevent them from being submitted or used for packaging, and ensure security and compliance.

[0055] Resource compilation refers to the automatic detection and compilation of the integrity, correctness, and adaptability of all resource files (such as images, layouts, strings, etc.) in the application project.

[0056] Optionally, resource compilation may include verifying the integrity of resource files, the correctness of resource files, conflict detection, and resource compatibility of the packaging parameters.

[0057] Specifically, embodiments of the present invention can check whether all resource files (images, layouts, strings, etc.) are complete and whether there are any missing references, avoid resource loading anomalies at runtime, use the AAPT2 tool to compile resources, detect whether there are duplicate or conflicting resource files, locate the specific problem file path, and check whether multi-version and multi-resolution resource directories (such as res / values-v21 / ) are complete, ensuring that the application can be displayed and run normally on various devices and Android versions.

[0058] Signature verification refers to the automated detection of the legitimacy of the signature file, signature type, and certificate to ensure that the generated executable file has a correct and valid digital signature.

[0059] Optionally, signature verification may include verifying the signature configuration of the packaging parameters, verifying the signature type, and verifying the validity of the certificate.

[0060] Specifically, embodiments of the present invention can verify whether the signature file (such as .keystore) exists and can be used normally to ensure that the built APK has been correctly signed. It integrates the apksigner verify command (built into the Android SDK) to detect whether the APK has enabled a compliant signing scheme (such as V1 / V2 / V3), and automatically blocks the build process when the signature is missing or invalid through a shell script. It also verifies the validity period and fingerprint information of the signature certificate (such as comparing with the preset SHA-256 fingerprint) to prevent the use of expired or invalid certificates for distribution.

[0061] Security scanning refers to the use of automated tools to detect security vulnerabilities and assess risks in code, dependency libraries, and configuration items during the application packaging process.

[0062] Optionally, the security scan may include scanning the packaging parameters for security vulnerabilities.

[0063] Specifically, embodiments of the present invention can use tools such as OWASP DependencyCheck to automatically scan dependencies for known high-risk security vulnerabilities (such as CVEs). If a serious vulnerability is found, the build will automatically fail, ensuring the security of the release.

[0064] S220. If the first detection result is passed, perform API call detection on the intermediate code in the application code to obtain the second detection result.

[0065] The intermediate code can include Smali code, bytecode, and other code obtained through decompilation.

[0066] Specifically, in embodiments of the present invention, if the first detection result is passed, an initial feature vector is constructed by statistically analyzing the API call frequency of intermediate code, and the core business feature vector is extracted by unsupervised clustering; at the same time, similarity matching results are obtained by combining signature consistency detection and code hash comparison; the feature vector similarity calculation, signature matching results and dynamic behavior sequences are integrated for comprehensive analysis, and a second detection result for security assessment is output.

[0067] S230. If the second test result is passed, perform a compliance test on the incremental code in the application code to obtain a third test result.

[0068] Specifically, embodiments of the present invention can identify potentially risky code segments in incremental code within application code by matching preset sensitive API pattern rules. Combined with call chain analysis and risk type correlation assessment, a third detection result containing risk level and violation type is generated. If the third detection result is passed, step S110 is executed.

[0069] This invention, through refined collection of packaging parameters in the application code to be packaged, and sequential execution of environment pre-check, dependency scanning, resource compilation, signature verification, and security scanning, enables automatic verification of key parameters in the packaging process, effectively improving the stability and security of the build. Furthermore, for application code that passes the initial detection, API call detection of intermediate code and incremental code compliance detection are further conducted, enabling in-depth review of core business logic and newly added changes. This not only reduces the risk of packaging failure due to environmental or dependency anomalies but also strengthens control over code logic and compliance risks, improving the accuracy and security of the automated packaging process.

[0070] Optional, based on Figure 2 The method shown is as follows: Figure 3 The diagram shows a specific implementation of step S220 in the application packaging processing method provided in this embodiment of the invention. Step S220 may specifically include:

[0071] S300: Count the number of API calls in the Smali code of the application code to obtain the API initial vector.

[0072] The API initialization vector refers to the raw statistical data set formed by traversing each method block in the Smali code and counting the occurrence frequency of each type of API. The API initialization vector records the call frequency of each API in the code, usually represented as [api1_count, api2_count, ..., apiN_count], and is used for subsequent feature processing.

[0073] Specifically, in this embodiment of the invention, a decompilation tool (such as Apktool) can be used to decompile the APK file and extract the Smali code files in the application. The method blocks (from .method to .endmethod) in each Smali file are traversed, and the frequency of various API calls is counted. Then, system APIs (such as calls starting with Landroid / ) are filtered, and developer-defined APIs (such as Lcom / yourpackage / ) and key business-related APIs (such as onCreate() and getDeviceId()) are extracted. The statistical results form an initial vector of APIs, with the number of calls as the numerical value, i.e., the API initial vector, in the form of [api1_count, api2_count,...,apiN_count].

[0074] As examples, embodiments of the present invention can employ Python scripts from an automated toolchain to parse Smali code obtained through decompilation using Apktool. The script iterates through method blocks in each Smali file, counts the frequency of API calls, and generates API initialization vectors. To improve accuracy, anti-obfuscation hardening technology identifies and removes redundant instructions (such as goto jump chains) from code bloat, extracts valid API calls by reconstructing the Control Flow Graph (CFG), and avoids redundancy and erroneous statistics. Simultaneously, for reflection calls (Method.invoke in Java reflection), its parameters are parsed to trace the actual APIs called, ensuring the completeness and accuracy of the statistics.

[0075] S310. Normalize the initial vector to obtain the API feature vector.

[0076] The API feature vector refers to a high-dimensional vector obtained by normalizing (e.g., TF-IDF weighting) the initial API vector, and is used to characterize the distribution and features of Smali code API calls. The API feature vector highlights APIs relevant to the application's own business, reduces the influence of general or third-party libraries, and provides standardized input for subsequent clustering and similarity analysis.

[0077] Specifically, this embodiment of the invention addresses the issue of the differences and universality of API call frequencies in the initial API vector by employing the TF-IDF (Term Frequency-Inverse Document Frequency) method to weight and normalize the vector. This reduces the weight of common APIs that appear frequently in most files (such as the log file Log.d), while highlighting important API calls with business characteristics. The formula is: Weight = (API frequency in files) × log(total number of files / number of files containing this API). The normalized vector, i.e., the API feature vector, can more accurately reflect the business relevance and differences of API calls in the application.

[0078] As examples, embodiments of the present invention can normalize the statistically obtained initial API vectors using the TF-IDF vectorization method provided by scikit-learn in the automated toolchain. This reduces the weight of high-frequency but non-business-related general APIs, highlighting the characteristics of business-related APIs. This process improves the expressive power and discriminative power of the vectors, laying the foundation for subsequent clustering analysis.

[0079] S320. Perform unsupervised clustering analysis and screening on API feature vectors to extract target feature vectors that reflect core business.

[0080] The core business logic refers to the set of features that best reflect the application's own business logic, identified from all API feature vectors through unsupervised clustering analysis (such as K-Means). The core business logic typically excludes interference from third-party libraries and basic system APIs, retaining only API call features related to the application's unique functions.

[0081] The target feature vector refers to the API feature vector that, after clustering and interference removal, retains only the core business clusters, serving as the final feature set reflecting the application ontology's business functions.

[0082] Specifically, in this embodiment of the invention, all API feature vectors can be input into an unsupervised clustering algorithm (such as K-Means). The number of clusters K is dynamically adjusted according to the silhouette coefficient, typically set to 5. The clustering results will form several clusters, corresponding to core business API clusters, third-party library API clusters (such as advertising SDKs), and system basic API clusters, respectively. By analyzing indices such as intra-cluster call patterns and code entropy, API feature vectors from third-party library clusters with high-density concentrated calls (such as com / google / gson) or low code entropy (repetitive patterns) are identified and removed. Only API feature vectors from core business clusters with dispersed calls and high code entropy (complex logic) are retained. This part is the target feature vector, representing the unique business logic characteristics of the application itself.

[0083] As examples, embodiments of the present invention can use the KMeans clustering algorithm implemented in scikit-learn to cluster all API feature vectors, initially setting K=5 and dynamically adjusting it based on the silhouette coefficient. The clustering results divide the API vectors into core business clusters, third-party library clusters, and system foundation clusters, etc. By analyzing the call density and code entropy characteristics of the clusters, APIs in the third-party library clusters are accurately eliminated, and target feature vectors that truly reflect the core business of the application are extracted, achieving effective isolation of interference from third-party libraries.

[0084] S330. Perform signature consistency checks and code hash comparisons on the Smali code to obtain similarity matching results.

[0085] The similarity matching result refers to the comparison between the target APK representing Smali code and the genuine APK, obtained by comparing signature consistency detection and code hash. The similarity matching result reflects whether the APK signatures are consistent and whether there is a risk of tampering or repackaging of the core business code.

[0086] Specifically, in this embodiment of the invention, keytool or apksigner can be used to extract the APK signature information (such as SHA-256 fingerprint) of the Smali code and compare it with the signature of the genuine APK. If they match, the signature passes; otherwise, a risk warning is triggered. Simultaneously, the SHA-256 hash value of the core business Smali code is calculated and compared with the code hash library of the genuine APK (such as {com.example.app:"a1b2c3..."}). If the hash deviation rate exceeds a set threshold (such as 5%), there may be risks such as repackaging or code injection. The detection result output in this step is the similarity matching result, used to determine the legality of the APK signature and the integrity of the code.

[0087] As examples, embodiments of the present invention can use keytool or apksigner to automatically extract the signature information (including certificate SHA-256 fingerprint, developer name, and validity period) of the APK to be detected. Simultaneously, SHA-256 hash values ​​are calculated for the core business Smali code (excluding non-business resource files). This signature and hash information is automatically compared with the signature and code hash database of the genuine APK. If inconsistencies are found or the hash deviation exceeds a set threshold, a security alert is triggered, and a similarity matching result is generated.

[0088] S340. Calculate the feature similarity between the target feature vector and the preset API call feature vector to obtain the similarity calculation result.

[0089] The similarity calculation result refers to the numerical comparison of the target feature vector of the target APK with the preset (genuine) API call feature vector using the cosine similarity algorithm to obtain a similarity score (generally between 0 and 1). The similarity calculation result is used to determine the consistency of the application's business logic and its risk level; for example, if it is below a certain threshold, it is judged as high risk.

[0090] Specifically, embodiments of the present invention can employ a cosine similarity algorithm to calculate the similarity score between the core business API feature vector of the target APK and the corresponding feature vector of the pre-stored genuine APK, with a numerical range of 0 to 1. By setting a threshold (e.g., <0.85 is considered high risk, 0.85~0.95 requires manual review, >0.95 is considered safe), the system assists in determining whether the application's business logic has been tampered with or forged. This step outputs the similarity calculation result, providing a quantitative basis for security determination.

[0091] As examples, embodiments of the present invention can utilize Python's scikit-learn library to calculate the cosine similarity between the feature vector of the core business API of the target APK and the corresponding feature vector of the genuine APK, quantifying the similarity of their business logic. A similarity below the threshold of 0.85 is considered high-risk; a similarity between 0.85 and 0.95 requires manual review; and a similarity above 0.95 is considered safe. This completes the quantitative risk assessment, and the similarity calculation result is output.

[0092] S350. Using the similarity calculation results, similarity matching results, and dynamic feature sequences of the Smali code, a second detection result is obtained.

[0093] Among them, dynamic feature sequence refers to the dynamic information sequence about API call chain and behavior order collected by Smali code at runtime through methods such as injecting logs and behavior tracking.

[0094] The second detection result refers to the detection conclusion output by using decision rules to determine whether the target APK has risks such as repackaging, malicious modification, or abnormal business logic, based on multi-dimensional data such as comprehensive similarity calculation results, similarity matching results, and dynamic feature sequences.

[0095] Specifically, embodiments of the present invention can integrate the similarity calculation results and signature hash matching results obtained from static analysis with the dynamic feature sequences of API calls collected through dynamic behavior enhancement verification and injection-based log tracing to form a multi-dimensional and multi-angle comprehensive judgment. Through the established comprehensive decision rules, the final second detection result is output, accurately identifying whether there are security risks such as repackaging, code obfuscation evasion, and malicious tampering, thus achieving precise security detection of the application package.

[0096] The script for injection-based log tracing can be:

[0097] "const-string v0, "SecurityMonitor"

[0098] const-string v1, "com.example.MainActivity.onCreate()"

[0099] invoke-static{v0,v1}, Landroid / util / Log;->d(Ljava / lang / String;Ljava / lang / String;)I".

[0100] Furthermore, in this embodiment of the invention, weights can be assigned to the similarity calculation result, the similarity matching result, and the dynamic feature sequence of the Smali code based on the comprehensive decision rule, and a second detection result can be calculated based on the weights. The comprehensive decision rule can be as shown in Table 1.

[0101] Table 1

[0102] Detection Dimensions Risk conditions Weight API Feature Similarity <0.85 40% Signature consistency Fingerprint mismatch or certificate expired 30% Dynamic call sequence Unauthorized sensitive behavior (such as sending SMS messages) detected. 30%

[0103] As examples, embodiments of the present invention can automatically inject log code into key API entry points based on the Frida framework during the dynamic behavior analysis phase, monitor the API call chain during application runtime in real time, and obtain dynamic feature sequences. Combining the similarity matching and calculation results obtained from static analysis, a final second detection result is derived through a preset comprehensive decision rule, achieving accurate identification of malicious repackaging and code obfuscation evasion.

[0104] This invention constructs an initial vector by statistically analyzing API call frequency and performs normalization processing. It then uses unsupervised clustering to accurately eliminate interference from third-party libraries and extract target feature vectors for core business logic. Combined with signature consistency and code hash comparison, it ensures code integrity and tamper-proofing. Feature similarity calculation quantitatively assesses the consistency of application business logic. Furthermore, it integrates dynamic feature sequence information to comprehensively determine the security risks of the application code. This effectively improves the accuracy and robustness of API call detection, enabling more precise identification of repackaging and malicious tampering behaviors. It solves the problem of malicious applications relying on code obfuscation to evade traditional detection, achieving in-depth security analysis and risk warning of application code, and ensuring the reliability and security of the final executable file.

[0105] Optional, based on Figure 2 The method shown is as follows: Figure 4 The diagram shows a specific implementation of step S230 in the application packaging processing method provided in this embodiment of the invention. Step S230 may specifically include:

[0106] S400: Extract incremental code from the application code.

[0107] Incremental code refers to the code that has been added or modified relative to the previous version or the most recent commit. In this embodiment of the invention, it can be extracted using the `git diff` command in version control tools (such as Git), mainly including the source code files and line-level differences involved in the current change. Incremental code focuses on the business logic and implementation added or changed in this update, facilitating security compliance checks and risk analysis of the latest changes and avoiding the duplication of processing previously unchanged code.

[0108] Specifically, embodiments of the present invention can automatically obtain the difference files and content between the current codebase and the previous version using the `git diff` command of a version control tool (such as Git) (e.g., "gitdiff --name-only HEAD^HEAD > changed_files.txt # Get the list of modified files" and "gitdiff HEAD^HEAD > code_changes.diff # Generate the complete diff file"), focusing on extracting the newly added or modified code parts, i.e., the incremental code. To avoid invalid analysis of irrelevant files (such as images and configuration files), regular expressions are used for filtering (e.g., ...).

[0109] Python

[0110] with open("changed_files.txt") as f:

[0111] The code `code_files = [line for line in f if re.match(r'.*\.(java|kt|js)$',line)]` retains only source code files (such as .java, .kt, .js, etc.). This incremental code is the target of subsequent sensitive API detection, enabling real-time monitoring of security risks associated with new features or modifications, thus improving detection efficiency and accuracy.

[0112] S410. Match the incremental code with the pre-configured sensitive API pattern rules to identify sensitive API code fragments in the incremental code.

[0113] Sensitive API pattern rules refer to a predefined and configured set of API call rules related to security and privacy, used to identify code call patterns that pose security risks. Sensitive API pattern rules can include a list of APIs corresponding to sensitive permissions (such as ACCESS_FINE_LOCATION and android.location.LocationManager.requestLocationUpdates related to location permissions), call conditions (such as no permission verification), specific call chain patterns, and abnormal use cases.

[0114] Among them, sensitive API code snippets refer to the actual code units in the incremental code that match the sensitive API pattern rules, which may include the call statements of sensitive APIs and their context (such as the class name, method name, call parameters, and line number).

[0115] Specifically, after obtaining the incremental code, this embodiment of the invention can perform real-time matching of method calls in the incremental code based on preset sensitive API pattern rules (including a list of APIs related to location permission abuse and calling conditions). The specific identification process includes determining whether there are API calls related to sensitive permissions (such as ACCESS_FINE_LOCATION) in the code, and whether these calls lack necessary permission verification logic. Code that successfully matches is marked as a "sensitive API code fragment". These code fragments carry key information such as class names (such as android.location.LocationManager), method names (such as requestLocationUpdates), calling parameters, specific code line numbers, or lack of permission checking logic (such as checkSelfPermission(Manifest.permission.ACCESS_FINE_LOCATION)==PackageManager.PERMISSION_GRANTED), and serve as the focus of subsequent risk assessment.

[0116] S420: Identify call chains of sensitive API code snippets.

[0117] The call chain refers to the complete call path that starts from the application's entry method, goes through a series of function or method calls, and finally triggers a sensitive API call.

[0118] Specifically, embodiments of the present invention can use a call chain analysis engine to trace and reconstruct the call paths of detected sensitive API code fragments, including direct calls and indirect call scenarios involving third-party SDKs.

[0119] S430. By utilizing the call chain and the risk types corresponding to sensitive API code snippets, a third detection result is obtained.

[0120] The third detection result refers to the security assessment conclusion obtained based on the identification of sensitive API code fragments in the incremental code and the analysis of the call chain. This third detection result comprehensively considers the call chain depth, permission verification status, and risk type (such as locating permission abuse, lack of permission requests, etc.), classifies the risk into high, medium, and low, and outputs corresponding security reports or triggers the packaging process to intercept.

[0121] Specifically, embodiments of the present invention can classify detected security risks (e.g., high, medium, and low risks) by combining call chain depth, specific characteristics of sensitive API code snippets, and predefined risk classification rules. High risks typically refer to code that directly calls sensitive APIs without permission checks, which may directly lead to the leakage of user privacy and requires immediate blocking of the packaging process. Medium and low risks may involve indirect calls or partial permission checks, generating detailed risk reports and notifying relevant developers. Ultimately, a third detection result is formed, which includes automated remediation suggestions for common risks (such as permission abuse) (e.g., automatically adding permission check code). This provides an important basis for the application packaging security detection process, achieving incremental compliance risk interception and continuous security assurance.

[0122] This invention combines risk codes with call chain reports, enabling incremental compliance interception of new risks and avoiding redundant checks: it merges deduplicated historical risk data from the database or files, classifies risks into high, medium, and low levels based on risk type and call chain depth, directly blocks the packaging process for high risks, generates reports for medium and low risks and notifies developers, and provides automated remediation suggestions for common risks (such as automatically adding permission check code), forming a closed-loop optimization mechanism.

[0123] This invention extracts incremental code from application code and matches it with pre-configured sensitive API pattern rules. This allows for accurate identification of sensitive API call fragments in newly added code. By combining this with call chain analysis, it provides a deeper understanding of the call path and context of sensitive APIs, effectively determining the risk type and level. This results in accurate third-party detection results, improving the targeting and efficiency of security detection, avoiding repetitive checks on historical code, and capturing potential compliance risks in newly added code in real time. This ensures the security and compliance of applications during continuous iteration, significantly enhances risk warning and automated interception capabilities, and achieves refined and dynamic closed-loop management of security detection, thereby improving the security and reliability of the application packaging process.

[0124] Optional, based on Figure 1 The method shown is as follows: Figure 5The diagram shows a specific implementation of step S110 in the application packaging processing method provided in this embodiment of the invention. Step S110 may specifically include:

[0125] The S500 uses a regular expression engine to match syntax error patterns and performs real-time scanning of logs generated during the application build process to obtain syntax error diagnosis results.

[0126] The syntax error diagnosis results refer to the set of specific syntax error information identified by real-time scanning of logs generated during the application build process using a regular expression engine, matching them against preset syntax error patterns (such as resource conflicts, missing dependencies, signature verification failures, etc.). The syntax error diagnosis results reflect formatting, dependency, or configuration errors existing in the code or build environment, and can include error type, location, and description, guiding the rapid location and repair of fundamental build-level problems.

[0127] Specifically, embodiments of the present invention can utilize a pre-designed regular expression rule library to parse build logs (such as Gradle logs) in real time, matching syntax error patterns such as resource conflicts, missing dependencies, and signature verification failures. Through dynamically loaded YAML configuration rules, various syntax error information during the build phase is identified and captured, generating syntax error diagnostic results to help quickly locate problems in the build environment and dependency configuration.

[0128] S510: Using the abstract syntax tree generated by the application code, abnormal nodes are automatically marked, and cross-file dependencies and structural anomalies are analyzed to obtain semantic error diagnosis results.

[0129] Semantic error diagnostic results refer to the set of error information obtained by automatically marking abnormal nodes in the code through abstract syntax tree analysis generated from the application code. Semantic error diagnostic results can include exceptions at the code logic and type levels, such as uninitialized variables, type mismatches, and missing permissions, as well as cross-file dependencies and structural anomalies (such as circular dependencies). Semantic error diagnostic results reflect the risk that the code may cause runtime exceptions or permission violations at the semantic execution level.

[0130] Specifically, embodiments of this invention can generate an abstract syntax tree from Java / Kotlin source code using tools (such as javaparser or kotlinx.ast), convert resource files (XML) into a DOM tree structure, and automatically mark abnormal nodes in the code structure (such as uninitialized variables (e.g., marking unassigned final variables or lateinit attributes), type mismatches (e.g., assigning a String to an Int variable), and missing permissions (e.g., detecting sensitive API calls without declared permissions)). Simultaneously, it constructs a cross-file dependency graph (e.g., A.kt references B.kt), traces variable propagation chains, identifies structural anomalies such as circular dependencies (e.g., ClassA→ClassB→ClassA), and generates semantic error diagnostic results.

[0131] S520. Trace the source of each semantic error in the semantic error diagnosis results to obtain the data flow tracing diagnosis results.

[0132] Data flow tracing diagnostic results refer to the set of detection information formed by deeply tracing the various errors in semantic error diagnostic results, using data flow analysis technology to track the assignment, transmission, and usage of variables, and identifying dynamic behavioral anomalies such as memory out-of-bounds errors, memory leaks, and thread safety issues. Data flow tracing diagnostic results reflect changes in the data state and potential root causes of failures during application runtime, supporting the discovery of hidden performance bottlenecks and security vulnerabilities, and enabling comprehensive monitoring and root cause analysis of code quality.

[0133] Specifically, based on semantic error diagnosis results, this invention employs data flow analysis technology to trace the assignment, use, and transfer processes of variables, detecting dynamic behavioral anomalies such as memory out-of-bounds errors, memory leaks, and thread safety issues. Thread safety can include detecting unsynchronized shared variables (such as multi-threaded write operations on HashMap) and identifying deadlock risks (e.g., analyzing the nesting order of mutexes through thread call graph analysis). By integrating tools such as Android Profiler and LeakCanary, the root causes of memory and thread problems are located, generating data flow tracing diagnostic results and improving the accuracy and depth of error localization.

[0134] As examples, embodiments of the present invention can capture heap memory snapshots using the Android Profiler to identify large objects (such as uncompressed Bitmaps); mark frequently created temporary objects (such as new String() calls within loops); and use LeakCanary to trace the reference chains held by static objects for Activities / Fragments.

[0135] S530. Link and integrate the results of syntax error diagnosis, semantic error diagnosis, and data flow tracing diagnosis to generate a diagnostic report.

[0136] Specifically, embodiments of the present invention can correlate and integrate syntax error diagnostic results, semantic error diagnostic results, and data flow tracing diagnostic results, prioritize processing according to error type, and generate a comprehensive diagnostic report that includes root cause localization, call chain topology diagram, and automated remediation suggestions. The diagnostic report can display the error distribution (e.g., 30% being missing dependencies) through a Grafana dashboard, and includes a call chain topology diagram, marking the source of the problem (e.g., memory leaks originating in the Singleton class), and automated remediation suggestions for missing dependencies and uncaught exceptions, such as automatically retrieving the latest version of the Maven repository and updating build.gradle, adding try-catch or @Nullable annotations.

[0137] This diagnostic report not only helps developers and operations personnel fully understand the source and impact of errors, but also supports automated repair and build process optimization, forming a closed-loop intelligent diagnostic and optimization system.

[0138] Optionally, the processing priority can be sorted as shown in Table 2.

[0139] Table 2

[0140] Error Type Processing priority Automatic Action Resource conflicts Highest Build interrupted, Slack alert pushed Memory out of bounds high Marked as blocked item, requires manual review. Uninitialized variables middle Generate repair suggestions and continue building.

[0141] This invention obtains syntax error diagnosis results by scanning build logs in real time, automatically marks anomalies based on an abstract syntax tree and analyzes cross-file dependencies to obtain semantic error diagnosis results, and traces the source of semantic errors to form data stream tracking diagnosis results. Finally, these detection results are correlated and integrated to generate a comprehensive and detailed diagnostic report, which can effectively improve the accuracy of error detection and root cause location capabilities, enabling errors in the packaging process to be identified and repaired in a timely manner, ensuring application build quality and security, thereby reducing the cost of repeated builds and improving the overall development and operation efficiency.

[0142] Optional, based on Figure 1 The method shown is as follows: Figure 6 The diagram shows a specific implementation of step S120 in the application packaging processing method provided in this embodiment of the invention. Step S120 may specifically include:

[0143] The S600 uses a pre-defined parameterized test script framework and executable file to obtain a test context configuration that includes automatically recognized environment parameters and channel parameters.

[0144] The pre-designed parameterized test script framework refers to a pre-designed and integrated automated testing framework that supports test scripts for reuse across multiple environments and channels through dynamic parameter configuration. This framework allows test scripts to receive runtime parameters (such as environment address and channel identifier), avoiding hard coding and improving script flexibility and maintainability.

[0145] Among them, environment parameters refer to configuration items used to describe the characteristics of the test or build environment, such as server address (API_HOST), running platform (development, testing, production environment), etc., which are used to dynamically adjust the behavior of test scripts to ensure that the test covers the functional differences in different environments.

[0146] Among them, channel parameters refer to the identifiers used to distinguish application release channels, such as "Hua A Channel" and "Xiao B Channel", which are used to determine channel-specific configurations and functions, as well as to select corresponding test cases to achieve channel-differentiated testing.

[0147] Test context configuration refers to the automatic identification of environment and channel parameters by reading the BuildConfig class or resource file inside the executable file when the test starts, and integrating them into the test execution context information to guide the parameterized execution and test case filtering of subsequent test cases.

[0148] Specifically, embodiments of the present invention can automatically read environment information (such as BuildConfig.API_HOST) and channel identifiers (such as BuildConfig.CHANNEL or resource files) built into the APK when starting tests through an integrated parameterized test script framework, thereby achieving awareness of the current operating environment and channel. Based on this, the test script framework dynamically configures the test context, ensuring that subsequent test cases can be executed based on the correct environment and channel parameters without manual intervention.

[0149] As examples, embodiments of the present invention can achieve automated testing requirements that automatically adapt to dynamic packaging by integrating a parameterized test script framework. Test cases can automatically receive dynamic parameters (such as environment address and channel identifier) ​​based on the differentiated configurations of different environments and channels, avoiding the problem of hard-coding fixed values, thereby achieving "one script for multiple environments" and "precise execution of dedicated test cases". The test script abstracts environment and channel-related variables (such as test server address and expected channel name) into parameter placeholders, and dynamically injects the parameter values ​​corresponding to the corresponding environment or channel during execution. For example, in the login test case, the expectedApiHost parameter will be passed to dev.api.com or prod.api.com depending on the current running environment, without the need to write separate scripts for each environment. Meanwhile, when the test starts, the BuildConfig class or resource file in the APK is automatically read through reflection technology to obtain the current build environment parameters (such as BuildConfig.API_HOST) and channel parameters (such as BuildConfig.CHANNEL or R.string.channel_name). Based on this, the test context is automatically configured, such as setting the test interface address and expected channel identifier, to ensure that subsequent test cases can be executed automatically under the correct environment and channel parameters without human intervention.

[0150] S610. Using a pre-defined set of parameterized test cases and test context configuration, obtain a list of first specialized test cases that match the current build environment.

[0151] Among them, the preset parameterized test case set refers to a set of pre-written automated test cases that support parameterized input. Parameter placeholders are reserved during the design, and specific data can be dynamically passed in according to different environments and channels to meet the requirement of "one script for multiple environments".

[0152] The first special test case list refers to the set of test cases that are selected from the preset parameterized test case set based on the test context configuration and match the current build environment and channel. It includes all preliminary test cases that need to be executed to verify the characteristics of the environment / channel.

[0153] Specifically, in this embodiment of the invention, based on the environment and channel parameters identified in the test context, a set of specialized test cases suitable for the current build environment can be selected from the full set of parameterized test cases, namely, the first specialized test case list. This first specialized test case list contains all the basic and dedicated functional test cases that need to be executed, ensuring that the test covers the business characteristics and differentiated requirements of the corresponding environment and channel.

[0154] As examples, embodiments of the present invention can, based on environment and channel parameters identified in the test context, filter a set of specialized test cases matching the current build environment and channel from a pre-set set of parameterized test cases, i.e., a first specialized test case list. For specific functions possessed by different channels or environments (e.g., HMS payment included in the Huawei C channel, and debugging entry point included in the development environment), specific tags (such as @HuaweiChannel, @DebugEnv) are pre-set in the test cases. During the test execution phase, the test framework automatically filters and executes test cases with corresponding tags based on the identified environment and channel parameters (e.g., only test cases marked @Huaw**Channel are executed for the Huawei D channel package), achieving precise filtering and execution through the tag filtering parameter (-e annotation) of the test execution engine (such as AndroidJUnitRunner). This first specialized test case list covers all basic and specialized functional test cases required by the current environment and channel, thereby ensuring that the test covers various business characteristics and personalized needs.

[0155] S620. Locate stable UI elements in the first special test case list to obtain the special test script set.

[0156] Stable UI element location refers to locating UI elements using relatively stable control identifiers such as resource IDs, rather than relying on volatile text or XPath, thereby improving the stability and reliability of UI automation testing across different channels and environments.

[0157] Among them, the special test script set refers to the specific executable test script set generated by combining the test cases selected from the first special test case list with the stable UI element location method, to ensure the accurate execution of the test in the target environment.

[0158] Specifically, in this embodiment of the invention, for the special test cases in the first special test case list, a UI element positioning method based on stable keywords such as resource ID can be adopted to replace the volatile text or XPath positioning, generating a set of special test scripts that can adapt to UI differences in different channels and environments, so as to ensure high stability and low maintenance cost of test scripts in multiple versions and multiple channel packages.

[0159] As examples, considering that UI text (such as button text and prompts) may change during dynamic packaging, different channels or environments can lead to variations. Using XPath or text positioning (such as / / Button[@text='Login']) can easily cause test cases to fail. This embodiment of the invention uses resource IDs for control positioning (e.g., onView(withId(R.id.login_button))), leveraging the fixedness and stability of resource IDs to resist variations in UI layout and text, ensuring that test scripts can execute stably in multi-version, multi-channel build packages.

[0160] S630. Analyze the scope of impact of parameter changes in the special test script set, and filter out the list of second special test cases to be executed by combining the preset parameter-test case mapping rules. The list of second special test cases includes multiple target test cases.

[0161] The scope of impact of parameter changes refers to the impact analysis results of changes to build parameters (such as minSdkVersion, obfuscation switch, etc.) on the functional modules, code areas, and corresponding test cases involved, which are used to guide the selection and execution of test cases.

[0162] Among them, the preset parameter-test case mapping rule refers to the pre-established mapping rule library based on the relationship between packaging parameters and functional modules and test requirements. It supports the automatic selection of corresponding special test cases based on parameter changes, so as to achieve accurate testing.

[0163] The second special test case list refers to the set of test cases that need to be actually executed, which are further selected from the special test script set based on the parameter change impact analysis and mapping rules. It mainly targets the key functional points affected by parameter changes.

[0164] Specifically, embodiments of the present invention can use static code analysis tools or custom plugins to identify changes in build parameters (such as minSdkVersion, obfuscation switch, etc.), and combine them with preset parameter-test case mapping rules to analyze the specific impact of changes on functional modules and test cases. This allows for the selection of key target test cases within the affected range, forming a more accurate list of second-specific test cases, avoiding invalid testing, and improving testing efficiency.

[0165] As examples, embodiments of the present invention can automatically identify changes in build parameters (such as minSdkVersion, minifyEnabled, etc.) through static code analysis tools or custom plugins. Combining pre-defined parameter-test case mapping rules, the specific impact of these parameter changes on functional modules and test cases is analyzed, thereby accurately identifying key target test cases within the affected range and forming a second specialized test case list. For example, when minSdkVersion changes, corresponding compatibility test cases are automatically associated and selected to verify the adaptation to lower-version systems; when the minifyEnabled obfuscation switch is adjusted, corresponding obfuscation integrity test cases are selected to ensure that critical classes are not mistakenly obfuscated.

[0166] S640. Execute each target test case in the second special test case list to obtain the test case execution results and performance analysis data.

[0167] Among them, test case execution results refer to the specific result data generated during the execution of automated tests, including the pass, failure, and skip status of test cases, as well as error logs and exception information, which are used for subsequent analysis and problem localization.

[0168] Among them, performance analysis data refers to application performance index data collected during the execution of special tests, such as cold start time, frame rate, memory usage and CPU utilization. These are compared and analyzed with historical baselines to help identify performance bottlenecks and degradation risks.

[0169] Specifically, in this embodiment of the invention, by executing the selected target test cases, the execution status (pass, fail, and skip) and detailed logs of each test case are collected during the testing process, and test case execution results are generated. Simultaneously, performance testing collects key performance indicators (such as cold start time, frame rate, memory and CPU usage) to generate performance analysis data, providing data support for subsequent performance baseline comparisons and anomaly alerts.

[0170] As examples, embodiments of the present invention can collect the execution status of each test case in real time during the testing process, including pass, failure, and skip status, while recording detailed execution logs and generating comprehensive test case execution results. Simultaneously, performance tests are automatically run, collecting key performance indicators such as cold start time, frame rate, memory usage, and CPU utilization. The monitored performance parameters can be dynamically configured according to requirements. After each build, the performance test results are stored in a database (e.g., InfluxDB), forming historical performance baseline data. Newly built performance indicators are compared and analyzed with the historical baseline. When an indicator deviates from the baseline by more than a preset threshold (e.g., cold start time increases by more than 20% from the target 800ms to 960ms), an alarm mechanism is triggered, promptly notifying relevant personnel via Jenkins notifications, email alerts, etc. Furthermore, performance monitoring also focuses on key packaging parameters (such as the minifyEnabled obfuscation switch and dexOptions optimization configuration) to ensure that parameter changes do not cause performance degradation.

[0171] S650 integrates test case execution results and performance analysis data to generate application test results.

[0172] Specifically, embodiments of the present invention can comprehensively analyze test case execution results and performance analysis data to statistically analyze pass rates, failure rates, and performance change trends, identify high-risk functionalities and performance bottlenecks, and generate comprehensive application test results. These results can include test coverage, environmental / channel differences, security and stability analysis, and performance degradation alerts, supporting subsequent problem localization and closed-loop optimization.

[0173] As examples, embodiments of the present invention can comprehensively analyze test case execution results and performance analysis data to statistically analyze the pass rate, failure rate, and skip rate of test cases, identify key test cases with high-frequency failures, and thus locate high-risk points in functional modules. Simultaneously, by combining performance indicator trends (e.g., cold start time increasing from 800ms to 960ms, an increase of 20%), system performance bottlenecks can be accurately identified. Furthermore, by comparing test results in different environments (development, testing, and production) and different channels, problems in specific environments or channels can be discovered and located, such as a high payment failure rate in a particular channel. In addition, security and stability-related indicators are analyzed to comprehensively generate a comprehensive application test result report that includes test coverage, environmental and channel differences, security and stability assessments, and performance degradation alarms, providing strong support for subsequent problem localization and closed-loop optimization. Based on intelligent result analysis reports, this invention supports problem fixing for frequently failed test cases, adjusting key packaging parameters to address performance bottlenecks, such as enabling the obfuscation switch (minifyEnabled) and optimizing dexOptions configuration, and dynamically adjusting test cases according to feature updates and parameter changes, forming a closed-loop process of "packaging-testing-optimization" to continuously improve test accuracy and application performance.

[0174] This invention, through a pre-defined parameterized test script framework combined with an executable file, automatically identifies and configures environment and channel parameters to form a test context dynamically adapted to the current build environment. Based on this context, a first-specific test case list precisely matching the current build environment is selected, ensuring the relevance and effectiveness of test coverage. Subsequently, a set of specific test scripts is generated using stable UI element positioning technology, improving the robustness and reusability of the test scripts. By analyzing the impact range of parameter changes in the specific test scripts and combining them with pre-defined parameter-test case mapping rules, a second-specific test case list affected by these changes is intelligently selected, significantly improving the relevance and efficiency of testing. Each target test case in this list is executed, obtaining detailed test case execution results and simultaneously collecting key performance indicators, achieving dual assurance of functional verification and performance analysis. Finally, by comprehensively integrating the test execution results and performance analysis data, comprehensive and accurate application test results are generated, greatly improving the automation and accuracy of testing, thereby effectively shortening the application testing cycle.

[0175] Optionally, in the above Figure 1 In addition to one or more corresponding embodiments, another optional embodiment provided by the present invention may further include:

[0176] Perform root cause diagnosis on failure results in test results, diagnostic reports, and / or application test results to obtain root cause diagnosis results; and execute the rollback operation corresponding to the root cause diagnosis results according to the preset circuit breaker configuration strategy.

[0177] Among them, root cause diagnosis results refer to the accurate identification and classification of the root cause of the failure of the build or test based on the failure situation in the test results, diagnostic reports and / or application test results through multi-dimensional analysis (including log aggregation, call chain tracing, device adaptation and parameter configuration, etc.), such as memory overflow, dependency conflict, missing UI elements, etc., and form a structured diagnostic conclusion for subsequent processing and decision-making.

[0178] The preset circuit breaker configuration strategy refers to a set of automated response rules predefined according to different fault levels and scenarios, including fault judgment conditions, corresponding self-healing actions, and execution time requirements. For example, a strategy is set to roll back to the most recent stable parameters and interrupt the build for compilation errors, and a strategy is set to degrade the run and send an email alert for UI test failures. The aim is to reduce build risks and ensure stable system operation through rapid response.

[0179] Rollback operations refer to recovery operations automatically triggered based on root cause diagnosis results and circuit breaker policies. These operations include code rollback (such as reverting problematic commits via `git revert`), parameter rollback (restoring Gradle and other build parameters to historical stable values), and dependency version rollback (downgrading to compatible third-party library versions). These actions quickly eliminate the impact of failures and restore the normal state of the build and testing process. Containerized verification ensures the accuracy and security of the rollback effect.

[0180] Specifically, this invention continuously monitors and verifies each stage, including pre-packaging parameter compliance, real-time build status during packaging, and post-packaging automated test results. When a failure is detected in the test results, diagnostic reports, or application test results, an intelligent root cause diagnosis mechanism is first used for analysis. For example, machine learning models (such as LSTM) combined with historical logs, parameter combinations, and resource metrics, or log aggregation and call chain tracing (such as stack analysis of crash logs and correlation with parameter configurations (such as NDK_VERSION=21.0.0 causing a JNI crash)) are used to diagnose the root cause of the failure, including memory overflow, incorrect parameter configuration, dependency conflicts, and UI adaptation anomalies.

[0181] Furthermore, after obtaining the root cause diagnosis results, this embodiment of the invention can automatically match corresponding rollback actions for different fault levels and scenarios based on a pre-set circuit breaker configuration strategy. For example, if a compilation error is detected, the system quickly rolls back to the most recent stable parameters and interrupts the build; if the failure rate of UI test cases exceeds a set threshold, the system degrades the operation, skips non-core test cases, and sends an alarm; if a significant drop in performance metrics is detected, the system automatically expands the test nodes and pushes optimization suggestions. Other scenarios, such as a high crash rate in the main process, failure of core functions, or occasional environmental problems, will also trigger self-healing measures such as code rollback, dependency rollback, or automatic retries. The hierarchical settings of the pre-set circuit breaker configuration strategy can be shown in Table 3, setting corresponding self-healing actions according to the failure scenario.

[0182] Table 3

[0183] Failure scenarios Self-healing actions aging Compilation error Rollback to the most recent stable parameters + interrupted build <10 seconds UI test case failure rate >30% Degraded execution (skipping non-core use cases) + email alerts <30 seconds Performance degradation Automatic scaling up of test nodes + push optimization suggestions <1 minute

[0184] As examples, embodiments of the present invention can extract key indicators (such as failure types, device models, and operation paths in UI test reports) through structured analysis of test results, and combine them with build parameters (such as Gradle heap memory settings and dependency versions) and test environment variables (screen resolution and network status) to achieve causal correlation analysis between parameters and environmental factors. Simultaneously, by utilizing log aggregation and regular expression matching techniques, common error patterns (such as NullPointerException and ResourceNotFound) can be accurately located. Combined with ADB crash stack capture (adb logcat -bcrash), multi-dimensional issues including device adaptation (UI misalignment on high-resolution devices → checking if layout constraints are adapted to various screen densities; crashes on low-end devices → analyzing memory snapshots (adb shell dumpsys meminfo) to locate resource leaks), parameter configuration (excessive thread count causing ANR → tracing back to the org.gradle.workers.max setting in gradle.properties), and dependency conflicts (third-party SDKs causing control ID conflicts → parsing the output of . / gradlew :app:dependencies to mark conflicting libraries) can be attributed. As shown in Table 4, the preset circuit breaker configuration strategy can include multi-level circuit breaker strategies, covering fault levels from blocking level (L1) to noise level (L5), supporting real-time dynamic configuration to ensure the accuracy and efficiency of the corresponding rollback operation.

[0185] Table 4

[0186] Fault Level Judgment conditions Back to roll Blocking level (L1) Main process crash rate >30% or crashes on startup Immediately roll back the code and parameters to the previous stable version. Severity level (L2) Core functionality failed (e.g., payment). Roll back the relevant module dependency versions and suspend the release of this build variant. General Level (L3) Non-core UI anomalies (such as misaligned icons) Retain the build artifacts; mark them as requiring manual review. Warning Level (L4) Performance degradation (frame rate drop >20%) Dynamic downgrade effects / resolution parameters Noise level (L5) Occasional environmental issues (such as network timeouts) Automatic retry test (exponential backoff strategy)

[0187] As examples, the code rollback provided in this embodiment of the invention automatically reverts to a specified commit by executing the `git revert` command and triggers a new build pipeline; parameter rollback restores the Gradle configuration to a historical stable version (e.g., reverting `-Xmx4096m` to `-Xmx2048m`); dependency rollback automatically downgrades to a compatible version based on conflict conditions (e.g., downgrading `com.google.gson` from 2.9.0 to 2.8.9). This closed-loop rollback strategy, combined with verification in a containerized testing environment, ensures the effectiveness and security of the rollback operation.

[0188] This invention allows for re-verification of the rolled-back artifacts within a containerized environment (such as a Docker sandbox) after the rollback operation, ensuring that key indicators such as main process pass rate and performance stability meet preset standards. All root causes of failures and rollback solutions are entered into a database, supporting automatic identification of high-frequency issues and continuous optimization of build rules, such as automatically adjusting compilation parameters and resource configurations based on device characteristics. This invention, through an automated and intelligent self-healing process of "root cause diagnosis—strategy matching—rollback execution—closed-loop verification," significantly improves the stability and fault response speed of application packaging, and reduces build failure rate and error feedback latency.

[0189] As examples, embodiments of the present invention can inject the rolled-back APK file into an Android emulator environment within a Docker container to perform targeted automated UI regression testing. This verifies that the main process pass rate must reach over 99%, and frame rate fluctuations must be controlled within 5%, thus ensuring the effectiveness and stability of the rollback operation. Furthermore, embodiments of the present invention systematically record all root causes of failures and corresponding rollback solutions into a database, facilitating automatic identification and analysis of high-frequency failure modes, such as memory leaks on specific device models or UI adaptation anomalies on notch screens. Based on the continuous accumulation and analysis of historical failure data, build rules are continuously optimized. For example, lower heap memory configurations and resource compression strategies are automatically enabled for low-end devices, while specific resolution configurations (such as resConfigs "xxhdpi") are injected for high-resolution models to improve the overall compatibility and stability of the build and runtime.

[0190] This invention, through intelligent location of the root cause of a fault, automatically matches and executes reasonable rollback measures based on different types and severity of faults. This effectively avoids resource waste and process disruption caused by repeated occurrences of similar errors. As a result, it not only improves the automation and intelligence of the packaging process and realizes closed-loop processing from fault detection and root cause analysis to adaptive rollback, but also significantly shortens fault response and repair time, and improves the stability and success rate of application packaging.

[0191] Although the operations are described in a specific order, this should not be construed as requiring these operations to be performed in the specific order shown or in a sequential order. In certain environments, multitasking and parallel processing may be advantageous.

[0192] It should be understood that the various steps described in the method embodiments of the present invention may be performed in different orders and / or in parallel. Furthermore, the method embodiments may include additional steps and / or omit the steps shown. The scope of the present invention is not limited in this respect.

[0193] This invention provides a computer-readable storage medium storing a program thereon, which, when executed by a processor, implements the application packaging method.

[0194] This invention provides a processor for running a program, wherein the program executes the application packaging method during runtime.

[0195] This invention provides an electronic device, which includes at least one processor, at least one memory connected to the processor, and a bus; wherein the processor and the memory communicate with each other via the bus; the processor is used to call program instructions in the memory to execute the application packaging processing method described above. The electronic device described herein may be a server, PC, PAD, mobile phone, etc.

[0196] The present invention also provides a computer program product that, when executed on an electronic device, is suitable for executing a program with initialization application packaging processing steps.

[0197] This invention is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus, electronic devices (systems), and computer program products according to embodiments of the invention. It will be understood that each block of 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, special-purpose computer, embedded processor, or other programmable device to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable device, generate instructions for implementing the flowchart illustrations and / or block diagrams. Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0198] Computer-readable media, including both permanent and non-permanent, removable and non-removable media, can store information using any method or technology. Information can be computer-readable instructions, data structures, program modules, or other data.

[0199] In the description of this invention, it should be understood that if the terms "upper", "lower", "front", "rear", "left" and "right" are used to indicate the orientation or positional relationship based on the orientation or positional relationship shown in the drawings, they are only for the convenience of describing this invention and simplifying the description, and do not indicate or imply that the position or element referred to must have a specific orientation, or be constructed and operated in a specific orientation, and therefore should not be construed as a limitation of this invention.

[0200] It should be noted that, in this document, relational terms such as "first" and "second" are used only to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. It should also be noted that the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such process, method, article, or apparatus. Unless otherwise specified, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes the element.

[0201] Those skilled in the art will understand that embodiments of the present invention can be provided as methods, systems, or computer program products. Therefore, the present invention can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, the present invention can take the form of a computer program product embodied on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0202] The above are merely embodiments of the present invention and are not intended to limit the invention. Various modifications and variations can be made to the present invention by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principle of the present invention should be included within the scope of the present invention.

Claims

1. An application packaging method, characterized by, The method comprises: a pre-packaging stage: performing security detection on packaging parameters and target code in application code to be packaged to obtain a detection result; a packaging stage: in the case that the detection result is passed, performing a packaging operation on the application code to generate a packaged executable file, wherein, in the packaging operation, a regular engine is used to match a syntax error pattern, an abstract syntax tree is used to mark an abnormal node, and a data flow analysis is used to track a semantic error to generate a diagnostic report; a post-packaging stage: performing automatic testing using target test cases matched with the executable file to obtain application test results; analyzing whether there is a packaging error that needs to be repackaged according to the application test results and the diagnostic report, and if so, adjusting the packaging parameters and / or the target test cases according to the error type of the packaging error, and returning to the step of performing security detection on the packaging parameters and the target code in the application code to be packaged to obtain a detection result.

2. The method of claim 1, wherein, The method comprises: collecting packaging parameters in the application code to be packaged; performing environment pre-checking, dependency scanning, resource compiling, signature verification and security scanning on the packaging parameters in sequence to obtain a first detection result; in the case that the first detection result is passed, performing API call detection on intermediate code in the application code to obtain a second detection result; in the case that the second detection result is passed, performing compliance detection on incremental code in the application code to obtain a third detection result.

3. The method of claim 2, wherein, The environment pre-checking comprises verifying the correctness and compliance of environment variables of the packaging parameters, and / or the dependency scanning comprises checking the consistency of dependency relationships and intercepting sensitive information of the packaging parameters, and / or the resource compiling comprises verifying the integrity, correctness, conflict and adaptation of resource files of the packaging parameters, and / or the signature verification comprises verifying the signature configuration, type and legality of certificates of the packaging parameters, and / or the security scanning comprises scanning security vulnerabilities of the packaging parameters.

4. The method of claim 2, wherein, The intermediate code comprises Smali code, and the API call detection on the intermediate code in the application code to obtain a second detection result comprises: counting the number of API calls of Smali code in the application code to obtain an initial API vector; performing normalization processing on the initial vector to obtain an API feature vector; performing unsupervised clustering analysis and screening on the API feature vector to extract a target feature vector reflecting core business; performing signature consistency detection and code hash comparison on the Smali code to obtain a similarity matching result; performing feature similarity calculation on the target feature vector and a preset API call feature vector to obtain a similarity calculation result; obtaining a second detection result using the similarity calculation result, the similarity matching result and a dynamic feature sequence of the Smali code.

5. The method of claim 2, wherein, The compliance detection on the incremental code in the application code obtains a third detection result, including: extracting the incremental code in the application code; matching the incremental code with a pre-configured sensitive API pattern rule to identify a sensitive API code segment in the incremental code; identifying a call chain of the sensitive API code segment; obtaining a third detection result by using the call chain and a risk type corresponding to the sensitive API code segment.

6. The method of claim 1, wherein, The method for generating a diagnostic report by matching syntax error patterns through a regular engine, marking abnormal nodes based on an abstract syntax tree, and tracking semantic errors using data flow analysis, includes: real-time scanning of logs generated during application construction based on regular engine matching of syntax error patterns to obtain syntax error diagnostic results; automatically marking abnormal nodes based on an abstract syntax tree generated by the application code, and analyzing cross-file dependencies and identifying structural abnormalities to obtain semantic error diagnostic results; tracing the source of each semantic error in the semantic error diagnostic results to obtain data flow tracking diagnostic results; integrating the syntax error diagnostic results, semantic error diagnostic results, and data flow tracking diagnostic results to generate a diagnostic report.

7. The method of claim 1, wherein, The method for obtaining application test results by executing automated tests using target test cases matching the executable file, includes: using a pre-set parameterized test script framework and the executable file to obtain a test context configuration containing automatically identified environment parameters and channel parameters; using a pre-set parameterized test case set and the test context configuration to obtain a first special test case list matching the current construction environment; stably positioning UI elements in the first special test case list to obtain a special test script set; analyzing the parameter change impact range of the special test script set, and filtering out a second special test case list to be executed based on a pre-set parameter-case mapping rule, wherein the second special test case list includes multiple target test cases; executing each target test case in the second special test case list to obtain test case execution results and performance analysis data; integrating the test case execution results and the performance analysis data to generate application test results.

8. The method according to any one of claims 1 to 7, characterized in that, The method further includes: performing root cause diagnosis on failure results in the detection results, the diagnostic report, and / or the application test results to obtain root cause diagnosis results; performing a rollback action corresponding to the root cause diagnosis results according to a pre-set fuse configuration strategy.

9. A computer-readable storage medium having stored thereon a program, characterized in that, The program is executed by a processor to implement the application packaging processing method of any one of claims 1 to 8.

10. An electronic device, comprising: The electronic device includes at least one processor, at least one memory connected to the processor, and a bus; wherein the processor, the memory, and the bus complete mutual communication through the bus; the processor is used to call program instructions in the memory to execute the application packaging processing method of any one of claims 1 to 8.

Images