Function management methods, devices, electronic devices, and computer-readable storage media

Abstract

This application discloses a function management method, apparatus, electronic device, and computer-readable storage medium, belonging to the field of computer technology. The method includes: in response to receiving a target configuration file, parsing the target configuration file to obtain target configuration parameters for a target system module; and updating the functions of the target system module based on the target configuration parameters. This enables remote dynamic updates of system module functions, extending the depth of function control to the system level, thereby improving the flexibility and maintenance efficiency of configuration management, while also supporting rapid functional iteration after product delivery, enhancing product operational capabilities and user experience.

Description

Technical Field

[0001] This application relates to the field of computer technology, specifically to a function management method, apparatus, electronic device, and computer-readable storage medium. Background Technology

[0002] Existing terminal function management solutions mainly target the application layer, such as controlling the installation and use of Apps (Applications) through whitelist comparison, but they cannot effectively manage the module status at the system level.

[0003] Currently, the functional management of system modules typically requires hard-coding during the development phase. However, this approach is difficult to maintain and cannot be dynamically adjusted after the product leaves the factory. Summary of the Invention

[0004] This application provides a function management method, apparatus, electronic device, and computer-readable storage medium, which can achieve efficient and flexible management of system module functions.

[0005] In a first aspect, embodiments of this application provide a function management method, including: In response to receiving the target configuration file, the target configuration file is parsed to obtain the target configuration parameters of the target system module; The functions of the target system module are updated based on the target configuration parameters.

[0006] In one embodiment, updating the functionality of the target system module based on the target configuration parameters includes: Determine the parameter type of the target configuration parameter; Based on the parameter type and the target configuration parameters, the functionality of the target system module is updated.

[0007] In one embodiment, updating the functionality of the target system module based on the parameter type and the target configuration parameters includes: When the parameter type is a database type, the target configuration parameter is updated to the target database. When the configuration framework detects the target configuration parameter in the target database, it notifies the registered target system module of the target configuration parameter, so that the target system module updates its functions based on the target configuration parameter. When the parameter type is an attribute type, the target configuration parameter is written into the system attribute so that the target system module can read the target configuration parameter from the system attribute and update the function of the target system module based on the target configuration parameter.

[0008] In one embodiment, before parsing the target configuration file to obtain the target configuration parameters of the target system module in response to receiving the target configuration file, the method further includes: In response to receiving the first configuration version information sent from the cloud, obtain the second configuration version information of the terminal; When the first configuration version information is greater than the second configuration version information, the target configuration file is downloaded from the cloud.

[0009] In one embodiment, after updating the functionality of the target system module based on the target configuration parameters, the method further includes: Update the second configuration version information to the first configuration version information.

[0010] In one embodiment, before obtaining the second configuration version information of the terminal in response to receiving the first configuration version information sent from the cloud, the method further includes: When the terminal starts up and / or according to a preset polling cycle, a version query request is sent to the cloud, so that the cloud responds to the version query request and sends the first configuration version information to the terminal.

[0011] In one embodiment, the target configuration file is generated in the following manner: In response to receiving a configuration update request, the historical configuration parameters in the historical configuration file are determined; wherein, the configuration update request includes the target configuration parameters of the target system module; The historical configuration parameters in the historical configuration file are updated to the target configuration parameters to generate the target configuration file.

[0012] Secondly, embodiments of this application provide a function management device, the device comprising: The file parsing module is used to parse the target configuration file in response to receiving the target configuration file, and obtain the target configuration parameters of the target system module; The function update module is used to update the functions of the target system module based on the target configuration parameters.

[0013] In one embodiment, the function update module includes: The type determination submodule is used to determine the parameter type of the target configuration parameter; The function update submodule is used to update the function of the target system module based on the parameter type and the target configuration parameters.

[0014] In one embodiment, the function update submodule includes: The first update unit is used to update the target configuration parameters to the target database when the parameter type is a database type, and to notify the registered target system module of the target configuration parameters when the configuration framework detects the target configuration parameters in the target database, so that the target system module updates the function of the target system module based on the target configuration parameters. The second update unit is used to write the target configuration parameter into the system attribute when the parameter type is an attribute type, so that the target system module can read the target configuration parameter from the system attribute and update the function of the target system module based on the target configuration parameter.

[0015] In one embodiment, the function management device further includes: The information acquisition module is used to acquire the terminal's second configuration version information in response to receiving the first configuration version information sent from the cloud; The file download module is used to download the target configuration file from the cloud when the first configuration version information is greater than the second configuration version information.

[0016] In one embodiment, the function management device further includes: The version update module is used to update the second configuration version information to the first configuration version information.

[0017] In one embodiment, the function management device further includes: The request generation module is used to send a version query request to the cloud when the terminal starts up and / or according to a preset polling period, so that the cloud responds to the version query request and sends the first configuration version information to the terminal.

[0018] In one embodiment, the target configuration file is generated in the following manner: In response to receiving a configuration update request, the historical configuration parameters in the historical configuration file are determined; wherein, the configuration update request includes the target configuration parameters of the target system module; The historical configuration parameters in the historical configuration file are updated to the target configuration parameters to generate the target configuration file.

[0019] Thirdly, embodiments of this application also provide an electronic device, which includes a memory, a processor, and a computer program stored in the memory and executable on the processor. When the computer program is executed by the processor, it implements the steps in the above-described function management method.

[0020] Fourthly, embodiments of this application also provide a computer-readable storage medium storing a computer program, which, when executed by a processor, implements the steps in the above-described function management method.

[0021] Fifthly, embodiments of this application also provide a computer program product or computer program, which includes computer instructions stored in a computer-readable storage medium. A processor of a computer device reads the computer instructions from the computer-readable storage medium and executes the computer instructions, causing the computer device to perform the methods provided in the various optional implementations described in the embodiments of this application.

[0022] In summary, in this embodiment, upon receiving a target configuration file, the target configuration file can be parsed to obtain the target configuration parameters of the target system module, and the functionality of the target system module can be updated based on the target configuration parameters. This enables remote dynamic updates of system module functionality, extending the depth of function control to the system level, thereby improving the flexibility and maintenance efficiency of configuration management. It also supports rapid functional iteration after product delivery, enhancing product operational capabilities and user experience. Attached Figure Description

[0023] To more clearly illustrate the technical solutions in this application, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0024] Figure 1 This is a flowchart illustrating a function management method provided in an embodiment of this application; Figure 2 This is a schematic diagram of a specific embodiment of the function management method provided in this application; Figure 3 This is a schematic diagram of another specific embodiment of the function management method provided in one embodiment of this application; Figure 4 This is a schematic diagram of the architecture of a function management method provided in an embodiment of this application; Figure 5 This is a schematic diagram of the structure of a function management device provided in an embodiment of this application; Figure 6 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Detailed Implementation

[0025] The technical solutions of this application will now be clearly and completely described with reference to the accompanying drawings. Obviously, the described embodiments are merely some embodiments of the present invention, and not all embodiments. All other embodiments obtained by those skilled in the art based on the embodiments of the present invention without creative effort are within the scope of protection of the present invention.

[0026] It should be noted that currently, in smart terminals such as Android systems, there are two common ways to control functional modules: one is to control the application layer (App), such as disabling or enabling the application on the controlled device through the control terminal, or controlling the installation and network access of the application through a whitelist mechanism. This type of solution cannot reach the underlying system modules. The other is to control the system modules, which is usually controlled by developers setting attributes or flags in the code during the development phase to control the function switch. Although this method can achieve a certain degree of module control, attribute management is scattered, maintenance costs are high, and it cannot be dynamically updated remotely after the device leaves the factory.

[0027] As product functions become increasingly complex and personalized needs grow, the ability to flexibly, securely, and traceably adjust system functionality after devices have been deployed to users has become a pressing issue. While some solutions attempt to distribute configurations via the cloud, they primarily focus on application-level parameter settings and lack mechanisms for controlling the status of system-level functional modules.

[0028] To address the current difficulty in managing the functionality of system modules, this application aims to provide a functionality management method. By responding to a received target configuration file, parsing the target configuration file to obtain the target configuration parameters of the target system module, and updating the functionality of the target system module based on these parameters, this method enables remote dynamic updates to system module functionality. This extends the depth of functionality control to the system level, improves the flexibility and maintenance efficiency of configuration management, and supports rapid functional iteration after product release, enhancing product operational capabilities and user experience.

[0029] The following sections provide detailed descriptions of each example. It should be noted that the order in which the embodiments are described is not intended to limit the priority of the embodiments.

[0030] Figure 1 The illustration shows a flowchart of a function management method according to an embodiment of this application. The entity executing the function management method can be a function management device, which can be integrated into any terminal with data processing, network communication, and program execution functions.

[0031] The terminal can be a smartphone, smartwatch, smart home device, tablet, laptop, desktop computer, etc., but is not limited to these.

[0032] In this embodiment, the description will be from the perspective of a function management device, which can be integrated into a terminal. To facilitate the explanation of the function management method of this application, the following will describe the function management device integrated into a terminal in detail, that is, the terminal will be used as the execution subject for detailed explanation.

[0033] Reference Figure 1 The diagram shows a flowchart of a function management method according to this application. The method may specifically include steps S101 to S102, as follows: S101: In response to receiving the target configuration file, parse the target configuration file to obtain the target configuration parameters of the target system module.

[0034] In this embodiment, the target configuration file is a data file used to configure the target system modules of the terminal. This target configuration file is a structured data file, such as a text file using JSON, XML, or a specific format, and contains the target configuration parameters of the target system modules that need to be updated.

[0035] In this embodiment, the target configuration file can be a configuration file actively pushed to the terminal by the cloud, a configuration file actively pulled from the cloud by the terminal when the target conditions are met, or a locally preset or manually imported configuration file.

[0036] In this embodiment, the target system module is a system-level software component in the terminal operating system. The target system module can accept external configuration to change its operating state, functional behavior, or internal parameters. The target system module is typically not a user-installed application, but rather constitutes part of the operating system's basic functions or core services.

[0037] For example, the target system module may include one or more of the following: a system service module, a hardware function management module, a system UI component, and a system-level function switch module. The system service module can provide various services, including multi-language switching. By configuring parameters for the system service module, support for a specific language can be dynamically enabled or disabled without modifying the overall code of the system language settings. The hardware function management module can provide various services, including automatic screen rotation drive services. By configuring parameters, the automatic screen rotation function can be globally disabled or enabled in specific regions or for power saving strategies. The system UI component can provide various services, including customization services for the status bar or navigation bar. By configuring parameters, it can control whether certain shortcut switches (such as a 5G switch or a dark mode switch) are displayed or their layout can be changed. The system-level function switch module can be used to control debugging functions, such as those in developer options. By configuring parameters, certain advanced debugging functions can be disabled by default in the commercial version, but can be remotely enabled for specific user groups as needed.

[0038] In this embodiment, after the target configuration file is detected to have arrived at the terminal, the parser is triggered to parse the target configuration file. For example, the file content can be read according to a predefined format specification, and then the target configuration parameters of the target system module can be extracted.

[0039] In this embodiment, the target configuration file can specifically be a JSON file named `new feature.json`. The target configuration file can include configuration files at different levels; for example, it can specifically include a first configuration file and a second configuration file. The first configuration file is a general-level configuration file, which can specifically be a JSON file named `new common.json`. The second configuration file is a project-level configuration file, which can specifically be a JSON file named `new project.json`. The first configuration file is used to control general-level system functions; the second configuration file is used to control project-level system functions, such as overriding or supplementing specific configuration parameters for a specific product project (e.g., model A, model B, country C version).

[0040] S102: Update the functionality of the target system module based on the target configuration parameters.

[0041] In this embodiment, after parsing the target configuration parameters, the terminal needs to securely and accurately transmit these parameters to the corresponding target system module. In a specific implementation, this can be achieved through inter-process communication (IPC).

[0042] In this embodiment, the target system module may contain one or more system modules, meaning that multiple system modules can be updated synchronously simultaneously. After receiving the target configuration parameters belonging to itself, the target system module will call its internal preset configuration processing logic to update the functionality of the target system module, thereby changing the external behavior and / or internal state of the target system module.

[0043] In this embodiment, when the target system module receives the target configuration parameters, it determines whether a functional update is needed by comparing the target configuration parameters with the original configuration parameters. If the target configuration parameters match the corresponding original configuration parameters in the target system module, it is determined that the function of the target system module will not be updated; if the target configuration parameters do not match the corresponding original configuration parameters in the target system module, it is determined that the function of the target system module will be updated.

[0044] In one example, the target system module includes a Bluetooth fast pairing module, identified as "bluetooth_fast_pair," with a target configuration parameter of "disabled." Upon receiving this parameter, the configuration processing logic of the Bluetooth fast pairing module recognizes that its internal flag is "on." It then updates this flag from "on" to "false." Subsequently, all requests triggering fast pairing will be intercepted and ignored by the Bluetooth fast pairing module, thus effectively disabling the Bluetooth fast pairing function.

[0045] In this embodiment, the solution adopted in this application effectively solves the problem that system functions are fixed during the development stage and cannot be remotely adjusted in traditional solutions. It allows operators or developers to directly distribute target configuration files from the cloud, enabling, disabling, or parameter optimization of specific system functions on a large number of deployed terminals. This greatly improves the flexibility and operability of the product after deployment. Furthermore, when function adjustments are needed, maintenance personnel do not need to delve into the codebase to find hard-coded flags; they only need to modify the configuration file, significantly reducing maintenance difficulty and manpower costs, and minimizing the risk of introducing new errors due to code modifications. On the other hand, compared to OTA (Over-the-Air) upgrade packages that require downloading, installing, and restarting the system, this solution only updates a lightweight target configuration file. Not only is the download speed fast, but the function updates take effect instantly in the background without user intervention or device restart, resulting in a smooth user experience.

[0046] In one feasible implementation, refer to Figure 2 The steps for updating the functionality of the target system module based on the target configuration parameters may specifically include S201~202, as follows: S201: Determine the parameter type of the target configuration parameter.

[0047] In this embodiment, after successfully parsing the target configuration parameters, the terminal will not immediately transmit the target configuration parameters. Instead, it will first initiate a type identification process to identify the parameter type of the target configuration parameters.

[0048] In this embodiment, the parameter type may specifically include database type and attribute type. Database type refers to the parameter type for which the target configuration parameters need to be persistently stored in a structured target database; attribute type refers to the parameter type for which the target configuration parameters need to be written into system attributes managed by the operating system kernel.

[0049] In this implementation, the criteria for determining the parameter type can be built into the structure of the configuration parameters or based on predefined rules. Specifically, a type field can be identified in the target configuration parameters, and the parameter type of the target configuration parameter can be determined based on this type field. For example, a type field named "type" can be designed for each configuration item in the JSON structure of the target configuration file. For example, if the target configuration parameter is: {"module": "bluetooth_fast_pair", "value": "disabled", "type": "property"}, then by identifying "type": "property", the parameter type of the target configuration parameter can be determined to be an "attribute type".

[0050] S202: Update the functionality of the target system module based on parameter type and target configuration parameters.

[0051] In this embodiment, after identifying the parameter type, the terminal invokes the preset update strategy corresponding to that parameter type and updates the functionality of the target system module according to the target configuration parameters based on the preset update strategy. Different parameter types can correspond to different preset update strategies, and each preset update strategy represents a standardized update process for that parameter type.

[0052] In this implementation, by identifying parameter types, the terminal can perform targeted updates for the functions of each target system module, thereby selecting the most suitable underlying communication or storage mechanism. For example, for complex configurations that need to be persisted and may be shared by multiple modules, a database type is used; for simple switches that need to take effect quickly, an attribute type is used. This effectively improves the flexibility and accuracy of function management.

[0053] In one feasible implementation, refer to Figure 3The steps for updating the functionality of the target system module based on parameter type and target configuration parameters may specifically include S301~302, as follows: S301: When the parameter type is database type, update the target configuration parameters to the target database, and when the configuration framework detects the target configuration parameters in the target database, notify the registered target system module of the target configuration parameters so that the target system module can update the function of the target system module based on the target configuration parameters.

[0054] In this embodiment, after determining that the parameter type is a database type, the terminal establishes a connection with a dedicated configuration database on its local machine and updates the target configuration parameters to the target database. This target database serves as a persistent storage center for system configurations and can be stored in non-volatile memory, ensuring that the configuration parameters are not lost after the terminal restarts.

[0055] In this embodiment, the terminal can locate the corresponding record row in the database table based on the module identifier of the target system module, and update the configuration parameters of the record row to the target configuration parameters.

[0056] In this implementation, the ConfigFramework is a standalone system service that can monitor the target database in real time. When the target configuration parameters are updated in the target database, any changes to the database content will immediately trigger the ConfigFramework's monitoring callback. The ConfigFramework can then detect the changed target configuration parameters in the target database within the callback function.

[0057] In this embodiment, the configuration framework maintains a registry that includes all system modules registered with the configuration framework. After detecting target configuration parameters, the configuration framework can identify the target system module from the registry based on the changed module identifier, and then actively push the target configuration parameters to the target system module via inter-process communication (such as Binder).

[0058] In this embodiment, before the configuration framework notifies the registered target system module of the target configuration parameters when it detects the target configuration parameters in the target database, the function management method may further include: registering the target system module in the configuration framework.

[0059] In this implementation, the target system module does not need to poll the target database; it only needs to register a listener with the configuration framework. When the configuration of the target system module changes, the framework can proactively and accurately push updates, enabling the target system module to achieve efficient and real-time updates to its own functions.

[0060] S302: When the parameter type is an attribute type, write the target configuration parameter into the system attribute so that the target system module can read the target configuration parameter in the system attribute and update the function of the target system module based on the target configuration parameter.

[0061] In this embodiment, after determining that the parameter type is an attribute type, the terminal can directly call the Android system's SystemProperties.set() or similar API (Application Programming Interface) to write the target configuration parameter into the system property.

[0062] It's important to note that system properties are a shared memory area accessible to the kernel and all user-space processes. System properties manage global configuration attributes (such as system behavior, hardware features, or debugging options), are loaded by the init process at startup, and their values ​​are primarily stored in memory.

[0063] In this implementation, the read and write operations of system attributes are at the memory level, which is extremely fast and immediately visible to all processes within the system. Therefore, it is suitable for configuration items with extremely high real-time requirements. Because the attributes are globally shared and immediately visible after being written, the target system module can immediately read the target configuration parameters.

[0064] In this implementation, for target configuration parameters of two parameter types—database type and attribute type—two parameter transmission paths can be provided: "database-listener push" and "attribute-active retrieval." The former ensures reliability and consistency, suitable for managing complex, structured configurations that require persistence; the latter achieves ultimate real-time performance and low overhead, suitable for controlling simple function switches or flags. Thus, based on the parameter type, the optimal path can be automatically selected to achieve efficient and flexible updates of the target system module's functionality.

[0065] In one feasible implementation, before parsing the target configuration file to obtain the target configuration parameters of the target system module in response to receiving the target configuration file, the function management method may further include the following steps: in response to receiving the first configuration version information sent by the cloud, obtaining the second configuration version information of the terminal; when the first configuration version information is greater than the second configuration version information, downloading the target configuration file from the cloud.

[0066] In this embodiment, the first configuration version information is the version information of the target configuration file, which is used to represent the latest version status in the cloud; the second configuration version information is the current configuration version information of the terminal, which can read the version information of the local configuration file that was successfully parsed and applied last time, and determine the version information as the second configuration version information.

[0067] In this embodiment, the second configuration version information can be obtained through a local file used to record configuration version information. Specifically, this local file can be an XML format file named config.xml. This local file needs to be persistently stored on the terminal to ensure that after the device restarts, it can still remember which version it last updated to, avoiding duplicate updates or loss of state.

[0068] In this implementation, the terminal logically compares the two version information to determine whether the first configuration version information is greater than the second configuration version information. Only when the comparison result indicates that the first configuration version information is greater than the second configuration version information will the terminal initiate a network request to download the complete target configuration file from the cloud. If the comparison result indicates that the first configuration version information is less than or equal to the second configuration version information, the process terminates, and no download or subsequent update operations are performed.

[0069] In this embodiment, by performing a lightweight version information comparison before downloading the file, the terminal can avoid repeatedly downloading large-scale complete configuration files when there is no need for updates, thereby significantly saving mobile data traffic, reducing the bandwidth pressure on the cloud server and the power consumption of the terminal device.

[0070] In this embodiment, after updating the function of the target system module based on the target configuration parameters, the function management method may further include the following steps: updating the second configuration version information to the first configuration version information.

[0071] In this embodiment, after confirming that the target system module's functionality has been updated based on the target configuration parameters, the terminal overwrites the previously stored second configuration version information with the first configuration version information received from the cloud. This write operation is persistent, ensuring that the updated first configuration version information remains unchanged after a device restart. Thus, after the target system module's functionality is updated, the terminal's local configuration version information and the cloud-based configuration version information can be promptly synchronized.

[0072] It should be noted that the terminal has built-in default configuration files, including a first default configuration file and a second default configuration file. The first default configuration file is a general-level configuration file, which can be a JSON file named `common.json`. The second default configuration file is a project-level configuration file, which can be a JSON file named `project.json`. `common.json` and `project.json` are configuration files pre-installed in the terminal system image. Their main function is to provide a complete and usable set of default configurations for all system modules when the device is first started, before any cloud updates have been performed, or when cloud updates have failed, ensuring the system's most basic functional state.

[0073] In this embodiment, the second configuration version information of the local configuration file can be stored in a database. Each time the terminal starts, it compares the third version information of the default configuration file with the second configuration version information of the local configuration file. If the third version information of the default configuration file is less than or equal to the second configuration version information, the terminal starts according to the local configuration file; if the third version information of the default configuration file is greater than the second configuration version information, the local configuration file is updated based on the default configuration file. Updating the local configuration file based on the default configuration file means updating the configuration information in the default configuration file to the database.

[0074] In this embodiment, after receiving the target configuration file from the cloud, if the first configuration version information of the target configuration file is greater than the second configuration version information of the local configuration file, then after updating the functionality of the target system module based on the target configuration parameters, the local configuration file can be updated based on the target configuration file. Thus, upon the next restart of the terminal, the third version information of the default configuration file will be compared again with the updated second configuration version information of the local configuration file. Since the second configuration version information has been updated to the first configuration version information, the third version information of the default configuration file will be less than the second configuration version information. Therefore, the terminal will start according to the updated latest version of the local configuration file, enabling the target system to implement the latest functionality after the terminal starts.

[0075] In this embodiment, by timely updating the second configuration version information to the first configuration version information, it is ensured that the same version of the configuration file will not be mistakenly identified as a new version by the terminal and repeatedly downloaded, parsed and applied. This fundamentally eliminates invalid repeated download operations, thereby protecting system resources. At the same time, it ensures that the terminal can always run the latest configuration file, thereby guaranteeing the stability of function updates.

[0076] In this embodiment, before obtaining the second configuration version information of the terminal in response to receiving the first configuration version information sent by the cloud, the function management method may further include the following steps: sending a version query request to the cloud when the terminal starts up and / or according to a preset polling cycle, so that the cloud responds to the version query request and sends the first configuration version information to the terminal.

[0077] In this embodiment, after the terminal's operating system completes the core boot process, it receives a system-broadcast boot completion event. In response to this event, the terminal immediately generates a version query request or, after a very short, fixed delay following boot, sends the version query request to a pre-defined cloud server address via an activated network connection (such as Wi-Fi or mobile data). This version query request is used to proactively obtain the current first configuration version information from the cloud.

[0078] In this embodiment, by utilizing the inevitable lifecycle node of terminal startup, it can be ensured that the status can be synchronized with the cloud immediately after each device restart, and that there are no new target configuration files published during the device shutdown period, thereby ensuring that the terminal has the latest configuration every time it enters the working state.

[0079] In this embodiment, the terminal can also maintain a timer with a preset polling period, such as 12 hours. The terminal will send a version query request to the cloud every 12 hours. Whenever the timer expires, as long as the terminal's network is available, the terminal will automatically send a version query request. After sending the version query request, the timer will reset and start the next cycle.

[0080] In this embodiment, by adopting a polling mechanism, cloud updates can be checked periodically and automatically during continuous terminal operation, making up for the update delay vulnerability that may exist if only the startup check is performed, thereby avoiding the situation where the target configuration file cannot be obtained if the terminal is not restarted for a long time.

[0081] In this implementation, the polling period can be set according to actual business needs. For example, for configurations with high real-time requirements, the corresponding polling period can be shortened.

[0082] In this embodiment, the step of sending a version query request to the cloud according to a preset polling cycle may specifically include: determining the actual polling time point based on the polling cycle and a preset random time offset; and sending a version query request to the cloud at the actual polling time point.

[0083] In this implementation, by combining random latency with the polling mechanism, the request traffic in the cloud can be smoothed, avoiding traffic peaks at specific times (such as the hour), thereby improving the stability and scalability of cloud services.

[0084] In this implementation, the two mechanisms of startup update and polling update complement each other, enabling configuration updates not only at the terminal's startup node but also periodically during terminal operation. This significantly reduces the probability of missing critical configuration updates; simultaneously, it allows configuration updates to adapt to different network environments and service requirements, enhancing the system's reliability and adaptability.

[0085] In one feasible implementation, the target configuration file can be generated as follows: in response to receiving a configuration update request, the historical configuration parameters in the historical configuration file are determined; wherein the configuration update request includes the target configuration parameters of the target system module; the historical configuration parameters in the historical configuration file are updated to the target configuration parameters to generate the target configuration file.

[0086] In this embodiment, the executing entity can be the cloud, specifically a cloud server. The cloud server can be an independent physical server, a server cluster or distributed system composed of multiple physical servers, or a cloud server providing basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communication, middleware services, domain name services, security services, Content Delivery Network (CDN), and big data and artificial intelligence platforms. The server can connect directly or indirectly to one or more terminals via wired or wireless communication; this application does not impose any limitations on this.

[0087] In this embodiment, the configuration update request can come from the management terminal. For example, the configuration update request can be a configuration update request submitted by the function owner through the JIRA (a workflow management platform) system.

[0088] In this implementation, before submitting a configuration update request to the JIRA system, the function owner can review the configuration update request to determine whether it is a push request for the latest software. If the configuration update request is a push request for the latest software, regression code is performed on the target configuration parameters of the target system module in the configuration update request. If the configuration update request is not a push request for the latest software, regression code is not performed on the target configuration parameters.

[0089] It's important to note that regression code refers to code regression testing, which involves performing regression tests on the target configuration parameters before pushing the configuration to the cloud. When pushing a latest, actively developed software version to the cloud, the development team needs to perform a round of regression testing. By performing regression code, it can be ensured that the configuration changes distributed via the cloud will not have any unexpected negative impacts on other existing functions of the system (i.e., "regression defects").

[0090] In this implementation, the cloud can find the corresponding historical configuration file in the version management repository based on the target configuration parameters of the target system module in the configuration update request. This historical configuration file is a file stored in the cloud containing all currently effective configurations for the terminal. By parsing this historical configuration file, the cloud can locate and extract the historical configuration parameters corresponding to the target configuration parameters from the historical configuration file.

[0091] In this implementation, the cloud can manipulate the data structure of the historical configuration file in memory, directly replacing the values ​​of the located historical configuration parameters with the values ​​of the target configuration parameters carried in the configuration update request. After completing the replacement, the cloud can serialize the modified configuration data (e.g., convert it to a JSON string) to generate a completely new file, namely the target configuration file. Simultaneously, the target configuration file is assigned the latest first configuration version information.

[0092] In this implementation, by updating the historical configuration parameters in the historical configuration file to the target configuration parameters, rather than creating a completely new configuration from scratch, minimal modifications can be made based on the existing configuration. This ensures that the configurations of all other system modules not mentioned in this request remain unchanged and are inherited.

[0093] In this implementation, the cloud only needs to make partial modifications to existing historical configuration files based on configuration update requests to generate the latest target configuration file. This effectively avoids regenerating the entire configuration for the entire system each time, thus saving server computing resources and reducing the overhead of configuration data generation and transmission. Simultaneously, it allows function owners or operations personnel to focus on and submit the configuration parameters that need to be changed, without needing to worry about and copy all unchanged configurations, thereby significantly reducing the complexity of manual operations and the probability of errors, making it particularly suitable for large-scale, multi-module configuration management.

[0094] For example, refer to Figure 4 The diagram illustrates the architecture of the function management method. Based on this architecture, the function management method can be divided into the following four operational phases: Local configuration loading phase: After the terminal boots up, the system service (SystemServer) starts and initializes services such as the global configuration (ConfigProvider). The global configuration reads and parses the default configuration file pre-installed in the system image to obtain all system modules (Features) that support cloud push and their default configuration parameters, serving as the configuration baseline. The global configuration reads and parses the pre-installed project.json file in the default configuration file and compares the version of project.json with the local configuration version. If the version of project.json is higher, its configuration content is overwritten on the corresponding configuration items in the local configuration version, forming the final local default configuration for the terminal.

[0095] In the target configuration file generation phase: The Feature Owner submits a configuration update request through the JIRA system, specifying the target configuration parameters of the target system module that need to be updated. Simultaneously, the Feature Owner can also submit the target configuration parameters of the target system module to a code repository management platform, such as GitWeb. The JIRA system reviews and manages the configuration update request, and after approval, sends the configuration update request to the cloud.

[0096] Target configuration file retrieval phase: After network availability, the terminal's global configuration can proactively initiate a version query request to the cloud, either after a device reboot or according to a preset polling cycle, and obtain the first configuration version information from the cloud. Simultaneously, the global configuration reads the second configuration version information of the last successfully updated local configuration file recorded in the local `config.xml` file. If the first configuration version information is greater than the second configuration version information, the target configuration file (new_feature.json) is downloaded from the cloud. Otherwise, the process ends at this polling stage.

[0097] The target system module's functional update phase involves the terminal's global configuration parsing and downloading of the `new_feature.json` file. This process yields the target configuration parameters and their types for each target system module (including Feature A, Feature B, Feature C, and Feature D). When the parameter type is `database`, the target configuration parameters belonging to `database` are updated in the target database. This target database can be a ContentProvider. The ConfigFramework monitors changes to the ContentProvider database in real time and, upon detecting updates to the configuration data of Feature A, Feature B, and Feature C, immediately notifies all corresponding functional modules (i.e., Feature A, Feature B, and Feature C) that have registered with it for monitoring. When the parameter type is `prop`, the target configuration parameters belonging to `prop` are written to system properties. Feature D can then retrieve the corresponding target configuration parameters from the system properties using the system property retrieval interface (e.g., `SystemProperties.get`). After obtaining the updated target configuration parameters, Features A, B, C, and D will immediately apply the updated target configuration parameters to update their own functions, thereby dynamically changing their operating status. For example, they can enable, disable, or adjust the working mode of the target system module.

[0098] In summary, the technical solution adopted in this application embodiment enables remote, dynamic, and unified control over the status of system-level functional modules. It overcomes the limitations of existing technologies that can only statically control the application layer or rely on pre-defined attributes in the code. It allows configurations to be directly distributed through the cloud after the product leaves the factory, dynamically enabling, disabling, or modifying the operating parameters of system modules. This greatly improves the flexibility of software function maintenance, reduces operation and maintenance costs, and enables users to obtain timely function updates and optimization experiences. At the same time, the security and reliability of the update process are ensured through multi-layer configuration management and version control mechanisms.

[0099] To facilitate better implementation of the function management method of this application, this application also provides a function management device based on the above-described function management method. The meanings of the terms used are the same as in the function management method described above, and specific implementation details can be found in the descriptions of the method embodiments.

[0100] Based on the same inventive concept, and referring to Figure 5This application provides a function management device 500, which includes: The file parsing module 501 is used to parse the target configuration file in response to receiving the target configuration file, and obtain the target configuration parameters of the target system module. Function update module 502 is used to update the functions of the target system modules based on the target configuration parameters.

[0101] In one embodiment, the function update module 502 includes: The type determination submodule is used to determine the parameter type of the target configuration parameters; The Function Update submodule is used to update the functionality of the target system module based on parameter type and target configuration parameters.

[0102] In one embodiment, the function update submodule includes: The first update unit is used to update the target configuration parameters to the target database when the parameter type is database type. When the configuration framework detects the target configuration parameters in the target database, it notifies the registered target system module of the target configuration parameters so that the target system module can update the target system module's functions based on the target configuration parameters. The second update unit is used to write the target configuration parameters into the system properties when the parameter type is an attribute type, so that the target system module can read the target configuration parameters in the system properties and update the function of the target system module based on the target configuration parameters.

[0103] In one embodiment, the function management device 500 further includes: The information acquisition module is used to acquire the terminal's second configuration version information in response to receiving the first configuration version information sent from the cloud; The file download module is used to download the target configuration file from the cloud when the first configuration version information is greater than the second configuration version information.

[0104] In one embodiment, the function management device 500 further includes: The version update module is used to update the second configuration version information to the first configuration version information.

[0105] In one embodiment, the function management device 500 further includes: The request generation module is used to send a version query request to the cloud when the terminal starts up and / or according to a preset polling cycle, so that the cloud responds to the version query request and sends the first configuration version information to the terminal.

[0106] In one embodiment, the target configuration file is generated in the following manner: In response to receiving a configuration update request, determine the historical configuration parameters in the historical configuration file; wherein, the configuration update request includes the target configuration parameters of the target system module; Update the historical configuration parameters in the historical configuration file to the target configuration parameters to generate the target configuration file.

[0107] The technical solution adopted in this application effectively solves the problem that system functions are fixed during the development stage and cannot be remotely adjusted in traditional solutions. It allows operators or developers to directly distribute target configuration files from the cloud, enabling, disabling, or parameter optimization of specific system functions on a large number of deployed terminals. This greatly improves the flexibility and operability of the product after deployment. Furthermore, when function adjustments are needed, maintenance personnel do not need to delve into the codebase to find hard-coded flags; they only need to modify the configuration file, significantly reducing maintenance difficulty and manpower costs, and minimizing the risk of introducing new errors due to code modifications. On the other hand, compared to OTA (Over-the-Air) upgrade packages that require downloading, installing, and restarting the system, this solution only updates a lightweight target configuration file. Not only is the download speed fast, but the function updates take effect instantly in the background without user intervention or device restart, resulting in a smooth user experience.

[0108] Specific limitations regarding the function management device 500 can be found in the limitations of the function management method described above, and will not be repeated here. Each module in the aforementioned function management device 500 can be implemented entirely or partially through software, hardware, or a combination thereof. These modules can be embedded in or independent of the processor in the computer device in hardware form, or stored in the memory of the computer device in software form, so that the processor can call and execute the operations corresponding to each module.

[0109] In addition, this application also provides an electronic device, such as Figure 6 As shown, it illustrates the structural diagram of the electronic device involved in this application, specifically: The electronic device may include components such as a processor 601 with one or more processing cores and a memory 602 with one or more computer-readable storage media. Those skilled in the art will understand that... Figure 6 The electronic device structure shown does not constitute a limitation on the electronic device and may include more or fewer components than shown, or combine certain components, or have different component arrangements. Wherein: The processor 601 is the control center of the electronic device. It connects various parts of the electronic device via various interfaces and lines, and performs various functions and processes data by running or executing software programs and / or modules stored in the memory 602, and by calling data stored in the memory 602, thereby providing overall monitoring of the electronic device. Optionally, the processor 601 may include one or more processing cores; preferably, the processor 601 may integrate an application processor and a modem processor, wherein the application processor mainly handles the operating system, user interface, and applications, and the modem processor mainly handles wireless communication. It is understood that the modem processor may not be integrated into the processor 601.

[0110] The memory 602 can be used to store software programs and modules. The processor 601 executes various functional applications and data processing by running the software programs and modules stored in the memory 602. The memory 602 may mainly include a program storage area and a data storage area. The program storage area may store the operating system, application programs required for at least one function (such as sound playback function, image playback function, etc.), etc.; the data storage area may store data created according to the use of the electronic device, etc. In addition, the memory 602 may include high-speed random access memory, and may also include non-volatile memory, such as at least one disk storage device, flash memory device, or other volatile solid-state storage device. Accordingly, the memory 602 may also include a memory controller to provide the processor 601 with access to the memory 602.

[0111] In one feasible implementation, the electronic device further includes a power supply 603 that supplies power to the various components. Preferably, the power supply 603 can be logically connected to the processor 601 through a power management system, thereby enabling functions such as charging, discharging, and power consumption management through the power management system. The power supply 603 may also include one or more DC or AC power supplies, recharging systems, power equipment debugging circuits, power converters or inverters, power status indicators, and other arbitrary components.

[0112] In one feasible implementation, the electronic device may further include an input unit 604, which can be used to receive input digital or character information and generate keyboard, mouse, joystick, optical or trackball signal inputs related to user settings and function control.

[0113] Although not shown, the electronic device may also include a display unit, etc., which will not be described in detail here. Specifically, in this embodiment, the processor 601 in the electronic device loads the executable files corresponding to the processes of one or more applications into the memory 602 according to the following instructions, and the processor 601 runs the applications stored in the memory 602, thereby realizing the steps in any of the function management methods provided in the embodiments of this application.

[0114] Those skilled in the art will understand that Figure 6 The structure shown is merely a block diagram of a portion of the structure related to the present application and does not constitute a limitation on the electronic device to which the present application is applied. The specific electronic device may include more or fewer components than shown in the figure, or combine certain components, or have different component arrangements.

[0115] In one feasible implementation, an electronic device is provided, including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement the methods described in any embodiment of this application.

[0116] In one feasible implementation, a computer-readable storage medium is provided having a computer program stored thereon, which, when executed by a processor, implements the methods described in any embodiment of this application.

[0117] In one feasible implementation, a computer program product is also proposed, comprising a computer program or instructions that, when executed by a processor, implement the methods described in any embodiment of this application.

[0118] For details on the implementation of each of the above operations, please refer to the previous examples, which will not be repeated here.

[0119] Those skilled in the art will understand that all or part of the steps in the various methods of the above embodiments can be performed by instructions, or by instructions controlling related hardware. These instructions can be stored in a computer-readable storage medium and loaded and executed by a processor.

[0120] Therefore, this application provides a computer-readable storage medium storing a computer program that can be loaded by a processor to execute the steps of any of the function management methods provided in this application.

[0121] For details on the implementation of each of the above operations, please refer to the previous examples, which will not be repeated here.

[0122] The computer-readable storage medium may include: read-only memory (ROM), random access memory (RAM), disk or optical disk, etc.

[0123] Since the instructions stored in the computer-readable storage medium can execute the steps of any of the function management methods provided in this application, the beneficial effects that any of the function management methods provided in this application can achieve can be realized, as detailed in the preceding embodiments, and will not be repeated here.

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

[0125] The above provides a detailed description of a function management method, apparatus, electronic device, and computer-readable storage medium provided in this application. Specific examples have been used to illustrate the principles and implementation methods of the present invention. The description of the above embodiments is only for the purpose of helping to understand the method and core ideas of the present invention. At the same time, those skilled in the art will recognize that there will be changes in the specific implementation methods and application scope based on the ideas of the present invention. Therefore, the content of this specification should not be construed as a limitation of the present invention.

Claims

1. A function management method, characterized in that, The method includes: In response to receiving the target configuration file, the target configuration file is parsed to obtain the target configuration parameters of the target system module; The functions of the target system module are updated based on the target configuration parameters.

2. The function management method according to claim 1, characterized in that, The update of the function of the target system module based on the target configuration parameters includes: Determine the parameter type of the target configuration parameter; Based on the parameter type and the target configuration parameters, the functionality of the target system module is updated.

3. The function management method according to claim 2, characterized in that, The step of updating the functionality of the target system module based on the parameter type and the target configuration parameters includes: When the parameter type is a database type, the target configuration parameter is updated to the target database. When the configuration framework detects the target configuration parameter in the target database, it notifies the registered target system module of the target configuration parameter, so that the target system module updates its functions based on the target configuration parameter. When the parameter type is an attribute type, the target configuration parameter is written into the system attribute so that the target system module can read the target configuration parameter from the system attribute and update the function of the target system module based on the target configuration parameter.

4. The function management method according to claim 1, characterized in that, Before the step of receiving the target configuration file, parsing the target configuration file, and obtaining the target configuration parameters of the target system module, the method further includes: In response to receiving the first configuration version information sent from the cloud, obtain the second configuration version information of the terminal; When the first configuration version information is greater than the second configuration version information, the target configuration file is downloaded from the cloud.

5. The function management method according to claim 4, characterized in that, After updating the functionality of the target system module based on the target configuration parameters, the method further includes: Update the second configuration version information to the first configuration version information.

6. The function management method according to claim 4, characterized in that, Before obtaining the second configuration version information of the terminal in response to receiving the first configuration version information sent from the cloud, the method further includes: When the terminal starts up and / or according to a preset polling cycle, a version query request is sent to the cloud, so that the cloud responds to the version query request and sends the first configuration version information to the terminal.

7. The function management method according to claim 1, characterized in that, The target configuration file is generated in the following way: In response to receiving a configuration update request, the historical configuration parameters in the historical configuration file are determined; wherein, the configuration update request includes the target configuration parameters of the target system module; The historical configuration parameters in the historical configuration file are updated to the target configuration parameters to generate the target configuration file.

8. A function management device, characterized in that, The device includes: The file parsing module is used to parse the target configuration file in response to receiving the target configuration file, and obtain the target configuration parameters of the target system module; The function update module is used to update the functions of the target system module based on the target configuration parameters.

9. An electronic device, characterized in that, It includes a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement the steps of the function management method as described in any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program that, when executed by a processor, implements the steps of the function management method as described in any one of claims 1 to 7.

Images