A method and device for dynamically generating a harmony application channel package

Abstract

The application provides a dynamic generation method and device for a Hongmeng application channel package, and relates to the technical field of computer software.The method comprises the following steps: receiving a user-input construction parameter; mapping the construction parameter into a command line parameter format to perform a verification process; when the verification result meets a preset specification, dynamically modifying an application configuration file, a module configuration file and a construction configuration file based on the construction parameter to complete real-time adjustment of application information, module attributes and construction targets, and outputting a configuration result; converting the configuration result into a construction task to generate a HAP package with a time stamp and a channel identifier; and outputting a construction result including an installation package path and an upload state according to user configuration. The application can solve the defect of low Hongmeng application channel package generation efficiency caused by the need to rely on fixed configuration or manual repeated modification in the prior art.

Description

Technical Field

[0001] This invention relates to the technical field of computer software, and specifically to a method and apparatus for dynamically generating HarmonyOS application channel packages. Background Technology

[0002] The process of generating HarmonyOS application channel packages involves merging the application configuration files and module configuration files provided by the developers step by step according to an atomic writing sequence to obtain the corresponding build configuration results. These configuration results are then transformed into build tasks. During the compilation process, channel identifiers and timestamps are added to the generated application installation packages to form HAP packages for specific channels. Finally, the HAP packages with channel identifiers are output as build results containing the installation package path and upload status, enabling application distribution and management for different channels.

[0003] Existing technologies typically rely on fixed configuration files or manual, repetitive modifications during the generation of application channel packages. Whenever a new channel is added or channel parameters are updated, the configuration must be modified item by item and recompiled manually. This process is not only cumbersome but also prone to introducing errors, resulting in a significant reduction in the efficiency of channel package generation. It also limits the application's ability to quickly distribute and iterate in a multi-channel environment.

[0004] Therefore, a method is needed to address the shortcomings of existing technologies that rely on fixed configurations or manual, repetitive modifications, resulting in low efficiency in generating HarmonyOS application channel packages. Summary of the Invention

[0005] This invention provides a method and apparatus for dynamically generating HarmonyOS application channel packages, which can solve the problem of low efficiency in generating HarmonyOS application channel packages due to the need for fixed configurations or repeated manual modifications in the prior art.

[0006] A first aspect of the present invention provides a method for dynamically generating HarmonyOS application channel packages, the method comprising: Receive build parameters input by the user; The construction parameters are mapped to command-line argument format to perform the verification process; When the verification result meets the preset specifications, the application configuration file, module configuration file and construction configuration file are dynamically modified based on the construction parameters to complete the real-time adjustment of application information, module attributes and construction goals, and output the configuration result; The configuration results are transformed into a build task to generate a HAP package with a timestamp and channel identifier; The HAP package outputs a build result, including the installation package path and upload status, based on the user configuration.

[0007] Based on the above technical solutions, preferably, mapping the construction parameters to command-line parameter format specifically includes: Based on the preset parameter pattern library, the construction parameters are standardized by converting the channel type, deep link host address, whether to remove a specific software development kit, version number, version name, icon resource path and launch image resource path into a standard key-value pair set, and marking conflict constraint pointers in the standard key-value pair set. The standard key-value pair set is converted into command line fragments item by item according to the command line rendering rule table. The command line rendering rule table defines the correspondence between standard keys and command line option names and the mapping relationship of the value encoder. The value encoder is used to perform path escaping, special character safe encoding and fixed-length mapping of enumeration values. After generating the command line fragment, the fragments are concatenated using the stable sequence number as the sorting key and a connector is injected to form a command line parameter string. If the conflict constraint pointer is triggered during the rendering process, a rollback strategy or an alternative strategy is executed according to the conflict priority matrix and the standard key-value pair set is corrected.

[0008] Based on the above technical solutions, preferably, after mapping the construction parameters to command-line parameter format, the method further includes: Based on the standard key-value pair set constructed for the aforementioned construction parameters, a candidate set of command-line arguments is generated; The command line parameter candidate set is sequentially subjected to syntax and format verification, integrity verification, and value range and consistency verification. The syntax and format verification is used to detect whether the path format, Boolean value format, enumeration value and deep link host address pattern meet the preset specifications. The integrity verification is used to detect missing required fields and mutual exclusion conflicts. The value range and consistency verification is used to detect the version number semantic monotonicity, resource path reachability and channel type and whether to remove the dependency constraints of a specific software development kit combination. The set of standard key-value pairs that have passed the verification is converted into command line fragments by rendering the rule table through the command line. Deterministic sorting and concatenation are performed with stable sequence numbers. When a conflict constraint is triggered, a rollback strategy or replacement strategy is executed according to the conflict priority matrix and the corrected set of standard key-value pairs is written back.

[0009] Based on the above technical solutions, preferably, when the verification result meets the preset specifications, the application configuration file, module configuration file, and construction configuration file are dynamically modified based on the construction parameters to complete the real-time adjustment of application information, module attributes, and construction goals, and the configuration result is output, specifically including: The application configuration file, the module configuration file, and the build configuration file are converted into an abstract syntax tree representation by a configuration parser, and key space normalization, default value completion, and initial screening of key conflicts are completed in the semantic constraint engine to obtain a candidate node set. A change plan is generated based on the construction parameters. The change plan is input into a differential patch generator to generate a minimum change set. The minimum change set is used in the transaction controller to establish an atomic write sequence in the form of a cross-file consistency barrier. Dynamic modifications are performed on the application configuration file, the module configuration file, and the build configuration file in sequence according to the atomic write sequence. The dynamic modification of the application configuration file generates an application layer change snapshot, the dynamic modification of the module configuration file generates a module layer change snapshot, and the dynamic modification of the build configuration file generates a build layer change snapshot. Based on the application layer change snapshot, the module layer change snapshot, and the build layer change snapshot, a consistency barrier check is performed. If the check passes, the transaction is committed and a configuration result containing the application configuration file version number, the module configuration file dependency fingerprint, and the build configuration file target summary is generated. If the check fails, a cross-file rollback is performed and a failure reason report is output.

[0010] Based on the above technical solutions, preferably, the step of dynamically modifying the application configuration file, the module configuration file, and the build configuration file sequentially according to the atomic writing sequence specifically includes: When dynamically modifying the application configuration file on the application side, locate the package name key, version number key, and icon path key, and generate an application layer change snapshot containing the modification location, old value, new value, and timestamp. At the same time, output the dependency export table in the application layer change snapshot to indicate the key references required by the module side. When the module configuration file is dynamically modified on the module side, the consistency comparison and correction of the deep link host address key, startup graph key, permission set key and dependency set key are performed based on the dependency export table of the application layer change snapshot. A module layer change snapshot containing key-level modification trajectory, set difference details and resource reachability verification results is generated, and the build constraint export table is output in the module layer change snapshot. When the build configuration file is dynamically modified on the build side, the source code directory key, resource directory key and compilation target key are mapped and supplemented based on the build constraint export table of the module layer change snapshot, and a build layer change snapshot containing path mapping table, target mapping table and dependency graph difference is generated.

[0011] Based on the above technical solutions, preferably, the step of converting the configuration result into a build task to generate a HAP package with a timestamp and channel identifier specifically includes: After parsing the configuration results, a build plan is generated. The build plan is transformed into a job queue containing compilation jobs, resource processing jobs, manifest generation jobs, and signing jobs, and a prerequisite dependency and output artifact description are established for each job. Before executing the build, the toolchain version, platform target, and minimum compatibility level are checked, and the generated environment lock record is written into the build plan to ensure the consistency of the toolchain between the compilation job and the resource processing job. The business code and module code are compiled according to the source code directory mapping, generating intermediate objects and intermediate libraries. The resource processing job completes the packaging and organization of icon resources, startup image resources and localization resources according to the resource directory mapping. During the linking stage, they are merged into module-level binary and bound to resource indexes, and the module bundle to be injected into the manifest is output. Inject the application information and module attributes into the module bundle, generate a manifest to lock the version, and ensure that the permission set is consistent with the dependency graph fingerprint, and that the deep link host address is consistent with the package name policy; Generate a signature block and verification summary on the assembled product, and append the signature time record to the product; After signing, the channel identifier and timestamp are injected into the product naming template, and a HAP package with timestamp and channel identifier is generated. The product archiver then generates a product index and a build result object, which includes the installation package path, channel identifier, timestamp, and upload status.

[0012] Based on the above technical solutions, preferably, the step of outputting the HAP package with the installation package path and upload status according to user configuration specifically includes: After generating the HAP package, the artifact index and user configuration are parsed to form a distribution plan. The distribution plan is marked with the target repository identifier, authentication mode and upload concurrency. When executing the distribution plan, the HAP package is first subjected to integrity and duplication checks. The integrity check outputs a check summary, and the duplication check determines whether the channel identifier and timestamp naming conflict. If there is a conflict, an alternative naming template is generated according to the renaming strategy. After verification, an upload session token is generated according to the authentication mode configured by the user, and the HAP packet is pushed under the direct upload path or the fragment and aggregation receipt is pushed under the fragmented resume upload path. If the upload fails, the retry controller will execute backoff retry according to the retry policy and generate a failure status and failure reason after exceeding the limit. After receiving confirmation of upload, a callback action is triggered according to the callback strategy configured by the user, using the installation package path, channel identifier, timestamp, and access identifier as callback inputs, and recording the distribution log; After merging the distribution logs, confirmation receipts, and verification summaries, a build result object is generated. The build result object includes the installation package path, channel identifier, timestamp, upload status, and log location. The build result object is then returned to the upper-level process as the final output.

[0013] In a second aspect of the present invention, a HarmonyOS application channel package dynamic generation apparatus is provided. The apparatus is used to execute a HarmonyOS application channel package dynamic generation method as described in any of the above embodiments. The apparatus includes an acquisition module, a processing module, and an output module, wherein: The acquisition module is used to receive the construction parameters input by the user; The processing module is used to map the construction parameters into command-line parameter format in order to perform a verification process; The processing module is used to dynamically modify the application configuration file, module configuration file and construction configuration file based on the construction parameters when the verification result meets the preset specifications, so as to complete the real-time adjustment of application information, module attributes and construction target, and output the configuration result. The processing module is used to convert the configuration result into a build task and generate a HAP package with a timestamp and channel identifier; The output module is used to output the build result of the HAP package, including the installation package path and upload status, according to the user configuration.

[0014] In a third aspect of the invention, an electronic device is provided, including a processor, a memory, a user interface, and a network interface, wherein the memory is used to store instructions, the user interface and the network interface are both used to communicate with other devices, and the processor is used to execute the instructions stored in the memory to cause the electronic device to perform the method as described in any of the preceding embodiments.

[0015] In a fourth aspect, the present invention provides a computer-readable storage medium storing instructions that, when executed, perform the method as described in any of the preceding claims.

[0016] In summary, one or more technical solutions provided in the embodiments of the present invention have at least the following technical effects or advantages: 1. This invention transforms repetitive operations that originally relied on fixed configuration files or manual item-by-item modification into visualized and automated processing by standardizing the collection of construction parameters, verifying command-line parameters, dynamically modifying configuration files, automatically generating construction tasks, and distributing results in a closed-loop process. This allows channel identifiers and timestamps to be automatically injected during the compilation process, and configuration results to be instantly converted into executable construction tasks and output traceable construction results. This significantly reduces the probability of manual intervention and errors, enabling the rapid generation of multi-channel application installation packages and effectively improving the efficiency of HarmonyOS application channel package generation.

[0017] 2. By combining the parameter pattern library with the command line rendering rule table, complex and diverse build parameters are uniformly converted into standardized command line expressions. In the conversion process, conflict constraint pointers and conflict priority matrices are introduced to ensure the correctness and consistency of parameters before they are passed to the build tool, thereby significantly reducing the error rate when manually concatenating command lines.

[0018] 3. By generating a candidate set of command-line arguments and performing syntax and format checks, integrity checks, and value range and consistency checks, we ensure that the input parameters are not only legal in form, but also logically complete and consistent with the global context. Furthermore, we execute command-line rendering only after the checks pass, which makes the build task more stable and traceable, and effectively avoids build failures caused by non-compliant parameters.

[0019] 4. Through the collaborative processing of abstract syntax tree representation, semantic constraint engine and differential patch generator, the build parameters are transformed into a controllable minimum change set, and the application configuration file, module configuration file and build configuration file are dynamically modified under the cross-file consistency barrier of the transaction controller. This ensures the atomicity of modification operations and cross-file consistency, thereby outputting traceable and reliable configuration results.

[0020] 5. By generating application-layer change snapshots, module-layer change snapshots, and build-layer change snapshots step by step, the configuration modification process can be tracked and exported in layers. This allows module configurations and build configurations to directly inherit the changes in application configurations. Furthermore, cross-layer constraints are passed through dependency export tables and build constraint export tables, ensuring that the final configuration remains consistent across layers.

[0021] 6. By implementing job queuing for the build plan, environment locking, parallel processing of source code and resources, manifest generation and signing, and automatic injection of channel identifiers and timestamps, the entire process of automated build can be achieved while ensuring toolchain consistency. The final generated HAP package has a unique channel identifier and timestamp, which facilitates channel differentiation and version management, and improves build efficiency and reliability.

[0022] 7. By generating distribution plans, verifying the integrity and duplication of HAP packages, securely establishing upload sessions, automatically retrying upload failures, triggering callbacks and logging after successful uploads, the security, uniqueness, and traceability of application installation packages during the distribution process can be guaranteed. Furthermore, by constructing result objects to uniformly output upload status and log locations, it supports subsequent automated pipeline integration and channel management. Attached Figure Description

[0023] Figure 1 This is a flowchart illustrating a method for dynamically generating HarmonyOS application channel packages according to an embodiment of the present invention. Figure 2This is a schematic diagram of a HarmonyOS application channel package dynamic generation device disclosed in an embodiment of the present invention; Figure 3 This is a schematic diagram of the structure of an electronic device disclosed in an embodiment of the present invention.

[0024] Explanation of reference numerals in the attached drawings: 201, acquisition module; 202, processing module; 203, output module; 301, processor; 302, communication bus; 303, user interface; 304, network interface; 305, memory. Detailed Implementation

[0025] To enable those skilled in the art to better understand the technical solutions in this specification, the technical solutions in the embodiments of this specification will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments.

[0026] In the description of the embodiments of the present invention, words such as "for example" or "for instance" are used to indicate examples, illustrations, or explanations. Any embodiment or design described as "for example" or "for instance" in the embodiments of the present invention should not be construed as being more preferred or advantageous than other embodiments or designs. Rather, the use of words such as "for example" or "for instance" is intended to present the relevant concepts in a specific manner.

[0027] In the description of the embodiments of the present invention, the term "multiple" means two or more. For example, multiple systems means two or more systems, and multiple screen terminals means two or more screen terminals. Furthermore, the terms "first" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the indicated technical features. Thus, a feature defined with "first" or "second" may explicitly or implicitly include one or more of that feature. The terms "comprising," "including," "having," and variations thereof all mean "including but not limited to," unless otherwise specifically emphasized.

[0028] Existing technologies rely on fixed configuration files or repeated manual modifications during the generation of HarmonyOS application channel packages. When adding or updating channels, each item needs to be adjusted and recompiled, which is inefficient and error-prone, limiting rapid distribution and iteration in a multi-channel environment. To address this deficiency, this method merges the application configuration file and module configuration file provided by the developer step by step in an atomic writing sequence to obtain the build configuration result, which is then transformed into a build task and the channel identifier and timestamp are added during compilation. Finally, the application installation package with the channel identifier and its build result are output, thereby achieving efficient and manageable multi-channel application distribution.

[0029] This embodiment discloses a method for dynamically generating HarmonyOS application channel packages, referring to... Figure 1 This includes the following steps S110-S150: S110 receives the build parameters input by the user.

[0030] This invention discloses a method for dynamically generating HarmonyOS application channel packages, which is applied to a server. The server includes, but is not limited to, electronic devices such as mobile phones, tablets, wearable devices, and PCs (Personal Computers), and can also be a backend server running the HarmonyOS application channel package dynamic generation method. The server can be implemented using a standalone server or a server cluster composed of multiple servers.

[0031] After completing the interactive initialization in the graphical configuration interface, the input collector creates an input event queue and registers field constraints. The field constraints cover channel type, icon resource path, launch image resource path, deep link host address, whether to remove a specific software development kit, version number, version name, whether to enable debug logs, and whether to automatically upload. The input collector generates atomic input events for each type, selection, and drag-and-drop event and writes them to the input event queue. At the same time, it maintains a local image and timestamp for each field for subsequent consistency comparison and rollback.

[0032] After the input event queue stabilizes, the parameter parser performs parsing based on the parameter pattern library. The parameter pattern library provides the type, value range, and default value for each field. The parameter parser aggregates atomic input events into a standard key-value pair set, performs normalization on path-type fields, performs explicit solidification on boolean and enumeration fields, and fills in missing fields with default values ​​to form a preliminary standardized parameter package. The preliminary standardized parameter package includes source indication and change sequence number to ensure data traceability across components.

[0033] After obtaining the initial standardized parameter package, the validator performs the verification in the order of "syntax and format verification - integrity verification - value range and consistency verification". Syntax and format verification is used to detect the domain name pattern of path format, Boolean literals, enumerated legal values ​​and deep link host addresses. Integrity verification is used to detect whether required fields are missing and whether mutually exclusive fields coexist. Value range and consistency verification is used to detect the semantic monotonicity of version number, resource path reachability, channel type and whether the dependency constraints of a specific software development kit have been removed. The validator generates a verification alarm for each non-compliance and writes it back to the interface control to trigger on-site correction.

[0034] After the verification passes or the correction is completed, the conflict resolver solves the cross-field constraints. The cross-field constraints cover the consistency between the package name policy and the deep link host address, the consistency of the resolution hierarchy between the icon resource family and the launch image resource family, and the closure integrity between the permission set and the dependency set. The conflict resolver uses the priority matrix and the substitution policy table to minimize the modification, generates a conflict resolution list and updates the standard key-value pair set, ensuring that no manual intervention is required in the subsequent dynamic modification stage of the configuration file.

[0035] After the conflict resolution list is applied, the preview orchestrator generates a visual preview based on the standard key-value pair set. The preview orchestrator renders the combined effect of package name, version number, icon and launcher image, and simulates the list fragments of injected deep link host address, permission set and dependency set. The preview result and the changes are presented together. After the user confirms, a confirmation token is generated. If the user refuses, the preview orchestrator maps the changes back to the input collector to form a new round of input events, maintaining the convergence loop.

[0036] After the user confirms the token, the persistent buffer performs a signature on the standard key-value pair set. The signature includes the change sequence number, timestamp, and field digest hash. The persistent buffer writes to the session archive and outputs a standardized parameter package. The standardized parameter package is passed to the configuration file parsing and modification process as a single trusted input to drive subsequent dynamic modifications to the application configuration file, module configuration file, and build configuration file, and to maintain consistency and traceability in the build pipeline.

[0037] S120 maps the build parameters to command-line argument format to perform the verification process.

[0038] In one possible implementation, the build parameters are mapped to command-line parameter format, specifically including: normalizing the build parameters based on a preset parameter pattern library, converting channel type, deep link host address, whether to remove a specific software development kit, version number, version name, icon resource path, and launch image resource path into a standard key-value pair set, and marking conflict constraint pointers in the standard key-value pair set; converting the standard key-value pair set into command-line fragments item by item according to the command-line rendering rule table, the command-line rendering rule table defines the correspondence between standard keys and command-line option names and the mapping relationship of the value encoder, the value encoder is used to perform path escaping, special character security encoding, and fixed-length mapping of enumerated values; after generating the command-line fragments, the fragments are concatenated using a stable sequence number as the sorting key and a connector is injected to form a command-line parameter string; if a conflict constraint pointer is triggered during the rendering process, a fallback strategy or replacement strategy is executed according to the conflict priority matrix and the standard key-value pair set is corrected.

[0039] Specifically, in the parameter processing phase, the parameter pattern library maintains a standardized description of type, value range, default value, and constraint relationships using field names as indexes. The input is an atomic record stream that constructs the parameters, and the output is a set of standard key-value pairs. After parsing, the channel type is parsed into an enumerated standard key, the deep link host address into a string standard key, whether to remove a specific software development kit into a boolean standard key, the version number and version name into semantic version standard keys, and the icon resource path and launch image resource path into path standard keys. During type normalization, enumerated standard keys undergo valid value verification and are solidified into a unified enumeration identifier. Boolean standard keys consolidate diverse inputs, such as "yes / no" and "true / false," into binary literals. Path standard keys undergo normalization rules to unify the slash direction, perform relative path calculations, and clean up redundant separators. While generating the standard key-value pair set, conflict constraint pointers are written for keys involving cross-field dependencies. These pointers indicate associated keys and constraint types that may conflict, such as the dependency between channel type and whether to remove a specific SDK, the consistency between package name policy and deep link host address, and the resolution hierarchy consistency between icon resource path and launch image resource path. The standard key-value pair set, along with the conflict constraint pointers, serves as deterministic input for downstream command-line rendering.

[0040] During the command-line rendering phase, the command-line rendering rule table defines a mapping using a ternary relationship: "standard key—command-line option name—value encoder." The input is a set of standard key-value pairs, and the output is a set of command-line fragments. The value encoder provides composable encoding operators for different value types. The path escaping operator escapes or encloses spaces, backslashes, and quotation marks, ensuring the command-line parser reads the path literally. The special character security encoding operator encodes deep link host addresses and strings containing reserved characters using percent encoding or similar mechanisms to avoid semantic corruption caused by command-line tokenization. The enumeration value fixed-length mapping operator maps multi-language or multi-alias enumeration values ​​to a unified fixed-length identifier, ensuring stable representation of the same enumeration across different platforms and sessions. Each standard key finds its corresponding command-line option name through the rule table, and the value processed by the value encoder is concatenated into a command-line fragment consisting of "option name + separator + encoded value." The command-line fragment includes a source key identifier and a local hash to support subsequent tracing and deduplication. The command-line fragment set is then written to a fragment buffer for consumption by sorting and concatenation processes.

[0041] During the fragment concatenation phase, to ensure cross-platform and cross-session determinism, the system assigns a stable sequence number to each command-line fragment. This stable sequence number is derived from the total order relation defined in the rule table, combined with key category priority and dependency topology. The input is a set of command-line fragments, and the output is a command-line parameter string. The sorter performs a stable sorting of the command-line fragments according to their stable sequence numbers and injects connectors between adjacent fragments. On Unix-like platforms, the connector is typically a space; in environments requiring long line continuation, a continuation marker can be used while maintaining logical equivalence. If a conflict constraint pointer is triggered during concatenation, the conflict resolver selects a processing path based on the conflict priority matrix: when a high-priority key conflicts with a low-priority key, the high-priority key is retained first, and a fallback strategy is applied to the low-priority key. Fallback strategies include restoring default values, deleting conflicting fragments, or replacing them with compatible subsets. When equal-priority conflicts exist, an alternative strategy is attempted, including switching to compatible command-line option names, switching to compatible encoding formats, or splitting the fragment into multiple fragments to satisfy the parser constraints. The conflict resolution results are written back to the standard key-value pair set and trigger a local re-render to update the affected command line fragments. After all fragments are sorted and concatenated, a single command line parameter string is generated, and a parameter summary and fragment source table are output. The parameter summary is used for subsequent verification and logging, and the fragment source table is used to locate the consistency between the source key and its command line expression during the dynamic modification phase of the configuration file.

[0042] In one possible implementation, after mapping the build parameters to command-line argument format, the method further includes: generating a command-line argument candidate set based on the standard key-value pair set built for the build parameters; sequentially performing syntax and format checks, integrity checks, and value range and consistency checks on the command-line argument candidate set, wherein the syntax and format checks are used to detect whether the path format, Boolean value format, enumerated values, and deep link host address patterns meet preset specifications; the integrity checks are used to detect missing required fields and mutual exclusion conflicts; and the value range and consistency checks are used to detect the version number semantic monotonicity, resource path reachability, and channel type and whether to remove the dependency constraints of a specific software development kit combination; converting the validated standard key-value pair set into command-line fragments through a command-line rendering rule table, and performing deterministic sorting and concatenation with stable sequence numbers; and when a conflict constraint is triggered, executing a fallback strategy or replacement strategy according to the conflict priority matrix and writing back the corrected standard key-value pair set.

[0043] Specifically, after mapping the parameters to command-line argument format, the parameter parser first constructs a candidate set of command-line arguments based on the generated standard key-value pair set. Each item in the standard key-value pair set consists of a field name and a field value. The field name corresponds to the channel type, deep link host address, whether to remove a specific software development kit, version number, version name, icon resource path, and launch image resource path, etc., while the field value is the user input or a default value. The candidate set is an intermediate set that maps these key-value pairs one by one to the expression of command-line arguments, used to support the subsequent verification and rendering process. By constructing the command-line argument candidate set, complete context information can be preserved before entering the actual rendering, avoiding direct modification operations on the configuration file.

[0044] After the candidate set is generated, the system sequentially performs syntax and format checks, integrity checks, and value range and consistency checks. In the syntax and format check phase, the system uses regularization rules to check whether path fields conform to directory or file path patterns, whether boolean fields conform to binary literal specifications, whether enumeration fields are in the enumeration definition set, and whether deep link host addresses conform to domain name and subdomain format patterns. In the integrity check phase, the system checks whether required fields are missing and whether mutually exclusive fields appear simultaneously; for example, enabling debug logging and enabling release mode cannot both be true. In the value range and consistency check phase, the system checks whether the version number conforms to semantic version increment rules, whether resource paths correspond to valid files or directories, and whether there are logical dependency conflicts between the combination of channel type and whether to remove a specific software development kit. These three types of checks ensure that the candidate set is not only syntactically correct but also logically complete and consistent globally.

[0045] After the candidate set passes validation, the command-line renderer converts the standard key-value pair set into command-line fragments according to the command-line rendering rule table. The command-line rendering rule table defines fixed command-line option names for each standard key and specifies how to call the value encoder to escape or map field values. The value encoder performs space and special character escaping when processing path values, special character security encoding when processing string values, and fixed-length mapping when processing enumeration values ​​to ensure stable interpretation by the command-line parser. The generated command-line fragments are then deterministically sorted and concatenated in the sorter based on stable ordinal numbers. These stable ordinal numbers are determined by the total order relation predefined in the rule table, ensuring consistent output order across different platforms and sessions. During sorting and concatenation, if a conflict constraint is triggered, the conflict resolver selects a fallback or replacement strategy based on the conflict priority matrix. Fallback strategies include deleting or resetting conflicting field values, while replacement strategies include replacing them with compatible values ​​or compatible parameter expressions. The corrected results are written back to the standard key-value pair set to ensure consistency in subsequent construction processes.

[0046] S130: When the verification result meets the preset specifications, the application configuration file, module configuration file and build configuration file are dynamically modified based on the build parameters to complete the real-time adjustment of application information, module attributes and build target, and the configuration result is output.

[0047] In one possible implementation, when the verification result conforms to the preset specifications, the application configuration file, module configuration file, and build configuration file are dynamically modified based on the build parameters to complete the real-time adjustment of application information, module attributes, and build goals, and the configuration result is output. Specifically, this includes: converting the application configuration file, module configuration file, and build configuration file into an abstract syntax tree representation through a configuration parser, and performing key space normalization, default value completion, and initial key conflict screening in the semantic constraint engine to obtain a candidate node set; generating a change plan based on the build parameters, which is then input into a differential patch generator to generate a minimum change set, and the minimum change set is used in the transaction controller as a cross-file consistency barrier. An atomic write sequence is established. Dynamic modifications are then performed on the application configuration file, module configuration file, and build configuration file sequentially according to the atomic write sequence. Dynamic modifications to the application configuration file generate an application-layer change snapshot, dynamic modifications to the module configuration file generate a module-layer change snapshot, and dynamic modifications to the build configuration file generate a build-layer change snapshot. Consistency barrier checks are performed based on the application-layer change snapshot, module-layer change snapshot, and build-layer change snapshot. If the check passes, the transaction is committed and a configuration result containing the application configuration file version number, the module configuration file dependency fingerprint, and the build configuration file target summary is generated. If the check fails, a cross-file rollback is performed and a failure reason report is output.

[0048] Specifically, the process of transforming application configuration files, module configuration files, and build configuration files into an abstract syntax tree representation through the configuration parser involves the configuration parser first reading the text content of the three configuration files and generating a set of syntax nodes based on predefined syntax rules. This set of syntax nodes records keys, values, and hierarchical relationships in a tree structure, thus transforming unstructured text into an operable structured representation. After receiving the abstract syntax tree representation, the semantic constraint engine normalizes the key space, mapping redundant, aliased, or differently formatted keys to standard keys to ensure consistency across files. It also fills in missing fields with default values ​​to ensure the configuration file meets the minimum legal structure requirement. Finally, it performs initial key conflict screening, detecting issues such as duplicate definitions and the simultaneous occurrence of mutually exclusive keys, and outputs a set of filtered candidate nodes, which serves as input for subsequent dynamic modifications.

[0049] The process of generating a change plan based on build parameters involves mapping user-provided build parameters such as channel type, deep link host address, version number, and icon resource path to target locations in the candidate node set. This forms a set of change triples consisting of a target key, a target value, and conditional logic, known as the change plan. After receiving the change plan, the differential patch generator compares the candidate node set with the change plan, extracting the minimum necessary modifications to form a minimum change set. This minimum change set avoids redundant modifications and retains the unchanged parts of the original configuration. Upon receiving the minimum change set, the transaction controller establishes an atomic write sequence using cross-file consistency barriers. This means uniformly sorting and binding the modification steps for the application configuration file, module configuration file, and build configuration file, ensuring that all three satisfy dependencies and maintain consistency during modification execution.

[0050] When dynamic modifications are executed sequentially according to the atomic write sequence, the write executor first modifies the application configuration file, updating the package name, version number, and icon path, and generates an application-layer change snapshot containing the modification location, old value, new value, and timestamp. Next, it modifies the module configuration file, adjusting the deep link host address, startup graph, permission set, and dependency set based on the application-layer change snapshot, generating a module-layer change snapshot. This snapshot records the key-level modification trajectory and set difference details. Finally, it modifies the build configuration file, adjusting the source code directory, resource directory, and compilation target, generating a build-layer change snapshot containing a path mapping table and target summary. All three snapshots are recorded as intermediate products of the transaction for subsequent consistency verification.

[0051] When performing consistency barrier checks based on application-layer, module-layer, and build-layer change snapshots, the transaction controller performs cross-file comparisons on these three types of snapshots. It checks whether the package name and deep-link host address are consistent, whether the permission set and dependency set are closed and complete, whether the resource directory and compilation target correspond to valid paths, and whether the application-layer information, module attributes, and build targets match. If the checks pass, the transaction controller commits the atomic write sequence and outputs the configuration results. The configuration results include the version number of the application configuration file, the dependency fingerprint of the module configuration file, and the target summary of the build configuration file, ensuring the traceability of subsequent build processes. If the checks fail, the transaction controller performs a cross-file rollback, using the snapshots to restore the original state in reverse order, and generates a failure reason report. The report includes conflict fields, failure constraints, and exception types, allowing the user to correct and resubmit.

[0052] In one possible implementation, dynamic modifications are performed on the application configuration file, module configuration file, and build configuration file sequentially according to the atomic write sequence. Specifically, this includes: when dynamically modifying the application configuration file on the application side, locating the package name key, version number key, and icon path key, and generating an application-layer change snapshot containing the modification location, old value, new value, and timestamp. Simultaneously, a dependency export table is output in the application-layer change snapshot to indicate the key references required by the module side. When dynamically modifying the module configuration file on the module side, based on the dependency export table of the application-layer change snapshot, a consistency comparison and correction is performed on the deep link host address key, startup graph key, permission set key, and dependency set key. This generates a module-layer change snapshot containing key-level modification traces, set difference details, and resource reachability verification results. A build constraint export table is output in the module-layer change snapshot. When dynamically modifying the build configuration file on the build side, based on the build constraint export table of the module-layer change snapshot, mapping correction and dependency supplementation are performed on the source code directory key, resource directory key, and compilation target key. This generates a build-layer change snapshot containing a path mapping table, target mapping table, and dependency graph differences.

[0053] Specifically, when dynamically modifying the application configuration file on the application side, the write executor first loads the application configuration file node in the abstract syntax tree representation. Based on the atomic write sequence, it locates the package name key, version number key, and icon path key, matching each one with the target value provided by the build parameters and the current value. If a difference is detected, a minimal change operation is generated and the modification is applied. After modification, the system generates a differential record for each change operation, containing the modification location, old value, new value, and timestamp, merging them to form an application-layer change snapshot. The application-layer change snapshot not only records the change trajectory but also generates a dependency export table. This table identifies key references such as package name strategy, icon resource identifier, and version number information. These key references provide a consistent comparison basis for the module side, ensuring that the fields in the module configuration file match the application configuration file.

[0054] When dynamically modifying the module configuration file on the module side, the write executor reads the dependency export table from the application layer change snapshot and compares each item with the deep link host address key, launch graph key, permission set key, and dependency set key in the module configuration file. If the comparison finds inconsistencies between the deep link host address and package name policy, mismatches between the launch graph resource and icon resource resolutions, or non-closed permission sets and dependency sets, a correction operation is generated. This correction operation may include replacing target values, adding missing entries, or removing redundant entries. After correction, the write executor generates a module-level change snapshot, which includes key-level modification traces, set difference details, and resource reachability verification results. Resource reachability verification verifies whether the launch graph path and dependency references can be found in the current directory structure. The module-level change snapshot also outputs a build constraint export table, which records source code directory mappings, resource directory mappings, and dependency set closures, providing boundary conditions for modifications to the build configuration file.

[0055] When the build configuration file is dynamically modified on the build side, the write executor verifies, item by item, whether the current mapping of source code directory keys, resource directory keys, and compilation target keys satisfies the constraints exported by the module layer, based on the build constraint export table of the module layer change snapshot. If the source code directory path is missing or does not match the module layer dependency set, a mapping correction operation is performed to replace or supplement the directory path; if the resource directory path is redundant or invalid, a cleanup operation is performed to maintain the resource layout consistent with the module layer; when processing the compilation target key, the write executor generates a dependency graph based on the dependency set and build rules, and compares it with the dependency graph in the current build configuration to generate a dependency graph difference, which includes added dependencies, removed dependencies, and updated dependencies. Finally, the write executor generates a build layer change snapshot, which contains a path mapping table, a target mapping table, and a dependency graph difference, used to ensure the reproducibility of the build task environment and the determinism of the generated artifacts during the consistency barrier verification phase.

[0056] S140 transforms the configuration results into a build task, generating a HAP package with timestamps and channel identifiers.

[0057] In one possible implementation, the configuration result is transformed into a build task, generating a HAP package with a timestamp and channel identifier. Specifically, this includes: generating a build plan after parsing the configuration result; converting the build plan into a job queue containing compilation jobs, resource processing jobs, manifest generation jobs, and signing jobs; establishing prerequisite dependencies and output artifact descriptions for each job; verifying the toolchain version, platform target, and minimum compatibility level before execution of the build; and writing the generated environment lock record into the build plan to ensure toolchain consistency between compilation jobs and resource processing jobs; compiling business code and module code according to the source code directory mapping, generating intermediate objects and intermediate libraries; and mapping completion icons for resource processing jobs according to the resource directory. Resources, launch graph resources, and localized resources are packaged and organized, merged into module-level binary and bound to resource indexes during the linking phase, and output module bundles to be injected into the manifest. Application information and module attributes are injected into the module bundles, a manifest is generated to lock the version, and the permission set and dependency graph fingerprint are consistent, as are the deep link host address and package name policy. A signature block and verification digest are generated on the assembly artifact, and the signature time record is attached to the artifact. After signing, the channel identifier and timestamp are injected into the artifact naming template, and a HAP package with timestamp and channel identifier is encapsulated. The artifact archiver generates a build artifact index and a build result object, which includes the installation package path, channel identifier, timestamp, and upload status.

[0058] Specifically, during the build plan generation process after parsing the configuration results, the build task planner first parses the application information, module attributes, and build goals in the configuration results into executable tasks. Based on dependencies, it then decomposes the overall build process into compilation jobs, resource processing jobs, manifest generation jobs, and signing jobs. Each job has prerequisite dependencies; for example, the resource processing job must be executed after the compilation job is completed, the manifest generation job depends on the compilation and resource processing results, and the signing job depends on the manifest generation results. Simultaneously, each job has a clearly defined output artifact description; for example, the compilation job outputs intermediate objects and intermediate libraries, the resource processing job outputs resource indexes and checksums, the manifest generation job outputs the manifest lock version, and the signing job outputs the assembly artifact. In this way, the build plan is organized into an ordered job queue, ensuring the traceability and sequential stability of subsequent task execution.

[0059] Before execution, the environment resolver verifies the toolchain version, platform target, and minimum compatibility level. The toolchain version confirms that the compiler and packaging tool versions match the environment declared in the configuration results. The platform target ensures that the generated application installer can run on the specified HarmonyOS version. The minimum compatibility level verifies that the application's minimum runtime requirements match the target environment. After verification, the environment resolver generates an environment lock record, which includes the toolchain version number, platform target number, and compatibility level parameters, and writes it to the build plan to ensure toolchain consistency across different build nodes and execution sessions.

[0060] During the compilation phase, the compilation job compiles the business code and module code one by one according to the source code directory mapping provided by the configuration results, generating intermediate object files and intermediate library files. Intermediate object files represent the output of a single source code file after compilation, while intermediate library files represent the module-level output of multiple linked object files. Parallel to the compilation job, the resource processing job reads icon resources, launch image resources, and localized resources according to the resource directory mapping, and performs format normalization, resolution calibration, and checksum generation, outputting a unified resource index and checksum summary. During the linking phase, the intermediate library files generated by compilation and the resource index generated by resource processing are merged to form a module-level binary, and the resource index is bound to the binary file, generating a module bundle to be injected with the manifest.

[0061] During the manifest generation phase, the manifest generator injects application information and module attributes into the module bundle. Application information includes the package name, version number, and icon path; module attributes include the deep link host address, permission set, and dependency set. The manifest generator generates a manifest-locked version, which is the final manifest file that has undergone consistency checks. This version ensures that the permission set and dependency graph fingerprint are completely consistent, avoiding missing or redundant dependencies. It also ensures that the deep link host address and package name policy strictly correspond, preventing cross-module call errors.

[0062] During the signing phase, the signer performs a signing operation on the assembled product. The signer loads the signing certificate and private key, generates a checksum of the product based on a hash algorithm, and generates a signature block on the product using the signing algorithm. The signing time is recorded as metadata attached to the product for subsequent traceability of the product's creation date. Once signing is complete, the assembled product is considered a deliverable module, ensuring its credible origin and complete content.

[0063] During the packaging phase, the packager injects a channel identifier and a timestamp into the signed assembly artifact. The channel identifier corresponds to the channel type in the user configuration, and the timestamp corresponds to a unique identifier generated by the build scheduler when the build starts. The packager writes the channel identifier and timestamp into the application installer's filename according to the artifact naming template and performs final encapsulation of the artifact, generating a HAP package with the timestamp and channel identifier. The artifact archiver then stores this HAP package and generates a build artifact index, while simultaneously creating a build result object. The build result object contains the application installer path, channel identifier, timestamp, and upload status, used to support subsequent distribution or integration pipeline tasks, thereby ensuring that the artifact can be traced, verified, and distributed.

[0064] S150 outputs the build results of the HAP package, including the installation package path and upload status, according to the user configuration.

[0065] In one possible implementation, the HAP package output includes the build result containing the installation package path and upload status, based on user configuration. Specifically, this includes: after generating the HAP package, parsing the build artifact index and user configuration to form a distribution plan, which is marked with the target repository identifier, authentication mode, and upload concurrency. When executing the distribution plan, integrity and duplicate checks are first performed on the HAP package. The integrity check outputs a checksum, and the duplicate check determines whether there is a conflict between the channel identifier and the timestamp naming. If a conflict is found, an alternative naming template is generated according to the renaming strategy. After completing the checks, an upload session token is generated based on the user-configured authentication mode and uploaded directly. HAP packages are pushed under the specified path, or fragment and aggregation receipts are pushed under the fragmented resume path. If the upload fails, the retry controller will execute backoff retries according to the retry policy and generate a failure status and failure reason after exceeding the limit. After receiving the confirmation receipt for the upload, a callback action is triggered according to the callback policy configured by the user. The installation package path, channel identifier, timestamp, and access identifier are used as callback inputs, and the distribution log is recorded. After the distribution log, confirmation receipt, and verification summary are converged, a build result object is generated. The build result object contains the installation package path, channel identifier, timestamp, upload status, and log position. The build result object is returned to the upper layer process as the final output.

[0066] Specifically, during the parsing of the build artifact index and user configuration after generating the HAP package, the distribution planner first reads the build artifact index, which records the application installation package path, channel identifier, timestamp, and artifact storage location. Simultaneously, it parses the user configuration to extract the distribution target and strategy. Based on this information, the distribution planner generates a distribution plan. The distribution plan marks the target repository identifier to clarify the upload destination, marks the authentication mode to determine the credential verification method, and marks the upload concurrency level to control the concurrency strategy during chunked push or direct upload, ensuring that subsequent distribution processes meet user settings and system security constraints.

[0067] When executing the distribution plan, the distribution executor first performs integrity and duplicate checks on the HAP package. Integrity checks generate a checksum using a hash function and compare it with the digest from the packaging stage to ensure no tampering occurred during transmission. Duplicate checks compare the channel identifier and timestamp name of the HAP package with existing records in the target warehouse to determine if there are any conflicting products with the same name. If a conflict is found, the distribution executor generates an alternative naming template according to a renaming strategy, such as adding a unique suffix or adjusting the timestamp format, thereby ensuring that the product is uniquely identifiable in the target warehouse.

[0068] After verification, the distribution executor generates an upload session token based on the authentication mode configured by the user. Authentication modes may include credential verification based on username and password, token generation based on keys, or authorization processes based on the OAuth protocol. After the session token is established, if the direct upload path is selected, the distribution executor directly pushes the HAP package to the target repository and waits for confirmation receipt; if the fragmented upload path is selected, the distribution executor divides the HAP package into multiple fragments of a fixed size, each fragment with a sequence number and offset, uploads them one by one, and then the receipt aggregator executes a merge request, finally returning an aggregated receipt. If the upload fails, the retry controller executes backoff retries according to the retry policy configured by the user. The backoff policy may use exponential backoff or fixed-interval retries. If the upload still fails after exceeding the preset maximum number of attempts, a failure status is generated and the reason for failure is recorded for traceability.

[0069] After receiving confirmation of the upload, the distribution executor triggers a callback action based on the user-configured callback strategy. The callback strategy includes the callback address, callback method, and callback data format. The callback input includes the installation package path, channel identifier, timestamp, and access identifier, ensuring that the upper-layer process can receive upload completion information in real time. The distribution executor also generates a distribution log, recording the results of each step of the upload process, timestamps, session token identifiers, and the target repository's response, serving as a basis for subsequent traceability and debugging.

[0070] After converging distribution logs, confirmation receipts, and verification summaries, the result generator summarizes this information to generate a build result object. The build result object includes the application installation package path, channel identifier, timestamp, upload status, and log location. The upload status is marked as "not uploaded," "uploaded," or "upload failed" based on the execution result. The build result object is returned as the sole output to the upper-level process for direct use by automated pipelines, manual review, or multi-channel distribution systems, ensuring a closed-loop process and traceability.

[0071] This embodiment also discloses a HarmonyOS application channel package dynamic generation device, referring to... Figure 2The device includes an acquisition module 201, a processing module 202, and an output module 203. It is used to execute any of the HarmonyOS application channel package dynamic generation methods described above, wherein: The acquisition module 201 is used to receive the construction parameters input by the user.

[0072] Processing module 202 is used to map the build parameters to command-line argument format in order to perform the verification process.

[0073] The processing module 202 is used to dynamically modify the application configuration file, module configuration file and build configuration file based on the build parameters when the verification result meets the preset specifications, so as to complete the real-time adjustment of application information, module attributes and build target, and output the configuration result.

[0074] Processing module 202 is used to convert the configuration results into build tasks and generate HAP packages with timestamps and channel identifiers.

[0075] Output module 203 is used to output the build result of the HAP package, including the installation package path and upload status, according to user configuration.

[0076] In one possible implementation, the processing module 202 is used to perform type normalization processing on the construction parameters based on a preset parameter pattern library, and to uniformly convert the channel type, deep link host address, whether to remove a specific software development kit, version number, version name, icon resource path and launch image resource path into a standard key-value pair set, and to mark the conflict constraint pointer in the standard key-value pair set.

[0077] The processing module 202 is used to convert the standard key-value pair set into command line fragments item by item according to the command line rendering rule table. The command line rendering rule table defines the correspondence between standard keys and command line option names and the mapping relationship of the value encoder. The value encoder is used to perform path escaping, special character safe encoding and fixed-length mapping of enumeration values.

[0078] The processing module 202 is used to perform fragment concatenation and inject connectors to form a command line parameter string after generating command line fragments, using stable sequence numbers as sorting keys. If a conflict constraint pointer is triggered during rendering, a rollback strategy or replacement strategy is executed according to the conflict priority matrix and the standard key-value pair set is corrected.

[0079] In one possible implementation, processing module 202 is configured to generate a set of command-line argument candidates based on a standard set of key-value pairs constructed for the build parameters.

[0080] The processing module 202 is used to sequentially perform syntax and format checks, integrity checks, and value range and consistency checks on the candidate set of command line arguments. The syntax and format checks are used to detect whether the path format, Boolean value format, enumeration values, and deep link host address patterns meet the preset specifications. The integrity checks are used to detect missing required fields and mutual exclusion conflicts. The value range and consistency checks are used to detect the version number semantic monotonicity, resource path reachability, and channel type and whether to remove the dependency constraints of a specific software development kit combination.

[0081] The processing module 202 is used to convert the validated set of standard key-value pairs into command line fragments by rendering the rule table through the command line, and to perform deterministic sorting and concatenation with stable sequence numbers. When a conflict constraint is triggered, a rollback strategy or substitution strategy is executed according to the conflict priority matrix and the corrected set of standard key-value pairs is written back.

[0082] In one possible implementation, the processing module 202 is used to convert the application configuration file, module configuration file and build configuration file into an abstract syntax tree representation through a configuration parser, and to complete key space normalization, default value completion and key conflict screening in the semantic constraint engine to obtain a candidate node set.

[0083] Processing module 202 is used to generate a change plan based on the build parameters. The change plan is input into the differential patch generator to generate a minimum change set. The minimum change set is used in the transaction controller to establish an atomic write sequence in the form of cross-file consistency barriers.

[0084] The processing module 202 is used to dynamically modify the application configuration file, module configuration file and build configuration file in sequence according to the atomic write sequence. The dynamic modification of the application configuration file generates an application layer change snapshot, the dynamic modification of the module configuration file generates a module layer change snapshot, and the dynamic modification of the build configuration file generates a build layer change snapshot.

[0085] Processing module 202 is used to perform consistency barrier verification based on application layer change snapshot, module layer change snapshot and build layer change snapshot. If the verification passes, the transaction is committed and a configuration result containing the application configuration file version number, module configuration file dependency fingerprint and build configuration file target summary is generated. If the verification fails, cross-file rollback is performed and a failure reason report is output.

[0086] In one possible implementation, the processing module 202 is used to locate the package name key, version number key, and icon path key when the application configuration file is dynamically modified on the application side, and generate an application layer change snapshot containing the modification location, old value, new value, and timestamp. At the same time, the application layer change snapshot outputs a dependency export table to indicate the key references required by the module side.

[0087] The processing module 202 is used to perform consistency comparison and correction on the deep link host address key, startup graph key, permission set key and dependency set key based on the dependency export table of the application layer change snapshot when the module configuration file is dynamically modified on the module side. It generates a module layer change snapshot containing key-level modification trajectory, set difference details and resource reachability verification results, and outputs the build constraint export table in the module layer change snapshot.

[0088] The processing module 202 is used to perform mapping correction and dependency supplementation on the source code directory key, resource directory key and compilation target key based on the build constraint export table of the module layer change snapshot when the build configuration file is dynamically modified on the build side, and generate a build layer change snapshot containing path mapping table, target mapping table and dependency graph difference.

[0089] In one possible implementation, the processing module 202 is used to generate a build plan after parsing the configuration results. The build plan is converted into a job queue containing compilation jobs, resource processing jobs, manifest generation jobs, and signing jobs, and a prerequisite dependency and output artifact description are established for each job.

[0090] Processing module 202 is used to verify the toolchain version, platform target and minimum compatibility level before execution of the build, and write the generated environment lock record into the build plan, thereby ensuring the consistency of the toolchain between the compilation job and the resource processing job.

[0091] Processing module 202 is used to compile business code and module code according to the source code directory mapping, generate intermediate objects and intermediate libraries, and complete the packaging and organization of icon resources, startup image resources and localization resources according to the resource directory mapping. During the linking stage, they are merged into module-level binary and bound to resource indexes, and the module bundle to be injected into the manifest is output.

[0092] Processing module 202 is used to inject application information and module attributes into the module bundle, generate a manifest to lock the version, and ensure that the permission set is consistent with the dependency graph fingerprint, and that the deep link host address and package name policy are consistent.

[0093] Output module 203 is used to generate a signature block and verification digest on the assembled product and to attach the signature time record to the product.

[0094] Processing module 202 is used to inject the channel identifier and timestamp into the product naming template after signing, encapsulate and generate a HAP package with timestamp and channel identifier, and generate a build product index and build result object by the product archiver. The build result object includes the installation package path, channel identifier, timestamp and upload status.

[0095] In one possible implementation, the acquisition module 201 is used to parse the build artifact index and user configuration after generating the HAP package to form a distribution plan. The distribution plan is marked with the target repository identifier, authentication mode and upload concurrency.

[0096] The processing module 202 is used to perform integrity verification and duplicate verification on the HAP package when executing the distribution plan. The integrity verification outputs a verification summary, and the duplicate verification determines whether the channel identifier and timestamp naming conflict. If there is a conflict, an alternative naming template is generated according to the renaming strategy.

[0097] The processing module 202 is used to generate an upload session token according to the authentication mode configured by the user after the verification is completed, and push HAP packets under the direct upload path or push fragment and aggregation receipts under the fragmented resume upload path. If the upload fails, the retry controller will execute backoff retry according to the retry policy and generate a failure status and failure reason after exceeding the limit.

[0098] The processing module 202 is used to trigger a callback action according to the callback strategy configured by the user after receiving a confirmation receipt for uploading. The installation package path, channel identifier, timestamp and access identifier are used as callback inputs, and the distribution log is recorded.

[0099] The processing module 202 is used to generate a build result object after accumulating distribution logs, confirmation receipts and verification summaries. The build result object includes the installation package path, channel identifier, timestamp, upload status and log location, and returns the build result object as the final output to the upper layer process.

[0100] It should be noted that the above embodiments of the apparatus are only illustrated by the division of the above functional modules. In practical applications, the above functions can be assigned to different functional modules as needed, that is, the internal structure of the device can be divided into different functional modules to complete all or part of the functions described above. In addition, the apparatus and method embodiments provided in the above embodiments belong to the same concept, and the specific implementation process can be found in the method embodiments, which will not be repeated here.

[0101] This embodiment also discloses an electronic device, as shown in the reference. Figure 3 The electronic device may include: at least one processor 301, at least one communication bus 302, user interface 303, network interface 304, and at least one memory 305.

[0102] The communication bus 302 is used to enable communication between these components.

[0103] The user interface 303 may include a display screen and a camera. Optionally, the user interface 303 may also include a standard wired interface and a wireless interface.

[0104] The network interface 304 may optionally include a standard wired interface or a wireless interface (such as a Wi-Fi interface).

[0105] The processor 301 may include one or more processing cores. The processor 301 connects to various parts of the server using various interfaces and lines, and performs various server functions and processes data by running or executing instructions, programs, code sets, or instruction sets stored in memory 305, and by calling data stored in memory 305. Optionally, the processor 301 may be implemented using at least one hardware form of Digital Signal Processing (DSP), Field-Programmable Gate Array (FPGA), or Programmable Logic Array (PLA). The processor 301 may integrate one or a combination of several of the following: Central Processing Unit (CPU), Graphics Processing Unit (GPU), and modem. The CPU primarily handles the operating system, user interface, and applications. The GPU is responsible for rendering and drawing the content required for display. The modem handles wireless communication. It is understood that the modem may also not be integrated into the processor 301 and may be implemented as a separate chip.

[0106] The memory 305 may include random access memory (RAM) or read-only memory. Optionally, the memory may include a non-transitory computer-readable storage medium. The memory 305 may be used to store instructions, programs, code, code sets, or instruction sets. The memory 305 may include a program storage area and a data storage area. The program storage area may store instructions for implementing an operating system, instructions for at least one function (such as touch functionality, sound playback functionality, image playback functionality, etc.), and instructions for implementing the various method embodiments described above. The data storage area may store data involved in the various method embodiments described above. Optionally, the memory 305 may also be at least one storage device located remotely from the aforementioned processor 301. As a computer storage medium, the memory 305 may include an operating system, a network communication module, a user interface 303 module, and an application program for a HarmonyOS application channel package dynamic generation method.

[0107] exist Figure 3 In the illustrated electronic device, the user interface 303 is primarily used to provide an input interface for the user and to acquire user input data. The processor 301 can be used to call an application stored in the memory 305 that provides a method for dynamically generating HarmonyOS application channel packages. When executed by one or more processors 301, this causes the electronic device to perform one or more methods as described in the above embodiments.

[0108] It should be noted that, for the sake of simplicity, the foregoing method embodiments are all described as a series of actions. However, those skilled in the art should understand that the present invention is not limited to the described order of actions, as some steps can be performed in other orders or simultaneously according to the present invention. Furthermore, those skilled in the art should also understand that the embodiments described in the specification are preferred embodiments, and the actions and modules involved are not necessarily essential to the present invention.

[0109] In the above embodiments, the descriptions of each embodiment have different focuses. For parts not described in detail in a certain embodiment, please refer to the relevant descriptions in other embodiments.

[0110] In the several embodiments provided by this invention, it should be understood that the disclosed apparatus can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some service interface; the indirect coupling or communication connection between apparatuses or units may be electrical or other forms.

[0111] The units described as separate components may or may not be physically separate. The components shown 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 units can be selected to achieve the purpose of this embodiment according to actual needs.

[0112] Furthermore, the functional units in the various embodiments of the present invention 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. The integrated unit can be implemented in hardware or as a software functional unit.

[0113] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage device (CMD). Based on this understanding, the technical solution of this invention, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a memory 305 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 of the various embodiments of this invention. The aforementioned memory 305 includes various media capable of storing program code, such as a USB flash drive, external hard drive, magnetic disk, or optical disk.

[0114] The present invention also discloses a computer-readable storage medium storing instructions. When executed by one or more processors 301, these instructions cause an electronic device to perform one or more methods as described in the above embodiments.

[0115] The above are merely exemplary embodiments of this disclosure and should not be construed as limiting the scope of this disclosure. Any equivalent changes and modifications made in accordance with the teachings of this disclosure shall still fall within the scope of this disclosure. Those skilled in the art will readily conceive of other embodiments of this disclosure upon considering the specification and the disclosure of practical truths. This invention is intended to cover any variations, uses, or adaptations of this disclosure that follow the general principles of this disclosure and include common knowledge or customary techniques in the art not described in this disclosure. The specification and embodiments are to be considered exemplary only, and the scope and spirit of this disclosure are defined by the claims.

Claims

1. A method for dynamically generating HarmonyOS application channel packages, characterized in that, The method includes: Receive build parameters input by the user; The construction parameters are mapped to command-line argument format to perform the verification process; When the verification result meets the preset specifications, the application configuration file, module configuration file and construction configuration file are dynamically modified based on the construction parameters to complete the real-time adjustment of application information, module attributes and construction goals, and output the configuration result; The configuration results are transformed into a build task to generate a HAP package with a timestamp and channel identifier; The HAP package outputs a build result, including the installation package path and upload status, based on the user configuration.

2. The method for dynamically generating HarmonyOS application channel packages according to claim 1, characterized in that, The process of mapping the construction parameters to command-line argument format specifically includes: Based on the preset parameter pattern library, the construction parameters are standardized by converting the channel type, deep link host address, whether to remove a specific software development kit, version number, version name, icon resource path and launch image resource path into a standard key-value pair set, and marking conflict constraint pointers in the standard key-value pair set. The standard key-value pair set is converted into command line fragments item by item according to the command line rendering rule table. The command line rendering rule table defines the correspondence between standard keys and command line option names and the mapping relationship of the value encoder. The value encoder is used to perform path escaping, special character safe encoding and fixed-length mapping of enumeration values. After generating the command line fragment, the fragments are concatenated using the stable sequence number as the sorting key and a connector is injected to form a command line parameter string. If the conflict constraint pointer is triggered during the rendering process, a rollback strategy or an alternative strategy is executed according to the conflict priority matrix and the standard key-value pair set is corrected.

3. The method for dynamically generating HarmonyOS application channel packages according to claim 2, characterized in that, After mapping the build parameters to command-line argument format, the method further includes: Based on the standard key-value pair set constructed for the aforementioned construction parameters, a candidate set of command-line arguments is generated; The command line parameter candidate set is sequentially subjected to syntax and format verification, integrity verification, and value range and consistency verification. The syntax and format verification is used to detect whether the path format, Boolean value format, enumeration value and deep link host address pattern meet the preset specifications. The integrity verification is used to detect missing required fields and mutual exclusion conflicts. The value range and consistency verification is used to detect the version number semantic monotonicity, resource path reachability and channel type and whether to remove the dependency constraints of a specific software development kit combination. The set of standard key-value pairs that have passed the verification is converted into command line fragments by rendering the rule table through the command line. Deterministic sorting and concatenation are performed with stable sequence numbers. When a conflict constraint is triggered, a rollback strategy or replacement strategy is executed according to the conflict priority matrix and the corrected set of standard key-value pairs is written back.

4. The method for dynamically generating HarmonyOS application channel packages according to claim 1, characterized in that, When the verification result meets the preset specifications, based on the construction parameters, the application configuration file, module configuration file, and construction configuration file are dynamically modified to complete the real-time adjustment of application information, module attributes, and construction goals, and the configuration result is output, specifically including: The application configuration file, the module configuration file, and the build configuration file are converted into an abstract syntax tree representation by a configuration parser, and key space normalization, default value completion, and initial screening of key conflicts are completed in the semantic constraint engine to obtain a candidate node set. A change plan is generated based on the construction parameters. The change plan is input into a differential patch generator to generate a minimum change set. The minimum change set is used in the transaction controller to establish an atomic write sequence in the form of a cross-file consistency barrier. Dynamic modifications are performed on the application configuration file, the module configuration file, and the build configuration file in sequence according to the atomic write sequence. The dynamic modification of the application configuration file generates an application layer change snapshot, the dynamic modification of the module configuration file generates a module layer change snapshot, and the dynamic modification of the build configuration file generates a build layer change snapshot. Based on the application layer change snapshot, the module layer change snapshot, and the build layer change snapshot, a consistency barrier check is performed. If the check passes, the transaction is committed and a configuration result containing the application configuration file version number, the module configuration file dependency fingerprint, and the build configuration file target summary is generated. If the check fails, a cross-file rollback is performed and a failure reason report is output.

5. The method for dynamically generating HarmonyOS application channel packages according to claim 4, characterized in that, The step of dynamically modifying the application configuration file, the module configuration file, and the build configuration file sequentially according to the atomic write sequence specifically includes: When dynamically modifying the application configuration file on the application side, locate the package name key, version number key, and icon path key, and generate an application layer change snapshot containing the modification location, old value, new value, and timestamp. At the same time, output the dependency export table in the application layer change snapshot to indicate the key references required by the module side. When the module configuration file is dynamically modified on the module side, the consistency comparison and correction of the deep link host address key, startup graph key, permission set key and dependency set key are performed based on the dependency export table of the application layer change snapshot. A module layer change snapshot containing key-level modification trajectory, set difference details and resource reachability verification results is generated, and the build constraint export table is output in the module layer change snapshot. When the build configuration file is dynamically modified on the build side, the source code directory key, resource directory key and compilation target key are mapped and supplemented based on the build constraint export table of the module layer change snapshot, and a build layer change snapshot containing path mapping table, target mapping table and dependency graph difference is generated.

6. The method for dynamically generating HarmonyOS application channel packages according to claim 5, characterized in that, The step of converting the configuration result into a build task to generate a HAP package with a timestamp and channel identifier specifically includes: After parsing the configuration results, a build plan is generated. The build plan is transformed into a job queue containing compilation jobs, resource processing jobs, manifest generation jobs, and signing jobs, and a prerequisite dependency and output artifact description are established for each job. Before executing the build, the toolchain version, platform target, and minimum compatibility level are checked, and the generated environment lock record is written into the build plan to ensure the consistency of the toolchain between the compilation job and the resource processing job. The business code and module code are compiled according to the source code directory mapping, generating intermediate objects and intermediate libraries. The resource processing job completes the packaging and organization of icon resources, startup image resources and localization resources according to the resource directory mapping. During the linking stage, they are merged into module-level binary and bound to resource indexes, and the module bundle to be injected into the manifest is output. Inject the application information and module attributes into the module bundle, generate a manifest to lock the version, and ensure that the permission set is consistent with the dependency graph fingerprint, and that the deep link host address is consistent with the package name policy; Generate a signature block and verification summary on the assembled product, and append the signature time record to the product; After signing, the channel identifier and timestamp are injected into the product naming template, and a HAP package with timestamp and channel identifier is generated. The product archiver then generates a product index and a build result object, which includes the installation package path, channel identifier, timestamp, and upload status.

7. The method for dynamically generating HarmonyOS application channel packages according to claim 1, characterized in that, The step of outputting the build result of the HAP package, including the installation package path and upload status, according to user configuration specifically includes: After generating the HAP package, the artifact index and user configuration are parsed to form a distribution plan. The distribution plan is marked with the target repository identifier, authentication mode and upload concurrency. When executing the distribution plan, the HAP package is first subjected to integrity and duplication checks. The integrity check outputs a check summary, and the duplication check determines whether the channel identifier and timestamp naming conflict. If there is a conflict, an alternative naming template is generated according to the renaming strategy. After verification, an upload session token is generated according to the authentication mode configured by the user, and the HAP packet is pushed under the direct upload path or the fragment and aggregation receipt is pushed under the fragmented resume upload path. If the upload fails, the retry controller will execute backoff retry according to the retry policy and generate a failure status and failure reason after exceeding the limit. After receiving confirmation of upload, a callback action is triggered according to the callback strategy configured by the user, using the installation package path, channel identifier, timestamp, and access identifier as callback inputs, and recording the distribution log; After merging the distribution logs, confirmation receipts, and verification summaries, a build result object is generated. The build result object includes the installation package path, channel identifier, timestamp, upload status, and log location. The build result object is then returned to the upper-level process as the final output.

8. A device for dynamically generating HarmonyOS application channel packages, characterized in that, The device is used to execute a method for dynamically generating HarmonyOS application channel packages as described in any one of claims 1-7, the device comprising an acquisition module, a processing module, and an output module, wherein: The acquisition module is used to receive the construction parameters input by the user; The processing module is used to map the construction parameters into command-line parameter format in order to perform a verification process; The processing module is used to dynamically modify the application configuration file, module configuration file and construction configuration file based on the construction parameters when the verification result meets the preset specifications, so as to complete the real-time adjustment of application information, module attributes and construction target, and output the configuration result. The processing module is used to convert the configuration result into a build task and generate a HAP package with a timestamp and channel identifier; The output module is used to output the build result of the HAP package, including the installation package path and upload status, according to the user configuration.

9. An electronic device, characterized in that, The device includes a processor, a communication bus, a user interface, a network interface, and a memory. The memory is used to store instructions. The user interface and the network interface are both used to communicate with other devices. The communication bus is used to enable communication between the components within the electronic device. The processor is used to execute the instructions stored in the memory to cause the electronic device to perform the method as described in any one of claims 1-7.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores instructions that, when executed, perform the method as described in any one of claims 1-7.

Images