Dual-protocol oriented mobile terminal system capability gateway method and device, electronic equipment and storage medium

Abstract

The application provides a dual-protocol-oriented mobile terminal system capability gateway method and device, electronic equipment and storage medium, the method comprises the following steps: receiving tool calling request of different calling parties through two types of communication protocols respectively; converting the heterogeneous request into model context protocol request data and generating request context; obtaining the tool name and calling parameter through protocol distributor analysis, and searching the tool register; after matching the target tool, executing system capability operation according to the parameter and receiving the return data; adapting and converting the execution data into corresponding protocol result and returning according to the request context, and releasing the context. The application sets dual-protocol access entrance, keeps the tool contract, permission boundary and callback mechanism of the system capability gateway consistent under the multi-protocol entrance, thereby effectively reducing the gateway development and maintenance cost, improving the operation stability, strengthening the permission security isolation, supporting the calling process observation and optimizing the mobile terminal system resource utilization.

Description

Technical Field

[0001] This invention relates to the fields of mobile terminal operating system and artificial intelligence system integration technology, specifically to a method, apparatus, electronic device and storage medium for a dual-protocol mobile terminal system capability gateway. Background Technology

[0002] In AI-driven smart device operating systems (such as iBoxAI OS), system capability calls typically involve multiple callers and communication protocols. For example, native Android applications (Apps) are well-suited to calling system services via the Android Binder / AIDL (Android Interface Definition Language) protocol, while agents or edge models running in low-privilege sandbox environments (such as Termux) are better suited to calling via network protocols such as WebSocket or TCP. Current technologies typically implement separate system capability call interfaces and gateways for different callers and communication protocols. This approach suffers from inconsistent system capability tool contracts; that is, for the same system function (such as adjusting brightness or calling a payment tool), two separate sets of interface definitions, permission verification logic, and callback mechanisms need to be maintained for different protocol entry points.

[0003] The shortcomings of the aforementioned existing technical solutions lie in the fact that the decentralization of tool contracts, permission boundaries, and callback mechanisms increases the maintenance cost of the system capability gateway. Furthermore, in scenarios involving the continuous operation of AI smart devices (such as AI smart cash registers and smartphones), it is difficult to guarantee high reliability, low latency, and state consistency of the call chain. Specifically, the decentralized implementation complicates tool upgrades, exception handling, and system resource management, potentially affecting the stability of the main interaction chain. Summary of the Invention

[0004] In view of the aforementioned problems, this application is made to provide a method, apparatus, electronic device, and storage medium for a dual-protocol mobile terminal system capability gateway that overcomes or at least partially solves the aforementioned problems, comprising: A method for a capability gateway in a dual-protocol mobile terminal system, comprising: The system receives a first tool invocation request sent by a first caller through a first communication protocol, and receives a second tool invocation request sent by a second caller through a second communication protocol. The first tool call request and the second tool call request are uniformly converted into request data corresponding to the model context protocol, and the corresponding request context is generated; The model context protocol dispatcher is invoked to parse the request data and obtain the tool name and invocation parameters; Query the preset tool registry based on the tool name; When a target tool that meets the execution conditions is found, the target tool is invoked based on the invocation parameters to perform the corresponding system capability operation, and the execution data returned by the target tool is received. Based on the request context, the execution data is converted into first result data corresponding to the first communication protocol and / or second result data corresponding to the second communication protocol; Return the first result data to the first caller, and / or return the second result data to the second caller, and release the request context.

[0005] Furthermore, the first communication protocol is the Android AIDL protocol, and the first caller is a native Android application; the second communication protocol is the local loopback WebSocket protocol, and the second caller is an agent or edge model running in a low-privilege sandbox.

[0006] Furthermore, the request data is MCP tools / call data in JSON-RPC format; the request context includes request identifier, entry protocol type, call source information, and callback method.

[0007] Furthermore, the tool registry is a mapping table between the tool name and the provider corresponding to each tool. Before calling the target tool to perform the corresponding system capability operation based on the calling parameters when a target tool that meets the execution conditions is found, and before receiving the execution data returned by the target tool, the method further includes: When the target tool is found, a tool instance corresponding to the target tool is generated through lazy loading of the Provider in the mapping table; Based on the calling parameters, the tool instance is invoked to perform the corresponding system capability operation, and the execution data is received.

[0008] Furthermore, after querying the preset tool registry based on the tool name, the process also includes: If no tool matching the execution conditions is found, then based on the request context, first error data corresponding to the first communication protocol and / or second error data corresponding to the second communication protocol are generated; The first error data is returned to the first caller, and / or the second error data is returned to the second caller.

[0009] Furthermore, the execution conditions include at least one of the following: the tool name is within a preset whitelist range, the first caller and / or the second caller has the corresponding tool's calling permission, and the current system resources meet the execution requirements.

[0010] Furthermore, the method runs in a high-privilege process of the Android system, which is either the system UID process or a privileged application process.

[0011] A capability gateway device for a dual-protocol mobile terminal system includes: The dual-entry receiving module is used to receive a first tool invocation request sent by a first caller through a first communication protocol, and to receive a second tool invocation request sent by a second caller through a second communication protocol. The first conversion module is used to convert the first tool call request and the second tool call request into request data corresponding to the model context protocol, and generate the corresponding request context; The parsing module is used to call the model context protocol dispatcher to parse the request data and obtain the tool name and calling parameters; The query module is used to query a preset tool registry based on the tool name; The execution module is used to, when a target tool that meets the execution conditions is found, invoke the target tool to perform the corresponding system capability operation based on the invocation parameters, and receive the execution data returned by the target tool; The second conversion module is used to convert the execution data into first result data corresponding to the first communication protocol and / or second result data corresponding to the second communication protocol based on the request context. The return module is configured to return the first result data to the first caller, and / or return the second result data to the second caller, and release the request context.

[0012] A computer electronic device includes a processor, a memory, and a computer program stored in the memory and capable of running on the processor, wherein the computer program, when executed by the processor, implements the steps of the dual-protocol mobile terminal system capability gateway method as described above.

[0013] A computer-readable storage medium storing a computer program that, when executed by a processor, implements the steps of the dual-protocol mobile terminal system capability gateway method as described above.

[0014] This application has the following advantages: In the embodiments of this application, addressing the problem in the prior art that "due to the decentralization of tool contracts, permission boundaries, and callback mechanisms, it is difficult for the system capability gateway to guarantee high reliability, low latency, and state consistency in the continuous operation scenario of AI intelligent devices," this application provides a solution to "maintain consistency of the system capability gateway's tool contracts, permission boundaries, and callback mechanisms under multiple protocol entry points." Specifically, this involves: "receiving a first tool call request sent by a first caller through a first communication protocol, and receiving a second tool call request sent by a second caller through a second communication protocol; uniformly converting the first tool call request and the second tool call request into request data corresponding to the model context protocol." The process involves generating a corresponding request context; invoking a model context protocol dispatcher to parse the request data, obtaining the tool name and call parameters; querying a preset tool registry based on the tool name; when a target tool matching the execution conditions is found, invoking the target tool based on the call parameters to execute the corresponding system capability operation, and receiving the execution data returned by the target tool; converting the execution data into first result data corresponding to the first communication protocol and / or second result data corresponding to the second communication protocol based on the request context; returning the first result data to the first caller, and / or returning the second result data to the second caller, and releasing the request context. This application establishes a dual-protocol entry point to receive tool call requests from different callers, and uniformly converts these heterogeneous requests into request data corresponding to the model context protocol, which is then parsed and routed by the same model context protocol dispatcher. This mechanism ensures that system capability calls from different callers follow the same set of tool contracts. Simultaneously, a unified tool registry and permission verification logic manage the execution of all tools, maintaining clear permission boundaries. Furthermore, the generated request context allows for accurate conversion and return of the unified execution data generated during tool execution to the corresponding original caller, thus ensuring the consistency of the callback mechanism. Based on the above principles, this application effectively solves the problems caused by the dispersion of protocols and implementations in the background technology, and achieves the following beneficial effects: First, by using a unified tool contract and distributor, the development and maintenance costs of the system capability gateway are reduced, and the overall stability of the system is improved; Second, by using a centralized tool registry and permission verification, permission boundary management is strengthened, and system security is improved; Third, by supporting streaming progress feedback and accurate result routing through request context, the observability of the system capability invocation process is enhanced; Fourth, by uniformly managing and lazy-loading tool instances in high-privilege processes, the utilization efficiency of mobile terminal system resources is optimized. Attached Figure Description

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

[0016] Figure 1 This is a flowchart illustrating the steps of a dual-protocol mobile terminal system capability gateway method according to an embodiment of this application; Figure 2 This is a structural block diagram of a dual-protocol mobile terminal system capability gateway device provided in one embodiment of this application; Figure 3 This is a schematic diagram of the structure of a computer electronic device provided in an embodiment of the present invention; 1. A computer electronic device; 2. An external device; 3. A processing unit; 4. A bus; 5. A network adapter; 6. An I / O interface; 7. A display; 8. Memory; 9. Random access memory; 10. A cache memory; 11. A storage system; 12. A program / utility; 13. A program module. Detailed Implementation

[0017] To make the objectives, features, and advantages of this application more apparent and understandable, the application will be further described in detail below with reference to the accompanying drawings and specific embodiments. Obviously, the described embodiments are only some, not all, of the embodiments of this application. All other embodiments obtained by those skilled in the art based on the embodiments of this application without inventive effort are within the scope of protection of this application.

[0018] In mobile terminal operating system scenarios geared towards artificial intelligence (AI), the system needs to be able to simultaneously handle system capability call requests initiated by two very different callers: the high-privilege native application layer and the low-privilege sandbox environment. These call requests are based on different underlying communication protocols, and their requirements for access control, data format, and callback mechanisms are inherently different.

[0019] Analysis of existing technologies reveals that the fragmentation of tool contracts, permission boundaries, and callback mechanisms in current smart device operating systems increases the maintenance cost of system capability gateways. Furthermore, in continuous operation scenarios of AI smart devices (such as AI smart cash registers and smartphones), it is difficult to guarantee high reliability, low latency, and state consistency across the call chain. Therefore, managing the execution of all tools through a unified tool registry and permission verification logic can maintain clear permission boundaries. In addition, utilizing the generated request context, the unified execution data generated during tool execution can be accurately converted and returned to the corresponding original caller, thereby ensuring the consistency of the callback mechanism.

[0020] To facilitate understanding of the technical solution of this application, the key terms involved in each claim of this application are explained here: MCP (Model Context Protocol): A protocol specification for enabling AI agents or models to invoke external tools in a structured manner. In this application, it specifically refers to the `tools / call` method defined in MCP, used to structure the intent to invoke system capabilities.

[0021] Tool Invocation Request: This is a structured data sent by the invoker to the gateway, containing information such as the tool name and invocation parameters. Its core purpose is to specify "which tool to invoke" and "how to invoke it." This request may have different protocol encapsulation forms when it enters different entry points of the gateway.

[0022] Request context: A data object or data structure created by the gateway after receiving a call request, which lasts throughout the entire lifecycle of the request. It is used to maintain metadata such as request identifier, original entry protocol type, call source information, and callback method of the final result, and is the core carrier to ensure callback consistency.

[0023] MCP Distributor: A logical module located within the gateway, serving as a single entry point for processing all requests converted to the MCPtools / call data format. This distributor is responsible for parsing requests, locating target tools, driving execution, and routing results, making it a key component for achieving unified tool contracts.

[0024] Tool Registry: A pre-configured data structure that records all callable system capability tools. This table establishes a mapping from "tool name" to "tool implementation" or "tool acquisition method" and serves as the sole basis for permission verification and tool legitimacy determination.

[0025] System capability operation: In this application, this refers to specific functional actions that can be executed at the mobile terminal operating system level, which may produce side effects or involve access to system resources, such as adjusting system brightness, opening the payment application interface, and modifying system settings. These operations need to be uniformly proxied and executed by a high-privilege gateway.

[0026] Provider: The provider object in the dependency injection pattern is used to create or obtain tool instances on demand and with a delay, rather than loading all tools when the gateway starts. It is a key technique for optimizing system resource consumption.

[0027] IStreamCallback: A streaming callback interface, it's a callback mechanism that supports multiple data pushes, unlike simple callbacks that only return a result once. It allows tools to continuously return progress, stage status, or intermediate results to the gateway during execution.

[0028] Reference Figure 1 This application illustrates an embodiment of a mobile terminal system capability gateway method for dual-protocol systems, comprising: S110: Receive a first tool call request sent by a first caller through a first communication protocol, and receive a second tool call request sent by a second caller through a second communication protocol; S120. The first tool call request and the second tool call request are uniformly converted into request data corresponding to the model context protocol, and the corresponding request context is generated. S130. The model context protocol dispatcher is invoked to parse the request data to obtain the tool name and invocation parameters; S140. Query the preset tool registry based on the tool name; S150. When a target tool that meets the execution conditions is found, the target tool is invoked based on the invocation parameters to perform the corresponding system capability operation, and the execution data returned by the target tool is received. S160. Based on the request context, convert the execution data into first result data corresponding to the first communication protocol and / or second result data corresponding to the second communication protocol; S170. Return the first result data to the first caller, and / or return the second result data to the second caller, and release the request context.

[0029] In the embodiments of this application, tool call requests from different callers are received through a dual-protocol entry point, and these heterogeneous requests are uniformly converted into request data corresponding to the Model Context Protocol (MGP), which is then parsed and routed by a single MGP dispatcher. This mechanism ensures that system capability calls from different callers follow the same set of tool contracts. Simultaneously, a unified tool registry and permission verification logic manage the execution of all tools, maintaining clear permission boundaries. Furthermore, using the generated request context, the unified execution data generated during tool execution can be accurately converted and returned to the corresponding original caller, thus ensuring the consistency of the callback mechanism. Through the above principles, this application effectively solves the problems caused by the dispersion of protocols and implementations in the background technology, achieving the following beneficial effects: First, by using a unified tool contract and dispatcher, the development and maintenance costs of the system capability gateway are reduced, improving the overall stability of the system; second, by using a centralized tool registry and permission verification, permission boundary management is strengthened, improving system security; third, by supporting streaming progress feedback and accurate result routing through the request context, the observability of the system capability call process is enhanced; fourth, by uniformly managing and lazy-loading tool instances in high-privilege processes, the utilization efficiency of mobile terminal system resources is optimized.

[0030] In a specific implementation, the above steps work together to form a complete processing loop. This solution solves the technical problems of inconsistent tool contracts, permission boundaries, and callback mechanisms caused by multiple protocol entry points by inserting a unified abstraction layer based on the Model Context Protocol (MCP) between the protocol entry layer and the tool execution layer. Specifically, step S110 establishes compatibility with heterogeneous communication methods from different callers; step S120 acts as the neck of the "protocol hourglass," uniformly converting all heterogeneous requests into tools / call request data in the same internal contract language—MCP—and binding a request context containing key metadata such as entry type and callback method; steps S130 and S140 constitute the "brain" of the gateway, with a single MCP dispatcher performing centralized routing and permission adjudication based on a unified tool registry; step S150 executes actual system capability operations under high-privilege protection and obtains execution data containing progress and final results; finally, steps S160 and S170 utilize the previously bound request context to precisely reverse-convert the unified internal execution data and feed it into the corresponding caller's native callback channel, achieving consistency in the callback mechanism under heterogeneous protocols. The entire process gathers, processes, and distributes requests from different callers in a "funnel-like" manner, much like an hourglass.

[0031] Taking a specific application scenario as an example, suppose that on an AI-powered smart POS device, the runtime system contains a high-privilege Android POS front-end application (the first caller) and an AI agent running in a low-privilege Termux sandbox (the second caller). The POS application needs to call ClawBox (the system capability gateway) via the AIDL protocol to perform the operation of "adjusting the screen brightness to 80%" (the first tool call request). Simultaneously, when planning payment tasks, the AI ​​agent in Termux needs to call the same ClawBox via the local loopback WebSocket protocol to "open the payment POS tool" (the second tool call request). After the gateway starts, it listens to both the AIDL interface and the local WebSocket port 127.0.0.1:9990. When an AIDL request arrives, the entry layer processes the received string-formatted MCP request data and callback object, along with the WebSocket connection object and its JSON-RPC message, into internally formatted MCPtools / call data, and generates two request contexts containing the AIDL callback method and WebSocket connection information respectively. Subsequently, the same MCP dispatcher resolved the two requests sequentially, retrieving their respective tool names, `system.setBrightness` and `payment.launch`, along with their parameters. The dispatcher then queried the tool registry in memory and located and executed the corresponding `SetBrightnessTool` and `LaunchPaymentTool` system tools. When `system.setBrightness` was executed, the tool called the `Settings.System` interface of the Android Framework to modify the brightness value; when `payment.launch` was executed, the tool launched the payment interface via `startActivity`. During execution, both tools reported their progress to the dispatcher via a unified `IStreamCallback` streaming callback interface (e.g., "Payment interface loading" or "Brightness adjustment complete"). This unified format of execution data was transformed by the dispatcher according to their respective request contexts: the execution result sent to the AIDL request was encapsulated as an AIDL `Result` object and sent via a Binder callback; the execution result sent to the WebSocket request was encapsulated as a JSON-RPC `result` response and pushed via the WebSocket connection. Ultimately, the POS application successfully adjusted the screen brightness, and the AI ​​agent successfully launched the payment POS interface; the contexts of both requests were safely released. Throughout the process, although the caller, protocol, and final implementation are quite different, they all strictly adhere to the same set of MCP tool contracts and are executed securely under a unified permission model.

[0032] The following will further explain the dual-protocol mobile terminal system capability gateway method in this exemplary embodiment.

[0033] In one embodiment of the present invention, the following description can be used to further explain the step S110 of "receiving a first tool call request sent by a first caller through a first communication protocol and receiving a second tool call request sent by a second caller through a second communication protocol".

[0034] In one specific implementation, the first communication protocol is the Android AIDL protocol, and the first caller is a native Android application; the second communication protocol is the local loopback WebSocket protocol, and the second caller is an agent or client-side model running in a low-privilege sandbox. The first communication protocol is the Android AIDL protocol, and the first caller is a native Android application; the second communication protocol is the local loopback WebSocket protocol, and the second caller is an agent or client-side model running in a low-privilege sandbox. The Android AIDL protocol is a high-performance inter-process communication method based on the Binder mechanism, suitable for applications running within the Android system with direct system service reference capabilities; while the local loopback WebSocket protocol is a standardized full-duplex long-connection communication protocol that binds the server to a local loopback address (127.0.0.1), not providing access to the external network, thereby ensuring communication capabilities while reducing security risks. This WebSocket protocol is well-suited for the communication needs of agents or client-side models running in low-privilege sandboxes such as Termux, which cannot directly use the Android Binder mechanism. By combining these two communication protocols with different physical characteristics and applicable scenarios, the gateway can comprehensively cover the two main types of caller entities on mobile terminals, ensuring the comprehensiveness and reliability of the access method from the starting point of the communication link.

[0035] In one embodiment of the present invention, the following description can be used to further explain step S120, which involves "converting the first tool call request and the second tool call request into request data corresponding to the model context protocol and generating the corresponding request context".

[0036] In one specific implementation, the request data is MCP tools / call data in JSON-RPC format; the request context includes a request identifier, entry protocol type, call source information, and callback method. JSON-RPC is a lightweight, language-independent data exchange protocol format whose request object typically includes method, params, and id fields. It is used as a unified internal request data format because it strictly maps to the MCP tools / call call structure, where the method field is the tools / call itself, and the params contain the tool name and parameters. This unified format eliminates protocol-level differences, allowing the subsequent MCP dispatcher to understand only one data contract. Simultaneously, the request context generated in this step serves as a "passport" for this call throughout its internal gateway lifecycle, binding and recording key data such as the request identifier, entry protocol type, call source information, and callback method. The request identifier is used to associate requests and responses, avoiding packet calls under high concurrency; the record of the entry protocol type (AIDL or WebSocket) and callback method (Binder callback object or WebSocket connection object) provides the only basis for the final correct and accurate reverse conversion and routing of result data, and is the key to achieving consistent conversion from unified execution data to heterogeneous callback protocols.

[0037] In one embodiment of the present invention, the tool registry is a mapping table of tool names and providers corresponding to each tool. The specific features of the "Method for Dual-Protocol Mobile Terminal System Capability Gateway" before step S150 can be further described in conjunction with the following description.

[0038] As described in the following steps, when the target tool is found, a tool instance corresponding to the target tool is generated through lazy loading of the Provider in the mapping table; the tool instance is invoked based on the invocation parameters to perform the corresponding system capability operation, and the execution data is received.

[0039] In one specific implementation, this embodiment replaces the conventional practice of pre-initializing all tool instances at gateway startup with a Provider lazy loading mechanism, which is a key resource optimization technique. The tool registry does not store the tool instances themselves, but rather the "factory" (i.e., Provider) that generates instances. Only when the MCP dispatcher queries and confirms for the first time that a target tool meets the execution conditions will it call its corresponding Provider to create the actual instance of that tool. This lazy loading design avoids memory waste and increased startup time caused by loading a large number of system capability tools (such as payment, specific input management, etc.) that may not be called for a long time under the limited memory resources of mobile terminals. Furthermore, this ensures that the required system resources are only truly occupied when the first call request for the tool arrives, optimizing overall resource utilization efficiency.

[0040] In one embodiment of the present invention, the specific features of the "Method for Dual-Protocol Mobile Terminal System Capability Gateway" after step S140 can be further described in conjunction with the following description.

[0041] As described in the following steps, if no tool matching the execution conditions is found, first error data corresponding to the first communication protocol and / or second error data corresponding to the second communication protocol are generated based on the request context; the first error data is returned to the first caller, and / or the second error data is returned to the second caller.

[0042] In one specific implementation, this embodiment defines an explicit handling path for tool call failures, forming a negative feedback loop that ensures the caller receives a deterministic response under all circumstances, avoiding the unobservable state of call requests "sinking without a trace." Unmet execution conditions may include the tool name not existing in the registry, or existing but failing permission verification. When this occurs, the gateway does not return a generic, vague system error to the caller. Instead, it uses the generated request context to generate error data conforming to its original protocol specifications. For example, for calls from AIDL, an AIDL exception or a callback containing a specific error code is generated; for WebSocket calls, an error object conforming to the JSON-RPC 2.0 specification (containing an error field and the corresponding error code and error information) is generated and pushed back via the corresponding WebSocket connection. This protocol-adaptive error routing mechanism allows different callers to understand the cause of failure in a standard way, improving the system's debuggability and robustness.

[0043] In one embodiment of the present invention, the following description can be used to further explain step S150, which states that "when a target tool that meets the execution conditions is found, the target tool is invoked based on the invocation parameters to perform the corresponding system capability operation, and the execution data returned by the target tool is received".

[0044] In one specific implementation, the execution conditions include at least one of the following: the tool name is within a preset whitelist range, the first caller and / or the second caller has the corresponding tool's calling permissions, and the current system resources meet the execution requirements. This is a combined condition judgment that ensures system security and stability from multiple dimensions. The whitelist range is a static security baseline that ensures that only explicitly registered and approved tools can be executed, preventing the injection of malicious or unauthorized tools. Calling permissions are a set of dynamic access control rules, which can be implemented by: determining whether the caller has marked a permission declaration identifier for using specific tools (such as payment, system setting modification, and other high-risk tools) based on the call source information (such as the caller application's UID or package name); this secondary centralized permission verification at the gateway level ensures that even if an application in a low-permission sandbox issues a call request, it cannot bypass the gateway to execute system capabilities beyond its permission scope. Ensuring that current system resources meet execution requirements is a dynamic runtime guarantee. For example, when memory is extremely low, a payment operation that requires launching a new interface can be refused, and a "system busy" error can be returned to the caller instead. This method prevents the system from lag or crashing due to high-consumption operations when resources are scarce, ensuring the smoothness of current foreground tasks and the overall stability of the system.

[0045] In one embodiment of the present invention, the "Method for a Dual-Protocol Mobile Terminal System Capability Gateway" can be further described in detail below.

[0046] In one specific implementation, this dual-protocol mobile terminal system capability gateway method runs in a high-privilege process of the Android system, which is either a system UID process or a privileged application process. The carrier and runtime environment of the method are the cornerstones for realizing its permission boundaries. The system UID process (system_server) is one of the most core processes in the Android system, possessing the highest privileges to execute Framework layer system APIs; while a privileged application process (priv-app) is a special application process granted protection levels such as signatureOrSystem by the system, and its privileges are far higher than those of ordinary third-party applications. Deploying the gateway in such a high-privilege process ensures that when the target tool called in step S150 actually performs system capability operations (such as modifying global system settings, launching an Activity with a special intent, simulating user input, etc.), its process itself has the underlying permissions to perform these operations, and the gateway does not need to implement it again through complex cross-process permission delegation. This fundamentally solves the contradiction of "how to securely execute high-privilege operations requested by low-privilege callers," making protected operations such as controlled memory cleanup, memory compression, and system setting modification safe and feasible.

[0047] As the device embodiment is basically similar to the method embodiment, the description is relatively simple, and relevant parts can be found in the description of the method embodiment.

[0048] Reference Figure 2 This illustration shows an embodiment of a dual-protocol mobile terminal system capability gateway device 200 provided in this application, used to implement the dual-protocol mobile terminal system capability gateway method provided in this application embodiment. The device specifically includes: The dual-entry receiving module 210 is used to receive a first tool call request sent by a first caller through a first communication protocol, and to receive a second tool call request sent by a second caller through a second communication protocol. The first conversion module 220 is used to convert the first tool call request and the second tool call request into request data corresponding to the model context protocol, and generate the corresponding request context; Parsing module 230 is used to call the model context protocol dispatcher to parse the request data and obtain the tool name and calling parameters; Query module 240 is used to query a preset tool registry based on the tool name; The execution module 250 is used to, when a target tool that meets the execution conditions is found, invoke the target tool to perform the corresponding system capability operation based on the invocation parameters, and receive the execution data returned by the target tool; The second conversion module 260 is used to convert the execution data into first result data corresponding to the first communication protocol and / or second result data corresponding to the second communication protocol based on the request context. The return module 270 is configured to return the first result data to the first caller, and / or return the second result data to the second caller, and release the request context.

[0049] In one embodiment of the present invention, the first communication protocol is the Android AIDL protocol, and the first caller is a native Android application; the second communication protocol is the local loopback WebSocket protocol, and the second caller is an agent or edge model running in a low-privilege sandbox.

[0050] In one embodiment of the present invention, the request data is MCP tools / call data in JSON-RPC format; the request context includes a request identifier, an entry protocol type, call source information, and a callback method.

[0051] In one embodiment of the present invention, the tool registry is a mapping table of tool names and providers corresponding to each tool, and the dual-protocol mobile terminal system capability gateway device 200 is further used for: When the target tool is found, a tool instance corresponding to the target tool is generated through lazy loading of the Provider in the mapping table; Based on the calling parameters, the tool instance is invoked to perform the corresponding system capability operation, and the execution data is received.

[0052] In one embodiment of the present invention, the dual-protocol mobile terminal system capability gateway device 200 is further configured to: If no tool matching the execution conditions is found, then based on the request context, first error data corresponding to the first communication protocol and / or second error data corresponding to the second communication protocol are generated; The first error data is returned to the first caller, and / or the second error data is returned to the second caller.

[0053] In one embodiment of the present invention, the execution conditions include at least one of the following: the tool name is within a preset whitelist range, the first caller and / or the second caller has the corresponding tool's calling permission, and the current system resources meet the execution requirements.

[0054] In one embodiment of the present invention, the method runs in a high-privilege process of the Android system, wherein the high-privilege process is the system UID process or a privileged application process.

[0055] Reference Figure 3 The illustration shows a computer electronic device 1 for implementing the dual-protocol mobile terminal system capability gateway method of the present invention, which may specifically include: The computer electronic device 1 is manifested in the form of a general computing device, including: one or more processors or processing units 3, memory 8, and a bus 4 connecting different system components (including memory 8 and processing unit 3).

[0056] Bus 4 represents one or more of several bus architectures, including memory buses or memory controllers, peripheral buses, graphics acceleration ports, processors, or local buses using any of the various bus architectures. For example, these architectures include, but are not limited to, the Industry Standard Architecture (ISA) bus, the Micro Channel Architecture (MAC) bus, the Enhanced ISA bus, the Audio / Video Electronics Standards Association (VESA) local bus, and the Peripheral Component Interconnect (PCI) bus.

[0057] Computer electronic device 1 typically includes a variety of computer system readable media. These media can be any available media that can be accessed by computer electronic device 1, including volatile and non-volatile media, removable and non-removable media.

[0058] Memory 8 may include computer system readable media in the form of volatile memory, such as random access memory 9 and / or cache memory 10. A computer electronic device 1 may further include other removable / non-removable, volatile / non-volatile computer system storage media. By way of example only, storage system 11 may be used to read and write non-removable, non-volatile magnetic media (commonly referred to as a "hard disk drive"). Although Figure 3 As not shown, a disk drive for reading and writing to a removable non-volatile disk (such as a "floppy disk") and an optical disk drive for reading and writing to a removable non-volatile optical disk (such as a CD-ROM, DVD-ROM, or other optical media) may be provided. In these cases, each drive may be connected to bus 4 via one or more data media interfaces. The memory may include at least one program product having a set (e.g., at least one) of program modules 13 configured to perform the functions of the embodiments of this application.

[0059] A program / utility 12 having a set (at least one) of program modules 13 may be stored, for example, in memory. Such program modules 13 include—but are not limited to—an operating system, one or more application programs, other program modules 13, and program data. Each or some combination of these examples may include an implementation of a network environment. Program modules 13 typically perform the functions and / or methods described in the embodiments of this application.

[0060] The computer electronic device 1 can also communicate with one or more external devices 2 (e.g., keyboard, pointing device, display 7, camera, etc.), and with one or more devices that enable an operator to interact with the computer electronic device 1, and / or with any device that enables the computer electronic device 1 to communicate with one or more other computing devices (e.g., network card, modem, etc.). This communication can be performed through the I / O interface 6. Furthermore, the computer electronic device 1 can also communicate with one or more networks (e.g., local area network (LAN)), wide area network (WAN), and / or public networks (e.g., the Internet) through the network adapter 5. Figure 3 As shown, network adapter 5 communicates with other modules of computer electronic device 1 via bus 4. It should be understood that, although... Figure 3 Not shown, it may be combined with other hardware and / or software modules, including but not limited to: microcode, device drivers, redundant processing unit 3, external disk drive array, RAID system, tape drive and data backup storage system 11, etc.

[0061] The processing unit 3 executes various functional applications and data processing by running programs stored in memory 8, such as implementing the dual-protocol mobile terminal system capability gateway method provided in the embodiments of this application.

[0062] That is, when the processing unit 3 executes the above program, it performs the following: receiving a first tool call request sent by a first caller through a first communication protocol, and receiving a second tool call request sent by a second caller through a second communication protocol; converting the first tool call request and the second tool call request into request data corresponding to the model context protocol, and generating a corresponding request context; calling the model context protocol dispatcher to parse the request data to obtain the tool name and call parameters; querying a preset tool registry based on the tool name; when a target tool that meets the execution conditions is found, calling the target tool to perform the corresponding system capability operation based on the call parameters, and receiving the execution data returned by the target tool; converting the execution data into first result data corresponding to the first communication protocol and / or second result data corresponding to the second communication protocol based on the request context; returning the first result data to the first caller, and / or returning the second result data to the second caller, and releasing the request context.

[0063] In this application embodiment, the application also provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the dual-protocol mobile terminal system capability gateway method provided in all embodiments of the application.

[0064] That is, when the program is executed by the processor, it implements the following: receiving a first tool call request sent by a first caller through a first communication protocol, and receiving a second tool call request sent by a second caller through a second communication protocol; converting the first tool call request and the second tool call request into request data corresponding to the Model Context Protocol, and generating a corresponding request context; calling the Model Context Protocol dispatcher to parse the request data to obtain the tool name and call parameters; querying a preset tool registry based on the tool name; when a target tool that meets the execution conditions is found, calling the target tool to execute the corresponding system capability operation based on the call parameters, and receiving the execution data returned by the target tool; converting the execution data into first result data corresponding to the first communication protocol and / or second result data corresponding to the second communication protocol based on the request context; returning the first result data to the first caller, and / or returning the second result data to the second caller, and releasing the request context.

[0065] Any combination of one or more computer-readable media may be used. A computer-readable medium can be a computer-readable signal medium or a computer-readable storage medium. A computer-readable storage medium can be, for example—but not limited to—an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples (a non-exhaustive list) of computer-readable storage media include: an electrical connection having one or more wires, a portable computer disk, a hard disk, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof. In this document, a computer-readable storage medium can be any tangible medium that contains or stores a program that can be used by or in connection with an instruction execution system, apparatus, or device.

[0066] Computer-readable signal media may include data signals propagated in baseband or as part of a carrier wave, carrying computer-readable program code. Such propagated data signals may take various forms, including—but not limited to—electromagnetic signals, optical signals, or any suitable combination thereof. Computer-readable signal media may also be any computer-readable medium other than computer-readable storage media, capable of transmitting, propagating, or transmitting programs for use by or in connection with an instruction execution system, apparatus, or device.

[0067] Computer program code for performing the operations of this application can be written in one or more programming languages ​​or a combination thereof. These programming languages ​​include object-oriented programming languages ​​such as Java, Smalltalk, and C++, as well as conventional procedural programming languages ​​such as C or similar languages. The program code can be executed entirely on the operator's computer, partially on the operator's computer, as a standalone software package, partially on the operator's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving remote computers, the remote computer can be connected to the operator's computer via any type of network—including a local area network (LAN) or a wide area network (WAN)—or can be connected to an external computer (e.g., via the Internet using an Internet service provider). The various embodiments in this specification are described in a progressive manner, with each embodiment focusing on the differences from other embodiments. Similar or identical parts between embodiments can be referred to interchangeably.

[0068] Although preferred embodiments of the present application have been described, those skilled in the art, upon learning the basic inventive concept, can make other changes and modifications to these embodiments. Therefore, the appended claims are intended to be interpreted as including the preferred embodiments as well as all changes and modifications falling within the scope of the embodiments of the present application.

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

[0070] The above provides a detailed description of the method, apparatus, electronic device, and storage medium for a dual-protocol mobile terminal system capability gateway provided in this application. Specific examples have been used to illustrate the principles and implementation methods of this application. The descriptions of the above embodiments are only for the purpose of helping to understand the method and core ideas of this application. At the same time, for those skilled in the art, there will be changes in the specific implementation methods and application scope based on the ideas of this application. Therefore, the content of this specification should not be construed as a limitation of this application.

Claims

1. A capability gateway method for dual-protocol mobile terminal systems, characterized in that, include: The system receives a first tool invocation request sent by a first caller through a first communication protocol, and receives a second tool invocation request sent by a second caller through a second communication protocol. The first tool call request and the second tool call request are uniformly converted into request data corresponding to the model context protocol, and the corresponding request context is generated; The model context protocol dispatcher is invoked to parse the request data and obtain the tool name and invocation parameters; Query the preset tool registry based on the tool name; When a target tool that meets the execution conditions is found, the target tool is invoked based on the invocation parameters to perform the corresponding system capability operation, and the execution data returned by the target tool is received. Based on the request context, the execution data is converted into first result data corresponding to the first communication protocol and / or second result data corresponding to the second communication protocol; Return the first result data to the first caller, and / or return the second result data to the second caller, and release the request context.

2. The method according to claim 1, characterized in that, The first communication protocol is the Android AIDL protocol, and the first caller is a native Android application; the second communication protocol is the local loopback WebSocket protocol, and the second caller is an agent or edge model running in a low-privilege sandbox.

3. The method according to claim 1, characterized in that, The request data is MCPtools / call data in JSON-RPC format; the request context includes the request identifier, entry protocol type, call source information, and callback method.

4. The method according to claim 1, characterized in that, The tool registry is a mapping table between the tool name and the provider corresponding to each tool. Before calling the target tool to perform the corresponding system capability operation based on the calling parameters when a target tool that meets the execution conditions is found, and before receiving the execution data returned by the target tool, the process further includes: When the target tool is found, a tool instance corresponding to the target tool is generated through lazy loading of the Provider in the mapping table; Based on the calling parameters, the tool instance is invoked to perform the corresponding system capability operation, and the execution data is received.

5. The method according to claim 1, characterized in that, After querying the preset tool registry based on the tool name, the process further includes: If no tool matching the execution conditions is found, then based on the request context, first error data corresponding to the first communication protocol and / or second error data corresponding to the second communication protocol are generated; The first error data is returned to the first caller, and / or the second error data is returned to the second caller.

6. The method according to claim 1, characterized in that, The execution conditions include at least one of the following: the tool name is within a preset whitelist, the first caller and / or the second caller has the corresponding tool's calling permission, and the current system resources meet the execution requirements.

7. The method according to any one of claims 1 to 6, characterized in that, The method runs in a high-privilege process of the Android system, which is either the system UID process or a privileged application process.

8. A capability gateway device for a dual-protocol mobile terminal system, characterized in that, include: The dual-entry receiving module is used to receive a first tool invocation request sent by a first caller through a first communication protocol, and to receive a second tool invocation request sent by a second caller through a second communication protocol. The first conversion module is used to convert the first tool call request and the second tool call request into request data corresponding to the model context protocol, and generate the corresponding request context; The parsing module is used to call the model context protocol dispatcher to parse the request data and obtain the tool name and calling parameters; The query module is used to query a preset tool registry based on the tool name; The execution module is used to, when a target tool that meets the execution conditions is found, invoke the target tool to perform the corresponding system capability operation based on the invocation parameters, and receive the execution data returned by the target tool; The second conversion module is used to convert the execution data into first result data corresponding to the first communication protocol and / or second result data corresponding to the second communication protocol based on the request context. The return module is configured to return the first result data to the first caller, and / or return the second result data to the second caller, and release the request context.

9. A computer electronic device, characterized in that, It includes a processor, a memory, and a computer program stored in the memory and capable of running on the processor, wherein the computer program, when executed by the processor, implements the steps of the dual-protocol mobile terminal system capability gateway method as described in any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that, A computer program is stored on the computer-readable storage medium, which, when executed by a processor, implements the steps of the method for a dual-protocol mobile terminal system capability gateway as described in any one of claims 1 to 7.

Images