Android embedded device underlying parameter configuration method and device based on large language model, terminal equipment and storage medium

Abstract

This application relates to the fields of artificial intelligence and embedded software development technology, and provides a method, apparatus, terminal device, and storage medium for configuring low-level parameters of Android embedded devices based on a large language model. The method includes: receiving a natural language instruction to modify hardware configuration parameters; extracting a first configuration identifier and a first configuration parameter corresponding to the natural language instruction; matching the first configuration identifier according to a pre-built structured constraint rule library to obtain a first matching result; if the first matching result indicates that the first configuration identifier exists in the structured constraint rule library, then performing a configuration modification operation on the first configuration parameter according to the first constraint rule corresponding to the first configuration identifier in the structured constraint rule library to obtain first target configuration data. This method effectively avoids configuration modification errors caused by the illusion of a large language model, improving the security and reliability of modifying low-level hardware parameters in Android embedded systems.

Description

Technical Field

[0001] This application belongs to the field of artificial intelligence and embedded software development technology, and in particular relates to a method, device, terminal device and storage medium for configuring low-level parameters of Android embedded devices based on a large language model. Background Technology

[0002] In the development of Android embedded devices such as smart vehicles, industrial handheld terminals, IoT gateways, and smart TVs, a large amount of low-level configuration customization is required based on hardware specifications and customer needs, including device trees, kernel macros, system attributes, and HAL layer parameters.

[0003] Traditional manual modification relies on senior engineers consulting documentation and manually changing code, which is inefficient, costly, and highly dependent on the personnel's familiarity with the code repository. Automated solutions based on large language models can parse natural language to complete configuration writing, reducing manual input. However, due to the probabilistic generation characteristics of large language models (LLM), they are prone to creating illusions, such as fabricating configuration items, outputting incorrect formats and file paths. Furthermore, they lack pre-deterministic verification, relying solely on compilation errors to discover problems. Error feedback is delayed, troubleshooting is difficult, and erroneous modifications can pollute the project environment, causing occasional compilation failures and failing to guarantee the reliability of customized configurations. Summary of the Invention

[0004] This application provides a method, apparatus, terminal device, and storage medium for configuring low-level parameters of Android embedded devices based on a large language model. By matching and verifying the parsed configuration identifier with a pre-built structured constraint rule library, and completing parameter modification configuration according to the corresponding constraint rules, the modification behavior can be constrained, effectively avoiding configuration modification errors caused by the illusion of a large language model, and improving the security and reliability of modifying low-level hardware parameters of Android embedded devices.

[0005] In a first aspect, embodiments of this application provide a method for configuring low-level parameters of an Android embedded device based on a large language model, including: Receive natural language commands to modify hardware configuration parameters; Extract the first configuration identifier and the first configuration parameter corresponding to the natural language command; Based on the pre-built structured constraint rule library, the first configuration identifier is matched to obtain the first matching result; wherein, the structured constraint rule library contains multiple underlying configuration items and constraint rule information corresponding to each underlying configuration item; If the first matching result indicates that a first configuration identifier exists in the structured constraint rule base, then according to the first constraint rule corresponding to the first configuration identifier in the structured constraint rule base, the first configuration parameter modification operation is performed to obtain the first target configuration data.

[0006] In this embodiment, a natural language instruction to modify hardware configuration parameters is first received, and the corresponding first configuration identifier and first configuration parameter are extracted. Then, a structured constraint rule library, which is pre-built and stores constraint rule information for various underlying configuration items, is used to perform matching and verification on the configuration identifier. After the verification is successful, the parameters are rewritten according to the corresponding constraint rules. This method can add a deterministic rule verification checkpoint after the large language model generates the modification instruction and before it is officially written into the underlying code. It avoids the problems of the large language model generating illusions, fabricating non-existent configuration items, and outputting illegal modification paths due to the probability generation mechanism. It does not need to rely entirely on manual review to identify errors. It retains the automation convenience brought by the natural language modification instruction, and uses the whitelist forced matching mechanism of the rule library to constrain the modification scope to the legally modifiable underlying configuration items. This reduces device operation abnormalities caused by invalid modifications and illegal parameter writing, and improves the reliability and security of the automated modification process of Android embedded underlying hardware configuration.

[0007] In one possible implementation of the first aspect, the method further includes: Retrieve multiple low-level configuration items in the target hardware device that are allowed to be modified; Establish corresponding constraint rules for each underlying configuration item; the constraint rules include the configuration identifier, code path, parameter type, value range, standard modification example, and validation script path for each underlying configuration item. A structured constraint rule library is generated based on multiple underlying configuration items and their corresponding constraint rules.

[0008] In this embodiment, by pre-collecting modifiable underlying configuration items and establishing a structured constraint rule base for each configuration identifier, code path, parameter range, modification example, verification script, and other constraint information, authoritative and definite verification basis can be provided for subsequent automated modification of hardware parameters of large language models. This effectively constrains the model output boundary, reduces the risk of configuration item, path, and parameter format errors caused by AI illusion, and ensures that the embedded underlying configuration modification work is safe and controllable.

[0009] In one possible implementation of the first aspect, a structured constraint rule library is generated based on multiple underlying configuration items and their corresponding constraint rules, including: Each underlying configuration item is bound to its corresponding constraint rule, generating multiple configuration constraint records; Multiple configuration constraint records are stored in a preset database to obtain a structured constraint rule library.

[0010] In this embodiment, the underlying configuration items and constraint rules are bound one by one to generate configuration constraint records and stored in the database to form a structured constraint rule library. This enables centralized and standardized management of configuration constraint information, facilitates rapid retrieval and querying in the future, ensures stable and reliable data reading during large model matching and verification, improves parameter verification efficiency, and provides persistent and reusable rule support for automated modification of embedded hardware configuration.

[0011] In one possible implementation of the first aspect, the method further includes: If the first matching result indicates that the first configuration identifier does not exist in the structured constraint rule base, then a prompt word is obtained; wherein, the prompt word is generated based on the first matching result, the structured constraint rule base, and natural language instructions; Re-extract the second configuration identifier and second configuration parameters corresponding to the natural language instructions based on the prompt words; Based on the structured constraint rule base, a matching check is performed on the second configuration identifier to obtain the second matching result; If the second matching result indicates that the second configuration identifier does not exist in the structured constraint rule base, and the number of matches corresponding to the second matching result reaches the first preset number, then the matching process is terminated and an early warning is issued.

[0012] In this embodiment, when the configuration identifier fails to match for the first time, a guiding prompt is generated by combining the matching result, rule base and original instruction, driving the large model to re-parse and extract the configuration information for secondary matching and verification. At the same time, a matching retry limit is set and the process is terminated and a warning is issued after the limit is exceeded. This not only gives the large model the opportunity to correct errors and retry, improving the probability of successful instruction parsing, but also prevents infinite loop retry, timely detects unrecognized modification requirements, and ensures process stability.

[0013] In one possible implementation of the first aspect, based on the first constraint rule corresponding to the first configuration identifier in the structured constraint rule base, a modification configuration operation of the first configuration parameter is performed to obtain the target configuration data, including: The target code path and standard modification examples are determined based on the structured constraint rule base; Invoke the code editor so that the code editor can perform the first configuration parameter modification operation on the target code according to the target code path and standard modification example, and obtain the first target configuration data.

[0014] In this embodiment, by reading the target code path and standard modification examples from the structured constraint rule library, and then having the code editor complete the parameter rewriting by referring to the examples, the code modification location and writing format can be strictly limited, avoiding arbitrary modification of irrelevant code and generation of incorrect syntax in large models, ensuring that the underlying configuration modification actions are accurate and controllable, and improving the correctness of automated modification results.

[0015] In one possible implementation of the first aspect, the method further includes: After obtaining the first target configuration data, the path of the first verification script is determined based on the structured constraint rule base; Obtain the first verification script based on the first verification script path; Execute the first verification script to verify the first target configuration data and obtain the first verification result; If the first verification result indicates that the verification failed, the first target configuration data is restored to its initial state, and the parameter modification configuration operation is re-executed according to the structured constraint rule base to obtain the second target configuration data. Execute the verification script corresponding to the second target configuration data to verify the second target configuration data and obtain the second verification result; If the second verification result indicates that the verification failed, and the number of verifications corresponding to the second verification result reaches the second preset number, then the parameter modification configuration is determined to be abnormal.

[0016] In this embodiment, after modification, a dedicated verification script is invoked to check the configuration data. If verification fails, the file is automatically restored and modified again, while a verification retry limit is set. Through the closed-loop mechanism of write-verify-rollback-retry, format errors and out-of-bounds parameters can be intercepted in a timely manner, illegal changes can be undone, and incorrect configurations cannot be written to the underlying code. The retry limit prevents the process from going into an infinite loop, quickly identifies abnormal tasks, and effectively improves the security and stability of embedded hardware parameter modification.

[0017] In one possible implementation of the first aspect, the method further includes: Obtain the execution operation log during the parameter modification and configuration process of the target hardware device; Generate an execution report based on the execution operation log; The execution report is sent to the display terminal for the purpose of tracing the execution operation.

[0018] In this embodiment of the application, by collecting the execution log of the entire process of parameter modification, an automatic traceable execution report is generated and pushed to the display terminal, which completely preserves the operation traces of each step, making it convenient for staff to troubleshoot and review problems afterward. This achieves auditability and traceability of the entire automated configuration modification process, and improves the operation and maintenance management capabilities of the solution.

[0019] Secondly, embodiments of this application provide a low-level parameter configuration device for Android embedded devices based on a large language model, comprising: The data receiving module is used to receive natural language commands that modify hardware configuration parameters; The identifier parameter extraction module is used to extract the first configuration identifier and the first configuration parameter corresponding to the natural language instruction; The identifier matching module is used to perform matching on the first configuration identifier according to the pre-built structured constraint rule library to obtain the first matching result; wherein, the structured constraint rule library contains multiple underlying configuration items and constraint rule information corresponding to each underlying configuration item; The parameter configuration module is used to perform a modification configuration operation on the first configuration parameter according to the first constraint rule corresponding to the first configuration identifier in the structured constraint rule library if the first matching result indicates that the first configuration identifier exists, so as to obtain the first target configuration data.

[0020] Thirdly, embodiments of this application provide a terminal device, including a memory, a processor, and a computer program stored in the memory and executable on the processor. When the processor executes the computer program, it implements the Android embedded device low-level parameter configuration method based on a large language model as described in any of the first aspects above.

[0021] Fourthly, embodiments of this application provide a computer-readable storage medium storing a computer program that, when executed by a processor, implements the Android embedded device low-level parameter configuration method based on a large language model as described in any of the first aspects above.

[0022] Fifthly, embodiments of this application provide a computer program product that, when run on a terminal device, causes the terminal device to execute the Android embedded device low-level parameter configuration method based on a large language model as described in any of the first aspects above.

[0023] It is understood that the beneficial effects of the second to fifth aspects mentioned above can be found in the relevant descriptions in the first aspect mentioned above, and will not be repeated here. Attached Figure Description

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

[0025] Figure 1This is a flowchart illustrating an embodiment of the Android embedded device low-level parameter configuration method based on a large language model provided in this application; Figure 2 This is a schematic diagram of the process for constructing a structured constraint rule base according to an embodiment of this application; Figure 3 This is a schematic diagram of the identifier matching process provided in one embodiment of this application; Figure 4 This is a schematic diagram of the execution configuration modification process provided in one embodiment of this application; Figure 5 This is a schematic diagram of the configuration verification process provided in one embodiment of this application; Figure 6 This is a schematic diagram of the process for generating an execution report provided in an embodiment of this application; Figure 7 This is a schematic diagram of the overall structure of an Android embedded device low-level parameter configuration method based on a large language model provided in an embodiment of this application; Figure 8 This application provides an embodiment of an Android embedded device low-level parameter configuration device based on a large language model. Figure 9 This is a schematic diagram of the structure of a terminal device provided in an embodiment of this application. Detailed Implementation

[0026] In the following description, specific details such as particular system architectures and techniques are set forth for illustrative purposes and not for limitation, in order to provide a thorough understanding of the embodiments of this application. However, those skilled in the art will understand that this application may also be implemented in other embodiments without these specific details. In other instances, detailed descriptions of well-known systems, apparatuses, circuits, and methods have been omitted so as not to obscure the description of this application with unnecessary detail.

[0027] It should be understood that, when used in this application specification and the appended claims, the term "comprising" indicates the presence of the described features, integrals, steps, operations, elements and / or components, but does not exclude the presence or addition of one or more other features, integrals, steps, operations, elements, components and / or a collection thereof.

[0028] It should also be understood that the term “and / or” as used in this application specification and the appended claims means any combination of one or more of the associated listed items and all possible combinations, and includes such combinations.

[0029] As used in this application specification and the appended claims, the term "if" may be interpreted, depending on the context, as "when," "once," "in response to determination," or "in response to detection." Similarly, the phrase "if determined" or "if detected [the described condition or event]" may be interpreted, depending on the context, as meaning "once determined," "in response to determination," "once detected [the described condition or event]," or "in response to detection [the described condition or event]."

[0030] Furthermore, in the description of this application and the appended claims, the terms "first," "second," "third," etc., are used only to distinguish descriptions and should not be construed as indicating or implying relative importance.

[0031] References to "one embodiment" or "some embodiments" in this specification mean that one or more embodiments of this application include a specific feature, structure, or characteristic described in connection with that embodiment. Therefore, the phrases "in one embodiment," "in some embodiments," "in other embodiments," "in still other embodiments," etc., appearing in different parts of this specification do not necessarily refer to the same embodiment, but rather mean "one or more, but not all, embodiments," unless otherwise specifically emphasized.

[0032] In the development of Android embedded devices such as smart vehicles, industrial handheld terminals, IoT gateways, and smart TVs, a large amount of low-level configuration customization is required based on hardware specifications and customer needs, including device trees, kernel macros, system attributes, and HAL layer parameters.

[0033] Traditional manual modification relies on senior engineers consulting documentation and manually changing code, which is inefficient, costly, and highly dependent on the personnel's familiarity with the code repository. Automated solutions based on large language models can parse natural language to complete configuration writing, reducing manual input, but are prone to illusions due to the probabilistic generation characteristics of LLM, such as fabricating configuration items, outputting incorrect formats and file paths. Furthermore, they lack pre-deterministic verification, relying solely on compilation errors to discover problems, resulting in delayed error feedback, difficulty in troubleshooting, and the potential for erroneous modifications to pollute the project environment, causing occasional compilation failures and failing to guarantee the reliability of customized configurations.

[0034] To address the aforementioned technical issues, this application provides a method for configuring low-level parameters of Android embedded devices based on a large language model. This application receives natural language instructions for modifying hardware configuration parameters, extracts the corresponding configuration identifier and configuration parameters, and then performs a matching verification between the configuration identifier and a pre-built structured constraint rule library containing constraint information for each low-level configuration item. If the verification is successful and the configuration identifier is valid, the parameter modification configuration operation is executed according to the constraint rules corresponding to the rule library to obtain the target configuration data. This solution uses a rule library to perform pre-verification constraints on the modification object. While utilizing natural language to automate the adjustment of the embedded low-level configuration, it can avoid modification errors caused by the illusion of a large language model, thus improving the security and reliability of the hardware parameter configuration process.

[0035] See Figure 1 This is a flowchart illustrating an embodiment of an Android embedded device low-level parameter configuration method based on a large language model, provided in this application. It is intended as an example and not a limitation. The method may include the following steps: S101 receives natural language instructions to modify hardware configuration parameters.

[0036] In this embodiment, the system receives natural language commands input by the user to modify the underlying hardware configuration parameters of the embedded device. These commands are submitted in human-readable, conversational text, eliminating the need for the user to manually write code or specify file paths. For example, if the user inputs the natural language command, "Please change the backlight current to 550mA," the system can receive this command and subsequently extract the configuration identifier to be modified and the target configuration parameters based on this command, thereby performing subsequent matching verification and parameter modification.

[0037] S102, extract the first configuration identifier and the first configuration parameter corresponding to the natural language instruction.

[0038] In this embodiment of the application, the received natural language instructions are parsed and identified, and from the user's colloquial requirements, two core pieces of information are separated: which configuration needs to be modified and what value to change it to.

[0039] For example, the system calls LLM to perform semantic parsing on the acquired natural language instructions, identify the hardware items to be adjusted in the instructions, map them to the corresponding configuration identifiers, and extract the user-specified target parameter value, i.e., the first configuration parameter. For instance, if the received natural language instruction is "Please change the backlight current to 550mA", after parsing, the extracted configuration identifier is CONFIG_BACKLIGHT_CURRENT, and the corresponding configuration parameter is 550mA. The extracted data will then be sent to the next stage for matching and verification.

[0040] S103, Match the first configuration identifier according to the pre-built structured constraint rule library to obtain the first matching result; wherein, the structured constraint rule library contains multiple underlying configuration items and constraint rule information corresponding to each underlying configuration item.

[0041] In this embodiment of the application, the validity of the configuration identifier parsed from the natural language instruction is verified, and it is determined whether the configuration belongs to the underlying configuration item that is allowed to be modified, thus filtering out fictitious or non-existent configuration requirements.

[0042] For example, the first configuration identifier extracted in the previous step is used as the search keyword to query the pre-built structured constraint rule base. The program compares this rule with all underlying configuration items already included in the rule base to determine if a matching configuration identifier exists, and finally outputs the corresponding matching result. The rule base stores constraint information such as the file path, parameter range, format examples, and validation scripts associated with each modifiable configuration item. For instance, if the extracted configuration identifier is CONFIG_BACKLIGHT_CURRENT, the program searches the rule base for this identifier. If a match is found, a matching result indicating successful validation is obtained. If a non-existent identifier, CONFIG_SCREEN_VOLT, is parsed and there is no corresponding record in the rule base, the matching result is a validation failure.

[0043] In one embodiment, see Figure 2 This is a schematic diagram of the process for constructing a structured constraint rule base according to an embodiment of this application, as shown below. Figure 2 As shown, it includes: S201, obtain multiple low-level configuration items in the target hardware device that are allowed to be modified.

[0044] In this application embodiment, the underlying configuration items in the target Android embedded hardware device that are secure, controllable, and open to user modification are selected, the allowed scope of subsequent automated modification operations is defined, and a basic list of modifiable configurations is formed.

[0045] For example, R&D personnel can consult the kernel source code, device tree file, hardware abstraction layer file, and system configuration documentation of the target hardware device to screen all underlying hardware configuration items, eliminate configurations that are prohibited from modification or will cause system failures, and filter out and summarize the underlying configuration items that can be modified. Taking industrial vehicle display equipment as an example, after screening, a batch of modifiable underlying configuration items are obtained, including items such as backlight current, screen refresh rate, and backlight on-delay; subsequently, based on this list, the identifiers, code paths, parameter ranges, and other information of each configuration can be entered to build a structured constraint rule base.

[0046] S202, establish corresponding constraint rules for each underlying configuration item; wherein, the constraint rules include the configuration identifier, code path, parameter type, value range, standard modification example and validation script path for each underlying configuration item.

[0047] In this embodiment, complete modification restriction information is added to each permitted modification of the underlying configuration, and corresponding constraint rules are generated. These rules are then used to control the file location, value range, writing format, and post-modification verification requirements when parameters are modified, in order to prevent incorrect configurations.

[0048] For example, for each underlying configuration item in the list, the corresponding constraint information is entered one by one to generate an independent constraint rule. The rule information includes a unique configuration identifier, the physical directory where the target code is stored, the data type of the parameter, the legal value range, a standard modification example for reference, and the storage path of the verification script. Taking the backlight current configuration item as an example, the constraint rule established is as follows: The configuration identifier is CONFIG_BACKLIGHT_CURRENT, the code path is kernel / drivers / video / backlight / panel.c, the parameter type is integer, the value range is 100-600ma, the standard modification example is #define PANEL_CURRENT500 / / ma, and the verification script path is tools / check_backlight.sh. After all configuration items generate constraint rules, they can be stored in the database to form a structured constraint rule library.

[0049] S203 generates a structured constraint rule library based on multiple underlying configuration items and their corresponding constraint rules.

[0050] In this embodiment of the application, this step involves summarizing and storing the already selected underlying configuration items and a complete set of constraint rules for each configuration item in a unified and structured manner, ultimately building a database that can be called and queried by subsequent processes, namely a structured constraint rule library.

[0051] In the above method, by pre-collecting modifiable underlying configuration items and establishing a structured constraint rule base for each configuration item's identifier, code path, parameter range, modification example, verification script, and other constraint information, authoritative and definite verification basis can be provided for subsequent automated modification of hardware parameters of large language models. This effectively constrains the model output boundary, reduces the risk of configuration item, path, and parameter format errors caused by AI illusions, and ensures that the embedded underlying configuration modification work is safe and controllable.

[0052] In one embodiment, step S202 includes: Each underlying configuration item is bound to its corresponding constraint rule to generate multiple configuration constraint records; these multiple configuration constraint records are stored in a preset database to obtain a structured constraint rule library.

[0053] In this embodiment of the application, the underlying configuration items and their constraint information are bound one by one to form independent records, and then uniformly stored in the database to complete the final construction of the structured constraint rule library.

[0054] For example, each modifiable underlying configuration item is associated and bound with the established constraint rules to generate a complete configuration constraint record. All configuration constraint records are then batch-written into a pre-prepared lightweight database or relational data table, ultimately forming a structured constraint rule library that can be retrieved and queried later. For instance, the backlight current configuration item can be bound to its configuration identifier, code path, value range, standard example, and verification script path to generate a configuration constraint record. Records corresponding to other configuration items, such as screen sleep delay, are then stored in the data table, thus building a complete rule library.

[0055] In the above method, the underlying configuration items and constraint rules are bound one by one to generate configuration constraint records and stored in the database to form a structured constraint rule library. This enables centralized and standardized management of configuration constraint information, facilitates rapid retrieval and querying in the future, ensures stable and reliable data reading during large model matching and verification, improves parameter verification efficiency, and provides persistent and reusable rule support for automated modification of embedded hardware configuration.

[0056] In one embodiment, see Figure 3 This is a schematic diagram of an identifier matching process provided in an embodiment of this application, such as... Figure 3 As shown, it includes: S301, if the first matching result indicates that the first configuration identifier does not exist in the structured constraint rule base, then obtain the prompt word; wherein, the prompt word is generated based on the first matching result, the structured constraint rule base, and the natural language instruction.

[0057] In this embodiment of the application, when the parsed configuration identifier fails the validity check or the configuration cannot be found in the rule base, a feedback prompt is generated and then sent to the large model to guide the model to re-understand the user's needs and avoid directly executing illegal configuration modification operations.

[0058] For example, when the verification determines that the first configuration identifier is not included in the structured constraint rule base, the system combines the failed matching result, the existing list of modifiable configurations in the rule base, and the user's initial natural language command to generate a corresponding prompt word to guide the large language model to re-infer and parse the modification request. For example, if the user inputs the command "Change the screen voltage to 12V", the parsed configuration identifier is CONFIG_SCREEN_VOLT. After searching, it is found that this identifier does not exist in the rule base. The system then generates a prompt word: "The configuration item you requested to modify is not in the allowed modification list. Please refer to the modifiable items in the rule base to re-identify the user's modification intent," and sends this prompt word, along with the rule base information and the original command, to the large language model.

[0059] S302, based on the prompt words, re-extract the second configuration identifier and second configuration parameters corresponding to the natural language instruction.

[0060] In this embodiment, the generated prompt words are input into the large language model, which guides the model to re-parse the original natural language instructions, re-identify the user's modification requirements, and output a new set of configuration identifiers and configuration parameters to correct the results of the previous parsing error.

[0061] For example, after receiving a prompt word generated upon a failed match, the large language model, combined with the list of allowed configuration items in the structured constraint rule base, rereads the original natural language instruction and performs semantic parsing again to extract a new second configuration identifier and its corresponding second configuration parameter. For instance, if the user's original instruction is "change the screen voltage to 12V", the first round of parsing results in the non-existent identifier CONFIG_SCREEN_VOLT, leading to a match failure. After receiving the prompt word, the model re-identifies the user's intent by referring to the rule base, recognizing that the user actually wants to modify the backlight current, and re-extracts the second configuration identifier CONFIG_BACKLIGHT_CURRENT and the second configuration parameter 500mA.

[0062] S303, perform a matching check on the second configuration identifier according to the structured constraint rule base to obtain the second matching result.

[0063] In this embodiment of the application, the second configuration identifier output after the large model is re-parsed is validated again to check whether the identifier exists in the structured constraint rule base and to determine whether the result after re-parse is legal and usable.

[0064] For example, using the re-extracted second configuration identifier as the search keyword, the structured constraint rule base is queried. The second configuration identifier is compared with all configuration identifiers stored in the base, generating the corresponding second matching result. After the previous round of prompting and guidance, the second configuration identifier CONFIG_BACKLIGHT_CURRENT is obtained. The system searches the rule base and finds that the identifier already exists, so the second matching result is a match. If the identifier obtained after re-parsing is still not in the base, the second matching result is a miss, and the prompt-re-parsing process can be entered again.

[0065] S304. If the second matching result indicates that the second configuration identifier does not exist in the structured constraint rule base, and the number of matches corresponding to the second matching result reaches the first preset number, then the matching process is terminated and an early warning is issued.

[0066] In this embodiment of the application, when the configuration identifier obtained by the large model through multiple re-parsings fails to pass the verification and the number of retries reaches the preset threshold, the retry will stop, the matching process will be stopped, and an early warning will be issued to prevent the system from falling into an infinite loop.

[0067] For example, the system counts the number of times matching verification has been performed. When the second matching result still determines that the second configuration identifier is not in the structured constraint rule base, and the cumulative number of matches equals the pre-set first preset number, the matching-re-parsing loop is immediately terminated, and an early warning is output to inform the user that the modification requirement cannot be recognized or is not within the scope of modification. For example, if the first preset number is set to 2, and the configuration identifier obtained after two rounds of parsing verification does not match the rule base, the system will not guide the model to re-infer, will terminate the matching process, and will pop up an early warning: "Multiple recognition failures, the configuration item you want to modify does not support adjustment."

[0068] In the above method, when the configuration identifier fails to match for the first time, a guiding prompt word is generated by combining the matching result, rule base and original instruction to drive the large model to re-parse and extract the configuration information for secondary matching and verification. At the same time, a matching retry limit is set and the process is terminated and a warning is issued after the limit is exceeded. This not only gives the large model the opportunity to correct errors and retry, improving the probability of successful instruction parsing, but also prevents infinite loop retry, timely detects unrecognized modification requirements, and ensures process stability.

[0069] S104, if the first matching result indicates that a first configuration identifier exists in the structured constraint rule base, then according to the first constraint rule corresponding to the first configuration identifier in the structured constraint rule base, the first configuration parameter modification configuration operation is performed to obtain the first target configuration data.

[0070] In this embodiment of the application, provided that the verification is successful and the configuration identifier is legal and valid, the complete set of constraint rules corresponding to the configuration in the rule base is retrieved, the parameters are modified according to the rule requirements, and the final modified configuration data is generated.

[0071] In the above method, after the verification is successful, the parameters are rewritten according to the corresponding constraint rules. This approach adds a deterministic rule verification checkpoint after the large language model generates the modification instructions and before they are actually written into the underlying code. This avoids the problems of the large language model generating illusions, fabricating non-existent configuration items, and outputting illegal modification paths due to its probability generation mechanism. It eliminates the need for manual review to identify errors, retains the automation convenience of issuing modification instructions from natural language, and uses the whitelist forced matching mechanism of the rule base to constrain the scope of modification to legally modifiable underlying configuration items. This reduces device malfunctions caused by invalid modifications and illegal parameter writing, and improves the reliability and security of the automated modification process of Android embedded underlying hardware configuration.

[0072] In one embodiment, see Figure 4 This is a schematic diagram of the execution configuration modification process provided in an embodiment of this application, as shown below. Figure 4 As shown, step S104 includes: S401 determines the target code path and standard modification examples based on the structured constraint rule base.

[0073] In this embodiment of the application, the storage location of the file to be modified and the code template for reference are read from the structured constraint rule base, so as to provide accurate modification address and writing format basis for subsequent modification parameters.

[0074] For example, the system uses the validated configuration identifier as an index to search the structured constraint rule base and extract the target code path and standard modification example corresponding to the configuration item. For instance, if the validated configuration identifier is CONFIG_BACKLIGHT_CURRENT, the system queries the rule base and obtains the target code path as kernel / drivers / video / backlight / panel.c, and the standard modification example as #definePANEL_CURRENT500 / / ma. Subsequently, the file under this path can be opened, and the parameters can be rewritten by referring to the example.

[0075] S402, invoke the code editor so that the code editor performs the first configuration parameter modification operation on the target code according to the target code path and standard modification example, and obtains the first target configuration data.

[0076] In this embodiment, a separate code editor tool is invoked to locate the specified source code file, replace the parameter values ​​according to the example format, and generate the modified configuration code data to achieve automated rewriting of the underlying parameters.

[0077] For example, the system sends a command to the code editor, passing in the target code path obtained from the query, a standard modification example, and the first configuration parameter. The code editor jumps to the target path, opens the source code file, finds the configuration code line corresponding to the example, and replaces only the original value in the example with the first configuration parameter provided by the user. The rest of the code text, format, and comments remain unchanged. After the modification is completed, the first target configuration data is generated. For example, if the target code path is kernel / drivers / video / backlight / panel.c, the standard modification example is #define PANEL_CURRENT 500 / / ma, and the first configuration parameter is 550ma, the code editor will obtain the first target configuration data after modification: #define PANEL_CURRENT 550 / / ma.

[0078] In the above method, by reading the target code path and standard modification examples from the structured constraint rule library, and then having the code editor complete the parameter rewriting by referring to the examples, the code modification location and writing format can be strictly limited, avoiding arbitrary modification of irrelevant code and generation of incorrect syntax in large models, ensuring that the underlying configuration modification actions are precise and controllable, and improving the correctness of automated modification results.

[0079] In one embodiment, see Figure 5 This is a schematic diagram of the configuration verification process provided in an embodiment of this application, as shown below. Figure 5 As shown, it includes: S501, after obtaining the first target configuration data, determines the path of the first verification script based on the structured constraint rule library.

[0080] In this embodiment of the application, after modifying the code to generate the target configuration data, the storage address of the corresponding verification script is retrieved from the structured constraint rule library to prepare for the next step of checking whether the modification result is legal.

[0081] For example, using the first configuration identifier that has already passed verification as the search index, the structured constraint rule base is queried to read the storage address of the verification script bound to the configuration item, thus obtaining the path of the first verification script. For instance, if the backlight current parameter is modified, the corresponding configuration identifier is CONFIG_BACKLIGHT_CURRENT. After querying the rule base, the path of the first verification script is found to be tools / check_backlight.sh. This script can then be run to verify the configuration modification result.

[0082] S502, Obtain the first verification script based on the first verification script path.

[0083] In this embodiment, the system uses the first verification script path to locate the script file in the server or project directory, reads the file content, and loads the executable first verification script. For example, if the first verification script path is tools / check_backlight.sh, the system finds the file based on this path, reads the script code, obtains the backlight current verification script, and uses it to perform verification checks on the first target configuration data.

[0084] S503, execute the first verification script to verify the first target configuration data and obtain the first verification result.

[0085] In this embodiment, a verification script is run to perform compliance checks on the target configuration data after the previous step of modification, determine whether the parameters meet the requirements of value range, format, etc., and output the verification results.

[0086] For example, the system executes the first verification script, passing the first target configuration data to the script for testing. The script checks whether the parameter values, units, and writing format meet the constraint rules, and returns the first verification result after execution. A return value of 0 indicates successful verification, while a non-zero value indicates failure. For instance, if the first target configuration data is `#definePANEL_CURRENT 550 / / ma`, running the `check_backlight.sh` script verifies that 550ma falls within the 100-600ma range, returning a value of 0, thus obtaining the first verification result of success. If the parameter is 700ma, exceeding the range, the script returns a non-zero value, indicating verification failure.

[0087] S504, if the first verification result indicates that the verification failed, the first target configuration data is restored to the initial state, and the parameter modification configuration operation is re-executed according to the structured constraint rule base to obtain the second target configuration data.

[0088] In this embodiment of the application, if the verification fails, the code change is undone, the original configuration content before the modification is restored, and then the parameter modification is executed again according to the constraint rules to generate new configuration data.

[0089] For example, before modifying parameters, the system pre-saves a snapshot of the original file or generates a record of the differences between the original and modified files. When verification fails and a rollback is triggered, a Diff file difference comparison tool is called to compare the modified file with the original version file, locate all newly added or modified lines of code, and only undo the changes made in this instance, leaving the rest of the original code unchanged. The target source code file is restored within milliseconds. Then, based on the corresponding constraint information in the structured constraint rule library, the parameter rewriting operation is performed again to generate the second target configuration data. For example, if the backlight current is modified to 700mA, the script detects that the value exceeds the legal range of 100-600mA, and the verification fails. The system restores the panel.c file to its original code before the modification, and then re-selects a compliant parameter of 500mA for rewriting, obtaining the second target configuration data #define PANEL_CURRENT 500 / / ma.

[0090] S505, execute the verification script corresponding to the second target configuration data to verify the second target configuration data and obtain the second verification result.

[0091] In this embodiment of the application, the verification script is run again on the second target configuration data after modification to check whether the newly generated configuration parameters meet the specifications and obtain a new round of verification judgment results.

[0092] For example, the verification script corresponding to the configuration item is invoked, and the detection program is run with the second target configuration data as the verification object. It checks whether the parameter values, formats, and units meet the requirements of the constraint rules. After the script finishes running, the second verification result is output. A return value of 0 indicates that the verification is successful, and a non-zero value indicates that the verification failed. For example, if the verification fails, the second target configuration data #definePANEL_CURRENT500 / / ma is regenerated, and the tools / check_backlight.sh verification script is run. The script checks that 500ma is within the legal range of 100-600ma, and the script returns a value of 0, resulting in a successful second verification result.

[0093] S506, if the second verification result indicates that the verification failed, and the number of verifications corresponding to the second verification result reaches the second preset number, then it is determined that the parameter modification configuration is abnormal.

[0094] In this embodiment of the application, when the regenerated configuration data still fails to be verified and the number of retry verifications has reached a preset threshold, it is determined that the parameter modification task has an anomaly and the modification will no longer be retried.

[0095] For example, the system accumulates the number of verification attempts after the current configuration modification. If the second verification result is still unqualified, and the accumulated verification count equals the second preset number, the process of repeatedly rolling back and rewriting the configuration is stopped, and this modification task is marked as an abnormal parameter modification configuration. For example, if the second preset number is set to 2; the first modification of the backlight current to 700mA fails verification, after rolling back, a new 650mA is generated and verified again, but it still exceeds the legal range of 100-600mA. At this point, the verification retries have reached the upper limit, and this parameter modification configuration is determined to be abnormal.

[0096] After the system reaches its maximum number of retries and determines that the modification is abnormal, it uses Diff comparison to completely restore the target source code file. It then sends an error message to the user, such as "Parameter write error, restored." For example, if two modifications to the backlight current parameter verification fail, the system rolls back the panel.c file, returning it to its initial version, displays an error message, and terminates the current configuration modification task.

[0097] In the above method, after modification, a dedicated verification script is invoked to check the configuration data. If verification fails, the file is automatically restored and modified again, while a verification retry limit is set. Through the closed-loop mechanism of write-verify-rollback-retry, format errors and out-of-bounds parameters can be intercepted in a timely manner, illegal changes can be undone, and incorrect configurations cannot be written to the underlying code. The retry limit prevents the process from going into an infinite loop, quickly identifies abnormal tasks, and effectively improves the security and stability of embedded hardware parameter modification.

[0098] In one embodiment, see Figure 6 This is a schematic diagram of the process for generating an execution report provided in an embodiment of this application, such as... Figure 6 As shown, it includes: S601, obtain the execution operation log during the parameter modification and configuration process of the target hardware device.

[0099] In this embodiment of the application, the operation records of each step in the entire process of modifying the underlying hardware parameters are collected and saved to generate an operation log, which facilitates subsequent tracing of problems and troubleshooting.

[0100] For example, after the parameter modification task is started, the system records key information at each stage, including the original natural language commands, the configuration identifier extracted in each round, the matching results, code modification records, Diff rollback operations, verification script execution status, verification results, retry count, and final error messages, summarizing them into a complete execution operation log. For example, in the case of a backlight current modification failure, the log will record: user commands, the first round configuration identifier CONFIG_BACKLIGHT_CURRENT, parameter modification of 700mA, verification failure, Diff rollback record, the second parameter modification of 650mA, verification failure, reaching the retry limit, and outputting the error message "Parameter write error, restored," etc.

[0101] S602, Generate an execution report based on the execution operation log.

[0102] In this embodiment of the application, the operation log information of the entire parameter modification process is sorted and summarized to generate a complete and readable execution report, which retains all execution traces of this modification task, making it convenient for post-event verification and problem review.

[0103] For example, the system reads the execution log of this task, extracts the user's original instructions, the matching results of each round of configuration identifiers, code modification records, diff file restoration actions, verification script execution results, retry count, and final success or error message. This information is then organized and arranged according to a fixed format to generate a structured execution report. For instance, if the task terminates after two failed verifications of modifying the backlight current parameters, the generated execution report will specify the user's modification requirements, the two modified parameter values, the reason for the verification failure, file rollback records, the number of retryes exceeding the limit, and the final result "Parameter write error, restored."

[0104] S603 sends the execution report to the display terminal for tracing the executed operations.

[0105] In this embodiment, the generated execution report is pushed and displayed on the display terminal for R&D personnel to view, enabling traceability and verification of the entire parameter modification process.

[0106] For example, the system sends the completed execution report to a display terminal such as a computer screen. The terminal loads and displays the entire process record in the report, allowing staff to view the execution status of each step and pinpoint the point where the problem occurred. For instance, if the backlight current modification task terminates abnormally, an execution report containing all operation traces is sent to the developer's computer terminal interface. The operator can then review the report to find that the write failure was caused by parameters exceeding the value range, thus tracing the problem back to its source.

[0107] In the above method, by collecting the execution log of the entire process of parameter modification, an automatic traceable execution report is generated and pushed to the display terminal, which completely preserves the operation trace of each step, making it convenient for staff to troubleshoot and review problems afterward. This achieves auditability and traceability of the entire automated configuration modification process, and improves the operation and maintenance management capabilities of the solution.

[0108] See Figure 7 This is a schematic diagram of the overall structure of an Android embedded device low-level parameter configuration method based on a large language model provided in an embodiment of this application, as shown below. Figure 7 As shown, specifically: Phase 1: Intent parsing and rule-based forced matching (probability zone - large model inference stage) Start: The engineer enters a natural language command to modify the underlying hardware parameters.

[0109] LLM inference extraction: The large language model reads the instructions and parses out the modification actions to be performed, the target configuration identifier, and the target parameter values.

[0110] Whitelist comparison and judgment: The system queries the structured rule base (work manual) to determine whether the configuration item just extracted exists in the whitelist that allows modification.

[0111] Match successful: Proceed to Phase Two: Deterministic Write and Dual Verification Match failed: Proceed to retry process Matching failure - retry guidance: The retry counter N is incremented by 1, the rule base context and failure information are encapsulated into prompt words and given back to the LLM, allowing the large model to infer and parse the user command again, returning to step 2.

[0112] Retry limit judgment: Repeatedly retry until the preset retry limit N is reached, then stop parsing, output warning: instruction is unacceptable, process terminates, and then jump to stage three to generate report.

[0113] Phase Two: Deterministic Writing and Double Verification (Deterministic Fence Zone, Detached from Large Model Probability Generation, Execution Code Modification) Prerequisite: Phase 1 match successful Read the structured rule base: retrieve the information bound to this configuration item: code file path, parameter format, standard modification example, and validation script path.

[0114] Code editing tool rewriting: Strictly follow the example template, only replace the parameter values, keep the rest of the code, format, and comments as they are, and generate the modified code data.

[0115] Run the verification script: Calls the dedicated verification program script for this item to automatically check constraints such as parameter format, numerical range, and units.

[0116] Verification result judgment Verification passed (return value 0): The changes are confirmed to be effective, and the process proceeds to stage three.

[0117] Verification failed (returns a non-zero value): Performs an atomic automatic rollback, using Diff difference comparison technology to restore the file to its original state before modification in milliseconds.

[0118] Modify retry: Increment the retry counter M by 1, and re-run the entire modification process (return to the steps of reading the rule base and rewriting the code).

[0119] Modify the retry limit judgment: Repeatedly modify the verification. If the preset retry limit M is reached, terminate the write process, issue an error warning, and jump to stage three.

[0120] Phase 3: Results Summary and Reporting (Full Process Archiving and Traceability) Regardless of whether the task is ultimately successfully modified, fails to be parsed, or terminates due to an error in the write verification, the system summarizes the operation logs for all steps.

[0121] Generate a structured, traceable execution report.

[0122] The report feedback is displayed on the engineer's interface, allowing staff to view the complete execution record and trace the entire parameter modification task.

[0123] It should be understood that the sequence number of each step in the above embodiments does not imply the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of this application.

[0124] Corresponding to the Android embedded device low-level parameter configuration method based on a large language model in the above embodiment, Figure 8 This is a structural block diagram of an Android embedded device low-level parameter configuration device based on a large language model provided in an embodiment of this application. For ease of explanation, only the parts related to the embodiment of this application are shown.

[0125] Reference Figure 8 The device includes: Module 81, which builds a structured constraint rule library, is used for: Retrieve multiple low-level configuration items in the target hardware device that are allowed to be modified; Establish corresponding constraint rules for each underlying configuration item; the constraint rules include the configuration identifier, code path, parameter type, value range, standard modification example, and validation script path for each underlying configuration item. A structured constraint rule library is generated based on multiple underlying configuration items and their corresponding constraint rules.

[0126] The data receiving module 82 is used to receive natural language instructions for modifying hardware configuration parameters; The identifier parameter extraction module 83 is used to extract the first configuration identifier and the first configuration parameter corresponding to the natural language instruction; The identifier matching module 84 is used to perform matching on the first configuration identifier according to the pre-built structured constraint rule library to obtain the first matching result; wherein, the structured constraint rule library contains multiple underlying configuration items and constraint rule information corresponding to each underlying configuration item; The parameter configuration module 85 is used to perform a modification configuration operation on the first configuration parameter according to the first constraint rule corresponding to the first configuration identifier in the structured constraint rule library if the first matching result indicates that the first configuration identifier exists, so as to obtain the first target configuration data.

[0127] Optionally, the structured constraint rule base building module 81 is also used for: Each underlying configuration item is bound to its corresponding constraint rule, generating multiple configuration constraint records; Multiple configuration constraint records are stored in a preset database to obtain a structured constraint rule library.

[0128] Optionally, the identifier matching module 84 is also used for: If the first matching result indicates that the first configuration identifier does not exist in the structured constraint rule base, then a prompt word is obtained; wherein, the prompt word is generated based on the first matching result, the structured constraint rule base, and natural language instructions; Re-extract the second configuration identifier and second configuration parameters corresponding to the natural language instructions based on the prompt words; Based on the structured constraint rule base, a matching check is performed on the second configuration identifier to obtain the second matching result; If the second matching result indicates that the second configuration identifier does not exist in the structured constraint rule base, and the number of matches corresponding to the second matching result reaches the first preset number, then the matching process is terminated and an early warning is issued.

[0129] Optionally, parameter configuration module 85 is also used for: The target code path and standard modification examples are determined based on the structured constraint rule base; Invoke the code editor so that the code editor can perform the first configuration parameter modification operation on the target code according to the target code path and standard modification example, and obtain the first target configuration data.

[0130] The Android embedded device low-level parameter configuration device 8 based on a large language model also includes a configuration verification module 86, used for: After obtaining the first target configuration data, the path of the first verification script is determined based on the structured constraint rule base; Obtain the first verification script based on the first verification script path; Execute the first verification script to verify the first target configuration data and obtain the first verification result; If the first verification result indicates that the verification failed, the first target configuration data is restored to its initial state, and the parameter modification configuration operation is re-executed according to the structured constraint rule base to obtain the second target configuration data. Execute the verification script corresponding to the second target configuration data to verify the second target configuration data and obtain the second verification result; If the second verification result indicates that the verification failed, and the number of verifications corresponding to the second verification result reaches the second preset number, then the parameter modification configuration is determined to be abnormal.

[0131] The Android embedded device low-level parameter configuration device 8 based on a large language model also includes a report generation module 87, used for: Obtain the execution operation log during the parameter modification and configuration process of the target hardware device; Generate an execution report based on the execution operation log; The execution report is sent to the display terminal for the purpose of tracing the execution operation.

[0132] It should be noted that the information interaction and execution process between the above-mentioned devices / units are based on the same concept as the method embodiments of this application. For details on their specific functions and technical effects, please refer to the method embodiments section, and they will not be repeated here.

[0133] in addition, Figure 8 The Android embedded device low-level parameter configuration device based on the large language model shown can be a software unit, hardware unit, or a combination of software and hardware built into an existing terminal device. It can also be integrated into the terminal device as an independent widget, or exist as an independent terminal device.

[0134] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the above-described division of functional units and modules is merely an example. In practical applications, the above functions can be assigned to different functional units and modules as needed, that is, the internal structure of the device can be divided into different functional units or modules to complete all or part of the functions described above. The functional units and modules in the embodiments can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit. Furthermore, the specific names of the functional units and modules are only for easy differentiation and are not intended to limit the scope of protection of this application. The specific working process of the units and modules in the above system can be referred to the corresponding process in the foregoing method embodiments, and will not be repeated here.

[0135] Figure 9 This is a schematic diagram of the structure of the terminal device provided in the embodiments of this application. For example... Figure 9 As shown, the terminal device 9 of this embodiment includes: at least one processor 90 ( Figure 9 (Only one is shown in the image) a processor, a memory 91, and a computer program 92 stored in the memory 91 and capable of running on at least one processor 90. When the processor 90 executes the computer program 92, it implements the steps in any of the above embodiments of the Android embedded device low-level parameter configuration method based on a large language model.

[0136] The terminal device can be a computing device such as a desktop computer, laptop, handheld computer, or cloud server. This terminal device may include, but is not limited to, a processor and memory. Those skilled in the art will understand that... Figure 9 This is merely an example of terminal device 9 and does not constitute a limitation on terminal device 9. It may include more or fewer components than shown in the figure, or combine certain components, or different components, such as input / output devices, network access devices, etc.

[0137] The processor 90 may be a Central Processing Unit (CPU), or it may be other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. A general-purpose processor may be a microprocessor or any conventional processor.

[0138] In some embodiments, memory 91 may be an internal storage unit of terminal device 9, such as a hard disk or memory of terminal device 9. In other embodiments, memory 91 may be an external storage device of terminal device 9, such as a plug-in hard disk, smart media card (SMC), secure digital (SD) card, flash card, etc., equipped on terminal device 9. Furthermore, memory 91 may include both internal storage units and external storage devices of terminal device 9. Memory 91 is used to store operating system, application programs, bootloader, data, and other programs, such as program code of computer programs. Memory 91 can also be used to temporarily store data that has been output or will be output.

[0139] This application also provides a computer-readable storage medium storing a computer program, which, when executed by a processor, can implement the steps in the above-described method embodiments.

[0140] This application provides a computer program product that, when run on a terminal device, enables the terminal device to implement the steps described in the various method embodiments above.

[0141] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the computer program that instructs related hardware to implement all or part of the processes in the above embodiments of this application can be stored in a computer-readable storage medium. When executed by a processor, this computer program can implement the steps of the various method embodiments described above. The computer program includes computer program code, which can be in the form of source code, object code, executable files, or certain intermediate forms. A computer-readable medium can include at least: any entity or device capable of carrying computer program code to a device / terminal equipment, a recording medium, a computer memory, a read-only memory (ROM), a random access memory (RAM), an electrical carrier signal, a telecommunication signal, and a software distribution medium. Examples include USB flash drives, portable hard drives, magnetic disks, or optical disks. In some jurisdictions, according to legislation and patent practice, computer-readable media cannot be electrical carrier signals or telecommunication signals.

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

[0143] Those skilled in the art will recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

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

[0145] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0146] The above embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit them. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of this application, and should all be included within the protection scope of this application.

Claims

1. A method for configuring low-level parameters of Android embedded devices based on a large language model, characterized in that, The method includes: Receive natural language commands to modify hardware configuration parameters; Extract the first configuration identifier and the first configuration parameter corresponding to the natural language instruction; The first configuration identifier is matched according to the pre-built structured constraint rule library to obtain the first matching result; wherein, the structured constraint rule library contains multiple underlying configuration items and constraint rule information corresponding to each underlying configuration item; If the first matching result indicates that the first configuration identifier exists in the structured constraint rule base, then according to the first constraint rule corresponding to the first configuration identifier in the structured constraint rule base, the first configuration parameter modification configuration operation is executed to obtain the first target configuration data; The steps for generating the structured constraint rule base include: Retrieve multiple low-level configuration items in the target hardware device that are allowed to be modified; Establish corresponding constraint rules for each of the underlying configuration items; wherein, the constraint rules include the configuration identifier, code path, parameter type, value range, standard modification example, and validation script path for each underlying configuration item; The structured constraint rule library is generated based on the multiple underlying configuration items and their corresponding constraint rules. Each of the underlying configuration items is bound to its corresponding constraint rule to generate multiple configuration constraint records; Multiple configuration constraint records are stored in a preset database to obtain the structured constraint rule library.

2. The method for configuring low-level parameters of Android embedded devices based on a large language model as described in claim 1, characterized in that, The method further includes: If the first matching result indicates that the first configuration identifier does not exist in the structured constraint rule base, then a prompt word is obtained; wherein, the prompt word is generated based on the first matching result, the structured constraint rule base, and the natural language instruction; Based on the prompt words, the second configuration identifier and second configuration parameters corresponding to the natural language instruction are extracted again; Based on the structured constraint rule base, a matching check is performed on the second configuration identifier to obtain a second matching result; If the second matching result indicates that the second configuration identifier does not exist in the structured constraint rule base, and the number of matches corresponding to the second matching result reaches the first preset number, then the matching process is terminated and an early warning is issued.

3. The method for configuring low-level parameters of Android embedded devices based on a large language model as described in claim 1, characterized in that, The step of performing a modification configuration operation on the first configuration parameter according to the first constraint rule in the structured constraint rule base corresponding to the first configuration identifier to obtain the first target configuration data includes: The target code path and standard modification examples are determined based on the structured constraint rule base. Invoke the code editor so that the code editor performs the modification configuration operation of the first configuration parameter on the target code according to the target code path and the standard modification example, and obtains the first target configuration data.

4. The method for configuring low-level parameters of Android embedded devices based on a large language model as described in claim 1, characterized in that, The method further includes: After obtaining the first target configuration data, the first verification script path is determined according to the structured constraint rule base; Obtain the first verification script based on the first verification script path; The first verification script is executed to verify the first target configuration data and obtain a first verification result. If the first verification result indicates that the verification failed, the first target configuration data is restored to its initial state, and the parameter modification configuration operation is re-executed according to the structured constraint rule base to obtain the second target configuration data. Execute the verification script corresponding to the second target configuration data to verify the second target configuration data and obtain the second verification result; If the second verification result indicates that the verification failed, and the number of verifications corresponding to the second verification result reaches the second preset number, then it is determined that the parameter modification configuration is abnormal.

5. The method for configuring low-level parameters of Android embedded devices based on a large language model as described in any one of claims 1-4, characterized in that, The method further includes: Obtain the execution operation log during the parameter modification and configuration process of the target hardware device; Generate an execution report based on the execution operation log; The execution report is sent to the display terminal for tracing the execution operation.

6. A low-level parameter configuration device for Android embedded devices based on a large language model, characterized in that, include: The data receiving module is used to receive natural language commands that modify hardware configuration parameters; The identifier parameter extraction module is used to extract the first configuration identifier and the first configuration parameter corresponding to the natural language instruction; The identifier matching module is used to perform matching on the first configuration identifier according to the pre-built structured constraint rule library to obtain a first matching result; wherein, the structured constraint rule library contains multiple underlying configuration items and constraint rule information corresponding to each underlying configuration item; The parameter configuration module is used to perform a modification configuration operation on the first configuration parameter according to the first constraint rule corresponding to the first configuration identifier in the structured constraint rule library if the first matching result indicates that the first configuration identifier exists in the structured constraint rule library, so as to obtain the first target configuration data. The structured constraint rule library building module is used for: Retrieve multiple low-level configuration items in the target hardware device that are allowed to be modified; Establish corresponding constraint rules for each of the underlying configuration items; wherein, the constraint rules include the configuration identifier, code path, parameter type, value range, standard modification example, and validation script path for each underlying configuration item; The structured constraint rule library is generated based on the multiple underlying configuration items and their corresponding constraint rules. Each of the underlying configuration items is bound to its corresponding constraint rule to generate multiple configuration constraint records; Multiple configuration constraint records are stored in a preset database to obtain the structured constraint rule library.

7. A terminal device, comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the computer program, it implements the method as described in any one of claims 1 to 5.

8. A computer-readable storage medium storing a computer program, characterized in that, When the computer program is executed by a processor, it implements the method as described in any one of claims 1 to 5.

Images