Automatic construction method of APK file and related product

Abstract

The invention discloses an automatic construction method of an APK file and a related product. According to the method, firstly, a user construction demand and an APK code corresponding to the user construction demand are obtained, the code comprises application module codes of multiple versions, and the application module codes comprise a bottom layer package code and an HMI code. And then version filtering is carried out on the APK code based on a user construction demand to obtain a target code. And then interface consistency verification is carried out on an interaction interface of the bottom layer package code and the HMI code in the target code. And if the verification is passed, querying a construction workflow matched with the construction demand of the user in the knowledge graph to obtain a target workflow. On this basis, according to the target workflow, bottom layer package codes and HMI codes in the target codes are called and compiled in order, and an APK file matched with the construction requirement of the user is generated. According to the method, the automation level and accuracy of APK construction are greatly improved, and the problems of manual operation errors and version compatibility are reduced.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of computer, in particular to an APK file automatic construction method and related products. BACKGROUND

[0002] In the traditional Android application development process, the development and construction of underlying packages and Human-Machine Interface (HMI) are usually independent of each other. The underlying package is mainly responsible for implementing business logic and core functions, while the HMI part focuses on interface display and user interaction experience. Since these two modules are usually designed and compiled by different teams or developers, the final binary files or modules generated by each are manually merged to form a complete Android Application Package (APK) file.

[0003] This separated construction and manual integration method has significant efficiency bottlenecks. First, the manual merging process is complex and has many steps, which is prone to omissions or human errors. Second, there is a lack of automated interface consistency verification and version compatibility detection, making it difficult to discover mismatching problems between modules in the integration stage. Therefore, the quality of the final APK file is difficult to guarantee, and may result in installation failure, application crash and other serious consequences, affecting the stability of the product and user experience. SUMMARY

[0004] Based on the above problems, the present application provides an APK file automatic construction method and related products, aiming to realize the automatic and intelligent integration and construction of underlying packages and HMI code, to improve construction efficiency, ensure interface compatibility, avoid errors and version mismatches caused by manual merging, and thus guarantee the stability and high quality of the APK file.

[0005] The embodiments of the present application disclose the following technical solutions:

[0006] Compared with the prior art, the present application has the following beneficial effects:

[0007] The embodiment of the application first collects the user's construction requirements and extracts the corresponding APK code, which contains multiple versions of application modules. Among them, there are underlying package code and HMI code. Then, according to the user's construction requirements, the collected APK code is filtered by version, and the target code most suitable for the requirements is selected. This process ensures that the selected code adapts to the user's desired function and performance. Subsequently, the interaction interface between the underlying package code and the HMI code in the target code is checked for consistency. This step is to confirm that the two parts of the code can work effectively together and avoid errors at runtime. If the consistency check passes, a target workflow matching the user's construction requirements will be found in the APK construction knowledge graph based on the user's construction requirements, and a target workflow will be obtained. This process contains all the steps and instructions required to build APK. Finally, according to the determined target workflow, the underlying package code and HMI code in the target code are called and compiled in order, and finally an APK file matching the user's construction requirements is generated. The application realizes intelligent version filtering of APK code by obtaining user construction requirements and multiple versions of application module code (including underlying package code and HMI code), ensuring that the code used in subsequent construction accurately matches user requirements. At the same time, for the interaction interface between the underlying package and the HMI code, the application introduces an interface consistency checking mechanism, effectively avoiding runtime errors and crash risks caused by interface incompatibility in traditional manual integration. In addition, based on user requirements, the application automatically queries and generates the corresponding construction workflow in the APK construction knowledge graph, replacing manual design and execution of construction steps, and realizing the intelligentization and standardization of the construction process. BRIEF DESCRIPTION OF DRAWINGS

[0008] In order to more clearly illustrate the technical solutions in the embodiments of the application or the prior art, the following will briefly introduce the drawings needed to be used in the embodiments or prior art description. Obviously, the drawings in the following description are only some embodiments of the application, and for those skilled in the art, other drawings can also be obtained from these drawings without creative labor

[0009] Figure 1 A schematic diagram of building an APK file is provided for the embodiment of the application;

[0010] Figure 2 An implementation mode flowchart of an automatic construction method of an APK file is provided for the embodiment of the application;

[0011] Figure 3 An implementation mode flowchart of an APK construction knowledge graph construction method is provided for the embodiment of the application;

[0012] Figure 4An implementation flowchart of the APK code adjustment suggestion generation method provided by the embodiment of the present application is shown in FIG. 1.

[0013] Figure 5 An implementation flowchart of the self-optimization method provided by the embodiment of the present application is shown in FIG. 2.

[0014] Figure 6 An implementation flowchart of the artificial optimization method provided by the embodiment of the present application is shown in FIG. 3.

[0015] Figure 7 An implementation flowchart of the APK code version filtering method provided by the embodiment of the present application is shown in FIG. 4.

[0016] Figure 8 A schematic diagram of the APK file automatic construction tool provided by the embodiment of the present application is shown in FIG. 5. DETAILED DESCRIPTION

[0017] In order to facilitate understanding of the technical solutions provided by the embodiments of the present application, the background art related to the embodiments of the present application will be described first.

[0018] In the traditional Android application development process, the development and construction of the underlying package and the HMI are often carried out independently. This separation means that the development team of the underlying package focuses on implementing business logic and core functions, such as data processing, network requests, and other technical tasks, while the HMI team is committed to designing and optimizing the user interface and interaction experience to ensure the visual appeal and ease of use of the application. This modular design helps professionals in their respective fields better utilize their skills, but at the same time, it also presents significant integration challenges.

[0019] Since these two parts are usually handled by different teams or developers, respectively, the binary files or modules generated by each party need to be manually combined in the final stage to form a complete APK file. This manual integration process is not only complex but also involves numerous steps, which are prone to human errors such as missing a file or selecting the wrong version. Furthermore, due to the lack of effective automated tools to verify the consistency of interfaces and the compatibility of versions, developers have difficulty quickly discovering potential issues during integration. For example, suppose the underlying package's Application Programming Interface (API) adds an interface method for "canceling an operation," and the HMI does not update in time to call or adapt to this new interface. Due to the inconsistency in interface definitions, it may result in calling an unimplemented or parameter-mismatched interface at runtime, causing an exception error or even application crash.

[0020] Such integration process directly affects the final APK file quality. Due to the possible mismatch problem in the integration process, the generated APK file is prone to failure when installed, or crashes during runtime, and other serious consequences.

[0021] Based on this, the embodiment of the application provides an automatic construction method of an APK file and related products. First, the construction requirements of a user and the corresponding APK code are obtained. The code contains application module codes of multiple versions, and the module codes are divided into underlying package codes and HMI codes. Second, according to the construction requirements of the user, the APK code is subjected to version screening, and the target code meeting the conditions is filtered out. Then, the interaction interface between the underlying package code and the HMI code in the target code is subjected to consistency verification, so as to ensure that the interface definition and the calling are matched with each other. If the interface verification is passed, the corresponding construction workflow is queried in the pre-established APK construction knowledge graph based on the construction requirements of the user, and the target workflow most suitable for the current requirements is obtained. Finally, the underlying package code and the HMI code in the target code are sequentially called and compiled according to the target workflow, and finally the APK file meeting the construction requirements of the user is generated, so that an efficient and accurate automatic construction process is realized. The application realizes intelligent version filtering of the APK code by obtaining the construction requirements of the user and the application module codes of multiple versions (including underlying packages and HMI codes), so as to ensure that the used code can accurately meet the requirements of the user. At the same time, the interface consistency verification mechanism is introduced, which effectively prevents the common interface incompatibility problem in the traditional manual integration, reduces the risk of runtime errors and crashes. In addition, based on the user requirements, the corresponding construction workflow is automatically queried and generated in the APK construction knowledge graph, so that the construction process is more intelligent and standardized, and the development efficiency is further improved.

[0022] In order for those skilled in the art to better understand the application scheme, the technical solutions in the embodiments of the application will be described clearly and completely in conjunction with the drawings in the embodiments of the application. Obviously, the described embodiments are only part of the embodiments of the application, not all embodiments. Based on the embodiments in the application, all other embodiments obtained by those skilled in the art without creative labor are within the scope of protection of the application.

[0023] Reference is made to Figure 1 , Figure 1 A schematic diagram for constructing an APK file is provided in the embodiments of the application.

[0024] When a user initiates a build request to the APK file automatic build tool, the APK file automatic build tool first receives and parses the user build requirements submitted by the user. The build requirements usually include, but are not limited to, the selection of functional modules of the target APK, version preferences, compatibility requirements, performance indicators, and interface styles, etc. For example, the user may specify the need to support the latest stable version module of the payment function, while requiring a simple interface style and adaptation to Android 12 or later systems. At the same time, the APK file automatic build tool obtains the application module code corresponding to the user's build requirements from Git Lab, and the code library contains multiple versions of application module code sets. The application module code is divided into two parts: bottom package code and HMI code. The bottom package code mainly covers core functional modules such as business logic, data processing, network communication, and security authentication; while the HMI code is responsible for visual display parts such as interface layout, user interaction, animation effects, and response events. For example, in an e-commerce APK project, the bottom package code includes order management modules, payment modules, and user authentication modules, while the HMI code contains interactive designs of product browsing pages, shopping cart interfaces, and settlement processes. Among them, the APK file automatic build tool is trained based on large language models through transfer learning, with strong intelligent understanding and reasoning capabilities. This enables the tool to accurately understand complex build requirements proposed by users, combine rich APK code version information, and automatically perform version screening, interface matching, and build process planning. For example, when the user wants to integrate a specific version of the payment SDK and ensure compatibility with the existing order management module interface, the tool can intelligently identify the relevant code versions and exclude incompatible versions to avoid conflicts or errors in subsequent integration. In addition, transfer learning enables the tool to quickly adapt to APK build requirements in different fields or emerging technologies, continuously improving build efficiency and quality.

[0025] Based on the user's construction requirements, the APK automatic construction tool first performs version filtering on the obtained APK code. This APK code usually contains multiple version codes of different modules of the same application, such as several version iterations of the underlying package code and the HMI code. The version filtering process filters out the code versions that best meet the conditions by parsing the parameters in the user's specific requirements, such as required functional features, compatible Android system versions, performance priorities, or security standards. The purpose of this is to avoid irrelevant or incompatible code from being included in the construction process, ensuring that the subsequent compilation and integration processes can be performed efficiently and stably, thereby producing a target APK file that meets the user's expectations. For example, suppose the user requires an APK that supports "payment functions" and is compatible with Android 11 and above. In the APK code library, there are multiple versions of the "payment module" that adapt to different Android versions, some of which only support Android 9 and below. Through version filtering, the tool will exclude those payment module versions that are incompatible with Android 11, and only keep the latest stable version that supports Android 11 and above. In addition, if the user emphasizes performance optimization, the version filtering will also preferentially select the module version that has been performance-optimized. Finally, the filtering result is a set of target code that meets the user's functional and compatibility requirements, laying the foundation for the subsequent interface verification and construction process, ensuring that the generated APK is both functionally complete and reliable in quality.

[0026] Subsequently, the APK file automatic construction tool performs consistency verification on the interaction interfaces between the underlying package code and the HMI code in the filtered target code. This verification mainly checks whether the underlying package and the HMI are synchronized in the definition and calling of interface methods, such as ensuring that the cancellation interface present in the underlying package also has a corresponding call or response logic in the HMI code, thereby verifying the compatibility and correctness of inter-module calls and avoiding runtime errors or application crashes caused by missing or mismatched interfaces.

[0027] If the interface consistency verification passes, the APK file automatic construction tool will trigger an intelligent matching process to automatically query in the pre-established APK construction knowledge graph according to the user's specific construction requirements. First, the APK file automatic construction tool locates the historical construction requirements in the knowledge graph that match the key features in the user's requirements by using these features as query conditions. Then, it extracts the APK construction process that meets the current requirements as the target workflow based on the historical construction requirements. This target workflow can accurately guide subsequent code compilation and integration operations, ensuring that the generated APK file meets the user's expected functional and quality requirements.

[0028] Finally, the deployment and build process is started to deploy the target workflow and target code to the configured Kubernetes environment. First, the environment configuration process of Kubernetes is completed, including writing a Dockerfile for building a standard compilation environment, and designing a Jenkins Pipeline script to realize the automation pipeline. Specifically, the Dockerfile is used to build a standard compilation environment image containing necessary dependencies and tool chains, which is then pushed to Kubernetes for scheduling. Then, in this configured Kubernetes environment, Jenkins calls the target workflow to compile the underlying package code and HMI code in the target code in a predetermined order, and finally generates the target APK file that meets the user's needs. Through containerization and automated continuous integration means, the consistency of the build environment and the efficiency and stability of the build process can be ensured.

[0029] Those skilled in the art can understand that, Figure 1 The framework diagram shown is only one example in which embodiments of the present application can be implemented. The scope of application of the embodiments of the present application is not limited by any aspect of this framework.

[0030] In order to facilitate the understanding of the present application, the automatic building method of an APK file provided by the embodiments of the present application is described below with reference to the accompanying drawings.

[0031] Referring to Figure 2 As shown in the figure, it is a flowchart of an automatic building method of an APK file provided by the embodiments of the present application, which is applied to an APK file automatic building tool obtained after transfer learning based on a large language model (LLM). Specifically, the APK file automatic building tool first fine-tunes a pre-trained large language model on a professional dataset related to APK building to enhance the model's understanding of specific domain knowledge and context in the APK building task through transfer learning technology. The process of transfer learning includes: selecting an existing general large language model as a base model; collecting and organizing a professional corpus containing information related to APK building processes, code structures, interface specifications, etc.; using the professional corpus to further train the base model supervised or unsupervised, optimizing its expression ability of language and logic in the APK building scenario; and finally generating a customized language model suitable for automatic parsing, reasoning and guiding APK building operations. Based on the model obtained through transfer learning, the automatic building tool can more accurately understand the user's building requirements, intelligently match historical building experience, and automatically generate a reasonable building workflow based on the current code state, thereby realizing efficient and accurate automatic building of APK files.

[0032] AsFigure 2 As shown, the method can include S201-S205:

[0033] S201: Obtain user build requirements and APK code corresponding to the user build requirements.

[0034] In the process of automatically building APK files, the user's build requirements and the APK code corresponding to the requirements need to be obtained first. The user's build requirements usually include specific information such as required functions, target device platforms, version numbers, etc., which directly guide the subsequent build process. The APK code corresponding to the requirements is a plurality of versions of application module code libraries prepared for different requirements, which cover various functional units of the application. Specifically, the application module code includes two parts: bottom package code and HMI code. The bottom package code is responsible for implementing core business logic, data processing, and system interface calls, while the HMI code defines the structure, layout, and interactive elements of the user interface to ensure consistency and friendliness of the user experience.

[0035] For example, assume that the user requirement is to develop an Android version v2.0 of a chat application. The APK code library corresponding to this requirement will contain multiple versions of chat function modules, such as bottom data encryption package code (v1.8, v2.0) and chat interface HMI code of different styles and resolution adaptation (default version, dark mode version). By accurately obtaining these build requirements and their corresponding multiple versions of APK code, the build tool can provide complete and accurate input for subsequent version screening, interface verification, and compilation and building, ensuring that the generated APK file meets the user's expected functional and performance requirements.

[0036] In one possible implementation, the APK code is stored in a Git Lab code management platform. By hosting multiple versions of application module code, including bottom package code and HMI code, in the Git Lab repository, version control, branch management, and collaborative development functions can be achieved. When the user's build requirements trigger the build process, the APK file automatic build tool can quickly pull the target code version corresponding to the current requirements through the Application Programming Interface (API) provided by GitLab, effectively ensuring the latest and consistency of the code. At the same time, with the help of Git Lab's permission management and audit functions, the security and traceability of source code management are improved, providing a stable and reliable foundation for the automatic build of APK files.

[0037] S202: Perform version filtering on the APK code based on the user build requirements to obtain target code.

[0038] The APK file automatic construction tool filters the stored multi-version APK code according to the specific construction requirements provided by the user, thereby accurately locating and extracting the target code that meets the requirements. The process first parses the version number, functional modules and compatibility requirements involved in the user's requirements, and then filters the code subset that meets these conditions from the code library containing multiple versions and modules. Through this filtering, irrelevant or outdated code versions can be effectively eliminated, ensuring that the code base used in the subsequent construction link is the most suitable and up-to-date.

[0039] For example, assuming that the user's requirements specify the construction of a social application supporting Android 11 system, and require the payment module to be version 2.5 or later, the automatic construction tool will filter out the code that meets the Android 11 compatibility and payment module version ≥2.5 from the underlying package code and HMI interface code in the repository as the target code for subsequent compilation and integration. This not only improves construction efficiency, but also ensures that the generated APK file is complete, stable and reliable in function.

[0040] S203: Interface consistency check on the interaction interface between the underlying package code and the HMI code in the target code.

[0041] The APK file automatic construction tool performs interface consistency check on the interaction interface between the underlying package code and the HMI code in the target code, ensuring that both are synchronized and matched in function calls, thereby avoiding construction errors or running abnormities caused by missing or inconsistent interfaces. Specifically, the tool checks whether all key interfaces provided by the underlying package code have corresponding call support in the HMI code, for example, if the underlying package code contains an interface method for "cancel" operation, the HMI code must also implement the corresponding "cancel" function entry to ensure that the user interface can correctly trigger and respond to the operation. Conversely, if an interface exists in the underlying package code but is missing in the HMI code, it is considered inconsistent, and the APK file automatic construction tool will prevent the construction process and feedback error information.

[0042] For example, assuming that the underlying package provides a cancelTransaction() interface for canceling payment operations, if the HMI code does not implement the corresponding cancel button or event binding, the interface consistency check will fail, prompting the developer to complete the interface function, ensuring that the final generated APK can fully support all underlying logic functions, improving the stability and user experience of the software.

[0043] S204: If the interface consistency check passes, query the APK construction knowledge graph for the construction workflow of the APK file that matches the user's construction requirements, and obtain the target workflow.

[0044] If the interface consistency check passes, the APK file automatic construction tool will retrieve the augmented generation (RAG) technology based on the specific construction needs of the user, query the pre-established APK construction knowledge graph to find a highly matched construction workflow. This knowledge graph collects a large number of binding relationships between user construction needs and corresponding construction workflows, and through the structured representation and association of demand characteristics such as function modules, version numbers, and compatible platforms, it realizes efficient mapping between demand and construction process. Based on this binding relationship, the most matched construction workflow can be quickly located and called according to the current user's construction needs, ensuring the accuracy and execution efficiency of the construction scheme, and avoiding repeated design and invalid attempts. Through this process, not only the accuracy and efficiency of the construction scheme are improved, but also the existing mature process is reused, reducing the construction risk.

[0045] S205: According to the target workflow, the underlying package code and HMI code in the target code are sequentially called and compiled to generate a target APK file matching the user's construction needs.

[0046] According to the target workflow, the APK file automatic construction tool can sequentially call and compile the underlying package code and HMI code in the target code according to the steps predetermined in the target workflow. Specifically, this process first parses the dependency relationship between modules to ensure that the underlying package code such as business logic and data processing modules is compiled first, then the HMI code that depends on these modules is compiled, and finally resource integration and packaging are performed. Through the gradual execution of the compilation, linking and testing links, the construction tool effectively guarantees the compatibility and functional integrity of the code, and finally generates an APK file that meets the user's construction needs.

[0047] Based on the description of S201-S205, the embodiment of the application provides an automatic APK file construction method, which first acquires the construction requirement of a user and a corresponding multi-version APK code library, the code library including two parts of underlying package code and HMI code. Then, the APK code is filtered according to the construction requirement of the user, so as to filter out target code meeting the condition. Then, consistency check is performed on the interaction interface between the underlying package code and the HMI code in the target code, to ensure that the interfaces of the two are matched and the function call is correct. If the interface consistency check passes, in the pre-constructed APK construction knowledge graph, a matched construction workflow is queried according to the user requirement, to obtain a target workflow most suitable for the current requirement. Finally, the underlying package code and the HMI code in the target code are sequentially called and compiled according to the target workflow, to complete the generation of the APK file, to meet the specific construction requirement of the user, and to realize efficient and accurate APK automatic construction. The application collects the construction requirement of the user and the application module code (i.e., APK code) of multiple versions, realizes intelligent version filtering of the APK code, and ensures that the selected code can accurately match the specific requirement of the user. Meanwhile, for the interface interaction between the underlying package and the HMI, an interface consistency check mechanism is introduced, to effectively avoid runtime errors and application crashes caused by interface incompatibility in traditional manual integration. In addition, the application relies on the APK construction knowledge graph, automatically retrieves and generates a corresponding construction workflow based on the user requirement, to replace manual design and execution of the workflow, so that the construction process is more intelligent and standardized.

[0048] In a possible implementation manner, the step S205 of sequentially calling and compiling the underlying package code and the HMI code in the target code according to the target workflow to generate a target APK file matching the user construction requirement includes A1-A2.

[0049] A1: The Kubernetes is configured, and the target workflow and the target code are deployed to the configured Kubernetes.

[0050] In order to guarantee the efficiency and stability of the APK automatic construction process, the Kubernetes environment needs to be configured first. The configuration includes preparing a standardized compilation environment image and building an automatic construction pipeline, and the target workflow and the target code are uniformly deployed to the configured Kubernetes cluster. By containerizing the construction task and scheduling it to the Kubernetes platform, not only is the dynamic allocation and elastic scaling of resources realized, but also the consistency and reusability of the construction environment are ensured, thereby providing reliable basic support for the subsequent sequential calling and compiling of the target code.

[0051] In a possible implementation, the environment configuration process of the Kubernetes includes: building a standard compilation environment image and writing a Jenkins Pipeline script; the building of the standard compilation environment image includes writing a Dockerfile to build the standard compilation environment image, and pushing the Dockerfile to the Kubernetes cluster.

[0052] Specifically, the configuration process of the Kubernetes environment mainly includes two aspects: first, building a standard compilation environment image, which specifically defines the required compilation tools, dependent libraries and related configurations through writing a Dockerfile, and then building a standardized compilation environment image using the Dockerfile, and pushing the image to the Kubernetes cluster for unified use within the cluster; second, writing a Jenkins Pipeline script for automatic scheduling and execution of the build process to achieve orderly compilation and packaging of the target code, thereby ensuring stable and efficient operation of the entire APK automatic build process.

[0053] A2: In the configured Kubernetes, the target workflow is called by Jenkins to compile the underlying package code and HMI code in the target code in sequence to generate the target APK file.

[0054] In the configured Kubernetes environment, with the help of the Jenkins automated build tool, the underlying package code and HMI code in the target code are sequentially called and compiled according to the pre-defined target workflow. Through the Jenkins Pipeline script, automatic scheduling and execution of the compilation task are achieved, ensuring that each module code is correctly compiled, integrated and packaged according to the dependency relationship, and finally generating a target APK file that meets user requirements. This process not only improves the build efficiency, but also ensures the stability and consistency of the build results.

[0055] Steps A1-A2 not only make full use of the container management and orchestration capabilities of Kubernetes, but also achieve an automated and efficient build process through Jenkins Pipeline.

[0056] In a possible implementation, in step A2, in the configured Kubernetes, the target workflow is called by Jenkins to compile the underlying package code and HMI code in the target code in sequence to generate the target APK file, including B1-B2:

[0057] B1: In the configured Kubernetes, the Jenkins calls the CMake tool, and uses the CMake tool to perform static library compilation on the underlying package code in the target code according to the target workflow, to obtain a static library file.

[0058] In the configured Kubernetes environment, the Jenkins calls the CMake tool, and performs a static library compilation operation on the underlying package code in the target code according to a predetermined target workflow. This process uses CMake to structurally manage and compile the underlying code, generating stable and reusable static library files, laying the foundation for subsequent module linking and application integration, thereby ensuring the normativity and efficiency of the build process.

[0059] B2: Using the Jenkins, the static library file is referenced to perform associated compilation on the HMI code in the target code according to the target workflow, to generate the target APK file.

[0060] Using the configured Jenkins according to the target workflow, the previously generated static library file is sequentially called and referenced to perform associated compilation on the HMI code in the target code. By effectively linking the HMI code with the underlying static library, the integration of functions between modules is achieved, and finally the packaging and generation of the APK file is completed. This process ensures that the generated APK file not only has complete interface interaction capabilities, but also can call underlying logic, thereby meeting the specific construction needs of users.

[0061] Steps B1-B2 implement efficient collaboration of underlying code and interface code through this phased and sequential compilation strategy, ensuring the functional integrity and construction quality of the APK file.

[0062] In one possible implementation, the present application also provides a method for building an APK construction knowledge graph, as shown in Figure 3 , Figure 3 The implementation process of the APK construction knowledge graph construction method provided by the embodiments of the present application is specifically implemented by steps S301-S304:

[0063] S301: Obtain a plurality of historical construction requirements and construction information of APK files corresponding to each of the plurality of historical construction requirements.

[0064] First, a plurality of historical build requirements are collected, which represent specific build requirements of APK files by users at different times or in different projects. For each historical build requirement, detailed build information of the corresponding APK file is further obtained, which includes the dependency relationship between HMI code and underlying package code. By analyzing these dependency relationships, the calling sequence and collaboration mode between modules can be determined.

[0065] For example, assume that the following two historical build requirements are collected:

[0066] Requirement A: Develop an APK application with user login functionality.

[0067] The build information corresponding to requirement A includes: the human-machine interaction code (HMI code) of the login interface depends on the underlying package code of the user authentication module, and the login button triggers the authentication logic to verify the user's identity.

[0068] Requirement B: Develop an APK application that supports message push functionality.

[0069] The build information corresponding to requirement B includes: the HMI code of the message display interface depends on the underlying package code of the push service, and the interface needs to call the underlying push module interface to obtain real-time messages.

[0070] Through these build information, the dependency relationship between the human-machine interface and the underlying functional modules in different APKs can be clearly understood, providing basic data support for the design and automation of subsequent build processes.

[0071] S302: Extract the process based on a plurality of build information to obtain a plurality of APK build processes.

[0072] Based on a plurality of historical build requirements and their corresponding detailed build information, the code modules, compilation order and dependency relationships involved in each build instance are analyzed and summarized to extract representative build steps and processes. Specifically, the calling chain between HMI code and underlying package code is identified, as well as the order of key operations such as compilation, linking and packaging, thereby forming a complete and structured APK build process. These processes not only reflect the dependency relationship between different functional modules, but also reveal the steps that must be followed in the build process. Through the process extraction of multiple build information, a series of standardized build processes suitable for different APK functional requirements are obtained, providing a scientific and reasonable execution path for the automated build platform, achieving efficient reuse and precise scheduling of build work.

[0073] For example, assume that the APK build information for the user login function, the process extraction result includes:

[0074] Compile the underlying authentication module code to generate a static library;

[0075] Compile the login interface HMI code and link the authentication static library;

[0076] Resource integration and APK packaging.

[0077] For APK build information of the message push function, the process extraction result includes:

[0078] Compile the push service underlying package code to generate a static library;

[0079] Compile the message display interface HMI code and associate the push static library;

[0080] Configure the push permission and service, and complete the APK packaging.

[0081] Then these processes are sorted and standardized according to the execution order, combined with the dependency relationship and operation steps of each link, and the standardized APK build process is abstracted to form a structured and reusable build scheme to support automated build execution under different functional requirements.

[0082] S303: Bind each APK build process with its corresponding historical build requirement to obtain multiple binding relationships.

[0083] After the extraction of multiple APK build processes, each build process is accurately matched and bound with its corresponding historical build requirement. That is, for each specific historical requirement, an applicable build process is explicitly associated to ensure that the process can fully and effectively meet the functional and performance requirements in the requirement. Through this binding relationship, not only is the one-to-one correspondence between the requirement and the build execution path achieved, but also it is convenient to quickly locate the appropriate process scheme during subsequent automated construction, improving the construction efficiency and accuracy. In addition, this structured binding relationship helps to accumulate construction experience, supports the optimization and upgrading of the construction process, and the construction of the knowledge graph, providing a solid data foundation and decision support for continuous integration and delivery.

[0084] S304: Graph modeling of the multiple binding relationships to obtain the APK build knowledge graph.

[0085] After obtaining the binding relationship between multiple historical build requirements and corresponding APK build processes, these binding relationships are used as basic data and are structured by graph modeling method. Specifically, the requirements and build processes are abstracted as nodes, and the association between them is abstracted as edges, building a multi-dimensional and multi-level APK build knowledge graph. This knowledge graph only visually presents the mapping relationship between each build requirement and process. Through this graph modeling, global cognition and intelligent reasoning of the APK build process can be achieved, providing strong technical support for the continuous integration and delivery of APK.

[0086] The APK building knowledge graph constructed through the above steps not only provides data support for automated building, but also provides a reference for future requirement changes and building optimization, ultimately forming a dynamically updated and easily expandable knowledge base.

[0087] Based on the automatic APK file building method provided in the above method embodiments, this application also provides an automatic APK file building tool, which will be described below with reference to the accompanying drawings.

[0088] In one possible implementation, this application also provides a method for generating APK code adjustment suggestions, see [link to relevant documentation]. Figure 4 , Figure 4 A flowchart illustrating the implementation of an APK code adjustment suggestion generation method provided in this application embodiment is shown, which can be specifically implemented through steps S401-S402:

[0089] S401: If the interface consistency check fails, generate APK code adjustment suggestions.

[0090] When performing consistency checks on the interaction interfaces between the underlying package code and the HMI code in the target code, if it is found that the two are out of sync or mismatched in their function calls, resulting in a failure to work together correctly, the interface consistency check is deemed to have failed. Based on this result, the system automatically generates APK code adjustment suggestions to address the issue, specifically pointing out the reasons and locations of the interface inconsistencies, and providing corresponding correction solutions or optimization strategies. This guides developers to adjust the code in a timely manner, ensuring that the interfaces between the underlying package and the HMI code can accurately connect, thereby guaranteeing the overall functional integrity and stability of the APK application.

[0091] S402: Send the APK code adjustment suggestion to the user so that the user can adjust the interaction interface between the underlying package code and the HMI code in the target code based on the APK code adjustment suggestion.

[0092] After generating APK code adjustment suggestions, these suggestions will be sent to the user to help them accurately understand the interface issues between the underlying package code and the HMI code. By receiving and referring to these adjustment suggestions, users can make necessary modifications and optimizations to the calling methods, parameter structures, or data transfer logic in the target code to address specific interface inconsistencies.

[0093] This process not only ensures that the interaction interface between the underlying package and the HMI code achieves the design expectation, but also effectively improves the code's compatibility and runtime stability, ultimately guaranteeing the correct implementation and efficient collaboration of the APK application's functions.

[0094] In one possible implementation, the self-optimization method of the application further comprises the following steps: Figure 5 , Figure 5 The implementation flowchart of the self-optimization method provided by the embodiment of the application can be implemented by steps S501-S502:

[0095] S501: Calculate the response time of the APK file automatic construction tool and evaluate the matching degree of the target workflow and the user construction demand.

[0096] First, the response time of the APK file automatic construction tool when executing the target workflow is accurately calculated, and the total time required from receiving the user construction request to completing the construction task is measured to reflect the running efficiency and performance of the tool. At the same time, the matching degree between the target workflow and the actual construction demand of the user is evaluated, and whether the function modules, execution steps and resource allocation involved in the target workflow meet the specific requirements of the user demand is judged to determine the rationality and applicability of the construction process. The comprehensive analysis of the two indicators can not only reveal the performance bottleneck and process deficiency of the current construction tool, but also provide a scientific basis for subsequent optimization decisions, ensuring that the automatic construction process is efficient and accurate to meet the user demand.

[0097] S502: Based on the response time and the matching degree, the APK file automatic construction tool is optimized by using a reinforcement learning algorithm.

[0098] Based on the calculated response time of the APK file automatic construction tool and the matching degree of the target workflow and the user construction demand, the reinforcement learning algorithm is used to intelligently optimize the construction tool. Specifically, reinforcement learning tries different construction strategies and process adjustments, and takes the response time and the matching degree as the key indicators of the reward function, so as to make the algorithm learn to select the optimal strategy that can shorten the construction time and improve the demand matching degree in multiple iterations. For example, when a certain construction process has a fast response speed but a low matching degree, the algorithm will adjust the construction steps or resource allocation and try to introduce additional verification links to improve the matching degree. Conversely, if the matching degree is high but the response time is long, the algorithm may optimize the parallel compilation or cache mechanism to speed up the construction. Through this feedback-based dynamic adjustment, reinforcement learning continuously improves the overall performance of the APK construction tool, and finally realizes efficient and accurate satisfaction of diversified user demand.

[0099] The self-optimization method can effectively improve the intelligent level and construction efficiency of the APK automatic construction tool, and meet the changing user demand and complex construction environment.

[0100] In one possible implementation, the self-optimization method of the application further comprises the following steps: Figure 6 , Figure 6A flowchart illustrating the implementation of a manual optimization method provided in this application embodiment is shown, which can be specifically implemented through steps S601-S602:

[0101] S601: Obtain user optimization strategies.

[0102] Optimization strategies provided by users are obtained through interactive interfaces or feedback mechanisms. These strategies aim to improve the overall performance and applicability of the APK automatic build system. Specifically, user optimization strategies include at least one of the following: First, optimization strategies for building a knowledge graph for APKs, including improving node information, correcting relationship errors, or introducing new related data to enhance the accuracy and expressiveness of the graph; second, optimization strategies for the version filtering function in the APK file automatic build tool, such as improving version selection rules and enhancing compatibility judgment logic, thereby improving the accuracy and stability of the build process; and third, optimization strategies for APK code adjustment suggestions, which help developers more effectively solve code problems such as interface inconsistencies by improving the suggestion generation algorithm or enriching adjustment schemes. By obtaining these diverse and targeted user optimization strategies, key modules can be improved and upgraded in a targeted manner according to actual needs.

[0103] S602: Optimize the APK to build a knowledge graph and / or the APK file automatic building tool based on the user optimization strategy.

[0104] Based on user-provided optimization strategies, targeted improvements and adjustments are made to the APK knowledge graph construction and automated APK file construction tools to enhance overall construction performance and user experience. For example, when users suggest strategies to optimize the APK knowledge graph construction, the nodes and edges in the graph can be supplemented or corrected based on the suggestions, improving the expression of dependencies between modules and making the knowledge graph more accurate and comprehensive. If users propose optimization strategies for the version filtering function in the automated construction tool, the version filtering rules can be adjusted to enhance the ability to judge the compatibility and priority of different versions, thereby avoiding construction failures caused by incorrect versions. In addition, if the optimization strategies involve suggestions for APK code adjustments, the suggestion generation algorithm can be improved to increase the accuracy of problem localization and the practicality of the suggestions. By combining user professional experience and feedback, adaptive manual optimization is achieved, driving the continuous improvement of the automated APK construction process and tools.

[0105] This manual optimization method effectively integrates user experience, providing a flexible and efficient technical means for continuous improvement and precise control of the APK building process.

[0106] In one possible implementation, this application also provides a method for version filtering of APK code, see [link to relevant documentation]. Figure 7 , Figure 7This is a flowchart illustrating the implementation of an APK code version filtering method provided in this application embodiment. Accordingly, step S202 filters the APK code based on the user's build requirements to obtain the target code, which can be specifically implemented through steps S701-S704:

[0107] S701: Calculate the upload time of the APK code and the upload time of the user's build request to obtain the first time and the second time.

[0108] First, the upload time of the APK code is obtained, that is, the specific time when the code version was submitted to the code repository or build platform, as the first time. Simultaneously, the upload time of the user's build request is extracted, that is, the time when the user initiated the build request, as the second time. By determining these two time points, the newness and relevance of the code version to the user's needs can be judged. For example, if an APK code version was uploaded at 10:00 AM on May 1, 2024, and the user's build request was uploaded at 9:00 AM on May 2, 2024, then the first time is "2024-05-01 10:00" and the second time is "2024-05-02 9:00". This time data will serve as an important basis for subsequent version filtering and matching to determine whether the code is suitable for the current user's build task.

[0109] S702: Identify the following condition: whether the time difference between the first time and the second time is less than or equal to a preset time threshold. If yes, proceed to step S703; otherwise, proceed to step S704.

[0110] After obtaining the upload time of the APK code (first time) and the upload time of the user's build request (second time), the time difference between the two is calculated and compared with a preset time threshold. If the time difference is less than or equal to the threshold, it indicates that the code version is close to the user's requirements and has good timeliness and relevance. In this case, the process automatically proceeds to step S703, where the APK code is filtered based on the user's requirements. Conversely, if the time difference exceeds the preset threshold, it indicates that the code version may be too old or unsuitable for the current requirements. In this case, the process proceeds to step S704, where the code is displayed to the user for manual confirmation to ensure that the selected code version meets the actual requirements.

[0111] For example, assuming the preset time threshold is 24 hours, if the code upload time is 10:00 on June 1, 2024, and the user request upload time is 8:00 on June 2, 2024, the time difference between the two is 22 hours, which is less than the threshold, then automatic filtering is directly executed (step S703); if the request upload time is 10:00 on June 3, 2024, the time difference is 48 hours, then manual confirmation is required (step S704).

[0112] S703: Based on the user's build requirements, the APK code is version filtered to obtain the target code.

[0113] In step S703, based on the specific requirements of the user's building needs, multiple versions in the APK code library are screened and filtered to select the code version that best meets the current requirements, thereby obtaining the target code.

[0114] S704: The APK code is displayed to the user for manual confirmation; if the APK code is confirmed to be usable by the user, the version of the APK code is filtered based on the user's building requirements to obtain the target code.

[0115] In step S704, when the time difference between the upload time of the APK code and the upload time of the user's build request exceeds a preset threshold, it indicates that there may be uncertainty or insufficient version matching in the automatic judgment. At this time, the relevant APK code will be fully displayed to the user, inviting the user to confirm manually. The user can evaluate whether the code meets the current build requirements and is usable by viewing information such as code version, commit history, or change log. If the user confirms that the code is usable, further version filtering will be performed on the code according to the user's build requirements to select the most suitable target code for the build process.

[0116] For example, suppose an APK code version is uploaded on May 28, 2024, while the user's build request is uploaded on June 2, 2024, with a time difference of 5 days, which exceeds the 1-day threshold limit. In this case, the code details will be shown to the user for review. If the user confirms that the version contains the required functions and has no major defects, the code will be further refined based on the requirements, and the target code that meets the requirements will be obtained for build use. This balances the efficiency of automation with the accuracy of human judgment.

[0117] The above process enables automated version selection, improving build efficiency, while also allowing for manual intervention in abnormal situations, ensuring the rationality of the APK code version and its match with user needs.

[0118] See Figure 8 As shown, Figure 8 This is a schematic diagram of an APK file automatic building tool provided in an embodiment of this application. Figure 8 As shown, the APK file automatic building tool includes: a perception layer 801, an analysis layer 802, a decision layer 803, and an execution layer 804; the perception layer 801 is connected to the analysis layer 802; the analysis layer 802 is connected to the decision layer 803; and the decision layer 803 is connected to the execution layer 804.

[0119] The perception layer 801 is used to acquire user build requirements and APK code corresponding to the user build requirements; the APK code includes application module code of multiple versions; the application module code includes underlying package code and HMI code;

[0120] The analysis layer 802 is used to perform version filtering on the APK code based on the user's construction requirements to obtain the target code;

[0121] The decision layer 803 is used to perform interface consistency verification on the interaction interface between the underlying package code and the HMI code in the target code; if the interface consistency verification passes, the decision layer 803 queries the APK construction knowledge graph to find the construction workflow of the APK file that matches the user's construction requirements, and obtains the target workflow.

[0122] The execution layer 804 is used to sequentially call and compile the underlying package code and HMI code in the target code according to the target workflow, and generate a target APK file that matches the user's building requirements.

[0123] In one possible implementation, the execution layer 804 is specifically used for:

[0124] Configure the Kubernetes environment and deploy the target workflow and target code to the configured Kubernetes.

[0125] In the configured Kubernetes, Jenkins is used to call the target workflow to compile the underlying package code and HMI code in the target code in sequence, generating the target APK file.

[0126] In one possible implementation, the execution layer 804 is further configured to:

[0127] In the configured Kubernetes, the CMake tool is invoked through Jenkins, and the CMake tool is used to compile the underlying package code in the target code into a static library according to the target workflow, thereby obtaining a static library file;

[0128] Using the Jenkins, the HMI code in the target code is associated and compiled according to the target workflow by referencing the static library file, thereby generating the target APK file.

[0129] In one possible implementation, the tool further includes a knowledge graph construction spectral layer, which is specifically used for:

[0130] Obtain multiple historical build requirements, and build information of the APK files corresponding to each of the multiple historical build requirements; the build information includes the dependency relationship between HMI code and underlying packages;

[0131] Based on the multiple construction information, process extraction is performed to obtain multiple APK construction processes;

[0132] Each APK build process is bound to its corresponding historical build requirements, resulting in multiple binding relationships;

[0133] The multiple binding relationships are modeled in a graph format to obtain the APK's knowledge graph.

[0134] In one possible implementation, the decision layer 803 is further configured to:

[0135] If the interface consistency check fails, APK code adjustment suggestions will be generated.

[0136] The proposed APK code adjustments are sent to the user so that the user can adjust the interaction interface between the underlying package code and the HMI code in the target code based on the proposed APK code adjustments.

[0137] In one possible implementation, the tool further includes a self-optimizing layer, which is specifically used for:

[0138] Calculate the response time of the APK file automatic build tool and evaluate the degree of match between the target workflow and the user's build requirements;

[0139] Based on the response time and the matching degree, a reinforcement learning algorithm is used to optimize the APK file automatic building tool.

[0140] In one possible implementation, the tool further includes manual optimization, which is specifically used for:

[0141] Obtain user optimization strategies; the user optimization strategies include at least one of the following: optimization strategies for building knowledge graphs in APKs, optimization strategies for version filtering functions in APK file automatic building tools, and optimization strategies for APK code adjustment suggestions;

[0142] The knowledge graph for the APK and / or the automatic APK file building tool are optimized based on the user optimization strategy.

[0143] In one possible implementation, the analysis layer 802 is specifically used for:

[0144] Calculate the upload time of the APK code and the upload time of the user's build request to obtain the first time and the second time;

[0145] If the time difference between the first time and the second time is less than or equal to a preset time threshold, then the APK code is version filtered based on the user's building requirements to obtain the target code;

[0146] If the time difference between the first time and the second time is greater than a preset time threshold, the APK code is displayed to the user for manual confirmation; if the APK code is confirmed to be usable by the user, the APK code is version filtered based on the user's building requirements to obtain the target code.

[0147] In addition, this application embodiment also provides a processor for running a computer program, which executes the automatic APK file building method described above when running the program.

[0148] This application achieves intelligent version filtering of APK code by acquiring the user's build requirements and multiple versions of application module code (including underlying package code and HMI code). This process ensures that the code used in subsequent builds accurately matches the user's specific needs, thereby improving development efficiency. Simultaneously, to effectively avoid common interface incompatibility issues in traditional manual integration, this application introduces an interface consistency verification mechanism, significantly reducing the risk of runtime exceptions and crashes caused by interface errors. Furthermore, based on user needs, this application also utilizes the APK to build a knowledge graph, automatically querying and generating corresponding build workflows. This method replaces the cumbersome steps previously dependent on manual design and execution, making the build process more intelligent and standardized. Through these measures, not only is the build process optimized, but the stability of APK files and the user experience are also improved.

[0149] It should be noted that the various embodiments in this specification are described in a progressive manner, and the same or similar parts between the various embodiments can be referred to mutually. Each embodiment focuses on describing the differences from other embodiments. In particular, for the embodiments of the APK file automatic building tool, since they are basically similar to the method embodiments, the description is relatively simple, and the relevant parts can be referred to the description of the method embodiments. The APK file automatic building tool embodiments described above are merely illustrative. The units described as separate components may or may not be physically separate, and the components indicated as units may or may not be physical units, that is, they may be located in one place or distributed across multiple network units. Some or all of the modules can be selected to achieve the purpose of this embodiment solution according to actual needs. Those skilled in the art can understand and implement this without creative effort.

[0150] The above description is merely one specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the technical scope disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

Claims

1. A method for automatically building APK files, characterized in that, An automatic APK file building tool for Android applications is provided, wherein the tool is derived from a large language model through transfer learning, and the method includes: Obtain user build requirements and the corresponding APK code; the APK code includes multiple versions of application module code; the application module code includes underlying package code and human-computer interaction interface (HMI) code; Based on the user's build requirements, the APK code is version filtered to obtain the target code; Perform interface consistency verification on the interaction interface between the underlying package code and the HMI code in the target code; If the interface consistency check passes, the build workflow of the APK file that matches the user's build requirements is queried in the APK build knowledge graph to obtain the target workflow; According to the target workflow, the underlying package code and HMI code in the target code are called and compiled in an orderly manner to generate a target APK file that matches the user's building requirements.

2. The method according to claim 1, characterized in that, The step of sequentially calling and compiling the underlying package code and HMI code in the target code according to the target workflow to generate a target APK file matching the user's building requirements includes: Configure the Kubernetes environment and deploy the target workflow and target code to the configured Kubernetes. In the configured Kubernetes, Jenkins is used to call the target workflow to compile the underlying package code and HMI code in the target code in sequence, generating the target APK file.

3. The method according to claim 2, characterized in that, In the configured Kubernetes environment, Jenkins is used to invoke the target workflow to sequentially compile the underlying package code and HMI code in the target code, generating the target APK file, including: In the configured Kubernetes, the CMake tool is invoked through Jenkins, and the CMake tool is used to compile the underlying package code in the target code into a static library according to the target workflow, thereby obtaining a static library file; Using the Jenkins, the HMI code in the target code is associated and compiled according to the target workflow by referencing the static library file, thereby generating the target APK file.

4. The method according to claim 1, characterized in that, The process of constructing the knowledge graph using the APK includes: Obtain multiple historical build requirements, and build information of the APK files corresponding to each of the multiple historical build requirements; the build information includes the dependency relationship between HMI code and underlying packages; Based on the multiple construction information, process extraction is performed to obtain multiple APK construction processes; Each APK build process is bound to its corresponding historical build requirements, resulting in multiple binding relationships; The multiple binding relationships are modeled in a graph format to obtain the APK's knowledge graph.

5. The method according to claim 1, characterized in that, The method further includes: If the interface consistency check fails, APK code adjustment suggestions will be generated. The proposed APK code adjustments are sent to the user so that the user can adjust the interaction interface between the underlying package code and the HMI code in the target code based on the proposed APK code adjustments.

6. The method according to claim 1, characterized in that, The method further includes: Calculate the response time of the APK file automatic build tool and evaluate the degree of match between the target workflow and the user's build requirements; Based on the response time and the matching degree, a reinforcement learning algorithm is used to optimize the APK file automatic building tool.

7. The method according to claim 1, characterized in that, The method further includes: Obtain user optimization strategies; the user optimization strategies include at least one of the following: optimization strategies for building knowledge graphs in APKs, optimization strategies for version filtering functions in APK file automatic building tools, and optimization strategies for APK code adjustment suggestions; The knowledge graph for the APK and / or the automatic APK file building tool are optimized based on the user optimization strategy.

8. The method according to claim 1, characterized in that, The step of filtering the APK code based on the user's build requirements to obtain the target code includes: Calculate the upload time of the APK code and the upload time of the user's build request to obtain the first time and the second time; If the time difference between the first time and the second time is less than or equal to a preset time threshold, then the APK code is version filtered based on the user's building requirements to obtain the target code; If the time difference between the first time and the second time is greater than a preset time threshold, the APK code is displayed to the user for manual confirmation; if the APK code is confirmed to be usable by the user, the APK code is version filtered based on the user's building requirements to obtain the target code.

9. An automatic APK file building tool, the tool comprising: The layers are: perception layer, analysis layer, decision-making layer, and execution layer. The perception layer is connected to the analysis layer; The analysis layer is connected to the decision-making layer; The decision-making layer is connected to the execution layer; The perception layer is used to acquire user build requirements and the APK code corresponding to those requirements; the APK code includes multiple versions of application module code; the application module code includes underlying package code and HMI code. The analysis layer is used to filter the APK code based on the user's build requirements to obtain the target code; The decision layer is used to perform interface consistency verification on the interaction interface between the underlying package code and the HMI code in the target code; if the interface consistency verification passes, the decision layer queries the APK construction knowledge graph for the construction workflow of the APK file that matches the user's construction requirements to obtain the target workflow. The execution layer is used to sequentially call and compile the underlying package code and HMI code in the target code according to the target workflow, and generate a target APK file that matches the user's build requirements.

10. A processor, characterized in that, Used to run a computer program, which, when running, executes the automatic construction method of an APK file as described in any one of claims 1-8.

Images