Function management method and device, electronic equipment and computer readable storage medium

Abstract

The embodiment of the invention discloses a function management method and device, electronic equipment and a computer readable storage medium, and belongs to the technical field of computers. The method comprises the following steps: in response to a received configuration file, analyzing the configuration file to obtain a target attribute and a file type of the configuration file; based on the file type, determining a target local layer module in the registered local layer modules; and updating the function of the target local layer module based on the target attribute. Thus, on the premise that the local layer module does not need to be recompiled, targeted updating of the function of the target local layer module can be achieved, then flexible and efficient management of the function of the local layer module is achieved, the updating efficiency is greatly improved, and user experience is prevented from being affected.

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] Native modules are modules developed using C and C++ languages ​​in the native layer. Updating a native module requires modifying its code and recompiling it.

[0003] Since user devices lack a compilation environment, updating the functionality of local modules already deployed on user devices can currently only be done through system self-upgrades. This method requires recompiling the version, which is inefficient, and the upgrade process necessitates restarting the user device, severely impacting the user experience. Summary of the Invention

[0004] This application provides a function management method, apparatus, electronic device, and computer-readable storage medium that enable efficient and flexible management of the functions of local layer modules.

[0005] In a first aspect, embodiments of this application provide a function management method, including: In response to receiving a configuration file, the configuration file is parsed to obtain the target attributes and the file type of the configuration file; Based on the file type, the target local layer module is determined from the registered local layer modules; Based on the target attributes, the functionality of the target local layer module is updated.

[0006] In one embodiment, determining the target local layer module among the registered local layer modules based on the file type includes: The target local layer module is determined by a customized feature attribute management service based on the file type and the pre-defined correspondence between the file type and the registered local layer module.

[0007] In one embodiment, before determining the target local layer module based on the file type and the preset correspondence between file types and registered local layer modules through a customized feature attribute management service, the method further includes: In response to a registration request sent by any local layer module to the customized feature attribute management service, the module type of the local layer module and the file types supported by the local layer module are obtained; When the module type is a preset type and the local layer module has a system user identifier, the local layer module is registered to the customized feature attribute management service, and the correspondence between the local layer module and the file type is saved in the customized feature attribute management service.

[0008] In one embodiment, updating the functionality of the target local layer module based on the target attribute includes: Send the target attribute to the customized feature attribute management service; The target attribute is sent to the target local layer module through the customized feature attribute management service, so that the target local layer module can adjust the on / off state of the target local layer module's functions based on the target attribute.

[0009] In one embodiment, the step of responding to receiving a configuration file and parsing the configuration file to obtain target attributes and the file type of the configuration file includes: In response to receiving a configuration file, obtain the first version information of the configuration file and the second version information of the local configuration file; When the first version information is greater than the second version information, the configuration file is parsed to obtain the target attribute and the file type of the configuration file.

[0010] In one embodiment, parsing the configuration file to obtain the target attribute includes: Parse the configuration data to obtain the attribute configuration data; Obtain the attribute name from the attribute configuration data; When the attribute name includes a target identifier, the attribute corresponding to the attribute name is determined as the target attribute.

[0011] In one embodiment, the configuration file is generated in the following manner: Obtain the requirement description information; Based on the aforementioned requirement description information, the target attributes of the target local layer module are determined; The configuration file is generated based on the target attributes of the target local layer module.

[0012] Secondly, embodiments of this application provide a function management device, the device comprising: The parsing module is used to parse the configuration file in response to receiving the configuration file, and obtain the target attributes and the file type of the configuration file; The determination module is used to determine the target local layer module among the registered local layer modules based on the file type; An update module is used to update the functionality of the target local layer module based on the target attributes.

[0013] In one embodiment, the determining module is specifically used to determine the target local layer module based on the file type and the preset correspondence between the file type and the registered local layer module through a customized feature attribute management service.

[0014] In one embodiment, the function management device further includes: The type acquisition module is used to obtain the module type of the local layer module and the file types supported by the local layer module in response to a registration request sent by any local layer module to the customized feature attribute management service. The module registration module is used to register the local layer module to the customized feature attribute management service when the module type is a preset type and the local layer module has a system user identifier, and to save the correspondence between the local layer module and the file type in the customized feature attribute management service.

[0015] In one embodiment, the update module includes: The attribute sending submodule is used to send the target attribute to the customized feature attribute management service; The attribute update submodule is used to send the target attribute to the target local layer module through the customized feature attribute management service, so that the target local layer module can adjust the on / off state of the target local layer module's functions based on the target attribute.

[0016] In one embodiment, the parsing module includes: The version acquisition submodule is used to obtain the first version information of the configuration file and the second version information of the local configuration file in response to receiving the configuration file; The version comparison submodule is used to parse the configuration file when the first version information is greater than the second version information, and obtain the target attribute and the file type of the configuration file.

[0017] In one embodiment, the parsing module includes: The file parsing submodule is used to parse the configuration data to obtain attribute configuration data; The name retrieval submodule is used to retrieve the attribute name from the attribute configuration data; The attribute determination submodule is used to determine the attribute corresponding to the attribute name as the target attribute when the attribute name includes the target identifier.

[0018] In one embodiment, the configuration file is generated in the following manner: Obtain the requirement description information; Based on the aforementioned requirement description information, the target attributes of the target local layer module are determined; The configuration file is generated based on the target attributes of the target local layer module.

[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, by responding to the received configuration file and parsing it to obtain the target attributes and the file type of the configuration file, the target local layer module can be determined among the registered local layer modules based on the file type. Then, based on the target attributes, the functionality of the target local layer module can be updated. This allows for targeted updates to the functionality of the target local layer module without recompiling it, thereby achieving flexible and efficient management of the local layer module's functionality, greatly improving update efficiency and avoiding impact on 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 flowchart illustrating a specific embodiment of the registration local layer module provided in this application; Figure 3This is a schematic diagram of the architecture of a function management method provided in an embodiment of this application; Figure 4 This is a schematic diagram of the architecture of a configuration file change notification provided in one 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 only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0026] 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 electronic device with data processing, network communication, and program execution functions. The electronic device can be a server or a terminal, etc.

[0027] The server can be a standalone physical server, a server cluster or distributed system composed of multiple physical servers, or a cloud server that provides 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, network acceleration services (Content Delivery Network, CDN), as well as big data and artificial intelligence platforms.

[0028] The terminal can be a smartphone, tablet, laptop, in-vehicle computer, desktop computer, smart home device, etc., but is not limited to these. The terminal and the server can be connected directly or indirectly through wired or wireless communication, which is not limited herein.

[0029] Furthermore, in the embodiments of this application, "multiple" refers to two or more. The terms "first" and "second," etc., in the embodiments of this application are used for distinguishing descriptions and should not be construed as implying relative importance.

[0030] 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 preferred order of the embodiments.

[0031] In this embodiment, the description will be from the perspective of a function management device, which can be integrated into a server or 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.

[0032] 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 S103, as follows: S101: In response to receiving the configuration file, parse the configuration file to obtain the target attributes and the file type of the configuration file.

[0033] In this embodiment, the configuration file is a data file used to configure the local layer modules. This configuration file is a structured data file, such as a text file in JSON, XML, or a specific format, and its content defines the functional attributes and values ​​of the local layer modules that need to be updated. This configuration file can originate from an update package pushed by a cloud server, or it can be a pre-installed local file or a manually imported file.

[0034] In this embodiment, target attributes refer to data information in the configuration file used to control the functional state of the target local layer module. The data format of the target attributes can be a basic data type format (such as string, number, boolean value, or enumeration), a structured data format (such as key-value pairs, lists, or nested structures), or a configuration file format (such as JSON files, XML files, or YAML files). This application embodiment does not require this.

[0035] In this embodiment, the target attribute may include attributes at multiple levels. These multiple levels may include, but are not limited to, software, hardware, and service layers.

[0036] In this embodiment, the target attributes of the software layer may include, but are not limited to: operating system attributes, pre-installed application attributes, user interface attributes, and security attributes. Customizing the operating system attribute can involve customizing different operating systems for different electronic devices; for example, some electronic devices may be customized to use the native Android system, while others may be customized to use the Apple iOS operating system. Customizing the pre-installed application attribute can involve pre-installing different applications on different electronic devices; for example, some electronic devices may have a map application pre-installed, while others may not. Customizing the user interface attribute can involve customizing different themes, fonts, and / or wallpapers for different electronic devices; for example, some electronic devices may have a red wallpaper, while others may have a green wallpaper. Customizing the security attribute can involve customizing different permission management schemes and / or anti-harassment functions for different electronic devices; for example, some electronic devices may only block calls from restricted numbers, while others may block both calls and SMS messages from restricted numbers.

[0037] In this embodiment, the hardware layer target attributes may include, but are not limited to, processor attributes, storage (ROM) attributes, and / or sensor attributes. Customizing processor attributes can involve tailoring different processors for different electronic devices, such as customizing the number of processor cores to 4, 6, or 8 cores. Different numbers of processor cores may lead to different task processing logic in the electronic device, thus customization of the processor attributes at the hardware layer may result in corresponding changes to the functionality of the local layer module of the electronic device. Customizing storage attributes can involve customizing different storage capacities and / or interface types for different electronic devices, such as customizing the storage capacity to 512GB or 1TB. Different storage capacities may lead to differences in the functionality and performance of the electronic device, which in turn may result in corresponding changes to the functionality of the local layer module. Customizing sensor attributes can involve customizing different sensors for different electronic devices, such as using a fingerprint sensor or a facial recognition sensor for unlocking the electronic device. Different sensor attributes may result in corresponding changes to the functionality of the local layer module of the electronic device.

[0038] In this embodiment, the target attributes of the service layer may include, but are not limited to, subscription attributes and / or cloud service attributes. Customizing subscription attributes can involve tailoring different subscription services to different electronic devices. For example, one could customize the subscription service for a first video platform and / or a second video platform. When customizing different subscription services, the local layer module of the electronic device may need to implement interface functionality with different video platforms. Customizing cloud service attributes can involve tailoring different cloud services to different electronic devices. For example, one could customize the automatic storage of photos and / or memos in the cloud. When customizing different subscription services, the local layer module of the electronic device may need to implement the functionality of retrieving files from different file storage paths.

[0039] It's important to note that native layer modules refer to modules developed using C and C++ languages ​​within the native layer. The native layer is a relatively low level of the system architecture, adjacent to the hardware driver layer and the operating system kernel. The native layer is primarily developed using C and C++, languages ​​known for their high performance and direct hardware access capabilities. Native layer modules can interact directly with the hardware driver layer and the operating system kernel, reducing intermediate layer overhead and significantly improving performance. Therefore, the native layer can handle extremely performance-intensive tasks such as graphics rendering and multimedia processing (audio and video encoding / decoding, image recognition). When dealing with performance-critical tasks like graphics rendering and multimedia processing, native layer modules can respond and process data quickly, ensuring smooth system operation.

[0040] In this embodiment, modules can be divided based on multiple dimensions such as module function, hardware access, or performance optimization. For example, based on module function, modules can be divided into image recognition modules or audio / video encoding / decoding modules; based on hardware access, modules can be divided into modules that interact with sensors or storage access modules; and based on performance optimization, modules can be divided into high-performance computing modules or real-time processing modules. A local layer module may be an image recognition module when divided based on module function; a storage access module when divided based on hardware access; and a high-performance computing module when divided based on performance optimization.

[0041] In this embodiment, the local layer module can be a graphics rendering module used to render graphics. For example, the local layer graphics rendering module can be used to achieve real-time rendering of complex scenes in 3D games.

[0042] In this embodiment, the local layer module can be a multimedia processing module used to process image data and audio / video data. For example, through the local layer multimedia processing module, audio and video data can be encoded and decoded in real time during video calls to ensure smooth calls.

[0043] In this embodiment, the local layer module can be a module that interacts with the sensor. For example, the module that interacts with the sensor through the local layer can read the sensor data and perform corresponding data processing based on the sensor data.

[0044] In this embodiment, after a new configuration file is detected to have arrived at the terminal, the parser is triggered to parse the configuration file in order to read the file content according to the predefined format specifications, and then extract the target attributes and the file type of the configuration file.

[0045] S102: Based on file type, determine the target local layer module among the registered local layer modules.

[0046] In this embodiment, the local layer module refers to a functional module registered in the terminal management service. This terminal management service manages the attributes of the local layer module. If the terminal management service receives a target attribute, it indicates that the attribute has changed. This change may be due to the customer customizing different attributes, or it may be due to the developers adjusting the attributes of the electronic device. The target attribute can include customized attributes and non-customized attributes. Customized attributes are attributes or features of the terminal that can be customized; they can be obtained by customizing the attributes or features of software, hardware, services, etc., according to the needs of customers, users, or specific scenarios.

[0047] In this implementation, each local layer module declares the file types it can handle during registration. The target local layer module is the registered module instance that matches the currently parsed file type.

[0048] In this implementation, a registry can be maintained within the customized feature attribute management service. This registry records the mapping relationship between the identifier of each local layer module and the file types it supports. After obtaining the parsed file type, this registry can be queried to find the target local layer module that supports that file type through string matching or identifier comparison.

[0049] In this implementation, each file type can correspond to a unique local layer module to ensure that configuration updates are targeted.

[0050] It's important to note that if the target attribute is broadcast to all local layer modules, each module needs to determine whether the target attribute corresponds to its own attribute and decide whether to update the attribute based on the result. For example, if the result indicates that the target attribute does not correspond to a local layer module, then the target attribute should be ignored. Therefore, matching the target local layer module based on file type effectively avoids this situation, enabling targeted delivery of configuration updates and providing specific updates to the target local layer module. This avoids the invalid processing and security issues associated with broadcasting the target attribute to all local layer modules.

[0051] S103: Update the functionality of the target local layer module based on the target attributes.

[0052] It should be noted that the functionality of native layer modules developed in C and C++ is controlled through attributes, and there is a corresponding relationship between the functionality and attributes of the native layer modules. Before the terminal is customized, the attributes of the native layer modules are adapted to the configuration of the electronic device before customization; when the terminal is customized in different ways, the target attributes of the terminal will also change accordingly.

[0053] In this embodiment, when the target local layer module receives a target attribute, it determines whether to update the target local layer module's attribute by comparing whether the target attribute is consistent with the original attribute. If the target attribute is consistent with the corresponding attribute in the target local layer module, it is determined that the target local layer module's attribute will not be updated; if the target attribute is inconsistent with the corresponding attribute in the target local layer module, it is determined that the target local layer module's attribute will be updated.

[0054] For example, the functionality of the target local layer module was originally designed for the Android operating system, and correspondingly, the operating system attribute of the target local layer module was originally the Android operating system attribute. When the terminal's operating system changes from Android to iOS, and the terminal's operating system attribute changes, the customized feature attribute management service can receive the changed iOS operating system attribute. The customized feature attribute management service sends a callback notification of the iOS operating system attribute to the target local layer module. By comparing the received iOS operating system attribute with its original Android operating system attribute, the target local layer module can know that its attributes have been updated. To avoid compatibility issues, the target local layer module may adjust its API interface functions and / or permission management functions to adapt to the changed iOS operating system.

[0055] The technical solution adopted in this application overcomes the shortcomings of traditional solutions where the functions of local layer modules are fixed in the terminal system and can only be changed through a system-wide upgrade. By sending configuration files to the terminal, flexible and efficient management of the functions of each local layer module can be achieved, greatly improving update efficiency. At the same time, there is no need to restart the device or wait for a system version update, which greatly enhances the user experience. On the other hand, by constructing a matching mechanism between file types and local layer modules, it ensures that the target attributes can be accurately delivered to the target local layer module, avoiding resource waste and potential conflicts caused by global broadcast, and improving the efficiency and security of system processing.

[0056] In one feasible implementation, the step of determining the target local layer module among the registered local layer modules based on the file type may specifically include: determining the target local layer module based on the file type and the preset correspondence between the file type and the registered local layer modules through a customized feature attribute management service.

[0057] In this embodiment, the terminal management service can specifically employ a custom feature attribute management service to manage the attributes of each local layer module. The local layer modules registered with the custom feature attribute management service may include one or more, and the target attributes may include one or more. After receiving each target attribute, the custom feature attribute management service can notify the corresponding registered target local layer modules of multiple target attributes via callback notifications.

[0058] In this embodiment, the mapping between preset file types and registered local layer modules can be a mapping table or registry stored within the custom feature attribute management service. This mapping table or registry uses "file type" as the key and "unique identifier (e.g., process ID, service name, Binder reference) of the local layer module that has been registered and authorized to process this type of file" as the value. For example, a mapping between a file type and a registered local layer module in the mapping table might be: {"audio_config":"com.tcl.audio.AudioFeatureService"}.

[0059] In this implementation, once the file type is parsed, it can be sent to the custom feature attribute management service. The custom feature attribute management service uses the obtained file type as a query parameter and searches in its internally maintained mapping table. The query algorithm is usually an efficient hash lookup or key-value pair direct retrieval, ensuring completion in constant time complexity (O(1)).

[0060] In this implementation, if a key that exactly matches the input file type is found in the mapping table, its corresponding module identifier is retrieved and returned to the caller as the target local layer module. If no match is found, an error code or null value is returned, indicating that no module is registered to process this type of file, and the process terminates.

[0061] In this embodiment, when the terminal needs to add a new locally layer module that can be dynamically configured, it only needs to register the new local layer module with the customized feature attribute management service to support the new file types and update the mapping table.

[0062] In this embodiment, by centralizing the module lookup logic into the customized feature attribute management service, the system's configuration update path becomes clear and unified. Module lookup is performed through a pre-established mapping table, which significantly improves the speed and performance of determining the target local layer module, making it particularly suitable for scenarios that require rapid response to cloud pushes.

[0063] In one feasible implementation, refer to Figure 2 Before determining the target local layer module by customizing the feature attribute management service based on file type and the pre-defined correspondence between file types and registered local layer modules, the function management method may also include steps S201~S202, as follows: S201: In response to a registration request sent by any local layer module to the custom feature attribute management service, obtain the module type of the local layer module and the file types supported by the local layer module.

[0064] In this embodiment, the registration request is a request actively sent by the local layer module to the customized feature attribute management service when it starts or initializes, which is used to declare its existence and capabilities to the customized feature attribute management service.

[0065] In this implementation, the module type is used to distinguish the categories of local layer modules. Each local layer module has a unique module type. The file types supported by a local layer module refer to the categories of configuration files that the local layer module can parse and process.

[0066] In this implementation, the local layer module connects to the custom feature attribute management service via inter-process communication (such as Binder calls), calls its registration interface, and passes its own module type and a list of supported file types as parameters. The registration interface of the custom feature attribute management service receives these parameters and temporarily stores them in the context of this request for subsequent verification.

[0067] S202: When the module type is a preset type and the local layer module has a system user identifier, register the local layer module to the custom feature attribute management service, and save the correspondence between the local layer module and the file type in the custom feature attribute management service.

[0068] In this implementation, the preset type specifies the types of modules allowed to register by the feature attribute management service. For example, the preset type can be a high-trust type such as SYSTEM or VENDOR. By judging the preset type, only high-trust local layer modules are allowed, thus preventing untrusted third-party modules from interfering with critical system configurations.

[0069] In this implementation, the system user identifier (SYSTEM_UID) is a user identity identifier assigned to a process by the operating system. In systems such as Android, SYSTEM_UID (usually 1000) represents the permission level of the system kernel process. Verifying whether the caller possesses this UID is a strict identity and permission verification method, ensuring that only the system itself or a local layer module with system permissions can register.

[0070] In this embodiment, the customized feature attribute management service can obtain the actual identity identifier of the process that calls the registration interface through the interface provided by the inter-process communication framework, and check whether the actual identity identifier is a system user identifier.

[0071] In this implementation, the registration process can only be completed successfully if both of the above verifications pass, and the local layer module will be registered to the custom feature attribute management service. The custom feature attribute management service establishes an association between the unique identifier of the local layer module and its declared supported file types in an internal mapping table. For example, if the local layer module AudioService declares support for audio_config, then a record is added to the mapping table: {“audio_config”: AudioServiceBinderRef}. If the verification fails, the registration request is rejected and an error is returned.

[0072] In this implementation, by employing a dual verification method combining a preset type whitelist and a system user identifier, the range of modules that can register with the customized feature attribute management service is strictly limited. This effectively prevents malicious software or non-privileged modules from masquerading as system services to tamper with critical function configurations, thus ensuring system security and stability. Furthermore, by storing the correspondence between the local layer module and file type in the customized feature attribute management service, the target local layer module requiring functional updates can be quickly and accurately located based on this correspondence when the attributes of the local layer module change subsequently.

[0073] In one feasible implementation, the step of updating the functionality of the target local layer module based on the target attribute may specifically include: sending the target attribute to a customized feature attribute management service; and sending the target attribute to the target local layer module through the customized feature attribute management service, so that the target local layer module can adjust the on / off state of the target local layer module's functionality based on the target attribute.

[0074] In this implementation, after parsing the target attributes, they are encapsulated into a data structure suitable for inter-process communication (IPC). For example, in the Android system, this can be placed in a Bundle object or serialized as a JSON string. Then, a connection is made to the custom feature attribute management service via binding or calling, and its specified interface method is invoked. In this call, not only are the target attributes passed to the custom feature attribute management service, but the file type of the configuration file is also passed to the service, so that the service can clearly identify the target local layer module that needs a feature update.

[0075] In this embodiment, the step of sending the target attribute to the customized feature attribute management service may specifically include: obtaining the process ID of the process where the customized feature attribute management service is located through the attribute service; and sending the target attribute to the customized feature attribute management service according to the process ID.

[0076] In this implementation, the attribute service extracts the target attribute and passes it to the custom feature attribute management service. The attribute service resides in the initialization (Init) process, while the custom feature attribute management service resides in the asynchronous input / output (Aio) process. To send the target attribute to the custom feature attribute management service, the attribute service needs to perform cross-process communication. The Init process can start a series of system services according to the system configuration file. The Aio process allows the program to continue executing other tasks after initiating an input / output request without waiting for the input / output operation to complete. When the input / output operation is complete, the system notifies the program through mechanisms such as callbacks or event notifications.

[0077] In this implementation, communication between the Init process and the Aio process can be achieved by sending signals. Signals are a software interrupt mechanism used to transmit asynchronous event notifications between processes. To send target attributes to the custom attribute management service in the Aio process, the attribute service in the Init process needs to know the process ID of the Aio process. The process ID is a unique character that identifies a process.

[0078] In this implementation, the process ID of the Aio process hosting the customized feature attribute management service can be obtained by querying the target file. The Aio process can pre-write its process ID to the target file upon startup. Alternatively, the process ID can be obtained by querying the process registry. The target file is a specific file used to store the Aio process's process ID; it can be a system configuration file, a log file, or a custom data file. The target file can serve as a system configuration file to record the Aio process's process ID. The Aio process can write its process ID to the log file upon startup, thus allowing the process ID to be obtained from the log file. Developers can also set up a custom data file, into which the Aio process can write its process ID upon startup.

[0079] In this implementation, once the Init process obtains the process ID of the Aio process, it can use the corresponding functions provided by the system to send the target attribute to the Aio process. This ensures that the target attribute is accurately sent to the custom feature attribute management service in the Aio process, and is not mistakenly sent to other processes, thereby enabling communication between the Init process and the Aio process.

[0080] In this embodiment, a signal mechanism is used to send the target attribute across processes to the custom feature attribute management service, which is simple and efficient. By sending the target attribute through the process ID of the process in which the custom feature attribute management service resides, it can be ensured that the target attribute can be accurately sent to the custom feature attribute management service in the Aio process.

[0081] In this implementation, the attribute service sends the target attribute to the custom feature attribute management service across processes. This can be an instrumentation interception behavior performed in the HandlePropertySet (handling attribute settings) method of AOSP (the open-source version of the Android system).

[0082] In this embodiment, the customized feature attribute management service may include a functional interface module, a file parsing module, and a callback notification module. The functional interface module can receive target attributes, the file parsing module can analyze the target attributes, and the callback notification module can send callback notifications of the target attributes to registered local layer modules. Communication between the local layer modules and the customized feature attribute management service can be conducted through a management interface; the local layer modules send information to the management interface, which then sends the information to the customized feature attribute management service.

[0083] In this implementation, for the same type of attribute, the local layer module has functions corresponding to each attribute within that type of attribute. The activation of a function can be controlled by switching that function on or off. For example, the local layer module has functions corresponding to both the Android operating system and the iOS operating system. When the local layer module's attribute is originally an Android operating system attribute, the function corresponding to the Android operating system is enabled, and the function corresponding to the iOS operating system is disabled. When the local layer module's attribute changes to an iOS operating system attribute, the function corresponding to the Android operating system is disabled, and the function corresponding to the iOS operating system is enabled.

[0084] In this implementation, within the local layer module, adjusting functions can be abstracted as turning a switch on and off. Each function within the local layer module has complex underlying code; adjusting these functions via switches provides a simplified interface for complex operations. Therefore, updating the functionality of the local layer module can be achieved by adjusting its on / off switches.

[0085] In this embodiment, inter-process communication enables efficient and unified management of the local layer module by the customized feature attribute management service. This allows the target local layer module to respond to external configuration commands in real time without restarting its own process or the device. By adjusting the on / off switches of the target local layer module's functions, the functionality of the local layer module can be updated intuitively and flexibly.

[0086] In this embodiment, in response to receiving a configuration file, the configuration file is parsed to obtain the target attributes and the file type of the configuration file, including: in response to receiving a configuration file, obtaining the first version information of the configuration file and the second version information of the local configuration file; when the first version information is greater than the second version information, the configuration file is parsed to obtain the target attributes and the file type of the configuration file.

[0087] In this embodiment, the configuration file refers to the newly received data file configuring the local layer module, typically originating from an update package pushed from the cloud or stored locally. The configuration file can include multiple levels of configuration files; for example, it can include files at different levels such as common.json (general level) and project.json (project level). In this embodiment, the local configuration file refers to the data file configuring the local layer module that is currently in effect on the terminal. This local configuration file is a copy of the configuration file corresponding to the same functional module or the same level.

[0088] In this implementation, the first version information refers to the version identifier of the configuration file, used to indicate the age of the configuration file. The second version information refers to the version identifier of the local configuration file, used to indicate the age of the local configuration file. The system can obtain the second version information through attributes, that is, read the version number stored after the last successful parsing and application of the local configuration file from system attributes.

[0089] In this implementation, different levels can be configured with corresponding version numbers independently. For example, the first version information may include the cloud-based general level version number and the cloud-based project level version number corresponding to the general level; the second version information may include the local general level version number and the local project level version number corresponding to the project level.

[0090] In this embodiment, when the cloud-based general-level version number is greater than the local general-level version number and / or the cloud-based project-level version number is greater than the local project-level version number, it can be determined that the first version information is greater than the second version information.

[0091] In this embodiment, considering that the local configuration file of the local layer module is usually located in the same directory as project.json (project level), that is, the configuration file usually modifies the configuration data in project.json (project level), therefore, when the version number of the cloud project level is greater than the version number of the local project level, it can be determined that the first version information is greater than the second version information.

[0092] In this implementation, if the first version information is less than or equal to the second version information, it indicates that the received configuration file is an older version or the same version. The terminal then discards or ignores the configuration file and does not perform parsing.

[0093] In this implementation, by performing version comparison before parsing, the terminal can automatically reject processing requests for old configuration files, avoiding invalid parsing, attribute overwriting, and possible unexpected rollback of functional states caused by repeatedly receiving the same or older cloud pushes, thus ensuring the unidirectional evolution of configuration states. At the same time, it ensures that CPU and memory resources are consumed to parse new configuration files only when they are actually received, thereby significantly reducing the processing overhead of the system when receiving pushes frequently or receiving old data unexpectedly, and improving overall energy efficiency and response speed.

[0094] In one feasible implementation, the step of parsing the configuration file to obtain the target attribute may specifically include: parsing the configuration file to obtain attribute configuration data; obtaining the attribute name from the attribute configuration data; and determining the attribute corresponding to the attribute name as the target attribute when the attribute name includes a target identifier.

[0095] In this embodiment, the configuration file is data used to configure the terminal, which may include attribute configuration data for configuring attributes, and the attribute configuration data may include target attributes. Target attributes may include attributes of one or more target local layer modules.

[0096] In this embodiment, refer to Figure 3 The diagram illustrates the architecture of the function management method. The terminal can obtain a configuration file sent from the cloud, and then parse the configuration file using a global configuration application package to obtain attribute configuration data. Attribute configuration data consists of attribute-related data within the configuration data. After obtaining the attribute configuration data, it can be passed to the attribute service. The attribute service verifies the attribute configuration data, retrieving each attribute and its name. It checks if the attribute name includes a target identifier; if so, the attribute corresponding to that name is identified as the target attribute. After determining the target attribute, the attribute service can send it to the customized feature attribute management service. Upon receiving the target attribute, the customized feature attribute management service can determine the target local layer module from among the registered local layer modules based on the configuration file's file type, and notify the registered target local layer module of the target attribute, thereby updating the functionality of the target local layer module.

[0097] In this embodiment, the configuration file can be a configuration file sent from the cloud. When it is necessary to update the functionality of the local layer modules of multiple terminals, only the configuration file stored in the cloud needs to be updated, and then the cloud pushes the configuration file to multiple terminals simultaneously, thereby quickly and conveniently modifying the functionality of the local layer modules of multiple terminals.

[0098] In this embodiment, the global configuration application package can be an Android application package (APK) named ConfigProvider (Global Configuration) that parses the configuration files. ConfigProvider is mainly used to interact with the cloud to download the configuration files, process the content, and save them.

[0099] In this embodiment, the target identifier can be a fixed character [persist.tcl.feature] in the prefix of the attribute name. The attribute service verifies whether the prefix of each attribute name includes the fixed character [persist.tcl.feature]. If the prefix of the attribute name includes the fixed character [persist.tcl.feature], the attribute corresponding to that attribute name is determined as the target attribute. In this way, by verifying the attribute name, it can be determined whether the attribute is a target attribute, so that the target attribute can be sent to the customized feature attribute management service, thereby updating the functionality of the target local layer module.

[0100] In this embodiment, the technical solution achieves accurate filtering and efficient extraction of massive configuration file content. By setting and identifying the target identifier as a key rule, the attribute service can automatically and quickly locate the truly dynamically managed local layer functional attributes from complex configuration data without parsing and loading all configuration items. This significantly reduces data processing volume, lowers memory usage, improves system response speed, and effectively avoids interference from irrelevant configuration items, ensuring the accuracy and execution efficiency of the dynamic update mechanism.

[0101] In one feasible implementation, the configuration file can be generated through the following steps: obtaining requirement description information; determining the target attributes of the target local layer module based on the requirement description information; and generating the configuration file based on the target attributes of the target local layer module.

[0102] In this embodiment, a configuration file can be generated via the cloud. The cloud can receive the user's input of the target local layer module's requirement description information, and then automatically identify the target attributes of the target local layer module based on the requirement description information, and generate a configuration file in a standard format.

[0103] In this embodiment, requirement description information refers to the instructions entered by product personnel or operations personnel regarding the target function they wish to change or configure. For example, requirement description information may be a feature (custom feature) function that needs to be changed, entered by the user into an online description platform. This requirement description information can be natural language; for example, the requirement description information could be: Enable audio surround sound enhancement. This requirement description information can also be structured requirement information, which includes structured forms and / or structured options, such as selecting "Audio_Enhancement" in a drop-down menu and setting it to "ON".

[0104] In this embodiment, users can submit requirement description information to an online description platform through a graphical user interface (GUI) or API interface. The backend service of the online description platform receives the input, converts it into an internal "requirement work order" or "change request" data structure, and automatically identifies the target local layer module that needs to be updated and the target attributes of the target local layer module.

[0105] In this embodiment, the system (such as an automated configuration tool) parses the received requirement description information. If the requirement description information is in natural language, the target attributes of the target local layer module can be identified by keyword extraction or intent recognition models; if the requirement description information is in structured requirement information, predefined first option value and second option value can be read from the structured requirement information, and the target local layer module can be determined according to the first option value, and the target attributes corresponding to the target local layer module can be determined according to the second option value.

[0106] In this embodiment, the target attributes of the target local layer module can be sent to the FCM (Firebase CloudMessaging) visual configuration tool, which then generates a standard format configuration file based on the target attributes of the target local layer module.

[0107] In this implementation, when it is necessary to update attribute configuration files at different levels, the cloud can generate a message containing the updated attributes. For example, if the attributes of the software layer need to be adjusted, the cloud will prepare a configuration file containing the adjusted software layer attributes. Through the FCM service, the cloud sends out the prepared package configuration data. FCM will accurately push the message to the corresponding client application based on the registration token of each terminal. Each terminal with the FCM application installed will obtain a unique registration token during FCM registration.

[0108] In this implementation, after receiving the configuration file pushed by FCM, the terminal will pass the configuration file to the local layer. For example, in the iOS operating system, the received configuration file can be passed to the local layer module through a bridging mechanism.

[0109] In this embodiment, using the technical solution of this application, developers only need to input requirement description information to automatically generate configuration files. The entire configuration file generation is completed automatically, ensuring that the configuration file format is uniform and the content is accurate. This achieves automatic conversion from requirements to configuration, replacing the tedious steps of manual review, manual search for configuration items, and writing configuration files required by traditional processes. This not only greatly improves configuration efficiency but also effectively avoids configuration errors and version inconsistencies that may occur during manual writing.

[0110] Reference Figure 4 This diagram illustrates the architecture of configuration file change notifications. The cloud interaction service, or the observed entity, is responsible for downloading the latest configuration file from the cloud and saving it to a specified local path (e.g., data / system / fcm). The medium, TclFeatureManager, acts as a customized feature attribute management service, undertaking a dual responsibility: first, providing a unified listener registration interface for observers; and second, receiving update events from the observed entity and distributing them to the corresponding observers through a unified change notification interface. Observers are the various system modules. For example, SystemConfigService corresponds to file type Type=1; SettingsProvider to file type Type=3; PMS (Package Manager Service) to file type Type=4; WMS (Window Manager Service) to file type Type=6, etc. System modules are the local layer modules that actually need to adjust their functionality based on configuration updates.

[0111] During the registration phase, each system module can register by calling the unified file change monitoring registration interface provided by TclFeatureManager during initialization. TclFeatureManager will perform type validity checks and caller authentication (as shown in the "Process Check" section, for example, verifying whether the caller's UID is SYSTEM_UID). After successful authentication,<type,listener> The correspondence between the file types described in this local layer module is stored in its internal cache (ArrayMap) to complete the registration.

[0112] During the notification triggering phase, once the cloud interaction service successfully downloads and saves the configuration file, it will proactively call the TclFeatureManager.notify(type) interface and pass in the file type of the changed configuration file.

[0113] During the notification distribution phase, after receiving the `notify(type)` call, `TclFeatureManager` first configures the file type in the configuration file and determines the target local layer module from the registered local layer modules. Then, using its internal cache (ArrayMap) as a registry, it quickly searches based on the passed file type to match the corresponding listener object (i.e., the target local layer module). Finally, `TclFeatureManager` calls back the `onChanged()` method of this listener object, thus accurately notifying the corresponding target local layer module of the target attribute. The target local layer module detects the attribute change in the `onChanged` callback and updates its functionality based on the target attribute.

[0114] Thus, by using TclFeatureManager as a dedicated configuration management service to centrally handle all registration and notification logic, the system architecture becomes clearer and more maintainable. By using file type as the exact matching key, combined with in-memory ArrayMap caching, update events can be instantly routed to the correct target local layer module, avoiding the resource waste and processing chaos caused by broadcast notifications. Type and process checks during registration ensure that only legitimate system core modules can access this dynamic update framework, preventing unauthorized listening or injection by malicious modules and ensuring system security.

[0115] 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.

[0116] Based on the same inventive concept, and referring to Figure 5 This application provides a function management device 500, which includes: The parsing module 501 is used to parse the configuration file in response to receiving the configuration file, and obtain the target attributes and the file type of the configuration file; The determination module 502 is used to determine the target local layer module among the registered local layer modules based on the file type; The update module 503 is used to update the functionality of the target local layer module based on the target attributes.

[0117] In one embodiment, the determining module 502 is specifically used to determine the target local layer module based on the file type and the preset correspondence between the file type and the registered local layer module through a customized feature attribute management service.

[0118] In one embodiment, the function management device 500 further includes: The type acquisition module is used to obtain the module type of the local layer module and the file types supported by the local layer module in response to a registration request sent by any local layer module to the customized feature attribute management service. The module registration module is used to register the local layer module to the customized feature attribute management service when the module type is a preset type and the local layer module has a system user identifier, and to save the correspondence between the local layer module and the file type in the customized feature attribute management service.

[0119] In one embodiment, the update module 503 includes: The attribute sending submodule is used to send the target attribute to the customized feature attribute management service; The attribute update submodule is used to send the target attribute to the target local layer module through the customized feature attribute management service, so that the target local layer module can adjust the on / off state of the target local layer module's functions based on the target attribute.

[0120] In one embodiment, the parsing module 501 includes: The version acquisition submodule is used to obtain the first version information of the configuration file and the second version information of the local configuration file in response to receiving the configuration file; The version comparison submodule is used to parse the configuration file when the first version information is greater than the second version information, and obtain the target attribute and the file type of the configuration file.

[0121] In one embodiment, the parsing module 501 includes: The file parsing submodule is used to parse the configuration data to obtain attribute configuration data; The name retrieval submodule is used to retrieve the attribute name from the attribute configuration data; The attribute determination submodule is used to determine the attribute corresponding to the attribute name as the target attribute when the attribute name includes the target identifier.

[0122] In one embodiment, the configuration file is generated in the following manner: Obtain the requirement description information; Based on the aforementioned requirement description information, the target attributes of the target local layer module are determined; The configuration file is generated based on the target attributes of the target local layer module.

[0123] By employing the technical solution of this application embodiment, in response to receiving a configuration file, the configuration file is parsed to obtain the target attributes and the file type of the configuration file. Based on the file type, the target local layer module can be determined among the registered local layer modules, and then the functionality of the target local layer module can be updated based on the target attributes. In this way, targeted updates to the functionality of the target local layer module can be achieved without recompiling the local layer module, thereby enabling flexible and efficient management of the functionality of the local layer module, greatly improving update efficiency and avoiding impact on user experience.

[0124] 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.

[0125] 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.

[0126] 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.

[0127] 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.

[0128] 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.

[0129] 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.

[0130] 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.

[0131] 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.

[0132] 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.

[0133] 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.

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

[0135] 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.

[0136] 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.

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

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

[0139] 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.

[0140] 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.

[0141] 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 a configuration file, the configuration file is parsed to obtain the target attributes and the file type of the configuration file; Based on the file type, the target local layer module is determined from the registered local layer modules; Based on the target attributes, the functionality of the target local layer module is updated.

2. The function management method according to claim 1, characterized in that, The step of determining the target local layer module among the registered local layer modules based on the file type includes: The target local layer module is determined by a customized feature attribute management service based on the file type and the pre-defined correspondence between the file type and the registered local layer module.

3. The function management method according to claim 2, characterized in that, Before determining the target local layer module through the customized feature attribute management service based on the file type and the preset correspondence between file types and registered local layer modules, the method further includes: In response to a registration request sent by any local layer module to the customized feature attribute management service, the module type of the local layer module and the file types supported by the local layer module are obtained; When the module type is a preset type and the local layer module has a system user identifier, the local layer module is registered to the customized feature attribute management service, and the correspondence between the local layer module and the file type is saved in the customized feature attribute management service.

4. The function management method according to claim 1, characterized in that, The step of updating the functionality of the target local layer module based on the target attribute includes: Send the target attribute to the customized feature attribute management service; The target attribute is sent to the target local layer module through the customized feature attribute management service, so that the target local layer module can adjust the on / off state of the target local layer module's functions based on the target attribute.

5. The function management method according to claim 1, characterized in that, The response to receiving the configuration file involves parsing the configuration file to obtain the target attributes and the file type of the configuration file, including: In response to receiving a configuration file, obtain the first version information of the configuration file and the second version information of the local configuration file; When the first version information is greater than the second version information, the configuration file is parsed to obtain the target attribute and the file type of the configuration file.

6. The function management method according to claim 1, characterized in that, The step of parsing the configuration file to obtain the target attributes includes: The configuration file is parsed to obtain the attribute configuration data; Obtain the attribute name from the attribute configuration data; When the attribute name includes a target identifier, the attribute corresponding to the attribute name is determined as the target attribute.

7. The function management method according to claim 1, characterized in that, The configuration file was generated in the following way: Obtain the requirement description information; Based on the aforementioned requirement description information, the target attributes of the target local layer module are determined; The configuration file is generated based on the target attributes of the target local layer module.

8. A function management device, characterized in that, The device includes: The parsing module is used to parse the configuration file in response to receiving the configuration file, and obtain the target attributes and the file type of the configuration file; The determination module is used to determine the target local layer module among the registered local layer modules based on the file type; An update module is used to update the functionality of the target local layer module based on the target attributes.

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