Task processing method and information processing method

Abstract

The invention discloses a task processing method and an information processing method. The task processing method comprises the steps that task information corresponding to a task instruction is received, the task instruction is an instruction received by a first application, and the task information conforms to an atomization standard protocol; analyzing the task information according to an atomization standard protocol to obtain task parameter information; and calling an atomic power corresponding to the task parameter information to execute a task corresponding to the task information to obtain an execution result, the atomic power being a power obtained by disassembling the function of the second application, and the atomic power conforming to an atomization standard protocol. According to the task processing method provided by the embodiment of the invention, the dependency between the first application and the second application can be reduced, and the security of the whole terminal is improved.

Description

Technical Field

[0001] This application belongs to the field of application technology, and in particular relates to a task processing method and an information processing method. Background Technology

[0002] Currently, some applications installed on a terminal typically integrate the software development kits (SDKs) of other applications to call some functions of those applications through the integrated SDKs. With the development of application intelligence, it is now common practice to select a primary application with voice assistant functionality on the terminal and integrate the SDKs of multiple secondary applications. This allows the primary application to receive user commands and then call the corresponding capabilities of the secondary applications through different SDKs, thereby achieving the goal of meeting diverse user needs with a single application.

[0003] However, multiple secondary applications typically involve iterative updates. Each update requires a corresponding update to the SDK for that secondary application, necessitating a re-release of the primary application. Furthermore, adding a new SDK for each secondary application necessitates reintegrating that SDK into the primary application. This approach of using a single application to meet diverse user needs leads to excessive dependencies between the primary and secondary applications. Problems with any component (including the primary application, multiple secondary applications, and multiple SDKs) can cause issues with the terminal, resulting in low overall terminal security. Summary of the Invention

[0004] This application provides a task processing method and an information processing method that can decouple the first application and the second application when using the capabilities of the second application through the first application, thereby reducing the dependency between the first application and the second application and improving the security of the entire terminal.

[0005] In a first aspect, embodiments of this application provide a task processing method, the method comprising:

[0006] Receive task information corresponding to a task instruction, wherein the task instruction is an instruction received by the first application, and the task information conforms to the atomicity standard protocol;

[0007] The task information is parsed according to the aforementioned atomization standard protocol to obtain task parameter information;

[0008] The atomic capabilities corresponding to the task parameter information are invoked to execute the task corresponding to the task information, and the execution result is obtained. The atomic capabilities are capabilities obtained by decomposing the functions of the second application, and the atomic capabilities conform to the atomication standard protocol.

[0009] In one possible implementation, the atomic standard protocol includes a permission part, a command part, and a parameter part; wherein, the permission part includes a plugin name, the command part includes a command corresponding to the plugin name, and the parameter part includes command parameters corresponding to the command;

[0010] The step of parsing the task information according to the atomicity standard protocol to obtain task parameter information includes:

[0011] Parse the permission portion of the task information to obtain at least one target plugin name;

[0012] Parse the command portion of the task information to obtain at least one target command corresponding to each target plugin name;

[0013] Parse the parameter portion of the task information to obtain at least one target command parameter corresponding to each target command.

[0014] In one possible implementation, the task parameter information includes the target plugin name, the task information includes the target display device identifier, and the step of calling the atomic capability corresponding to the task parameter information to execute the task corresponding to the task information and obtain the execution result includes:

[0015] Based on the correspondence between the display device identifier and the plug-in name, at least one first display device identifier corresponding to the target plug-in name is determined;

[0016] When at least one first display device identifier includes the target display device identifier, the target atomic capability corresponding to the target display device identifier is invoked to execute the task corresponding to the task information, and the execution result is obtained and displayed on the target display device corresponding to the target display device identifier. The target atomic capability is the atomic capability corresponding to the task parameter information.

[0017] In one possible implementation, after determining at least one first display device identifier corresponding to the target plugin name, the method further includes:

[0018] If at least one first display device identifier includes the target display device identifier, and the target display device corresponding to the target display device identifier does not support the target atomic capability call, the target atomic capability corresponding to the third display device identifier is invoked to execute the task corresponding to the task information, and an execution result is obtained. The display device corresponding to the third display device identifier supports the target atomic capability call.

[0019] The execution result is displayed on the target display device.

[0020] In one possible implementation, the first application is set in a second display device corresponding to the second display device identifier, the second display device is controlled by a first control unit, and the target display device is controlled by a target control unit;

[0021] The step of invoking the target atomic capability corresponding to the target display device identifier to execute the task corresponding to the task information includes:

[0022] The task information is sent from the first control unit to the target control unit.

[0023] The target control unit invokes the target atomic capabilities corresponding to the target display device to execute the task corresponding to the task information.

[0024] In one possible implementation, after determining at least one first display device identifier corresponding to the target plugin name, the method further includes:

[0025] If the target display device identifier is not included in the at least one first display device identifier, the target atomic capability corresponding to the fourth display device identifier is invoked to execute the task corresponding to the task information and obtain the execution result. The fourth display device identifier is any one of the at least one first display device identifier.

[0026] The execution result is displayed on the target display device corresponding to the target display device identifier.

[0027] In one possible implementation, the step of invoking the target atomic capability corresponding to the fourth display device identifier to execute the task corresponding to the task information and obtain the execution result includes:

[0028] When the display device corresponding to the fourth display device identifier is controlled by the second control unit, and the target display device is controlled by the target control unit, the second control unit calls the target atomic capability corresponding to the fourth display device identifier to execute the task corresponding to the task information, and obtains the execution result;

[0029] The execution result is sent to the target control unit through the second control unit;

[0030] Displaying the execution result on the target display device corresponding to the target display device identifier includes:

[0031] The target control unit controls the target display device to display the execution result.

[0032] In one possible implementation, before determining at least one first display device identifier corresponding to the target plugin name based on the correspondence between the display device identifier and the plugin name, the method further includes:

[0033] Multiple display devices are scanned to determine multiple plug-in information corresponding to each of the multiple display devices. Each display device corresponds to a display device identifier, and the plug-in information includes the plug-in name.

[0034] Store the correspondence between the display device identifier and the plugin name.

[0035] In one possible implementation, after obtaining the execution result, the method further includes:

[0036] Display the first content corresponding to the execution result in the first application;

[0037] If the target command is a callback command and the associated content corresponding to the execution result in the second application is updated, the first display content in the first application is updated using the associated content to obtain the second display content.

[0038] Secondly, embodiments of this application provide an information processing method, the method comprising:

[0039] Obtain functional information from the second application;

[0040] The functional information is broken down to obtain multiple sub-functional information. Each sub-functional information includes a plugin name, multiple commands corresponding to the plugin name, and multiple command parameters corresponding to each command.

[0041] Each of the sub-functional information is encapsulated according to the atomization standard protocol to obtain functional plug-ins corresponding to the multiple sub-functional information, and each functional plug-in includes multiple atomic capabilities.

[0042] In one possible implementation, the encapsulation of each sub-functional information according to the atomicity standard protocol to obtain functional plug-ins corresponding to the plurality of sub-functional information includes:

[0043] Obtain the plugin name annotation corresponding to the plugin name, the command annotation corresponding to the command, the command parameter annotation corresponding to the command parameters, the execution result description annotation, and the task identifier annotation corresponding to the task information;

[0044] For each of the sub-function information, the plugin name and its corresponding plugin name annotation, the command and its corresponding command annotation, the command parameters and their corresponding command parameter annotation, the execution result description annotation, and the task identifier annotation are encapsulated according to the atomicity standard protocol to obtain the function plugins corresponding to the multiple sub-function information respectively.

[0045] Thirdly, embodiments of this application provide a task processing apparatus, the apparatus comprising:

[0046] A receiving module is used to receive task information corresponding to a task instruction, wherein the task instruction is an instruction received by the first application, and the task information conforms to the atomicity standard protocol.

[0047] The parsing module is used to parse the task information according to the atomicity standard protocol to obtain task parameter information;

[0048] The execution module is used to call the atomic capabilities corresponding to the task parameter information to execute the task corresponding to the task information and obtain the execution result. The atomic capabilities are capabilities obtained by decomposing the functions of the second application, and the atomic capabilities conform to the atomication standard protocol.

[0049] Fourthly, embodiments of this application provide an information processing apparatus, which includes:

[0050] The acquisition module is used to acquire functional information from the second application;

[0051] The disassembly module is used to disassemble the functional information to obtain multiple sub-functional information. Each sub-functional information includes a plugin name, multiple commands corresponding to the plugin name, and multiple command parameters corresponding to each command.

[0052] The encapsulation module is used to encapsulate each of the sub-functional information according to the atomicity standard protocol to obtain functional plug-ins corresponding to the multiple sub-functional information, and each functional plug-in includes multiple atomic capabilities.

[0053] Fifthly, embodiments of this application provide an electronic device, which includes: a processor and a memory storing computer program instructions;

[0054] When the processor executes the computer program instructions, it implements the method in any one of the possible implementations of the first or second aspect described above.

[0055] Sixthly, embodiments of this application provide a computer-readable storage medium storing computer program instructions, which, when executed by a processor, implement the method in any of the possible implementations of the first or second aspect described above.

[0056] Seventhly, embodiments of this application provide a vehicle that includes at least one of the following:

[0057] As in any embodiment of the third aspect, the task processing apparatus;

[0058] Information processing apparatus as described in any embodiment of the fourth aspect;

[0059] The electronic device as described in any embodiment of the fifth aspect;

[0060] Computer-readable storage medium as in any embodiment of the sixth aspect.

[0061] In this embodiment, since both atomic capabilities and task information conform to the atomication standard protocol, it is possible to execute the task corresponding to the task information through the atomic capabilities corresponding to the task parameter information. Because atomic capabilities are capabilities obtained by decomposing the functions of the second application, by receiving the task information corresponding to the task instruction when the first application receives a task instruction, determining the task parameter information corresponding to the task information, and calling the atomic capabilities corresponding to the task parameter information to execute the task corresponding to the task information, the capabilities of the second application can be used to execute the task corresponding to the first application and obtain the execution result, without needing to integrate the SDK of the second application into the first application. Thus, when using the capabilities of the second application through the first application, the first application and the second application can be decoupled, reducing the dependency between the first and second applications, thereby improving the security of the entire terminal. Attached Figure Description

[0062] To more clearly illustrate the technical solutions of the embodiments of this application, the accompanying drawings used in the embodiments of this application will be briefly introduced below. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0063] Figure 1 This is a schematic diagram of a traditional inter-application capability interface calling scheme provided in an embodiment of this application;

[0064] Figure 2 This is a flowchart illustrating a task processing method provided in an embodiment of this application;

[0065] Figure 3 This is a schematic diagram of a standardized interface calling scheme after atomic capability standardization provided in an embodiment of this application;

[0066] Figure 4 This is a schematic diagram illustrating the registration of atomic capabilities to an atomic capability management platform, as provided in an embodiment of this application.

[0067] Figure 5 This is a schematic diagram of storage plug-in information provided in an embodiment of this application;

[0068] Figure 6 This is a schematic diagram of the first type of atomic capability call provided in the embodiments of this application;

[0069] Figure 7 This is a schematic diagram of the second type of atomic capability invocation provided in the embodiments of this application;

[0070] Figure 8 This is a schematic diagram of the third type of atomic capability invocation provided in the embodiments of this application;

[0071] Figure 9 This is a schematic diagram illustrating atomic capability invocation based on a single SOC, provided in an embodiment of this application.

[0072] Figure 10 This is a schematic diagram of the fourth type of atomic capability invocation provided in the embodiments of this application;

[0073] Figure 11 This is a schematic diagram illustrating atomic capability invocation based on multiple SOCs, provided in an embodiment of this application.

[0074] Figure 12 This is an overall schematic diagram of a plug-in routing rule provided in an embodiment of this application;

[0075] Figure 13 This is a schematic diagram of a long-connection bidirectional communication capability invocation logic provided in an embodiment of this application;

[0076] Figure 14 This is a flowchart illustrating an information processing method provided in an embodiment of this application;

[0077] Figure 15 This is a schematic diagram of a task processing method provided in an embodiment of this application;

[0078] Figure 16 This is a schematic diagram of the structure of a task processing device provided in an embodiment of this application;

[0079] Figure 17 This is a schematic diagram of the structure of an information processing device provided in an embodiment of this application;

[0080] Figure 18 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Detailed Implementation

[0081] To better understand the above-mentioned objectives, features, and advantages of this application, the solution of this application will be further described below. It should be noted that, unless otherwise specified, the embodiments and features described in these embodiments can be combined with each other.

[0082] Many specific details are set forth in the following description in order to provide a full understanding of this application, but this application may also be implemented in other ways different from those described herein; obviously, the embodiments in the specification are only some embodiments of this application, and not all embodiments.

[0083] It should be noted that, in this document, relational terms such as "first" and "second" are used merely 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 term "comprising" or any other variations thereof is intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus 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 apparatus. 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 apparatus that includes said element.

[0084] To better understand the background technology, a typical traditional inter-application capability interface call scheme is introduced below. A diagram illustrating this scheme can be seen as follows: Figure 1 As shown. From Figure 1 As can be seen, in the traditional solution, the implementation of function F specifically depends on SDK-A and SDK-B, and the corresponding interface calls are not consistent. This makes it impossible to change or add the use of a certain interface without altering the code of the application using the capability, resulting in lower security for the entire terminal. Furthermore, the numerous dependencies between the first and second applications lead to frequent releases and integrations of the first application, resulting in higher maintenance costs and lower operational efficiency.

[0085] In addition, in the development of existing application features, the componentization concept is an indispensable part of agile development. In a broad sense, all the encapsulated code that all features development depends on can be regarded as components, which can be divided into application program interface (API) level, software development kit (SDK) level and application level according to their granularity.

[0086] In practical development, existing component-based solutions typically encapsulate code capabilities on a business-by-business basis, according to their own specifications or agreements with interfacing parties, and ultimately provide these capabilities to the business users. Dependencies between different applications are mostly in the form of SDKs (jar / aar / libraries, etc.). The main shortcomings in the current component management and usage process include:

[0087] 1) Inflexible application feature iteration and fragmented functionality between applications: Existing component-based solutions typically involve single-point connections during application feature development, often relying on inter-application navigation when multiple application capabilities are involved. In the context of large-scale models, traditional component-based solutions are too rigid and lack flexibility, failing to meet the demands of generative applications. Generative applications based on new content production methods (AI Generated Content, AIGC) will experience a qualitative leap in the variety and quantity of component capabilities. The fragmented behavior of traditional component providers severely fragments the functionality of each application, limiting the efficient reuse of individual capabilities within each application, and failing to meet the demand for personalized generative applications tailored to each user through large-scale model algorithms.

[0088] 2) Inconsistent interface protocols hinder application self-learning capabilities: In traditional component-based platforms, the lack of a unified protocol for component integration, often relying on protocols customized by the application capability provider, results in multiple components having multiple different protocols. There are no standardized interfaces or related data protocols, leading to high customization among components. Consequently, once an application is released, its functionalities are fixed; adding new features requires a separate release, making it impossible to leverage AI to achieve self-learning expansion of capabilities without requiring new releases.

[0089] 3) Unfriendly development and maintenance: More features mean more dependencies, frequent releases, and high maintenance costs: A large application typically relies on multiple SDKs or other packages provided by different business units to implement features. The more features there are, the more SDKs and other components are required. If any component has a problem or feature is updated, the application needs to be re-integrated and released. At the same time, too many dependencies can also lead to a decrease in overall security.

[0090] Based on this, this application proposes a componentization scheme that can serve generative applications. This componentization scheme can be applied to vehicle scenarios. When applied to vehicle scenarios, by setting a unified interface protocol for the components involved in the scheme, applications only need to integrate one dependency, the Task Processing Unit (TPU), to use the atomic capabilities of any application across the entire vehicle domain. This enables self-learning expansion of the same application's functionality without secondary releases, allowing traditional applications to be transformed into artificial intelligence (AI) generative applications. The TPU can act as a central management role, coordinating task execution and information display on the Head Unit (HU) side of the in-vehicle infotainment system.

[0091] Therefore, the componentization scheme of this application can solve the following main problems:

[0092] 1) It integrates the full-domain application capabilities of the vehicle end, enabling flexible iteration of application features and solving the problems of inflexible application feature iteration and functional fragmentation between applications in traditional component-based solutions.

[0093] 2) Unified access suite enables unified protocol and unified management, solves the problem of inconsistent interface protocols among components, and enables atomic abstraction of the capabilities and data of each module in various vertical applications on the vehicle side. This allows the componentized interface to support the self-learning and expansion of AI application capabilities, ultimately achieving flexible personalized features.

[0094] 3) It integrates the full-domain capabilities of the vehicle, so that applications only need to rely on the TPU to use the full-domain capabilities, eliminating the need for individual dependencies and maintenance. This solves the problems of inefficient maintenance and frequent releases caused by excessive dependencies in traditional solutions.

[0095] Therefore, to address the problems of the prior art, embodiments of this application provide a task processing method, apparatus, information processing method, apparatus, device, storage medium, and vehicle. The task processing method can be applied to scenarios where capabilities in a second application are used through a first application. Specifically, the task processing method can be applied to vehicle scenarios. Furthermore, the task processing method can be executed by a processor corresponding to the task processing engine in a task processing system. The task processing system may include an interaction module, an information aggregation framework, a generative framework, a task processing engine, a first application, and a second application. The first application can be a blank application, a self-developed application, or a third-party application; no limitation is made here.

[0096] As an example, a user can issue a user command to the first application through the interaction module. Upon receiving the user command, the interaction module can determine the corresponding task description information using an AI big data model. This task description information can conform to the domain-specific language (DSL) of the AI ​​big data model. The interaction module can then send the task description information output by the AI ​​big data model to an information aggregation framework. The information aggregation framework can parse the task description information, identify the task information within it, and send the task information to the task processing engine. The task processing engine then executes the task corresponding to the task information, obtaining the execution result. The task information can conform to an atomicity standard protocol.

[0097] In the example above, after receiving task information, the task processing engine can invoke the atomic capabilities corresponding to the task information to execute the task and obtain the execution result. An atomic capability can be a small, independent, atomic functional module that can be dynamically loaded and invoked to implement specific business functions or services. Atomic capabilities can be set in a second application or exist independently of a second application; this is not limited here.

[0098] The following describes the task processing method applied to the task processing engine provided in the embodiments of this application.

[0099] Figure 2 A flowchart illustrating a task processing method provided in an embodiment of this application is shown.

[0100] like Figure 2 As shown, the task processing method provided in this application includes the following steps:

[0101] S210. Receive task information corresponding to the task instruction. The task instruction is the instruction received by the first application. The task information conforms to the atomicity standard protocol.

[0102] S220. Parse the task information according to the atomization standard protocol to obtain the task parameter information;

[0103] S230. Call the atomic capability corresponding to the task parameter information to execute the task corresponding to the task information and obtain the execution result. The atomic capability is the capability obtained by decomposing the function of the second application. The atomic capability conforms to the atomication standard protocol.

[0104] In the task processing method of this application embodiment, since both atomic capabilities and task information conform to the atomication standard protocol, it is possible to execute the task corresponding to the task information through the atomic capabilities corresponding to the task parameter information. Since atomic capabilities are capabilities obtained by decomposing the functions of the second application, by receiving the task information corresponding to the task instruction when the first application receives a task instruction, determining the task parameter information corresponding to the task information, and calling the atomic capabilities corresponding to the task parameter information to execute the task corresponding to the task information, the capabilities of the second application can be used to execute the task corresponding to the first application and obtain the execution result, without needing to integrate the SDK of the second application into the first application. Thus, when using the capabilities of the second application through the first application, the first application and the second application can be decoupled, reducing the dependency between the first application and the second application, thereby improving the security of the entire terminal.

[0105] The specific implementation methods for each of the above steps are described below.

[0106] In some embodiments, in S210, the task information may conform to an atomic standard protocol. The atomic standard protocol may be a protocol derived with reference to the Uniform Resource Identifier (URI) protocol. The standard URI may be: scheme: / / domain / path?key=value. Here, scheme identifies the access method of the resource, domain represents the permission part, including user information, hostname, and port number, path identifies the specific location of the resource, and key=value may be appended to path to pass additional parameters or information. Based on this, using TPU as the protocol header, the plugin name (including the protocol header) as the permission part, the command corresponding to the plugin name as the command part, and the command parameters corresponding to the command as the parameter part, the protocol can be defined to obtain the atomic standard protocol. That is, the permission part may include the plugin name. The command part may include the command corresponding to the plugin name. The parameter part may include the command parameters corresponding to the command. The plugin name may be, for example, tpu: / / media. media (i.e., media) may be associated with the name of the target application. The command may be, for example, play. Command parameters can include, for example, `pkg=com.xx.music, id=xxx`, representing the location and identifier of the music to be played. An atomic standard protocol can be, for example, `tpu: / / media / play?pkg=com.xx.music&id=xxx`. Since the atomic standard protocol can include the plugin name, command, and command parameters, it can also be called the Plugin Name-Command-Content (PCC) protocol. Here, `Plugin name` represents the plugin name, `Command` represents the command, and `Content` represents the command parameters. Specifically, `Plugin name` can distinguish the application domain providing atomic capabilities, supports TPU customization, and is used to distinguish plugins integrating several atomic capabilities. `Command` executes action instructions and is used to identify atomic capability methods, including different types of capabilities such as data, service, and user interface (UI) classes. `Content` can encapsulate the data needed to execute the command. Data capabilities can be used to retrieve data such as music lists and food delivery information from the application. UI capabilities can be used to retrieve card templates corresponding to the generative application and interface elements such as controls and icons in the application. Service-type capabilities can be used to control objects such as air conditioners and windows that are associated with a terminal. If the method is applied to a vehicle, the service-type capability can be used to control the vehicle.

[0107] As an example, plugin names can be "turning," "painting," etc., and the commands corresponding to each plugin name can include "setEffect," "gstList," etc., with multiple command parameters for each command, such as "Bundle(id:01)," "Bundle(id:02)," etc. This can be understood as the plugin "turning" executing commands like "setEffect" and "gstList." If the command executed by the plugin "turning" is "setEffect" (i.e., setting a sound effect), then the sound effect set can be "Bundle(id:01)," "Bundle(id:02)," etc. Therefore, if the task information is displayed as "tpu: / / turning / setEffect?id=01," then the task corresponding to this information is to set the sound effect to "id=01."

[0108] In some embodiments, in S220, the task parameter information may include at least one target plugin name, at least one command corresponding to each target plugin name, and at least one command parameter corresponding to each command. After receiving the task information, the target plugin name, target command, target command parameters, and other parameter information in the task information can be identified by parsing the task information according to the atomicity standard protocol.

[0109] Therefore, in order to ensure the accuracy of the task parameter information, in some embodiments, the above-mentioned S220 may specifically include:

[0110] Parse the permissions section of the task information to obtain at least one target plugin name;

[0111] Parse the command portion of the task information to obtain at least one target command corresponding to each target plugin name;

[0112] Parse the parameter part of the task information to obtain at least one target command parameter corresponding to each target command.

[0113] If the task information is tpu: / / media / play?pkg=com.xx.music&id=xxx, then by parsing the permission part "tpu: / / media", the target plugin name "media" can be obtained; by parsing the command part "play", the target command "play" can be obtained; and by parsing the parameter part "pkg=com.xx.music&id=xxx", the target task parameters "pkg=com.xx.music" and "id=xxx" can be obtained.

[0114] By parsing each part of the task information according to the atomization standard protocol, the accuracy of the parsed task parameter information can be guaranteed.

[0115] In some embodiments, in S230, an atomic capability can be a small, independent, atomic functional module that can be dynamically loaded and invoked to implement specific business functions or services. An atomic capability can conform to atomicity standard protocols. Specifically, an atomic capability includes a plugin name, a command corresponding to the plugin name, and command parameters corresponding to the command.

[0116] As an example, if multiple second applications are installed on the terminal, by decomposing the functions of each second application, multiple atomic capabilities corresponding to each second application can be obtained. These atomic capabilities can be set in the second application or can be independent of the second application; no limitation is made here.

[0117] Based on this, in order to obtain multiple atomic capabilities corresponding to each second application, in some embodiments, before S230 above, the following may also be included:

[0118] Obtain functional information from the second application;

[0119] The functional information is broken down into multiple sub-functional information. Each sub-functional information includes a plugin name, multiple commands corresponding to the plugin name, and multiple command parameters corresponding to each command.

[0120] Each sub-function information is encapsulated according to the atomization standard protocol to obtain multiple sub-function information corresponding to function plug-ins, and each function plug-in includes multiple atomic capabilities.

[0121] Here, functional information can be information inherent in the second application itself, used to implement the capabilities of the second application. The functional information in the second application can be represented as a Class. For example, the second application can have Class A and Class B. Class A can include methods + method A(string):int, and Class B can include methods + method B(type):type. By decomposing the functional information (i.e., multiple Classes), multiple sub-functional information can be obtained. For example, all the information in Class A can be a sub-functional information. Another example is that some of the information in Class A can be a sub-functional information. Yet another example is that a combination of information from Class A and Class B can be a sub-functional information. Each sub-functional information can include a plugin name, multiple commands corresponding to the plugin name, and multiple command parameters corresponding to each command. The plugin name can be a plugin identifier, used to identify the provider of atomic capabilities, serving as the first-level path for PCC addressing in the TPU service. The same functional plugin can carry multiple atomic capabilities. The command, or atomic capability method, serves as an atomic capability identifier, identifying a specific atomic capability. Used in conjunction with the plugin name, it constructs a complete PCC address path and represents the minimum set of capabilities in this component-based solution, serving as the target entry point for functional plugins. PCC addressing is used to locate the atomic capability corresponding to the task information. The command parameter (Content), or the input parameter of the atomic capability, is a serialized encapsulated body of atomic capability parameters, used to pass necessary parameters when calling the atomic capability interface.

[0122] After obtaining multiple sub-functionality information, each sub-functionality information can be encapsulated according to the atomicity standard protocol to obtain the functional plugins corresponding to each sub-functionality information. As mentioned above, the form of the atomicity standard protocol can be, for example, tpu: / / plugin / command?content. To ensure that multiple atomic capabilities can conform to the atomicity standard protocol, this application embodiment provides a custom annotation processor and a set of annotations serving the PCC protocol to standardize the interfaces and plugin classes of capability providers, unify the interface form of global capabilities, and standardize atomic capabilities. To ensure that all atomic capability providers can quickly and standardizedly access the platform, a unified access suite needs to be provided to ensure the uniformity of the external interface of atomic capabilities, while their internal implementation can be handled by the specific capability provider itself, appearing as a black box to the outside world (TPU service or atomic capability user).

[0123] Based on this, in order to achieve atomic capability standardization, in some embodiments, each sub-functional information is encapsulated according to the atomicity standard protocol to obtain functional plug-ins corresponding to multiple sub-functional information. Each functional plug-in includes multiple atomic capabilities, which may specifically include:

[0124] Retrieve the plugin name annotation corresponding to the plugin name, the command annotation corresponding to the command, the command parameter annotation corresponding to the command parameters, the execution result description annotation, and the task identifier annotation corresponding to the task information;

[0125] For each sub-function information, the plugin name and its corresponding plugin name annotation, the command and its corresponding command annotation, the command parameters and their corresponding command parameter annotation, the execution result description annotation, and the task identifier annotation are encapsulated according to the atomicity standard protocol to obtain the functional plugins corresponding to multiple sub-function information.

[0126] Here, the plugin name annotation can specifically be the @PluginName annotation, one of the core annotations of the PCC protocol. It is a plugin class tag that only applies to the class level and is also the key path used for PCC addressing of TPU services in the componentization scheme.

[0127] The command annotation can specifically be the `@Command` annotation, one of the core annotations of the PCC protocol. It is a method tag used to mark the Command information processed by the current method. It is the target entry point for standardized interfaces in the entire componentization scheme. Through the processing of this annotation, the global interface is implemented in a unified form of abstraction. This annotation contains relevant parameters such as command name and package name.

[0128] The command parameter annotation can specifically be the @Content annotation, one of the core annotations of the PCC protocol. It is a method parameter annotation used to identify that the received parameter is a parameter passed through DCC. The type is String, and it is a standardized encapsulation of interface call parameters.

[0129] Here, the execution result description annotation can specifically be the `@Listener` annotation, which is a method parameter annotation used to identify that the received parameter is a callback interface that returns the execution result corresponding to the atomic capability. The parameter type of its internal callback method is a JSON data protocol string corresponding to the custom entity class. The internal callback method can be used to encapsulate the execution result.

[0130] The task identifier annotation can be the @ID annotation, which is a method parameter annotation that indicates that the current parameter is the transaction ID passed from the TPU service. This parameter is a unique ID in a single call of the plugin and is used to identify an atomic capability call transaction.

[0131] Thus, the atomic capability provider (i.e., the second application) can unify the corresponding external interfaces through the above annotations, ultimately achieving the standardization of atomic capabilities across the entire domain and ensuring that atomic capabilities can perform tasks normally.

[0132] The atomic capability standardization scheme has designed a unified interface protocol, namely the PCC protocol. Standardized atomic capabilities have been encapsulated and implemented in a standardized manner according to this protocol, including plugin names, commands, and command parameters. Following the standard scheme format, the atomic capability interfaces standardized using the PCC protocol can be mapped, transforming them into PCC protocol-compliant strings that can be distributed as data.

[0133] Since the atomic capability standardization scheme has completed the standardized access according to the PCC protocol, a standard PCC protocol data (i.e., task information) and a standardized atomic capability interface (i.e., the atomic capability that executes the task information) form a one-to-one mapping.

[0134] Based on this, as mentioned above, the command and plugin name share a complete PCC addressing path. Therefore, after determining the target plugin name and target command, the atomic capabilities corresponding to the task information can be identified using these names. Calling these atomic capabilities will then execute the task corresponding to the task information and yield the execution result. Atomic capability calls can include data capability calls, UI capability calls, and service capability calls. Specifically, calling data capabilities can be used to retrieve data such as music playlists and food delivery information from the application. Calling UI capabilities can be used to retrieve card templates and UI elements such as controls and icons corresponding to the generative application. Calling service capabilities can be used to control objects associated with the terminal, such as air conditioners and windows. If the method is applied to a vehicle, calling service capabilities can be used to control the vehicle. Based on this, the execution result can include the retrieved music playlists, food delivery information, UI elements, and the control results of the objects.

[0135] As an example, after standardizing atomic capabilities, application interface calls no longer depend on specific interfaces, but are uniformly abstracted into a standardized interface form. Thus, by receiving task information conforming to the atomic standard protocol, the new interface (i.e., atomic capability) can be invoked. The standardized interface invocation scheme after atomic capability standardization can be as follows: Figure 3 As shown.

[0136] like Figure 3As shown, the application providing atomic capabilities (i.e., the second application) uses the PCC protocol provided by this componentization solution to decompose the capabilities that need to be exposed externally. It then standardizes the relevant interface capabilities through unified annotations. The capability user (the application) uses the unified PCC protocol (tpu: / / plugin / command?content) for all interface calls. Furthermore, the related protocol parsing, addressing, and invocation are all handled uniformly by the task processing engine, decoupling the caller from the capability provider. This allows for the expansion of application capabilities simply by sending data conforming to the PCC protocol.

[0137] Furthermore, after standardizing atomic capabilities across the entire domain, applications providing atomic capabilities can integrate standardized access suites to encapsulate their exposed atomic capabilities as functional plugins. Then, by registering the atomic capabilities within these functional plugins, TPU services or other related capability users can become aware of the interface's existence. Atomic capabilities can be registered with an atomic capability management platform. This platform is a service built between atomic capabilities and the AI ​​big data model, designed to uniformly manage the collection and distribution of atomic capabilities. The platform manages the output of various versions of atomic capabilities and provides this information to the AI ​​big data model for learning and use. The AI ​​big data model can learn the use cases and methods of multiple atomic capabilities, and upon receiving user instructions, determine the corresponding task information, which can be executed by multiple atomic capabilities.

[0138] As an example, such as Figure 4 As shown, registering atomic capabilities to the atomic capability management platform mainly involves the following four steps:

[0139] Step 1: The Continuous Integration / Continuous Deployment (CI / CD) tool triggers the build of the capability-providing APP project, which can include a first application and a second application;

[0140] Step 2: Standardize the compilation plugin scanning and parsing of the annotation information of the functional plugins in the access suite, collect information on all functional plugins and their internal atomic capabilities, including the plugin name, the names of each capability (i.e., commands) in the plugin, related command parameters and other basic PCC protocol information, as well as the corresponding descriptive information;

[0141] Step 3: Integrate and summarize the collected plugin-related information;

[0142] Step 4: Report the standardized plugin information (including atomic capability information) and complete the plugin capability registration after the data is reported to the atomic capability management platform.

[0143] At this point, the capability-providing app has completed the registration of its standardized atomic capabilities, enabling large models or TPU services to perceive the currently existing global atomic capabilities through the platform. After the atomic capabilities are standardized and registered, relevant framework businesses or AI applications can invoke them, with the invocation rules also following the aforementioned PCC protocol. However, the method of interface invocation may differ depending on the business objectives and application scenarios.

[0144] As described above, the task processing method in this application embodiment can be applied to vehicle scenarios. A vehicle typically includes multiple display devices. Each display device can have multiple applications installed. The applications installed on different display devices may be the same or different. The same application may be installed on one display device or on multiple display devices. Furthermore, for the same display content, it may support display on only one display device or multiple display devices. For example, a vehicle may include a driver's side display device, a passenger side display device, and a rear-seat display device. The driver's side display device, passenger side display device, and rear-seat display device can all display navigation information. Additionally, during driving, the passenger side display device and the rear-seat display device can display video information, but the driver's side display device cannot display video information.

[0145] In practice, a user might issue a command to display device A, which is then executed by display device B. For example, a user could issue a command to the driver's side display to "play an animated film on the rear display."

[0146] Therefore, in order to support routing of global plugins, the functional plugins supported on each display device can be managed.

[0147] Since the installation rules for business applications are differentiated based on the display device dimension, while the capabilities provided by functional plugins are provided by the application platform, functional plugins can be categorized based on the display device dimension.

[0148] Specifically, by scanning multiple display devices, information on multiple plugins corresponding to each display device can be identified. This plugin information can include the plugin name, the names of each capability (i.e., command) within the plugin, command parameters, and other basic PCC protocol information, as well as corresponding descriptive information. Furthermore, scanning multiple display devices can involve scanning the application installation packages (Android Packages, APKs) installed on those devices and identifying plugin information within the APKs. Each APK can contain multiple functional plugins. Specifically, an APK can be an application containing multiple functional plugins, or it can be a plugin application specifically designed to store multiple functional plugins; this is not a limitation.

[0149] like Figure 5 As shown, multiple plugin information can be stored separately in the PCC atomic capability list under different display devices. Each display device corresponds to a display device identifier, which can be denoted as screenId. Each display device identifier can also correspond to a user identifier. Multiple user identifiers can be, for example, user0, user1, and user2. The PCC atomic capability list can include the plugin name. That is, after determining the multiple plugin information corresponding to multiple display devices, the correspondence between display device identifiers and plugin names can be stored.

[0150] Building upon this, when the vehicle includes multiple display devices, the task information may include a target display device identifier to instruct the display of generative information on the target display device corresponding to that identifier. The task information can be executed by the atomic capabilities corresponding to the target display device, or by the atomic capabilities corresponding to other display devices; this is not limited here. The atomic capabilities can be stored in the display devices or in the plug-in management platform; this is not limited here either. The plug-in management platform can store atomic capabilities corresponding to multiple display devices.

[0151] Therefore, in order to ensure the smooth execution of the task, in some embodiments, the above-mentioned S230 may specifically include:

[0152] Based on the correspondence between display device identifiers and plugin names, at least one first display device identifier corresponding to the target plugin name is determined;

[0153] When at least one first display device identifier includes a target display device identifier, the target atomic capability corresponding to the target display device identifier is invoked to execute the task corresponding to the task information, and the execution result is obtained and displayed on the target display device corresponding to the target display device identifier. The target atomic capability is the atomic capability corresponding to the task parameter information.

[0154] As mentioned above, an application may be installed on multiple display devices, therefore, the plugin information corresponding to multiple display devices may be the same. Therefore, after receiving the task information, the target plugin name can be searched in the PCC atomic capability list for each of the multiple display devices, and then the display device identifier corresponding to the target plugin name can be determined as the first display device identifier. There can be one or more first display device identifiers, and at least one first display device identifier may or may not include the target display device identifier. If there is one first display device identifier that is the same as the target display device identifier, then that first display device identifier is the target display device identifier. If there are multiple first display device identifiers, the target display device identifier can be determined from among them. After determining the target display device identifier, if the target display device has an application APK installed or the plugin management platform stores the atomic capabilities corresponding to the target display device, the target atomic capability corresponding to the target display device identifier can be called to execute the task corresponding to the task information.

[0155] As an example, such as Figure 6 As shown, if a vehicle includes a driver's side display device, a passenger side display device, and a rear-seat display device, and each of the driver's side display device, passenger side display device, and rear-seat display device has an application APK installed, then when the target display device is any one of the three display devices, the target atomic capability corresponding to the target display device can be directly called to execute the task corresponding to the task information, and the execution result can be obtained and displayed on the target display device.

[0156] It should be noted that if the target display device does not support displaying the execution results, an error can be reported, or the execution results can be displayed on other display devices.

[0157] By invoking the target atomic capability corresponding to the target display device identifier to execute the task corresponding to the task information when at least one first display device identifier includes the target display device identifier, the smooth execution of the task can be guaranteed.

[0158] Furthermore, if at least one first display device identifier includes a target display device identifier, the target display device corresponding to the target display device identifier may or may not support target atomic capability invocation. If the target display device supports target atomic capability invocation, the task corresponding to the target atomic capability corresponding to the target display device can be directly invoked to execute the task information, and the execution result can be obtained and displayed on the target display device.

[0159] As an example, supporting the invocation of a target atomic capability can be based on the availability of certain conditions for invoking that target atomic capability. Whether the conditions for invoking the target atomic capability are met can be determined based on factors such as the vehicle's driving status, the vehicle's infotainment system's operating status, and the display device's operating status.

[0160] For example, if the target atom's capability is to play video, then even if the driver's side display device has the function of playing video, it will not be able to play video while the vehicle is in motion, in order to ensure driving safety.

[0161] If the target display device does not support the call to the target atomic capability, an error can be reported directly to ensure driving safety. Additionally, to ensure successful task execution, in some embodiments, after determining at least one first display device identifier corresponding to the target plugin name, the method may further include:

[0162] If at least one first display device identifier includes a target display device identifier, and the target display device corresponding to the target display device identifier does not support the target atomic capability call, the target atomic capability corresponding to the third display device identifier is called to execute the task corresponding to the task information, and the execution result is obtained. The display device corresponding to the third display device identifier supports the target atomic capability call.

[0163] Display the execution results on the target display device.

[0164] As an example, if the target display device has reached its memory limit (e.g., the target display device contains a large AI model and is currently running the large AI model), the target display device may no longer be able to call the target atomic capabilities. Therefore, to ensure the smooth execution of the task, the task can be executed first using a display device that supports atomic capability calls (e.g., the display device corresponding to the third display device identifier), the execution result can be obtained, and then the execution result can be displayed across screens on the target display device.

[0165] In this case, it can be determined whether the target display device supports displaying the execution result. If the target display device supports displaying the execution result, the execution result can be displayed on the target display device. If the target display device does not support displaying the execution result, an error can be reported, or the result can be displayed on another display device that supports displaying the execution result. It should be noted that multiple display devices can be controlled by the same control unit or by different control units, which is not limited here. The control unit can be, for example, a system-on-chip (SOC) or a microcontroller unit (MCU). If multiple display devices are controlled by the same control unit, the schematic diagram of atomic capability invocation based on a single SOC provided in this application embodiment can be as follows. Figure 9 As shown.

[0166] In cases where multiple display devices are controlled by multiple control units, as an example, such as Figure 10As shown, the two display devices in the front row can be controlled by the same control unit, while the display devices in the back row can be controlled by a different control unit. If the two display devices are controlled by different control units, communication can be achieved through Rebinder during cross-display device calls (i.e., cross-control unit calls).

[0167] Based on this, if the first application is set in the second display device corresponding to the second display device identifier, the second display device is controlled by the first control unit, and the target display device is controlled by the target control unit, then in order to ensure the smooth execution of the task, the aforementioned invocation of the target atomic capability corresponding to the target display device identifier to execute the task corresponding to the task information may specifically include:

[0168] The task information is sent from the first control unit to the target control unit.

[0169] The target control unit invokes the target atomic capabilities corresponding to the target display device to execute the task corresponding to the task information.

[0170] Here, the first control unit may include a task processing engine (i.e., a TPU service), and the target control unit may also include a task processing engine (i.e., a TPU service). Cross-control unit calls can be achieved through the TPU services corresponding to the two control units respectively, and cross-control unit calls of atomic capabilities can be achieved by using Rebinder as the underlying framework for cross-control unit communication.

[0171] For example, if the target display device is a rear-seat display device and the second display device is a driver's seat display device, then after the first control unit receives the task information, it can send the task information to the target control unit so that the target control unit can call the target atomic capability corresponding to the rear-seat display device to execute the task corresponding to the task information, obtain the execution result, and control the rear-seat display device to display the execution result.

[0172] As a more concrete example, this solution establishes a unified rule: when a capability is invoked from the upstream business, the instruction is uniformly sent to the TPU under User 0 (i.e., the user identifier corresponding to the driver) for execution. Taking the control unit as a SOC as an example, if multiple display devices correspond to one SOC, the schematic diagram of atomic capability invocation based on a single SOC can be shown as follows. Figure 9 As shown. In Figure 9 In this context, calls from the upstream business logic (driver: user0) to atomic capabilities (driver) can be made within the same user. Calls from the upstream business logic (driver: user0) to atomic capabilities (passenger) and atomic capabilities (back row) can be made across different users. The rest follows the same logic and will not be elaborated upon further here.

[0173] For cross-SOC capability calls (i.e., front-end calling back-end capabilities or vice versa), the TPU service can be used to achieve cross-SOC calls, with Rebinder as the underlying framework for cross-SOC communication. A diagram illustrating atomic capability calls across multiple SOCs can be seen as follows: Figure 11 As shown.

[0174] Additionally, at least one first display device identifier may not include the target display device identifier. The absence of the target display device identifier in at least one first display device identifier could mean that the target atomic capability corresponding to the target display device identifier does not exist. If at least one first display device identifier does not include the target display device identifier, an error can be reported.

[0175] As an example, such as Figure 7 As shown, if a vehicle includes a driver's side display, a passenger side display, and a rear-seat display, and the driver's side display has an application APK installed, but the passenger side display and the rear-seat display do not, then an error can be reported directly when the target display device is either the passenger side display or the rear-seat display.

[0176] Based on this, in order to ensure the smooth execution of the task, in some embodiments, after determining at least one first display device identifier corresponding to the target plugin name, the method may further include:

[0177] If at least one first display device identifier does not include the target display device identifier, the target atomic capability corresponding to the fourth display device identifier is invoked to execute the task corresponding to the task information, and the execution result is obtained. The fourth display device identifier is any one of at least one first display device identifier.

[0178] The execution results are displayed on the target display device corresponding to the target display device identifier.

[0179] As an example, such as Figure 8 As shown, if a vehicle includes a driver's side display, a passenger side display, and a rear-seat display, and the driver's side display has an application APK installed, but the passenger side display and the rear-seat display do not, then when the target display device is the passenger side display or the rear-seat display, the target atomic capability corresponding to the driver's side display can be called first to execute the task corresponding to the task information, obtain the execution result, and then the execution result can be displayed across screens on the passenger side display or the rear-seat display.

[0180] It should be noted that if the passenger-side display or rear-seat display does not support displaying execution results, an error message will be displayed. Alternatively, if the driver-side display supports displaying execution results, the results can also be displayed on the driver-side display.

[0181] In cases where the control units corresponding to the display device and the target display device are different, in order to ensure the smooth execution of the task, in some embodiments, the above-mentioned invocation of the target atomic capability corresponding to the fourth display device identifier to execute the task corresponding to the task information and obtain the execution result may specifically include:

[0182] When the display device corresponding to the fourth display device identifier is controlled by the second control unit, and the target display device is controlled by the target control unit, the second control unit calls the target atomic capability corresponding to the fourth display device identifier to execute the task corresponding to the task information and obtain the execution result.

[0183] The execution result is sent to the target control unit through the second control unit.

[0184] Based on this, the execution results are displayed on the target display device corresponding to the target display device identifier, which may specifically include:

[0185] The target control unit controls the target display device to display the execution results.

[0186] Here, the second control unit and the first control unit can be the same or different; no limitation is made here. The fourth display device identifier and the third display device identifier can be the same or different. Furthermore, the second control unit and the target control unit can communicate via Rebinder. By sending the execution result to the target control unit through the second control unit, and then controlling the target display device to display the execution result through the target control unit, the successful execution of the task can be guaranteed even when the control unit corresponding to the fourth display device (i.e., the display device corresponding to the fourth display device identifier) ​​is different from the control unit corresponding to the target display device.

[0187] For example, if the target display device is a rear-seat display device and the fourth display device is a driver's seat display device, then the second control unit calls the target atomic capability corresponding to the fourth display device to execute the task corresponding to the task information. After obtaining the execution result, it can send the execution result to the target control unit so that the target control unit controls the rear-seat display device to display the execution result.

[0188] Based on the above embodiments, since plug-in capabilities are stored separately in their respective PCC atomic capability lists according to the display device, but the same atomic capability may exist under multiple display devices, the plug-in routing rules uniformly limit the decision on display device selection, with the overall priority order as follows: user corresponding to the scene > user 0 > other users. Here, the user corresponding to the scene can be the target user identifier corresponding to the target display device identifier, user 0 can be the driver user identifier corresponding to the driver's display device identifier, and other users can be user identifiers other than the target user identifier and the driver's user identifier. A schematic diagram of the plug-in routing rules can be shown below. Figure 12 As shown.

[0189] In addition, asynchronous communication interactions may occur in some business scenarios. Therefore, in order to make reasonable use of computing resources, in some embodiments, after obtaining the execution result as described above, the process may further include:

[0190] Display the first content corresponding to the execution result in the first application;

[0191] If the target command is a callback command and the associated content corresponding to the execution result is updated in the second application, the first display content in the first application is updated using the associated content to obtain the second display content.

[0192] Here, a callback command can be a command that involves updating the execution result via a callback. For example, a callback command could include displaying a playlist.

[0193] As an example, if the target command is to retrieve a playlist of a specific artist, then after obtaining the playlist from the second application (i.e., the execution result), the playlist (i.e., the first display content) can be displayed in the first application. If the playlist in the second application is updated, the playlist in the first application can be updated synchronously to obtain the second display content.

[0194] To achieve the above, when the target command is a callback command, a long-lived bidirectional communication connection can be established between the first application and the second application. This will ensure that when the capability user A uses a certain atomic capability, the call will not end immediately, but the atomic capability provider will continuously notify the user of data changes.

[0195] Specifically, upon receiving a task instruction, the first application can initiate a business call to the TPU through capability A. Capability A can be any capability within the first application capable of making business calls. The first application can integrate TPUSDK. Capability A can specifically call the TPU service through the TPU SDK. The call information can include task information corresponding to the task instruction, conforming to the atomic standard protocol. After receiving the task information, the TPU service can detect whether the task information contains a command identifier corresponding to the callback command. If the task information contains a command identifier corresponding to the callback command, the target command in the task information can be determined to be the callback command, thus establishing a long-lived bidirectional communication connection between the first and second applications. Specifically, the second application can integrate the TPU SDK. Based on the TPU SDKs in both the first and second applications, a long-lived communication connection can be established between the first and second applications. After establishing the long-lived communication connection, the atomic capability corresponding to the second application can be called to execute the task instruction, obtain the execution result, and return the execution result to the first application. Subsequently, if the execution result corresponding to the target command in the second application is updated, the updated execution result can be automatically encapsulated in a callback function (such as `callback`) and returned to the first application.

[0196] Based on this, as an example, the logic for invoking the capability of long-connection bidirectional communication can be as follows: Figure 13 As shown.

[0197] based on Figure 13 In the interface definition, the TPUPluginCallback used by the plugin can add a ConnectionListener to handle resource cleanup when the process disconnects. In the implementation of plugin capabilities, the specific logic of the business capabilities can be saved, and corresponding logic listeners can be implemented. Simultaneously, this long-connection capability defines an opposite operation, such as register / unregist, and uses the same ID for association to handle logic stored in the context and clean up data stored in the plugin, preventing data leakage.

[0198] The information processing method provided in the embodiments of this application is described below.

[0199] Figure 14 A flowchart illustrating an information processing method provided in an embodiment of this application is shown.

[0200] like Figure 14 As shown, the information processing method provided in this application embodiment includes the following steps:

[0201] S1410, Obtain functional information from the second application;

[0202] S1420. Decompose the functional information to obtain multiple sub-functional information. Each sub-functional information includes a plugin name, multiple commands corresponding to the plugin name, and multiple command parameters corresponding to each command.

[0203] S1430. Each sub-function information is encapsulated according to the atomization standard protocol to obtain multiple sub-function information corresponding to function plug-ins. Each function plug-in includes multiple atomic capabilities.

[0204] In some embodiments, the above-mentioned S1430 may specifically include:

[0205] Retrieve the plugin name annotation corresponding to the plugin name, the command annotation corresponding to the command, the command parameter annotation corresponding to the command parameters, the execution result description annotation, and the task identifier annotation corresponding to the task information;

[0206] For each sub-function information, the plugin name and its corresponding plugin name annotation, the command and its corresponding command annotation, the command parameters and their corresponding command parameter annotation, the execution result description annotation, and the task identifier annotation are encapsulated according to the atomicity standard protocol to obtain the functional plugins corresponding to multiple sub-function information.

[0207] The steps in the embodiments of this application can be found in the relevant description above, and will not be repeated in detail here.

[0208] Therefore, by providing a custom annotation processor and a set of annotations serving the PCC protocol, the interfaces and plugin classes of capability providers can be standardized, external interfaces can be unified, and ultimately, the standardization of global atomic capabilities can be achieved. Since both atomic capabilities and task information conform to the atomicity standard protocol, it is possible to execute the task corresponding to the task information using the atomic capability corresponding to the task parameter information. Because atomic capabilities are capabilities obtained by decomposing the functions of the second application, when the first application receives a task instruction, it receives the task information corresponding to the task instruction, determines the task parameter information corresponding to the task information, and calls the atomic capability corresponding to the task parameter information to execute the task corresponding to the task information. This allows the capabilities of the second application to execute the task corresponding to the first application and obtain the execution result, without needing to integrate the SDK of the second application into the first application. Thus, when using the capabilities of the second application through the first application, the first and second applications can be decoupled, reducing the dependency between the first and second applications and thereby improving the security of the entire terminal.

[0209] To better describe the overall solution, some specific examples are given based on the above embodiments.

[0210] For example, to achieve atomic capability invocation, preliminary preparations for the overall business logic can be performed first. These preliminary preparations may include the following steps:

[0211] Step 1: CI / CD tools trigger engineering builds that provide atomic capabilities;

[0212] Step 2: The project providing atomic capabilities integrates capabilities according to the standards provided by TPU. During the build process, the compilation plugin collects atomic capability information through standardized annotations.

[0213] Step 3: The collected atomic capability information is summarized and reported to the atomic capability management platform to complete the registration of atomic capabilities on the atomic capability management platform;

[0214] Step 4: The atomic capability management platform aggregates the atomic capabilities provided by various applications and provides a comprehensive list of atomic capabilities to the AI ​​big model, enabling the AI ​​big model to learn the use cases and usage methods of atomic capabilities.

[0215] Step 5: The large AI model generates domain-specific languages ​​(DSL) templates based on the atomic capability list.

[0216] Secondly, after the vehicle's infotainment system starts up, the collection of atomic capability information from the vehicle side is performed to complete the final preparatory work for the overall business. This may include the following steps:

[0217] Step 6: The vehicle infotainment system starts up. The TPU service plugin management module can scan all plugin capabilities on the vehicle infotainment system.

[0218] Step 7: After the plugin scan is completed, the plugins are summarized according to the plugin capabilities of different users on the vehicle system, and the plugins are stored by user.

[0219] Next, human-computer interaction begins, responding to user commands by invoking atomic capabilities, which may include the following steps:

[0220] Step 8: Human-computer interaction begins; the user initiates interaction with the first application.

[0221] Step 9: The first application initiates a capability call request to the framework-type business (including information aggregation framework and generative UI framework) based on the user interaction content;

[0222] Step 10: The framework-based business parsed the application request and requested the corresponding DSL data from the large artificial intelligence model;

[0223] Step 11: Based on the DSL data parsing commands, the framework-type business sends TPU-related commands, i.e., task information, to the TPU service;

[0224] Step 12: The task scheduling module of the TPU service parses the instructions according to the PCC protocol and calls the atomic capability routing service unit to obtain the routing data corresponding to the atomic capability;

[0225] Step 13: According to the plugin routing rules, perform instruction addressing according to the PCC protocol, and find the routing data of the corresponding plugin in the plugin storage unit;

[0226] Step 14: The task scheduling unit makes routing decisions based on the user scenario and determines the scheduling type as a single SOC call or a cross-SOC call based on the vehicle system type;

[0227] Step 15: Initiate the corresponding atomic capability call according to the PCC protocol;

[0228] Step 16: Depending on the atomic capabilities being called, initiate calls to different atomic capability providers, and have the corresponding capability provider's APP complete the function execution, data return, or UI provision;

[0229] Step 17: For scenarios requiring continuous communication or where the business capability party initiates communication, the TPU service establishes bidirectional communication between the two parties for subsequent function execution.

[0230] In the above business process, steps 6 to 17 can be as follows: Figure 15 As shown.

[0231] In addition, to implement this component-based solution in the aforementioned business process, three important processes need to be completed: 1) atomic capability encapsulation; 2) atomic capability conversion into standardized interfaces; and 3) atomic capability invocation by the user. Corresponding to these three main processes, corresponding technical solutions need to be designed to meet the operational requirements of the component-based solution. The core technical solutions involved may include: 1) atomic capability standardization scheme; 2) standardized interface conversion scheme; and 3) standardized interface invocation scheme.

[0232] In the atomic capability standardization scheme, in order to meet the self-learning capability expansion of generative applications, the use of any capability can have a unified abstraction, so that the functions that the application can have no longer directly depend on a specific party (SDK / APK, etc.). Instead, the dependent capability output party is reversed into a parameterized input party. By issuing relevant DSLs, the corresponding capabilities are parsed and called, thereby enabling the self-learning capability expansion of the application without the need for a new version.

[0233] After the standardization of atomic capabilities, the interface for all capabilities has been unified. However, for application users to implement new capabilities without releasing a new version, it is still necessary to decouple the dependencies of capability invocation operations and achieve application capability expansion by distributing data to invoke specific capabilities. Therefore, a solution is needed to bidirectionally convert between standardized atomic capability interfaces and distributable data. The standardized interface conversion solution mainly includes three aspects of design: standard access protocol and interface mapping scheme, standardized interface registration scheme, and PCC protocol addressing scheme.

[0234] Once atomic capabilities are standardized and registered, relevant framework businesses or AI applications can invoke them, following the PCC protocol mentioned above. However, depending on the differences in business objectives and application scenarios, standardized interface calls still need to address issues such as cross-domain routing of plugins, cross-domain invocation of atomic capabilities, and bidirectional communication over long-lived connections.

[0235] For details on how to solve the above-mentioned problems, please refer to the description above, which will not be repeated here.

[0236] Therefore, through the embodiments of this application, the vehicle-side capabilities and data external protocols are unified and standardized, and the vehicle-side capabilities are adapted and called across the entire domain. This solves the problem that traditional component-based solutions rely on many things and lack a unified interface protocol. This solution enables the algorithm capabilities to be implemented in a standardized manner on the vehicle side and can quickly build a generative application, bringing users an intelligent and innovative user experience.

[0237] Based on the task processing method provided in the above embodiments, this application also provides specific implementations of the task processing apparatus. Please refer to the following embodiments.

[0238] like Figure 16 As shown, the task processing device 1600 provided in this application embodiment includes the following modules:

[0239] The receiving module 1610 is used to receive task information corresponding to the task instruction. The task instruction is the instruction received by the first application, and the task information conforms to the atomicity standard protocol.

[0240] The parsing module 1620 is used to parse the task information according to the atomicity standard protocol to obtain the task parameter information;

[0241] The execution module 1630 is used to call the atomic capabilities corresponding to the task parameter information to execute the task corresponding to the task information and obtain the execution result. The atomic capability is the capability obtained by decomposing the function of the second application. The atomic capability conforms to the atomication standard protocol.

[0242] The task processing device 1600 described above will be described in detail below:

[0243] In some embodiments, the atomicity standard protocol includes a permission part, a command part, and a parameter part; wherein, the permission part includes the plugin name, the command part includes the command corresponding to the plugin name, and the parameter part includes the command parameters corresponding to the command. Based on this, the parsing module 1620 may specifically include:

[0244] The first parsing submodule is used to parse the permission part of the task information to obtain at least one target plugin name;

[0245] The second parsing submodule is used to parse the command part of the task information to obtain at least one target command corresponding to each target plugin name;

[0246] The third parsing submodule is used to parse the parameter part of the task information to obtain at least one target command parameter corresponding to each target command.

[0247] In some embodiments, the task parameter information includes the target plugin name, and the task information includes the target display device identifier. Based on this, the execution module 1630 may specifically include:

[0248] The first determining submodule is used to determine at least one first display device identifier corresponding to the target plugin name based on the correspondence between the display device identifier and the plugin name;

[0249] The first execution submodule is used to, when at least one first display device identifier includes a target display device identifier, call the target atomic capability corresponding to the target display device identifier to execute the task corresponding to the task information, obtain and display the execution result on the target display device corresponding to the target display device identifier, where the target atomic capability is the atomic capability corresponding to the task parameter information.

[0250] In some embodiments, the execution module 1630 may specifically include:

[0251] The second execution submodule is used to determine at least one first display device identifier corresponding to the target plugin name, and in the case where at least one first display device identifier includes the target display device identifier and the target display device corresponding to the target display device identifier does not support the target atomic capability call, call the task corresponding to the target atomic capability execution task information corresponding to the third display device identifier to obtain the execution result. The display device corresponding to the third display device identifier supports the target atomic capability call.

[0252] The first display submodule is used to display the execution results on the target display device.

[0253] In some embodiments, the first application is set in the second display device corresponding to the second display device identifier, the second display device is controlled by the first control unit, and the target display device is controlled by the target control unit. Based on this, the first execution submodule may specifically include:

[0254] The first sending unit is used to send task information to the target control unit through the first control unit;

[0255] The first execution unit is used to execute the task corresponding to the task information by calling the atomic capabilities in the target display device that correspond to the task parameter information through the target control unit.

[0256] In some embodiments, the execution module 1630 may specifically include:

[0257] The third execution submodule is used to, after determining at least one first display device identifier corresponding to the target plugin name, and if at least one first display device identifier does not include the target display device identifier, call the target atomic capability corresponding to the fourth display device identifier to execute the task corresponding to the task information and obtain the execution result. The fourth display device identifier is any one of the at least one first display device identifier.

[0258] The second display submodule is used to display the execution results on the target display device corresponding to the target display device identifier.

[0259] In some embodiments, the third execution submodule may specifically include:

[0260] The second execution unit is used to, when the display device corresponding to the fourth display device identifier is controlled by the second control unit and the target display device is controlled by the target control unit, call the target atomic capability corresponding to the fourth display device identifier to execute the task corresponding to the task information through the second control unit, and obtain the execution result;

[0261] The second sending unit is used to send the execution result to the target control unit through the second control unit.

[0262] Based on this, the second display submodule may specifically include:

[0263] The display unit is used to control the target display device to display the execution results through the target control unit.

[0264] In some embodiments, the execution module 1630 may specifically include:

[0265] The second determining submodule is used to scan multiple display devices before determining at least one first display device identifier corresponding to the target plugin name based on the correspondence between the display device identifier and the plugin name, and to determine multiple plugin information corresponding to the multiple display devices respectively. Each display device corresponds to a display device identifier, and the plugin information includes the plugin name.

[0266] The storage submodule is used to store the mapping between display device identifiers and plugin names.

[0267] In some embodiments, the task processing device 1600 may further include:

[0268] The display module is used to display the first display content corresponding to the execution result in the first application after the execution result is obtained;

[0269] The update module is used to update the first display content in the first application using the associated content when the target command is a callback command and the associated content corresponding to the execution result in the second application is updated, so as to obtain the second display content.

[0270] In the task processing apparatus of this application embodiment, since both atomic capabilities and task information conform to the atomication standard protocol, it is possible to execute the task corresponding to the task information through the atomic capabilities corresponding to the task parameter information. Since atomic capabilities are capabilities obtained by decomposing the functions of the second application, by receiving the task information corresponding to the task instruction when the first application receives a task instruction, determining the task parameter information corresponding to the task information, and calling the atomic capabilities corresponding to the task parameter information to execute the task corresponding to the task information, the capabilities of the second application can be used to execute the task corresponding to the first application and obtain the execution result, without needing to integrate the SDK of the second application into the first application. Thus, when using the capabilities of the second application through the first application, the first application and the second application can be decoupled, reducing the dependency between the first application and the second application, thereby improving the security of the entire terminal.

[0271] Based on the information processing method provided in the above embodiments, this application also provides specific implementations of the information processing apparatus. Please refer to the following embodiments.

[0272] like Figure 17 As shown, the information processing apparatus 1700 provided in this application embodiment includes the following modules:

[0273] Module 1710 is used to acquire functional information from the second application.

[0274] The disassembly module 1720 is used to disassemble the functional information to obtain multiple sub-functional information. Each sub-functional information includes a plugin name, multiple commands corresponding to the plugin name, and multiple command parameters corresponding to each command.

[0275] The encapsulation module 1730 is used to encapsulate each sub-function information according to the atomicity standard protocol to obtain functional plug-ins corresponding to multiple sub-function information, and each functional plug-in includes multiple atomic capabilities.

[0276] In some embodiments, the encapsulation module 1730 may specifically include:

[0277] The Get submodule is used to retrieve the plugin name annotation corresponding to the plugin name, the command annotation corresponding to the command, the command parameter annotation corresponding to the command parameters, the execution result description annotation, and the task identifier annotation corresponding to the task information;

[0278] The encapsulation submodule is used to encapsulate the plugin name and its corresponding plugin name annotation, command and its corresponding command annotation, command parameters and their corresponding command parameter annotation, execution result description annotation, and task identifier annotation for each sub-function information according to the atomicity standard protocol, so as to obtain the functional plugins corresponding to multiple sub-function information.

[0279] Therefore, by providing a custom annotation processor and a set of annotations serving the PCC protocol, the interfaces and plugin classes of capability providers can be standardized, external interfaces can be unified, and ultimately, the standardization of global atomic capabilities can be achieved. Since both atomic capabilities and task information conform to the atomicity standard protocol, it is possible to execute the task corresponding to the task information using the atomic capability corresponding to the task parameter information. Because atomic capabilities are capabilities obtained by decomposing the functions of the second application, when the first application receives a task instruction, it receives the task information corresponding to the task instruction, determines the task parameter information corresponding to the task information, and calls the atomic capability corresponding to the task parameter information to execute the task corresponding to the task information. This allows the capabilities of the second application to execute the task corresponding to the first application and obtain the execution result, without needing to integrate the SDK of the second application into the first application. Thus, when using the capabilities of the second application through the first application, the first and second applications can be decoupled, reducing the dependency between the first and second applications and thereby improving the security of the entire terminal.

[0280] Based on the task processing method provided in the above embodiments, this application also provides specific implementation methods for electronic devices. Figure 18 A schematic diagram of an electronic device 1800 provided in an embodiment of this application is shown.

[0281] Electronic device 1800 may include processor 1810 and memory 1820 storing computer program instructions.

[0282] Specifically, the processor 1810 may include a central processing unit (CPU), an application-specific integrated circuit (ASIC), or one or more integrated circuits that can be configured to implement the embodiments of this application.

[0283] Memory 1820 may include mass storage for data or instructions. For example, and not limitingly, memory 1820 may include a hard disk drive (HDD), floppy disk drive, flash memory, optical disk, magneto-optical disk, magnetic tape, or Universal Serial Bus (USB) drive, or a combination of two or more of these. Where appropriate, memory 1820 may include removable or non-removable (or fixed) media. Where appropriate, memory 1820 may be internal or external to electronic device 1800. In a particular embodiment, memory 1820 is a non-volatile solid-state memory.

[0284] Memory may include read-only memory (ROM), random access memory (RAM), disk storage media devices, optical storage media devices, flash memory devices, and electrical, optical, or other physical / tangible memory storage devices. Therefore, typically, memory includes one or more tangible (non-transitory) computer-readable storage media (e.g., memory devices) encoded with software including computer-executable instructions, and when the software is executed (e.g., by one or more processors), it is operable to perform the operations described with reference to the method according to the first aspect of this application.

[0285] The processor 1810 implements any of the task processing methods described in the above embodiments by reading and executing computer program instructions stored in the memory 1820.

[0286] In one example, the electronic device 1800 may also include a communication interface 1830 and a bus 1840. For example... Figure 18 As shown, the processor 1810, memory 1820, and communication interface 1830 are connected via bus 1840 and communicate with each other.

[0287] The communication interface 1830 is mainly used to realize communication between various modules, devices, units and / or equipment in the embodiments of this application.

[0288] Bus 1840 includes hardware, software, or both, that couples components of an electronic device together. For example, and not limitingly, the bus may include an Accelerated Graphics Port (AGP) or other graphics bus, an Enhanced Industry Standard Architecture (EISA) bus, a Front Side Bus (FSB), HyperTransport (HT) interconnect, an Industry Standard Architecture (ISA) bus, an Infinite Bandwidth Interconnect, a Low Pin Count (LPC) bus, a memory bus, a Microchannel Architecture (MCA) bus, a Peripheral Component Interconnect (PCI) bus, a PCI-Express (PCI-X) bus, a Serial Advanced Technology Attachment (SATA) bus, a Video Electronics Standards Association Local (VLB) bus, or other suitable buses, or combinations of two or more of these. Where appropriate, bus 1840 may include one or more buses. Although specific buses are described and illustrated in embodiments of this application, this application contemplates any suitable bus or interconnect.

[0289] For example, the electronic device 1800 can be a mobile phone, tablet computer, laptop computer, handheld computer, in-vehicle electronic device, ultra-mobile personal computer (UMPC), netbook, or personal digital assistant (PDA), etc.

[0290] The electronic device can execute the task processing method described in the embodiments of this application, thereby achieving a combination Figures 1 to 17 The described task processing methods and apparatus.

[0291] Furthermore, in conjunction with the task processing methods in the above embodiments, this application embodiment can provide a computer-readable storage medium for implementation. This computer-readable storage medium stores computer program instructions; when these computer program instructions are executed by a processor, they implement any of the task processing methods in the above embodiments.

[0292] In addition, this application embodiment also provides a vehicle, which may include at least one of the following:

[0293] The task processing device as described in the above embodiments;

[0294] The information processing device as described in the above embodiments;

[0295] The electronic device as described in the above embodiments;

[0296] The computer-readable storage medium described in the above embodiments will not be repeated here.

[0297] It should be clarified that this application is not limited to the specific configurations and processes described above and shown in the figures. For the sake of brevity, detailed descriptions of known methods are omitted here. In the above embodiments, several specific steps are described and shown as examples. However, the method process of this application is not limited to the specific steps described and shown. Those skilled in the art can make various changes, modifications, and additions, or change the order of steps, after understanding the spirit of this application.

[0298] The functional blocks shown in the above-described structural diagram can be implemented as hardware, software, firmware, or a combination thereof. When implemented in hardware, they can be, for example, electronic circuits, application-specific integrated circuits (ASICs), appropriate firmware, plug-ins, function cards, etc. When implemented in software, the elements of this application are programs or code segments used to perform the required tasks. Programs or code segments can be stored on a machine-readable medium or transmitted over a transmission medium or communication link via data signals carried on a carrier wave. "Machine-readable medium" can include any medium capable of storing or transmitting information. Examples of machine-readable media include electronic circuits, semiconductor memory devices, ROM, flash memory, erasable ROM (EROM), floppy disks, CD-ROMs, optical disks, hard disks, fiber optic media, radio frequency (RF) links, etc. Code segments can be downloaded via computer networks such as the Internet, intranets, etc.

[0299] It should also be noted that the exemplary embodiments mentioned in this application describe methods or systems based on a series of steps or apparatus. However, this application is not limited to the order of the above steps; that is, the steps can be performed in the order mentioned in the embodiments, or in a different order, or several steps can be performed simultaneously.

[0300] The aspects of this application have been described above with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of this application. It should be understood that each block in the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, or other programmable data processing apparatus to produce a machine such that these instructions, executable via the processor of the computer or other programmable data processing apparatus, enable the implementation of the functions / actions specified in one or more blocks of the flowchart illustrations and / or block diagrams. Such a processor can be, but is not limited to, a general-purpose processor, a special-purpose processor, a special application processor, or a field-programmable logic circuit. It is also understood that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, can also be implemented by dedicated hardware performing the specified functions or actions, or can be implemented by a combination of dedicated hardware and computer instructions.

[0301] The above description is merely a specific implementation of this application. Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the specific working processes of the systems, modules, and units described above can be referred to the corresponding processes in the foregoing method embodiments, and will not be repeated here. It should be understood that the protection scope of this application is not limited thereto. Any person skilled in the art can easily conceive of various equivalent modifications or substitutions within the technical scope disclosed in this application, and these modifications or substitutions should all be covered within the protection scope of this application.

Claims

1. A task processing method characterized by, The method comprises: receiving task information corresponding to a task instruction, the task instruction being an instruction received by a first application, the task information conforming to an atomization standard protocol; parsing the task information according to the atomization standard protocol to obtain task parameter information; calling an atomic capability corresponding to the task parameter information to execute a task corresponding to the task information, the atomic capability being a capability obtained by disassembling a function of a second application, the atomic capability conforming to the atomization standard protocol.

2. The method of claim 1, wherein, The atomization standard protocol comprises a permission part, a command part and a parameter part; wherein the permission part comprises a plug-in name, the command part comprises a command corresponding to the plug-in name, and the parameter part comprises a command parameter corresponding to the command; The parsing of the task information according to the atomization standard protocol to obtain task parameter information comprises: parsing a permission part of the task information to obtain at least one target plug-in name; parsing a command part of the task information to obtain at least one target command corresponding to each target plug-in name; parsing a parameter part of the task information to obtain at least one target command parameter corresponding to each target command.

3. The method of claim 1, wherein, The task parameter information comprises a target plug-in name, the task information comprises a target display device identifier, and the calling of the atomic capability corresponding to the task parameter information to execute the task corresponding to the task information to obtain an execution result comprises: determining at least one first display device identifier corresponding to the target plug-in name according to a correspondence between display device identifiers and plug-in names; in a case where the at least one first display device identifier comprises the target display device identifier, calling a target atomic capability corresponding to the target display device identifier to execute the task corresponding to the task information, and obtaining and displaying the execution result in a target display device corresponding to the target display device identifier, the target atomic capability being an atomic capability corresponding to the task parameter information.

4. The method of claim 3, wherein, After the determination of the at least one first display device identifier corresponding to the target plug-in name, the method further comprises: in a case where the at least one first display device identifier comprises the target display device identifier, and a target display device corresponding to the target display device identifier does not support the target atomic capability call, calling a target atomic capability corresponding to a third display device identifier to execute the task corresponding to the task information to obtain an execution result, a display device corresponding to the third display device identifier supporting the target atomic capability call; displaying the execution result in the target display device.

5. The method of claim 3, wherein, The first application is arranged in a second display device corresponding to a second display device identifier, the second display device being controlled by a first control unit, and the target display device being controlled by a target control unit; The calling of the target atomic capability corresponding to the target display device identifier to execute the task corresponding to the task information comprises: sending the task information to the target control unit through the first control unit; calling a target atomic capability corresponding to the target display device through the target control unit to execute the task corresponding to the task information.

6. The method of claim 3, wherein, After the at least one first display device identifier corresponding to the target plug-in name is determined, the method further comprises: In a case where the at least one first display device identifier does not include the target display device identifier, a target atomic capability corresponding to a fourth display device identifier is invoked to execute a task corresponding to the task information, to obtain an execution result, the fourth display device identifier being any one of the at least one first display device identifier; The execution result is displayed in the target display device corresponding to the target display device identifier.

7. The method of claim 6, wherein, The invoking of the target atomic capability corresponding to the fourth display device identifier to execute the task corresponding to the task information, to obtain the execution result, comprises: In a case where the display device corresponding to the fourth display device identifier is controlled by a second control unit and the target display device is controlled by a target control unit, the target atomic capability corresponding to the fourth display device identifier is invoked by the second control unit to execute the task corresponding to the task information, to obtain the execution result; The execution result is sent to the target control unit by the second control unit; The displaying of the execution result in the target display device corresponding to the target display device identifier comprises: The target display device is controlled by the target control unit to display the execution result.

8. The method according to any one of claims 3-7, characterized in that, Before the at least one first display device identifier corresponding to the target plug-in name is determined according to the correspondence between the display device identifier and the plug-in name, the method further comprises: A plurality of display devices are scanned to determine a plurality of plug-in information respectively corresponding to the plurality of display devices, each display device corresponding to a display device identifier, the plug-in information comprising the plug-in name; The correspondence between the display device identifier and the plug-in name is stored.

9. The method of claim 2, wherein, After the execution result is obtained, the method further comprises: First display content corresponding to the execution result is displayed in the first application; In a case where the target command is a callback command and associated content in the second application corresponding to the execution result is updated, the first display content in the first application is updated by using the associated content, to obtain second display content.

10. An information processing method characterized by comprising: Comprise: Obtaining function information in a second application; The function information is disassembled to obtain a plurality of sub-function information, each sub-function information comprising a plug-in name, a plurality of commands corresponding to the plug-in name, and a plurality of command parameters corresponding to each command; Each sub-function information is encapsulated according to an atomic standard protocol to obtain a function plug-in corresponding to each sub-function information, each function plug-in comprising a plurality of atomic capabilities.

11. The method of claim 10, wherein, The encapsulation of each sub-function information according to the atomic standard protocol to obtain the function plug-in corresponding to each sub-function information comprises: Obtaining plug-in name annotations corresponding to the plug-in name, command annotations corresponding to the command, command parameter annotations corresponding to the command parameter, execution result description annotations, and task identifier annotations corresponding to task information; According to the atomization standard protocol, the plug-in name and the corresponding plug-in name annotation, the command and the corresponding command annotation, the command parameter and the corresponding command parameter annotation, the execution result description annotation and the task identification annotation of each sub-function information are encapsulated to obtain the function plug-in corresponding to the plurality of sub-function information respectively.

12. A task processing apparatus characterized by comprising: The device comprises: The receiving module is configured to receive task information corresponding to a task instruction, the task instruction being an instruction received by a first application, and the task information conforming to an atomization standard protocol; The parsing module is configured to parse the task information according to the atomization standard protocol to obtain task parameter information; The execution module is configured to execute a task corresponding to the task information by invoking an atomic capability corresponding to the task parameter information, the atomic capability being an ability obtained by disassembling a function of a second application, and the atomic capability conforming to the atomization standard protocol.

13. An information processing apparatus comprising: The device comprises: The obtaining module is configured to obtain function information in a second application; The disassembling module is configured to disassemble the function information to obtain a plurality of sub-function information, each sub-function information including a plug-in name, a plurality of commands corresponding to the plug-in name, and a plurality of command parameters corresponding to each command; The encapsulating module is configured to encapsulate each sub-function information according to an atomization standard protocol to obtain function plug-ins corresponding to the plurality of sub-function information respectively, each function plug-in including a plurality of atomic capabilities.

14. An electronic device, comprising: The electronic device comprises a processor and a memory storing computer program instructions; The processor executes the computer program instructions to implement the task processing method of any one of claims 1-9 or the information processing method of any one of claims 10-11.

15. A computer-readable storage medium, characterized in that, The computer readable storage medium stores computer program instructions, and the computer program instructions are executed by the processor to implement the task processing method of any one of claims 1-9 or the information processing method of any one of claims 10-11.

16. A vehicle characterized by comprising: At least one of the following is included: The task processing device of claim 12; The information processing device of claim 13; The electronic device of claim 14; The computer readable storage medium of claim 15.

Images