Application package generation method, electronic device, and computer-readable storage medium

Abstract

The application provides an application package generation method, an electronic device and a computer readable storage medium, and relates to the technical field of software development. The method comprises the following steps: loading and running a build plug-in mounted on a build root node, and obtaining a build context object in the memory through a callback function mounted on the build root node, wherein the build root node is a build root node in a target project corresponding to a target application package to be generated; when the build plug-in is running, a build configuration file in the memory is read through the build context object, a signature configuration item in the build configuration file is dynamically modified according to a current development stage of the target project, and the build context object is updated based on the modified build configuration file; and a build process is executed based on the updated build context object to generate the target application package. According to the application, the signature configuration is automatically modified through the build plug-in, manual switching of signature parameters is not required, and the build capability and generation efficiency of the application package are significantly improved.

Description

Technical Field

[0001] This application relates to the field of software development technology, and more specifically, to an application package generation method, an electronic device, and a computer-readable storage medium. Background Technology

[0002] During application development, signature configuration is usually managed through the build-profile.json5 file in the project directory. Generally, the signature configuration is hardcoded into the build-profile.json5 file. In actual projects, there are multiple functional modules. For different functional modules, developers need to frequently switch between different build environments such as debugging, testing and official release and modify the signature configuration to generate application packages (HarmonyOSAbility Package, HAP).

[0003] Currently, the main way to modify the signature configuration is to directly modify the build-profile.json5 configuration file. However, every time the environment is switched, the build-profile.json5 configuration file needs to be manually modified. This not only makes it easy to miss or modify the wrong file, but also causes frequent conflicts in configuration files due to differences in the local environments of different developers, thus reducing the efficiency of application package generation. Summary of the Invention

[0004] The purpose of this application is to address the shortcomings of the prior art by providing an application package generation method, electronic device, and computer-readable storage medium. This addresses the problem that manually modifying the signature configuration of the build-profile.json5 configuration file in the prior art is prone to omissions or errors, and that for different developers, the differences in their local environments can lead to frequent conflicts in the configuration files, thereby reducing the efficiency of application package generation.

[0005] To achieve the above objectives, the technical solutions adopted in the embodiments of this application are as follows: In a first aspect, embodiments of this application provide an application package generation method, the method comprising: Load and run the build plugin mounted on the build root node, and obtain the build context object in memory through the callback function mounted on the build root node, wherein the build root node is the build root node in the target project corresponding to the target application package to be generated; When the build plugin runs, it reads the build configuration file in memory through the build context object, dynamically modifies the signature configuration items in the build configuration file according to the current development stage of the target project, and updates the build context object based on the modified build configuration file. The build process is executed based on the updated build context object to generate the target application package.

[0006] As one possible implementation, before loading and running the build plugin mounted on the build root node, the following steps are also included: Create the build plugin, generate a corresponding plugin identifier for the build plugin, and add the build plugin to the plugin registration array; Call the registration interface of the root node to attach the callback function to the root node.

[0007] As one possible implementation, loading and running the build plugin mounted on the build root node includes: In response to the completion of the configuration evaluation of the root node, the build plugin is retrieved from the plugin registration array based on the plugin identifier of the build plugin, and the build plugin is loaded and run.

[0008] As one possible implementation, dynamically modifying the signature configuration item in the build configuration file according to the current development stage of the target project includes: Obtain the environmental parameters of the current development stage of the target project, and determine the target construction mode based on the environmental parameters; The signature configuration item in the build configuration file is dynamically modified according to the target build pattern.

[0009] As one possible implementation, dynamically modifying the signature configuration item in the build configuration file according to the target build mode includes: If the target build mode is debug mode, then determine the location information of the signature configuration item in the build configuration file; The configuration writing interface corresponding to the build context object is invoked so that the configuration writing interface removes the signature configuration reference field in the signature configuration item of the build configuration file based on the location information of the signature configuration item, while keeping the original build configuration file on the disk unchanged.

[0010] As one possible implementation, the step of executing the build process based on the updated build context object to generate the target application package includes: The build process is executed based on the updated build context object to generate the unsigned target application package.

[0011] As one possible implementation, after executing the build process based on the updated build context object and generating the unsigned target application package, the method further includes: The script invokes a signing tool, which is then used to independently sign the unsigned target application package.

[0012] As one possible implementation, dynamically modifying the signature configuration item in the build configuration file according to the target build mode includes: If the target build mode is release mode, then determine the location information of the signature configuration item in the build configuration file; Obtain the certificate materials and call the configuration writing interface corresponding to the build context object, so that the configuration writing interface adds the certificate materials to the signature configuration item based on the location information of the signature configuration item, while keeping the original build configuration file on the disk unchanged.

[0013] Secondly, embodiments of this application provide an application package generation apparatus, the apparatus comprising: The loading module is used to load and run the build plugin mounted on the build root node, and obtain the build context object in memory through the callback function mounted on the build root node, wherein the build root node is the build root node in the target project corresponding to the target application package to be generated; The signature configuration module is used to read the build configuration file in memory through the build context object when the build plugin is running, dynamically modify the signature configuration items in the build configuration file according to the current development stage of the target project, and update the build context object based on the modified build configuration file. The generation module is used to execute the build process based on the updated build context object to generate the target application package.

[0014] As one possible implementation, the loading module is also used for: Create the build plugin, generate a corresponding plugin identifier for the build plugin, and add the build plugin to the plugin registration array; Call the registration interface of the root node to attach the callback function to the root node.

[0015] As one possible implementation, the loading module is specifically used for: In response to the completion of the configuration evaluation of the root node, the build plugin is retrieved from the plugin registration array based on the plugin identifier of the build plugin, and the build plugin is loaded and run.

[0016] As one possible implementation, the signature configuration module is specifically used for: Obtain the environmental parameters of the current development stage of the target project, and determine the target construction mode based on the environmental parameters; The signature configuration item in the build configuration file is dynamically modified according to the target build pattern.

[0017] As one possible implementation, the signature configuration module is specifically used for: If the target build mode is debug mode, then determine the location information of the signature configuration item in the build configuration file; The configuration writing interface corresponding to the build context object is invoked so that the configuration writing interface removes the signature configuration reference field in the signature configuration item of the build configuration file based on the location information of the signature configuration item, while keeping the original build configuration file on the disk unchanged.

[0018] As one possible implementation, the generation module is specifically used for: The build process is executed based on the updated build context object to generate the unsigned target application package.

[0019] As one possible implementation, the generation module is further configured to: The script invokes a signing tool, which is then used to independently sign the unsigned target application package.

[0020] As one possible implementation, the signature configuration module is specifically used for: If the target build mode is release mode, then determine the location information of the signature configuration item in the build configuration file; Obtain the certificate materials and call the configuration writing interface corresponding to the build context object, so that the configuration writing interface adds the certificate materials to the signature configuration item based on the location information of the signature configuration item, while keeping the original build configuration file on the disk unchanged.

[0021] Thirdly, embodiments of this application provide an electronic device, including: a processor, a storage medium, and a bus. The storage medium stores machine-readable instructions executable by the processor. When the electronic device is running, the processor communicates with the storage medium via the bus, and the processor executes the machine-readable instructions to perform the steps of the application package generation method as described in any of the first aspects above.

[0022] Fourthly, embodiments of this application provide a computer-readable storage medium storing a computer program, which, when executed by a processor, performs the steps of the application package generation method as described in any of the first aspects above.

[0023] According to the application package generation method, electronic device, and computer-readable storage medium of this application embodiment, a build plugin mounted on the build root node is loaded and run, and a build context object in memory is obtained through a callback function mounted on the build root node. The build root node is the build root node in the target project corresponding to the target application package to be generated. When the build plugin runs, it reads the build configuration file in memory through the build context object, dynamically modifies the signature configuration items in the build configuration file according to the current development stage of the target project, updates the build context object based on the modified build configuration file, and executes the build process based on the updated build context object to generate the target application package. According to the embodiments of this application, by loading and running the build plugin mounted on the build root node, the build context object in memory is directly obtained using a callback function. Thus, when the build plugin runs, it reads the build configuration file in memory based on the build context object, dynamically modifies the signature configuration items in the build configuration file according to the current development stage, writes the modifications back to the context object, and executes the build process based on the updated context object to generate the target application package. Based on this, the dynamic modification of the signature configuration is completed entirely in memory, without requiring developers to manually modify the original configuration file on the disk. This fundamentally eliminates the risk of omissions or errors caused by manual operations. At the same time, since the original build configuration file on the disk itself remains unchanged, the differences in the local environments of different developers will not cause frequent conflicts in file content, thus significantly improving the efficiency of application package generation. Attached Figure Description

[0024] To more clearly illustrate the technical solutions of the embodiments of this application, the accompanying drawings used in the embodiments will be briefly introduced below. It should be understood that the following drawings only show some embodiments of this application and should not be regarded as a limitation of the scope. For those skilled in the art, other related drawings can be obtained based on these drawings without creative effort.

[0025] Figure 1 A flowchart illustrating an application package generation method provided in an embodiment of this application is shown; Figure 2 A flowchart illustrating a method for customizing plugin creation according to an embodiment of this application is shown. Figure 3 A flowchart illustrating a signature configuration modification method provided in an embodiment of this application is shown; Figure 4 This paper shows a schematic diagram of the structure of an application package generation device provided in an embodiment of this application; Figure 5 A schematic diagram of the structure of an electronic device provided in an embodiment of this application is shown. Detailed Implementation

[0026] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. It should be understood that the accompanying drawings in this application are for illustrative and descriptive purposes only and are not intended to limit the scope of protection of this application. Furthermore, it should be understood that the schematic drawings are not drawn to scale. The flowcharts used in this application illustrate operations implemented according to some embodiments of this application. It should be understood that the operations in the flowcharts may not be implemented in sequence, and steps without logical contextual relationships may be reversed or implemented simultaneously. In addition, those skilled in the art, guided by the content of this application, may add one or more other operations to the flowcharts, or remove one or more operations from the flowcharts.

[0027] Furthermore, the described embodiments are merely some, not all, of the embodiments of this application. The components of the embodiments of this application described and illustrated herein can typically be arranged and designed in various different configurations. Therefore, the following detailed description of the embodiments of this application provided in the accompanying drawings is not intended to limit the scope of the claimed application, but merely to illustrate selected embodiments of the application. All other embodiments obtained by those skilled in the art based on the embodiments of this application without inventive effort are within the scope of protection of this application.

[0028] It should be noted that the term "comprising" will be used in the embodiments of this application to indicate the presence of the features declared thereafter, but does not exclude the addition of other features.

[0029] During application development, such as the actual development of HarmonyOS applications, the following problems may be encountered: (1) Troublesome switching between multiple environments: The environments involved in multiple development stages are different, and each time the environment is switched, the build-profile.json5 configuration file needs to be manually changed, which is easy to miss or make mistakes. (2) Difficulty in adapting to Continuous Integration (CI) and Continuous Delivery / Deployment (CD): Jenkins scripts cannot automatically select a signature strategy based on build requirements during automatic builds, requiring an additional signature logic to be written within the Jenkins scripts, separating the build and signing processes into two steps. Jenkins is currently one of the most widely used open-source CI / CD automation tools in the industry, providing a visual operating platform to help developers automate various tasks in the CI / CD process; (3) There are security risks: the certificate path, keystore password and other signature materials are written in plain text in the build-profile.json5 configuration file and build script, and anyone who can access the project can obtain the signature materials; (4) Highly invasive: To adjust the signing behavior, you must directly modify the build-profile.json5 configuration file or the build script. Differences in the local environments of different developers can lead to frequent conflicts in the configuration files.

[0030] Based on the problems existing in the prior art, there is an urgent need in practical engineering projects for a solution that can automatically switch signature configurations and generate application packages based on the build environment without modifying the original build configuration files and project code. To address this, this application provides a method for dynamically modifying application signature configurations and generating application packages based on a plug-in mechanism. A custom build plugin is injected into the Hvigor build lifecycle. Hvigor is the official automated build system provided by HarmonyOS for application development, serving as the core underlying engine for the entire HarmonyOS application compilation, packaging, signing, and release process. The build plugin can automatically modify the signature configuration according to the current build environment at runtime. Development, debugging, and CI / CD packaging no longer require manual switching of signature parameters. Signature materials are extracted from the project code and uniformly passed in from an external source, significantly improving the automated build capability and generation efficiency of application packages.

[0031] Figure 1 This diagram illustrates a flowchart of an application package generation method provided in an embodiment of this application. The execution entity of this method is the Hvigor build system. (Refer to...) Figure 1 As shown, the method specifically includes the following steps: S101. Load and run the build plugin mounted on the build root node, and obtain the build context object in memory through the callback function mounted on the build root node.

[0032] The root node is the root node in the target project corresponding to the target application package to be generated.

[0033] Optionally, when the Hvigor build system initializes and loads the build root node of the target project corresponding to the target application package to be generated, the Hvigor build system automatically retrieves and runs the build plugins pre-mounted on the build root node. During the execution of the build plugins, the Hvigor build system triggers the lifecycle callback functions mounted on the build root node. After the configuration evaluation of the build root node is completed, it accurately captures and obtains the build context object currently in memory, thereby providing the basis for subsequent dynamic reading of the build configuration file in memory and modification of the signature configuration items in the build configuration file.

[0034] S102. When the build plugin is running, it reads the build configuration file in memory through the build context object, dynamically modifies the signature configuration items in the build configuration file according to the current development stage of the target project, and updates the build context object based on the modified build configuration file.

[0035] Optionally, the file structure for building the configuration file is as follows: { "app": { "products": [ { "name": "default", "signingConfig": "default", "compatibleSdkVersion": "5.0.3(15)", "runtimeOS": "HarmonyOS" } ], "signingConfigs": [ { "name": "default", "type": "HarmonyOS", "material": { "storeFile": ".. / config / certificate / **.p12", "storePassword": "00000019...", "keyAlias": "****", "keyPassword": "00000019...", "signAlg": "SHA256withECDSA", "profile": ".. / config / certificate / *Test.p7b", "certpath": ".. / config / certificate / *Test.cer" } } ] } } For example, the signature configuration items in the build configuration file mainly include the "products" and "signingConfigs" objects shown in the file structure of the build configuration file. Other field objects in the build configuration file remain intact and are not processed. It should be noted that the build context object reads the build configuration file from memory, and subsequent modifications to the signature configuration items also apply to the build configuration file in memory, not the original build configuration file on disk. Furthermore, since different development stages correspond to different environment parameters, when dynamically modifying the signature configuration items in the build configuration file in memory, the target build mode adapted to the current development stage can be determined based on the environment parameters of the target project's current development stage. Then, a signature configuration modification strategy adapted to this target build mode can be used to dynamically modify the signature configuration items in the build configuration file. The current development stage can be different, such as debugging, testing, and official release.

[0036] Furthermore, after dynamically modifying the signature configuration items in the build configuration file, the changes need to be written back to the build context object to obtain the updated build context object. It is worth noting that since this application only modifies the configuration object in memory and does not modify the original build configuration file on disk, it achieves non-intrusive signature configuration modification overwriting.

[0037] S103. Execute the build process based on the updated build context object to generate the target application package.

[0038] Optionally, the Hvigor build system executes a standard build process according to the configuration in the updated build context object to generate the target application package. Specifically, the build process includes resource compilation, ArkTS compilation, signing (optional), and outputting the target application package. ArkTS is a high-level programming language for HarmonyOS application development.

[0039] Optionally, in the embodiments of this application, the target build mode includes debug mode and release mode. Different build modes correspond to different signature configuration modification strategies. The main difference lies in the signature stage in the build process. For example, debug mode generates an unsigned HAP package, while release mode generates a signed HAP package.

[0040] Based on this, the application package generation method according to the embodiments of this application loads and runs a build plugin mounted on the build root node, and directly obtains the build context object in memory using a callback function. Then, during the build plugin runtime, it reads the build configuration file in memory based on the build context object, dynamically modifies the signature configuration items in the build configuration file according to the current development stage, and then writes the modifications back to the context object. Based on the updated context object, the build process is executed to generate the target application package. Therefore, the dynamic modification of the signature configuration is completed entirely in memory, eliminating the need for developers to manually modify the original configuration file on disk. This fundamentally eliminates the risk of missed or incorrect modifications caused by manual operation. Furthermore, since the original build configuration file on disk remains unchanged, differences in the local environments of different developers do not cause frequent conflicts in file content, thus significantly improving the efficiency of application package generation.

[0041] Figure 2 This illustration shows a flowchart of a method for customizing plugin creation according to an embodiment of this application. (Refer to...) Figure 2 As shown, before loading and running the build plugins mounted on the build root node, the method also includes: S201. Create a build plugin, generate a corresponding plugin identifier for the build plugin, and add the build plugin to the plugin registration array.

[0042] Optionally, developers can customize plugins according to the functions to be implemented. For example, in this embodiment of the application, in order to modify the signature configuration and improve the building capability of the application package, developers can create custom build plugins. For example, in the main project build entry file Main / hvigorfile.ts of the target project, a build plugin with the HvigorPlugin interface can be created, and a corresponding plugin identifier pluginId can be generated for the created build plugin. The build plugin can then be added to the plugin registration array plugins.

[0043] Optionally, the plugins registration array is used to store build plugins. The created build plugin contains a plugin identifier (pluginId) and a specific implementation method of the build plugin, denoted as the apply method. When adding a build plugin to the plugins registration array, the plugin identifier (pluginId) and the apply method of the build plugin can be associated and stored in a storage location in the plugins registration array.

[0044] S202. Call the registration interface of the root node and attach the callback function to the root node.

[0045] Optionally, in the apply method, the registration interface getNode(_filename) for building the root node is called to obtain the root node instance for building the root node, and the callback function afterNodeEvaluate() written by the developer is written as a parameter into the root node instance to successfully attach the callback function to the generation cycle of building the root node.

[0046] Accordingly, the above steps load and run the build plugin mounted on the build root node, specifically including: in response to the completion of the configuration evaluation of the build root node, retrieving the build plugin from the plugin registration array based on the plugin identifier of the build plugin, and loading and running the build plugin.

[0047] For example, since the plugins registry array can store plugin identifiers and apply methods for multiple plugins, in practical applications, a plugin can be retrieved from the plugins registry array based on the plugin identifier of the plugin to be loaded and run, and then the retrieved plugin can be loaded and run. It should be noted that the retrieval of the build plugin and the callback are triggered before the configuration evaluation of the build root node is completed and before actual compilation begins. When the configuration evaluation of the build root node is completed, the callback is triggered, and the build plugin is retrieved from the plugins registry array based on the plugin identifier pluginId, and then the specific logic defined in the apply method of the build plugin is executed.

[0048] Based on this, in this embodiment of the application, developers can customize the build plugin according to specific needs and generate a unique plugin identifier, register the build plugin to the plugin registration array, and then automatically trigger the plugin execution after the build root node configuration evaluation is completed by attaching a callback function, thereby realizing dynamic configuration modification of the build process without modifying the core code of the build process.

[0049] Figure 3 A flowchart illustrating a signature configuration modification method provided in an embodiment of this application is shown. (Refer to...) Figure 3 As shown, the above steps dynamically modify the signature configuration items in the build configuration file according to the current development stage of the target project. Specifically, the steps include the following: S301. Obtain the environmental parameters of the current development stage of the target project, and determine the target build mode based on the environmental parameters.

[0050] Optionally, during the build plugin's execution, the external environment parameter `config` of the target project's current development stage, injected via the CI / CD pipeline or command line, is read through `process.env`. `process.env` is a crucial property representing the global object of the current development stage; essentially, it's a key-value mapping object containing the inherited environment parameter `config`, which is represented as a string. After obtaining the environment parameter `config`, string matching can be performed. If the environment parameter `config` contains the string "release", the target build mode is determined to be release mode (release mode); if the environment parameter `config` contains the string "debug", the target build mode is determined to be debug mode (debug mode).

[0051] It's worth noting that the build plugin reads environment variables at runtime and determines whether the target build mode for the current development stage is debug or release mode, then executes the corresponding signing strategy for each build mode. In this way, the CI / CD pipeline only handles passing in environment variables; the build process requires no manual intervention.

[0052] S302. Dynamically modify the signature configuration items in the build configuration file according to the target build mode.

[0053] Optionally, if the target build mode is debug mode, the location information of the signature configuration item in the build configuration file is determined; the configuration writing interface corresponding to the build context object is called so that the configuration writing interface removes the signature configuration reference field in the signature configuration item of the build configuration file based on the location information of the signature configuration item, and keeps the original build configuration file on the disk unchanged.

[0054] For example, when the target build mode is determined to be debug mode, the location information of the signature configuration item in the build configuration file in memory is parsed and located, and the configuration writing interface provided by the build context object is called. The configuration writing interface locates the signature configuration item in the build configuration file according to the location information of the signature configuration item, and removes the signature configuration reference field "signingConfigs" in the signature configuration item. Referring to the file structure of the build configuration file provided above, that is, the contents contained in the "signingConfigs" field are removed.

[0055] It is worth noting that since the above removal operation only applies to the build configuration file in memory and does not trigger any modification to the signature configuration items in the original build configuration file stored on disk, a non-intrusive signature configuration overwrite is achieved.

[0056] Accordingly, step S103 above executes the build process based on the updated build context object to generate the target application package, including: executing the build process based on the updated build context object to generate an unsigned target application package.

[0057] For example, in debug mode, the signing stage is skipped when building the target application package, resulting in an unsigned application package being generated directly. In other words, by removing the "signingConfigs" field reference from the "products" configuration in debug mode, the Hvigor build system automatically skips the signing stage and directly generates an unsigned target application package. Local development and debugging no longer rely on signing certificates. This not only eliminates the barrier of certificate configuration but also accelerates development iteration, enabling rapid construction of HAP packages without signatures.

[0058] Furthermore, after generating an unsigned target application package by executing the build process based on the updated build context object, the method also includes: calling a signing tool by invoking a script, and using the signing tool to independently sign the unsigned target application package.

[0059] For example, since the target application package built in debug mode is unsigned, it needs to be independently signed after the target application package is generated to generate a debug-signed package for distribution testing.

[0060] Specifically, the signing tool hap-sign-tool.jar is invoked by calling a script such as a Jenkins script, and the signing tool hap-sign-tool.jar is used to independently sign the target application package built in debug mode, generating a debug-signed package for distribution and testing.

[0061] Optionally, if the target build mode is release mode, the location information of the signing configuration item in the build configuration file is determined; the certificate materials are obtained, and the configuration writing interface corresponding to the build context object is called so that the configuration writing interface adds the certificate materials to the signing configuration item based on the location information of the signing configuration item.

[0062] For example, when the target build mode is determined to be release mode, the location information of the signature configuration item in the build configuration file in memory is parsed and located, and the configuration writing interface provided by the build context object is called. The configuration writing interface locates the signature configuration item in the build configuration file according to the location information of the signature configuration item, and reads the certificate material containing sensitive signature materials such as certificate path certpath, keystore file storeFile, description file profile, and key alias keyAlias ​​from the external data file data.json. The certificate material is added to the signature configuration item. Referring to the file structure of the build configuration file provided above, that is, the certificate material is added to the "material" object. Thus, the signature configuration is modified dynamically while keeping the original build configuration file on the disk unchanged.

[0063] It is worth noting that in this embodiment, sensitive signing materials such as certificate path certpath, keystore file storeFile, profile file profile, and key alias keyAlias ​​are not hardcoded into the project code. Instead, the plugin reads them from the external data file data.json at runtime and dynamically injects them into the "material" object of "signingConfigs". The project itself does not contain the signing path information, thus decoupling the signing materials from the project.

[0064] Furthermore, in this embodiment, regardless of whether it is in debug mode or release mode, the dynamic modification of the signature configuration only assigns values ​​to the "products" and "signingConfigs" fields in the build configuration file build-profile.json5 in memory, without replacing the entire build configuration file. Other fields in the file structure of the build configuration file, such as "modules", "buildModeSet", and "buildOption", maintain their original integrity and are not processed.

[0065] Based on the above, this application embodiment uses the Hvigor plugin mechanism to add custom build plugins in the plugins registration array in an append manner. This ensures that the signature configuration does not modify the original build-profile.json5 configuration file on the disk, nor does it modify the built-in build script of Hvigor. Instead, the configuration modification logic is injected through the build plugin, thereby realizing dynamic modification of the application signature configuration based on the plugin mechanism.

[0066] Based on the same inventive concept, this application also provides an application package generation device corresponding to the application package generation method. Since the principle of the application package generation device in this application is similar to that of the application package generation method described above, the implementation of the application package generation device can refer to the implementation of the application package generation method, and the repeated parts will not be described again.

[0067] Reference Figure 4 The diagram shown is a structural schematic of an application package generation device provided in an embodiment of this application. The application package generation device 400 includes: a loading module 401, a signature configuration module 402, and a generation module 403, wherein: Loading module 401 is used to load and run the build plugin mounted on the build root node, and obtain the build context object in memory through the callback function mounted on the build root node, wherein the build root node is the build root node in the target project corresponding to the target application package to be generated; The signature configuration module 402 is used to read the build configuration file in memory through the build context object when the build plugin is running, dynamically modify the signature configuration items in the build configuration file according to the current development stage of the target project, and update the build context object based on the modified build configuration file. The generation module 403 is used to execute the build process based on the updated build context object to generate the target application package.

[0068] Based on this, the application package generation apparatus according to the embodiments of this application loads and runs the build plugin mounted on the build root node, and directly obtains the build context object in memory using a callback function. Thus, during the runtime of the build plugin, it reads the build configuration file in memory based on the build context object, dynamically modifies the signature configuration items in the build configuration file according to the current development stage, and then writes the modifications back to the context object. Based on the updated context object, it executes the build process to generate the target application package. Therefore, the dynamic modification of the signature configuration is completed entirely in memory, eliminating the need for developers to manually modify the original configuration file on disk. This fundamentally eliminates the risk of missed or incorrect modifications caused by manual operation. Furthermore, since the original build configuration file on disk remains unchanged, differences in the local environments of different developers do not cause frequent conflicts in file content, thereby significantly improving the efficiency of application package generation.

[0069] In one possible implementation, the loading module 401 is further configured to: Create a build plugin, generate a corresponding plugin identifier for the build plugin, and add the build plugin to the plugin registration array; Call the registration interface for building the root node and attach the callback function to the root node.

[0070] In one possible implementation, the loading module 401 is specifically used for: In response to the completion of configuration evaluation of the build root node, the build plugin is retrieved from the plugin registry array based on the plugin identifier of the build plugin, and the build plugin is loaded and run.

[0071] In one possible implementation, the signature configuration module 402 described above is specifically used for: Obtain the environmental parameters of the current development stage of the target project, and determine the target build mode based on the environmental parameters; The signature configuration items in the build configuration file are dynamically modified according to the target build mode.

[0072] In one possible implementation, the signature configuration module 402 described above is specifically used for: If the target build mode is debug mode, then determine the location information of the signature configuration item in the build configuration file; Call the configuration write interface corresponding to the build context object so that the configuration write interface removes the signature configuration reference field in the signature configuration item of the build configuration file based on the location information of the signature configuration item, and keeps the original build configuration file on the disk unchanged.

[0073] In one possible implementation, the above-mentioned generation module 403 is specifically used for: The build process is executed based on the updated build context object, generating an unsigned target application package.

[0074] In one possible implementation, the generation module 403 is further configured to: The script invokes the signing tool, which then independently signs the unsigned target application package.

[0075] In one possible implementation, the signature configuration module 402 described above is specifically used for: If the target build mode is release mode, then determine the location information of the signature configuration item in the build configuration file; Obtain the certificate materials and call the configuration write interface corresponding to the build context object so that the configuration write interface adds the certificate materials to the signature configuration item based on the location information of the signature configuration item, while keeping the original build configuration file on the disk unchanged.

[0076] The processing flow of each module in the device and the interaction flow between each module can be referred to the relevant descriptions in the above method embodiments, and will not be detailed here.

[0077] This application also provides an electronic device 500, such as... Figure 5The diagram shown is a structural schematic of an electronic device 500 provided in an embodiment of this application, including: a processor 501, a memory 502, and optionally, a bus 503. The memory 502 stores machine-readable instructions executable by the processor 501. When the electronic device 500 is running, the processor 501 and the memory 502 communicate via the bus 503. When the machine-readable instructions are executed by the processor 501, the steps of the application package generation method described in any of the preceding claims are performed.

[0078] This application also provides a computer-readable storage medium storing a computer program that, when executed by a processor, performs the steps of the application package generation method described in any of the preceding claims.

[0079] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the specific working processes of the systems and devices described above can be referred to the corresponding processes in the method embodiments, and will not be repeated here. In the several embodiments provided in this application, it should be understood that the disclosed systems, devices, and methods can be implemented in other ways. The device embodiments described above are merely illustrative. For example, the division of modules is only a logical functional division, and in actual implementation, there may be other division methods. Furthermore, multiple modules or components can be combined or integrated into another system, or some features can be ignored or not executed. Another point is that the displayed or discussed mutual coupling or direct coupling or communication connection can be through some communication interfaces; the indirect coupling or communication connection of devices or modules can be electrical, mechanical, or other forms.

[0080] Furthermore, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. If the functions are implemented as software functional units and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this invention, or the part that contributes to the prior art, or a part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this invention. The aforementioned storage medium includes: USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, optical disks, and other media capable of storing program code.

[0081] The above are merely specific embodiments of this application, but the scope of protection of this application is not limited thereto. Any changes or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application.

Claims

1. A method for generating an application package, characterized in that, include: Load and run the build plugin mounted on the build root node, and obtain the build context object in memory through the callback function mounted on the build root node, wherein the build root node is the build root node in the target project corresponding to the target application package to be generated; When the build plugin runs, it reads the build configuration file in memory through the build context object, dynamically modifies the signature configuration items in the build configuration file according to the current development stage of the target project, and updates the build context object based on the modified build configuration file. The build process is executed based on the updated build context object to generate the target application package.

2. The method according to claim 1, characterized in that, Before loading and running the build plugin mounted on the build root node, the process also includes: Create the build plugin, generate a corresponding plugin identifier for the build plugin, and add the build plugin to the plugin registration array; Call the registration interface of the root node to attach the callback function to the root node.

3. The method according to claim 2, characterized in that, The loading and running of the build plugin mounted on the build root node includes: In response to the completion of the configuration evaluation of the root node, the build plugin is retrieved from the plugin registration array based on the plugin identifier of the build plugin, and the build plugin is loaded and run.

4. The method according to claim 1, characterized in that, The step of dynamically modifying the signature configuration item in the build configuration file according to the current development stage of the target project includes: Obtain the environmental parameters of the current development stage of the target project, and determine the target construction mode based on the environmental parameters; The signature configuration item in the build configuration file is dynamically modified according to the target build pattern.

5. The method according to claim 4, characterized in that, The step of dynamically modifying the signature configuration item in the build configuration file according to the target build mode includes: If the target build mode is debug mode, then determine the location information of the signature configuration item in the build configuration file; The configuration writing interface corresponding to the build context object is invoked so that the configuration writing interface removes the signature configuration reference field in the signature configuration item of the build configuration file based on the location information of the signature configuration item, while keeping the original build configuration file on the disk unchanged.

6. The method according to claim 5, characterized in that, The process of executing the build flow based on the updated build context object to generate the target application package includes: The build process is executed based on the updated build context object to generate the unsigned target application package.

7. The method according to claim 6, characterized in that, After the build process is executed based on the updated build context object to generate the unsigned target application package, the process further includes: The script invokes a signing tool, which is then used to independently sign the unsigned target application package.

8. The method according to claim 4, characterized in that, The step of dynamically modifying the signature configuration item in the build configuration file according to the target build mode includes: If the target build mode is release mode, then determine the location information of the signature configuration item in the build configuration file; Obtain the certificate materials and call the configuration writing interface corresponding to the build context object, so that the configuration writing interface adds the certificate materials to the signature configuration item based on the location information of the signature configuration item, while keeping the original build configuration file on the disk unchanged.

9. An electronic device, characterized in that, include: A processor and a memory, the memory storing machine-readable instructions executable by the processor, which, when the electronic device is running, are executed by the processor to perform the steps of the application package generation method as described in any one of claims 1 to 8.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program that, when executed by a processor, performs the steps of the application package generation method as described in any one of claims 1 to 8.

Images