Multi-provincial customization method and system applied to terminal equipment and automatic deployment method of multi-provincial customization system

Abstract

The embodiment of the invention discloses a multi-provincial-domain customization method and system applied to terminal equipment and an automatic deployment method of the multi-provincial-domain customization method and system. The method comprises the following steps: analyzing provincial domain customization requirements, classifying provincial domain customization parameters, defining field specifications of the classified parameters, and generating a data modeling rule template; reading the data modeling rule template, performing grammar analysis to generate an abstract syntax tree, abstracting each component of the data modeling rule template into a node tree, performing atomization conversion, and outputting an obtained rule set as a deconstruction rule set; analyzing the received deconstruction rule set, and performing data filling on different atomization conversion sequences according to classification when the application program is initialized; and externally arranging the generated configuration file in a system partition of the terminal equipment. The provincial domain configuration is externally arranged in the system partition of the terminal equipment, the configuration file is analyzed through the analysis engine module when the terminal equipment runs, and the automatic deployment link is constructed to automatically deploy the configuration file to the terminal equipment, so that the resource waste is reduced, and the configuration efficiency is improved.

Description

Technical Field

[0001] This invention belongs to the field of electrical data processing technology, specifically relating to a multi-province customization method, system, and automated deployment method for terminal devices. Background Technology

[0002] With the nationwide proliferation of smart terminal devices (such as set-top boxes and smart TVs), the demand for differentiated customization across provinces has become an essential industry requirement. Due to differences in policies, regulations, operator standards, group standards, and user preferences, different provinces require the same Android application to present different UI interfaces, functional logic, or service entry points.

[0003] To meet the diverse needs of different provinces for application interfaces and business logic, traditional solutions primarily rely on two industry-standard technologies. One is multi-channel packaging, which uses the Android Gradle plugin's productFlavors mechanism to generate a separate APK for each province, with customized parameters hard-coded into resource files. The number of resource directories and APKs generated and deployed corresponds to the number of different customizations, leading to a sharp increase in storage and compilation resources. The other is cloud-based configuration, where the application retrieves provincial configurations from the server upon startup, relying on real-time network interaction.

[0004] However, in multi-channel packaging technology, each new province customization requires a complete compilation → signing → distribution process, generating an independent APK. When supporting N provinces, storage overhead increases to O(N), with N APKs with identical code consuming significant server storage. Furthermore, the province customization parameters and resource identifiers are embedded in the application code, leading to high coupling between configuration and code. This strong dependency causes a chain reaction of problems: a surge in application packaging, with each province requiring independent compilation, signing, and the generation of a dedicated APK, resulting in a linear waste of storage resources and compilation time, severely slowing down delivery efficiency; high maintenance costs; if single-project, single-branch development is adopted, the mixed provincial customization code significantly increases the risk of code reading and modification, easily triggering "logic bloat and domino effect," and modifying logic in one province can easily cause cross-province compatibility issues; if multi-branch parallel development is adopted, problems such as chaotic branch management and migration difficulties arise as the number of provinces increases, with each province having its own branch, facing "Branch Hell"—frequent merge conflicts, difficulty in tracing historical versions, and exponentially increasing management costs. Both models lead to iteration delays, and management complexity continues to worsen with increasing demands.

[0005] Cloud-based configuration delivery technology involves terminal devices sending configuration requests to a server, which then returns differentiated configuration parameters. The terminal dynamically adjusts its interface based on these parameters. This approach has high requirements for network connectivity and server bandwidth, resulting in high costs. Furthermore, this method is heavily reliant on network connectivity, and terminal devices such as set-top boxes often operate in weak network environments. Configuration retrieval failures can lead to functional malfunctions and startup delays, requiring users to wait for configuration downloads when first opening the application, thus compromising the user experience. Summary of the Invention

[0006] In view of this, on the one hand, some embodiments disclose a multi-province customization method applied to terminal devices, including the following steps: S1. Analyze the customized requirements of each province, classify the customized parameters of each province, define the field specifications of the classified parameters, and generate data modeling rule templates; S2. Read the data modeling rule template, perform syntax parsing, generate an abstract syntax tree, abstract each component of the data modeling rule template into a node tree, perform atomic transformation on the node tree, and output the resulting rule set as a deconstructed rule set. S3. Parse the received deconstruction rule set. During initialization, the application fills in the data for different atomization transformation sequences according to the classification. S4. Place the generated configuration file on the system partition of the terminal device.

[0007] Furthermore, some embodiments disclose a multi-province customization method applied to terminal devices. In step S1, the parameter classification includes UI parameters, functional parameters, and business parameters; in step S2, the node tree includes UI nodes, logical nodes, and business nodes.

[0008] In some embodiments of the multi-province customization method for terminal devices, in step S3, after receiving the atomic conversion sequence, each processing interface is loaded, the configuration files of different partition paths are adapted, the serialized data is analyzed and interpreted, the classification of the sequence data is determined by itself, and the data is sent to different rule interpreters for data filling according to different classifications.

[0009] Some embodiments disclose a multi-province customization method for terminal devices, in which the rule interpreter includes a UI renderer and a logic executor.

[0010] In some embodiments of the multi-province customization method for terminal devices, if an abnormality occurs in step S3, the step is automatically rolled back, the abnormality information is stored in the corresponding memory, the rollback position is recorded, and default data is filled in as needed.

[0011] On the other hand, some embodiments disclose a multi-province customization system for terminal devices, used to execute a multi-province customization method for terminal devices, the system comprising: Standardize predefined modules; configure them to analyze provincial customization requirements, classify provincial customization parameters, define field specifications for classification parameters, and generate data modeling rule templates; The rule destructuring module is configured to read the data modeling rule template, perform syntax parsing, generate an abstract syntax tree, abstract each component of the data modeling rule template into a node tree, perform atomic transformation on the node tree, and output the resulting rule set as a destructuring rule set. The parsing engine module is configured to parse the received deconstruction rule set. During initialization, the application populates different atomic transformation sequences with data according to the classification. Configuration module; configured to place the generated configuration file externally in the terminal device's system partition.

[0012] Furthermore, some embodiments disclose automated deployment methods for multi-provincial customized systems applied to terminal devices, including: Trigger the build task of the configuration engine; Automated metadata scanning and analysis; Decision-making regarding configuration changes; Determine the configuration file. Register the configuration file to the system node.

[0013] Furthermore, some embodiments of the multi-province customization method for terminal devices also include: compiling a terminal system image and releasing it.

[0014] Some embodiments disclose a multi-provincial customization method for terminal devices, including configuration change decisions and configuration file determination: If the configuration is updated, the new configuration will be compiled and written to the corresponding server node; If the configuration has not been updated, then trace back to the previous version and register the previous version to the corresponding server node.

[0015] Some embodiments disclose a multi-province customization method for terminal devices, which includes compiling a terminal system image by dynamically injecting customized corresponding provincial nodes according to the selected nodes, and the compilation chain putting all the necessary build dependencies into a container for compilation and injecting the registered nodes into the system image partition one by one.

[0016] The multi-province customization method for terminal devices disclosed in this invention places the provincial configuration externally in the system partition of the terminal device. When the terminal device is running, it parses the configuration file through the parsing engine module and builds an automated deployment link to automatically deploy the configuration file to the terminal device, which greatly reduces resource waste, improves configuration efficiency, and reduces maintenance costs. Attached Figure Description

[0017] Figure 1Example 1 discloses a flowchart of a multi-province customization method for terminal devices; Figure 2 Example 2 discloses an automated deployment flowchart of a multi-province customized system for terminal devices. Detailed Implementation

[0018] The term "embodiment" used herein, as an example, is not necessarily to be construed as superior to or better than other embodiments. Performance testing in these embodiments of the invention, unless otherwise specified, employs conventional testing methods in the art. It should be understood that the terminology used in these embodiments is merely for describing particular implementations and is not intended to limit the scope of the disclosure of these embodiments.

[0019] Unless otherwise stated, the technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which the embodiments of this invention pertain; other experimental methods and technical means not specifically noted in the embodiments of this invention refer to experimental methods and technical means commonly used by one of ordinary skill in the art.

[0020] The terms “basic” and “approximately” as used herein are used to describe small fluctuations. For example, they can mean less than or equal to ±5%, such as less than or equal to ±2%, such as less than or equal to ±1%, such as less than or equal to ±0.5%, such as less than or equal to ±0.2%, such as less than or equal to ±0.1%, such as less than or equal to ±0.05%. Numerical data presented or expressed in range format herein are used for convenience and brevity only, and should therefore be interpreted flexibly to include not only the explicitly listed values ​​that define the range, but also all independent values ​​or subranges contained within that range. For example, a numerical range of “1–5%” should be interpreted to include not only the explicitly listed values ​​from 1% to 5%, but also the independent values ​​and subranges within the indicated range. Thus, this numerical range includes independent values ​​such as 2%, 3.5%, and 4%, and subranges such as 1%–3%, 2%–4%, and 3%–5%, etc. This principle also applies to ranges that list only one value. Furthermore, this interpretation applies regardless of the width of the range or the characteristics described.

[0021] In this document, including in the claims, conjunctions such as "comprising," "including," "with," "having," "containing," "involving," and "accommodating" are understood to be open-ended, meaning "including but not limited to." Only the conjunctions "consisting of" and "composed of" are closed conjunctions.

[0022] To better illustrate the content of this invention, numerous specific details are provided in the following detailed embodiments. Those skilled in the art should understand that the invention can be practiced even without certain specific details. In the embodiments, some methods, means, instruments, and devices well-known to those skilled in the art are not described in detail, in order to highlight the main points of the invention.

[0023] Without conflict, the technical features disclosed in the embodiments of the present invention can be combined arbitrarily, and the resulting technical solution belongs to the content disclosed in the embodiments of the present invention.

[0024] In some embodiments, the multi-provincial customization method applied to terminal devices includes the following steps: S1. Analyze the province-wide customization requirements, classify the province-wide customization parameters, define the field specifications of the classified parameters, and generate data modeling rule templates; typically, parameters can be classified into UI parameters, functional parameters, and business parameters. Typically, provincial-level customized requirements or specifications are broken down into multiple parameters, which are then categorized. For example, based on UI effects, functional logic, and business, parameters are divided into three categories: UI parameters, functional parameters, and business parameters. Each category of parameters is then uniformly and standardizedly defined, thereby enabling data modeling and combination as needed to obtain data modeling rule templates. S2. Read the data modeling rule template, perform syntax parsing, generate an abstract syntax tree, abstract each component of the data modeling rule template into a node tree, perform atomic transformation on the node tree, and output the resulting rule set as a destructured rule set. Typically, the generated node tree includes UI nodes, logic nodes, and business nodes. The data modeling rule template usually contains multiple components. Through a standardized parsing syntax, each component is abstracted into a node tree. Each node in the node tree is atomically serialized, and the rule nodes are converted into executable program instructions. Finally, the destructured rule set is obtained. This rule set can then be input into the parsing module for further parsing and encapsulation so that it can be recognized. Typically, a component refers to a reusable small functional module object encapsulating data and methods. Typically, the structured rule set is a low-level, imperative, atomic, and serializable set of instructions output by the parsing module after processing the high-level, declarative data modeling rule template. The final data format can be converted into a mapping list or a sequential list in the program. A list is also a collection of instructions serialized from a combination set. Because the instructions in the instruction set are also constrained by rules, it can also be called a rule set.

[0025] S3. Parse the received destructuring rule set. During initialization, the application fills in the data for different atomic transformation sequences according to the classification. Usually, the received structure rule set is the configuration file. At this time, the rule set still supports human customization and modification. Typically, after receiving the atomic transformation sequence, it loads various processing interfaces, adapts the configuration files for different partition paths, analyzes and interprets the serialized data, and determines the classification of the sequence data. According to different classifications, it will be transmitted to different rule interpreters for data filling. Typically, based on the classification of sequence data, such as UI parameters or functional parameters, the program will automatically determine which sequence data to pass to the UI renderer and logic executor for final data filling. Typically, data classification can be predefined in components, with multiple classifications corresponding to multiple interpreters. An application may have only one or more classifications depending on the required functionality, and may correspond to one or more interpreters. Typically, data population is the process of associating (binding) abstract, parameterized atomic instructions from the "deconstruction rule set" with specific UI components, business objects, or functions in the current runtime environment, and assigning (injecting) the parameter values ​​they carry to the target object. For example: Enter an abstract, simple atomic command such as {"op": "setText", "target": "btn_submit", "value": "Submit"}; Output a specific, effective UI change or logic execution result, such as the button text with ID btn_submit being successfully set to "Submit"; The data population process is executed automatically by the parsing engine during application initialization. First, it checks if the "op" field of the operation type in the instruction is in the predefined rule template list (supporting sequential lookup). If it exists, its category is determined, and the instruction is routed (distributed) to the corresponding rule interpreter for processing based on the category. The interpreter parses the target (target identifier) ​​field in the instruction, finds and retrieves the actual reference "btn_submit" to the target object in the current runtime context, and finally injects the "value" into the object.

[0026] Typically, if an exception occurs midway, the process automatically rolls back to the previous step, storing the exception information in the corresponding memory, recording the rollback position, and filling in default data as needed. This rollback usually doesn't refer to rolling back the entire sequence, but rather rolling back the sequence in progress. If the sequence has sub-branch sequences, these sub-branch sequences are also rolled back.

[0027] Generally, the entire sequence refers to the set of all instruction operations that need to be parsed in a file, while the ongoing sequence refers to the instruction being parsed. A single instruction can contain descendant instructions; therefore, the relationship between the entire sequence and the ongoing sequence is the same as the relationship between a sequence and a sub-branch sequence.

[0028] Generally, after serialization, a configuration file becomes an instruction set, which is a collection of multiple instructions. Instructions A or B in the instruction set are allowed to have descendant instructions, which are the sub-branch sequences of instructions A or B. The parent branch of instructions A and B is the root instruction in the instruction set.

[0029] S4. Place the generated configuration file on the system partition of the terminal device.

[0030] Some embodiments disclose a multi-provincial customization system for terminal devices, used to execute a multi-provincial customization method for terminal devices. The customization system includes: Standardize predefined modules; configure them to analyze provincial customization requirements, classify provincial customization parameters, define field specifications for classification parameters, and generate data modeling rule templates; The rule destructuring module is configured to read the data modeling rule template, perform syntax parsing, generate an abstract syntax tree, abstract each component of the data modeling rule template into a node tree, perform atomic transformation on the node tree, and output the resulting rule set as a destructuring rule set. The parsing engine module is configured to parse the received deconstruction rule set and populate the data for different atomized transformation sequences according to the classification. Configuration module; configured to place the generated configuration file externally in the terminal device's system partition.

[0031] Some embodiments disclose an automated deployment method for a multi-provincial customized system applied to terminal devices, including: Trigger the build task of the configuration engine; Automated metadata scanning and analysis; Configuration change decisions determine the configuration file. Typically, configuration change decisions include: if the configuration is updated, compiling the new configuration and writing the resulting configuration file to the corresponding server node; if the configuration is not updated, tracing back to the previous version of the configuration file and registering it to the corresponding server node; and registering the configuration file to the system node. Typically, multi-province customized systems are integrated into terminal devices. When the server allocates resources to the customized system, it triggers the configuration engine's build task, engaging in a series of resource interactions with the server. It performs metadata scanning using the server's owned and configured resources. Metadata analysis typically includes comparing the previous file's hash fingerprint and version number. If it's new data, it's signed and encrypted, and the new configuration file is written to the corresponding server node; if the data is not updated, tracing back to the previous version and registering it to the corresponding server node. The terminal system image is compiled and deployed. Typically, dynamic injection is performed based on the selected corresponding provincial node. The compilation chain puts all the necessary build dependencies into the container for compilation, injects the registered nodes into the system image partition one by one, and after compilation is completed, the image package is automatically deployed to the production repository, thus completing the automated deployment.

[0032] Generally, building dependencies has a dual meaning, which can be further detailed below: First, system-level build dependencies Toolchain: refers to the basic set of tools necessary for compiling an Android system image, such as: specific versions of JDK (Java Development Kit), NDK (Native Development Kit), GCC (GNU Compiler Collection), Python interpreter, and build tools such as Make (GNU Make) and Ninja; Environment and configuration: This includes the source code for a specific version of AOSP (Android Open Source Project), the Hardware Abstraction Layer (HAL) code provided by the device manufacturer, kernel header files, and a series of environment variables and compilation configuration files; these are the cornerstones for building the entire system environment. Second, application-level dependency libraries Third-party libraries refer to external code libraries that are required when compiling built-in applications or system services. These dependencies are typically managed by package management tools (such as Gradle and Maven) and declared in Gradle files (such as the dependencies block in build.gradle). Specific forms include: aar / jar packages in remote repositories (such as Google's AndroidX library, network library, and APIs in the Android system SDK (such as android.jar); In summary, the core action of the compilation process (i.e., 'build') is to incorporate all the aforementioned build dependencies (from toolchain to codebase) into a controllable containerized environment (such as a Docker container) to ensure the consistency, reproducibility, and isolation of the compilation environment. Subsequently, the compilation system (such as the Build system) recursively retrieves, compiles, and links all the necessary code according to the dependency files of each module (such as Android.bp, Android.mk, build.gradle) according to the dependency relationship, and finally generates a complete system image that embeds the customized configuration of the province.

[0033] The present invention discloses a multi-province customization method, a customization system, and an automated deployment method for the customization system applied to terminal devices. These methods achieve dynamic decoupling of customization. An embedded configuration parsing module reads the pre-set configuration files of the system partitions at runtime, parses them in real time, and loads the rules into memory (RAM). A two-stage mechanism of "static configuration during development + dynamic parsing at runtime" completely decouples the strong binding between code and customization logic. Resource consumption is fundamentally optimized; regardless of the number of customized provinces, only a single code compilation is required. The configurations for each province are injected into the system partitions through an automated pipeline, reducing resource overhead from O(N) to O(1), breaking through the linear bottleneck of traditional solutions. Maintenance and management efficiency are significantly improved; customization requirements are only implemented through configuration files, allowing the application layer to focus on general business logic and parsing algorithms. A single codebase supports multi-province customization, simultaneously avoiding the maintenance risks of strongly coupled code and the management burden of multi-branch development, significantly reducing long-term iteration costs.

[0034] The technical details are further illustrated below with reference to the embodiments.

[0035] Example 1 Example 1 discloses a multi-provincial customization method for terminal devices, such as... Figure 1 As shown, it includes: S1. Analyze the customized requirements of each province, classify the customized parameters of each province, define the field specifications of the classified parameters, and generate data modeling rule templates; S2. Read the data modeling rule template, perform syntax parsing, generate an abstract syntax tree, abstract each component of the data modeling rule template into a node tree, perform atomic transformation on the node tree, and output the resulting rule set as a deconstructed rule set. S3. Parse the received deconstruction rule set. During initialization, the application fills in the data for different atomization transformation sequences according to the classification. S4. Place the generated configuration file on the system partition of the terminal device.

[0036] Example 2 Example 2 discloses an automated deployment method for a multi-provincial customized system applied to terminal devices, such as... Figure 2 As shown, it includes: Some embodiments disclose an automated deployment method for a multi-provincial customized system applied to terminal devices, including: Trigger the build task of the configuration engine; Automated metadata scanning and analysis; Decision-making regarding configuration changes; Determine the configuration file. Compile the terminal system image and release it.

[0037] The multi-province customization method for terminal devices disclosed in this invention places the provincial configuration externally in the system partition of the terminal device. When the terminal device is running, it parses the configuration file through the parsing engine module and builds an automated deployment link to automatically deploy the configuration file to the terminal device, which greatly reduces resource waste, improves configuration efficiency, and reduces maintenance costs.

[0038] The technical solutions and technical details disclosed in the embodiments of this invention are merely illustrative of the inventive concept of this invention and do not constitute a limitation on the technical solutions of the embodiments of this invention. Any conventional changes, substitutions, or combinations made to the technical details disclosed in the embodiments of this invention have the same inventive concept as this invention and are within the protection scope of the claims of this invention.

Claims

1. A multi-provincial customization method applied to terminal devices, characterized in that, Including the following steps: S1. Analyze the customized requirements of each province, classify the customized parameters of each province, define the field specifications of the classified parameters, and generate data modeling rule templates; S2. Read the data modeling rule template, perform syntax parsing, generate an abstract syntax tree, abstract each component of the data modeling rule template into a node tree, perform atomic transformation on the node tree, and output the resulting rule set as a deconstructed rule set. S3. Parse the received deconstruction rule set. During initialization, the application fills in the data for different atomization transformation sequences according to the classification. S4. Place the generated configuration file on the system partition of the terminal device.

2. The multi-provincial customization method for terminal devices according to claim 1, characterized in that, In step S1, the parameter categories include UI parameters, functional parameters, and business parameters; In step S2, the node tree includes UI nodes, logic nodes, and business nodes.

3. The multi-provincial customization method for terminal devices according to claim 1, characterized in that, In step S3, after receiving the atomic transformation sequence, the various processing interfaces are loaded, the configuration files for different partition paths are adapted, the serialized data is analyzed and interpreted, the classification of the sequence data is determined by itself, and the data is sent to different rule interpreters for data filling according to different classifications.

4. The multi-provincial customization method for terminal devices according to claim 3, characterized in that, The rule interpreter includes a UI renderer and a logic executor.

5. The multi-provincial customization method for terminal devices according to claim 3, characterized in that, In step S3, if an exception occurs midway, the step will be automatically rolled back, the exception information will be stored in the corresponding memory, the rollback position will be recorded, and default data will be filled in as needed.

6. A multi-provincial customized system applied to terminal devices, used to execute the method of claim 1, characterized in that, include: Standardized predefined modules; Configured to analyze provincial customization requirements, classify provincial customization parameters, define field specifications for classification parameters, and generate data modeling rule templates; Rule destructuring module; The configuration reads the data modeling rule template, performs syntax parsing, generates an abstract syntax tree, abstracts each component of the data modeling rule template into a node tree, performs atomic transformation on the node tree, and outputs the resulting rule set as a deconstructed rule set. The parsing engine module is configured to parse the received deconstruction rule set, populate different atomic transformation sequences with data according to the classification, and generate a configuration file; Configuration module; Configure the generated configuration file to be placed externally on the terminal device's system partition.

7. The automated deployment method for a multi-provincial customized system applied to terminal devices as described in claim 6, characterized in that, include: Trigger the build task of the configuration engine; Automated metadata scanning and analysis; Decision-making regarding configuration changes; Determine the configuration file. Register the configuration file to the system node of the terminal device.

8. The method according to claim 7, characterized in that, Also includes: Compile the terminal system image and release it.

9. The method according to claim 7, characterized in that, The configuration change decision determines the configuration file, including: If the configuration is updated, the new configuration will be compiled and written to the corresponding server node; If the configuration has not been updated, then trace back to the previous version and register the previous version to the corresponding server node.

10. The method according to claim 8, characterized in that, The compilation of the terminal system image includes: dynamic injection based on the selected corresponding provincial node; the compilation chain will put all the necessary build dependencies into the container for compilation; and inject the registered nodes into the system image partition one by one.

Images